Cum evaluezi corect un sistem RAG: cele 9 metrici esențiale

Un sistem RAG (Retrieval-Augmented Generation) are două componente care pot greși independent. Dacă răspunsul e slab, trebuie să știi care parte e de vină. Acest articol rezumă cele 9 metrici esențiale, le explică vizual și arată cum le implementezi în practică — inclusiv cum le folosim deja într-un sistem real de-al nostru.

De ce ai nevoie de metrici pe DOUĂ axe

Cele două componente ale unui RAG:

1. Retrieval — ce documente/chunk-uri aduce din baza de cunoștințe.
2. Generation — ce răspuns produce modelul din documentele aduse.

De aceea metricile se împart în două familii + una umană:

Diagrama 1 — Unde se aplică fiecare metrică în pipeline

Cum citești diagrama: metricile de RETRIEVAL evaluează ce iese din retriever (înainte de LLM); cele de GENERATION evaluează răspunsul final; Human Evaluation e verdictul uman peste tot.

Familia A — Metrici de RETRIEVAL

1. Context Precision — cât din ce-ai adus e relevant

Precision = chunk-uri relevante recuperate / total chunk-uri recuperate

• Intuiție: puțin zgomot. Dacă aduci 5 chunk-uri și doar 2 sunt relevante → precizie 0,4.
• Mai mare = mai bine. Precizie mică = retrieverul aduce gunoi care distrage LLM-ul.
• Fix când e mică: adaugă un reranker, scade k, filtre pe metadate.

2. Context Recall — ai adus TOT ce era relevant

Recall = chunk-uri relevante recuperate / toate chunk-urile relevante

• Intuiție: acoperire. Dacă existau 3 chunk-uri relevante și ai adus doar 2 → recall 0,67.
• Mai mare = mai bine. Recall mic = retrieverul RATEAZĂ informație → răspuns incomplet.
• Fix când e mică: crește k, îmbunătățește embeddings/chunking, hybrid search (semantic + keyword).

Precision și Recall sunt în tensiune: crești k → recall ↑ dar precision ↓. Reranker-ul le împacă (aduci mult, apoi filtrezi sus).

3. Context Relevance — cât de relevante-s documentele față de întrebare

Verifică, calitativ, dacă documentele recuperate chiar au legătură cu query-ul. Mai mare = mai bine. Implementare: LLM-as-judge dă un scor de relevanță per (query, chunk).

7. Hit Rate (Hit@k) — măcar unul nimerit în top-k

Hit@k = 1 dacă un doc relevant e în top-k, altfel 0.

• Intuiție: binar per query. Media pe tot setul = % din întrebări pentru care retrieverul a nimerit măcar un doc bun în primele k.
• Mai mare = mai bine. Metrică rapidă de „funcționează retrieverul?“.

8. Mean Reciprocal Rank (MRR) — cât de SUS apare primul doc relevant

MRR = (1/N) · Σ (1 / rankᵢ) — unde rankᵢ = poziția primului document relevant pentru query-ul i, iar N = numărul total de query-uri.

• Intuiție: dacă primul doc relevant e pe poziția 1 → 1,0; pe poziția 2 → 0,5; pe poziția 5 → 0,2.
• Mai mare = mai bine. Spre deosebire de Hit@k (doar da/nu), MRR penalizează ranking-ul prost.
• Fix când e mic: reranker, embeddings mai bune, tuning HNSW.

Familia B — Metrici de GENERATION

4. Faithfulness — răspunsul e susținut de context (fără halucinații)

Verifică dacă fiecare afirmație din răspuns este acoperită de contextul recuperat. „No hallucinations.” Mai mare = mai bine.

• Cea mai importantă metrică anti-halucinație. Faithfulness mic = modelul inventează.
• Implementare: LLM-as-judge (compară răspuns vs context) SAU grounding prin embeddings (cosine răspuns↔span sursă).

5. Answer Relevance — răspunsul adresează întrebarea userului

Un răspuns poate fi 100% fidel contextului dar pe lângă subiect. Măsoară cât de bine răspunde la ce a întrebat userul. Mai mare = mai bine. Fix când e mic: îmbunătățește prompt-ul de generare, reformulare query.

6. Answer Correctness — corectitudine factuală față de adevărul de referință

Compară răspunsul cu un ground truth / referință. Mai mare = mai bine. Necesită un set „gold” de răspunsuri corecte. Implementare: LLM-as-judge sau potrivire semantică vs referință.

Familia C — Human Evaluation

9. Human Evaluation — judecata umană

Judecată umană de utilitate, acuratețe și grounding, pe o rubrică:

• Correctness (corect factual)
• Helpfulness (util pentru user)
• Grounding (ancorat în surse)
• Completeness (complet)

Rămâne standardul de aur pentru cazurile ambigue; se face pe un eșantion, nu pe tot.

Diagrama 2 — Taxonomia celor 9 metrici

Cum le implementezi în practică

Unelte: biblioteca ragas (Python) acoperă din cutie Context Precision/Recall, Faithfulness, Answer Relevance, Answer Correctness (LLM-as-judge). Metricile pur de ranking (Hit@k, MRR) le calculezi cu cod simplu peste rezultatele retrieverului.

Cum le facem NOI (implementare reală)

Pipeline-ul nostru de RAG automatizează exact 2 din cele 9 metrici ca poartă de calitate, la scară:

• Retrieval: vector DB (Qdrant) + embeddings (BGE-M3) + reranker → pe un set gold măsurăm Hit@k, MRR, Context Precision/Recall. Reranker-ul e fix soluția pentru Context Precision + MRR mici.
• Faithfulness (metrica 4): pentru fiecare pereche întrebare/răspuns, calculăm cosine similarity ≥ 0,85 între răspuns și span-ul sursă → grounding automat = „No hallucinations”.
• Answer Correctness (metrica 6): un LLM-as-judge (scor ≥ 9 din 10) verifică corectitudinea factuală față de sursă; certificarea finală o dă un judecător mai puternic.

Practic, „datasetul platinum” e construit trecând fiecare exemplu prin Faithfulness + Answer Correctness automatizate — două dintre metricile de mai sus, aplicate la sute de mii de perechi.

Praguri orientative + ce faci când o metrică e mică

Rezumat de reținut

• Evaluezi RAG pe retrieval (aduci ce trebuie?) și generation (răspunzi corect din ce-ai adus?).
• Recall = nu ratezi; Precision = nu aduci gunoi; MRR/Hit@k = ranking bun.
• Faithfulness = fără halucinații (cea mai importantă); Answer Relevance/Correctness = răspuns la subiect și corect.
• Human Evaluation = verdictul final pe un eșantion.
• În producție, automatizezi Faithfulness + Correctness cu LLM-as-judge / grounding și le rulezi pe mii de exemple.