Cum reduce RAG halucinațiile: grounding și citarea surselor

Un model de limbaj nu minte când halucinează. Completează. Iar mecanismul care îl face să completeze — presiunea de a produce un răspuns plauzibil chiar când nu are pe ce se sprijini — e același indiferent dacă îi dai sau nu documente. Aici pornim de la cauză ca de la un dat și trecem la partea practică: ce anume dintr-un sistem RAG reduce efectiv halucinațiile, și ce doar pare că le reduce.

Răspunsul scurt e că nu recuperarea în sine face treaba. Documentele aduse în context sunt materia primă. Reducerea vine din trei mecanisme suprapuse peste ele: grounding-ul (constrângerea răspunsului la ce e în context), citarea verificabilă (posibilitatea de a controla fiecare afirmație) și abținerea (dreptul sistemului de a spune „nu știu”). Fiecare acoperă un gol pe care celelalte două îl lasă deschis.

De ce documentele în prompt nu reduc singure halucinațiile

Recuperarea rezolvă o problemă de acces: modelul nu mai trebuie să știe răspunsul, îi ajunge să-l citească. Grounding-ul rezolvă o problemă complet diferită — ca răspunsul să nu depășească ce scrie efectiv în pasajele recuperate.

Sunt două tipuri de eroare distincte, iar confuzia dintre ele explică de ce multe sisteme RAG „cu documente” halucinează în continuare:

• Eroare de factualitate: afirmația e falsă în raport cu lumea. Recuperarea o atacă direct.
• Eroare de fidelitate: afirmația nu e susținută de contextul dat, chiar dacă e adevărată sau plauzibilă. Recuperarea nu o atacă deloc — uneori o creează, pentru că modelul primește un teren pe care poate broda.

Al doilea tip e cel periculos în B2B, fiindcă arată exact ca un răspuns corect: are ton documentat, are surse atașate, are structura potrivită. Diferența se vede doar dacă cineva deschide sursa. Distincția între cele două se măsoară separat, iar metricile de faithfulness și de retrieval sunt subiectul altei discuții — aici ne interesează ce faci ca să nu ajungi să le ratezi.

Contextul are mai multă forță decât crezi

Un rezultat din ClashEval, benchmark publicat la NeurIPS 2024, ar trebui să schimbe felul în care privești pasajele pe care le trimiți modelului. Autorii au perturbat deliberat conținutul recuperat, de la erori subtile la erori flagrante, și au măsurat ce se întâmplă când contextul contrazice ceea ce modelul „știa” corect. Modelele testate au adoptat conținutul recuperat greșit, suprascriind propriul răspuns corect, în peste 60% din cazuri.

Asta e o veste bună și una proastă în același timp. Bună: dacă pui informația corectă în context, modelul o va folosi — instrucțiunea de grounding chiar are pe ce se prinde. Proastă: calitatea răspunsului tău e limitată de calitatea retrieval-ului, iar un pasaj recuperat prost nu e ignorat politicos, ci repetat cu încredere. Modurile prin care retrieval-ul eșuează în producție devin astfel moduri prin care sistemul halucinează.

De aici rezultă structura pe care o urmează restul articolului: grounding-ul funcționează doar dacă îl construiești pe trei niveluri — ca instrucțiune, ca arhitectură și ca interfață.

Grounding ca instrucțiune: contractul de răspuns

Primul nivel e cel mai ieftin și cel mai des făcut prost. Un prompt de grounding serios nu e o propoziție („răspunde doar pe baza contextului”), ci un contract cu cinci clauze explicite.

Cele cinci clauze

1. Sursa exclusivă. Răspunsul se construiește doar din pasajele furnizate. Cunoștințele generale ale modelului nu completează golurile — nici măcar când sunt corecte.
2. Marcarea golurilor. Dacă o parte din întrebare nu e acoperită, se spune explicit care parte, nu se ocolește.
3. Citarea per afirmație. Fiecare afirmație factuală poartă referința pasajului din care provine.
4. Formula de abținere. Textul exact pe care îl produce sistemul când contextul e insuficient. Nu-l lăsa la latitudinea modelului — variază de la un răspuns la altul și devine imposibil de detectat automat.
5. Interdicția de inferență tăcută. Dacă răspunsul cere un pas de raționament care nu e în documente (o combinație, o extrapolare, un calcul), acel pas se marchează ca atare.

Diferența față de un prompt obișnuit e că fiecare clauză produce un comportament observabil în output. Poți să verifici automat dacă a fost respectată — ceea ce cu „fii precis și nu inventa” nu poți.

Citează întâi, răspunde apoi

O tehnică simplă care schimbă vizibil rata de invenție: cere modelului să extragă întâi citatele verbatim relevante și abia apoi să formuleze răspunsul. Documentația Anthropic pentru reducerea halucinațiilor o recomandă explicit pentru documente lungi, peste 20.000 de tokeni, împreună cu o a doua mișcare la fel de utilă — după ce răspunsul e generat, modelul e pus să găsească un citat care susține fiecare afirmație, iar afirmațiile pentru care nu găsește citat se retrag.

Ordinea contează. Când extragerea vine prima, răspunsul se construiește pe un material deja delimitat. Când vine la final, ca justificare, modelul caută sprijin pentru ceva ce a scris deja — și găsește, pentru că e bun la asta.

Există și o variantă mai slabă, dar aproape gratuită: instrucțiunile de tip „conform”, studiate de cercetătorii care au propus metrica QUIP-Score. Simplul fapt de a cere modelului să răspundă folosind informația dintr-o sursă anume îi crește rata de citare literală, iar rata mai mare de citare literală se corelează cu mai puține halucinații.

De ce instrucțiunea nu e suficientă

Un model nu poate „des-ști” ce a învățat la antrenare. Asociațiile factuale puternice trag textul generat spre memoria parametrică, iar instrucțiunea de grounding e o preferință în competiție cu ele, nu o barieră. Funcționează statistic, nu determinist.

Ceea ce înseamnă un lucru simplu: dacă singurul tău mecanism anti-halucinație e o secțiune din system prompt, nu ai un mecanism, ai o speranță. Nivelul următor nu e opțional.

Grounding ca arhitectură: verificarea care nu depinde de bunăvoința modelului

Al doilea nivel mută controlul din prompt în cod. Ideea de bază: verificarea unui răspuns e o sarcină mai ușoară decât producerea lui. Un component separat care întreabă „e fraza asta susținută de pasajul citat?” are un job îngust, evaluabil și ieftin.

Verificatorul de fidelitate

Cea mai directă implementare e o a doua trecere, la nivel de frază: iei fiecare propoziție din răspuns, iei pasajele pe care le citează și verifici relația de implicație. Poți face asta cu un model NLI mic (rapid, ieftin, rulează local) sau cu un LLM-judecător (mai flexibil, mai scump, mai lent).

Rezultatul nu e o notă pe care o afișezi, ci un semnal de rutare: fraza trece, fraza primește avertisment, fraza se elimină din răspuns. Un sistem care taie afirmațiile nesusținute înainte să ajungă la utilizator produce răspunsuri mai scurte și considerabil mai de încredere.

Citarea la nivel de API

Câțiva furnizori au mutat mecanismul în platformă, ceea ce îți scutește o bună parte din efortul de prompt engineering.

Anthropic a lansat în ianuarie 2025 funcția Citations în API: documentele sunt sparte în propoziții, iar modelul întoarce citări structurate către pasajele exacte pe care se sprijină fiecare afirmație — cu trei niveluri de granularitate, poziție în text, pagină în PDF sau bloc de conținut definit de tine. Un detaliu de cost care contează la volum: textul citat nu se facturează ca tokeni de output. Anthropic citează în anunț un client, Endex, care raportează că a eliminat complet halucinațiile de sursă și problemele de formatare a referințelor după trecerea pe Citations — o cifră auto-raportată de client, nu o măsurătoare independentă, dar direcția e consistentă cu ce vezi în practică.

Google Cloud expune o piesă complementară în Agent Search: un API dedicat de verificare a grounding-ului, care primește răspunsul candidat plus setul de fapte și întoarce un scor de suport între 0 și 1, aproximând fracțiunea de afirmații care chiar sunt susținute, împreună cu maparea fiecărei afirmații către bucățile citate. Există și un prag de citare configurabil: îl urci și primești mai puține citări, dar mai puternice.

Diferența față de citarea prin prompt e că aceste mecanisme întorc structură, nu text. O structură o poți valida, filtra și loga. Un șir de caractere care arată ca o citare nu.

Citarea deterministă

Există și o abordare mai radicală, apărută în domenii unde eroarea e inacceptabilă, ca sănătatea: citatele afișate utilizatorului nu sunt cele generate de model, ci sunt extrase programatic din sursă pe baza ancorelor întoarse. Premisa e că orice text care trece prin model e potențial alterat — chiar și un citat pe care l-ai cerut verbatim. Modelul poate greși alegând pasajul, dar pasajul afișat e garantat real.

Pentru un asistent intern peste documentație tehnică sau contracte, e o schimbare de câteva ore de implementare cu un efect disproporționat asupra încrederii.

Rutarea pe calitatea retrieval-ului

Ultima piesă arhitecturală mută decizia înaintea generării. În loc să generezi mereu și să verifici după, evaluezi întâi dacă merită să generezi.

Corrective RAG, propus în 2024, adaugă un evaluator ușor care clasifică pasajele recuperate în trei categorii — corecte, ambigue, incorecte — și declanșează acțiuni diferite: rafinare și curățare pentru primele, o sursă alternativă pentru ultimele, o combinație pentru cele din mijloc. Self-RAG merge pe altă cale, antrenând modelul să emită token-uri de reflecție care decid dacă e nevoie de retrieval, dacă pasajul e relevant și dacă afirmația generată e susținută de el.

Nu ai nevoie să implementezi niciuna dintre ele ca atare. Ideea transferabilă e că suficiența contextului e o decizie separată de generare, iar dacă nu o iei explicit, o ia modelul implicit — și o ia prost. Un reranker plasat corect în pipeline îți dă deja jumătate din semnalul de care ai nevoie pentru poarta asta.

Abținerea: „nu știu” e feature, nu bug

Al treilea mecanism e cel pe care echipele îl taie primul, sub presiunea unei observații reale: utilizatorii se plâng când sistemul refuză. Merită pus în balanță corect.

Costurile sunt asimetrice. Un „nu știu” costă o escaladare și puțină frustrare. Un răspuns fabricat, livrat cu ton sigur și cu surse atașate, costă o decizie greșită luată pe baza lui — plus încrederea în tot sistemul, pentru toate răspunsurile viitoare, inclusiv cele corecte. Prima greșeală descoperită de un utilizator invalidează retroactiv sute de răspunsuri bune.

Nu vine gratis cu un model mai bun

AbstentionBench, un benchmark din 2025 construit pe peste 35.000 de întrebări fără răspuns valid, a testat exact această capacitate. Două rezultate merită reținute înainte să planifici un upgrade de model ca soluție: dimensiunea modelului nu are practic niciun efect asupra capacității de abținere, iar intervenții de tip reasoning înrăutățesc abținerea față de modelele instruction-tuned de bază.

Comportamentul se vede și în afara laboratorului. Studiul Tow Center publicat de Columbia Journalism Review în martie 2025 a testat opt motoare de căutare generative pe 1.600 de interogări, cerându-le să identifice sursa unor fragmente reale din articole. Peste 60% din răspunsuri au fost greșite, cu variații mari între sisteme — de la 37% la Perplexity până la 94% la Grok 3. Concluzia relevantă aici nu e rata de eroare, ci ce au făcut sistemele când nu știau: au ghicit. Autorii notează că modelele au fost în general slabe la a refuza întrebările la care nu puteau răspunde corect și au oferit în schimb răspunsuri speculative. Din 134 de atribuiri greșite ale unui singur sistem, doar 15 conțineau vreo formă de exprimare a incertitudinii.

Abținerea nu apare de la sine. O construiești.

Cum scrii politica de abținere

O abținere utilă nu e un refuz. „Nu am găsit informația” e un capăt de drum; o abținere bine construită e o redirecționare cu patru componente:

• Ce lipsește exact — nu „nu am date”, ci „documentația acoperă configurarea, dar nu și limitele de rată pentru planul enterprise”.
• Ce ai găsit totuși — dacă 60% din întrebare e acoperită, răspunde la 60% și marchează restul. Abținerea parțială e aproape întotdeauna mai valoroasă decât refuzul total.
• Ce ar rezolva golul — ce document, ce echipă, ce sistem ar avea răspunsul.
• Calea de escaladare — concretă, cu un singur pas de făcut.

Formula trebuie să fie fixă și detectabilă programatic. Dacă nu poți număra abținerile în log-uri, nu poți nici să le reglezi.

Capcana simetrică

Un sistem care se abține prea des e la fel de inutil ca unul care inventează, doar că eșuează vizibil în loc de invizibil. Dacă recompensa pentru abținere e prea mare, modelul devine precaut și refuză întrebări pe care le acoperă perfect.

Măsoară deci ambele direcții: rata de abținere pe întrebări care aveau răspuns în corpus și rata de răspuns pe întrebări care nu-l aveau. Un set de evaluare cu ambele tipuri de întrebări, în proporții egale, e minimul necesar înainte să atingi orice prag.

Citarea la nivel de frază vs la nivel de document

Toate sistemele „cu citări” nu fac același lucru. Distincția dintre citarea la nivel de document și cea la nivel de afirmație e diferența dintre un element de decor și un mecanism de verificare.

Citarea la nivel de document înseamnă o listă de surse la finalul răspunsului. Arată bine, dă senzația de rigoare și e practic inutilizabilă: ca să verifici o singură afirmație, deschizi trei documente și cauți. Nimeni nu face asta, deci nimeni nu verifică, deci o afirmație nesusținută trece nedetectată.

Citarea la nivel de frază leagă fiecare afirmație de pasajul care o susține. Costul de verificare scade de la minute la secunde, iar verificarea începe efectiv să se întâmple.

Recall și precizie de citare

Benchmark-ul ALCE, propus la EMNLP 2023, a formalizat cele două dimensiuni care contează, iar ele sunt utile ca mod de gândire chiar dacă nu rulezi benchmark-ul:

• Citation recall: fiecare frază din răspuns e susținută de pasajele pe care le citează.
• Citation precision: fiecare citare chiar contribuie la susținere. Se testează prin eliminare — scoți o citare și verifici dacă relația de implicație se rupe. Dacă nu se rupe, citarea era decorativă.

A doua metrică e cea pe care echipele o ignoră și e exact cea care previne comportamentul defensiv al modelului: „citez toate cele cinci pasaje la fiecare frază, ca să fiu acoperit”. Recall perfect, precizie zero, verificare imposibilă.

Granularitatea citării e o decizie de chunking

Cele două sunt legate direct. Dacă chunk-urile tale au două pagini, o citare la nivel de frază duce utilizatorul la două pagini — ai construit tehnic mecanismul, dar ai păstrat costul de verificare al citării pe document. Dacă sunt prea mici, pasajul citat nu mai conține contextul care face afirmația inteligibilă.

Concluzia practică: strategia de chunking nu se optimizează doar pentru calitatea retrieval-ului, ci și pentru cât de ușor e de verificat o citare. Sunt obiective diferite și uneori trag în direcții opuse.

O citare care arată bine nu e o citare corectă

Același studiu Tow Center a documentat și partea a doua a problemei: URL-uri fabricate, trimiteri către versiuni sindicalizate în loc de sursa originală, linkuri care duc la pagini de eroare. Prezența unei citări nu spune nimic despre validitatea ei.

De aici două reguli operaționale: ancorele trebuie să fie stabile și verificabile programatic (offset de caractere, pagină, identificator de bloc — nu titluri reconstruite de model), iar validarea trebuie să ruleze automat, nu vizual. Adaugă și versionarea documentelor: dacă sursa se schimbă după ce răspunsul a fost livrat, o ancoră care încă rezolvă, dar spre alt conținut, e mai rea decât una ruptă.

Ce faci când contextul recuperat se contrazice

Situația pe care majoritatea sistemelor o tratează cel mai prost: două pasaje recuperate spun lucruri diferite despre același lucru. Lăsat singur, modelul alege o variantă și o prezintă cu exact aceeași încredere ca pe orice altceva. Tehnic e grounded — sprijinit pe un pasaj real. Practic, e cea mai periculoasă formă de halucinație, fiindcă trece toate verificările de fidelitate.

Sunt trei tipuri de conflict, cu soluții diferite:

• Context contra memorie parametrică. Ce a măsurat ClashEval. Aici vrei ca modelul să prefere contextul, dar cu o excepție: când pasajul e evident absurd, prioritatea ar trebui să se inverseze.
• Conflict în interiorul corpusului. Două documente interne se contrazic — o politică veche și una nouă, două versiuni ale aceleiași proceduri, o pagină de wiki nemigrată. Cazul cel mai frecvent în bazele de cunoștințe reale.
• Ambiguitate sau perspective diferite. Sursele nu se contrazic factual, răspund la întrebări ușor diferite.

Politica de precedență trebuie declarată, nu ghicită

Pentru al doilea tip, singura soluție robustă e o ierarhie explicită, exprimată în metadate, nu dedusă din text: data efectivă, tipul documentului, aria de aplicabilitate, statusul de aprobare. Modelul nu are cum să știe că procedura din 2024 a fost înlocuită dacă nimic din pasaj nu spune asta — iar dacă ghicește după dată, va greși exact în cazurile în care documentul vechi a fost reeditat cosmetic.

Detecția se face înainte de generare: compari perechile de pasaje recuperate pe câmpurile relevante și, dacă se contrazic, nu treci la sinteză.

Expune conflictul, nu-l rezolva în tăcere

Când precedența nu poate decide, cel mai bun răspuns nu e un răspuns. „Două surse spun lucruri diferite: [A] conform documentului X din martie, [B] conform documentului Y din ianuarie” e mai util decât orice sinteză, pentru că mută decizia la cineva care are contextul organizațional pe care sistemul nu-l are.

Și mai important: fiecare conflict detectat e un defect de calitate a datelor, nu doar o problemă de RAG. Loghează-le. Lista conflictelor recurente e cel mai bun plan de curățenie pentru baza de cunoștințe pe care îl vei primi vreodată — și e generat gratuit, din trafic real.

Pragul de încredere și escaladarea către om

Ultima piesă leagă tot ce e mai sus de o decizie binară pe care sistemul o ia la fiecare cerere: livrez, avertizez sau escaladez.

Ce semnale ai la dispoziție

• Scorul de suport al răspunsului, dacă folosești un API de verificare a grounding-ului sau propriul verificator NLI.
• Acoperirea citărilor: procentul de fraze factuale care au cel puțin o citare validată. Se calculează local, fără costuri suplimentare de model.
• Calitatea retrieval-ului: scorul rerankerului pentru primele pasaje, distanța dintre primul și al treilea rezultat, numărul de pasaje peste un prag de relevanță.
• Dezacordul între eșantioane: generezi de două-trei ori la temperatură mică și compari afirmațiile. Divergența pe fapte e un semnal puternic, dar plătești de câteva ori generarea.

O avertizare de implementare: nu construi pe semnale care s-ar putea să nu mai fie acolo. Câmpurile de confidence per segment de grounding din Vertex AI, de exemplu, sunt documentate ca goale începând cu Gemini 2.5 și trebuie ignorate. Verifică ce întoarce efectiv furnizorul tău, nu ce spunea documentația acum un an.

Pragul se calibrează, nu se alege

Nu există o valoare universală. Procedura e mecanică: iei un set de întrebări reprezentative cu răspunsuri etichetate, incluzând întrebări fără răspuns în corpus, rulezi sistemul, sortezi după scorul de încredere și cauți punctul în care rata de eroare a răspunsurilor livrate scade sub bugetul tău de eroare. Rata de escaladare rezultată nu e un parametru pe care îl alegi — e consecința pe care o accepți.

Bugetul de eroare diferă enorm între contexte. Un asistent intern care sugerează articole de documentație tolerează 5% răspunsuri imperfecte. Un sistem care răspunde la întrebări despre clauze contractuale sau conformitate nu tolerează 1%, iar acolo pragul va trimite o parte semnificativă din trafic spre om. Asta nu e un eșec al sistemului, e configurarea corectă.

Trei benzi, nu două

Împărțirea binară „răspunde sau taci” pierde valoare. Trei benzi funcționează mai bine:

Escaladarea e un produs, nu un capăt de linie

Ce trece la om contează mai mult decât faptul că trece. Un tichet care conține doar întrebarea aruncă munca sistemului la gunoi. Un pachet de escaladare util duce mai departe întrebarea originală, pasajele recuperate cu scorurile lor, ce a identificat sistemul ca lipsă și răspunsul parțial, dacă există. Operatorul pornește de la 70%, nu de la zero — mecanica asta e ce face diferența într-un flux de customer support între un asistent care ajută echipa și unul care îi adaugă muncă.

Închide bucla: răspunsul dat de om se întoarce în corpus. Fiecare escaladare rezolvată e o gaură astupată în baza de cunoștințe.

Cum arată totul pus cap la cap

Niciun strat nu rezolvă singur problema, iar costurile diferă cu un ordin de mărime între ele. Ordinea de implementare de mai jos merge după raportul dintre efect și efort.

Un sistem care are primele două straturi e deja substanțial mai bun decât media. Un sistem care are primele patru poate fi lăsat în fața clienților. Al cincilea e ce separă un pilot reușit de o implementare care rezistă doi ani, pentru că bazele de cunoștințe reale se contrazic pe măsură ce cresc.

Restul contextului conceptual — ce este RAG și când merită, plus celelalte articole din fundamentele RAG — completează imaginea dacă construiești primul sistem.

Întrebări frecvente

Grounding-ul elimină complet halucinațiile?

Nu. Reduce substanțial rata și, mai important, face erorile rămase detectabile — o afirmație fără citare validată e vizibilă, una inventată într-un răspuns fără mecanism de citare nu e. Obiectivul realist nu e zero halucinații, ci un sistem în care o halucinație e o excepție care declanșează un semnal, nu o normalitate invizibilă.

E suficient să cer în prompt „răspunde doar din context”?

E punctul de plecare, nu soluția. Instrucțiunea concurează cu asociațiile învățate la antrenare și câștigă statistic, nu determinist. Fără un verificator în afara modelului, nu ai cum să știi în ce procent din cazuri a fost respectată.

Cât costă în plus un strat de verificare?

Depinde de implementare. Un verificator NLI mic rulează local, adaugă zeci de milisecunde și practic niciun cost de API. Un LLM-judecător pe fiecare răspuns poate dubla costul de inferență. Compromisul obișnuit: verificare ieftină pe tot traficul, verificare scumpă doar pe răspunsurile care intră în banda de mijloc.

Ce fac dacă utilizatorii se plâng că sistemul spune prea des „nu știu”?

Verifică întâi dacă abținerea e corectă — dacă întrebările chiar n-au răspuns în corpus, problema e acoperirea documentației, nu pragul. Dacă au, urcă pragul controlat și măsoară ce se întâmplă cu rata de eroare. Și îmbunătățește forma abținerii: majoritatea plângerilor vizează refuzuri seci, nu refuzuri justificate care oferă o cale de continuare.

Merită citarea la nivel de frază dacă documentele mele sunt scurte?

Da, dar câștigul e mai mic. Cu chunk-uri de un paragraf, diferența de cost al verificării între cele două granularități se comprimă. Beneficiul rămâne pe partea de precizie a citării: știi care pasaj susține fiecare afirmație, ceea ce îți dă un semnal de rutare pe care lista de surse de la final nu ți-l dă.

Dacă ai deja un sistem RAG care răspunde bine în demo și te face nervos în producție, punctul de plecare e de obicei același: verifici ce procent din afirmații au sprijin real în context și ce face sistemul când nu are răspuns. Restul deciziilor de arhitectură vin singure după aceste două numere. Vezi și celelalte articole despre integrări AI și sisteme RAG dacă evaluezi acum ce merită construit.