Vai al contenuto
Liguori
§ 00 | GIOVANNI
Costruisco automazioni AI con Claude per PMI e freelancer italiani. 21 sistemi in produzione, zero dipendenti, 60+ ore/mese risparmiate. Stack: Python, GCP.
ACCEPTING NEW CLIENTS
Risorse · DM · EVALS

Come costruire una suite di evals per il tuo sistema AI

97 casi deterministici + 28 LLM judge: il metodo per misurare che i tuoi prompt funzionano ancora dopo ogni modifica. Runner in locale, zero infrastruttura.

Commenta EVALS sotto il reel|30 luglio 2026|Giovanni Liguori
Contenuto assistito da AI

Il problema

Hai un prompt che funziona. Lo modifichi. Come sai che non hai rotto niente?

La risposta onesta è: non lo sai, finché non misuri.

Questo è il problema che risolve una suite di evals. Non è roba da big tech. È un file di casi attesi e un runner.

Cosa sono le evals

Un eval è semplice: un input noto + un output atteso. Se il sistema produce l'output atteso, il test passa.

Due tipi:

  1. Deterministico: l'output è una stringa esatta, un JSON strutturato, un valore booleano. Non c'è giudizio. Passa o non passa.
  2. LLM-judge: l'output è testo libero che un modello AI valuta secondo criteri definiti da te. "Questa risposta rispetta il tono?" "Contiene il dato numerico richiesto?" Hai più latenza, ma catturi casistiche che il deterministico non vede.

Il metodo in 4 passi

  1. Identifica i punti critici del tuo sistema: i prompt che governano output pubblicati, gate di qualità, decisioni binarie.
  2. Per ogni punto critico, scrivi 5-10 casi attesi. Usa input reali che hai già visto in produzione, non inventati.
  3. Scegli il tipo di eval: deterministico se l'output è preciso, LLM-judge se l'output è aperto ma ha criteri valutabili.
  4. Crea una regola bloccante: verde prima e verde dopo ogni modifica. Se un caso passa da verde a rosso, non applicare la modifica finché non capisci perché.

Come gira il mio runner

Uno script Node.js che legge un file JSON con i casi, chiama il sistema per ogni input, confronta l'output, e stampa il risultato. Gira in locale, senza chiave API dedicata.

[
  {
    "input": "Analizza questo testo e restituisci il topic principale in una parola",
    "context": "Il backup notturno copia i file su un disco esterno",
    "expected": "backup",
    "type": "deterministic"
  },
  {
    "input": "Scrivi una caption per il reel di oggi",
    "context": "Topic: pipeline CI/CD automatizzata",
    "criteria": "La prima riga contiene un numero. Niente em-dash. Voce diretta.",
    "type": "llm-judge"
  }
]

Il runner legge ogni caso, esegue il prompt, confronta l'output con l'expected (deterministici) o lo passa al giudice (LLM-judge), e accumula i risultati.

La regola bloccante

Nel mio sistema la regola è esplicita nei file di istruzioni: verde prima e verde dopo ogni modifica a prompt e gate di contenuto.

Stamattina ho usato questo output per tagliare il 35 percento del file istruzioni del sistema AI. 125 casi, 0 mismatch prima. 125 casi, 0 mismatch dopo. La riduzione è avvenuta in sicurezza.

Senza evals, lo stesso taglio sarebbe stato un atto di fede.

Da dove iniziare

Se il tuo sistema ha anche solo un prompt che tocca un output pubblicato, inizia da lì. 5 casi deterministici, uno script di 50 righe, una regola bloccante. Poi cresci.

Non devi avere 125 casi dal primo giorno. Devi avere la regola: verde prima, verde dopo.

Come costruire una suite di evals per il tuo sistema AI | Giovanni Liguori