-- Crearea tabelului și căutarea rapidă prin pgvector cu distanță cosinus
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE document_chunks (
id bigserial PRIMARY KEY,
content text,
embedding vector(1536) -- dimensiune standard OpenAI
);
-- Căutare semantică simplă folosind operatorul <=>
SELECT content, 1 - (embedding <=> $1) AS similarity
FROM document_chunks
ORDER BY embedding <=> $1
LIMIT 5;Salutare! Dacă te-ai apucat de un side-project cu LLM-uri în ultima vreme, probabil te-ai lovit de aceeași problemă ca mine: ce bază de date vectorială folosești fără să îți explodeze factura? Pinecone e mișto în reclame, dar când vrei să ții costurile la zero, trebuie să cauți alternative reale.
În ultimul an am construit trei chestii mici (inclusiv un tool de search pentru documentația internă a unui client, cam 50k de chunk-uri text) și am trecut prin pgvector, Chroma și Qdrant. Am pierdut destule nopți cu ele și am zis să las aici concluziile, direct la subiect, fără povești de marketing.
pgvector: Calea leneșului deștept
Dacă proiectul tău folosește deja PostgreSQL, adăugarea extensiei pgvector e de departe cea mai simplă mișcare. Am avut cazul unui catalog de produse (vreo 15k de items) unde aveam nevoie de recomandări similare bazate pe embeddings.
Ai tranzacții ACID, backup-uri pe care le ai deja configurate și SQL clasic. Nu adaugi altă tehnologie în stack, nu-ți prinzi urechile cu porturi noi în Docker Compose.
Dar există un trade-off destul de dureros. pgvector devine extrem de gurmand cu memoria când folosești indecși HNSW (recomandați pentru viteză la căutări mari). Pe o instanță free de Supabase sau Neon, dacă sari de 50.000 de vectori cu 1536 de dimensiuni (standardul de la OpenAI), o să vezi cum memoria RAM se duce la cer. Fără index, căutarea devine secvențială și extrem de lentă. Pe acel proiect, o căutare brută fără index trecea lejer de 400ms, ceea ce e groaznic pentru UX.
Chroma: Jucăria perfectă pentru prototipuri în Python
Chroma e iubit de comunitate pentru că rulează complet in-memory cu o singură linie de cod. Dai un pip install chromadb și ești gata.
L-am folosit pentru un MVP rapid în weekend. E genial pentru că nu trebuie să configurezi nimic, nicio bază de date externă. Totuși, când am vrut să mut proiectul pe un VPS ieftin de 5$ în producție, au început problemele. Docker-ul lor oficial mănâncă destul de multe resurse din start. În plus, dacă proiectul tău e scris în Node.js sau Go, client-ul lor non-Python e destul de neîngrijit și are bug-uri ciudate la serializare.
Qdrant: Performanță pe bune (scris în Rust)
Dacă ai nevoie de performanță și vrei să scapi de bătăile de cap cu hostingul self-hosted, Qdrant e câștigătorul detașat în momentul de față. Au un free tier în cloud extrem de generos (1GB RAM, 20GB disk), care e mai mult decât suficient pentru side-projects.
Am mutat proiectul de documentație (50k vectori) de pe pgvector pe Qdrant Cloud. Timpul de căutare semantică a scăzut de la ~120ms (pe Postgres neoptimizat) la sub 35ms stabil, incluzând latența de rețea.
Cel mai mare plus la Qdrant e sistemul de filtrare. Poți face pre-filtering pe metadate (de exemplu, caută doar în documentele din categoria 'marketing' create după 2023) extrem de rapid, lucru care la alte baze vectoriale e destul de greoi de implementat eficient.
Ca trade-off, API-ul lor e un pic mai stufos și îți ia ceva timp să te prinzi cum funcționează payload-urile dacă ești obișnuit cu SQL-ul clasic.
Concluzia mea
Regula mea de aur acum este simplă:
- Ai deja Postgres și sub 30k vectori? Folosește
pgvector. - Faci un script rapid în Python pe mașina locală? Pune
Chroma. - Construiești un SaaS adevărat, fie el și side-project, și vrei latență mică pe free tier? Mergi direct pe
Qdrant.
Voi ce folosiți pentru RAG-uri în producție? A încercat cineva pgvector cu noii indecși HNSW pe volume mari?