Ingegneria del comportamento agentico

I modelli di linguaggio di grandi dimensioni (LLM) non sono deterministici per natura. Lo stesso input potrebbe non sempre produrre lo stesso output. I metodi di test tradizionali faticano a tenere conto di questa variabilità. Come è possibile adattare il processo di sviluppo in modo da avere la certezza che il sistema esegua in modo coerente come previsto?

La trasformazione di intelligenza artificiale aziendale genera altre domande: come proteggere e gestire le conoscenze proprietarie? Come si ottiene un comportamento affidabile? Come si usano le prove di esecuzione per migliorare il sistema nel tempo?

La progettazione del comportamento agentico (ABE), proposta da questo articolo, è una metodologia indipendente dalla piattaforma per specificare, ancorare, controllare, verificare e osservare il comportamento degli agenti di intelligenza artificiale. La metodologia consente di chiarire le esigenze dell'utente e del sistema, definire i risultati previsti, imporre i vincoli di esecuzione e verificare le modifiche rispetto agli scenari rappresentativi. I test tradizionali possono verificare che un'implementazione specifica funzioni come previsto, ma spesso non riescono a rilevare completamente la deriva comportamentale causata da modifiche apportate a modelli, richieste, strumenti o origini dati. ABE affronta questa sfida rendendo esplicito e continuamente verificabile il comportamento desiderato, consentendo ai team di evolvere i sistemi agenti senza perdere fiducia nei risultati.

Concetti chiave

L'artefatto chiave in ABE è il contratto comportamentale. Il contratto definisce il comportamento richiesto separatamente dall'implementazione in modo che le aspettative rimangano esplicite e verificabili man mano che il sistema cambia. Nei sistemi agentici, modelli, richieste, implementazioni degli strumenti, origini delle conoscenze, memoria, criteri, orchestrazione e accesso degli utenti possono cambiare nel tempo. Usare i contratti comportamentali per valutare l'effetto di tali modifiche sul comportamento richiesto per identificare lo scostamento e risolverlo.

Contratto comportamentale

Un contratto di comportamento definisce ciò che un agente deve e non deve eseguire in una situazione circoscritta. Specifica:

• La situazione, gli attori e l'ambito in cui si applica il contratto.
• Risultati accettabili e caratteristiche del risultato richieste.
• Conclusioni, informative, azioni ed effetti collaterali proibiti.
• Prove richieste prima che l'agente possa concludere o agire.
• Comportamento quando l'evidenza non è sufficiente o le dipendenze falliscono.
• Escalation, approvazione e condizioni di arresto.

Il contratto rende espliciti i requisiti di sicurezza e di IA responsabile applicabili. Definire questi requisiti durante la progettazione in modo che il team possa incorporarli nell'implementazione e nella verifica fin dall'inizio. Per indicazioni sulla definizione delle responsabilità e dei criteri specifici del carico di lavoro, vedere Intelligenza artificiale responsabile nei carichi di lavoro Azure.

Un behavior contract condivide un principio con la progettazione per contratto: rendere espliciti gli obblighi software. Definisce il comportamento richiesto senza prescrivere un'implementazione, in modo che i requisiti possano rimanere stabili man mano che cambia l'implementazione.

Usare un contratto per una situazione delimitata e più scenari per le sue variazioni. Creare un altro contratto quando gli attori, l'autorità, le prove necessarie o i risultati accettabili cambiano materialmente.

I team di ingegneria e prodotto mantengono congiuntamente il contratto di comportamento come asset con controllo delle versioni. Il Product Owner, supportato dagli esperti di dominio, approva il comportamento previsto e i risultati previsti. Il team di ingegneria redige congiuntamente i vincoli tecnici e i requisiti di evidenza e mantiene definizioni di scenari testabili, copertura, controllo delle versioni e verifica.

Esaminare le modifiche alle aspettative comportamentali congiuntamente ed eseguire una verifica della sicurezza e dei rischi quando necessario. La manutenzione tecnica che mantiene tali aspettative deve seguire il processo di revisione tecnica del team. Per indicazioni correlate, vedere Responsabilità relative alla proprietà delle specifiche funzionali e responsabilità della strategia di test.

Esempio: Approvare le recensioni dei prodotti a basso rischio

Un sito Web di vendita al dettaglio richiede al team standard di controllare le recensioni dei clienti sui prodotti rispetto ai criteri di utilizzo accettabili prima della pubblicazione. Il team Workload vuole che un agente approvi le richieste a basso rischio e invii i casi più rischiosi o incerti al team degli standard. L'obiettivo è ridurre la revisione manuale mantenendo gli standard di pubblicazione del sito.

La tabella seguente presenta un contratto comportamentale con controllo delle versioni per questo agente.

È possibile mantenere il contratto in JSON, YAML, Markdown, un documento Word o PDF. Scegli un formato che i product owner, gli esperti di dominio e gli ingegneri possono rivedere e gestire le versioni insieme. JSON o YAML possono semplificare la lettura dei singoli campi da parte degli strumenti. Qualsiasi formato scelto, mantenere una versione autorevole e collegare ad essa scenari e risultati di valutazione.

In questo esempio, il criterio consente un feedback negativo sul prodotto e richiede una revisione umana degli invii contenenti informazioni personali. Un cliente invia:

La batteria durava solo un'ora. Non lo comprerei di nuovo.

La decisione prevista consiste nell'approvare la sottomissione. Il record decisionale cita la regola della policy applicabile e spiega che il testo descrive un'esperienza del prodotto e non contiene contenuto che richiede una revisione umana ai sensi di questo criterio.

Se l'invio include informazioni personali, la decisione prevista consiste nell'inviarlo per la revisione umana e mantenerlo non pubblicato. Se non è possibile recuperare il criterio corrente, anche l'invio rimane non pubblicato.

L'applicazione applica le autorizzazioni e controlla la sottomissione prima di pubblicare una recensione approvata. Per valutare la decisione dell'agente, confrontarla con la decisione prevista del team standard per quella segnalazione.

Raccolta scenari

La libreria di scenari trasforma il contratto di comportamento in scenari utente concreti. Ogni scenario definisce una query o un'attività, un'evidenza e condizioni di dipendenza e un risultato previsto. Applica il behavior contract senza modificare i requisiti del contratto.

Gli esperti di prodotti e domini convalidano scenari e risultati previsti. L'ingegneria mantiene definizioni e copertura del contratto.

La tabella seguente illustra come la libreria di scenari applica il contratto di comportamento alle situazioni rappresentative per l'agente di revisione del prodotto:

Inizia a eseguire test con casi sintetici: invii fittizi e risposte simulate del servizio policy. La raccolta dei dati di ground truth può impedire al team di ingegneria di completare l'implementazione delle funzionalità. I casi sintetici espongono lacune nel contratto o nell'implementazione e offrono agli esperti di dominio il tempo necessario per completare la curatela dei dati di riferimento.

Usare casi sintetici per guidare esperti della materia (SME) nella raccolta di casi reali di carico di lavoro per un set di dati golden separato. Il set di dati golden espande gli scenari usando la stessa struttura: query effettive, prove corrispondenti e risultati previsti convalidati dallo SME. Uno scenario può avere molti casi gold.

Per lo scenario di revisione negativa, il team degli standard raccoglie gli invii reali che criticano un prodotto ma soddisfano la politica di pubblicazione. Mantengono gli input di test approvati e la versione della policy applicabile, quindi stabiliscono la decisione prevista. Raccolta di guide sui casi sintetici. Non vengono promossi nel set di dati golden.

La verità di riferimento è un risultato previsto convalidato dal dominio o un'evidenza di supporto in cui è possibile stabilire la correttezza, non l'output registrato di un agente. Vedi Usare i dati corretti per la valutazione.

Usare gli scenari durante una prova di concetto per confrontare le implementazioni rispetto allo stesso contratto e agli stessi limiti di costo e latenza. Nell'agente di revisione dei prodotti è necessario testare le decisioni di approvazione e gli handoff rispetto ai risultati previsti del team degli standard. Registrare la progettazione e i compromessi in un Architecture Decision Record e conservare gli scenari per i test di regressione.

Collegare ogni caso allo scenario e alla versione del contratto e registrare se è sintetico o proviene da dati reali del carico di lavoro. Mantenere gli scenari indipendenti dalle richieste, in modo che il comportamento richiesto rimanga testabile man mano che l'implementazione cambia.

Aggiungere casi limite ed errori di produzione esaminati. Se i confini di sicurezza sono inclusi nell'ambito, includere scenari di prompt injection, uso improprio ed esfiltrazione da red teaming di intelligenza artificiale e modellazione delle minacce.

Mantenere separati i set di sviluppo, di regressione e di rilascio protetti. Riservare alcuni test case per la verifica del rilascio e non usarli per sviluppare o ottimizzare l'implementazione. Limitare l'accesso a questi casi e ai risultati previsti. Se un caso comporta una modifica dell'implementazione, spostarlo nella suite di regressione e sostituirlo con un altro caso convalidato dagli esperti di dominio.

Intervallo operativo

L'inviluppo operativo copre un subset dei requisiti non funzionali del carico di lavoro. Definisce limiti di risorse ed esecuzione, ad esempio latenza, costo, utilizzo dei token, tentativi, chiamate agli strumenti e tempo impiegato per l'approvazione.

Il contratto definisce il comportamento corretto. L’inviluppo definisce i limiti operativi entro i quali il sistema deve operare. Un contratto può fare riferimento a una versione dell’inviluppo operativo quando tali limiti fanno parte dei criteri di accettazione. Versiona l’envelope in modo indipendente in modo che i limiti operativi possano cambiare senza ridefinire i requisiti comportamentali che non sono cambiati. I contratti di comportamento e i limiti operativi non richiedono una relazione uno a uno.

Riproduci di nuovo

Progettazione per la riesecuzione

Replay, come suggerisce il nome, esegue nuovamente i passaggi di inferenza del sistema fornendo gli output degli strumenti raccolti e le risposte delle API o i risultati RAG. Questo approccio consente di ottimizzare il prompt e identificare eventuali elementi di prova mancanti. Evita chiamate ripetute alle API live o agli strumenti MCP (Model Context Protocol), che possono essere costosi, soggetti a limitazioni di frequenza o restituire dati che cambiano nel tempo.

Raccogliere i dati di replay nell'ambiente di produzione. Rimuovere o mascherare i dati sensibili in base ai criteri prima dell'analisi o della revisione da parte di un esperto in materia (SME). Mantenere i payload della risposta e i relativi argomenti della richiesta senza modificare il significato del caso. Se l'oscuramento rimuove le prove necessarie, usare un dispositivo approvato e documentare la limitazione.

È necessario far esaminare e curare a un esperto (SME) i dati derivati dalla produzione prima di aggiungerli al set di dati golden o usarli per creare i double di test. I test double possono simulare risposte, in modo che il replay possa supportare scenari nuovi ed esistenti senza richiedere dati di produzione. Vedere risposte simulate con Dev Proxy e i set di dati di valutazione in Microsoft Foundry.

Configurare ed eseguire il replay

Versiona i set di dati di riproduzione usati per i test di valutazione e regressione. Per confrontare un aggiornamento con la baseline, eseguire entrambe le implementazioni sulla stessa versione del set di dati usando gli stessi case e le stesse versioni del valutatore. Mantenere coerenti altre condizioni di test, ad eccezione della modifica che si sta testando. Quando si aggiungono o si modificano i casi, creare una nuova versione del set di dati ed eseguire nuovamente entrambe le implementazioni.

Durante lo sviluppo, è possibile riprodurre un set di casi più piccolo per controllare il comportamento che si sta modificando. Se non sono ancora state registrate risposte per un nuovo scenario, usare risposte simulate ed etichettarle nel set di dati.

Scegliere lo scopo dell'esecuzione:

La configurazione di esecuzione si estende oltre i set di dati e i valutatori. Comprende anche prompt, modello, server API/MCP, librerie di supporto e altro ancora. Quando si eseguono valutazioni, è necessario avere un'ipotesi chiara e modifiche correlate per garantire che ogni esecuzione cambi solo un set minimo. Ciò consente di misurare correttamente l'impatto ed evitare di eseguire lo stesso aggiornamento più volte a causa di errori di mantenimento dei record.

Replay non sostituisce unit test o test di integrazione. Ogni test controlla un aspetto diverso del sistema software ed è altrettanto importante. Vedi Testare e valutare i carichi di lavoro di intelligenza artificiale.

Il diagramma seguente illustra il processo di shared replay.

Esempio: Verificare la modifica di un agente per recensioni di prodotti

Si supponga che la versione 42 dell'agente di revisione del prodotto approvi un invio che dovrebbe essere andato al team standard perché contiene informazioni personali. Il team prepara il caso usando le misure di protezione dei dati di replay e utilizza un test di sviluppo mirato durante la revisione dell'implementazione per il candidato 43.

1. Configurare un'esecuzione di valutazione per il candidato 43. Il set di dati di valutazione deve includere casi normali, nonché recensioni negative conformi, segnalazioni incerte e errori di dipendenza. Aggiornarlo con i casi che testano la funzionalità (regola delle informazioni personali). L'aggiornamento crea una nuova versione del set di dati. Eseguire la valutazione e la baseline nel nuovo set di dati. Riprodurre il set di dati completo per misurare l'accuratezza, il costo e la latenza delle decisioni per scenario.

2. Aggiornare il set di dati di verifica della versione con il nuovo caso d'uso e ottenere una versione aggiornata. Fare riferimento alla versione espansa del set di dati e impostare le soglie di accettazione. Riprodurre il candidato 43 e la baseline 42 rispetto alla stessa suite espansa e alle prove registrate.

3. Controllare i casi esistenti e nuovi in base alle aspettative esaminate. Aspettatevi approve per feedback negativo conforme ai requisiti e human_review per gli invii contenenti informazioni personali. Verificare che gli invii in attesa della revisione umana rimangano non pubblicati.

4. Salvare i risultati e le tracce per caso con la relativa versione di configurazione. Calcolare le metriche per ogni scenario. Usare i risultati della valutazione per migliorare i risultati dell'implementazione e della verifica del rilascio per decidere se il candidato può essere rilasciato. Un miglioramento complessivo non annulla un requisito obbligatorio non soddisfatto.

Architettura

Per usare la metodologia ABE per progettare le funzionalità del workload, iniziare con l'individuazione dei problemi e documentare il comportamento previsto in un contratto. Successivamente, decidere se il carico di lavoro richiede l'esecuzione guidata dall'agente. Collaborare con il responsabile business e il team di ingegneria per chiarire le esigenze e i presupposti degli utenti. Derivare gli scenari dai contratti di comportamento, identificare le conoscenze e le prove di cui il sistema ha bisogno e decidere quali controlli devono essere applicati dal sistema circostante.

Il contratto di comportamento e la libreria di scenari connettono il sistema a due cicli e guidano l'implementazione e il miglioramento. L'inner loop dello sviluppatore verifica le modifiche prima del rilascio. Il ciclo esterno di produzione raccoglie l'evidenza di esecuzione e il feedback per identificare gli errori o i requisiti modificati.

ABE organizza questo lavoro in cinque responsabilità di progettazione: specificare, mettere a terra, controllare, verificare e osservare. Queste responsabilità sono logiche, non cinque servizi necessari o passaggi sequenziali di runtime. Il lavoro su una singola funzionalità può estendersi su diverse responsabilità.

L'IA responsabile e la sicurezza sono aspetti trasversali in tutte e cinque le responsabilità del sistema. La responsabilità di specificare rende esplicite le aspettative di IA responsabile e i requisiti di sicurezza nei contratti comportamentali. La funzione di controllo implementa le regole di accesso e le misure di sicurezza di esecuzione che supportano tali requisiti.

Specify e ground forniscono controlli iniziali sulla prontezza e la fattibilità del progetto. Specificare stabilisce il problema e cosa significa il successo. Ground valuta se le informazioni necessarie sono disponibili e utilizzabili in base ai requisiti di accesso applicabili. Usare questi risultati per identificare le lacune prima di impegnarsi nell'implementazione, quindi convalidare i presupposti rimanenti in una prova di concetto. Per altre informazioni, vedere Allineare la strategia tecnica ai requisiti aziendali.

Usare il behavior contract e la libreria di scenari per confrontare le progettazioni fattibili. Un'implementazione deterministica o un flusso di lavoro fisso con passaggi basati su modello potrebbe soddisfare i requisiti. Scegliere un approccio agentico quando la valutazione dimostra vantaggi che giustificano costi, latenza e complessità operativa aggiuntivi. Per indicazioni sulla scelta di un approccio di esecuzione, vedere Flussi di lavoro fissi rispetto ai sistemi diretti dall'agente.

Specificare

Usare il pensiero progettuale per comprendere la necessità effettiva dell'utente prima di scegliere cosa e come automatizzare. Collaborare con utenti, proprietari aziendali e PMI per concordare risultati, vincoli e comportamenti di errore accettabili.

Raccogli questi requisiti in un contratto di comportamento versionato e deriva scenari di test per creare la libreria di scenari. I team di ingegneria e prodotto esaminano insieme le modifiche al comportamento previsto. Per affrontare le preoccupazioni relative all’IA responsabile e alla sicurezza, coinvolgere esperti di dominio, specialisti del rischio e specialisti della sicurezza. Versiona sia il contratto di comportamento che la libreria di scenari. Le note sulla versione devono identificare la versione del contratto e della libreria di scenari supportati e pubblicati.

Esaminare le modifiche dei requisiti insieme alla roadmap del prodotto e controllare nuovamente l'implementazione rispetto a entrambi. Per i carichi di lavoro multi-agente, definire un contratto end-to-end e aggiungere contratti di passaggio in cui responsabilità, requisiti di evidenza o le autorizzazioni cambiano.

Per l'agente di revisione del prodotto, concordare con il team degli standard quali invii sono idonei per l'approvazione automatica, quando è necessaria la revisione umana e come gestire un criterio o una coda di revisione non disponibile.

Il diagramma seguente illustra in che modo il contratto di comportamento e la libreria di scenari guidano l'implementazione e la verifica. Usare la libreria di scenari per guidare la cura del set di dati golden e definire i criteri di valutazione. Segnalare i risultati in base allo scenario, incluso il numero di casi testati, in modo che un punteggio complessivo non nasconda le lacune. I riscontri esaminati provenienti dalla valutazione e dalla produzione possono portare ad aggiornamenti alla libreria di scenari o al contratto di comportamento.

Per le tecniche di discovery, vedere Condurre ricerche sugli utenti e condividere i risultati.

Terra

Ground governa le conoscenze e le evidenze che passi al tuo agente, incluse le informazioni recuperate, le risposte degli strumenti, le regole business e la memoria. Prepara le informazioni rilevanti e autorevoli per ogni attività mantenendo al tempo stesso l'origine e l'autorità. La provenienza, la freschezza e il livello di sensibilità dei dati sono alcuni attributi chiave che devono essere rappresentati correttamente.

Per preparare le informazioni gestite per l'agente:

• Selezionare fonti autorevoli e assegnare i proprietari per mantenerle.
• Identificare i requisiti di accesso e mantenere i metadati di autorizzazione e riservatezza per la responsabilità del controllo .
• Preparare le informazioni in una forma che l'agente può usare senza perdere il significato aziendale, l'origine o la versione.

Durante la progettazione, assicurarsi che le fonti possano fornire le prove richieste dal behavior contract. Per l'agente per la revisione dei prodotti, collegare ogni valutazione al testo completo della submission, alla relativa revisione e alla versione della policy applicabile. Se l'evidenza richiesta è mancante o inaccessibile, risolvere il problema di accesso o dei dati, restringere l'ambito o rinviare la capacità interessata.

In fase di esecuzione, il livello di recupero segnala se una ricerca ha restituito dati, non ha trovato corrispondenze o ha avuto esito negativo. L'applicazione usa tale stato, insieme ai metadati dell'evidenza, per determinare se procedere o seguire la risposta prevista dal contratto in caso di prove insufficienti.

Mantenere le definizioni e le regole aziendali in asset versionati di proprietà del workload, indipendenti da prompt e modelli. Usare un contratto dati o un modello semantico per definire la struttura e il significato delle informazioni scambiate con altri agenti e sistemi.

La tabella seguente distingue le definizioni business dall'evidenza per una richiesta specifica. Una piattaforma di ontologia o di modello semantico può aiutare a organizzare queste definizioni quando gli agenti e i sistemi necessitano di concetti e relazioni aziendali condivisi.

Per esempi di implementazione, vedere associazione dati ontologici di Fabric (anteprima) e modelli semantici di Power BI.

È possibile stabilire un motore di regole o un flusso di lavoro per applicare regole aziendali nel codice deterministico prima di passare i risultati all'agente. Testa queste regole ripetutamente sui casi esaminati dagli esperti di dominio per verificare che l'implementazione corrisponda ai criteri previsti e ridurre l'incertezza di implementazione.

Durante la raccolta del contesto, identificare l'origine e l'autorità delle linee guida aziendali, le prove correnti e le informazioni memorizzate. Definire cosa l'agente può scrivere in memoria e per quanto tempo conservarle. La memoria non deve eseguire l'override dei record autorevoli e non può essere considerata allo stesso modo di richieste o istruzioni.

Il diagramma seguente illustra come preparare e combinare conoscenze, evidenze e memoria per l'agente.

Controllo

Control protegge il carico di lavoro tramite l'autenticazione, l'autorizzazione e la governance del runtime. Stabilisce chi può accedere al sistema, cosa può fare ogni chiamante e agente e quali azioni richiedono l'approvazione. Applicare queste decisioni nel codice dell'applicazione e nei servizi connessi, non nel modello.

Seguire le procedure consigliate per la sicurezza e eseguire la modellazione delle minacce per decidere quali misure di sicurezza di runtime implementare. Un diagramma del flusso di dati (DFD) mostra come le informazioni si spostano tra chiamanti, agenti, strumenti e archivi dati, compreso dove attraversano i confini di attendibilità. Usare tale analisi per determinare dove applicare i controlli di accesso, limitare la condivisione dei dati e richiedere approvazioni.

Questi confini di attendibilità fanno parte della difesa contro gli attacchi. Ad esempio, i contenuti recuperati o le risposte degli strumenti possono contenere istruzioni dannose. I controlli di accesso e i controlli di approvazione devono comunque essere applicati se il modello segue tali istruzioni. Seguire i principi di difesa in profondità e Zero Trust. Combina questi controlli con altre difese contro il prompt injection, invece di considerare una singola protezione sufficiente.

Autentica le identità del chiamante e dell'agente e quindi autorizza ogni accesso ai dati e ogni azione dello strumento in base all'attività e alla risorsa di destinazione. Applicare il privilegio minimo e far rispettare i requisiti di accesso identificati nella responsabilità fondamentale. Quando si delega il lavoro, mantenere il contesto di autorizzazione e i riferimenti di evidenza del chiamante e controllare nuovamente le autorizzazioni a ogni passaggio. La delega non deve estendere l'autorità. Se l'accesso viene negato, seguire il percorso di arresto o escalation definito invece di aggirare il diniego tramite un altro strumento o agente.

La governance del runtime applica anche le approvazioni necessarie, i passaggi obbligatori del flusso di lavoro e i limiti operativi, ad esempio budget e limiti di frequenza. Ripetere solo le operazioni che sono sicure da ripetere. Quando viene raggiunto un limite, seguire il comportamento di arresto o fallback del contratto. Questi controlli completano la progettazione più ampia della resilienza del carico di lavoro.

Nell'esempio dell'agente di revisione del prodotto l'accesso è limitato al contenuto inviato assegnato, ai criteri applicabili e alle azioni di moderazione. Il flusso di lavoro della pubblicazione controlla le autorizzazioni, la revisione della sottomissione e la versione della policy prima di pubblicare una recensione approvata. Tenere le modifiche alle policy e le azioni dell'account cliente fuori dalle autorizzazioni dell'agente.

Il diagramma seguente mostra come vengono valutate e registrate le azioni proposte.

Per un esempio di recupero delle informazioni, vedere Progettare una soluzione di inferenza RAG multi-tenant sicura. Per indicazioni sulla protezione a più livelli e sull'identità, vedere Identità, accesso e privilegi minimi e principi di progettazione della sicurezza.

Per esempi di controlli di esecuzione implementati tramite l'orchestrazione del flusso di lavoro, vedere Modelli multi-agente orientati al flusso di lavoro.

Verificare

Verify combina controlli su singoli casi con la valutazione a livello di set di dati nel ciclo interno dello sviluppatore.

Controllare un singolo caso

Durante l'implementazione, eseguire o riprodurre un test case usando risposte registrate o simulate. Esaminare la traccia di esecuzione per confrontare l'evidenza, le chiamate degli strumenti, le decisioni di controllo e il risultato con il contratto di comportamento e lo scenario. Usare i risultati per eseguire il debug e perfezionare l'implementazione.

Evaluations

Eseguire valutazioni in un set di dati con controllo delle versioni per misurare il comportamento in scenari supportati. Definire metriche e soglie di accettazione in base al contratto di comportamento. La tabella seguente descrive gli scenari e le misure associate per l'agente di revisione del prodotto.

Confrontare il candidato e la baseline usando lo stesso set di dati e le stesse versioni del valutatore. Per altre informazioni, vedere Configurare ed eseguire la riproduzione.

Riporta i risultati per scenario in modo che i punteggi aggregati non nascondano le regressioni. Ripetere i test case per verificare la coerenza. Definire il numero di esecuzioni e criteri di accettazione prima della valutazione. Registrare il contratto di comportamento, il set di dati, il valutatore e le versioni di soglia con i risultati.

Testare i casi a esecuzione prolungata e il comportamento di errore ai limiti operativi. Definire i conteggi dei passaggi e delle chiamate agli strumenti, ma richiedere un percorso esatto solo quando il contratto ne specifica uno. Per i carichi di lavoro multi-agente, testare gli handoff e i risultati end-to-end.

Eseguire questi controlli insieme a unit test e test di integrazione. Blocca i rilasci che non superano le soglie di scenario richieste. Per indicazioni relative al rilascio, vedere Checklist del percorso di adozione.

Osservare

Observe analizza le esecuzioni di produzione per identificare comportamenti corretti, errori e relative cause. Il sistema deve raccogliere commenti e suggerimenti degli utenti per facilitare l'analisi. Avviare l'analisi con la classificazione dello scenario:

1. Classificare i run registrati usando l'attività e il contesto di esecuzione. Associare ogni esecuzione allo scenario e alle versioni del contratto applicabili. Contrassegnare casi poco chiari o ambigui per la verifica.

2. Confrontare il risultato con il comportamento previsto dello scenario e combinare tali informazioni con il feedback degli utenti per valutare l'esito positivo o negativo. Lasciare i casi non valutati quando l'evidenza non è sufficiente.

3. Analizzare gli errori usando tracce e feedback dei revisori. Raggruppare i riscontri per causa, ad esempio lacune delle conoscenze, errori di implementazione o errori dovuti alle dipendenze o requisiti non chiari.

4. I proprietari dei prodotti, gli esperti di dominio e i tecnici esaminano i risultati e decidono cosa modificare. Verificare i risultati previsti prima di aggiungere casi preparati alla copertura della regressione. Registrare il motivo di ogni modifica e verificarlo prima del rilascio.

Nell'esempio dell'agente di revisione del prodotto, instradare un invio che contiene informazioni personali alla revisione umana mantenendolo non pubblicato è un comportamento corretto. Approvarlo è un esempio di fallimento. Una richiesta di aggiungere il supporto per le revisioni delle immagini identifica invece una potenziale modifica dell'ambito.

Acquisire l'input dell'attività, le richieste e le risposte degli strumenti, il contenuto recuperato fornito al modello e l'output. Mantenere le versioni di origine, controllare le decisioni e i guasti. Collegare il feedback dell'utente e del revisore al run e al rilascio. Ridurre al minimo i dati acquisiti, applicare i limiti di accesso e conservazione e seguire la guida per la preparazione dei dati di replay prima dell'analisi o della gestione del dataset.

Per un esempio di connessione dei risultati di produzione alla valutazione, vedere il agent observability quality loop.

Checklist del percorso di adozione

Iniziare con un'implementazione minima praticabile intorno a un comportamento significativo nel workload.

L'implementazione di ABE più piccola utile non è una piattaforma. Si tratta di un comportamento esplicito, riproducibile, valutato e soggetto a controllo. Il primo ciclo di lavoro si trova in Specifica e Verifica. Evitare di creare una piattaforma ampia prima che il team possa usare un unico contratto per prevenire, rilevare o diagnosticare un problema comportamentale reale.

1. Selezionare una situazione limitata e rilevante, identificare i proprietari di prodotto e i responsabili tecnici e coinvolgere esperti di dominio.
2. Scrivere un contratto di comportamento revisionato, incluse le evidenze e gli stati di errore.
3. Definire scenari per casi normali, limite, evidenze insufficienti e casi di errore dovuti a dipendenze. Genera casi sintetici da questi scenari per avviare il test.
4. Usare i casi sintetici per guidare gli esperti in materia nella raccolta e nella cura dei casi effettivi del carico di lavoro per un set di dati golden separato.
5. Acquisire o simulare risposte stabili di strumenti e conoscenze per la riproduzione.
6. Aggiungere controlli deterministici e solo gli analizzatori basati sul giudizio necessari per il contratto.
7. Eseguire gli scenari nell'integrazione continua e bloccare i rilasci in caso di errori critici.
8. Registrare informazioni sufficienti dalle esecuzioni di produzione per identificare il contratto, l'implementazione, il percorso di evidenza e il risultato.
9. Trasformare le evidenze di produzione esaminate in scenari di regressione.

Le modifiche alle richieste, alle impostazioni del modello e al codice dell'applicazione possono modificare il comportamento dell'agente. Convalida queste modifiche prima di usarle nell'ambiente di produzione. Registrare le versioni testate, la configurazione di valutazione e i risultati. Seguire le procedure di distribuzione sicure per introdurre le modifiche gradualmente e pianificare il ripristino in caso di problemi. Includi le modifiche di configurazione nel piano di ripristino.

Basati su questo primo ciclo man mano che impari quali sono le esigenze del carico di lavoro. Quando gli agenti e i sistemi necessitano di definizioni e relazioni aziendali condivise, un modello di dati semantico può fornire tale base. Quando le decisioni seguono regole business esplicite, un motore di regole può applicare tali regole all'esterno del modello. Mantieni i controlli di accesso e l'evidenza dell'esecuzione richiesti dal carico di lavoro fin dall'inizio, quindi espandi il monitoraggio e l'automazione man mano che i rischi e i risultati della produzione lo giustificano.

Implementare ABE in Azure

ABE è indipendente dalla piattaforma. Azure fornisce servizi che è possibile usare per supportare le sue cinque responsabilità tecniche.

Il diagramma seguente esegue il mapping di ogni responsabilità di ABE ai servizi di Azure da considerare per il carico di lavoro.

Per ogni responsabilità di ingegneria, combinate le funzionalità di Azure con i contratti, i controlli e i processi di revisione che il team gestisce.

Prima di scegliere qualsiasi servizio Azure, verificare che le funzionalità, le aree e le API siano adatte al carico di lavoro. Preferire i servizi generalmente disponibili (GA) e i controlli di proprietà dell'applicazione per l'applicazione obbligatoria e i controlli di rilascio. Alcune delle funzionalità indicate nelle sezioni seguenti sono funzionalità di anteprima e potrebbero non essere adatte per il carico di lavoro.

Specifica in Azure

Mantieni contratti, scenari, operating envelopes e configurazioni di replay nel repository Git esistente, ad esempio Azure Repos o GitHub. Seguire le responsabilità di revisione condivisa quando una modifica influisce sul comportamento previsto. Usare la revisione ingegneristica per la manutenzione tecnica.

Ground su Azure

Connetti l'agente alle fonti autorevoli identificate per la responsabilità di base. Per l'agente di revisione del prodotto, si inizia con le API dell'applicazione esistenti del sito Web per recuperare i contenuti inviati e la policy attualmente approvata.

Quando è necessario eseguire il recupero tra più fonti di conoscenza, prendere in considerazione recupero agentico di Azure AI Search. Può restituire contenuti con grounding con riferimenti di origine facoltativi e un log attività. Misurare il costo e la latenza dell'approccio di recupero selezionato.

Se i dati aziendali sono già presenti in Microsoft Fabric, il Fabric IQ tool può connettere agenti Microsoft Foundry a modelli semantici ed elementi di ontologia. La funzionalità di integrazione e la funzionalità di ontologia sono disponibili in anteprima. Controllare come la connessione esegue l'autenticazione, i dati a cui può accedere e se i dati potrebbero lasciare il limite di conformità Azure.

Definire la versione delle definizioni semantiche separatamente dall'implementazione dell'agente e registrare le relative versioni con l'evidenza di test. Integrazione Git di Fabric supporta gli elementi di ontologia in anteprima.

Controllo ed eseguire in Azure

È possibile eseguire agenti prompt e agenti ospitati personalizzati in Foundry Agent Service. Per altri requisiti di runtime o distribuzione, prendere in considerazione AKS, App contenitore di Azure o Servizio app di Azure. Vedi Scegli un servizio di calcolo di Azure per confrontare le opzioni. Implementare le regole di autorizzazione, approvazione ed esecuzione nell'applicazione e nei servizi connessi.

Per gli agenti Foundry, usare Microsoft Entra agent identities per le connessioni MCP e da agente a agente supportate. Quando l'agente agisce per un utente, controllare sia l'autorità dell'utente che l'autorità dell'agente. Prima del rilascio, verificare l'identità e le autorizzazioni che l'agente userà in fase di esecuzione.

Gestione API di Azure è possibile gestire gli endpoint MCP condivisi tramite criteri di autenticazione, limiti di frequenza e quote. Usare il middleware di Agent Framework per aggiungere controlli gestiti dall'applicazione per gli strumenti funzione eseguiti dal framework. Per gli strumenti eseguiti all'esterno di tale limite, applicare l'autorizzazione obbligatoria e i criteri in un gateway o in un servizio downstream.

Quando un'azione richiede una conferma umana, usare approvazione function-tool. Se le approvazioni del flusso di lavoro devono sopravvivere a un riavvio, configurare l'archiviazione del checkpoint permanente e ripristinare lo stato di approvazione in sospeso prima di consentire l'esecuzione. Per gli strumenti che modificano lo stato, convalidare gli input e aggiungere misure di sicurezza di idempotenza nell'executor dell'azione. Orchestrazione della versione e impostazioni di controllo nell'implementazione.

Prompt Shields in Sicurezza dei contenuti di Azure AI può rilevare i tentativi di prompt injection nei prompt degli utenti e nei documenti di grounding. Combina questi controlli con l'autorizzazione. Definire il modo in cui il carico di lavoro risponde al contenuto bloccato nel contratto di comportamento e testare tale risposta.

Per l'agente per la revisione dei prodotti, viene concesso l'accesso in lettura alle sottomissioni assegnate e alla policy corrente. L'accesso in scrittura è limitato alle operazioni di moderazione che approvano un invio o lo instradano per la revisione umana. I controlli della versione dei criteri e dell'invio vengono applicati nel flusso di lavoro della pubblicazione.

Verifica in Azure

È possibile archiviare i casi di replay preparati e i risultati dei test in Archiviazione BLOB di Azure. Fare riferimento a versioni specifiche del set di dati nelle configurazioni di replay e collegare i casi derivati dall'ambiente di produzione alle esecuzioni di origine. Limitare l'accesso ai casi holdout protetti e alle prove di produzione conservate. Seguire le linee guida sull'architettura gestione rete virtuale di Azure per l'accesso basato su identità, la protezione dei dati e la conservazione.

Usando i set di dati di valutazione Foundry, è possibile assegnare punteggi alle risposte completate o inviare input a un agente per generare e valutare nuove risposte. Per la riproduzione controllata, configurare gli adattatori di dipendenza prima di richiamare l'agente. Pubblicare i set di dati come copie di esecuzione della libreria di scenari regolamentati e applicare le stesse restrizioni di accesso holdout.

Usare controlli deterministici per i criteri con valori o regole di riferimento espliciti e usare i valutatori basati su modello per i criteri basati sul giudizio. I valutatori personalizzati di Foundry supportano entrambi gli approcci, nonché gli endpoint di assegnazione dei punteggi esterni.

Per l'agente di revisione del prodotto, un controllo basato sul codice può confrontare la decisione strutturata con la decisione prevista del team degli standard. Un analizzatore basato su modello può valutare se la spiegazione e la regola della policy citata supportano tale decisione, in base al testo inviato. I valutatori rubric e i valutatori personalizzati sono in anteprima.

Controllare la compatibilità dello strumento di valutazione prima di usare i punteggi in un gate. Per le conversazioni contenenti chiamate dell'agente dati di Azure AI Search o di Fabric, non usare i risultati tool_call_accuracy, tool_input_accuracy, tool_output_utilization, tool_call_success o groundedness. Usare asserzioni di contratto deterministiche o un altro metodo di valutazione supportato.

Salva i risultati e le tracce per ciascun caso con la configurazione che li ha prodotti. Applicare le soglie di rilascio nella pipeline e bloccare il rilascio in caso di errore di uno scenario obbligatorio. Usare gli stessi case e versioni del valutatore durante il confronto delle implementazioni. Se si esegue il training di modelli personalizzati in Azure Machine Learning, includere le relative versioni nella configurazione.

Osserva in Azure

Il tracciamento di Foundry usa la risorsa Application Insights di Monitoraggio di Azure connessa al progetto. Strumenta lo strumento e il codice di recupero della tua applicazione per acquisire eventuali prove aggiuntive necessarie.

Decidi quale contenuto è necessario registrare. L'integrazione del tracciamento lato client di Foundry include le impostazioni per la registrazione del contenuto dei messaggi. Verificare che la strumentazione acquisisca le risposte degli strumenti necessarie e il contenuto recuperato insieme ai nomi delle operazioni e alle tempistiche. Ridurre al minimo o oscurare i payload sensibili prima dell'esportazione della telemetria e conservare solo le evidenze consentite dai criteri dei dati.

È consigliabile usare la trace evaluation (preview) per valutare le tracce di Application Insights conservate che soddisfano i requisiti di bonifica dei dati. Assegna punteggi alle interazioni esistenti senza riesecuzione delle richieste, incluse le tracce OpenTelemetry supportate dagli agenti esterni a Foundry. Usare questi punteggi per analizzare il comportamento di produzione e quindi verificare le modifiche di implementazione risultanti tramite la riproduzione e la valutazione prima del rilascio. Questa funzionalità è disponibile in anteprima pubblica, non ha un accordo sul livello di servizio (SLA) e non è consigliata per i carichi di lavoro di produzione. Non basarsi su di esso per il monitoraggio in produzione o le decisioni di rilascio.

Usare query di Log Analytics e avvisi di Monitoraggio di Azure per analizzare gli errori comportamentali e le violazioni dei limiti operativi. La visualizzazione dei dettagli dell'agente di Application Insights, attualmente in anteprima, consente di analizzare le singole esecuzioni. Ha inserito i risultati esaminati e i casi preparati nel successivo ciclo di modifica e riproduzione.

Contributors

Microsoft mantiene questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autori principali:

• Yang Song | Ingegnere software principale

Altri contributori:

• Chad Kittel | Principal Software Engineer
• Bryan Ostdiek | Scienziato dei dati principale
• Peter Parker | Principal Solution Engineer, Azure AI Cloud Strategist and Architect
• Rama Pyarasani | Responsabile di ingegneri multidisciplinari sul campo
• Ronnie Yates | General Manager, Forward Deployed Engineering

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Agenti in Microsoft Foundry
• Valutare gli agenti di intelligenza artificiale
• Recupero agentico in Azure AI Search
• Monitorare gli agenti di intelligenza artificiale con Application Insights
• Contratti comportamentali degli agenti (documento di ricerca)

Risorse correlate

• Pattern di progettazione degli agenti AI
• Generazione aumentata dal recupero agentica
• operazioni di Machine Learning