Cum arată un răspuns bun de RAG: sinteză, format, refuz

Retrieval-ul a mers perfect. Documentul relevant e pe prima poziție, scorurile arată bine, iar pasajul care conține răspunsul e chiar acolo, în context. Și totuși, în loc de un răspuns bun, utilizatorul primește patru paragrafe care ocolesc întrebarea și se termină cu o invitație să contacteze suportul.

Un răspuns bun de RAG nu se naște din retrieval bun. Se construiește pe ultimul metru — distanța dintre pasajele recuperate și textul care ajunge efectiv pe ecran. Acolo se decide dacă cineva mai deschide sistemul săptămâna viitoare sau se întoarce la căutarea manuală în documentație.

Ghidul de față tratează exact acel metru: cum asamblezi contextul înainte de generare, ce clauze din prompt schimbă forma răspunsului, când răspunzi în proză și când într-un tabel, ce spui când ai doar jumătate din informație, cum refuzi fără să pari inutil și cum arată în interfață un răspuns pe care cineva îl poate verifica în cinci secunde.

Ultimul metru: de ce retrieval bun nu înseamnă răspuns bun

Un sistem RAG are două jumătăți. Prima găsește informația. A doua o transformă în ceva ce un om poate citi și folosi. Aproape toată atenția tehnică se duce în prima jumătate — embeddings, chunking, reranking — iar a doua rămâne un prompt scris în grabă acum șase luni și nemodificat de atunci.

Rezultatul e un tipar recognoscibil: sistemul „știe” răspunsul, dar nu-l livrează.

Trei eșecuri care apar strict după retrieval

Diluția. Modelul primește cinci pasaje și le rezumă pe toate, în loc să răspundă la întrebare. Utilizatorul citește 300 de cuvinte corecte din care niciunul nu-i spune ce să facă. Contextul a fost folosit, dar întrebarea nu a fost adresată.

Suprarevendicarea. Un pasaj tangențial devine bază pentru o afirmație categorică. Documentul spune ce se întâmplă în cazul general; răspunsul afirmă ce se întâmplă în cazul particular pe care l-a întrebat omul. Arhitectura pare fundamentată — există pasaje, există citări — dar afirmația nu e susținută de ele.

Formatul greșit. Întrebarea cerea o procedură în patru pași; răspunsul a venit ca un eseu. Sau invers: o întrebare de „de ce” a primit un tabel care nu explică nimic.

Ce ține de acest articol și ce nu

Delimitarea contează, fiindcă subiectele vecine se ating. Mecanismul citării, verificarea grounding-ului și politica de precedență între surse contradictorii sunt tratate în ghidul despre halucinații, grounding și citare — acolo e dovada din spatele răspunsului. Aritmetica bugetului de tokeni stă în ghidul despre fereastra de context. Cum măsori calitatea rezultatului, cu faithfulness și answer relevance, e subiectul ghidului de evaluare RAG. Iar ordonarea rezultatelor înainte de generare ține de hybrid search și reranking. Ce model rulează efectiv generarea — și pe ce criterii îl alegi dintre candidați — e o decizie separată, tratată în cum alegi modelul de generare.

Aici rămâne forma: ce intră în prompt și în ce ordine, ce instrucțiuni dai, ce structură are textul livrat, ce faci când acoperirea e parțială și cum arată răspunsul în interfață.

Asamblarea contextului: ce intră în prompt și în ce ordine

Retrieverul întoarce o listă de obiecte. Prompt-ul are nevoie de un singur bloc de text. Între cele două stă un pas de asamblare pe care multe implementări îl rezolvă cu un join peste câmpul content — și pierd acolo mai mult decât au câștigat din reranking.

Deduplicarea: același paragraf, patru versiuni

Într-o bază de cunoștințe reală, aceeași informație apare în mai multe locuri: un paragraf din politica internă, aceeași frază copiată în FAQ-ul de pe site, o versiune ușor editată într-un PDF de anul trecut și un extras într-un email de onboarding. Retrieverul le găsește pe toate patru, fiindcă toate sunt relevante.

Efectul asupra răspunsului e dublu și ambele părți sunt proaste. Contextul se umple cu redundanță în loc de informație nouă, iar modelul interpretează repetiția ca semnal de importanță — și accentuează exact detaliul care s-a nimerit duplicat.

Un pas de deduplicare rezonabil face trei lucruri: detectează near-duplicates (similaritate ridicată între pasaje, nu doar potrivire exactă), păstrează varianta cea mai autoritară sau cea mai recentă și menționează în metadate că există alte versiuni. Regulile de igienă a corpusului care previn duplicarea din start sunt în ghidul despre pregătirea documentelor pentru RAG.

Ordinea: capetele contextului contează mai mult decât mijlocul

Lucrarea „Lost in the Middle” a lui Nelson Liu și colegii, publicată în Transactions of the ACL, a arătat că performanța modelelor variază în funcție de unde se află informația relevantă în context: cea mai bună când e la început sau la final, cea mai slabă când e la mijloc. Efectul a fost măsurat pe sarcini de tip question answering cu documente distractoare.

Nuanța importantă: rezultatul nu s-a reprodus uniform. Lucrări ulterioare au raportat că efectul depinde de model și de sarcină — o evaluare din 2025 pe Gemini 2.5 Flash nu a găsit degradare pozițională pentru întrebări factuale simple, iar benchmark-ul Counting-Stars a ajuns la concluzii similare pentru anumite modele. Nu trata poziția ca lege universală.

Trata-o ca asigurare ieftină. Pui pasajul cel mai puternic primul, pe al doilea ultimul, iar restul la mijloc. Nu costă nimic și acoperă cazul în care modelul tău chiar are prejudecată pozițională. Dacă vrei să știi dacă o are, testează: mută pasajul care conține răspunsul pe fiecare poziție și măsoară.

Câte pasaje sunt prea multe

Instinctul spune că mai mult context înseamnă acoperire mai bună. Datele spun altceva. Cercetarea „Long-Context LLMs Meet RAG” a arătat că, pe măsură ce crește numărul de pasaje recuperate, recall-ul urcă, precizia scade, iar acuratețea sistemului crește până într-un punct și apoi coboară. Autorii au remarcat și un detaliu contraintuitiv: hard negatives de la un retriever mai bun pot deruta modelul mai tare decât cele de la un retriever slab, fiindcă sunt mai plauzibile.

În aceeași direcție, lucrarea „The Distracting Effect” (Amiraz și colegii, ACL 2025) a formalizat ideea că pasajele irelevante dar semantic apropiate nu sunt zgomot neutru — sunt distragere activă, măsurabilă per pasaj.

Concluzia practică nu e o cifră universală, fiindcă pragul depinde de model, de lungimea chunk-urilor și de domeniu. Concluzia practică e o metodă: pornește de la un număr mic de pasaje, măsoară acuratețea pe setul tău de întrebări, apoi crește până când curba se aplatizează. Punctul de întoarcere e configurația ta, nu una din literatură.

Ce metadate merg lângă fiecare pasaj

Un pasaj gol de context nu poate fi citat, datat sau ierarhizat. Ambalajul minim util conține un identificator stabil, titlul documentului, secțiunea, data ultimei actualizări și link-ul canonic.

Formatul contează mai puțin decât consistența. Un delimitator fix, aceleași câmpuri în aceeași ordine pentru fiecare pasaj, fără variații între rulări:

1[S3] Politica de retur | Secțiunea 4.2 | actualizat 2026-03-11
2https://intranet.exemplu.ro/politici/retur#4-2
3---
4Produsele electronice pot fi returnate în 30 de zile de la livrare,
5cu ambalajul original. Excepțiile sunt listate în anexa B.

1[S3] Politica de retur | Secțiunea 4.2 | actualizat 2026-03-11
2https://intranet.exemplu.ro/politici/retur#4-2
3---
4Produsele electronice pot fi returnate în 30 de zile de la livrare,
5cu ambalajul original. Excepțiile sunt listate în anexa B.

Identificatorul scurt (S3) e ce va apărea în citare. Data permite modelului să aplice o regulă de precedență când două pasaje se contrazic. Link-ul face răspunsul verificabil fără să treci prin căutare.

Prompt-ul de sinteză: contractul dintre pasaje și răspuns

Prompt-ul de generare nu e un loc pentru amabilități. E un contract cu patru clauze, iar fiecare clauză lipsă produce un tip previzibil de eșec.

Cele patru clauze

Sursa adevărului. Răspunzi doar din pasajele furnizate. Fără această clauză, modelul completează golurile din cunoștințele parametrice și obții afirmații care sună bine și nu apar nicăieri în corpus.

Politica de acoperire. Ce faci când pasajele acoperă întrebarea parțial și ce faci când nu o acoperă deloc. Fără ea, modelul alege singur — iar alegerea implicită e aproape întotdeauna să răspundă oricum.

Forma răspunsului. Când folosești proză, când liste, când tabel; ce lungime implicită; ce vine primul. Fără ea, primești formatul cu care modelul se simte confortabil, nu cel de care are nevoie întrebarea.

Marcarea evidenței. Fiecare afirmație care poate fi verificată poartă identificatorul pasajului din care provine. Mecanica exactă a citării e detaliată separat, dar clauza trebuie să existe în contract.

Ce se strică dacă lipsește o clauză

Merită să faci exercițiul invers, o dată, pe setul tău de întrebări: scoți câte o clauză și te uiți ce se rupe. Ce vezi de obicei — fără sursa adevărului apar detalii inventate plauzibil; fără politica de acoperire dispar răspunsurile parțiale și rămân doar cele complete-dar-false; fără forma răspunsului variază lungimea haotic de la o întrebare la alta.

E cel mai ieftin test de regresie din tot pipeline-ul și îți spune care clauză chiar face muncă.

Ce nu pui în prompt

Nu pui instrucțiuni contradictorii. „Răspunde în maximum trei propoziții” plus „citează fiecare afirmație” plus „explică raționamentul” nu pot fi respectate simultan; modelul va sacrifica una dintre ele, iar tu nu controlezi care.

Nu pui adjective fără conținut. „Fii util și prietenos” nu schimbă nimic măsurabil. „Începe cu răspunsul direct, apoi dă contextul” schimbă.

Nu pui exemple few-shot care contrazic politica. Un exemplu în care modelul răspunde confident dintr-un pasaj vag anulează în practică clauza de acoperire scrisă cu 20 de rânduri mai sus.

Formatul răspunsului: proză, pași sau tabel

Formatul nu e cosmetică. E prima decizie de conținut, fiindcă structura textului comunică ce fel de lucru e răspunsul înainte ca cineva să citească primul cuvânt.

Regula de decizie

Patru tipare acoperă majoritatea întrebărilor dintr-o bază de cunoștințe de business:

Regula are o excepție simplă: tabelul merită doar cu cel puțin două opțiuni și cel puțin două criterii. Un tabel cu o coloană e o listă deghizată și se citește mai prost decât lista.

Când structura strictă face rău

Există o tentație de a forța totul în JSON, ca să fie ușor de randat. Lucrarea „Let Me Speak Freely?” (Tam și colegii, EMNLP 2024 Industry Track) a raportat o degradare a capacității de raționament a modelelor sub constrângeri de format, cu atât mai pronunțată cu cât constrângerea e mai strictă. Rezultatul a fost și contestat metodologic, iar magnitudinea diferă între surse — motiv suficient să nu citezi o cifră, dar și să nu ignori direcția.

Soluția de compromis e ordinea câmpurilor: lasă modelul să scrie raționamentul sau răspunsul liber într-un câmp de la începutul schemei și abia apoi câmpurile structurate. Fiindcă generarea e secvențială, ce e scris primul influențează ce urmează.

Lungimea implicită și dezvăluirea progresivă

Setează o lungime implicită scurtă și lasă detaliul la cerere. Structura care funcționează în aproape orice interfață: răspunsul direct în prima propoziție, contextul necesar în următoarele două-trei, sursele imediat sub, iar restul — excepții, cazuri limită, proceduri conexe — accesibil printr-un click.

Motivul e simplu: majoritatea întrebărilor au un răspuns scurt și o coadă lungă de nuanțe care interesează o minoritate. Dacă livrezi coada implicit, minoritatea e mulțumită și restul renunță să citească.

Acoperire parțială: cazul cel mai frecvent în producție

Cazurile curate — pasajele răspund complet sau nu răspund deloc — sunt minoritare. Cazul dominant e la mijloc: pasajele acoperă o parte din întrebare. Aici se pierd cele mai multe sisteme, fiindcă nimeni nu a scris ce trebuie să se întâmple.

Anatomia unui răspuns parțial onest

Trei mișcări, în ordine: ce se poate afirma din documente, ce nu s-a găsit, ce e de făcut mai departe.

Documentele acoperă termenul de retur pentru produse electronice: 30 de zile de la livrare, cu ambalaj original [S3]. Nu am găsit nimic despre returul produselor cumpărate cu voucher corporate — anexa B menționează excepții, dar nu e în materialul disponibil. Pentru cazul cu voucher, secțiunea completă e la [link] sau întreabă echipa de conturi corporate.

Ce face răspunsul de mai sus: separă vizibil ce e susținut de ce nu, numește exact ce lipsește (nu „informații suplimentare”, ci anexa B) și dă o cale de continuare. Utilizatorul pleacă cu jumătate de răspuns și un pas următor clar, ceea ce e mai valoros decât un răspuns întreg și greșit.

Cum ceri clarificare fără să pari inutil

O întrebare de clarificare e justificată doar când ambiguitatea schimbă răspunsul. Dacă cele două interpretări duc la același rezultat, răspunzi și menționezi că e valabil în ambele cazuri.

Când chiar e nevoie, oferi ramurile în loc să pui o întrebare deschisă. „Depinde dacă e contract pe perioadă determinată sau nedeterminată — pentru determinată se aplică X [S1], pentru nedeterminată Y [S4]” livrează ambele răspunsuri și lasă omul să aleagă, în loc să-l trimită înapoi la tastatură.

Când sursele se contrazic

Contradicția în corpus e o realitate permanentă: politica veche nu a fost ștearsă, iar cea nouă a fost publicată în alt loc. Politica de precedență — cine câștigă și de ce — e tratată în articolul despre grounding și citare. Ce ține de forma răspunsului e altceva: contradicția se arată, nu se ascunde.

Un răspuns care alege tăcut o variantă și o prezintă ca adevăr transformă o problemă de conținut într-o problemă de încredere. Un răspuns care spune „documentul din martie 2026 zice 30 de zile [S3], unul mai vechi zice 14 [S7]; cel recent are prioritate” e verificabil și îl ajută pe cititor să înțeleagă de ce a primit ce a primit.

Refuzul calibrat: „nu știu” ca răspuns corect

Cel mai greu comportament de obținut e și cel mai valoros: să nu răspundă când nu are pe ce.

De ce modelele refuză prost din oficiu

Nu e o presupunere. AbstentionBench, un benchmark publicat în 2025 pentru evaluarea capacității de abținere pe întrebări fără răspuns, a raportat că modelele au dificultăți sistematice cu abținerea — iar antrenarea suplimentară pe raționament, care ar fi trebuit să ajute, a înrăutățit-o pentru mai multe modele evaluate. Comportamentul implicit e să producă ceva, nu să se oprească.

Concluzia operațională: dacă vrei refuz, îl proiectezi explicit. Nu apare de la sine și nu apare din modele mai mari.

Ce distinge un refuz util de unul leneș

Refuzul leneș e o propoziție: „Nu am găsit informații relevante.” Utilizatorul nu știe dacă a formulat greșit întrebarea, dacă documentul lipsește din bază sau dacă sistemul e stricat.

Refuzul util are trei componente: ce a fost căutat (în ce corpus, ce arie), de ce nu e suficient (nu există documentul, sau există dar nu acoperă cazul întrebat) și ce urmează (unde se caută manual, pe cine se întreabă, ce reformulare ar ajuta).

Diferența nu e de politețe, ci de utilitate. Al doilea răspuns îl mută pe om cu un pas mai departe; primul îl blochează.

Pragurile care declanșează refuzul

Trei niveluri, aplicate în ordine, prind majoritatea cazurilor:

1. Prag pe scorul de retrieval. Dacă cel mai bun pasaj e sub un prag, nu mai generezi deloc.
2. Verificare de suficiență. Pasajele au trecut pragul, dar acoperă ele întrebarea? Un pas separat care compară cerința cu ce e disponibil prinde cazul „relevant, dar insuficient”.
3. Verificare a răspunsului generat. Fiecare afirmație are suport în context? Dacă nu, răspunsul nu pleacă în forma aceea.

Valorile pragurilor nu se importă din articole. Se calibrează pe setul tău de întrebări, cu un compromis explicit între abțineri inutile și răspunsuri nefondate — exact tipul de arbitraj pe care metricile de evaluare îl fac vizibil.

Cazul în care refuzul e cel mai greu de acceptat și cel mai necesar e întrebarea cantitativă peste un corpus mare: „câți clienți au reclamat asta” nu are răspuns în opt pasaje, oricât de relevante ar fi. Granița dintre ce poate răspunde retrievalul și ce cere agregare pe date structurate e detaliată în RAG peste feedbackul clienților.

Ton, lungime și audiență

Același conținut, trei audiențe, trei texte diferite. Ce se schimbă e registrul și densitatea; ce nu se schimbă niciodată e fundamentarea.

Trei registre

Client final. Propoziții scurte, zero jargon intern, fără coduri de document în text. Sursa apare ca titlu lizibil („Politica de retur”), nu ca identificator. Un pas următor concret la final. Tiparele specifice pentru acest caz sunt în ghidul despre RAG în customer support.

Utilizator intern expert. Poate absorbi densitate mare și vrea referințe precise: secțiune, versiune, dată. Nu are nevoie de reintroducerea contextului la fiecare răspuns. Aici tonul explicativ devine zgomot.

Dezvoltator sau analist. Vrea structura brută: valori exacte, cazuri limită, ce nu acoperă documentul. Un tabel și trei note valorează mai mult decât două paragrafe bine scrise.

Ce nu se schimbă cu tonul

Politica de fundamentare, politica de refuz și marcarea evidenței rămân identice în toate cele trei registre. Un răspuns prietenos care afirmă mai mult decât susțin documentele e mai periculos decât unul sec, nu mai puțin.

Cercetarea despre supraîncredere în agenți conversaționali sugerează direcția: un stil cald crește acordul utilizatorului inclusiv atunci când sistemul greșește, iar formulările care exprimă incertitudine reduc supraîncrederea, cu efect dependent de cum sunt formulate. Căldura fără marcarea incertitudinii nu e ospitalitate, e risc.

Verificabil în cinci secunde: cum arată răspunsul în interfață

Un răspuns corect care nu poate fi verificat rapid e, în practică, un răspuns pe care nimeni nu-l verifică.

Ce vede ochiul întâi

Prima propoziție conține răspunsul, nu preambulul. „Conform documentației disponibile, în urma analizei materialelor furnizate...” consumă exact secunda în care cititorul decide dacă textul merită.

Sub răspuns vine evidența — fraza sau două din documentul-sursă care susțin afirmația. Nu tot pasajul; fragmentul relevant.

Citarea ca ancoră vizuală, nu ca notă de subsol

Un număr între paranteze drepte e o promisiune de dovadă, nu dovada. Lucrări din 2025 despre interfețele de tip answer engine descriu problema în termeni de „urmă slabă”: șirul de citare nu comunică ce conține sursa, deci costul verificării rămâne integral pe utilizator.

Ce reduce costul: numele documentului vizibil lângă afirmație, un fragment la hover, secțiunea exactă în link. Nu trimiți omul la un PDF de 40 de pagini; îl trimiți la paragraful din care a venit fraza.

Golul de încredere: oamenii verifică rar

Un studiu pe utilizatori ai sistemelor conversaționale cu referințe a măsurat rate de verificare mici — sub un sfert dintre răspunsuri primesc măcar un hover, iar click-urile pe sursă sunt mult mai rare — în timp ce scorurile de satisfacție rămân ridicate. Concluzia autorilor: plauzibilitatea contează mai mult decât verificarea. Analize ale sistemelor de căutare augmentată cu AI merg în aceeași direcție — prezența citărilor pare să conteze mai mult decât conținutul lor.

Asta schimbă obiectivul de design. Nu proiectezi pentru cititorul care verifică, fiindcă e minoritar. Proiectezi pentru cel care nu verifică: adică răspunsul nu are voie să afirme mai mult decât susțin sursele, iar incertitudinea trebuie să fie vizibilă în text, nu ascunsă într-un link pe care nimeni nu-l deschide.

Ce mai rămâne de făcut ține de disciplina zilnică: măsoară ce iese, nu ce crezi că iese. Tiparele de eșec care apar după punerea în producție sunt inventariate în ghidul despre motivele pentru care eșuează un sistem RAG, iar restul fundamentelor sunt grupate în categoria Fundamentele RAG.

Întrebări frecvente

Care e diferența dintre un răspuns fundamentat și unul bun?

Fundamentarea e o condiție necesară, nu suficientă. Un răspuns poate fi complet susținut de pasaje și în același timp inutil: prea lung, în format greșit, fără răspunsul direct în prima frază sau fără să spună ce lipsește. Fundamentarea ține de adevăr, forma ține de utilizabilitate — ai nevoie de amândouă.

Câte pasaje ar trebui să trimit în prompt?

Nu există o cifră universală. Cercetarea arată că acuratețea crește cu numărul de pasaje până într-un punct și apoi scade, fiindcă pasajele irelevante dar apropiate semantic distrag modelul. Metoda corectă e empirică: pornești mic, măsori pe setul tău de întrebări și crești până când câștigul dispare.

Cum fac modelul să spună „nu știu” fără să refuze prea des?

Prin praguri explicite și calibrare, nu prin instrucțiuni în prompt. Pui un prag pe scorul de retrieval, o verificare de suficiență a pasajelor și o verificare a răspunsului generat, apoi ajustezi pragurile pe un set de întrebări unde știi care ar trebui să primească răspuns și care nu. Fără setul acela, orice prag e ghicit.

Merită să forțez răspunsul în JSON?

Depinde de ce faci cu el. Pentru randare într-o interfață, structura ajută. Pentru sarcini care cer raționament, constrângerea strictă de format poate degrada calitatea, așa că lasă modelul să formuleze liber într-un câmp inițial și structurează după. Ordinea câmpurilor în schemă e o decizie de conținut, nu de serializare.

Cum tratez cazul în care două documente se contrazic?

Arăți contradicția în răspuns și explici ce a câștigat și de ce (de obicei documentul mai recent sau cel cu autoritate mai mare). Ascunderea conflictului dă un răspuns care pare curat până când cineva găsește celălalt document — și atunci pierzi încrederea în tot sistemul, nu doar în răspunsul acela.

Ce metadate ar trebui să însoțească fiecare pasaj?

Minimul util: un identificator scurt și stabil pentru citare, titlul documentului, secțiunea, data ultimei actualizări și link-ul canonic către locul exact. Data permite aplicarea unei reguli de precedență, iar link-ul către secțiune, nu către document, e diferența dintre o verificare de cinci secunde și una de cinci minute.

Dacă ai deja un sistem RAG care recuperează bine și răspunde prost, ultimul metru e locul unde se recuperează cel mai mult cu cel mai puțin efort. Vezi cum arată abordarea completă pe linia de servicii AI și RAG sau pornește de la o singură întrebare la care sistemul tău răspunde nesatisfăcător și urmărește-o de la pasaje la text livrat.