Când NU folosești RAG: alternativele și pragurile reale

Ai un corpus de documente, o echipă care pierde timp căutând prin el și o propunere pe masă: construim un sistem RAG. Înainte de a semna bugetul, merită o oră pe întrebarea inversă — ce se întâmplă dacă nu-l construiești?

Pentru o felie surprinzător de mare din cazuri, răspunsul e: nimic rău. Întrebările primesc răspunsuri la fel de bune dintr-o interogare SQL, dintr-un index full-text de acum cincisprezece ani sau dintr-un prompt în care încape tot ce ai. Iar diferența nu e stilistică: alternativele alea garantează lucruri pe care un sistem RAG nu le garantează.

Articolul ăsta nu reia comparația cu fine-tuning — aia e o altă decizie, între două moduri de a aduce cunoștințe într-un model, și e tratată separat în RAG vs fine-tuning. Aici compari RAG cu a nu construi RAG. Cu SQL. Cu BM25. Cu un prompt lung. Cu un om și un motor de căutare.

Ce cumperi de fapt când cumperi RAG

Un sistem de retrieval nu e un feature, e un subsistem. Arhitectura completă are minimum șase piese care trebuie să existe și să fie întreținute: un pipeline de ingestie, o strategie de chunking, un model de embeddings, un index vectorial, un strat de retrieval cu ranking și un strat de generare cu prompt propriu.

Fiecare piesă are un mod propriu de a se strica. Chunking-ul taie o clauză în două. Embedding-ul confundă două documente similare ca formă și opuse ca sens. Indexul rămâne în urmă după o ștergere. Modelul primește trei fragmente relevante și două zgomotoase și îl citează pe cel greșit.

Costul de intrare vs costul de existență

Costul de build e vizibil și se negociază. Costul de existență e cel care surprinde: reindexări la fiecare modificare de document, permisiuni care trebuie să se propage din sursa de adevăr în index, un set de evaluare care trebuie rulat de fiecare dată când schimbi modelul sau chunking-ul.

Un sistem RAG nu e o investiție unică, e o cheltuială recurentă cu o pantă. Asta îl face să merite pe volum și să nu merite deloc sub el.

Semnalul că răspunsul e „nu”

Dacă poți scrie manual, în cinci minute, interogarea care întoarce răspunsul corect la 80% dintre întrebările pe care le primești — nu ai o problemă de retrieval. Ai o problemă de interfață. Aia se rezolvă cu un formular, nu cu un index vectorial.

Arborele de decizie: cinci întrebări înainte de primul embedding

Ordinea contează. Fiecare întrebare de mai jos elimină o categorie întreagă de cazuri, iar RAG rămâne răspunsul corect abia după ce toate cinci trec de partea lui.

1. Răspunsul e un fapt sau o sinteză?

„Câte facturi neîncasate are clientul X?” e un fapt. Are exact un răspuns corect, el există într-o coloană dintr-o bază de date, iar orice sistem care îl aproximează e mai prost decât unul care îl calculează.

„Cum tratăm de obicei o reclamație pe garanție la produsele importate?” e o sinteză. Răspunsul e împrăștiat în cinci documente, niciunul nu îl conține întreg și cineva trebuie să le pună cap la cap.

RAG e bun la a doua categorie. Pe prima e o regresie: schimbi un răspuns exact cu unul probabilistic și plătești în plus pentru privilegiu.

2. Știi termenul exact sau doar sensul?

Dacă utilizatorii caută după coduri de eroare, SKU-uri, numere de contract, denumiri de parametri sau articole de lege, ai nevoie de potrivire literală. Căutarea semantică e construită exact pe premisa opusă — că sensul contează mai mult decât forma — și tocmai de asta netezește identificatorii.

3. Încape tot corpusul în prompt?

Dacă da, selecția devine opțională: îi dai modelului tot și scapi de întreaga clasă de erori numite „retrieval a adus fragmentul greșit”. Detaliile aritmetice și capcanele lor sunt mai jos, la secțiunea despre fereastra de context.

4. Câte întrebări primești pe zi?

Un sistem de retrieval are un cost fix care nu depinde de trafic: indexul stă în memorie, reindexarea rulează, evaluarea trebuie întreținută. Împarte costul lunar la numărul de întrebări. Dacă rezultatul depășește ce ar costa un om să răspundă la aceeași întrebare, ai construit un instrument mai scump decât problema.

5. Cine plătește o greșeală?

Într-un asistent intern de documentație, un răspuns greșit costă două minute de verificare. Într-un flux care generează oferte de preț sau răspunsuri către clienți, costă bani și credibilitate. Cu cât e mai mare costul unei erori, cu atât mai puțin tolerabilă e o arhitectură care poate greși fără să te anunțe — și cu atât mai atractivă o alternativă care întoarce fie răspunsul corect, fie nimic.

Pragurile cantitative: de la ce cifre începe retrieval-ul să merite

Cifrele de mai jos sunt ordine de mărime pentru calibrare, nu praguri universale. Le folosești ca să vezi în ce cadran te afli, apoi le ajustezi pe datele tale.

Volumul corpusului

Aritmetica e simplă și o poți face în două minute. O pagină de text tehnic în română înseamnă undeva la 700–1.000 de tokeni, fiindcă tokenizarea limbii române e mai puțin eficientă decât cea a englezei — diacriticele și morfologia bogată sparg cuvintele în mai multe bucăți. La 200.000 de tokeni, o fereastră care e mediană printre modelele urmărite de BenchLM în iulie 2026, intră ordinul a două-trei sute de pagini.

Sub acest prag, un index vectorial rezolvă o problemă pe care nu o ai. Între câteva sute și câteva mii de pagini ești în zona gri, unde decid celelalte criterii. Peste zeci de mii de pagini, selecția devine obligatorie indiferent de fereastră.

Rata de interogare

Sub zece întrebări pe zi, aproape orice sistem automat pierde comparația cu un om care caută. Nu pentru că omul e mai rapid, ci pentru că sistemul are un cost care curge și când nu îl folosește nimeni.

Pragul se mută dacă răspunsul are valoare mare per instanță — un răspuns care scurtează cu două ore un audit justifică mai multă infrastructură decât unul care scutește două minute de căutare.

Volatilitatea conținutului

Un corpus care se schimbă zilnic transformă prospețimea și reindexarea în cost operațional permanent. Un corpus înghețat — un manual de produs, un set de proceduri revizuite anual — nu are problema asta, dar nici nu are nevoie de un index care se actualizează.

Paradoxul e util: corpusurile stabile pot fi băgate întregi în prompt și cache-uite, iar corpusurile volatile plătesc cel mai mult pentru un index.

Un singur criteriu în zona „nu construi” nu închide discuția. Trei din cinci, da.

Alternativele și ce garantează fiecare

Diferența dintre aceste patru opțiuni și RAG nu e „mai bun / mai slab”. E ce promit. Fiecare garantează ceva ce retrieval-ul semantic nu poate garanta, și renunță la ceva ce doar el oferă.

Interogarea structurată: garantează exactitate

Dacă întrebarea are un răspuns care există într-o coloană, SQL îl întoarce exact, reproductibil și auditabil. Nu aproximează, nu inventează, iar când nu găsește nimic spune că nu găsește nimic.

Tentația de a înlocui asta cu un model care citește baza de date ca text e reală, și există și dovezi pe ea. Benchmark-ul LOFT, publicat de o echipă Google pe arXiv, a arătat că modelele cu context lung rivalizează cu sisteme de retrieval specializate — dar rămân în urmă tocmai pe sarcinile de tip SQL, cele care cer raționament compozițional peste date structurate. Traducerea practică: pe agregări, filtre combinate și numărători, motorul de bază de date rămâne mai bun decât orice cititor de text.

Full-text search: garantează potrivirea literală

BM25 nu e o soluție de compromis, e o soluție potrivită. Pe benchmark-ul BEIR, retrieval-ul lexical depășește retrieval-ul dens pe jumătate dintre seturile de date evaluate zero-shot, potrivit sintezei publicate de Atlan în 2026 — iar cazurile unde câștigă sunt exact cele cu identificatori, jargon rar și terminologie precisă.

În plus, are proprietăți pe care un index vectorial nu le are: latență de ordinul milisecundelor, ranking pe care îl poți citi și explica, zero cost de GPU și nicio nevoie de reembedding când documentul se schimbă. Dacă ai deja Postgres sau Elasticsearch în stack, funcția există și nu costă un proiect.

Combinația celor două — hybrid search cu reranking — e răspunsul corect când chiar ai nevoie de amândouă. Dar dacă 90% dintre interogări conțin un identificator exact, jumătatea semantică e infrastructură pe care o plătești fără să o folosești.

Corpusul întreg în prompt: garantează că nimic nu se pierde la selecție

Când tot corpusul încape în fereastră, elimini stratul care greșește cel mai des. Nu mai există „chunk-ul relevant n-a intrat în top-5”, fiindcă nu mai există top-5.

Prețul e că plătești tot corpusul la fiecare întrebare, iar aici intervine caching-ul de prompt: toți furnizorii mari facturează prefixul deja procesat la o fracțiune din tariful de input — în jur de 10% la Anthropic, 50% automat la OpenAI, potrivit comparațiilor publice de la mijlocul lui 2026. Pentru un corpus stabil, interogat des, asta schimbă complet aritmetica.

Un om cu un motor de căutare: garantează judecată

Cea mai des ignorată alternativă. Un om cu acces la o căutare bună face ceva ce niciun retrieval nu face: recunoaște când întrebarea e prost pusă, cere clarificare și știe ce lipsește din documente.

La volume mici e și cea mai ieftină. Devine insuportabilă abia când aceeași întrebare vine de o sută de ori pe zi — moment în care ai și datele necesare ca să construiești ceva serios, fiindcă știi exact ce se întreabă.

Fereastra mare de context: când chiar înlocuiește RAG-ul și când doar pare

Aici e argumentul care a schimbat cel mai mult în ultimii doi ani, și cel în care e cel mai ușor să te înșeli. Cum decizi ce intră în prompt e o problemă de selecție în interiorul unui sistem RAG. Întrebarea de aici e alta: când face fereastra sistemul inutil?

Ce spune piața în 2026

Fereastra de un milion de tokeni a încetat să fie un diferențiator între modelele de frontieră. BenchLM raporta în iulie 2026 că aproximativ 22% dintre cele 278 de modele cu limite publicate ajung la un milion de tokeni sau peste, cu o mediană de 200.000 de tokeni pe întregul set. Ce înseamnă asta pentru selecția de conținut e discutat pe larg în articolele despre fereastra de context.

Sursele publice se contrazic însă pe detalii — care model conduce clasamentul și cât costă efectiv umplerea unei ferestre de un milion diferă de la un comparativ la altul cu un ordin de mărime. Ce nu se contrazice: diferența de preț între cel mai ieftin și cel mai scump model pentru aceeași fereastră plină e uriașă, deci alegerea modelului contează mai mult decât dimensiunea ferestrei.

Ce spun benchmark-urile

Fereastra advertisată e o capacitate, nu o garanție. Benchmark-ul RULER, construit de NVIDIA tocmai ca să măsoare diferența, a găsit că din modelele care revendicau 32.000 de tokeni sau mai mult, doar aproximativ jumătate mențineau calitatea la 32.000, iar aproape toate cădeau sub prag înainte de lungimea revendicată.

NoLiMa, benchmark-ul Adobe Research, definește lungimea efectivă drept cel mai lung context la care modelul păstrează minimum 85% din scorul obținut pe input scurt — și arată căderi mari când întrebarea și textul-țintă nu împart cuvinte.

Rezultatul cel mai incomod vine dintr-o lucrare prezentată la EMNLP 2025: chiar și cu retrieval perfect, adică atunci când modelul primește garantat toate informațiile relevante, performanța scade substanțial pe măsură ce inputul crește — între 13,9% și 85%, în interiorul lungimilor revendicate de modele. Degradarea persistă și când tokenii irelevanți sunt înlocuiți cu spații albe. Simpla lungime a inputului face rău.

Sinteza Chroma pe același subiect, cunoscută ca „context rot”, ajunge în aceeași direcție: degradarea nu e liniară și nu se vede în testul clasic de tip needle-in-a-haystack.

Aritmetica de cost care decide

Trei numere decid: mărimea corpusului în tokeni, numărul de întrebări pe lună și tariful de input al modelului. Le înmulțești și compari cu costul lunar al unui index — pentru cifrele de build și de operare, devizul detaliat e în articolul dedicat.

Regula care iese aproape mereu: corpus mic × trafic mic → prompt complet; corpus mic × trafic mare → prompt complet cu caching; corpus mare × trafic mic → full-text sau om; corpus mare × trafic mare → RAG. Retrieval-ul câștigă într-un singur cadran din patru.

Costul ascuns al unui RAG subdimensionat

Un sistem construit sub pragul lui nu eșuează spectaculos. Eșuează încet, și asta îl face mai scump decât un eșec pe față.

Ce plătești și când nu întreabă nimeni nimic

Indexul consumă memorie. Reembedding-ul rulează la fiecare modificare de document. Cineva trebuie să fie de gardă când pipeline-ul de ingestie pică. Un asistent cu treizeci de utilizatori plătește aceeași infrastructură ca unul cu trei mii, doar că o împarte la de o sută de ori mai puține răspunsuri.

Datoria de evaluare

Fără un set de evaluare, nu ai cum să știi dacă sistemul s-a stricat. Cu unul, ai o sarcină recurentă: îl rulezi la fiecare schimbare de model, de chunking sau de sursă de date. Metricile de retrieval și de generare sunt o disciplină, nu un fișier.

Echipele care sar peste ea ajung în tiparele descrise la de ce eșuează RAG în producție: sistemul răspunde, nimeni nu verifică, încrederea scade lent și apoi brusc.

Costul de credibilitate

Cel mai scump. Un asistent intern care greșește vizibil de trei ori nu mai e folosit, indiferent cât de bine merge a patra oară. Recuperarea încrederii costă mai mult decât construirea inițială — iar pe un corpus care nu avea nevoie de retrieval, ai plătit-o degeaba.

Tiparul hibrid: RAG pe felia care chiar are nevoie

Decizia nu e binară. Cel mai bun rezultat vine de obicei dintr-un router care trimite fiecare întrebare pe drumul potrivit, iar RAG acoperă doar felia rămasă.

Cum arată routerul

Un clasificator ieftin — sau chiar un set de reguli — citește întrebarea și decide ruta. Interogările cu identificator merg în full-text. Cele cu intenție de agregare merg în SQL, cu parametri validați. Ce rămâne — întrebări deschise, formulate în limbaj natural, cu răspuns împrăștiat — merge în RAG. Ce nu se clasifică cu încredere merge la om.

Avantajul nu e doar de cost. Fiecare ramură are un mod de eșec diferit și îl poți diagnostica separat, în loc să te uiți la un singur număr agregat care nu spune nimic.

Ce măsori ca să știi dacă felia crește

Ține trei contoare: câte întrebări cad pe fiecare ramură, câte ajung la om și câte primesc răspuns marcat drept nesatisfăcător. Dacă ramura de RAG crește de la 10% la 40% în trei luni, ai justificarea pentru a investi în ea. Dacă rămâne la 10%, ai economisit un proiect.

Testul de o zi înainte de a aproba proiectul

Nu ai nevoie de un pilot de șase săptămâni ca să decizi. Ai nevoie de o zi și de disciplină.

Setul de 50 de întrebări reale

Adună 50 de întrebări pe care oamenii le-au pus efectiv — din tichete, din Slack, din mailuri. Nu întrebări inventate, care ies mereu convenabil de bine formulate. Clasifică-le pe cele cinci criterii din arborele de decizie și numără câte cad în fiecare categorie.

Dacă peste jumătate sunt fapte punctuale sau conțin identificatori exacți, ai răspunsul înainte să scrii o linie de cod.

Baseline-ul care trebuie bătut

Rulează toate cele 50 prin cea mai simplă alternativă pe care o poți construi într-o zi: căutare full-text peste aceleași documente, plus un model care primește primele cinci rezultate. Notează câte răspunsuri sunt corecte.

Ăsta e baseline-ul. Orice sistem RAG propus trebuie să-l bată cu o marjă care justifică diferența de cost și de întreținere. Dacă îl bate cu trei procente, decizia e luată — și nu în favoarea retrieval-ului.

Întrebări frecvente

De la câte documente merită un sistem RAG?

Numărul de documente contează mai puțin decât numărul de tokeni și decât forma întrebărilor. Un corpus care încape într-o fereastră de context și primește sub zece întrebări pe zi nu justifică un index, indiferent dacă are 50 sau 500 de fișiere. Peste zeci de mii de pagini cu trafic real, discuția se schimbă complet.

Ferestrele de un milion de tokeni fac RAG-ul inutil?

Nu, dar mută pragul în sus. Benchmark-urile independente arată constant că lungimea efectivă e mai mică decât cea revendicată, iar performanța scade odată cu lungimea inputului chiar și când retrieval-ul e perfect. Pentru corpusuri mici și stabile, fereastra mare chiar înlocuiește retrieval-ul. Pentru corpusuri mari, îl mută mai departe, nu îl elimină.

Când e full-text search mai bun decât căutarea semantică?

Când utilizatorii caută după termeni exacți: coduri de eroare, SKU-uri, numere de contract, denumiri de parametri, articole de lege. Embedding-urile netezesc exact identificatorii pe care te bazezi, iar retrieval-ul lexical rămâne un baseline greu de bătut pe seturile de date cu terminologie precisă.

Pot începe cu o alternativă simplă și migra la RAG mai târziu?

Da, și de obicei e ordinea corectă. Full-text peste documentele curate îți dă un sistem funcțional în câteva zile, plus ceva mult mai valoros: logurile de interogări. Ele îți spun exact ce se întreabă, cât de des și unde eșuează căutarea — adică fix specificația de care ai nevoie ca să construiești retrieval-ul corect, dacă se dovedește necesar.

Cum justifici în fața conducerii decizia de a nu construi?

Cu cele trei numere din testul de o zi: procentul de întrebări care sunt fapte punctuale, acuratețea baseline-ului simplu și costul lunar estimat al alternativei RAG. O decizie de a nu construi documentată cu cifre e o decizie de arhitectură. Una nedocumentată e doar o amânare.

Cea mai bună implementare de RAG e cea care nu s-a făcut, atunci când problema nu o cerea. Restul clusterului — de la arhitectură până la evaluare — presupune că ai trecut deja de întrebarea asta. Dacă vrei să reiei traseul de la capăt, Fundamentele RAG le are pe toate la un loc, comparațiile de abordare stau grupate la RAG vs fine-tuning, iar restul lucrărilor pe soluții AI și RAG acoperă ce urmează după decizie.