Come misuro se un agente IA sta davvero funzionando

Indice

Aggiornato maggio 2026.

TL;DR: La maggior parte degli operatori salta le valutazioni e assume semplicemente che i propri agenti funzionino. Il mio framework: costruire un golden set di 5–10 input noti con output attesi, definire criteri superato/fallito in linguaggio semplice e controllare i log settimanalmente. Non costruire un sistema di valutazione elaborato prima di avere 10 esecuzioni reali — questa è la trappola che uccide lo slancio.

[Prospettiva dell’operatore] Gestisco oltre 30 agenti IA in produzione per il mio brand di consulenza e Pickleland, una struttura di pickleball a Pflugerville, TX. A un certo punto ho realizzato che stavo passando più tempo a preoccuparmi della deriva degli agenti che ad usarli davvero. Questo è il framework di valutazione su cui mi sono stabilizzato — nessun dottorato richiesto, nessuna piattaforma di valutazione personalizzata, nessun Python.

Il problema di cui nessuno parla: gli agenti derivano silenziosamente

Quando un dipendente umano inizia a fare male il proprio lavoro, di solito te ne accorgi. Quando un agente IA inizia a produrre spazzatura, continua a produrla — silenziosamente, su larga scala, finché qualcosa non si rompe abbastanza male da far guardare a un umano.

Ho avuto un agente di contenuti che ha iniziato ad aggiungere disclaimer “Come modello linguistico IA” dopo un aggiornamento del modello. Ho avuto un agente promotore di eventi che ha smesso di includere link ai biglietti perché il nome di una variabile del prompt era cambiato. Nessuno dei due ha fallito rumorosamente. Entrambi si sono semplicemente degradati.

La soluzione non è costruire un sistema di monitoraggio degno della NASA. È avere una verifica semplice e ripetibile che rileva la deriva prima che si accumuli.

Cos’è davvero una valutazione (per gli operatori)

Gli ingegneri usano la parola “eval” per eseguire un benchmark su un modello. Per gli operatori, intendo qualcosa di più semplice: un test ripetibile che ti dice se il tuo agente sta ancora facendo quello per cui l’hai costruito.

Tre componenti:

1. Golden set — 5–10 input reali che hai già visto, con output attesi che già sai essere buoni
2. Criteri superato/fallito — regole in linguaggio semplice per cosa conta come superato
3. Un controllo programmato — tu o il tuo assistente esegue effettivamente il test con una cadenza

Ecco tutto. Non hai bisogno di un framework. Hai bisogno di disciplina.

Costruire il tuo golden set

Attingi dai tuoi log di produzione. Trova 5–10 input reali per cui sai già come appare un buon output. Questi sono la tua verità di base.

Per il mio agente di pipeline di contenuti, il golden set è composto da 5 post pubblicati che hanno superato la mia checklist di voce quando li ho scritti manualmente. Per il mio promotore di eventi Pickleland, sono 5 post Facebook passati con engagement superiore alla media (commenti + condivisioni, non solo like).

Regole per un buon golden set:

• Input reali, non ipotesi che hai inventato
• Includere almeno un caso limite (un input complicato, breve, o con formattazione insolita)
• Tenere gli output attesi documentati — uno screenshot, un file di testo, una riga in un foglio di calcolo
• Non eliminare mai dal golden set; solo aggiungere

Quando l’agente funzionava bene l’ultima volta che è stato confermato, scrivi esattamente come appariva “buono”. Questo diventa il tuo output atteso.

Definire i criteri superato/fallito

I criteri vaghi sono inutili. “L’output dovrebbe essere buono” passerà sempre perché lo razionalizzerai.

Scrivi i tuoi criteri come elementi di checklist che un non-esperto potrebbe valutare. Ecco i criteri effettivi che uso per il mio agente di pipeline di contenuti:

Checklist superato/fallito dell’agente di contenuti:

• Il post ha un TL;DR nelle prime 100 parole
• Nessuna frase come “nel frenetico mondo di oggi” o “Come IA”
• Almeno un numero concreto o una statistica
• Conteggio parole tra 800 e 2000
• Tutti i link interni si risolvono (nessun 404)

Per il promotore di eventi Pickleland:

Checklist superato/fallito del promotore di eventi:

• Il nome dell’evento corrisponde al calendario fonte
• Data e ora sono corrette
• Il link al biglietto è presente e funzionante
• Il testo è sotto le 280 parole
• Il post non usa frasi generiche di riempimento

Se 4 dei 5 elementi della checklist superano, l’esecuzione è superata. Se 3 o meno superano, è un fallimento e indago prima della prossima esecuzione.

Usare Claude come giudice

Per agenti con output lunghi o complessi, uso Claude Sonnet come giudice automatizzato. È più veloce della revisione manuale e rileva cose che sfoglierei.

Ecco il prompt del giudice che uso per l’agente di contenuti:

You are evaluating a blog post written by an AI agent. Your job is to check whether it meets the operator's standards.

Evaluate the following post against these criteria:
1. Starts with a direct answer or TL;DR in the first 100 words (YES/NO)
2. Contains at least one concrete number or specific example (YES/NO)
3. Free of AI-speak filler ("As an AI", "in today's fast-paced world", "delve", "it's worth noting") (YES/NO)
4. Word count is between 800 and 2000 words (YES/NO)
5. Tone matches the reference: direct, first-person, opinionated, no fluff (YES/NO)

For each criterion, respond YES or NO with one sentence of explanation.
At the end, output PASS if 4 or 5 criteria are YES, FAIL otherwise.

Post to evaluate:
---
{{post_content}}
---

Lo eseguo come un Cloudflare Worker che recupera l’ultima bozza, lancia questo prompt e scrive il risultato in un Google Sheet. L’intero processo richiede 8 secondi e costa circa $0,003 per esecuzione.

Per il promotore di eventi, il prompt del giudice è più semplice:

You are checking an AI-generated Facebook event post for accuracy and quality.

Source data:
- Event name: {{event_name}}
- Date: {{event_date}}
- Time: {{event_time}}
- Ticket URL: {{ticket_url}}

Generated post:
---
{{generated_post}}
---

Check:
1. Does the post correctly state the event name? (YES/NO)
2. Does the post correctly state the date and time? (YES/NO)
3. Does the post include the exact ticket URL? (YES/NO)
4. Is the post under 280 words? (YES/NO)
5. Is the tone inviting without using generic filler phrases? (YES/NO)

Output PASS if all 5 are YES, FAIL if any are NO. List which items failed.

Dove guardare: i log di Cloudflare Worker

Se esegui agenti su Cloudflare Workers (cosa che faccio per la maggior parte dei miei agenti leggeri), il log tail integrato è il tuo migliore amico. Non hai bisogno di un servizio di logging di terze parti per iniziare.

Cosa controllo nelle revisioni settimanali a campione:

• Errori ed eccezioni — qualsiasi cosa che si è bloccata o ha superato il timeout
• Conteggi di token — se un’esecuzione usa improvvisamente 3 volte i token normali, qualcosa è cambiato
• Picchi di latenza — un rallentamento improvviso di solito significa che il prompt è diventato più lungo o il modello ha difficoltà
• Deriva nella lunghezza dell’output — se l’output medio è passato da 600 a 200 parole, l’agente ha cambiato comportamento

Passo 15 minuti ogni lunedì mattina su questo. Ho una semplice checklist in Notion: aprire i log per ogni agente, annotare qualsiasi anomalia, confrontare l’utilizzo dei token con il baseline della settimana scorsa. Questo è l’intero processo.

La valutazione in foglio di calcolo: brutta ma funziona

Prima di avere qualsiasi automazione, eseguivo valutazioni in un Google Sheet. Lo uso ancora per i nuovi agenti nelle prime 4 settimane.

Struttura:

Cinque righe a settimana. Impiega 10 minuti. Se hai due fallimenti consecutivi, fermi l’agente e correggi il prompt prima di continuare.

È imbarazzantemente low-tech. È anche così che ho individuato tre regressioni del prompt prima che raggiungessero la produzione.

Cosa NON fare

Non costruire il sistema di valutazione prima di avere 10 esecuzioni reali. Ho visto fondatori trascorrere due settimane a costruire una sofisticata pipeline di valutazione per un agente che avevano eseguito solo due volte. Non sai abbastanza su come appare “buono” finché non hai dati reali di produzione.

Non valutare con input sintetici che hai inventato. I casi di test sintetici mancano i casi limite strani che la produzione ti lancia. Inizia sempre con log reali.

Non valutare tutto. Scegli gli agenti 3–5 in cui il fallimento farebbe davvero male — output rivolti ai clienti, tutto ciò che posta pubblicamente, tutto ciò che attiva un pagamento. Salta gli agenti di utilità interni finché non hai spazio mentale.

Non automatizzare troppo presto. Un foglio di calcolo che usi davvero supera un dashboard Datadog che dimentichi di controllare. Inizia manualmente, automatizza dopo aver eseguito il controllo 10 volte e sapere cosa stai davvero cercando.

La conclusione dell’operatore

Le valutazioni non devono essere di livello ingegneristico per essere utili. Un golden set di 5–10 input reali, una checklist di criteri superato/fallito e 15 minuti di controllo dei log ogni lunedì rileveranno l’80% della deriva degli agenti prima che si accumuli. Inizia da lì. Se stai ancora eseguendo agenti senza alcuna valutazione, stai volando alla cieca — e alla fine qualcosa fallirà abbastanza pubblicamente da farti desiderare di aver dedicato i 20 minuti.