Găzduiește o bază vectorială pentru memoria agentului AI pe un VPS

Un agent AI fără memorie e condamnat să se prezinte din nou la fiecare conversație. Soluția e o bază de date vectorială — stochează embeddingurile documentelor, notițelor sau conversațiilor trecute, ca agentul să-și amintească la cerere bucățile relevante (ăsta e „R”-ul din RAG). O poți închiria ca serviciu administrat sau o poți rula singur pe un VPS și îți ții datele — care sunt adesea datele tale private — pe o mașină pe care o controlezi. Iată cum și cât costă de fapt în RAM.

Două opțiuni bune

Nu-ți trebuie nimic exotic. Două căi acoperă aproape pe toată lumea:

pgvector — o extensie Postgres. Dacă rulezi deja Postgres (sau n-ai nimic împotrivă), adaugă căutare vectorială la baza de date pe care o ai deja. Un singur serviciu, un singur backup, SQL pe care îl știi. De departe începutul cu cel mai mic efort.

Qdrant — un motor vectorial construit special. Apelează la el când ai mulți vectori (câteva milioane+) sau vrei filtrare rapidă după metadate și un API dedicat. E un serviciu separat de rulat, dar e construit exact pentru treaba asta.

Pentru majoritatea agenților care își caută drumul, pgvector e primul răspuns corect. Treci la Qdrant când l-ai depășit, nu înainte.

Realitatea RAM-ului (partea pe care oamenii o subestimează)

Căutarea vectorială e rapidă pentru că indexul stă în memorie — deci RAM-ul, nu discul, e limita ta reală. Un ghid aproximativ:

• Câteva sute de mii de embeddinguri — comod în 2 GB.
• Câteva milioane — socotește 4 GB+ și ajustează indexul.
• Discul e partea ușoară: un milion de embeddinguri înseamnă doar câțiva GB, deci 25–45 GB acoperă o memorie serioasă.

Așa că dimensionează după index, nu după fișier. (Aceeași logică precum în ghidul general de dimensionare — lucrul greu nu e evident până nu măsori.)

Pornire rapidă: pgvector

Pe o mașină cu Postgres (Docker e cel mai simplu — același tipar ca la găzduirea 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);

Agentul tău inserează content + embeddingul lui, apoi interoghează cu ORDER BY embedding <=> $query_embedding LIMIT 5 ca să scoată cele mai apropiate amintiri. Asta e toată bucla.

Preferi Qdrant? E un singur container Docker care expune un API HTTP/gRPC; creezi o colecție cu dimensiunea vectorilor tăi și faci upsert de puncte. Aceeași idee, motor dedicat.

Poate sta pe aceeași mașină cu agentul?

Da — pentru memorii mici și medii, rulează baza vectorială pe același VPS cu agentul. E mai simplu, iar latența e practic zero. Separă-le pe servere diferite doar când unul începe să-l împingă pe celălalt afară din RAM. E o decizie de mai târziu, o problemă bună de avut, nu una din prima zi.

Rezerve cinstite

• RAM-ul e zidul, și e tăcut. Căutarea rămâne rapidă până când indexul nu mai încape în memorie, apoi se degradează. Urmărește memoria și redimensionează înainte să te muște — nu aștepta ca interogările lente să-ți spună.
• Crearea embeddingurilor costă tokeni. Fiecare document pe care îl transformi în embedding e un apel API către un model de embedding. Baza e ieftin de găzduit; generarea vectorilor e costul recurent — relevant pentru cât costă de fapt rularea unui agent.
• Fă-i backup. Memoria agentului tău e date, ca oricare altele. Dacă contează, fă-i backup.

În limitele astea, o bază vectorială găzduită de tine e o cale curată de a-i da unui agent memorie durabilă fără să predai datele private unui terț. Pornește cu pgvector pe o mașină de 2 GB, fii atent la RAM și treci la Qdrant sau la un plan mai mare doar când îți spun cifrele.