Хоствай векторна база данни за памет на AI агент на VPS

AI агент без памет е заседнал да се представя наново всеки разговор. Решението е векторна база данни — тя съхранява embeddings на документите, бележките или минали чатове, така че агентът може да си припомни релевантните части при поискване (това е „R“-то в RAG). Можеш да наемеш това като управлявана услуга, или да го пуснеш сам на VPS и да държиш данните си — които често са твоите лични данни — на машина, която контролираш. Ето как и колко реално струва в RAM.

Две добри опции

Не се нуждаеш от нищо екзотично. Два пътя покриват почти всеки:

pgvector — Postgres разширение. Ако вече пускаш Postgres (или си щастлив да го направиш), това добавя векторно търсене към базата данни, която вече имаш. Една услуга, един архив, SQL, който познаваш. Началото с най-малко усилие с широка разлика.

Qdrant — специализиран векторен двигател. Посегни към него, когато имаш много вектори (ниски милиони+) или искаш бързо филтриране по метаданни и специално API. Отделна услуга е за пускане, но е построена точно за тази работа.

За повечето агенти, намиращи стъпката си, pgvector е правилният първи отговор. Премести се към Qdrant, когато си го надраснал, не преди.

Реалността на RAM (това е частта, която хората подценяват)

Векторното търсене е бързо, защото индексът живее в паметта — така че RAM, не дискът, е реалното ти ограничение. Грубо ръководство:

• Няколко стотин хиляди embeddings — комфортно в 2 GB.
• Ниски милиони — планирай 4 GB+ и настрой индекса.
• Дискът е лесната част: милион embeddings е само няколко GB, така че 25–45 GB покриват сериозен store.

Така че оразмерявай за индекса, не за файла. (Същата логика като общото ръководство за оразмеряване — тежкото нещо не е очевидно, докато не го измериш.)

Бърз старт: pgvector

На машина с Postgres (Docker е най-лесен — същият модел като self-hosting на n8n):

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- match your embedding model's dimensions
);

-- after you have data, build an index for fast search:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

Агентът ти вмъква content + неговия embedding, после прави заявка с ORDER BY embedding <=> $query_embedding LIMIT 5, за да извлече най-близките спомени. Това е целият цикъл.

Предпочиташ Qdrant? То е единичен Docker контейнер, излагащ HTTP/gRPC API; създаваш колекция с размера на вектора си и правиш upsert на точки. Същата идея, специализиран двигател.

Може ли да споделя машина с агента?

Да — за малки-до-средни store-ове за памет, пусни DB за вектори на същия VPS като агента. По-просто е и латентността е практически нула. Раздели ги на отделни сървъри само когато единият започне да изтласква другия от RAM. Това е по-късно решение, приятен проблем за имане, не от първия ден.

Честни забележки

• RAM е стената, и е тиха. Търсенето остава бързо, докато индексът вече не се събира в паметта, после деградира. Гледай паметта и ресайзвай преди да захапе — не чакай бавните заявки да ти кажат.
• Embeddings-ите струват токени за създаване. Всеки документ, който вграждаш, е API извикване към модел за embedding. Store-ът е евтин за хостване; генерирането на векторите е повтарящият се разход — релевантно за колко реално струва пускането на агент.
• Архивирай го. Паметта на агента ти е данни като всякакви други. Ако има значение, направи ѝ снимка.

Вътре в това self-hosted vector store е чист начин да дадеш на агент трайна памет, без да предаваш личните си данни на трета страна. Започни с pgvector на машина от 2 GB, дръж око на RAM и порасни към Qdrant или по-голям план само когато числата ти кажат.