Passa al contenuto principale

Valutare la Qualità dell'AI (Evals)

Avanzato
What you'll learn
  • Costruire la eval minima utile — un golden set di 20–100 input reali con criteri di superamento chiari
  • Scegliere la metrica giusta per task: check deterministici, LLM-as-judge o revisione umana
  • Far girare le eval come un gate — prima/dopo ogni modifica al prompt, cambio di modello, e in CI
  • Punteggiare ogni stage (retrieval, chiamata tool, risposta finale), non solo l'ultimo, per localizzare le regressioni

Se rilasci qualcosa costruito sull'AI, le eval sono il modo in cui sai che funziona — e il modo in cui sai che un cambiamento l'ha migliorato, non peggiorato. Senza vai alla cieca: un tweak del prompt che aiuta un caso può silenziosamente rompere altri dieci. Le eval trasformano l'iterazione "a naso" in un loop misurabile.

La eval minima praticabile​

Non ti serve un framework per iniziare. Tutto il loop sta in quattro passi:

Guided walkthrough1 of 4
  1. 20–100 input reali con gli output corretti o accettabili (o criteri chiari per cosa conta come pass). Copri i casi facili, quelli complicati e gli edge case che ti hanno già morso in produzione.

Scegliere le metriche​

Non ogni domanda merita lo stesso test. Abbina la metrica al task:

Tipo di taskMetricaCostoAffidabilità
Output strutturato (JSON, SQL)Validazione dello schema, match esattoGratisAlta
Generazione di codiceFai girare i test che ha scrittoBassoAlta
Estrazione (date, entità)String contains / regexGratisAlta
ClassificazioneAccuracy, precision, recallGratisAlta
Riassunti, draft, tonoLLM-as-judge con una rubricaModeratoMedia — va calibrata
Scrittura ad alto rischio, sicurezzaRevisione umana su una fettaCostosoMassima

Tre regole pratiche:

  • Check deterministici quando possibile. Se la risposta è "JSON valido conforme a questo schema" o "il codice passa questi test", non chiederlo a un LLM — controllalo e basta.
  • LLM-as-judge per la qualità sfumata. Utilità, tono, aderenza-alla-fonte. Economico, veloce, ma ha bias (lunghezza, posizione, self-preference). Valida il judge contro rating umani su un campione prima di fidarti dei suoi numeri.
  • Umani sulla fetta a rischio più alto. Anche 10 casi gradati da umani per release batte 0.

Rubrica di partenza per LLM-as-judge

You are grading assistant responses against a source document.

For each response, output a JSON object with these fields:
- grounded: true if every factual claim is supported by the source, else false
- complete: true if the response answers all parts of the question, else false
- concise: true if the response contains no filler or repetition, else false
- overall_score: 1-5 (1 = unusable, 5 = ship it)
- reasoning: one sentence explaining the score

Do not consider length. Do not consider whether the response comes first or second.

<source>{{SOURCE}}</source>
<question>{{QUESTION}}</question>
<response>{{RESPONSE}}</response>

Return only the JSON, no preamble.

Quando farle girare​

  • Prima/dopo ogni cambio di prompt o modello. Senza eccezioni. Il punto del golden set è proprio intercettare il cambiamento che pensavi fosse sicuro.
  • Sulla migrazione di modello. I nuovi modelli spostano il comportamento — a volte silenziosamente. Fai girare le eval prima di cambiare l'ID del modello. Vedi Errori & Migrazione.
  • In CI, per i sistemi in produzione. Trasforma una eval verde in un merge gate. Le regressioni vengono intercettate prima che gli utenti le vedano.
  • Dopo ogni bug segnalato. Aggiungi il caso fallito al golden set. Il set cresce insieme al sistema.

Punteggia ogni stage, non solo la risposta finale​

Per RAG e agenti, un singolo punteggio "risposta finale" nasconde dove le cose si rompono. Punteggia ogni stage separatamente così le regressioni cadono in un solo posto:

StageCosa controllare
RetrievalI top-k includevano il doc che contiene la risposta?
Selezione del toolL'agente ha scelto il tool giusto per questo turno?
Argomenti del toolGli argomenti erano ben formati e corretti?
Risposta finaleCorrisponde ai criteri golden?

Quando il punteggio del retrieval cala ma quello della risposta finale tiene, sai che è una regressione del retrieval — non un problema di prompt. Questo tipo di localizzazione è ciò che rende le eval davvero utili per il debug, non solo per il punteggio.

Errori comuni​

  • Gradare con lo stesso modello che ha generato la risposta. Il bias di self-preference gonfia i punteggi. Usa un modello diverso — o meglio, una famiglia diversa — come judge.
  • Prompt di judge che rivelano la risposta "giusta". Se il judge vede la risposta gold, troverà motivi per premiare chi le somiglia. Giudica sui criteri, non sulla somiglianza.
  • Golden set congelati al giorno uno. Il set dovrebbe crescere ogni volta che la produzione ti sorprende. Un set stantio misura il passato.
  • Ottimizzare per la eval invece che per il task. Se tuni i prompt su un set piccolo finché ogni caso passa, potresti aver fatto overfit. Tieni ~20% dei casi come slice di validazione che non guardi mai durante l'iterazione.

Verifica te stesso

0/4
  1. Qual è la eval minima praticabile?
  2. Quando dovresti preferire un check deterministico rispetto a LLM-as-judge?
  3. Per un agente RAG, perché punteggiare ogni stage separatamente?
  4. Qual è un red flag che hai fatto overfit al tuo set di eval?
Key takeaways
  • 20–100 input reali + criteri di pass + una variabile alla volta = un loop di eval funzionante.
  • Deterministico > LLM-judge > umano — scegli la metrica più economica che il task consente.
  • Punteggia ogni stage in una pipeline, non solo la risposta finale.
  • Il golden set cresce con ogni bug segnalato. Un set stantio misura il passato.

Prossimi passi​