-- Creăm tabela cu o coloană de tip vector (1536 dimensiuni pentru OpenAI)
CREATE TABLE document_chunks (
id SERIAL PRIMARY KEY,
content TEXT,
user_id INT,
embedding VECTOR(1536)
);
-- Căutare semantică combinată cu filtrare clasică
SELECT id, content, 1 - (embedding <=> '[0.002, -0.015, ...]') AS similarity
FROM document_chunks
WHERE user_id = 42
ORDER BY embedding <=> '[0.002, -0.015, ...]'
LIMIT 5;Salutare. Am tot bătut câmpii în ultima vreme cu LLM-uri și căutare semantică pentru un proiect personal—un motor de căutare prin legi și ordonanțe din România, cam 45.000 de documente chunk-uite. Pentru că n-aveam chef să arunc cu banii pe Pinecone (care te taxează de te usucă dacă vrei indexare persistentă), am testat trei variante moca: pgvector, Qdrant și Chroma.
Fiecare are bubele ei pe care nu le scrie în documentația oficială. Am trecut prin procesul de deployment și optimizare, iar concluziile de mai jos s-ar putea să-ți scutească câteva nopți pierdute.
pgvector: Extensia care îți salvează mințile (și bugetul)
Dacă ai deja un Postgres în stack, pgvector e probabil cea mai simplă alegere. L-am testat pe free tier-ul de la Supabase. Dai un CREATE EXTENSION vector; și ești gata de joacă.
Cel mai mare avantaj? Faci join direct între vectori și tabelele tale de utilizatori sau postări. Nu ai nevoie de un serviciu separat, nu ai probleme de sincronizare a datelor.
Trade-off-ul sincer: Memoria RAM. Indexul HNSW (Hierarchical Navigable Small World), care e cel mai rapid pentru căutări, se construiește complet în RAM. Pe instanța gratuită de la Supabase (care are în jur de 512MB RAM disponibili), când am încercat să indexez peste 25.000 de vectori de 1536 de dimensiuni (generați cu OpenAI text-embedding-ada-002), baza de date a crăpat cu Out Of Memory (OOM).
Soluția a fost să folosesc indexul IVFFlat, care e mai lent și mai puțin precis, dar consumă mult mai puțină memorie la build.
Qdrant: Performanță pură scrisă în Rust
Dacă vrei ceva dedicat, Qdrant e de departe preferatul meu în acest moment. L-am rulat în două moduri: pe free tier-ul lor din cloud (îți oferă 1GB de RAM și 10GB spațiu, destul pentru vreo 70.000 de vectori) și self-hosted pe un VPS de 4 euro la Hetzner.
Qdrant e incredibil de eficient. În idle, containerul de Docker consumă sub 50MB RAM. Căutările semantice cu filtre atașate (de exemplu: "caută textul X, dar doar în documentele din anul 2023") sunt extrem de rapide datorită modului în care combină indexarea vectorială cu cea de payload.
Trade-off-ul sincer: E încă o piesă în infrastructură pe care trebuie să o monitorizezi și să o securizezi. Dacă pici în capcana de a nu seta limite de resurse pe containerul de Docker, Qdrant va mânca tot ce prinde în timpul indexării masive.
Chroma: Regele prototipurilor rapide
Chroma e iubit de comunitatea Python pentru că dai pip install chromadb și în 5 secunde ai o bază de date vectorială locală, în memorie, gata de treabă. E perfect pentru Jupyter Notebooks sau scripturi rapide.
Trade-off-ul sincer: Producția e un chin. Chroma e practic un wrapper peste SQLite și ClickHouse. Când încerci să-l rulezi în mod server (chroma run) într-un container Docker pentru a-l folosi dintr-un backend de Node.js sau Go, performanța scade dramatic la scrieri concurente, iar debugging-ul erorilor interne devine frustrant.
Cum arată o interogare reală în pgvector
Pentru cei care vor să meargă pe varianta Postgres, iată cum arată o căutare semantică clasică folosind distanța de cosinus, combinată cu un filtru clasic pe id-ul utilizatorului.