-- Crearea indexului HNSW pentru performanță maximă
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- Exemplu de Hybrid Search (simplificat)
WITH vector_search AS (
SELECT id, rank() OVER (ORDER BY embedding <=> '[0.12, 0.05, ...]') as rank
FROM documents
ORDER BY embedding <=> '[0.12, 0.05, ...]' LIMIT 20
),
text_search AS (
SELECT id, rank() OVER (ORDER BY ts_rank_cd(fts_tokens, query) DESC) as rank
FROM documents, to_tsquery('english', 'error_code') query
WHERE fts_tokens @@ query LIMIT 20
)
SELECT
COALESCE(v.id, t.id) as doc_id,
(1.0 / (60 + v.rank) + 1.0 / (60 + t.rank)) as rrf_score
FROM vector_search v
FULL OUTER JOIN text_search t ON v.id = t.id
ORDER BY rrf_score DESC LIMIT 10;M-am săturat să văd setup-uri cu trei baze de date diferite pentru un amărât de MVP cu AI. Dacă ai deja Postgres în stack, să adaugi o bază de date vectorială separată (ca Pinecone sau Milvus) e, de cele mai multe ori, o complicație inutilă de infrastructură. Am avut recent un proiect unde trebuia să indexăm cam 500.000 de fragmente de documente tehnice. Am început cu un vector store extern, dar sincronizarea datelor între DB-ul principal și cel de vectori a devenit rapid un coșmar de consistență.
Soluția a fost pgvector. E o extensie care transformă Postgres-ul într-un cetățean de prim rang în lumea AI-ului. Nu e doar despre a stoca niște array-uri de float-uri, ci despre cum le interoghezi eficient fără să îți crape serverul când ajungi la volum mare.
HNSW vs IVFFlat: Unde se rupe filmul
Când începi cu pgvector, ai două opțiuni mari pentru indexare. IVFFlat era standardul acum un an, dar sincer, e cam depășit pentru majoritatea cazurilor de producție. Am pățit să avem recall prost pentru că nu am antrenat indexul cu destule date reprezentative.
Acum mergem direct pe HNSW (Hierarchical Navigable Small World). E mult mai rapid la query-uri, dar are un trade-off sincer: mănâncă RAM la micul dejun și durează o veșnicie să construiești indexul. La proiectul menționat, am economisit cam 30% la build time-ul indexului folosind un m mai mic, dar am pierdut puțin la precizie. Dacă ai un dataset care se schimbă constant, HNSW e sfânt pentru că poți adăuga date noi fără să reconstruiești tot indexul de la zero.
Căutarea hibridă: Salvatorul RAG-ului
Embeddings-urile sunt geniale pentru context semantic, dar sunt praf la cuvinte cheie specifice. Dacă userul caută un cod de eroare gen „ERR_502_TIMEOUT”, un model de embedding s-ar putea să îl trimită spre „probleme de rețea”, dar să rateze exact documentul care conține string-ul ăla fix.
Aici strălucește Postgres. Poți să faci Hybrid Search combinând cosine similarity (din pgvector) cu Full Text Search-ul clasic (BM25/tsvector). Eu folosesc Reciprocal Rank Fusion (RRF) pentru a combina rezultatele. Practic, dai o pondere ambelor metode și obții ce e mai bun din ambele lumi.
Problemele de care nu scrie în documentație
Nu totul e roz. Nasol e că Postgres nu e optimizat nativ pentru vectori de dimensiuni mari (gen 3072 de la noile modele OpenAI) fără un tuning serios de memorie. Dacă nu ești atent la work_mem și maintenance_work_mem, o să vezi cum query-urile tale de 50ms sar brusc la 2 secunde pentru că baza de date începe să facă swap pe disk.
Un alt aspect: backup-urile. Un index HNSW mare poate să adauge zeci de GB la dump-ul bazei de date. Am avut situații unde timpul de restore s-a dublat doar din cauza indexului vectorial.
Concluzia mea e simplă: folosește pgvector până când chiar simți că te lovești de o limită fizică a Postgres-ului (vorbim de zeci de milioane de vectori). Până atunci, simplitatea de a avea totul într-un singur loc bate orice micro-optimizare de latență oferită de o bază de date specializată.
Voi ce folosiți pentru RAG în producție? V-ați lovit de limitări de memorie cu HNSW pe Postgres?