-- Crearea indexului HNSW în pgvector pentru performanță optimă
CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- Căutare rapidă după similaritate (top 5 rezultate)
SELECT id, content FROM items
ORDER BY embedding <=> '[0.12, -0.56, 0.89, 0.22, ...]'
LIMIT 5;Am trecut prin faza aia în care voiam să folosesc cel mai „shiny” tool pentru fiecare mic proiect de AI. Mi-am dat seama repede că să plătești 70-100$ pe lună pentru un index de vectori, când tu ai abia 5 useri activi, e pură nebunie. De vreun an încoace, m-am jucat cu tot ce e open-source sau are un free tier generos și m-am oprit la trei soluții care chiar fac treabă fără să-ți golească portofelul.
Regele pragmatismului: pgvector
Dacă proiectul tău are deja un PostgreSQL în spate (și probabil are, că e standardul de facto în industrie), pgvector e cea mai simplă cale. Nu mai ai alt serviciu de monitorizat, alt backup de făcut și altă factură de plătit la final de lună. Am avut un caz la un proiect cu vreo 80.000 de vectori folosind modelul text-embedding-3-small de la OpenAI și pgvector s-a mișcat impecabil pe o instanță mică.
Trade-off-ul e sincer: dacă ai nevoie de filtrare extrem de complexă pe metadate în timp ce cauți vectori, Postgres e ok, dar indexarea HNSW (Hierarchical Navigable Small World) mănâncă mult RAM la construcție. La un moment dat, pe o mașină cu doar 1GB RAM, mi-a crăpat build-ul de index pentru că rămăsese fără memorie. Dacă ai peste 200k de vectori pe o mașină slabă, începi să simți latența. Dar pentru 90% din side-projects, e alegerea cea mai logică.
Performanță pură: Qdrant
Qdrant e ceea ce folosesc când știu că volumul de date o să crească sau când am nevoie de latențe sub 20ms constant. E scris în Rust, ceea ce se vede imediat în consumul de resurse și în stabilitate. Au un free tier destul de ok în cloud-ul lor (vreun 1GB de RAM și jumătate de vCPU), dar eu prefer să-l ridic într-un container Docker pe același VPS cu restul aplicației.
Ce îmi place la Qdrant e că API-ul e foarte curat și au un suport excelent pentru filtrare avansată. Poți să-i spui: „caută-mi vectorii ăștia, dar doar pentru userul X și în categoria Y”, iar motorul lor de filtrare e mult mai optimizat decât ce poți improviza în alte părți. Am reușit să economisesc cam 30% la timpul de răspuns într-un motor de recomandări trecând de la o implementare custom la Qdrant. Singurul minus e că mai adaugi o piesă în infrastructură care trebuie întreținută.
Chroma: Simplitate cu un asterisc
Chroma e cel mai popular în tutorialele de LangChain pentru că se instalează cu un simplu pip install chromadb. E grozav pentru prototipuri rapide pe care le rulezi local sau în notebook-uri. Totuși, am avut experiențe mixte cu el când am încercat să-l mut spre ceva mai serios.
Partea nasolă e că, fiind un proiect relativ nou, formatul de stocare pe disc s-a mai schimbat între versiuni majore. M-am trezit o dată că după un update minor nu mai puteam citi indexul vechi și a trebuit să re-generez toți vectorii. Dacă vrei ceva de tipul „set and forget”, aș merge mai degrabă pe primele două variante. Chroma e bun dacă vrei să pornești ceva în 5 minute fără să te atingi de Docker sau baze de date externe, dar curba de maturitate e încă acolo.
Ce alegi până la urmă?
Strategia mea e simplă acum. Dacă am Postgres, instalez extensia și văd dacă face față. E cea mai sigură cale și scapi de overhead-ul mental al gestionării unui serviciu nou. Dacă văd că indexarea devine lentă sau am nevoie de search pe vectori ca funcționalitate critică (de exemplu, un search engine pentru mii de documente), sar direct pe Qdrant.
Voi ce folosiți pentru RAG-uri mici? V-ați lovit de limitările de memorie la pgvector sau ați sărit direct pe soluții managed?