-- Exemplu de Hybrid Search folosind RRF (Reciprocal Rank Fusion)
WITH vector_search AS (
SELECT id, row_number() OVER (ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector) as rank
FROM documents
ORDER BY embedding <=> '[0.1, 0.2, ...]'::vector
LIMIT 50
),
text_search AS (
SELECT id, row_number() OVER (ORDER BY ts_rank_cd(content_tsvector, query) DESC) as rank
FROM documents, to_tsquery('romanian', 'eroare & conexiune') query
WHERE content_tsvector @@ query
LIMIT 50
)
SELECT
COALESCE(v.id, t.id) as doc_id,
(COALESCE(1.0 / (60 + v.rank), 0.0) +
COALESCE(1.0 / (60 + t.rank), 0.0)) as score
FROM vector_search v
FULL OUTER JOIN text_search t ON v.id = t.id
ORDER BY score DESC
LIMIT 10;Am observat o tendință obositoare în ultima vreme: cum apare un proiect de RAG (Retrieval-Augmented Generation), cum sare toată lumea să instaleze o bază de date de vectori dedicată. Pinecone, Milvus, Weaviate — sunt scule bune, nu zic nu, dar adaugă o complexitate operațională imensă. Ai încă un sistem de monitorizat, încă un loc unde datele pot deveni inconsistente și, cel mai important, încă o factură lunară care crește odată cu traficul.
La un proiect recent unde aveam de gestionat vreo 50.000 de documente tehnice pentru un client din zona de enterprise, am decis să mergem pe drumul mai bătătorit: Postgres cu extensia pgvector. Am vrut să văd dacă putem obține aceeași performanță fără să mutăm datele din baza noastră principală. Spoiler: am economisit cam 30% din timpul de dezvoltare doar pentru că n-a trebuit să scriem conducte complexe de sincronizare a datelor.
De ce pgvector și nu ceva dedicat?
Cel mai mare avantaj e tranzacționalitatea. Când un user își șterge un document, el dispare instant și din indexul de vectori. Nu trebuie să aștepți după un proces de background să facă sync între baza ta SQL și vector store. În plus, dacă ai deja datele în Postgres, e un simplu ALTER TABLE.
Totuși, m-am lovit de o problemă de care mulți uită: similarity search-ul pur (cosine similarity) este, de multe ori, prost. Dacă utilizatorul caută un termen foarte specific, cum ar fi un cod de eroare gen 0x8004210B, un model de embedding s-ar putea să-l considere „similar” cu alte erori de rețea, dar să nu-ți dea exact documentul care conține acel string. Aici intervine Hybrid Search.
Combinația câștigătoare: Vector + BM25
Ca să obținem rezultate cu adevărat relevante, am combinat pgvector cu Full Text Search-ul nativ din Postgres (care e o implementare solidă de BM25). Ideea e simplă: rulezi două căutări. Una semantică (cu vectori) și una lexicală (cu tsvector). Apoi combini rezultatele folosind Reciprocal Rank Fusion (RRF).
La indexare, am folosit HNSW (half-precision dacă vrei să economisești RAM). Am setat m = 16 și ef_construction = 64 pentru un echilibru bun între viteza de build și acuratețe. Pe un dataset de 50k row-uri, query-urile rulau sub 50ms pe un instance de RDS destul de modest.
Trade-offs sincere
Nu e totul roz. Dacă ajungi la zeci de milioane de vectori cu dimensiuni mari (gen 1536 de la OpenAI), Postgres începe să gâfâie la indexare. Memoria RAM devine rapid un bottleneck pentru că indexul HNSW trebuie să stea în memorie ca să fie rapid. Dacă ai nevoie de scaling la nivel de miliarde de vectori, atunci da, mută-te pe ceva dedicat. Dar pentru majoritatea aplicațiilor de business, Postgres e mai mult decât suficient.
Un alt aspect e tuning-ul pentru BM25. Trebuie să fii atent la stop words și stemmers pentru limba română dacă ai documente locale, altfel căutarea lexicală va fi mediocră.
În final, am ajuns la concluzia că simplitatea bate hype-ul. Am preferat să investesc timpul salvat din infrastructură în rafinarea chunk-ing-ului și a prompt-urilor de sistem. Voi ce folosiți pentru RAG în producție, mergeți pe varianta „all-in-one” sau preferați baze de date specializate?