Tre segnali diversi: traccia, metrica, valutazione

Microsoft Foundry raggruppa l’osservabilità in tre capacità che l’esame si aspetta tu sappia tenere separate: evaluation, monitoring e tracing (/azure/foundry/concepts/observability). Il tracing è distribuito, costruito su OpenTelemetry e archiviato in Azure Monitor Application Insights: cattura input dell’utente e output dell’agente, uso degli strumenti, consumo di token e segnali di tempo. Una trace è il percorso di una richiesta, uno span è la singola operazione, gli attributes sono coppie chiave-valore; le convenzioni semantiche per i sistemi multi-agente definiscono fra gli altri tool.call.arguments e tool.call.results, cioè gli argomenti passati a uno strumento e il risultato che ha restituito. Il tracing è generalmente disponibile per prompt agent e hosted agent, mentre per workflow ed external agent è in preview.

Il monitoring è un’altra cosa. L’Agent Monitoring Dashboard (preview) mostra token usage, latency, run success rate, evaluation metrics e red teaming results sulla finestra temporale scelta, e la documentazione suggerisce soglie di lettura: una latenza sopra i 10 secondi può indicare throttling del modello, tool call complesse o problemi di rete; un run success rate sotto il 95% merita un’indagine sulle run fallite. L’evaluation, infine, non descrive: giudica. Gli agent evaluators restituiscono un esito Pass/Fail, eventualmente derivato da una scala 1-5 tramite soglia.

La distinzione non è terminologica. La telemetria dice che cosa è successo, non perché: la traccia di una chiamata a tool mostra input e output, e proprio per questo serve a separare un problema di prompt da uno di strumento da uno di dati. La doc lo dice esplicitamente: il tracing aiuta a rispondere a domande come “Where did this response come from?” e “Which step introduced an error or latency spike?”.

Isolare la causa: prompt, strumento o dati

Il metodo diagnostico segue la traccia in ordine. Se tool.call.arguments contiene parametri sbagliati, il difetto sta a monte dello strumento: istruzioni ambigue, descrizione del tool povera, schema dei parametri incompleto. Se gli argomenti sono corretti ma il risultato è un errore tecnico o un insieme vuoto, il difetto sta nello strumento o nei dati sottostanti. Se il risultato è buono ma la risposta finale lo ignora o lo contraddice, il difetto sta nella sintesi.

Gli evaluators ricalcano esattamente questa partizione. La process evaluation guarda i passi: Tool Selection, Tool Input Accuracy, Tool Call Success, Tool Output Utilization, Tool Call Accuracy. La system evaluation guarda l’esito: Task Completion (preview), Task Adherence (preview), Intent Resolution (preview), Customer Satisfaction (preview), Task Navigation Efficiency. Un agente che fallisce Tool Input Accuracy ma supera Tool Call Success ha un problema di istruzioni, non di integrazione.

Su Microsoft Copilot Studio la stessa diagnosi passa da oggetti diversi, e vanno nominati per quello che sono: l’activity map rappresenta ogni passo come node, disponibile solo per gli agenti con generative orchestration attiva; il nodo knowledge mostra la query effettivamente usata, le fonti citate e quelle consultate ma scartate; Rationale genera su richiesta una spiegazione di perché l’agente ha scelto quel tool, e la doc avverte che essendo generata dall’AI può non essere accurata; la Chain of Thought è disponibile solo per modelli selezionati. Non confondere questa superficie con la telemetria di Foundry: sono strumenti diversi per prodotti diversi.

Strumenti basati su AI per analizzare e mettere a punto

Gli evaluators assistiti da AI usano un modello come giudice, e la doc raccomanda gpt-5-mini per il bilanciamento fra prestazioni ed efficienza nelle valutazioni complesse. In produzione si sceglie fra due regimi: la continuous evaluation, che campiona il traffico live man mano che si presenta, e la scheduled evaluation, che gira a cadenza fissa su un dataset di riferimento per intercettare la deriva. La prima misura la realtà, la seconda misura la regressione; il limite di default è 100 run all’ora per regola.

L’AI Red Teaming Agent appartiene a un’altra famiglia ancora: usa PyRIT e le Risk and Safety Evaluations per simulare probing avversario e produce l’Attack Success Rate. Le categorie agentiche — prohibited actions, sensitive data leakage, task adherence — sono disponibili solo in cloud red teaming, e la doc consiglia di eseguirle in un purple environment, cioè un ambiente non di produzione configurato con risorse simili a quelle reali.

Sul versante Power Platform esiste un pattern architetturale documentato per l’analisi retrospettiva: Copilot Studio registra i transcript nella tabella ConversationTranscript di Microsoft Dataverse, un cloud flow di Power Automate li passa ad AI Builder che restituisce sentiment, temi e riassunto, i risultati tornano in Dataverse e Power BI li visualizza. È analisi, non monitoraggio: risponde a “quali intenti ricorrono”, non a “questa run è fallita”.

Dalla diagnosi alla leva giusta

Considera un gruppo assicurativo il cui agente di back office apre sinistri: il run success rate scende, ma il modello non si può cambiare perché il deployment è vincolato a una region approvata dal comitato rischi. Le leve residue sono le istruzioni, la descrizione degli strumenti, il grounding e l’orchestrazione — e la traccia dice quale delle quattro. Il fine-tuning è l’ultima, non la prima: la doc lo colloca dove serve ridurre l’overhead di prompt engineering, fissare stile e formato, o migliorare l’uso degli strumenti, e avverte che va ripetuto quando i dati cambiano o esce un nuovo modello base.

Se invece il vincolo è di costo, il model router è un modello ML addestrato che analizza il prompt e sceglie il modello, con routing mode Balanced, Cost o Quality; il modello scelto è sempre esposto nel campo model della risposta, ed è quello il segnale da loggare. Non confonderlo con i deployment type, che riguardano come un modello è ospitato, non quale viene scelto.

L’esame verifica proprio questa catena: dato un sintomo e un vincolo, quale segnale lo diagnostica e quale leva lo corregge. La confusione tipica da evitare è trattare evaluation, monitoring e testing come sinonimi, o presentare la Foundry Control Plane — che aggrega la salute della flotta e richiede Application Insights collegato — come se sostituisse la traccia del singolo run.