AI-агент без памяти обречён заново представляться каждый разговор. Решение — векторная БД: хранит эмбеддинги ваших документов, заметок или прошлых чатов, чтобы агент по запросу вспоминал нужные куски (это «R» в RAG). Можно взять managed-сервис, а можно поднять самому на VPS и держать данные — часто ваши приватные — на машине, которую контролируете вы. Вот как, и что это реально стоит по RAM.
Два хороших варианта
Ничего экзотического не нужно. Два пути покрывают почти всех:
pgvector — расширение Postgres. Если уже крутите Postgres (или не против) — оно добавляет векторный поиск в БД, что у вас уже есть. Один сервис, один бэкап, знакомый SQL. Самый ненапряжный старт с большим отрывом.
Qdrant — профильный векторный движок. Берите, когда много векторов (низкие миллионы+) или нужна быстрая фильтрация по метаданным и отдельный API. Это отдельный сервис, но он сделан ровно под эту задачу.
Для большинства агентов, что встают на ноги, pgvector — правильный первый ответ. К Qdrant переходите, когда переросли, не раньше.
Реальность по RAM (это и недооценивают)
Векторный поиск быстр, потому что индекс живёт в памяти — так что RAM, не диск, ваше реальное ограничение. Грубый ориентир:
- Пара сотен тысяч эмбеддингов — комфортно в 2 ГБ.
- Низкие миллионы — закладывайте 4 ГБ+ и тюньте индекс.
- Диск — лёгкая часть: миллион эмбеддингов это всего несколько ГБ, так что 25–45 ГБ покрывают серьёзное хранилище.
Так что берите под индекс, не под файл. (Та же логика, что в общем гайде по sizing — тяжёлое неочевидно, пока не измеришь.)
Быстрый старт: pgvector
На машине с Postgres (Docker проще всего — тот же паттерн, что self-host n8n):
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE memory (
id bigserial PRIMARY KEY,
content text,
embedding vector(1536) -- под размерность вашей модели эмбеддингов
);
-- когда появятся данные, постройте индекс для быстрого поиска:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);
Агент вставляет content + его эмбеддинг, затем запрашивает ORDER BY embedding <=> $query_embedding LIMIT 5, чтобы достать ближайшие воспоминания. Это весь цикл.
Хотите Qdrant? Это один Docker-контейнер с HTTP/gRPC API; создаёте коллекцию с размером вектора и upsert'ите точки. Та же идея, профильный движок.
Может ли он делить машину с агентом?
Да — для малых-средних хранилищ запускайте векторную БД на том же VPS, что и агент. Проще, и задержка почти ноль. Разносите по разным серверам, только когда один начинает теснить другой по RAM. Это поздняя приятная проблема, не задача первого дня.
Честные оговорки
- RAM — это стена, и тихая. Поиск остаётся быстрым, пока индекс влезает в память, потом деградирует. Следите за памятью и увеличивайте до того, как укусит — не ждите медленных запросов как сигнала.
- Эмбеддинги стоят токенов. Каждый документ, что вы эмбеддите, — вызов API модели эмбеддингов. Хранилище дёшево держать; генерация векторов — повторяющийся расход, релевантно тому, что реально стоит держать агента.
- Бэкапьте. Память агента — данные как любые другие. Важно — снапшотьте.
В этих рамках self-hosted векторное хранилище — чистый способ дать агенту прочную память, не отдавая приватные данные третьим. Старт с pgvector на 2 ГБ, следите за RAM, и растите в Qdrant или больший тариф, только когда цифры скажут.