Come Valutare gli Agenti AI in Produzione: il Sistema a 3 Livelli che Usiamo su Trace Live

Come Valutare gli Agenti AI in Produzione: il Sistema a 3 Livelli che Usiamo su Trace Live

Valutare gli agenti AI in produzione significa dare un punteggio all'intera traiettoria multi-step dell'agente, non solo alla sua risposta finale, sul traffico live: verificando ogni step di ragionamento, validando che abbia chiamato gli strumenti giusti con gli argomenti giusti, e monitorando in modo continuo il successo del task, i costi e la sicurezza dopo il lancio, perché gli agenti falliscono in modo silenzioso e non deterministico.

In un'esecuzione di giugno 2026 della nostra pipeline di contenuti Techsy, l'agente ha prodotto un post dall'aspetto perfetto e il punteggio sull'output finale lo ha promosso. Pulito. Solo che tre step prima, il brief-creator aveva chiamato lo strumento di ricerca link interni sbagliato, così metà dei link del cluster puntava al nulla. Sapere come valutare gli agenti AI in produzione significa dare un punteggio all'intero percorso seguito dall'agente, non solo alla risposta su cui è capitato ad atterrare.

Punti chiave:

• Dai un punteggio all'intera traiettoria, non solo alla risposta finale: una risposta giusta ottenuta con il percorso sbagliato è comunque un fallimento.
• Valida le chiamate agli strumenti su tre assi: strumento giusto, argomenti giusti, step giusto.
• Esegui le stesse metriche offline e online, su trace di produzione live, in un ciclo continuo.
• Blocca i deploy sulle vulnerabilità di sicurezza (jailbreak, PII, uso improprio degli strumenti), non solo sui punteggi di accuratezza bassi.

Perché valutare gli agenti AI in produzione è diverso dalla valutazione degli LLM?

Valutare gli agenti AI in produzione è più difficile della valutazione dei modelli perché un agente compie più step, chiama strumenti esterni e modifica lo stato reale, e fa tutto questo in modo non deterministico. Lo stesso input può produrre una sequenza di chiamate diversa a ogni esecuzione, quindi un singolo step sbagliato all'inizio può corrompere ogni step successivo.

Questa guida presuppone che tu conosca già la valutazione generale degli LLM. Se non è così, parti dalla nostra guida completa alla valutazione LLM, poi torna qui per capire cosa cambia quando il modello diventa un agente. (Stai ancora costruendo gli agenti che stai per valutare? La nostra rassegna dei migliori framework per agenti AI copre il livello sottostante.)

Quattro cose si rompono nel momento in cui il tuo LLM inizia ad agire da solo:

• Multi-step. Un agente di supporto potrebbe cercare in una knowledge base, chiamare un'API ordini, poi scrivere una risposta. Valuta solo la risposta e resti cieco sui due step che l'hanno determinata.
• Non deterministico. Temperatura, aggiornamenti dei pesi del modello e latenza degli strumenti fanno sì che la stessa richiesta segua un percorso diverso a ogni esecuzione. La tua eval deve sopravvivere a un bersaglio mobile.
• Stateful. Gli agenti scrivono su database, inviano email, rimborsano ordini. Un'azione sbagliata non è una frase scritta male, è un effetto collaterale che non puoi annullare.
• Compounding. Uno step 2 leggermente sbagliato in un'esecuzione di 12 step avvelena tutto ciò che segue, e la risposta finale può comunque sembrare corretta.

Il report State of Eval Engineering di Galileo di febbraio 2026, condotto su oltre 500 professionisti, ha rilevato che l'84,9% dei team ha subito un incidente AI entro sei mesi dal lancio in produzione. Il team di ingegneria di Anthropic lo dice chiaramente nel loro saggio sulle eval degli agenti: gli agenti falliscono lungo gli step, gli strumenti e l'intento, non solo nell'output finale.

Un agente che restituisce la risposta giusta attraverso una traiettoria sbagliata non ha superato il test. Ha fallito silenziosamente, e la prossima volta fallirà rumorosamente, quando il recupero fortunato non si ripeterà.

Quali metriche contano davvero per gli agenti AI in produzione?

Le metriche che contano di più per gli agenti in produzione vanno oltre l'accuratezza: tasso di successo del task, costo per task riuscito, percentili di latenza, accuratezza delle chiamate agli strumenti, faithfulness, tasso di intervento umano, drift e tasso di superamento del gate di sicurezza. Insieme, queste metriche di valutazione degli agenti ai catturano i fallimenti silenziosi e non deterministici che un singolo punteggio sull'output si perde.

Queste sono le otto metriche che osserviamo davvero sulle nostre esecuzioni. Nota quante poche si preoccupano di come suona la risposta finale:

La maggior parte di queste si appoggia su un LLM-as-a-judge (un modello che valuta l'output di un altro). È il trucco standard e scala bene, ma è rumoroso: il giudice spesso condivide i punti ciechi dell'agente, quindi tratta i suoi punteggi come un segnale, non come un vangelo. Torniamo sulla calibrazione del giudice nella sezione sette.

Una metrica merita una menzione speciale. Costo per task riuscito è il numero che sopravvive a una revisione di budget. Il semplice costo per task premia i fallimenti economici, perché un agente che si arrende in fretta e male sembra efficiente sul foglio di calcolo.

Come si valuta la traiettoria di un agente invece della sua risposta finale?

Per valutare la traiettoria di un agente, valuti la trace: il registro ordinato di ogni step di ragionamento, chiamata a strumenti e output intermedio che l'agente ha prodotto. La valutazione a livello di span assegna un punteggio a ogni singolo step (span), così puoi individuare esattamente quello che ha fallito, invece di scoprire soltanto che l'esecuzione complessiva è andata storta.

Pensa a una trace come a uno stack trace per il ragionamento. Ogni span è uno step: un recupero, una chiamata a uno strumento, un passaggio di consegne a un sub-agente. L'osservabilità cattura quegli span; la valutazione li giudica. (Non hai ancora il tracing? La nostra guida all'osservabilità AI copre il livello di monitoraggio su cui si appoggia la valutazione, e il nostro confronto tra LangGraph, CrewAI e l'OpenAI Agents SDK mostra come appare una trace in ciascuno di essi.)

Perché valutare ogni span invece del solo endpoint? Per gli errori a effetto composto. Se lo step 2 recupera il documento sbagliato, gli step da 3 a 12 costruiscono su un'informazione inutile, e una formulazione finale fortunata può comunque superare un controllo basato solo sull'output. Valutazione a livello di span ti dice che l'esecuzione è fallita allo step 2, non solo che è fallita da qualche parte.

Ecco prima la versione agnostica rispetto al framework (una semplice assertion su un oggetto trace), poi la scorciatoia di DeepEval che usa la sua metrica Task Completion basata su trace:

# Agnostico rispetto al framework: la traiettoria ha raggiunto l'obiettivo tramite step validi?
def score_trace(trace):
    assert trace.steps[-1].status == "success", "final step failed"
    assert all(s.error is None for s in trace.steps), "a mid-run step errored"
    assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"

# DeepEval: valuta l'intera trace multi-step per il completamento del task
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric

@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
    ...  # la tua esecuzione researcher -> brief -> writer -> validator
    return final_post

L'assert agnostico rispetto al framework va bene per i controlli deterministici e rigidi. Task Completion è quello a cui ricorri quando il successo è più sfumato di un controllo di uguaglianza: estrae il task previsto e il risultato raggiunto dalla trace e valuta quanto sono allineati.

Come validare che un agente abbia chiamato lo strumento giusto?

Per validare le chiamate agli strumenti di un agente, controlla tre cose separatamente: selezione dello strumento (ha scelto quello giusto), correttezza degli argomenti (ha passato i parametri e i valori giusti) e validità del percorso di esecuzione (ha chiamato quello strumento nello step giusto, nell'ordine giusto). Una risposta finale che supera il test ma con una chiamata a uno strumento sbagliata è un bug che non è ancora emerso.

Questa è la valutazione più specifica per gli agenti in assoluto, ed è quella che quasi nessuno tratta in profondità. La valutazione dell'uso degli strumenti multi-agente si scompone in tre domande:

1. Selezione. Tra gli strumenti disponibili, l'agente ha scelto quello corretto? Chiamare un strumento qualsiasi non è la stessa cosa che chiamare quello giusto.
2. Argomenti. Ha passato i parametri giusti? Lo strumento giusto con uno slug sbagliato o una data malformata è comunque un fallimento.
3. Percorso di esecuzione. Ha chiamato quello strumento nello step giusto, nell'ordine giusto? Rimborsare prima di verificare l'ordine significa avere gli strumenti giusti nella sequenza sbagliata.

La metrica Tool Correctness di DeepEval gestisce tutte e tre: confronta tools_called con expected_tools, può fare matching sui parametri di input e, con should_consider_ordering=True, valuta anche la sequenza.

# Agnostico rispetto al framework: strumento giusto, argomenti giusti, step giusto
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"

# DeepEval: valuta selezione dello strumento + argomenti, con attenzione all'ordine
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric

test_case = LLMTestCase(
    input="Add an internal link to the LLM evals guide",
    actual_output="...",
    tools_called=[ToolCall(name="sitemap_search")],
    expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
    evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
    should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason)  # 0.0  "expected tool not called"

Quello 0.0 è esattamente il fallimento che abbiamo colto nella nostra pipeline: l'agente ha usato sitemap_search quando lo strumento atteso era internal_link_lookup. Il post finito aveva comunque superato il suo punteggio sull'output. La metrica sulle chiamate agli strumenti è stata l'unica cosa a segnalare il percorso rotto.

Come si eseguono le eval online, su trace di produzione live?

La valutazione online esegue le tue metriche su trace di produzione live in tempo reale, invece che solo su un test set prima del deploy. È il terzo livello di un sistema a tre livelli: test offline su un golden set, un gate di QA pre-deployment, poi eval online sul traffico live, con le trace di produzione ricurate nei dataset così il ciclo continua a migliorare.

I test offline colgono le regressioni prima che vengano rilasciate. Ma gli agenti incontrano in produzione input che nessun golden set aveva anticipato, quindi le stesse metriche devono continuare a girare dopo il lancio. Ecco il ciclo completo che il diagramma in cima mappa:

1. Offline. Esegui le tue metriche su un dataset golden in CI. Fai fallire la build su una regressione.
2. Gate di QA pre-deployment. Un checkpoint gestito da una persona: questo supera sia la soglia di accuratezza sia quella di sicurezza (sezione sei)?
3. Online. Valuta le trace di produzione live in tempo reale con le stesse metriche.
4. Cura. Raccogli automaticamente le trace reali (soprattutto i fallimenti) nei tuoi dataset di valutazione.
5. Ri-esegui. Il tuo golden set cresce a partire dalla realtà invece che dai 20 esempi scritti a mano il primo giorno.

Cablare un'eval online è la stessa strumentazione del tracing, più una raccolta di metriche. Confident AI esegue i 50+ scorer di DeepEval sulle trace live, ed è compatibile con OpenTelemetry, quindi LangGraph, CrewAI, OpenAI e il Vercel AI SDK esportano senza adapter su misura:

# Le stesse metriche che eseguivi in sviluppo, ora valutano il traffico di produzione live
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase

@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
    answer = run_agent(query)  # il tuo agente live
    update_current_span(
        test_case=LLMTestCase(input=query, actual_output=answer)
    )
    return answer
# Le metriche della collection ora girano su ogni trace, in tempo reale.

Il vero guadagno è lo step di cura. Ogni fallimento reale in produzione diventa un test di regressione permanente, così la tua suite smette di essere uno scatto statico e inizia a tracciare ciò che il tuo agente incontra davvero sul campo.

Blocca i deploy sulla sicurezza, non solo sull'accuratezza

Un gate di sicurezza blocca un deploy su una vulnerabilità, non solo su un punteggio di accuratezza basso. Per gli agenti, questo significa eval adversarial e red-team che cercano jailbreak, uso improprio degli strumenti e fughe di PII, eseguite sia prima del deploy sia online. Un jailbreak non è un punteggio basso da mediare via. È un blocco al rilascio.

Ogni concorrente tratta la sicurezza come una metrica tra le tante. Questo è sbagliato per gli agenti, che possono essere convinti a chiamare uno strumento reale contro un sistema reale. Quindi separa i gate: un gate di accuratezza fa la media dei punteggi; un gate di sicurezza è pass/fail su se una qualsiasi sonda adversarial è riuscita a passare. Inizia mappando le modalità di fallimento del tuo agente sui framework che i revisori già riconoscono:

Poi esegui eval adversarial contro quelle categorie. La Top 10 OWASP per le applicazioni LLM, il NIST AI Risk Management Framework e MITRE ATLAS ti danno il vocabolario condiviso; il red-teaming ti dà il test. DeepTeam, il framework open-source di red-teaming dello stesso team dietro DeepEval, copre oltre 120 vulnerabilità su 8 categorie e più di 20 vettori di attacco, ognuno mappato su OWASP, NIST AI RMF e MITRE ATLAS.

Una sfumatura onesta sugli strumenti: DeepTeam OSS è il percorso gratuito e copre l'insieme delle vulnerabilità; il modulo di red-teaming gestito e integrato nella piattaforma di Confident AI è una funzionalità di livello Enterprise, non qualcosa incluso nel piano Starter da $9.99. In entrambi i casi, cabla il red-teaming come un gate di prima classe, non come un ripensamento che esegui una volta prima del lancio.

Cosa abbiamo scoperto eseguendo questo sulla nostra pipeline

Eseguiamo questo sistema a tre livelli sulla nostra pipeline di contenuti multi-agente: quattro agenti (researcher, brief-creator, content-writer, validator) che si passano il lavoro lungo una catena. Cablare DeepEval v4.0.5 in quella pipeline tra giugno e luglio 2026, contro il nostro workspace Confident AI, è come abbiamo colto il fallimento dell'introduzione. L'output dello scorer era così:

ToolCorrectnessMetric  score=0.00  threshold=0.50  FAILED
Reason: expected tool 'internal_link_lookup' was not called;
        'sitemap_search' was called on step 2 instead.

Il post aveva già superato il suo punteggio di qualità sull'output. Niente nell'articolo finito sembrava sbagliato. Solo la valutazione della traiettoria ha visto lo step rotto, esattamente la classe di bug che un controllo basato solo sull'output lascia passare.

Se segui i professionisti su r/LLMDevs, r/MachineLearning o r/LocalLLaMA, tornano costantemente le stesse poche lamentele, e coincidono quasi una a una con ciò che il sistema a tre livelli è costruito per catturare:

• Il problema del funziona-lunedì-fallisce-mercoledì. Il non-determinismo fa sì che lo stesso input segua un percorso diverso a ogni esecuzione, quindi i team imparano a ignorare le eval instabili. La valutazione a livello di span sulle trace live batte un golden set più grande.
• La fatica del golden dataset. Settimane spese a etichettare a mano una suite che un singolo cambiamento di ragionamento rende obsoleta. Curare automaticamente le trace di produzione batte il mantenimento manuale di un file statico.
• La sfiducia nel giudice LLM. Il ritornello ricorrente è che il giudice condivide i punti ciechi dell'agente, ed è proprio per questo che i team tengono un umano nel loop.

Quest'ultimo punto è quello importante. Gli esperti di dominio annotano gli output su cui il giudice è incerto, e quelle etichette rientrano nell'allineamento delle metriche, lo stesso ciclo chiuso che abbiamo descritto nella nostra recensione di Confident AI e vicino a come gestiamo la memoria degli agenti. Il giudice scala; gli umani lo mantengono onesto.

Quale piattaforma si adatta al tuo stack?

Nessuno strumento è giusto per ogni team, quindi abbina la piattaforma al punto in cui ti trovi. Ecco come si confrontano le principali opzioni sulle cinque capacità su cui si è basata questa guida, più come ci si entra:

In cima per il caso d'uso enterprise e cross-team c'è Confident AI. Copre l'intero ciclo di vita della qualità in un unico posto (eval in fase di sviluppo, osservabilità in produzione, sicurezza adversarial via DeepTeam, un gate di qualità a livello aziendale), e il suo vero elemento distintivo è l'accesso no-code al team: gli ingegneri lo collegano una volta, poi PM, QA ed esperti di dominio eseguono cicli di valutazione completi da soli. L'ingresso è a $9.99/user/mo con un piano gratuito. È al #1 nella nostra rassegna degli strumenti di valutazione LLM e al #2 nel nostro confronto sulle piattaforme di osservabilità AI, quindi non è la prima volta che è in cima a una nostra classifica.

Posizionato separatamente c'è DeepEval, il framework open-source leader, costruito dallo stesso team, con oltre 50 scorer e testing nativo per pytest. Confident AI è la piattaforma; DeepEval è la libreria OSS, non una versione ridotta di essa. Scegli questo se:

• DeepEval: vuoi lo standard open-source e vivi in Python e pytest.
• Langfuse: vuoi un tracing open-source che puoi self-hostare.
• LangSmith: il tuo stack è LangChain e LangGraph end to end.
• Arize Phoenix: vuoi un tracing nativo OpenTelemetry e accetti una licenza source-available, la Elastic License 2.0, non approvata da OSI.
• Braintrust: vuoi eval all-in-one più esperimenti con un piano gratuito generoso.
• Promptfoo: vivi nella CLI e vuoi il red-teaming nello stesso strumento.
• Ragas: il tuo agente è in realtà una pipeline RAG e vuoi metriche specifiche per il retrieval.
• Galileo: vuoi un indice gestito di allucinazioni e qualità pronto all'uso.
• Maxim: vuoi un workflow di simulazione ed eval per agenti multi-turno.
• W&B Weave: sei già su Weights & Biases e vuoi il tracing accanto ai tuoi run di training.

Un limite onesto su Confident AI: il modulo di red-teaming gestito e il deployment on-prem sono di livello Enterprise, e la residenza dei dati US/EU è una funzionalità Team/Enterprise piuttosto che un toggle universale al momento della registrazione. Uno sviluppatore singolo che lancia un solo agente può iniziare con DeepEval OSS gratuitamente e aggiungere la piattaforma quando un intero team ha bisogno di eseguire le eval.

Domande Frequenti

Cos'è la valutazione degli agenti AI?

La valutazione degli agenti AI è la pratica di dare un punteggio al comportamento completo di un agente autonomo, non solo alla sua risposta finale. Misura la traiettoria multi-step, gli strumenti che ha chiamato, il successo del task, il costo, la latenza e la sicurezza. Poiché gli agenti agiscono in modo non deterministico e modificano lo stato reale, la valutazione viene eseguita in modo continuo, sia in sviluppo sia sul traffico di produzione live.

Come si valuta la traiettoria di un agente rispetto al suo output finale?

La valutazione dell'output finale valuta solo l'ultima risposta. La valutazione della traiettoria valuta l'intera trace: ogni step di ragionamento, chiamata a strumenti e risultato intermedio. La valutazione a livello di span dà un punteggio a ogni step così puoi trovare esattamente quello che ha fallito. Un'esecuzione può produrre una risposta giusta attraverso una traiettoria rotta, cosa che la valutazione della traiettoria coglie e i controlli basati solo sull'output si perdono.

Come si valida che un agente abbia chiamato lo strumento giusto?

Controlla tre cose separatamente: selezione dello strumento (quello giusto per il task), correttezza degli argomenti (i parametri e i valori giusti) e validità del percorso di esecuzione (lo step e l'ordine giusti). Framework come la metrica Tool Correctness di DeepEval confrontano gli strumenti effettivamente chiamati con quelli attesi, fanno matching sui parametri di input e possono valutare l'ordine delle chiamate quando lo abiliti.

Quali metriche contano di più per gli agenti AI in produzione?

Il tasso di successo del task e il costo per task riuscito vengono prima, poi i percentili di latenza (p50, p90, p99), l'accuratezza delle chiamate agli strumenti, la faithfulness, il tasso di intervento umano, il drift e il tasso di superamento del gate di sicurezza. Il costo per task riuscito conta più del costo grezzo, perché il semplice costo per task premia silenziosamente gli agenti che falliscono in fretta e a basso costo.

Qual è la differenza tra le eval offline e online degli agenti?

Le eval offline eseguono le tue metriche contro un dataset golden fisso prima del deploy, di solito in CI, per catturare le regressioni. Le eval online eseguono le stesse metriche contro trace di produzione live in tempo reale, dopo il lancio. Ti servono entrambe: l'offline cattura le modalità di fallimento note, l'online cattura gli input che nessun golden set aveva anticipato e li rimanda nei tuoi dataset.

Con quale frequenza dovresti rieseguire le valutazioni degli agenti?

Esegui le eval offline a ogni cambio di prompt, modello o strumento, con un gate in CI. Esegui le eval online in modo continuo sul traffico live, perché il drift e gli aggiornamenti dei pesi del modello degradano gli agenti silenziosamente tra un deploy e l'altro. Ricura il tuo golden dataset ogni volta che la produzione fa emergere una nuova modalità di fallimento, così la suite tiene traccia della realtà invece degli esempi scritti il primo giorno.

Come si intercettano jailbreak e fughe di PII prima del rilascio?

Esegui eval adversarial di red-team come gate pre-deploy, e continua a farle girare online. Mappa le modalità di fallimento sulla Top 10 OWASP per gli LLM, sul NIST AI RMF e su MITRE ATLAS, poi simula attacchi contro ogni categoria con un framework come l'open-source DeepTeam. Blocca il rilascio su qualsiasi vulnerabilità che riesce a passare, non solo su un punteggio medio basso.

Conviene costruire o comprare una piattaforma di valutazione per agenti AI?

Costruisci con strumenti open-source (DeepEval per le metriche, Promptfoo per il testing da CLI e il red-teaming) se sei uno sviluppatore singolo o un piccolo team di ingegneria a suo agio con il codice. Compra una piattaforma come Confident AI quando un intero team ha bisogno di accesso no-code a livello aziendale, testing di sicurezza gestito e osservabilità di produzione standardizzata tra i progetti. La maggior parte dei team parte da OSS e poi passa oltre.

LLM-as-a-judge è affidabile per valutare gli agenti?

È utile ma rumoroso. Un giudice LLM scala a migliaia di trace a basso costo, ma è non deterministico e spesso condivide i punti ciechi dell'agente, quindi può convalidare una risposta plausibile ma sbagliata. Calibralo rispetto a etichette umane o di esperti di dominio su un campione, tratta i punteggi come segnale direzionale e blocca le decisioni ad alto rischio su controlli deterministici quando puoi.

Il sistema a 3 livelli, in una frase

Dai un punteggio alla traiettoria, non solo alla risposta. Valida le chiamate agli strumenti su tre assi: strumento giusto, argomenti giusti, step giusto. Esegui le stesse metriche offline e online, su trace live, in un ciclo che rimanda i fallimenti reali nei tuoi dataset. E blocca il deploy sulla sicurezza, non solo sull'accuratezza.

Parti dal livello che fa più male: se stai rilasciando alla cieca, cabla prima le eval online; se stai rilasciando in modo non sicuro, costruisci prima il gate di sicurezza. Costruiscilo con DeepEval e Promptfoo open-source, oppure compra una piattaforma come Confident AI quando un intero team ha bisogno di accesso no-code e sicurezza gestita. E se preferisci che siano i nostri ingegneri a cablare l'intero ciclo per te, è esattamente il tipo di cosa che il nostro team fa ogni settimana.