Formazione AI e sviluppo su misura · Bergamo, Italia
ITEN
97 casi deterministici + 28 LLM judge: il metodo per misurare che i tuoi prompt funzionano ancora dopo ogni modifica. Runner in locale, zero infrastruttura.
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.
Un eval è semplice: un input noto + un output atteso. Se il sistema produce l'output atteso, il test passa.
Due tipi:
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.
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.
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.