De ce eșuează un sistem RAG în producție (și cum eviți)

Proporția companiilor care renunță la majoritatea inițiativelor AI a crescut de la 17% la 42% într-un singur an, iar organizația medie aruncă 46% din proof-of-concept-uri înainte să ajungă în producție — date din raportul S&P Global Market Intelligence „Voice of the Enterprise: AI & Machine Learning, Use Cases 2025", pe peste 1.000 de respondenți. În paralel, cercetarea MIT din proiectul NANDA („The GenAI Divide", 2025) arată că 95% dintre piloții de generative AI nu produc niciun impact măsurabil pe rezultatele financiare, iar barierele sunt organizaționale și operaționale, nu tehnologice.

Un sistem RAG se încadrează perfect în tiparul ăsta: merge impecabil în demo și se prăbușește în producție din cauze previzibile. Articolul detaliază unde exact se defectează, de ce adăugarea mai multor date nu rezolvă problema și ce trebuie să faci înainte de lansare.

Capcana demoului

Dacă vrei mai întâi conceptele de bază, poți citi ce e RAG și cum funcționează. Dar diferența critică între un demo și producție e simplă: demoul rulează pe întrebări pe care le anticipezi, cu documente selectate, într-o ordine controlată — în timp ce producția primește întrebări neașteptate, formulate prost, pe o bază de cunoștințe care se schimbă constant.

Cercetarea de referință pe subiect (Barnett și colaboratorii, Deakin University, 2024 — „Seven Failure Points When Engineering a RAG System") trage o concluzie dură: un sistem RAG nu poate fi validat pe hârtie, ci doar în operare reală. Robustețea nu se proiectează de la început; se dezvoltă treptat, pe măsură ce vezi cum se comportă sistemul sub trafic real.

Dacă planul tău e să construiești, să testezi pe câteva întrebări și să lansezi, ai construit de fapt un demo, nu un produs. De aceea costul unui sistem RAG include și faza de operare și stabilizare de după lansare, nu doar construcția inițială.

Cele șapte puncte unde se rupe un pipeline RAG

Eșecul nu e o singură catastrofă, ci șapte moduri specifice de cădere, distribuite pe tot fluxul — de la indexare și chunking, prin retrieval și reranking, până la context și generarea finală.

Cel mai periculos eșec e când conținutul lipsește din baza de cunoștințe și sistemul inventează un răspuns plauzibil în loc să spună „nu știu". Apoi vin cazurile în care documentul corect există și e indexat, dar retrieval-ul îl clasează prea jos și nu ajunge în top-k — sau ajunge în top-k, dar se pierde la consolidare, fie din reranking agresiv, fie din limitări de tokeni, fie dintr-o strategie de merge care îl elimină.

Urmează eșecurile de extracție și formatare: informația e în context, dar modelul nu o scoate din cauza zgomotului prea mare, ori răspunde în format greșit, ignorând cerința de tabel sau listă. Uneori răspunsul e prea vag sau prea detaliat; alteori modelul acoperă doar o parte din întrebare și ignoră restul, deși informația lipsă era disponibilă în context.

Apare un tipar clar: cinci din cele șapte probleme țin de retrieval și de date, nu de generare. Acolo se decide de fapt calitatea răspunsului.

Mitul „mai mult context rezolvă tot"

Reacția intuitivă când sistemul ratează e să-i dai mai mult context: crești top-k, adaugi mai multe chunk-uri, treci pe un model cu fereastră de context imensă. De obicei asta înrăutățește lucrurile.

Cercetarea Chroma din 2025 a testat 18 modele frontier — printre care GPT-4.1, Claude Opus 4 și Gemini 2.5 — și a constatat că toate se degradează pe măsură ce inputul crește, chiar și sub limita ferestrei de context. Fenomenul are deja un nume: context rot. În plus, studiul „lost in the middle" (Liu și colaboratorii, 2024) a arătat că acuratețea scade cu peste 30% când informația relevantă se află la mijlocul contextului, nu la început sau la final.

Concluzia practică: o fereastră de context mare nu compensează un retrieval slab. Zece chunk-uri foarte relevante valorează mai mult decât o sută adăugate „ca să fim siguri". Calitatea bate cantitatea.

Nu poți repara ce nu măsori: golul de evaluare

Problema reală e mai mare: majoritatea echipelor nu măsoară deloc dacă sistemul funcționează. Fără metrici concrete, fiecare ajustare de chunking sau de prompt e o ghicire — nu știi dacă ai îmbunătățit ceva sau ai stricat altceva.

RAG-ul are două componente independente, care pot eșua separat: retriever-ul și generatorul. Le evaluezi pe amândouă, cu metrici dedicate. Frameworkuri ca RAGAS sau DeepEval fac exact asta: context precision și context recall pentru retrieval, faithfulness și answer relevancy pentru generare.

Regula de bază: construiești un set de evaluare cu întrebări și răspunsuri așteptate, îl rulezi în CI la fiecare schimbare și monitorizezi aceleași metrici în producție, nu doar la lansare — pentru că un sistem RAG se degradează treptat.

Cum previi eșecul: checklist înainte de lansare

Practicile de mai jos atacă direct modurile de eșec de mai sus:

• Gestionează abținerea (abstention). Forțează modelul să răspundă „nu știu" când contextul nu conține informația și stabilește un prag de relevanță sub care nu răspunde deloc. Acoperă conținutul lipsă și o bună parte din halucinații.
• Combină căutarea lexicală cu cea semantică (hybrid search). Multe rateuri de retrieval vin din dependența exclusivă de embeddings; căutarea hibridă prinde și termenii exacți care altfel scapă. Pasul următor e rerankingul cu cross-encoder, care rearanjează rezultatele după relevanță, nu după similaritate.
• Cere citare obligatorie la sursă. Când fiecare afirmație trebuie ancorată într-un chunk, halucinațiile devin detectabile automat. Citarea corectă nu e însă suficientă când documentul citat a expirat — un mod de eșec tratat pe corpus comercial în RAG pentru enablement de vânzări.
• Măsoară continuu. Eval set în CI la fiecare schimbare, plus monitorizare în producție — nu doar o verificare la lansare.
• Stabilește proprietatea (ownership). Cineva trebuie să dețină conținutul RAG și să răspundă când modelul de bază se schimbă.

Diferența dintre sistemele care ajung în producție și restul nu e un model mai bun — e disciplina în tratarea retrieval-ului și a evaluării.

Toate cele șapte puncte de mai sus presupun un pipeline cu un singur pas de retrieval. Când treci pe o buclă în care modelul decide singur de câte ori caută, peste ele se adaugă un set nou de eșecuri — bucle care nu se închid, context care se umflă de la o iterație la alta, drift de raționament. Le tratează articolul despre agentic RAG și multi-hop.

Întrebări frecvente

De ce eșuează un sistem RAG în producție dacă merge în demo?

Demoul rulează pe întrebări și documente controlate; producția primește întrebări neanticipate și o bază de cunoștințe în schimbare. De aceea robustețea se construiește în operare, nu înainte de lansare.

Care e cea mai frecventă cauză de eșec?

Retrieval-ul, nu generarea. Majoritatea punctelor de eșec documentate țin de regăsirea informației: documentul corect nu e găsit, e clasat prea jos sau se pierde înainte să ajungă la model.

O fereastră de context mai mare rezolvă problemele de retrieval?

Nu. Modelele se degradează pe măsură ce inputul crește, iar efectul „lost in the middle" reduce acuratețea cu peste 30%. Retrieval-ul precis bate contextul mare.

Cum măsori dacă un sistem RAG funcționează corect?

Pe două straturi: retriever-ul (context precision și context recall) și generatorul (faithfulness și answer relevancy), folosind framework-uri de evaluare automatizată ca RAGAS sau DeepEval.

Cât durează să stabilizezi un sistem RAG după lansare?

Nu e un sprint unic, ci operare continuă, dependentă de trafic și de calitatea datelor. Robustețea se construiește iterativ, urmărind unde eșuează sistemul pe întrebări reale și corectând retrieval-ul și conținutul în consecință.

De unde continui

Pentru o implementare completă, pas cu pas, vezi ghidul despre cum construiești un sistem RAG cu Next.js și Vercel AI SDK. Dacă vrei imaginea de ansamblu a serviciului, intră pe hub-ul de soluții AI și RAG, iar pentru restul articolelor din această serie urmărește categoria RAG în producție.