RAG vs căutare BM25 keyword: când investiția în semantică se justifică și când nu

Una dintre cele mai costisitoare greșeli pe care le vedem la clienți este ipoteza implicită că „RAG este superior căutării clasice”. În anumite scenarii, da. În altele, un BM25 ELI5 rulat pe Elasticsearch cu un tokenizator decent oferă rezultate mai bune, mai rapide, mai ieftine și mai auditabile decât un pipeline RAG cu embeddings, vector DB și reranker.

Acest articol oferă decizionarilor o matrice clară: pentru ce caz de utilizare alegeți keyword search clasic, când treceți la hybrid, și când justifică investiția în RAG semantic complet.

TL;DR

• BM25 keyword search este rapid (1–10 ms), ieftin, deterministic, auditabil. Funcționează excelent pe queries cu termeni tehnici exacți și pe domenii cu vocabular standardizat.
• RAG semantic (dense + reranker) este mai bun pe queries conversaționale, parafraze, sinonime, dar costă 5–20× mai mult în compute și latency.
• Hybrid search (BM25 + dense fuzionat cu RRF) combină avantajele și este standardul industrial pentru corpusuri >100K documente cu queries variate.
• Pentru chatbots juridice, RAG hybrid este obligatoriu. Pentru search bar pe site corporate, BM25 cu sinonime configurate manual este adesea suficient.
• Decizia este financiară: cost-benefit clar dacă măsurați volume reale și calitate cerută de business, nu prin „state-of-the-art”.

Trei tipuri de search, trei profile diferite

BM25 (keyword search clasic)

BM25 este algoritmul standard din motoarele de căutare lexicale (Elasticsearch, OpenSearch, Solr). Funcționează pe principii statistice: TF (term frequency), IDF (inverse document frequency), normalizare pe lungimea documentului. Fără embeddings, fără rețele neuronale.

Funcționează excelent când:

• Queries-urile conțin termeni exacți care apar și în documente (numere de articol, ID-uri, denumiri specifice).
• Vocabularul domeniului este standardizat și redus.
• Aveți buget zero pentru GPU și latency strâns.
• Auditabilitatea este cerință legală — BM25 este complet explicabil.

Limitări:

• Eșuează pe sinonime („concediere” vs „desfacerea contractului”) fără configurare manuală a unui dicționar.
• Eșuează pe parafraze conversaționale.
• Eșuează pe queries cu typos sau diacritice lipsă.

RAG semantic (dense embeddings + LLM)

RAG semantic folosește embeddings dense pentru a capta semnificația, nu literele. Un encoder transformă query-ul și documentele în vectori; similaritatea cosinus măsoară apropierea semantică.

Funcționează excelent când:

• Queries-urile sunt conversaționale, exprimate diferit de cum apar în documente.
• Domeniul are sinonime și parafraze numeroase, imposibil de enumerat manual.
• Aveți buget pentru GPU și acceptați latency 50–500 ms.
• Doriți să răspundeți la întrebări „ce înseamnă X pentru afacerea mea” pe documente care folosesc terminologie diferită.

Limitări:

• Eșuează pe queries cu termeni tehnici exacți (numerele de articol pot fi „translatate” semantic la articole similare).
• Cost computațional semnificativ — încărcarea și menținerea unui index vectorial este nontrivială.
• Mai puțin auditabil — explicarea exactă a ranking-ului unui document cere instrumente specializate.

Hybrid (BM25 + dense, fuzionat)

Hybrid search rulează ambele algoritmi în paralel și fuzionează rezultatele cu Reciprocal Rank Fusion (RRF) sau learned weights. În producție, asta este standardul industrial pentru corpusuri mari și queries variate.

Funcționează excelent când:

• Aveți volum suficient pentru a justifica complexitatea.
• Queries-urile sunt amestecate (unele tehnice, unele conversaționale).
• Calitatea contează mai mult decât simplificarea operațională.

Decision matrix concret

Pe baza experienței cu peste 30 de proiecte de search la clienți, oferim următorul ghid:

Caz de utilizare	Volum corpus	Recomandare
Search bar pe site corporate	1K–10K pagini	BM25 cu sinonime manuale
Help center cu FAQ	100–1000 articole	BM25 + sinonime + redirect manual
Knowledge base intern (Confluence/SharePoint)	10K–100K pagini	Hybrid (BM25 + dense, fără reranker)
Chatbot juridic / fiscal	100K–10M documente	RAG semantic complet (hybrid + reranker + grounding)
Search pe e-commerce produse	10K–1M produse	Hybrid + filters + rerank pe popularity
Search pe procurement / SEAP	100K–1M anunțuri	Hybrid + filters + reranker
Asistent de cod intern	10K–100K fișiere	RAG semantic + AST chunking

Cum se calculează ROI-ul

ROI-ul pentru RAG vs BM25 nu este abstract. Se calculează pe trei axe:

1. Calitate

• Pe ce procent din queries returnează BM25 răspunsul corect?
• Câștigul incremental al RAG (în puncte de relevance) se traduce în câte tranzacții/clicks/case-uri în plus?

2. Cost

• BM25: costuri marginale aproape zero per query (sub 0,001 EUR la volume mari).
• Hybrid: GPU pentru encoder + index vectorial. Tipic 20–200 EUR/lună la volume mici-medii.
• RAG complet cu LLM: 1–10 EUR per 1000 queries (depinde de prompt length și model).

3. Latency

• BM25: 1–10 ms per query.
• Hybrid: 50–150 ms.
• RAG cu LLM: 1.5–8 secunde (LLM generation domină).

Pentru un sistem cu 100.000 queries/lună:

• BM25: ~5–20 EUR/lună infrastructură, 99% queries servite
• Hybrid: ~150–400 EUR/lună
• RAG cu LLM: ~500–3000 EUR/lună

Diferența între hybrid și RAG cu LLM nu este în search-ul în sine — este în costul generării răspunsului. Dacă utilizatorii vor doar lista de documente relevante (search clasic), hybrid este suficient și ieftin. Dacă utilizatorii vor răspuns sintetizat (chatbot), apare costul LLM.

Semnale din usage real

Cum știți că trebuie să treceți de la BM25 la hybrid sau RAG? Iată semnalele pe care le urmărim cu clienții:

• Rate de „no results” peste 5%: înseamnă că BM25 nu prinde formulări comune. Hybrid ajută.
• Click-through rate scăzut pe top-3 rezultate: înseamnă că ranking-ul e prost. Reranker semantic ajută.
• Suport tichete repetitive cu „nu găsesc X în search”: utilizatori sunt frustrați. Hybrid cu sinonime auto.
• Queries lungi conversaționale (peste 8 cuvinte): BM25 eșuează predictiv. Embeddings dense ajută direct.
• Diversitate vocabulară mare în corpus: același concept exprimat în 10 feluri diferite. Embeddings prind asta.

Invers, semnale că NU aveți nevoie de RAG:

• Utilizatori experți care folosesc terminologie standard.
• Volume sub 100 queries/zi — overhead-ul nu se justifică.
• Cerință de auditabilitate strictă (sectorul public, financiar reglementat).

Capcana „state-of-the-art”

O greșeală comună: echipele tehnice vor să implementeze RAG complet pentru că este „modern” și pentru că vor să folosească embeddings. Rezultatul: cost crescut, complexitate operațională, fără îmbunătățire de business.

Recomandarea noastră standard: începeți cu BM25 cu sinonime manuale. Măsurați rate de no-results, CTR pe top-3, satisfacție utilizator. Treceți la hybrid când datele vă spun că BM25 ratează. Treceți la RAG complet doar când utilizatorii cer răspunsuri sintetizate, nu liste de linkuri.

Diagramă decizie

Aveți search engine?
  ├── Nu → BM25 cu Elasticsearch/OpenSearch (start aici)
  ├── BM25 + queries conversaționale frecvente
  │     → Adaugă encoder dense + RRF (hybrid)
  ├── Hybrid + utilizatorii vor răspuns sintetizat
  │     → Adaugă LLM cu citation grounding (RAG complet)
  └── RAG complet + acuratețe juridică critică
        → Adaugă reranker + validation gate

Concluzie operațională

RAG nu este superior căutării clasice. Este o opțiune cu profil diferit. Decizia se ia pe baza volumului, tipului de query, cerințelor de calitate și bugetului. Echipele care decid „pe modă” cheltuiesc 5–20× mai mult fără justificare. Echipele care decid pe baza datelor de usage real obțin cost-benefit favorabil.

Pentru consultanța clienților CAI Technology, recomandarea standard este: prototype rapid cu BM25, măsurați 4 săptămâni, decideți upgrade pe baza semnalelor. Această disciplină elimină majoritatea proiectelor RAG care eșuează la cost-benefit.

Articole conexe

• Pillar RAG — arhitecturi enterprise
• BGE-M3 vs OpenAI embeddings pentru queries românești
• Hybrid search RRF vs Cohere vs cross-encoder

Surse externe

• Robertson & Zaragoza, „The Probabilistic Relevance Framework: BM25 and Beyond”
• Lewis et al., „Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”
• Cormack et al., „Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods”
• Elastic, „The BM25 algorithm and its variables”

Următorul pas

Pentru o evaluare gratuită a stack-ului vostru de search (audit pe 4 săptămâni cu metrice cantitative), echipa CAI Technology oferă o consultație de 30 de minute fără cost.