Eval Engineering: il passaggio che trasforma un modello da 200 $ in un sistema da 200.000 $ (guida completa)

Tutti stanno affittando lo stesso cervello ormai.

Il modello che puoi avere per un paio di centinaia di euro al mese è, più o meno, lo stesso modello che sta usando un'azienda con mille ingegneri. Doveva livellare tutto. Invece ha reso il divario tra due team che affittano lo stesso cervello più ampio del divario tra due modelli.

Un'agenzia di viaggi, quella digitale, ha risposto a una domanda su un viaggio: un tasso di cambio con una cifra decimale, la temperatura della settimana, gli orari di apertura di un museo. Specifico, pulito, dall'aria utile. Tutto inventato.

Il tool di ricerca non aveva trovato nulla, e il modello ha tranquillamente riempito il vuoto, spacciando la sua invenzione per un dato verificato.

Poi il team l'ha misurato su 100 sessioni reali e ha ottenuto due numeri che non dovrebbero mai essere così distanti.

Quanto erano buone le risposte: 83,9%.

Quanto di quelle risposte era ancorato a ciò che i tool avevano effettivamente restituito: 32,3%.

L'agente scriveva benissimo e diceva la verità solo un terzo delle volte.

Nessuno se n'è accorto, perché la scrittura era l'unica cosa che la gente guardava.

83,9% di qualità delle risposte contro 32,3% di fedeltà, stessa esecuzione

Stesso agente, stesso giorno: la barra di sinistra è ciò che mostra la demo, la barra di destra è ciò che ottiene realmente un cliente.

Un modello migliore non avrebbe risolto il problema. Manca il livello che decide se una risposta è corretta, e poi fa qualcosa con quel verdetto.

Quel livello è l'intera distanza tra un'AI che impressiona e un'AI che viene pagata. È la componente più economica dell'intero stack e l'unica che nessuno può venderti, perché codifica la tua personale definizione di "corretto".

Questo articolo non è da leggere distrattamente. Tieni aperto un terminale accanto. L'impostazione inizia con un singolo comando che hai già, e finisce in un punto che suona irragionevole: pull request che vengono unite senza che nessuno le legga.

Prima di iniziare, seguimi su X e unisciti al mio canale Telegram dove pubblico più contenuti sull'AI ogni giorno. Sono entrambi gratuiti.

X -

https://x.com/Argona0x Telegram -

https://t.me/+r0clI4-MMC03ZjAy

Cos'è l'ingegneria delle valutazioni

Un'azienda che gestisce agenti in produzione ha detto la verità in una frase. In versioni successive del loro agente hanno cambiato nessun modello, nessun prompt, nessun intervento umano, solo le valutazioni — e i punteggi si sono spostati su ogni dimensione.

Stesso cervello. Esaminatore diverso. Prodotto migliore.

La loro conclusione successiva è stata ancora più diretta: le valutazioni dovevano essere nel sistema dal primo giorno, non dal nono mese.

Un termometro ti dice che la stanza è fredda. Un termostato accende il riscaldamento.

Quasi tutti quelli che costruiscono con l'AI possiedono al massimo un termometro: una dashboard, una sensazione, un venerdì pomeriggio in cui qualcuno scorre gli output e dice che sembra peggio della settimana scorsa.

L'ingegneria delle valutazioni è il cablaggio che va dalla lettura alla caldaia.

← termometro vs termostato, con il verdetto che torna nel grafico

L'intera differenza è la freccia di ritorno a destra: il verdetto torna nel grafico e cambia cosa viene eseguito dopo.

Questo è arrivato in un ordine preciso. Prima è arrivato un agente in un loop, così poteva provare, guardare cosa tornava e riprovare. Poi molti agenti disposti come un grafico, così il lavoro che non dipendeva l'uno dall'altro veniva eseguito in parallelo invece di mettersi in coda.

Loop, poi grafici, poi valutazioni.

https://x.com/Argona0x/status/2080626046903157126

Il grafico è stato l'ultimo aggiornamento che ti ha reso più veloce. Il giudice decide se quella velocità è valsa la pena.

Venti agenti che eseguono contemporaneamente, tutti che riportano a un unico giudice, sono venti volte più posti in cui una risposta sbagliata può sembrare finita.

È anche l'unica parte del sistema che diventa più preziosa ogni settimana che la fai funzionare. Il modello è un noleggio. L'esaminatore è tuo, e ogni fallimento che gli dai rimane lì per sempre.

Il che rende strano il prezzo d'ingresso. L'esaminatore costa quasi nulla da installare, e il modello che esamina costa circa 200 dollari al mese.

Passo 1 · Il motore di valutazione che possiedi già

Presumi che questo inizi con una piattaforma: un contratto, un costo per utente, un trimestre di setup prima del primo numero utile.

Questa supposizione è il motivo per cui la maggior parte delle persone non costruisce mai questo livello, e ha smesso di essere vera circa quattro settimane fa.

Il test alla cieca

1. Due ricercatori hanno fatto il test onesto. Hanno preso 100 tracce di produzione reali da un agente vocale live, hanno fatto segnare ogni fallimento a mano da un esperto umano, hanno costruito una tassonomia di 39 fallimenti etichettati, poi hanno nascosto le etichette e hanno dato la stessa pila a ogni sistema di valutazione sul mercato.

Trovali tu stesso.

La riga interessante non era il vincitore:

1. Braintrust Loop: 87,2% dei fallimenti umani recuperati.
2. Codex su GPT-5.5 High: 84,6% recall, 82,8% precision.
3. LangSmith: 79,5%.
4. Arize AX: 74,4% recall, e la precision più pulita del gruppo con 91,0%.

Un agente di codifica generico, con un abbonamento che già paghi, si è piazzato sopra due piattaforme di valutazione dedicate. Una di loro ha scritto la conclusione in modo chiaro: puoi ottenere risultati simili usando il tuo agente di codifica.

Poi le piattaforme hanno fatto qualcosa di più strano che perdere. Si sono mosse.

In quattro settimane, quattro venditori di valutazione hanno confezionato la loro competenza come una competenza installata nell'agente di codifica di qualcun altro: LangChain il 22 luglio, Galileo, AWS sotto Apache 2.0, e Arize che mette la sua estrazione di tracce in competenze pensate, nelle loro parole, per il tuo agente di codifica preferito.

Nessuno ha contato queste quattro come una singola mossa.

È una categoria che si smembra nel terminale che hai già aperto.

Installare l'esaminatore

Installare tutto richiede tre righe.

1npx skills add langchain-ai/langchain-skills --skill '*' --yes --global
2npx skills add langchain-ai/langsmith-skills --skill '*' --yes --global
3uv tool install evalkit --from git+https://github.com/awslabs/Agent-EvalKit.git

All'interno di Claude Code la stessa cosa si installa come plugin:

1/plugin marketplace add langchain-ai/langchain-skills
2/plugin install langchain-skills@langchain-skills

← esecuzione reale nel terminale: le skill si installano, evalkit init crea la struttura della cartella

Un'esecuzione reale su una macchina reale: le skill arrivano come file globali, e evalkit init crea la struttura della cartella in cui vivrà la tua valutazione.

Due dettagli lì dentro valgono più dei comandi.

1. Due repository, due lavori: langchain-skills costruisce le valutazioni, langsmith-skills recupera le esecuzioni di produzione reali per crearle. Quasi tutti installano il primo, poi si chiedono da dove arrivi il materiale.
2. Non è una funzionalità di Claude Code: quelle skill seguono la specifica delle skill aperte, quindi gli stessi file possono essere caricati in Codex, Cursor, Windsurf e Goose.

Il kit AWS funziona con sei comandi, ognuno è una fase che scrive in una cartella eval/ che la successiva legge:

1evalkit init my-agent-evaluation
2# poi, all'interno del tuo agente di codifica:
3/evalkit.plan Valuta il mio agente in ./my_agent per l'ancoraggio e la precisione degli strumenti
4/evalkit.data
5/evalkit.trace
6/evalkit.run_agent
7/evalkit.eval
8/evalkit.report

L'ultimo comando è quello che vale l'intero setup. /evalkit.report restituisce raccomandazioni prioritarie che puntano a posizioni specifiche nel tuo codice.

L'esaminatore è installato. Ora deve potergli essere permesso di fare qualcosa.

Passo 2 · Fai sì che il punteggio cambi il prossimo bordo

Costruirai la tua prima valutazione, otterrai un numero, lo guarderai e sentirai che non succede nulla.

Quella sensazione è corretta. Un numero in un report non ha un percorso di ritorno all'esecuzione che ha misurato.

Una riga risolve l'intera disciplina, e appartiene a un fondatore ventunenne di Tokyo con 258 follower il cui post su di essa ha ricevuto due like:

Un punteggio che non cambia mai il comportamento è analisi. Una valutazione che cambia il prossimo bordo è ingegneria.

Il suo cablaggio è di sei regole. Ognuna prende un verdetto e fa qualcosa di strutturale all'esecuzione in corso:

1basso recall del contesto   → rifiuta il passaggio di consegne
2cattivo uso degli strumenti → riprova o scambia il nodo
3allucinazione               → metti in quarantena il ramo
4fallimento dello schema      → blocca il bordo
5rischio di conformità        → instrada alla revisione umana
6completamento verificato     → termina l'esecuzione

← sei verdetti, sei azioni strutturali sull'esecuzione in corso

Ognuna di quelle sei è una decisione di instradamento che il grafico esegue. La valutazione guida l'esecuzione in volo, un bordo alla volta.

Regole per il giudice stesso

L'esaminatore ha bisogno della propria igiene, e quasi nessuno imposta correttamente questa parte.

1. Giudica da un'altra famiglia: un modello riconosce la propria scrittura e la valuta con più indulgenza quando lo fa. Un team di valutazione usa Sonnet come giudice per l'output generato da Haiku, apposta. Una riga su X lo dice in meno parole: la stessa famiglia genera e valuta, quindi i punti ciechi sono condivisi.
2. Scrivi la rubrica in una riga: la forma funzionante è letteralmente Passa sse [il risultato di successo indipendentemente osservabile]. Un verdetto primario, mai un insieme di punteggi proxy.
3. Dividi il lavoro per tipo: il giudice decide le chiamate semantiche, il codice semplice decide quelle oggettive. Il test è passato, il file esiste, lo stato è cambiato.
4. Non premiare mai la forma di una risposta: la regola scritta nella competenza vieta di valutare in base alla lunghezza della risposta, alle parole chiave, al numero di citazioni, alla formulazione esatta, al numero di chiamate di strumento o alla somiglianza con un riferimento. Premia la forma e l'agente imparerà la forma.
5. Blocca il giudice e registra la sua versione: un esaminatore che si aggiorna silenziosamente rende ogni punteggio prima e dopo incomparabile, e non te ne accorgerai per un mese. Il blocco della versione è ciò che la gente salta, e ciò che rende un mese di punteggi illeggibili a posteriori.

Ottimizza contro un giudice abbastanza a lungo e l'agente imparerà a sembrare giusto piuttosto che esserlo.

Ora il punteggio ha un posto dove andare. Il prossimo problema è da dove arrivano i buoni test, perché inventarli a una scrivania è il motivo per cui il primo set di tutti è inutile.

Passo 3 · Trasforma un'esecuzione fallita in una valutazione

I test che inventi con l'immaginazione ti proteggono dai fallimenti che hai già immaginato.

Quelli che costano soldi sono seduti nei tuoi log in questo momento, con un timestamp.

L'intero ciclo è lungo cinque passi:

1estrai tracce -> identifica un fallimento -> costruisci una valutazione -> migliora l'agente -> riesegui

Da dove vengono i test

Il primo passo porta tutto il peso. La competenza che lo fa professionalmente nomina quali esecuzioni estrarre, e inizia con 25 tracce complete, non di più, scelte in modo che il buon comportamento e quello cattivo siano uno accanto all'altro:

1. Una richiesta normale che è finita: la tua linea di base per come appare il funzionamento.
2. Una richiesta che l'utente ha confermato: la rara traccia in cui sai che la risposta era buona.
3. Una richiesta che l'utente ha corretto o riformulato: la correzione è l'etichetta, gratis.
4. Un'esecuzione con una chiamata di strumento fallita, vuota o ripetuta: la ripetizione significa un loop, il vuoto significa che sta per arrivare una risposta inventata.
5. Un'esecuzione con un fallimento esterno: un timeout o un limite di velocità, dove l'unica cosa testata è come si comporta il tuo agente quando il mondo dice di no.

Ognuna viene scritta in quattro righe, e questo template è la parte degna di essere rubata:

1Comportamento osservato: cosa ha chiesto l'utente e cosa ha effettivamente fatto l'agente
2Confronto:            cosa ha funzionato e cosa no
3Attribuzione:         comportamento dell'agente, comportamento della dipendenza o non chiaro
4Candidato per la valutazione: la capacità da preservare o migliorare

L'attribuzione è dove i principianti perdono una settimana.

La stessa ricerca chiamata due volte con argomenti identici è un loop nel tuo agente. Un 429 che torna è il limite di qualcun altro, e diventa la tua valutazione solo se il tuo agente avrebbe dovuto riprendersi da esso.

Dal ritrovamento alla cartella

Poi il ritrovamento diventa una cartella, e la cartella è il formato che gli strumenti eseguono:

1evals/<task-id>/
2├── task.toml
3├── instruction.md
4├── environment/
5└── tests/

← 25 tracce → un fallimento → una cartella di attività di Harbor: cosa vede l'agente, cosa rimane nascosto

Una capacità per cartella. L'istruzione e l'ambiente sono visibili all'agente sottoposto a test. Il risultato atteso, la rubrica e le credenziali del giudice non lo sono, e quella separazione è l'unica ragione per cui il punteggio significa qualcosa.

Tre regole fermano i fallimenti che fanno smettere la gente:

1. Non trattare mai la risposta registrata come verità: la traccia ti dice cosa ha fatto il tuo agente, mai cosa avrebbe dovuto fare. Prendi la chiave delle risposte dai test, dai documenti originali, dalle policy, dallo stato noto o da una persona.
2. Testa il test prima di fidartene: dai al verificatore due risultati falsi a mano, uno chiaramente corretto e uno plausibile ma sbagliato. Se uno dei due va nella direzione sbagliata, la rubrica è rotta, non l'agente.
3. Controlla che l'ambiente non stia dando la risposta: se il setup fornisce il risultato prima che l'agente raggiunga lo strumento che doveva usare, il compito passa per sempre e non misura nulla.

Tutto ciò che costa denaro o scrive in produzione viene simulato piuttosto che chiamato, così la suite viene eseguita tutte le volte che vuoi senza una fattura.

Un'istruzione avvia tutto, nell'agente che hai già aperto:

1Usa la competenza di ingegneria delle valutazioni.
2
3Analizza l'agente di questo repository: punto di ingresso, strumenti, dati di supporto e come appare un buon risultato.
4Poi leggi le 25 tracce in ./traces e proponi due o tre candidati per la valutazione basati su ciò che è effettivamente fallito lì.
5
6Raccomandane uno. Non implementare finché non scelgo io.
7Costruiscilo come un'attività di Harbor sotto evals/, tieni la rubrica e il risultato atteso nascosti al target, e testa il verificatore su un risultato positivo e uno negativo plausibile prima dell'esecuzione reale.

Il passo del colloquio è deliberato. Il team che ha scritto la competenza ha scoperto che fare domande all'utente batte la generazione una tantum ogni volta, per la semplice ragione che la definizione di corretto vive nella tua testa e da nessuna parte nel modello.

Eseguilo un paio di volte e ogni fallimento smette di essere un incidente e diventa un test permanente.

Passo 4 · Lascia che il grafico unisca il suo stesso lavoro

Ogni pull request che un agente apre finisce nello stesso posto: una coda umana.

Diventi il collo di bottiglia della tua stessa automazione, e la flotta che hai costruito funziona alla velocità di un revisore stanco.

La via d'uscita non assomiglia per niente a fidarsi di più del modello. Quando un agente apre una pull request, quattro segnali sono già disponibili, e un punteggio di confidenza viene calcolato da essi sul momento:

1. Risultato dei Guardrails: un passaggio o fallimento deterministico sugli standard bloccanti. Nessun modello coinvolto.
2. Traiettoria recente delle valutazioni: come ha ottenuto punteggi questa versione esatta di questo agente ultimamente.
3. Tasso storico di rollback: quanto spesso il lavoro di questo agente, su questo repository, su questa classe di modifica, è stato ripristinato in precedenza.
4. Risultato del sandbox: è stato eseguito.

Sopra la soglia si unisce da solo. Sotto, un umano lo riceve con il segnale fallente nominato, così la revisione inizia dal problema invece che dalla riga uno.

← quattro segnali → un punteggio di confidenza → si unisce da solo, o viene instradato a un umano

Tre di quei quattro sono cronologia e controlli deterministici, e esattamente uno di loro tocca il modello.

La fiducia in un agente è un calcolo attuariale.

Quello che stai costruendo è una cronologia dei risultati con un prezzo, allo stesso modo in cui un assicuratore ne costruisce una, e diventa più nitida ogni settimana che i modelli migliorino o meno.

Come appare quando funziona

Alla stessa azienda che non ha cambiato altro che le sue valutazioni, 19 pull request su 20 sull'agente completamente autonomo vengono unite senza coinvolgimento umano.

Tra i migliori agenti, circa tre quarti del lavoro unito entra senza una singola modifica umana, il tasso di rollback rimane a una cifra bassa, e solo i Guardrails respingono una pull request su cinque prima che una persona la veda mai.

Qualcuno che usa questo modello sui suoi repository personali lo ha messo in un modo che nessun venditore farebbe:

Negli ultimi 90 giorni, ho approvato e unito circa 1.500 pull request. Non ho guardato una riga di codice. Come posso riporre così tanta fiducia negli agenti? Non mi fido affatto di loro. Non mi fido nemmeno della mia capacità di fare code review del loro lavoro. Ma mi fido della mia capacità di vincolare il loro lavoro.

Il vincolo è il prodotto.

E l'avvertimento che vale più della formula viene da un team che ha eseguito 285 iterazioni di un codebase auto-migliorante e ne è uscito con 1.094 pull request unite e zero regressioni.

La loro stessa frase è quella da tenere a mente: 38 test verdi coesistevano con un prodotto completamente rotto.

Una suite può diventare tutta verde mentre il prodotto che protegge cade a pezzi, ecco perché il ciclo deve convergere sulle specifiche piuttosto che sul punteggio.

Attivalo nel modo cauto:

1. Eseguilo prima in modalità ombra: il gate valuta ogni pull request e non ne unisce nessuna, per almeno 4 ore di traffico reale.
2. Imposta una soglia di deviazione del 2%: se il verdetto automatico e il verdetto umano discordano più di questo, il gate rimane chiuso.
3. Campiona le tracce all'1-5%: la cattura completa di tutto è un costo che non devi sostenere.

Un team di due persone in cui ogni modifica scritta dall'agente aspetta un revisore può gestire all'incirca tanto lavoro quanto quel revisore può leggere.

Con il gate chiuso sulla parte rischiosa e aperto sul noioso 80%, le stesse due persone iniziano a fare preventivi per i contratti che prima rifiutavano.

La bolletta del modello non si muove. Tutto il resto sì.

Passo 5 · Le valutazioni da costruire questa settimana

Una suite troppo lenta o troppo vaga non viene mai eseguita, quindi questa è la parte da salvare.

Inizia con tre misurazioni, non dodici. Le tre che hanno smascherato l'agenzia di viaggi sono un valore predefinito funzionante per qualsiasi agente che chiami strumenti:

1. Fedeltà: la risposta è ancorata a ciò che gli strumenti hanno effettivamente restituito. Questa è quella che era al 32,3% mentre ogni altro numero sulla dashboard sembrava a posto.
2. Accuratezza dei parametri dello strumento: strumento giusto, argomenti giusti.
3. Qualità della risposta: l'output è coerente e utile per la persona che ha chiesto.

Se il tuo agente produce codice, valuta la modifica invece. Le cinque dimensioni usate in produzione su ogni pull request: intenzione e decisione, esecuzione e artefatto, completezza e utilità, istruzione e confine, efficienza.

Scegli il tipo di dataset apposta. Ne esistono quattro: final_response per la sola risposta, single_step per una decisione isolata, trajectory per l'intero percorso che l'agente ha fatto, e RAG per la qualità del recupero.

Valutare solo la risposta finale è il modo in cui un agente raggiunge una risposta corretta attraverso una sequenza rotta senza che nessuno se ne accorga.

Dimensiona la suite in modo che rimanga viva. Tieni da parte da 300 a 800 casi, e mantieni 500 di essi in esecuzione

in meno di 5 minuti.

Una suite che richiede più tempo di una pausa caffè smette di essere eseguita.

Le prime cinque valutazioni, in ordine:

1. Risultato dello strumento vuoto: lo strumento non restituisce nulla, e l'agente deve dirlo invece di inventare il numero.
2. Chiamata ripetuta: la stessa ricerca con gli stessi argomenti due volte. Questo è un loop, e la valutazione lo fa fallire.
3. Rifiuto per limite: gli viene chiesto qualcosa al di fuori dei suoi permessi, l'agente rifiuta educatamente invece di cercare una via alternativa.
4. Integrità del passaggio di consegne: ciò che il nodo precedente ha prodotto è ciò che il nodo successivo legge, senza nulla di inventato in mezzo.
5. Completamento verificato: fatto significa che un segnale reale dice fatto, mai la parola dell'agente stesso.

← questa settimana: tre misurazioni, un tipo di dataset, cinque valutazioni (la scheda da salvare)

Tre misurazioni, un tipo di dataset, cinque valutazioni. Questo è un pomeriggio di lavoro, e ogni settimana successiva la suite vale più della settimana prima.

Quelli che vanno per primi

Il modello non è mai stata la parte interessante. È un noleggio, identico per tutti, e verrà sostituito due volte prima della fine dell'anno.

Ciò che sopravvive a ogni sostituzione è l'esaminatore che hai costruito intorno ad esso: i fallimenti che hai trasformato in test permanenti, le regole che permettono a un verdetto di cambiare il prossimo bordo, la cronologia dei risultati che permette a una macchina di unire il proprio lavoro.

Questo è ciò che decide se i 200 $ sulla tua estratta conto producono una demo o producono un'attività.

La maggior parte delle persone tornerà a scorrere gli output di venerdì e a decidere che sembra a posto.

Quelli che vanno per primi passano un pomeriggio a cablare il termostato, e poi passano l'anno successivo con un agente che non può rompere la stessa cosa due volte.

Tre righe racchiudono l'intera disciplina:

1. Misura il percorso che l'agente ha fatto, mai solo la risposta a cui è arrivato.
2. Un verdetto che non cambia il prossimo bordo è un report.
3. Qualsiasi fallimento che non trasformi in un test permanente, lo incontrerai di nuovo.

Installa una competenza. Estrai 25 tracce. Costruisci una valutazione oggi, e aggiungine una ogni volta che qualcosa si rompe.

Se vuoi rimanere aggiornato su tutto ciò che sta accadendo nell'AI, seguimi su X e Telegram:

X -

https://x.com/Argona0x Telegram -

https://t.me/+r0clI4-MMC03ZjAy