Supabase для ИИ-агентов: память и векторный поиск

Агенту нужна память снаружи: модель не помнит ничего между вызовами, а контекст кончается быстрее, чем кажется. Supabase закрывает эту задачу без отдельной инфраструктуры.

Хранение состояния агента

Три вещи, которые обязательно живут в базе:

Что уже сделано. Основа идемпотентности. Агент перезапустился - он должен узнать, что письмо уже отправлено, а не отправить второе. Без этого повторный запуск создаёт двойные эффекты - см. идемпотентные пайплайны.

Результаты работы. Извлечённые факты, принятые решения, созданные объекты. Держать их только в разговоре - значит потерять при первой компакции контекста.

Логи шагов. Что было на входе, какой инструмент вызван, что вернулось. Без этого разбор инцидента невозможен: вы видите результат и не видите, почему он такой.

Практическая деталь: логи растут быстро. Ограничивайте срок хранения сразу, иначе они станут основной таблицей в базе.

Развёрнуто про то, что и как агент помнит, - память ИИ-агента.

Векторный поиск

Задача: найти релевантное среди многого, когда точного совпадения по словам нет. Пользователь спрашивает своими словами, а в документах написано иначе.

Как это работает: текст превращается в набор чисел, отражающий смысл, и поиск идёт по близости этих наборов. Тексты о похожем оказываются рядом, даже если слова разные.

В PostgreSQL это делается расширением для векторов: отдельная система не нужна. Практические преимущества такого варианта:

• Данные и векторы вместе. Не нужно синхронизировать два хранилища.
• Обычные фильтры работают. Можно искать похожее среди документов конкретного пользователя - в отдельном векторном движке это сложнее.
• Права доступа работают. Те же политики, что и на остальных таблицах, - см. авторизацию и RLS.

Когда нужен отдельный движок: на больших объёмах и высокой частоте запросов. Для MVP и для внутренних инструментов это преждевременно.

Что учесть на практике:

Индекс обязателен. Без него поиск идёт перебором по всей таблице и на десятках тысяч записей становится неприемлемо медленным.

Размер фрагмента. Слишком большие куски текста дают размытый результат, слишком мелкие теряют контекст. Настраивается опытным путём на ваших данных.

Гибридный поиск. Сочетание векторного и обычного текстового поиска обычно даёт лучший результат, чем любой из них по отдельности.

Смена модели векторизации ломает индекс. Векторы, посчитанные разными моделями, несравнимы. Смена модели означает пересчёт всего.

Что держать в базе, а что нет

В базе:

• Состояние и отметки о выполненном.
• Извлечённые факты и результаты.
• Векторы и документы для поиска.
• Логи шагов с ограниченным сроком хранения.
• Метрики: число шагов, стоимость, доля неудач.

Не в базе:

• Сырые ответы моделей целиком. Занимают много, переиспользуются почти никогда.
• Полный контекст каждого шага. То же самое.
• Секреты. Ключи от моделей и внешних сервисов - в переменных окружения функций, а не в таблицах.
• Персональные данные без необходимости. Если их можно не хранить, лучше не хранить.

Типовые ошибки

1. Нет проверки на повтор. Агент перезапустился и выполнил действие дважды.
2. Нет индекса на векторах. Работает на сотне записей, встаёт на десяти тысячах.
3. Логи без ограничения срока. Через месяц они занимают больше, чем данные.
4. Служебный ключ в клиенте. Агент, работающий в браузере с полным доступом к базе, - это открытая база.
5. Векторизация при каждом запросе. Пересчитывать векторы документов надо один раз при загрузке, а не при каждом поиске.

Общая теория - гид по ИИ-агентам. Общая картина по инструменту - гид по Supabase.