WITH semantic_search AS (
SELECT id, row_number() OVER (ORDER BY embedding <=> $1) as rank
FROM documents
ORDER BY embedding <=> $1
LIMIT 20
),
keyword_search AS (
SELECT id, row_number() OVER (ORDER BY ts_rank_cd(fts_tokens, query) DESC) as rank
FROM documents, to_tsquery('romanian', $2) query
WHERE fts_tokens @@ query
ORDER BY ts_rank_cd(fts_tokens, query) DESC
LIMIT 20
)
SELECT
COALESCE(s.id, k.id) AS document_id,
(COALESCE(1.0 / (60 + s.rank), 0.0) + COALESCE(1.0 / (60 + k.rank), 0.0)) AS rrf_score
FROM semantic_search s
FULL OUTER JOIN keyword_search k ON s.id = k.id
ORDER BY rrf_score DESC
LIMIT 10;Să fim serioși, s-a creat un hype masiv în jurul bazelor de date vectoriale dedicate. Am trecut și eu prin asta la un proiect cu vreo 120.000 de documente tehnice, unde am pornit cu Pinecone doar ca să ne dăm seama că ne complicăm viața inutil cu sincronizarea datelor. Am mutat totul în Postgres cu pgvector și am redus latența globală cu 25%, având toate datele relaționale și vectorii în același loc.
Dacă ai un volum de date de ordinul sutelor de mii sau chiar câtorva milioane de rânduri, Postgres este mai mult decât suficient pentru RAG. Dar nu e destul să arunci niște embeddings într-o coloană de tip vector și să dai un ORDER BY <=>. Trebuie să știi cum să scalezi și cum să combini căutarea semantică cu cea lexicală.
HNSW vs IVFFlat: Ce alegem în producție?
Când indexezi vectorii în pgvector, ai două opțiuni mari: IVFFlat și HNSW (Hierarchical Navigable Small World).
IVFFlat funcționează prin împărțirea spațiului vectorial în clustere. Este rapid de construit și are un consum redus de memorie, dar acuratețea (recall-ul) scade masiv dacă baza de date se modifică des fără să reconstruiești indexul.
La proiectul menționat, am mers direct pe HNSW. Creează un graf multidimensional și oferă un recall excelent (peste 98% din rezultatele exacte), chiar și atunci când adaugi date noi în mod constant.
Trade-off-ul sincer: HNSW mănâncă RAM pe pâine și durează mult să fie construit. Dacă indexul tău depășește memoria RAM alocată pentru shared_buffers, query-urile vor începe să citească de pe disc și performanța se va prăbuși. Sfatul meu: folosește embeddings cu dimensiuni mai mici (de exemplu, text-embedding-3-small de la OpenAI redus la 512 dimensiuni în loc de 1536) dacă vrei să economisești memorie fără să pierzi vizibil din calitate.
De ce căutarea pur semantică e o capcană și cum o rezolvă BM25
Embeddings-urile sunt geniale pentru a înțelege contextul și sinonimele, dar sunt incredibil de proaste la potriviri exacte. Dacă utilizatorul caută un cod de produs specific (ex: "X-992-B"), căutarea semantică s-ar putea să-i returneze produse similare ca funcționalitate, dar nu exact modelul căutat.
Aici intervine căutarea hibridă. Combinăm puterea semantică a vectorilor cu căutarea clasică de tip text (BM25, implementată în Postgres via to_tsvector). Ca să fuzionăm cele două seturi de rezultate într-un mod matematic corect, folosim un algoritm simplu numit Reciprocal Rank Fusion (RRF). Acesta oferă un scor fiecărui document în funcție de poziția sa în ambele liste de rezultate.
Cum arată query-ul de producție
Mai jos ai o interogare SQL reală care face exact asta: rulează în paralel căutarea semantică și cea full-text, apoi aplică RRF pentru a returna cele mai relevante rezultate. Am folosit o constantă de penalizare (K = 60), care este standardul în industrie pentru a echilibra cele două clasamente.
Faptul că poți face asta într-o singură bază de date, într-o singură tranzacție, fără să muți date prin rețea către un vector DB extern, este un avantaj uriaș. Postgres câștigă când simplitatea arhitecturală e o prioritate, adică în 95% din cazuri.
Voi ce folosiți pentru RAG în producție? V-ați lovit de limitările pgvector la volume mari sau ați rămas la soluții dedicate?