Note 01 · RAG · Evaluation
Come valutiamo un sistema RAG prima che vada in produzione.
Non mandiamo mai in produzione un sistema RAG senza farlo passare prima dal nostro harness di evaluation. Sette metriche, tre ground-truth set, un report di regressione a ogni cambio di modello o indice. Questa nota descrive cosa misuriamo, come costruiamo i dataset e perché le solite risposte da demo sono ingannevoli.
Ein RAG-System auf Basis von „Demo läuft” zu shippen ist verantwortungslos. Wir messen retrieval-Qualität (recall@5, MRR, hit-rate@k) getrennt von generation-Qualität (faithfulness, groundedness, answer relevance) und tracken beides gegen ein versioniertes Ground-Truth-Set aus echten Kundenfragen. Jeder Commit, der Embeddings, Chunk-Strategie oder den Generator anfasst, läuft automatisch durch das Harness. Regression > 5% blockt den Merge.
1 · Perché la solita demo mente
In ogni demo RAG vengono fatte le stesse tre domande che lo sviluppatore ha usato in fase di build. Funzionano — perché il sistema è stato indirettamente ottimizzato proprio su quelle. Appena un impiegato vero, un avvocato o uno studio medico usa formulazioni diverse, recall e faithfulness crollano.
Lo abbiamo imparato in un primo progetto: un bot interno sembrava brillante nella demo, ma due settimane dopo il rilascio è tornato da noi con il 31% di risposte errate. Da allora la valutazione è una parte obbligatoria del processo.
2 · Le sette metriche
Separiamo rigorosamente „il sistema trova i documenti rilevanti?” (retrieval) da „il sistema risponde fedelmente in base a quei documenti?” (generation). Entrambi gli stadi possono rompersi indipendentemente.
| Stadio | Metrik | Cosa misura | Threshold |
|---|---|---|---|
| Retrieval | recall@5 | Quota di domande in cui il documento corretto è nei top-5 | ≥ 0.92 |
| MRR@10 | Mean Reciprocal Rank — quanto in alto sta il documento giusto | ≥ 0.78 | |
| hit-rate@1 | Top-1 è il documento giusto (per risposte in strict-mode) | ≥ 0.65 | |
| Generation | faithfulness | La risposta è supportata interamente dal contesto recuperato? | ≥ 0.88 |
| answer-relevance | Il sistema risponde davvero alla domanda fatta? | ≥ 0.85 | |
| refusal-rate | Quota di rifiuti corretti su domande senza risposta | ≥ 0.90 | |
| System | latency P95 | Latenza end-to-end dalla richiesta alla risposta finita | ≤ 2.4 s |
Le soglie non sono universali — le calibriamo per ogni use-case. Un sistema di ricerca giuridica ha requisiti di refusal-rate molto più alti di un assistente marketing. L'importante è che i valori siano controfirmati dal cliente prima del primo sprint.
3 · Costruire il ground-truth set
È la parte poco romantica e dispendiosa — e la più importante. Per ogni progetto costruiamo tre set separati:
- Set A — realtà (80–120 domande): da ticket cliente, email, registrazioni di chiamate. Con formulazioni reali, errori di battitura, frasi a metà. Per ogni domanda: la risposta canonica più gli ID dei documenti che la supportano.
- Set B — adversarial (30–50 domande): richieste volutamente fuorvianti o ambigue, domande su informazioni non presenti nel corpus, richieste out-of-scope. Qui conta soprattutto la refusal-rate.
- Set C — regressione (cresce): ogni domanda a cui in produzione si è risposto male una volta finisce qui. Con la risposta corretta. Così vediamo subito se un cambio di modello futuro riporta bug vecchi.
Versioniamo questi set in un repo privato accanto al codice. Se un cliente ci fornisce un documento nuovo che cambia le risposte, aggiorniamo il set. È lavoro. Vale la pena ogni volta.
4 · Die Pipeline
L'harness è un modesto script Python che gira contro la pipeline produttiva (o di staging). Niente framework custom, niente „RAG Eval Studio” — vogliamo codice leggibile, modificabile in 20 minuti.
$ uv run python eval/run.py --set A --tag pre-deploy-2026-05
[1/3] Loading ground-truth set A ............... 104 questions
[2/3] Running pipeline (vllm@l40s, top-k=5) ... ████████ 104/104
[3/3] Computing metrics ........................ done
retrieval/recall@5 ............ 0.943 (Δ +0.012 vs baseline)
retrieval/MRR@10 .............. 0.812 (Δ -0.004 vs baseline)
retrieval/hit-rate@1 .......... 0.683 (Δ +0.021 vs baseline)
generation/faithfulness ....... 0.891 (Δ -0.018 vs baseline)
generation/answer-relevance ... 0.876 (Δ +0.005 vs baseline)
generation/refusal-rate ....... 0.923 (Δ -0.011 vs baseline)
system/latency-p95 ............ 1.94 s (Δ -0.21 s vs baseline)
✓ all thresholds met. Δ-faithfulness within ±0.02 tolerance.
Report written to: eval/reports/2026-05-27-pre-deploy.htmlUn file di report HTML finisce in una cartella che fa parte del repo. A ogni PR che tocca generator o retriever l'harness gira automaticamente — niente merge senza spunta verde.
5 · Cosa probabilmente facciamo male
Ehrlich, weil das nicht gelöst ist:
- Faithfulness mit LLM-as-Judge gemessen ist noisy. Wir verwenden zwei verschiedene Judges (lokales Llama 3.1 + Claude als Zweit-Judge) und nehmen den niedrigeren Score. Wichtig: Der Zweit-Judge läuft ausschließlich auf anonymisierten bzw. synthetischen Eval-Sets — es gehen keine Kundendaten an US-Anbieter. Trotzdem schwanken Werte ±0.03 zwischen Läufen.
- Il set A non è mai abbastanza grande. Cento domande non coprono tutti i casi meno frequenti. Compensiamo con il set C, ma nei nuovi domini restano lacune nelle prime settimane.
- Latenz auf Staging-Hardware ist optimistisch. Wir haben gelernt, P95 immer +30% draufzuschlagen, bevor wir versprochene SLAs gegenüber dem Kunden formulieren.
6 · Perché è decisivo per i settori regolati
Eine Hörgeräte-Klinik kann nicht 31% falsche Auskünfte tolerieren. Ein Anwalt nicht 5% halluzinierte Paragrafen. Eine Industrie-Wartung nicht 10% irreführende Reparaturanweisungen. Für genau diese Kunden bauen wir RAG. Das Eval-Harness ist der einzige Weg, vor dem ersten Live-Anruf zu wissen, ob das System die Anforderung trifft.
Se un fornitore le vende un sistema RAG e non dice nulla su eval, ground-truth o regressione — chieda. Se la risposta resta vaga, cambi fornitore.