Cum evaluezi un sistem RAG: metrici de retrieval și de generare

Ai schimbat embedding-ul, ai mai adăugat câteva documente în corpus, ai rescris promptul de sistem. Rulezi câteva întrebări, citești răspunsurile și ai senzația că „pare mai bine". Dai deploy. Două săptămâni mai târziu, un client îți trimite un screenshot cu un răspuns inventat, sigur pe el, despre o funcție care nu există.

Problema nu e că ai greșit modificarea. Problema e că nu aveai cum să știi dacă a ajutat sau a stricat ceva, fiindcă singura ta metrică era impresia de moment. Un sistem RAG fără evaluare e un sistem pe care îl optimizezi pe ghicite. Acest articol e despre cum înlocuiești senzația cu numere: ce măsori la retrieval, ce măsori la generare, cum construiești un set de referință și cât de mult poți să te bazezi pe un alt model care îți notează răspunsurile.

Dacă încă te lămurești cu mecanica de bază — ce este un pipeline RAG și cum circulă datele prin el — pornește de la ghidul despre ce este RAG și revino aici. De aici încolo presupun că ai deja un sistem care întoarce ceva și vrei să afli cât de bun e acel ceva.

De ce „pare mai bine" nu e o metrică

Evaluarea pe baza câtorva întrebări alese manual e atrăgătoare fiindcă e gratis și rapidă. E și înșelătoare din trei motive concrete.

Primul e selection bias. Întrebările pe care le testezi sunt cele la care te gândești tu, iar tu te gândești la cazurile pe care le înțelegi deja. Cazurile care strică sistemul sunt exact cele care nu-ți trec prin cap — formulări ciudate, întrebări la care răspunsul nu există în corpus, cereri care ating două documente simultan.

Al doilea e că impresia nu prinde regresiile. Ai îmbunătățit răspunsul la întrebarea A și ai stricat răspunsul la întrebarea B, dar tu te uitai la A. Fără un set fix rulat de fiecare dată, fiecare schimbare e o monedă aruncată în aer pe care nu o vezi cum cade.

Al treilea e că „pare mai bine" nu e comparabil. Nu poți pune două variante una lângă alta și să spui cât de departe sunt. Nu poți urmări un trend. Nu poți pune un prag dincolo de care dai drumul în producție. O metrică, prin definiție, e un număr pe care îl poți compara cu el însuși de săptămâna trecută.

Multe dintre eșecurile catalogate în articolul despre de ce eșuează RAG în producție trec nedetectate luni de zile tocmai fiindcă echipa nu avea un număr care să scadă vizibil când lucrurile se stricau.

Separă cele două întrebări: retrieval vs. generare

Cea mai utilă mișcare pe care o faci în evaluarea RAG e să nu mai tratezi sistemul ca pe o cutie neagră care primește o întrebare și scoate un răspuns. Sunt două subsisteme, cu moduri de eșec diferite și cu remedii diferite.

Retrieval-ul răspunde la întrebarea: am adus în context bucățile potrivite? Generarea răspunde la întrebarea: având bucățile aduse, modelul a produs un răspuns corect și ancorat în ele? Dacă măsori doar răspunsul final și e prost, nu ai cum să știi pe cine să dai vina. Poate retrieval-ul a adus gunoi și modelul s-a descurcat onorabil cu el. Poate retrieval-ul a adus exact ce trebuia și modelul tot a halucinat.

Distincția asta e și modul în care gândesc framework-urile mature de evaluare. În documentația RAGAS, de pildă, metricile sunt împărțite explicit: context precision și context recall măsoară retriever-ul, iar faithfulness și answer relevancy măsoară generatorul. Le tratezi separat fiindcă o intervenție care repară una nu o atinge pe cealaltă — schimbi strategia de chunking și miști retrieval-ul, schimbi promptul și miști generarea.

Metrici de retrieval

Retrieval-ul e, în fond, o problemă de căutare: dintr-un corpus, sistemul întoarce o listă ordonată de k bucăți, iar tu vrei să știi cât de bună e acea listă. Metricile clasice din information retrieval se aplică direct, cu condiția să ai un set în care știi care bucăți sunt cu adevărat relevante pentru fiecare întrebare.

Recall@k

Recall@k întreabă: din toate bucățile relevante care există în corpus pentru întrebarea asta, câte au ajuns în primele k rezultate? E cea mai importantă metrică de retrieval pentru RAG, fiindcă reprezintă plafonul a tot ce urmează. Dacă bucata cu răspunsul nu e în context, niciun model, oricât de bun, nu poate produce răspunsul corect — cel mult îl poate inventa. Un recall@k scăzut îți spune că problema e la retrieval și că degeaba mai reglezi promptul.

Precision@k

Precision@k întreabă invers: din cele k bucăți pe care le-ai întors, câte sunt efectiv relevante? E despre zgomot. Un context plin de bucăți irelevante costă bani (mai mulți tokeni de procesat) și degradează calitatea răspunsului, fiindcă modelul trebuie să ignore activ distragerile. Recall și precision sunt în tensiune: dacă mărești k, recall-ul crește aproape mereu, dar precision-ul de obicei scade. Alegerea lui k e exact negocierea dintre „am adus suficient" și „nu am adus prea mult gunoi".

MRR

Mean Reciprocal Rank se uită la poziția primei bucăți relevante și calculează 1 împărțit la acea poziție, mediat peste toate întrebările. Dacă bucata bună e prima, scorul e 1; dacă e a cincea, e 0.2. MRR e metrica potrivită când îți ajunge un singur chunk bun ca să răspunzi — cazul tipic al întrebărilor factuale, cu un răspuns precis. Îți spune nu doar dacă ai găsit ceva relevant, ci cât de sus l-ai pus.

NDCG

Normalized Discounted Cumulative Gain e cea mai sofisticată dintre cele patru. Ține cont de două lucruri pe care celelalte le ignoră: că relevanța poate fi graduală (o bucată e exact ce trebuie, alta e doar tangențial utilă) și că poziția contează, cu un discount care scade pe măsură ce cobori în listă. Folosești NDCG când ordinea efectivă a rezultatelor are importanță și când ai etichete de relevanță mai fine decât simplul „relevant / irelevant".

Pe scurt, ca să nu te pierzi: recall@k e metrica ta principală, semnalul că răspunsul e măcar prezent în context. Precision@k o folosești ca să ții zgomotul și costul sub control. MRR și NDCG intră în joc când ordonarea rezultatelor — nu doar prezența lor — afectează calitatea răspunsului final.

Metrici de generare

Presupunem acum că retrieval-ul și-a făcut treaba și ai bucățile potrivite în context. A doua întrebare e dacă modelul le-a folosit cum trebuie. Aici metricile nu mai vin din information retrieval, ci sunt evaluări semantice ale textului generat — de regulă calculate cu ajutorul unui alt model, despre care vorbim mai jos.

Faithfulness (groundedness)

Faithfulness măsoară ce proporție din afirmațiile dintr-un răspuns pot fi verificate direct în contextul care i-a fost dat modelului. Se descompune răspunsul în afirmații individuale și se verifică fiecare față de bucățile aduse: dacă toate sunt susținute de context, scorul e maxim; fiecare afirmație nesusținută îl trage în jos. E metrica ta directă împotriva halucinațiilor — răspunde la „a inventat modelul ceva ce nu scrie în surse?".

Aici e capcana pe care o ratează multă lume. Faithfulness nu măsoară dacă răspunsul e corect. Măsoară dacă răspunsul e ancorat în contextul primit. Dacă retrieval-ul a adus o bucată greșită și modelul a rezumat-o fidel, vei avea un faithfulness ridicat la un răspuns complet greșit. De-asta nu poți evalua doar generarea: un scor de groundedness bun pe un retrieval prost e o capcană care te liniștește exact când n-ar trebui. Corectitudinea factuală vine din combinația dintre un retrieval bun (răspunsul e în context) și un faithfulness bun (modelul s-a ținut de context).

Answer relevance

Answer relevance verifică dacă răspunsul chiar adresează întrebarea pusă, nu o întrebare vecină. Un model poate produce un paragraf perfect ancorat în context, dar care răspunde pe lângă — corect și inutil în același timp. Metrica asta prinde răspunsurile evazive, pe cele care divaghează și pe cele care răspund la o reformulare convenabilă în loc de întrebarea reală.

Context precision și context recall

Aceste două metrici stau la graniță și sunt felul în care framework-urile evaluează retrieval-ul folosind răspunsul de referință în loc de etichete manuale pe bucăți. Context recall verifică dacă tot ce era necesar pentru răspunsul de referință se regăsește în contextul adus — în terminologia RAGAS, e singura metrică de bază care se sprijină pe un ground truth scris de om. Context precision verifică dacă bucățile relevante au fost ordonate sus, penalizând situațiile în care ce era util a fost îngropat sub zgomot. Sunt utile fiindcă îți dau un semnal de retrieval fără să fii nevoit să adnotezi manual ce chunk e relevant pentru fiecare întrebare.

Cum construiești un golden test set

Toate metricile de mai sus au un numitor comun: au nevoie de un set de referință, adesea numit golden test set sau golden dataset. E fundația pe care stă tot restul, iar calitatea evaluării tale nu poate depăși calitatea acestui set.

Fiecare exemplu din set are trei părți: întrebarea, bucata-țintă (chunk-ul din corpus care conține efectiv răspunsul) și răspunsul de referință (formularea corectă, validată de cineva care cunoaște domeniul). Cu cele trei poți calcula deopotrivă metrici de retrieval — bucata-țintă a ajuns în top k? — și metrici de generare — răspunsul produs se potrivește cu cel de referință?

Câteva reguli care fac diferența între un set util și unul decorativ: Pleacă de la întrebări reale. Cea mai bună sursă sunt logurile de producție și tichetele de suport — întrebări pe care le-au pus oameni adevărați, cu formulările lor reale, nu variante curate inventate la birou. Întrebările sintetice au tendința să fie prea politicoase și prea bine formulate față de ce primești în realitate.

Include cazurile grele deliberat. Un set care conține doar întrebări ușoare îți dă scoruri bune și o falsă liniște. Bagă reformulări ambigue, întrebări care cer informație din mai multe documente și — esențial — întrebări la care răspunsul nu există în corpus. Sistemul ar trebui să spună „nu știu", iar setul tău trebuie să verifice că o face în loc să inventeze. Aceste exemple negative sunt cele care prind cele mai periculoase halucinații.

Pune un om care știe domeniul să valideze răspunsurile de referință. Dacă răspunsul „corect" e scris de cineva care nu înțelege subiectul, măsori conformitatea cu o eroare. Pe domenii reglementate sau tehnice, asta nu e opțional.

Începe mic și crește. Cincizeci până la o sută de exemple bine alese sunt deja suficiente ca să prinzi regresii majore și să compari variante. Nu aștepta setul perfect de o mie de întrebări ca să începi — un set mic rulat constant bate un set mare care nu există încă. Adaugă în el de fiecare dată când producția scoate la iveală un mod de eșec nou: așa setul crește exact în direcția în care sistemul te doare.

Setul ăsta nu e o investiție unică. Pe măsură ce corpusul se schimbă, unele răspunsuri de referință devin caduce și trebuie întreținute, altfel evaluezi sistemul de azi cu adevărul de acum șase luni.

LLM-as-judge și capcanele lui

Pentru metricile semantice — faithfulness, answer relevance, potrivirea cu răspunsul de referință — ai nevoie de cineva care să citească textul și să dea un verdict. La scară, acel cineva e tot un model, pus să joace rolul de judecător. Abordarea se numește LLM-as-judge și e coloana vertebrală a evaluării automate moderne, dar are limite pe care trebuie să le cunoști înainte să te bazezi orbește pe ea.

Vestea bună: funcționează surprinzător de bine. Studiul lui Zheng și colegii, cel care a introdus MT-Bench și Chatbot Arena, a arătat că un judecător puternic precum GPT-4 ajunge la peste 80% acord cu preferințele exprimate de evaluatori umani — un nivel comparabil cu acordul dintre doi oameni diferiți, care în datele lor era în jur de 81%. Cu alte cuvinte, un model bun nu e mai în dezacord cu tine decât e un alt om.

Vestea proastă: judecătorul are prejudecăți sistematice, documentate.

Position bias. Când compari două răspunsuri, modelul tinde să-l prefere pe primul indiferent de conținut. În studiul citat, această preferință pentru prima poziție urca până spre 75% în anumite condiții, iar verdictul se schimba pe o bună parte din cazuri doar prin inversarea ordinii. Mitigarea standard: evaluează fiecare pereche în ambele ordini și păstrează doar verdictele consistente. Costă dublu la apeluri, dar nu e opțional dacă vrei cifre în care să ai încredere.

Verbosity bias. Judecătorii tind să prefere răspunsurile mai lungi, chiar când lungimea în plus nu aduce informație. Dacă nu controlezi pentru asta în rubrica de evaluare, ajungi să optimizezi sistemul către răspunsuri stufoase. Remediul e să ceri explicit judecătorului să penalizeze redundanța și să trateze concizia ca pe o calitate.

Self-preference (self-enhancement). Un model are tendința să-și prefere propriul stil de scriere, deci un judecător din aceeași familie cu generatorul îl poate favoriza nedrept. Estimările acestui efect merg, în diverse analize, în zona a 10–25%. Mitigarea: folosește un judecător dintr-o altă familie de modele decât generatorul, sau pune mai mulți judecători să voteze și ia consensul.

Concluzia practică nu e să renunți la LLM-as-judge, ci să nu-l tratezi niciodată ca pe singurul semnal de adevăr. Calibrează-l periodic față de un eșantion notat de oameni: dacă judecătorul automat și cel uman se mișcă în aceeași direcție, te poți baza pe el între calibrări.

Mai e și chestiunea costului, fiindcă fiecare exemplu evaluat înseamnă apeluri în plus către un model. La prețurile publice OpenAI din 2026, un judecător puternic precum GPT-4.1 costă în jur de $2 la milionul de tokeni de input și $8 la milionul de output; un model mic, suficient pentru verificări simple, precum GPT-4o mini, stă la circa $0.15 input și $0.60 output — o diferență de peste zece ori. Dacă rulezi evaluarea în ambele ordini, cu mai mulți judecători, pe un set care crește, costul devine o linie reală de buget. O strategie pragmatică e să folosești modelul ieftin pentru verificările de rutină din pipeline și să rezervi judecătorul scump pentru rundele de calibrare și pentru cazurile incerte. Dacă vrei o imagine completă a costurilor unui sistem RAG, o găsești detaliată separat în cât costă un sistem RAG.

Evaluare offline vs. online

Tot ce ai citit până aici ține de evaluarea offline: rulezi sistemul pe golden set-ul fix, înainte de deploy, ca să prinzi regresii și să compari variante. E plasa ta de siguranță și locul unde iei deciziile de „dau drumul sau nu".

Evaluarea online e celălalt picior: măsori sistemul pe trafic real, în producție. Aici nu mai ai răspunsuri de referință pentru fiecare interogare, așa că te bazezi pe alte semnale — feedback explicit de la utilizatori (thumbs up/down), semnale implicite (a reformulat utilizatorul întrebarea imediat? a abandonat?), și eșantioane de conversații reale trecute printr-un judecător automat. Offline-ul îți spune dacă o schimbare e sigură de lansat; online-ul îți spune ce se întâmplă cu adevărat când o lansezi, pe distribuția reală de întrebări pe care niciun set de test nu o acoperă complet.

Cele două se hrănesc reciproc. Eșecurile descoperite online devin exemple noi în golden set-ul offline, iar setul offline devine treptat o reflexie tot mai fidelă a realității din producție.

Ce prag e „suficient de bun"

Întrebarea care revine mereu: ce valoare de recall sau de faithfulness înseamnă că sistemul e gata? Răspunsul incomod e că nu există un prag universal, iar oricine îți vinde unul ignoră contextul tău.

Pragul corect e o funcție de costul erorii în domeniul tău. Un asistent intern care ajută echipa să găsească documentație tolerează un faithfulness mai relaxat — dacă greșește ocazional, un coleg observă și corectează. Un sistem care răspunde clienților despre clauze contractuale sau dozaje nu are același lux: o singură halucinație ancorată convingător poate însemna răspundere legală. Acolo pragul de groundedness trebuie să fie aproape de maxim, iar comportamentul de „nu știu" la întrebări fără acoperire în corpus devine nenegociabil.

În loc să urmărești o cifră absolută, fixează o linie de bază măsurată azi și urmărește trendul. Întrebarea utilă nu e „e recall-ul 0.8 bun?", ci „e mai bun sau mai prost decât săptămâna trecută, și se apropie de pragul pe care l-ai legat de costul erorii tale?". O metrică ce scade e un semnal de acțiune indiferent de valoarea ei absolută.

Cât despre instrumente, peisajul de framework-uri de evaluare e bogat și în continuă mișcare — RAGAS, DeepEval, TruLens, Arize Phoenix sau LangSmith acoperă, fiecare cu accentele lui, exact metricile discutate aici. Niciunul nu e obligatoriu și niciunul nu te scutește de partea grea, care rămâne golden set-ul și calibrarea umană. Alege-l pe cel care se integrează curat în stack-ul tău; dacă vrei să vezi cum arată evaluarea legată direct de o implementare concretă, ai un pipeline întreg descris în RAG cu Next.js și Vercel AI SDK. Instrumentul contează mult mai puțin decât disciplina de a rula evaluarea de fiecare dată, pe un set care reflectă realitatea.

Întrebări frecvente

Care e cea mai importantă metrică pentru un sistem RAG?

Dacă ar fi să alegi una singură, recall@k la retrieval. E plafonul întregului sistem: dacă bucata cu răspunsul nu ajunge în context, nimic din ce urmează nu o poate salva. După ce recall-ul e sub control, faithfulness devine prioritatea, fiindcă el guvernează halucinațiile. Cele două împreună acoperă majoritatea modurilor de eșec.

Pot folosi un singur model atât ca generator, cât și ca judecător?

Poți, dar cu prudență, din cauza self-preference bias-ului — un model tinde să-și favorizeze propriul stil. Pentru evaluări în care contează precizia verdictului, folosește un judecător dintr-o altă familie de modele decât generatorul, sau pune mai mulți judecători să voteze și ia consensul. Pentru verificări de rutină în pipeline, riscul e mai tolerabil.

De câte exemple am nevoie în golden set ca să încep?

Cincizeci până la o sută de exemple bine alese sunt suficiente ca să prinzi regresii majore și să compari variante. Calitatea și diversitatea exemplelor contează mai mult decât numărul — un set mic cu cazuri grele reale bate un set mare de întrebări ușoare. Crește-l incremental, adăugând fiecare mod de eșec nou pe care îl scoate la iveală producția.

Faithfulness ridicat înseamnă că răspunsul e corect?

Nu. Faithfulness măsoară doar dacă răspunsul e ancorat în contextul primit, nu dacă acel context era corect. Un model care rezumă fidel o bucată greșită va avea faithfulness ridicat la un răspuns greșit. Corectitudinea vine din retrieval bun plus faithfulness bun, niciodată din faithfulness singur.

Care e diferența dintre evaluarea offline și cea online?

Offline rulezi sistemul pe un golden set fix, înainte de deploy, ca să prinzi regresii și să decizi dacă lansezi. Online măsori pe trafic real, în producție, folosind feedback de la utilizatori și eșantioane judecate automat, fiindcă acolo nu ai răspunsuri de referință pentru fiecare interogare. Offline-ul validează schimbarea; online-ul observă efectul ei real.

Trebuie să folosesc un framework de evaluare anume?

Nu. RAGAS, DeepEval, TruLens, Arize Phoenix și LangSmith implementează toate metricile discutate aici, cu accente diferite. Alege-l pe cel care se leagă curat de stack-ul tău. Niciun instrument nu înlocuiește golden set-ul de calitate și calibrarea umană periodică — acolo stă efortul care contează.

Următorul pas

Evaluarea transformă optimizarea unui sistem RAG din ghicit în inginerie: măsori retrieval-ul separat de generare, construiești un set de referință din întrebări reale, folosești un judecător automat calibrat și legi pragul de costul erorii tale. De aici, drumul către producție trece prin doi piloni pe care îi acoperă articolele următoare din serie — securitatea datelor și calitatea efectivă a retrieval-ului la scară.

Dacă vrei să duci sistemul mai departe, vezi toate ghidurile din seria RAG în producție sau explorează abordarea completă a sistemelor RAG și AI cap-coadă.