Il guasto peggiore di un agente non è l’errore che alza un’eccezione: è la risposta plausibile ottenuta scegliendo lo strumento sbagliato, o quella giusta pagata con dieci chiamate inutili. Dall’output finale non si vede. Servono tracce per capire cosa ha fatto, metriche per sapere quanto costa e quanto è lento, valutazioni per stabilire se lo ha fatto bene.

Cosa contiene una traccia e come si legge

Il punto di partenza è il tracing lato server: appena colleghi una risorsa Application Insights al progetto Foundry, il servizio registra le tracce di prompt agent e hosted agent senza modifiche al codice, e nel portale restano consultabili per novanta giorni. L’instrumentazione lato client, con OpenTelemetry e il plugin di tracing dell’SDK Azure, serve solo per vedere anche il codice della tua applicazione.

Foundry usa le semantic convention di OpenTelemetry. Una traccia è il percorso completo di una richiesta; gli span sono le singole operazioni, annidate per mostrare la gerarchia; gli attributi sono le coppie chiave-valore che portano il contenuto. Nelle convenzioni multi-agente lo span execute_task copre la pianificazione e sotto invoke_agent compaiono span figli come agent_to_agent_interaction, agent_planning e agent_orchestration; argomenti e risultati delle chiamate agli strumenti stanno negli attributi tool.call.arguments e tool.call.results dello span execute_tool.

È lì che si legge un errore di selezione. Apri il run, scorri gli span nell’ordine di invocazione e cerca il primo execute_tool che non doveva esserci: gli argomenti dicono come il modello ha interpretato la richiesta, i risultati se lo strumento ha restituito qualcosa di inutile. Se lo strumento giusto non è stato chiamato affatto, il problema non è il modello ma la sua descrizione o le istruzioni dell’agente. Nel portale la vista Conversation affianca alla traccia azioni, run step e tool call con input e output, ricercabili per Response ID o Trace ID.

Token, latenza e segnali di sicurezza

La dashboard nella scheda Monitor raccoglie quattro famiglie di numeri. L’uso dei token dice quanto stai spendendo e, se cresce senza che cresca il traffico, indica prompt o risposte prolisse. La latenza è il tempo di risposta dei run: la documentazione suggerisce di indagare oltre i dieci secondi — throttling, strumenti pesanti o rete. Il run success rate sotto il 95 per cento merita un’analisi dei run falliti. Ci sono poi i punteggi degli evaluator sul traffico campionato e gli esiti delle scansioni di red teaming.

Due implicazioni operative. Costo e conservazione: la telemetria vive nella risorsa Application Insights collegata, quindi retention e fatturazione seguono quella risorsa, non Foundry. Accesso: per leggere le tracce serve il ruolo Log Analytics Reader, e se le tabelle sono protette anche Privileged Monitoring Data Reader. Poiché le tracce contengono prompt, output e argomenti degli strumenti, il contenuto sensibile va instradato nella tabella dedicata e ristretto con RBAC; dati personali e segreti vanno redatti prima.

Valutare il comportamento: sistema e processo

Le tracce dicono cosa è successo, non se andava bene. Servono gli agent evaluator, che funzionano come unit test: prendono i messaggi dell’agente e restituiscono Pass o Fail, eventualmente derivato da un punteggio su scala 1-5 confrontato con una soglia.

Si dividono in due famiglie. La valutazione di sistema guarda l’esito complessivo: Intent Resolution (l’agente ha capito l’intento?), Task Adherence (ha rispettato regole e vincoli delle sue istruzioni?), Task Completion, Customer Satisfaction e Task Navigation Efficiency, che confronta la traiettoria con una sequenza attesa (match esatto, in ordine o in qualsiasi ordine). La valutazione di processo guarda i singoli passi: Tool Call Accuracy (chiamate giuste con i parametri giusti), Tool Selection, Tool Input Accuracy, Tool Output Utilization (l’agente ha davvero usato il risultato?) e Tool Call Success, che isola i fallimenti tecnici. In un sistema multi-agente gli evaluator di sistema si applicano all’orchestratore o all’agente finale.

Due dettagli d’esame. Gli input cambiano per evaluator: Task Adherence e Intent Resolution vogliono query, response e un deployment_name, gli evaluator sui tool anche tool_definitions nel formato function-calling di OpenAI. Nel data mapping i campi del dataset si citano nella forma item.query, mentre l’output strutturato dell’agente con chiamate e risultati si prende con sample.output_items e il testo semplice con sample.output_text: usare la variante testuale per un evaluator sui tool è un errore ricorrente. Per le categorie di rischio esistono invece i risk and safety evaluator, che girano sul servizio ospitato e non richiedono un deployment_name.

Dalla valutazione una tantum al monitoraggio continuo

In produzione una valutazione manuale non basta. Foundry offre due modalità ricorrenti: la scheduled evaluation, che gira a intervalli fissi su un dataset o su tracce filtrate, e la continuous evaluation, che campiona il traffico vivo. La seconda si configura con una regola di valutazione legata a un evento — tipicamente il completamento di una response — con un filtro sul nome dell’agente e un tetto di esecuzioni orarie, predefinito a 100: oltre quello le run vengono saltate. Il campionamento può essere casuale o intelligente, e la managed identity del progetto deve avere il ruolo Foundry User.

Sullo stesso pannello si attivano le scansioni di red teaming pianificate e gli alert su latenza, token, punteggi di valutazione e risultati delle scansioni. Se l’agente gira fuori da Foundry puoi registrarlo nel control plane e instradare la sua telemetria verso la stessa Application Insights: valutazione continua e metriche funzionano lo stesso, purché l’instrumentazione rispetti le semantic convention.

Da ricordare per l’esame

  • Il tracing lato server si attiva collegando Application Insights al progetto: nessuna modifica al codice, tracce consultabili nel portale per novanta giorni.
  • Gli argomenti e i risultati delle chiamate agli strumenti stanno in tool.call.arguments e tool.call.results: è lì che si diagnostica una selezione sbagliata.
  • Gli agent evaluator si dividono fra valutazione di sistema (Intent Resolution, Task Adherence, Task Completion) e di processo (Tool Call Accuracy, Tool Selection, Tool Output Utilization).
  • Nel data mapping sample.output_items serve agli evaluator che devono vedere chiamate e risultati; sample.output_text solo a quelli che valutano testo.
  • Scheduled evaluation gira su una pianificazione, continuous evaluation campiona il traffico vivo con un limite orario predefinito di 100 run.