Se non riesci a dare un numero a quanto una modifica ha migliorato o peggiorato il tuo agente, non lo stai facendo ingegneria, lo stai indovinando con qualche passo in più. Il motivo più comune per cui i progetti ad agenti si bloccano non è un modello debole, è l'assenza di un eval harness. Senza uno, ogni piccola modifica al prompt, cambio di tool, o sostituzione di modello viene valutata da qualcuno che guarda a occhio una manciata di output e dichiara che "sembra migliore", che è il modo in cui rilasci una regressione e lo scopri da un utente. Il tabellone deve esistere prima dell'agente, perché non puoi migliorare ciò che non puoi misurare.

Il modo utile di vederla: un eval set è la tua test suite per codice probabilistico. Non rifattorizzeresti un servizio senza test e lo rilasceresti sulla base del fatto che sembra andare bene. Un agente è più difficile da ragionare di quel servizio, non più facile, quindi ha bisogno del tabellone ancora di più, non di meno.

Costruisci l'harness prima dell'agente

Un eval harness è poco affascinante e piccolo all'inizio: un insieme di input rappresentativi, una definizione di output buono per ciascuno, e un modo per far girare il sistema attuale contro tutti loro e ottenere un punteggio. Venti-cinquanta esempi reali, presi da traffico reale o atteso, battono mille esempi sintetici. Il punto è avere un metro fisso, così "abbiamo migliorato l'agente" diventa un'affermazione verificabile invece di una sensazione.

Una volta che esiste, il flusso di lavoro si ribalta. Ogni modifica, nuovo prompt, nuovo tool, nuovo modello, gira prima contro l'harness. Una modifica che alza il punteggio viene rilasciata, una che lo abbassa no, per quanto sembrasse intelligente. Su Bedrock, Model Evaluation ti dà un percorso gestito per questo, con metriche automatiche e revisione umana, ed è diventato generalmente disponibile ben prima che ne avessi bisogno qui. Lo strumento conta meno della disciplina: misura, poi decidi.

LLM-as-a-judge, e dove ti mente

Valutare output aperti a mano non scala, quindi la mossa standard è usare un modello come giudice: dai a un modello forte l'input, l'output dell'agente, e una rubrica, e chiedigli di valutare. Bedrock Model Evaluation supporta esattamente questo. È genuinamente utile ed è anche un componente che può sbagliare, cosa che i team dimenticano nel momento in cui inizia a sfornare numeri ordinati.

Il giudice ha modi prevedibili di fallire, e devi progettare intorno a essi:

  • Bias di posizione e verbosità. I giudici tendono a preferire la prima opzione mostrata e la risposta più lunga e sicura di sé, indipendentemente dalla correttezza. Randomizza l'ordine e controlla la lunghezza.
  • Auto-preferenza. Un giudice della stessa famiglia di modelli può valutare più in alto gli output della propria famiglia. Dove conta, usa un giudice di una famiglia diversa dal modello sotto test.
  • Deriva della rubrica. Una rubrica vaga ("questa risposta è buona?") produce punteggi vaghi e instabili. Una rubrica specifica ("la risposta cita la sezione della policy, e la sezione citata è corretta?") produce punteggi su cui puoi agire.
  • Accordo sicuro con una risposta sbagliata. Se l'input contiene una premessa falsa, il giudice può premiare un output che la asseconda. Includi casi avversariali dove il comportamento corretto è rifiutare o correggere.

Il giudice non è ground truth. È un'approssimazione veloce ed economica della ground truth che tari contro un piccolo insieme etichettato da esseri umani. Se il giudice e i tuoi umani non sono d'accordo su quell'insieme, sistema la rubrica prima di fidarti del giudice sul resto.

Valuta la traiettoria, non solo la risposta

Per gli agenti in particolare, la risposta finale è solo metà di ciò che conta. Un agente può produrre una risposta giusta seguendo un percorso sbagliato: chiamando un tool che non avrebbe dovuto chiamare, spendendo dieci passi su un task da due, o facendo trapelare dati in un log lungo il percorso. Valuta la traiettoria oltre all'output. Ha usato i tool attesi? È rimasto dentro le azioni consentite? Ha finito in un numero sensato di passi? Un agente che ottiene la risposta giusta chiamando un'API di cancellazione che non avrebbe mai dovuto toccare ha fallito l'eval, qualunque cosa dica il testo finale.

Il punto chiave

L'ordine non è negoziabile: prima l'eval harness, poi l'agente. L'harness è un insieme piccolo e fisso di input reali con output buoni definiti e un punteggio ripetibile, e trasforma ogni modifica da un vibe check in una decisione misurata. Usa un LLM-as-a-judge per scalare la valutazione, ma trattalo come un componente fallibile: controlla i suoi bias, dagli una rubrica specifica, e tara contro etichette umane. Valuta il percorso, non solo il risultato. Non puoi rilasciare ciò che non puoi misurare, e i team che rilasciano agenti affidabili sono quelli che hanno costruito il tabellone prima di costruire il giocatore.

Leggi questo dopo

Per il lato platform di collegare gli eval a una pipeline di delivery, le note di campo sul cloud sono su ercan.cloud, e l'hub è su ercanermis.com.