Eccellenza operativa per l'azienda agente

L'eccellenza operativa per i sistemi agentici estende le pratiche DevOps tradizionali per affrontare le caratteristiche specifiche degli agenti AI: comportamento non deterministico, ragionamento e memoria dipendenti dal contesto, complessità degli obiettivi e costi di inferenza variabile. Le applicazioni convenzionali seguono percorsi di codice prevedibili, ma gli agenti generano nuove risposte basate sul contesto. Il monitoraggio tradizionale tiene traccia delle metriche note, mentre l'osservabilità degli agenti richiede la comprensione del ragionamento del modello linguistico e degli schemi decisionali. I test standard convalidano gli output deterministici, ma la convalida degli agenti valuta la qualità della risposta in più dimensioni, tra cui precisione, pertinenza, sicurezza ed equità.

Poiché i prodotti e i sistemi cambiano nel tempo, applicare questi cinque principi di progettazione per incorporare l'eccellenza operativa nel modo in cui vengono eseguiti: evolvere con osservabilità, standardizzare le procedure operative, adottare una cultura DevOps, automatizzare per l'efficienza e imparare da tutti gli eventi operativi. Il principio di eccellenza operativa fondamentale, "Evolvere con osservabilità", diventa fondamentale per i sistemi agenti poiché il comportamento degli agenti emerge da interazioni complesse tra prompt, contesto recuperato, comportamento del modello e cronologia delle conversazioni anziché dall'esecuzione di codice deterministico. Poiché gli architetti non sono in grado di prevedere ogni risposta degli agenti al momento della progettazione, poiché le risposte dipendono dal modello, dal prompt e dal contesto live, progettare per l'osservabilità e i guardrail. L'osservabilità completa rivela come si comportano effettivamente gli agenti in condizioni reali. Questa visibilità consente miglioramenti basati sui dati e una diagnosi rapida dei problemi quando gli agenti producono output imprevisti.

"Operations as Code" assume nuove dimensioni per gli agenti. L'infrastruttura tradizionale come codice si estende al controllo delle versioni del prompt, alla gestione della configurazione del modello e all'automazione della distribuzione degli agenti. Le procedure operative degli agenti riguardano le modifiche della versione del modello, l'evoluzione rapida e gli aggiornamenti della Knowledge Base e le operazioni convenzionali di distribuzione e ritiro.

"Impara da tutti gli eventi operativi" diventa ancora più utile con i sistemi agenti. Gli incidenti degli agenti spesso rivelano piccoli problemi di prompt engineering, errori di scripting e orchestrazione, lacune della Knowledge Base o schemi di interazione utente imprevisti. L'autopsia combinata con l'analisi sistematica della telemetria degli agenti trasforma l'esperienza operativa in capacità organizzativa che aumenta nel tempo.

La registrazione completa delle conversazioni costituisce la base dell'osservabilità degli agenti. Acquisire ogni conversazione, inclusi gli input degli utenti, le risposte degli agenti, le fasi di ragionamento, le azioni richiamate, i dati recuperati e gli esiti finali. Questa telemetria ha diversi scopi: debug di incidenti specifici, analisi della qualità in molte interazioni, controllo della conformità, miglioramento del modello e analisi dello schema di utilizzo.

Utilizzare il modello nativo di tracciamento delle sessioni anziché la registrazione personalizzata. Agentforce Session Tracing acquisisce i dati di interazione degli agenti in un modello di dati unificato in Data 360 anziché richiedere la creazione di un sistema di telemetria parallelo. Il modello di dati di tracciamento delle sessioni (STDM) registra la conversazione come gerarchia delle tracce. Ogni sessione contiene interazioni (turni), ogni interazione contiene fasi (UserInputStep, LLMExecutionStep, FunctionStep) e fasi contengono messaggi (comunicazioni utente e agente). STDM utilizza oggetti Data 360 standard come AIAgentSession, AIAgentSessionParticipant, AIAgentInteraction, AIAgentInteractionStep e AIAgentInteractionMessage. Le interazioni contengono identificatori di tracciamento distribuito (TelemetryTraceId e TelemetryTraceSpanId) e le fasi contengono un identificatore di span (TelemetryTraceSpanId), che riflette un modello di span in stile OpenTelemetry.

La modellazione delle conversazioni degli agenti come tracce è l'approccio standard del settore all'osservabilità degli agenti e il riutilizzo del modello nativo evita i problemi di scala in cui si trovano gli oggetti creati a mano: archiviazione di conversazioni a più turni, carichi utili JSON di grandi dimensioni e rapida crescita dei dati. La creazione di oggetti transazionali personalizzati per registrare le conversazioni è un'eccezione deliberata, ad esempio un oggetto personalizzato leggero che correla il comportamento degli agenti ai risultati aziendali e non al substrato di registrazione principale.

I metadati delle sessioni e delle conversazioni acquisiscono il contesto critico, inclusi gli identificativi di sessione e interazione, l'identità dell'utente, l'identità dell'agente, l'ora di inizio e l'ora di fine. STDM collega inoltre ogni fase di interazione ai relativi record di chiamata LLM (large language model) (tramite GenerationId e riferimenti GenAiGatewayRequest/Response). L'utilizzo dei token, il modello e i dettagli del prompt sono disponibili tramite questi join anziché memorizzati come campi di sessione. I metadati consentono di filtrare e aggregare le conversazioni per l'analisi degli schemi.

I dettagli delle interazioni e delle fasi acquisiscono ogni turno, inclusi l'input dell'utente, la risposta dell'agente, la spiegazione del ragionamento (se disponibile), i punteggi di confidenza, il contesto recuperato, le azioni tentate e gli errori riscontrati. Il tracciamento a livello di fase consente un'indagine dettagliata degli incidenti che ricostruisce esattamente ciò che è accaduto in ogni punto della catena di ragionamento.

Le fasi azione registrano ogni azione eseguita da un agente, incluse le chiamate API, le modifiche dei dati, le interazioni con i sistemi esterni e le integrazioni richiamate. I record azione rispondono a domande come "cosa ha modificato questo agente?" e "a quali sistemi ha avuto accesso questo agente?". Queste risposte supportano le indagini di sicurezza e i requisiti di conformità. STDM acquisisce le azioni in modo nativo come fasi di interazione.

Le tracce di ragionamento del Motore di ragionamento Atlas rivelano i processi decisionali degli agenti, consentendo di diagnosticare perché gli agenti hanno scelto azioni specifiche o generato risposte particolari. Il tracciamento della sessione registra le fasi del pianificatore come parte di ogni interazione. La profondità del ragionamento esposto dipende dal modello e dal pianificatore, ma quando disponibili queste tracce migliorano notevolmente la possibilità di debug.

L'itinerario di controllo AI generativo Einstein Trust Layer acquisisce ogni interazione generativa-intelligenza artificiale, il prompt e il testo della risposta, incluse le versioni mascherate con informazioni personali (PII), i dati di base recuperati, i punteggi di sicurezza e tossicità della risposta e i dettagli del modello LLM, tutti trasmessi e archiviati in Data 360. Attivare AI generativa Einstein e Raccolta e archiviazione dati di feedback per acquisire i dati di controllo e feedback in Data 360, dove è possibile eseguirne query e analisi con i rapporti di Data 360 per la conservazione a lungo termine.

Esempio:

Bene: Registri delle conversazioni archiviati in oggetti Salesforce personalizzati con campi per l'input dell'utente, la risposta dell'agente, le azioni intraprese, il consumo di token e l'esito della conversazione. Il cruscotto digitale mostra le percentuali di successo delle conversazioni per agente e caso d'uso. Meglio: La registrazione completa include tracce di ragionamento che mostrano il processo decisionale dell'agente, il contesto recuperato che mostra le risposte basate sulle informazioni e i punteggi di confidenza che indicano incertezza. Meglio: L'analisi delle conversazioni correla il comportamento degli agenti ai risultati aziendali, identifica le opportunità di miglioramento tramite l'analisi degli schemi e alimenta le opportunità di apprendimento continuo con esempi con etichetta di qualità.

Monitorare le prestazioni operative assicurando che gli agenti soddisfino i livelli di servizio e operino entro i parametri previsti.

La latenza della risposta tiene traccia del tempo end-to-end dall'input dell'utente alla risposta dell'agente. La latenza influisce direttamente sull'esperienza utente. Misurare la latenza ai percentili (p50, p95, p99) rivelando le prestazioni tipiche e le esperienze peggiori. Avviso quando la latenza p95 supera le soglie che indica un peggioramento delle prestazioni.

I fattori di latenza per gli agenti includono il tempo di inferenza del modello, la durata del recupero di dati e contesto, l'esecuzione di strumenti e azioni esterni e la latenza di rete. Strumentare ogni fase separatamente abilitando l'ottimizzazione mirata quando la latenza complessiva supera gli obiettivi.

Il consumo di token misura i token utilizzati per conversazione, per agente e per caso d'uso. Il consumo di token determina i costi di inferenza e influisce sul tempo di risposta (più token richiedono più calcolo dell'inferenza). Tenere traccia della distribuzione dei token che rivela se l'utilizzo effettivo corrisponde alle proiezioni. Rileva conversazioni anomale che consumano token eccessivi suggerendo problemi immediati o un uso improprio.

Le metriche dei token includono token di prompt (input al modello), token di completamento (output del modello) e token totali (somma di prompt e completamento). I token di prompt sono più controllabili dei token di completamento. Ottimizzare i prompt e il contesto recuperato riducendo il consumo di token prompt mantenendo la qualità.

Il monitoraggio della produttività tiene traccia delle conversazioni simultanee, delle richieste al secondo e delle tendenze del volume delle conversazioni e può aiutare a prevedere i requisiti di capacità e scalabilità. Confrontare la produttività corrente con i limiti di traffico noti o le linee di base di capacità che avvisano quando si avvicinano alle soglie.

Il tracciamento del tasso di errore monitora gli errori in base al tipo, inclusi gli errori specifici del modello, gli errori di timeout, gli errori di autorizzazione negata e gli errori di integrazione esterna. Gli schemi di errore rivelano problemi sistematici che richiedono una correzione. Calcolare le percentuali di errore come percentuale del totale delle richieste abilitando il confronto tra agenti e periodi di tempo.

Distinguere le categorie di errore che richiedono risposte diverse. Gli errori specifici del modello possono richiedere correzioni immediate o passare a un modello migliore. Gli errori di autorizzazione richiedono modifiche della configurazione di sicurezza. Gli errori di integrazione richiedono un'analisi del sistema esterno o l'attivazione di un interruttore.

Il monitoraggio della disponibilità misura il tempo di attività degli agenti e i periodi di funzionamento riusciti. Calcolare la disponibilità come percentuale di tempo in cui gli agenti rispondono correttamente alle richieste. Tenere traccia della disponibilità rispetto agli obiettivi del livello di servizio (SLO), abilitando una risposta proattiva quando la disponibilità scende al di sotto dei target.

Proactive Monitoring valuta la presenza di anomalie della piattaforma e problemi di utilizzo delle risorse che possono influire sullo stato dell'infrastruttura degli agenti. Fa emergere i segnali prima che vengano inoltrati al livello superiore in problemi visibili agli utenti. Utilizzarlo per anticipare le condizioni a livello di infrastruttura, ad esempio l'attività API insolita o il consumo di risorse che tende verso i limiti della piattaforma, che potrebbero peggiorare le prestazioni degli agenti. Esaminare i segnali rispetto alla normale base di riferimento operativa degli agenti per poter distinguere le anomalie fruibili dalla variazione prevista.

Monitorare continuamente la qualità della risposta, rilevando il degrado prima che influisca sui risultati aziendali. Quando la piattaforma offre strumenti di valutazione integrati, utilizzarli al posto di processi personalizzati o manuali. Iniziare con gli strumenti di test e valutazione nativi. Centro test Agentforce consente di gestire gli insiemi di casi di test riutilizzabili e di eseguire gli agenti in batch, verificando se l'agente ha selezionato l'argomento e l'azione previsti e ha prodotto una risposta accettabile anziché creare ed eseguire il proprio cablaggio di test. Supporta anche i valutatori nativi, incluse le dimensioni di qualità pronte all'uso e un approccio LLM-as-judge per il calcolo del punteggio della qualità della conversazione, e consente di creare valutatori personalizzati per criteri specifici dell'organizzazione. Utilizzare conversazioni rappresentative negli insiemi di test in modo che la valutazione rifletta l'utilizzo reale.

L'accuratezza della risposta misura se le risposte degli agenti contengono informazioni corrette. Una valutazione accurata richiede asserzioni con risposta nota o un riesame umano. Per le domande fattuali con risposte note, la valutazione automatica confronta le risposte degli agenti con le risposte corrette; conservarle come casi di test nel Centro test per una valutazione ripetibile. Per le domande a risposta aperta, i valutatori umani valutano la precisione delle conversazioni campionate. Tenere traccia delle tendenze della precisione nel tempo, rivelando se modifiche rapide, aggiornamenti del modello o modifiche della Knowledge Base migliorano o peggiorano le prestazioni.

La pertinenza della risposta misura se le risposte degli agenti rispondono alle domande degli utenti in modo appropriato anche se non sono perfettamente accurate. Le risposte pertinenti comprendono l'intento dell'utente e forniscono informazioni utili anche quando non è possibile una risposta completa. Valutare la pertinenza tramite valutatori nativi, se disponibili, revisione umana delle conversazioni campionate e dei segnali degli utenti. Per gli agenti basati su una Knowledge Base, l'analisi della qualità di recupero nativa può valutare la pertinenza del contesto, la pertinenza delle risposte e la fedeltà (fondatezza) delle risposte.

I guardrail rilevano risposte non sicure, inappropriate o dannose, tra cui distorsioni, contenuti offensivi, consigli pericolosi e risposte fuori dall'ambito. Einstein Trust Layer applica il rilevamento della tossicità alle interazioni LLM in fase di esecuzione, che è la prima linea di difesa. Migliorare il monitoraggio della sicurezza attraverso filtri dei contenuti, campionamenti manuali delle revisioni, meccanismi di segnalazione degli utenti e controlli dell'equità che valutano la distribuzione dei risultati tra i gruppi demografici.

Le metriche di soddisfazione degli utenti acquisiscono la qualità soggettiva dell'esperienza. Il feedback Agentforce confluisce nei modelli di dati generativi di Controllo AI e Feedback di Einstein (GenAIFeedback/GenAIFeedbackDetail in Data 360). Questi modelli acquisiscono segnali utente espliciti (pollice su/giù, accettazione/rifiuto, modifiche e commenti integrali) da una fonte umana o di sistema, insieme alla richiesta gateway e ai dati di generazione.Acquisire feedback espliciti (domanda prima dell'inoltro al livello superiore, dopo la fine di una conversazione e tramite sondaggi di follow-up) dove necessario e combinare segnali espliciti e impliciti per una prospettiva di qualità completa.

Salesforce fornisce varie superfici del modello. Il livello generativo fornisce gli elementi di ragionamento conversazionale eseguiti dagli agenti: I modelli ospitati da Agentforce offrono un ragionamento pronto all'uso all'interno del confine Trust Salesforce e portano i propri link LLM (BYOLLM) a LLM o provider esterni. Il livello predittivo fornisce i punteggi strutturati su cui gli agenti basano le loro decisioni: BYOM estrae i punteggi predittivi a copia zero dalle piattaforme ospitate esternamente e i modelli Einstein nativi producono punteggi e classificazioni automatici sugli oggetti CRM. Insieme, queste superfici consentono a un agente autonomo di ragionare in linguaggio naturale, basando il flusso di lavoro su dati statistici strutturati.

Monitorare la fluttuazione del modello, che indica prestazioni deteriorate nel tempo o condizioni variabili che richiedono un adattamento. Rivedere le note di rilascio e testare i casi d'uso critici in un Sandbox prima che ogni rilascio principale venga reso disponibile per la produzione. Utilizzare la matrice di rilascio e la finestra di anteprima Sandbox per individuare tempestivamente i problemi di compatibilità.

La deriva delle prestazioni si verifica quando la precisione, la pertinenza o la sicurezza degli agenti peggiorano nel tempo. Monitorare le metriche di qualità nel tempo rilevando cali statisticamente significativi. La fluttuazione delle prestazioni può essere il risultato di un deterioramento del modello, di una stasi della Knowledge Base, di un rapido disallineamento con i modelli di utilizzo che cambiano o di una fluttuazione del concetto in cui le relazioni tra gli input e gli output desiderati evolvono.

Stabilire le prestazioni di base immediatamente dopo la distribuzione iniziale dell'agente misurando l'accuratezza, la pertinenza, la sicurezza e la soddisfazione nei casi di test rappresentativi. Rivalutare periodicamente rispetto agli stessi casi di test rilevando modifiche delle prestazioni indipendentemente dai turni dello schema di utilizzo.

Avvisa quando le metriche di qualità diminuiscono oltre le soglie accettabili. Definire soglie basate sulla tolleranza dell'impatto aziendale. Alcuni casi d'uso tollerano un modesto deterioramento della qualità; altri richiedono una risposta immediata a qualsiasi declino.

La deriva della distribuzione si verifica quando gli schemi di input degli utenti cambiano in modo significativo rispetto all'addestramento o alla regolazione delle distribuzioni dei dati. La fluttuazione della distribuzione peggiora le prestazioni quando gli agenti incontrano tipi di input che non sono stati progettati per gestire. Monitorare le caratteristiche di input, tra cui la lunghezza delle domande, la distribuzione degli argomenti, la complessità della lingua e la terminologia del dominio, rilevando cambiamenti significativi.

Confrontare le distribuzioni degli input correnti con i valori di riferimento storici. Turni di distribuzione di grandi dimensioni possono indicare nuovi casi d'uso, cambiamenti nel comportamento degli utenti o processi aziendali in evoluzione. I turni di distribuzione possono richiedere aggiornamenti rapidi, espansione della Knowledge Base o miglioramenti delle funzionalità degli agenti.

La deriva comportamentale si verifica quando gli schemi di risposta degli agenti cambiano in modo imprevisto. Monitorare le caratteristiche delle risposte, tra cui la durata media delle risposte, le percentuali di chiamata delle azioni, le frequenze di inoltro al livello superiore e gli schemi di errore. Modifiche comportamentali significative possono indicare problemi urgenti, problemi del modello o modifiche del sistema sottostanti.

Stabilire i valori di riferimento comportamentali nelle prime fasi della produzione, acquisendo le normali caratteristiche operative, ad esempio schemi di prestazioni regolari, utilizzo degli utensili e percorsi decisionali. Questi valori di riferimento diventano il benchmark con cui il rilevamento dell'anomalia misura in seguito. Confrontare il comportamento in corso con i valori di riferimento, avvisando quando le deviazioni superano la variazione prevista.

L'avviso automatico abilita la risposta proattiva alla deriva. Configurare gli avvisi che vengono attivati quando le metriche di fluttuazione superano le soglie attivando indagini e potenziali rimedi, inclusi perfezionamento rapido, aggiornamenti della Knowledge Base, espansione dell'insieme di test o addestramento del modello BYOM.

Rileva automaticamente comportamenti insoliti degli agenti che richiedono un'indagine.

Anomalie dei costi, tra cui picchi di consumo dei token, aumenti del tasso di inferenza o accelerazione del costo totale. I picchi di costo possono indicare problemi immediati che causano una generazione eccessiva di token, abusi o usi impropri che determinano un utilizzo imprevisto o problemi dell'infrastruttura che causano chiamate ridondanti.

Monitorare le distribuzioni del consumo di token che rilevano le conversazioni anomale. Esaminare le conversazioni che consumano 10 volte il conteggio tipico dei token per capire se rappresentano casi limite legittimi o problemi che richiedono una risoluzione.

Picchi di tassi di errore che includono aumenti improvvisi delle percentuali di errore, la comparsa di nuovi tipi di errore che non esistevano nella base di riferimento o concentrazioni di errori localizzate che interessano utenti, agenti o casi d'uso specifici. I picchi di errore spesso precedono i problemi di deterioramento della qualità che i clienti possono vedere. Il rilevamento proattivo consente la riparazione prima dell'impatto generale.

Modifiche dello schema di risposta, inclusi cambiamenti improvvisi nella lunghezza della risposta, nella frequenza di chiamata delle azioni o nella percentuale di inoltro al livello superiore. Le modifiche degli schemi possono indicare problemi urgenti, modifiche del comportamento del modello o modelli di utilizzo in evoluzione.

L'abbandono delle conversazioni aumenta quando gli utenti abbandonano le conversazioni con percentuali più elevate, il che suggerisce una riduzione della qualità, un aumento della latenza o lacune di funzionalità. Tenere traccia dell'abbandono in base alla fase della conversazione, identificando se gli utenti lo abbandonano durante l'interazione iniziale, a metà conversazione o dopo il completamento di un'operazione. Gli schemi di abbandono rivelano opportunità di miglioramento specifiche.

Progettare un'architettura di avviso che bilancia la notifica rapida con l'affaticamento degli avvisi. Instradare immediatamente gli errori critici degli agenti ai tecnici su chiamata. Instradare gli avvisi di degrado della qualità ai team di prodotto per l'analisi durante l'orario di ufficio. Aggregare le anomalie minori in rapporti giornalieri per l'analisi del trend.

Prompt di controllo delle versioni, configurazioni e metadati del modello che abilitano il rollback, i test A/B e la manutenzione dell'itinerario di controllo.

I modelli di prompt sono prompt riutilizzabili creati nel Generatore di prompt che definiscono l'obiettivo, i vincoli e le linee guida del marchio dell'agente, oltre a segnaposto per i dati di base dinamici, ad esempio i dettagli del cliente o del prodotto. Memorizzare i modelli di prompt in Git insieme al codice dell'applicazione, trattando i prompt come logica dell'applicazione critica che meritano lo stesso rigore del codice. Le modifiche del prompt passano attraverso la revisione del codice, i test e la distribuzione controllata.

Utilizzare il Generatore di prompt per lo sviluppo iterativo dei prompt con cronologia delle versioni e funzionalità di test. Quando si utilizzano i modelli di prompt come azioni degli agenti, visualizzare in anteprima il modello nel Generatore di prompt per verificare che i campi di unione vengano risolti correttamente. Utilizzare quindi il Centro test per eseguire test end-to-end che confermano che l'agente seleziona l'azione e genera gli output corretti.

Esportare i prompt pronti per l'uso in produzione nel controllo di versione creando una sincronizzazione tra lo sviluppo Generatore di prompt e le opportunità di distribuzione controllate dalla fonte.

La gestione delle configurazioni tiene traccia della selezione del modello, delle impostazioni di temperatura, delle configurazioni di recupero e dei flag delle funzioni. Memorizzare le configurazioni come codice in modo da poter utilizzare valori specifici dell'ambiente, automatizzare le distribuzioni e rilevare la fluttuazione della configurazione.

Il controllo semantico si applica ai rilasci degli agenti. Le versioni principali indicano modifiche non riuscite, ad esempio contratti di input/output modificati o comportamenti significativamente modificati. Le versioni secondarie indicano aggiunte di funzioni o miglioramenti che mantengono la compatibilità. Le versioni patch indicano correzioni di bug. La numerazione delle versioni comunica l'impatto delle modifiche ai team operativi e agli utenti.

Implementare il controllo semantico delle versioni per i componenti degli agenti, inclusi modelli di prompt, configurazioni degli agenti e Knowledge Base. I numeri di versione nei registri consentono la correlazione degli incidenti con distribuzioni specifiche.

La documentazione sulle modifiche acquisisce la motivazione per modifiche rapide, modifiche delle configurazioni e aggiornamenti del modello. Documentare che cosa è cambiato, perché è cambiato, quali test hanno convalidato la modifica e quali procedure di ritiro esistono. La documentazione sulle modifiche accelera le indagini sugli incidenti e il trasferimento Knowledge.

Gestire un registro completo delle versioni del modello, dei prompt, delle configurazioni e della cronologia di distribuzione.

Il registro del modello registra le versioni del modello distribuite, incluse la famiglia di modelli, la versione specifica, lo stato di perfezionamento, l'ambiente di distribuzione (produzione, gestione temporanea e sviluppo), la data di distribuzione e il team responsabile. Il registro fornisce un'unica fonte di dati per lo stato dell'infrastruttura degli agenti.

Il tracciamento della distribuzione registra ogni distribuzione dell'agente, incluse la versione distribuita, l'ambiente, l'indicazione oraria della distribuzione, l'utente di distribuzione, le approvazioni ottenute e l'esito della distribuzione. Utilizzare la cronologia delle distribuzioni per valutare l'impatto quando emergono problemi (ad esempio, "quali agenti sono stati distribuiti prima dell'inizio dell'incidente?") e per supportare la generazione di rapporti sulla conformità.

Il tracciamento delle dipendenze mappa le relazioni tra agenti, prompt, Knowledge Base, azioni e integrazioni. Quando la Knowledge Base condivisa viene aggiornata, il tracciamento delle dipendenze rivela quali agenti sono interessati. Quando l'integrazione esterna cambia, il tracciamento delle dipendenze identifica gli agenti interessati.

Documentare le dipendenze in modo esplicito anziché scoprirle durante gli incidenti. Creare mappe delle dipendenze gestite attraverso i processi di sviluppo e distribuzione.

Le politiche di deprecazione definiscono i cicli di vita delle versioni del modello, inclusi la durata dell'assistenza, la tempistica di deprecazione e i requisiti di migrazione. Chiare policy di deprecazione gestiscono il debito tecnico impedendo il supporto indefinito delle vecchie versioni del modello. Stabilire una pianificazione di deprecazione comunicando le tempistiche con sufficiente anticipo per consentire le migrazioni pianificate anziché le risposte di emergenza alle deprecazioni forzate. Un periodo di preavviso minimo ben comunicato e sostenuto dalla policy offre un tempo di migrazione adeguato per le modifiche critiche.

Le procedure di ritiro consentono ai team di riprendersi rapidamente dalle distribuzioni problematiche. Le procedure di ritiro dei documenti per ogni agente includono:

Condizioni che attivano un ritiro
Versione a cui ripristinare
Come eseguire il ritiro
Chi autorizza ed esegue il ritiro
Quali test confermano che il ritiro è riuscito e quali team informare.

Testare regolarmente le procedure di ritiro in ambienti non di produzione per verificare che funzionino prima di dipendere da esse durante gli incidenti di produzione. Eseguire le prove con distribuzioni fittizie in modo che il team sappia esattamente cosa fare. Le procedure di ritiro non testate spesso non riescono quando è più necessario.

Mantenere la qualità degli agenti attraverso flussi di lavoro di formazione, perfezionamento e perfezionamento continui.

La raccolta dei commenti raccoglie sistematicamente i commenti degli utenti, le correzioni delle recensioni umane, le valutazioni della qualità e le misurazioni dei risultati. Il feedback fornisce materia prima per il miglioramento. Senza una raccolta sistematica, il miglioramento diventa congettura. Raccogliere commenti espliciti tramite domande prima dell'inoltro al livello superiore, dopo la fine di una conversazione o tramite sondaggi di follow-up. Raccogliere commenti impliciti tramite percentuali di completamento, frequenze di inoltro al livello superiore e schemi di tentativo. Combinare segnali espliciti e impliciti per offrire una prospettiva di qualità completa.

Data curation mantiene serie di dati di formazione di alta qualità attraverso la gestione, la revisione della qualità e il controllo della distorsione. La qualità dei dati di addestramento determina direttamente la qualità del modello. Dati scarsi generano modelli inaffidabili; dati eccellenti consentono prestazioni eccezionali.

Gestire i registri delle conversazioni nelle serie di dati di addestramento:

Filtraggio per la qualità, incluse le conversazioni con valutazioni elevate e gli esiti positivi
Rimozione di esempi problematici, tra cui violazioni della sicurezza ed errori
Garantire la rappresentatività - compresi scenari diversi e casi limite
Deduplicazione - rimozione di esempi quasi identici

Adattare gli agenti al dominio (vocabolario specializzato, processi aziendali univoci, Knowledge specifico dell'organizzazione) principalmente tramite la generazione aumentata di recupero (RAG) basata su Data 360 e la messa a punto rapida, il percorso nativo di Salesforce.

Nessun modello generativo viene perfezionato all'interno di Salesforce; i modelli vengono selezionati e configurati tramite modelli AI e Generatore di prompt. Quando la messa a terra è insufficiente, perfezionare esternamente, quindi connettersi tramite BYOLLM.

Il perfezionamento dei prompt migliora in modo iterativo i prompt in base ai dati sulle prestazioni utilizzando il Generatore di prompt. L'ingegneria del prompt è una pratica continua piuttosto che un esercizio singolo. Man mano che gli schemi di utilizzo evolvono, che i processi aziendali cambiano e che le aspettative degli utenti cambiano, i prompt richiedono una rettifica per mantenere prestazioni ottimali.

Stabilire una cadenza periodica di revisione rapida che esamina le conversazioni recenti, le metriche di qualità e i commenti degli utenti che identificano le opportunità di miglioramento. Implementare modifiche rapide in modo incrementale con test A/B che convalidano i miglioramenti prima dell'implementazione completa.

L'automazione della valutazione esegue la valutazione della qualità sugli insiemi di test in attesa consentendo una valutazione rapida dei candidati al miglioramento. La valutazione automatica fornisce una misurazione oggettiva che integra la valutazione umana soggettiva.

Gestire gli insiemi di test che coprono i percorsi felici, i casi limite, gli input contraddittori e gli scenari di problemi storici. Impostare l'automazione dei test per eseguire gli scenari di test con cadenza regolare. Includere il monitoraggio automatico dei risultati, le soglie e le notifiche per avvisare gli amministratori delle anomalie. Questo test automatico è fondamentale per rilevare gli effetti negativi di fattori esterni come la fluttuazione del modello.

Espandere continuamente gli insiemi di test man mano che emergono nuovi casi edge in produzione. L'automazione dei test è fondamentale, ma è anche possibile eseguire controlli periodici manuali a campione, test una tantum e test gorilla per assicurarsi che la distribuzione degli agenti regga contro i casi limite.

Distribuire le modifiche degli agenti gradualmente e monitorare la qualità prima dell'implementazione completa per limitare il raggio d'azione dei problemi. Quando una modifica si estende a più aree (prompt, configurazione del modello, azioni, radicamento nel contesto, integrazioni), può compromettere il comportamento in modi che i test non hanno rilevato. Quando ciò accade, la regressione della qualità risultante raramente punta a un'unica, ovvia causa principale. Spedire le piccole modifiche una alla volta in modo che una regressione possa essere ricondotta all'origine e rilasciare prima ogni modifica a una porzione limitata di traffico per contenere l'impatto durante la diagnosi.

I flag delle funzioni separano la distribuzione dal rilascio distribuendo gli agenti con funzioni disabilitate dietro la configurazione. Implementare i flag delle funzioni utilizzando la logica o tipi di metadati personalizzati o impostazioni personalizzate. I flag delle funzioni consentono il test nell'ambiente di produzione senza esporre le funzioni agli utenti, implementazioni graduali a segmenti di utenti specifici, test A/B di confronto delle implementazioni e ritiro immediato disabilitando i flag senza ridistribuirli.

Utilizzare i flag delle funzioni per le modifiche significative degli agenti, in cui il raggio di esplosione di un guasto potrebbe essere grave, ad esempio Modifiche che interessano gli agenti business-critical, Nuovi schemi di ragionamento con comportamento di produzione incerto Integrazioni con sistemi esterni in cui gli schemi di interazione possono essere diversi dai test.

Le distribuzioni Canary rilasciano le modifiche degli agenti a piccoli sottoinsiemi di utenti monitorando prima i tassi di errore, le metriche di qualità e le prestazioni prima di un'implementazione più ampia. Utilizzare gli insiemi di autorizzazioni per controllare le distribuzioni dei canarini, limitare l'accesso degli agenti a un sottoinsieme di utenti o filtrare in base alla logica di orchestrazione in base agli attributi utente.

Monitorare e misurare le percentuali di successo, la qualità delle risposte e i commenti degli utenti. Confrontare le metriche canarino con i gruppi di controllo utilizzando la versione agente precedente. Espandere l'implementazione solo quando Canary dimostra prestazioni equivalenti o migliorate.

I test A/B confrontano le variazioni degli agenti misurando qualità, costo e soddisfazione degli utenti. I test A/B forniscono prove empiriche per le decisioni di miglioramento. Distribuire le varianti a sottoinsiemi di utenti selezionati in modo casuale per garantire la validità statistica. Misurare i risultati in più dimensioni (accuratezza, soddisfazione, costo e latenza) offrendo un confronto completo.

Definire i criteri e le ipotesi di successo prima di iniziare i test A/B. Criteri chiari evitano risultati ambigui in cui alcune metriche migliorano mentre altre peggiorano. I criteri di successo devono essere allineati agli obiettivi aziendali (ad esempio, "la variante B deve corrispondere alla precisione della variante A entro il 2% riducendo il costo del 15%").

I test Champion-challenger distribuiscono versioni degli agenti migliorate a sottoinsiemi di traffico rispetto alle versioni Champion correnti. Lo schema Champion-challenger gestisce il rischio di miglioramento mantenendo la versione collaudata come fallback. Se lo sfidante ha prestazioni insufficienti, tornare a Promotore senza impatto sugli utenti. Se lo sfidante supera le prestazioni, promuoverlo a nuovo campione.

Stabilire criteri di promozione obiettivi, tra cui la dimensione minima del campione per la validità statistica, le soglie di qualità che gli sfidanti devono superare e la durata della valutazione prima delle decisioni relative alla promozione. Documentare le decisioni di promozione creando un itinerario di controllo del motivo per cui le versioni degli agenti sono cambiate.

Stabilire il rilevamento degli incidenti identificando rapidamente i problemi operativi degli agenti attraverso un monitoraggio completo.

Le modalità di errore differiscono dagli errori delle applicazioni tradizionali. Le modalità di errore comuni includono:

Allucinazioni - generare informazioni plausibili ma non corrette
Risposte off-topic - intenti utente fraintendimento
Consumo eccessivo di costi - generazione di token fuori controllo
Timeout non riuscito - inferenza che richiede troppo tempo
Errori di autorizzazione - tentativo di azioni non autorizzate
Errori di integrazione - indisponibilità del sistema esterno
Violazioni della sicurezza - generazione di contenuti inappropriati

Rilevamento degli errori tramite il monitoraggio automatico che avvisa sui tassi di errore, sul degrado delle metriche di qualità, sulle anomalie dei costi, sugli aumenti di latenza e sugli inoltri al livello superiore degli utenti. Integrare i meccanismi di auto-segnalazione degli utenti, incluse le richieste di feedback e indicazioni chiare su come e dove fornire feedback, in modo da poter correggere le lacune segnalate nell'automazione.

La classificazione della gravità instrada gli incidenti ai soccorritori appropriati con la dovuta urgenza. Gli incidenti critici indicano l'indisponibilità della produzione che interessa molti utenti, il rischio di danneggiamento dei dati a causa di azioni degli agenti, la compromissione della sicurezza o violazioni della sicurezza che richiedono una risposta immediata. Un livello di gravità elevato indica un peggioramento della qualità che colpisce gli agenti business-critical o un superamento significativo dei costi. La gravità media indica problemi isolati o soglie prossime che richiedono un'indagine durante l'orario di ufficio. Una gravità bassa indica problemi minori rilevati all'esterno del processo di gestione degli incidenti.

Definire i criteri di gravità in modo obiettivo in base all'impatto dell'utente, al raggio di esplosione, al rischio di integrità dei dati e all'urgenza del ripristino. I criteri oggettivi evitano di sottovalutare i problemi reali e di esagerare i problemi minori. Mantenere la documentazione sui risultati della risoluzione degli incidenti per migliorare continuamente il processo.

Le procedure di risposta guidano le azioni immediate che stabilizzano la situazione. Le procedure includono:

Disabilita attivazione agente guasto - interruttore
Instradare gli utenti alle opzioni di fallback - passaggio di consegne umano, agente più semplice, risposte statiche
Raccogliere informazioni diagnostiche - conversazioni recenti, registri errori, metriche delle risorse
Avvisare gli stakeholder - tecnici su chiamata, titolari di prodotti, utenti interessati
Avvia comunicazione incidente - aggiornamenti della pagina di stato, canali di coordinamento interni
Documentare le procedure di risposta iniziale come runbook che consentono un'esecuzione rapida senza richiedere indagini specifiche sull'incidente.
I runbook devono essere eseguibili da tecnici su chiamata senza una profonda esperienza degli agenti.

Impedire errori a catena e mantenere una funzionalità parziale durante gli incidenti degli agenti.

Lo schema dell'interruttore disabilita automaticamente gli agenti in errore impedendo errori ripetuti e l'impatto degli utenti durante la risoluzione dei problemi. Implementare gli interruttori automatici per monitorare i tassi di errore e l'apertura (agente disabilitante) quando il tasso di errore supera la soglia per un periodo prolungato.

Configurare gli interruttori automatici con soglia di errore, finestra di durata e test di ripristino. Ad esempio, una percentuale di errore del 50% con una finestra continuativa di cinque minuti e una prova periodica che richiede di verificare se l'agente ha recuperato. All'apertura del circuito, instradare le richieste alle opzioni di fallback. Dopo un periodo di timeout, il circuito passa a uno stato semiaperto che consente il passaggio delle richieste di prova. Quando le richieste di prova hanno esito positivo, chiudere il circuito riprendendo il normale funzionamento.

Le gerarchie di fallback forniscono un deterioramento graduale quando gli agenti principali hanno esito negativo. Progettare sequenze di fallback tentando opzioni sempre più semplici fino a ottenere una risposta accettabile. Esempio di gerarchia di fallback: Agente sofisticato principale → Agente di backup più semplice → Risposte alle domande frequenti statiche → Passaggio di consegne umano.

Implementare la logica di fallback nel livello di orchestrazione anziché all'interno degli agenti abilitando un comportamento coerente in tutto l'ecosistema degli agenti. Testare regolarmente i percorsi di fallback verificandone il funzionamento quando necessario.

La consegna umana viene inoltrata agli agenti umani quando gli agenti AI non possono gestire le richieste. Progettare flussi di lavoro di trasferimento mantenendo il contesto della conversazione, comunicando il motivo del trasferimento, instradando gli agenti umani appropriati con le competenze pertinenti e monitorando la frequenza del trasferimento rivelando opportunità di miglioramento.

Monitorare le percentuali di inoltro al livello superiore per argomento, agente e motivo dell'errore. Percentuali più elevate indicano lacune di capacità degli agenti che richiedono miglioramenti immediati, espansione della Knowledge Base o perfezionamento dei casi d'uso.

Il grazioso degrado mantiene una funzionalità parziale durante il funzionamento degradato. Quando il ragionamento sofisticato non riesce, tornare a una logica più semplice. Quando i dati in tempo reale non sono disponibili, utilizzare i dati memorizzati nella cache. Quando le integrazioni esterne non riescono, operare in modalità di sola lettura. La degradazione graziosa consente a un sistema di continuare a funzionare con una capacità ridotta anziché guastarsi completamente.

Eseguire revisioni post-incidente senza colpe concentrandosi sui miglioramenti del sistema anziché sulla colpa individuale che crea sicurezza psicologica per una valutazione onesta.

La ricostruzione della sequenza temporale crea una sequenza dettagliata dalle condizioni iniziali fino al primo segnale, rilevamento, conferma, indagine, azioni di risposta, ripristino e convalida. Indicare l'ora di ogni evento abilitando l'analisi della durata di ogni fase che rivela dove la risposta all'incidente è stata ritardata.

Includere i seguenti elementi nella sequenza temporale:

Che cosa è stato distribuito di recente (prompt, configurazioni, modelli, integrazioni)?
Quali cambiamenti negli schemi di utilizzo (aumento improvviso del traffico, nuovi tipi di conversazione) sono stati osservati?
Quali fattori esterni hanno contribuito (degrado del servizio di terze parti, aggiornamenti della piattaforma)?
Cosa ha reso il rilevamento più lento dell'ideale?

L'identificazione causa principale determina la causa tecnica diretta. Distinguere la causa immediata (timeout del modello) dai fattori che contribuiscono (progettazione del prompt che supera i limiti del token in schemi di conversazione specifici). L'analisi della causa principale impedisce conclusioni semplicistiche ("l'agente aveva un bug") a favore di risultati specifici che risultano in una risoluzione efficace.

Utilizzare la tecnica "Five Whys", esercitando dai sintomi alle cause fondamentali.

Esempio di superficie: "L'agente ha prodotto informazioni non corrette" → "Perché? Il contesto recuperato conteneva dati non aggiornati" → "Perché? La Knowledge Base non è stata aggiornata con le modifiche recenti dei prodotti" → "Perché? Non esiste alcun processo per il team di prodotto che attiva gli aggiornamenti della Knowledge Base" → Flusso di lavoro mancante che collega i rilasci prodotto alla manutenzione della Knowledge Base.

I fattori che contribuiscono rivelano le condizioni organizzative, di processo o architettoniche che consentono o amplificano l'impatto degli incidenti. I fattori comuni includono lacune di monitoraggio che consentono ai problemi di persistere più a lungo di quanto rilevato, lacune nei test che lasciano scoperti scenari di errore, lacune nella documentazione che rallentano la diagnosi rapida, lacune nell'automazione che costringono a fasi di ripristino manuali e lacune architetturali come singoli punti di errore o ridondanza mancante.

L'analisi dei fattori che contribuiscono rivela le opportunità di miglioramento oltre la correzione immediata della causa principale. La maggior parte degli incidenti ha più fattori che contribuiscono, ciascuno dei quali amplifica l'impatto.

L'analisi del rilevamento esamina come è stato rilevato l'incidente e se il rilevamento avrebbe potuto essere più rapido. Molti incidenti degli agenti vengono segnalati per la prima volta dagli utenti anziché dal monitoraggio automatico, il che indica una lacuna nel monitoraggio. Determinare: Quale segnale avrebbe dovuto rilevare il problema prima? Quale monitoraggio consentirebbe un rilevamento più rapido? Quali criteri di avviso sarebbero stati attivati in modo appropriato?

I miglioramenti dell'analisi del rilevamento includono: Aggiunta della copertura di monitoraggio mancante, ottimizzazione delle soglie di avviso eliminando i falsi negativi, arricchimento del contesto degli avvisi per un triage più rapido e miglioramento dei cruscotti digitali per l'identificazione proattiva dei problemi.

La valutazione della risposta valuta cosa è andato bene e cosa è stato più lento o più difficile del necessario. Domande di valutazione della risposta: I runbook sono stati utili e precisi? I percorsi di inoltro al livello superiore erano chiari ed efficaci? Le procedure di ritiro sono state testate e pronte? Gli strumenti hanno fornito le informazioni diagnostiche necessarie? La comunicazione è stata tempestiva ed efficace?

I miglioramenti della valutazione della risposta includono: aggiornamento dei runbook con le lezioni apprese, chiarimento dei criteri di inoltro al livello superiore, test periodico delle procedure di ritiro, aggiunta di strumenti diagnostici e miglioramento dei modelli di comunicazione degli incidenti.

Le voci azione specificano miglioramenti concreti, assegnati e limitati nel tempo che impediscono la ricorrenza o migliorano la risposta futura. Evitare voci azioni vaghe come "migliora monitoraggio" a favore di operazioni specifiche come "aggiungi avviso per la percentuale di errore degli agenti superiore al 5% in un periodo di 10 minuti, assegnate: Alex, due: 2 settimane.".

Tenere traccia del completamento degli elementi azione nelle revisioni successive per garantire che il miglioramento continuo avvenga davvero. Esaminare le voci azioni aperte degli incidenti precedenti durante ogni riesame post-incidente. Le basse percentuali di completamento indicano un errore continuo del processo di miglioramento che richiede attenzione.

La condivisione Knowledge documenta le revisioni post-incidente in wiki condivise, Knowledge Base o spazio di collaborazione con tag che abilitano l'analisi degli schemi in più incidenti. Le retrospettive degli incidenti devono essere ricercabili in base alla modalità di guasto, ai componenti interessati e al periodo di tempo, consentendo ai futuri soccorritori di imparare dagli incidenti storici.

Condividere le revisioni post-incidente in generale oltre i soccorritori diretti. L'apprendimento organizzativo richiede la propagazione delle informazioni. Valutare la possibilità di presentare gli apprendimenti sugli incidenti gravi in riunioni di team o sessioni di pranzo e apprendimento per diffondere Knowledge e sviluppare capacità collettive.

Richiedere l'approvazione prima di distribuire gli agenti di produzione per garantire la revisione, la valutazione del rischio e l'allineamento degli stakeholder.

L'elenco di controllo convalida la preparazione, inclusi:

Test completi completati - funzionalità, qualità, sicurezza, prestazioni
Revisione della sicurezza approvata - limiti delle autorizzazioni, accesso ai dati, autorizzazione delle azioni
Conformità convalidata - requisiti normativi, osservanza delle policy
Documentazione completa - runbook, procedure di ritiro, percorsi di inoltro al livello superiore
Monitoraggio configurato - metriche di qualità, percentuali di errore, tracciamento dei costi
Approvazione degli stakeholder ottenuta - titolare del prodotto, sicurezza, conformità

L'elenco di controllo fornisce criteri di valutazione coerenti tra gli agenti. Adattare l'elenco di controllo per il profilo di rischio dell'agente con profondità variabile in base alla criticità dell'agente, alla riservatezza dei dati e al livello di autonomia.

La valutazione del rischio valuta il potenziale impatto degli errori degli agenti, tra cui:

Raggio di esplosione - quanti utenti interessati da un errore
Sensibilità dei dati: a quale agente dati accede
Autorità di azione: le modifiche che l'agente può apportare
Dipendenze di integrazione - influenza dell'agente di sistema
Complessità del ripristino: quanto è difficile il ritiro
Implicazioni di conformità - quali regolamenti si applicano

La valutazione del rischio determina i requisiti di approvazione. Gli agenti ad alto rischio richiedono l'approvazione esecutiva, la revisione della sicurezza e l'implementazione graduale, mentre gli agenti a basso rischio possono richiedere la revisione tra pari e test standard.

I flussi di lavoro instradano le richieste di distribuzione tramite esaminatori appropriati. Implementare i flussi di lavoro di approvazione utilizzando i processi di approvazione Salesforce o strumenti di distribuzione esterni. Automatizzare, monitorare e controllare i flussi di lavoro di approvazione per consentire la generazione di rapporti sulla conformità e l'analisi degli incidenti.

Documentare le decisioni di approvazione, creare un itinerario di controllo di chi ha approvato le distribuzioni, quali informazioni hanno informato le approvazioni, quali condizioni o restrizioni sono state applicate e quali impegni di monitoraggio sono stati assunti.

Le procedure di bypass consentono una distribuzione rapida durante gli incidenti di produzione quando i normali processi di approvazione ritardano le correzioni critiche. Le procedure di emergenza devono richiedere l'approvazione esecutiva, includere la documentazione giustificativa e attivare un riesame post-distribuzione rapido per convalidare le modifiche di emergenza.

Tenere traccia delle distribuzioni di emergenza separatamente dai rilasci standard. L'elevata frequenza di distribuzione indica problemi del processo che richiedono un'analisi.

Definire i gate di qualità che gli agenti devono superare prima della distribuzione in produzione per impedire agli agenti problematici di raggiungere gli utenti.

I test funzionali confermano che gli agenti eseguono correttamente le operazioni previste in scenari rappresentativi. Testare i percorsi felici che coprono le interazioni tipiche, i casi limite che coprono scenari rari ma validi, i percorsi di errore che verificano se gli agenti gestiscono gli input non validi in modo fluido e le condizioni al contorno che verificano se l'agente rientra nei limiti del governor, nei limiti dei token e nei limiti del volume di dati.

I test funzionali per gli agenti si differenziano dai test tradizionali perché gli output non deterministici impediscono la corrispondenza esatta. Caratteristiche dell'output del test (contiene le informazioni richieste, mantiene il tono appropriato, include le citazioni necessarie) anziché il testo esatto.

Il test qualità risposta valuta la precisione e la pertinenza della risposta negli scenari di test. I test di qualità richiedono una valutazione umana o serie di dati di verità con gli output previsti. Stabilire soglie minime di qualità che gli agenti devono soddisfare (ad esempio, "accuratezza del 95% sul set di test di resistenza, zero violazioni della sicurezza, controllo dell'equità non mostra disparità demografiche superiori al 5%"). Mantenere ed espandere continuamente gli insiemi di test man mano che vengono rilevati nuovi casi limite.

I test di sicurezza confermano che gli agenti rifiutano richieste pericolose, non etiche o fuori dall'ambito. I test di sicurezza tentano input contraddittori, tra cui:

Prompt injection - tentativo di ignorare le istruzioni
Tentativi di jailbreak - tentativo di aggirare i vincoli di sicurezza
Richiesta di inoltro al livello superiore - richiesta di azioni sempre più sensibili
Richieste fuori dall'ambito - tentativo di operazioni non autorizzate

Assegnare i test di sicurezza ai membri del team indipendenti che non hanno partecipato alla creazione dell'agente. Per gli agenti ad alto rischio, chiamare gli specialisti del team rosso.

I test delle prestazioni convalidano la latenza, la produttività e i costi che soddisfano le aspettative. Eseguire il test sotto carico realistico, incluse le conversazioni simultanee, la durata tipica delle conversazioni e il volume di utilizzo previsto. I test delle prestazioni rilevano problemi di limiti del governor, vincoli delle risorse e colli di bottiglia di scalabilità invisibili nei test per utente singolo.

Misurare il consumo dell'ambiente di test durante i test delle prestazioni e utilizzarlo per prevedere le esigenze di capacità di produzione.

I test di sicurezza convalidano i confini delle autorizzazioni, i controlli di accesso ai dati e l'autorizzazione delle azioni. I test di sicurezza confermano: gli agenti non possono accedere a dati non autorizzati, gli agenti non possono eseguire azioni non autorizzate, l'iniezione rapida non può inoltrare i privilegi al livello superiore e la registrazione di controllo acquisisce tutte le attività degli agenti.

Integrare la scansione della sicurezza del codice statico nella pipeline di distribuzione utilizzando Salesforce Code Analyzer, che analizza Apex, Flussi, Lightning e Visualforce per individuare vulnerabilità di sicurezza e può essere eseguito in integrazione/distribuzione continua (CI/CD) tramite l'interfaccia della riga di comando (CLI) o l'azione GitHub. Utilizzare test di sicurezza AI/agente specializzati per rilevare vulnerabilità di prompt injection e rischi di esposizione ai dati sensibili, poiché si tratta di minacce di input LLM in fase di esecuzione che non rientrano nell'ambito dell'analisi del codice statico.

Applicare la disciplina di gestione del cambiamento alle distribuzioni degli agenti assicurando che le modifiche vengano documentate, riviste e comunicate.

La documentazione di modifica acquisisce:

Che cosa è cambiato - modifiche richieste, aggiornamenti della configurazione, modifiche del modello
Perché è stata apportata quella modifica - miglioramento della qualità, ottimizzazione dei costi, correzione dei bug
Quali test hanno convalidato la modifica - risultati dei test, punteggi di qualità, analisi di sicurezza
Quale procedura di ritiro esiste

La documentazione sulle modifiche consente indagini sugli incidenti, rapporti sulla conformità e trasferimento Knowledge. Le modifiche documentate creano un'organizzazione di apprendimento basata sull'esperienza precedente anziché riscoprire le lezioni.

La pianificazione delle comunicazioni notifica alle parti interessate le modifiche apportate agli agenti, inclusi gli utenti interessati, i team operativi, i team di assistenza e gli stakeholder aziendali. La comunicazione deve descrivere: che cosa sta cambiando, quando avviene il cambiamento, quali vantaggi vedranno gli utenti, quali rischi esistono e chi contattare per i problemi.

Stabilire modelli di comunicazione per diversi tipi di modifiche standardizzando i messaggi e riducendo il sovraccarico di preparazione alla distribuzione.

La pianificazione della distribuzione calcola i tempi di distribuzione degli agenti durante i periodi di basso utilizzo in base ai dati di Monitoraggio evento che mostrano gli schemi di utilizzo effettivi. Evitare le distribuzioni durante i picchi di utilizzo, la chiusura di fine mese, la chiusura di fine trimestre o i principali eventi aziendali. Comunicare le finestre di distribuzione, incluse la durata prevista e la tempistica delle decisioni di ritiro.

Valutare la possibilità di pianificare modifiche importanti per la settimana da inizio a metà ed evitare distribuzioni a settimana inoltrata, in modo che i problemi possano essere risolti con risorse adeguate. Assegnare la priorità al ritiro rapido e al monitoraggio post-distribuzione rispetto a qualsiasi regola di calendario fissa.

Cambiare finestre e congelamenti per proteggere periodi di attività critici. Stabilire periodi di congelamento delle modifiche prima dei principali eventi aziendali (fine anno fiscale, lancio di prodotti e campagne di marketing importanti) per evitare problemi dovuti alla distribuzione durante i periodi con rischi elevati.

Le modifiche dei documenti bloccano il calendario ogni anno comunicando i periodi di restrizione con sufficiente anticipo, consentendo ai team di pianificare di conseguenza. Congelamenti eccessivi rallentano la velocità; congelamenti insufficienti creano rischi per l'azienda.

Stabilire cicli di feedback che collegano la telemetria operativa al miglioramento degli agenti.

La raccolta dei commenti raccoglie commenti espliciti tramite domande o sondaggi di follow-up. Raccogliere commenti impliciti tramite percentuali di completamento, inoltro al livello superiore agli agenti umani, schemi di nuovo tentativo e domande di follow-up che indicano insoddisfazione. Combinare segnali espliciti e impliciti, offrendo una prospettiva di qualità completa.

Raccogliere i commenti in linea, proprio quando si verificano e non in seguito. La raccolta di feedback ritardata riduce le percentuali di risposta e introduce una distorsione del richiamo.

**Le analisi dell'**utilizzo mostrano modelli di conversazione reali come argomenti, domande e tendenze ricorrenti. Verificano se la complessità di un agente si guadagna da vivere, se le funzionalità non vengono utilizzate a causa della scarsa individuabilità e se l'utilizzo reale convalida i presupposti di progettazione originali.

Eseguire query nei registri delle conversazioni analizzando i tipi di domande, la durata delle conversazioni, le percentuali di successo per argomento e la soddisfazione degli utenti per caratteristiche della conversazione. L'analisi degli schemi di utilizzo guida il rapido perfezionamento, l'espansione della Knowledge Base e l'assegnazione delle priorità alle funzionalità.

L'analisi degli schemi di errore identifica i problemi di qualità sistematici che richiedono una correzione. Analizzare i registri errori raggruppandoli per tipo di errore, utenti interessati, schemi di conversazione e distribuzione temporale. Gli schemi di errore rivelano problemi immediati, lacune della Knowledge Base, problemi di integrazione o casi limite che richiedono una gestione.

Assegnare priorità alla correzione degli errori in base alla frequenza e all'impatto. Gli errori ad alta frequenza che interessano molti utenti richiedono un'attenzione immediata. Gli errori a bassa frequenza possono rappresentare casi limite accettabili a seconda dell'impatto sul business e del costo di riparazione.

Il monitoraggio del trend tiene traccia di precisione, pertinenza, sicurezza e soddisfazione nel tempo rilevando il degrado prima che diventi grave. Stabilire valori di riferimento per la qualità dopo la distribuzione iniziale dell'agente. Monitorare la qualità in corso rispetto ai valori di riferimento avvisando quando le tendenze diminuiscono oltre le soglie accettabili.

Il monitoraggio della qualità rivela se modifiche rapide, aggiornamenti del modello o modifiche della Knowledge Base migliorano o peggiorano le prestazioni consentendo decisioni di miglioramento basate sui dati.

Tenere traccia degli esperimenti informando sistematicamente le decisioni di miglioramento con prove empiriche.

Il framework Experiment offre una struttura coerente per testare i miglioramenti, tra cui:

Ipotesi - quale miglioramento è previsto
Progettazione sperimentale - modalità di distribuzione delle varianti
Metriche - quali risultati vengono misurati
Dimensioni del campione: quante interazioni sono necessarie per la validità statistica
Criteri di successo: quali risultati giustificano la promozione

Documentare gli esperimenti prima dell'esecuzione evitando interpretazioni ambigue dei risultati. I criteri di successo predefiniti consentono di prendere decisioni chiare sulle promozioni evitando lunghi dibattiti sulla "buona riuscita" dei risultati.

Il tracciamento delle varianti registra quali utenti hanno ricevuto quali varianti abilitando la correlazione dei risultati. Tenere traccia dell'assegnazione delle varianti nei metadati della conversazione abilitando l'analisi di qualità, costo e soddisfazione per variante.

La validità statistica garantisce che gli esperimenti vengano eseguiti abbastanza a lungo con dimensioni del campione sufficienti per conclusioni affidabili. Calcolare le dimensioni del campione richieste prima degli esperimenti in base alle dimensioni previste dell'effetto, ai requisiti statistici di potenza e alle percentuali di errore accettabili. Campioni insufficienti producono risultati rumorosi che portano a decisioni sbagliate.

L'ottimizzazione dei banditi multi-braccio alloca dinamicamente più traffico alle varianti con prestazioni migliori durante gli esperimenti. Gli approcci basati su banditi a più bracci riducono il costo opportunità della sperimentazione riducendo l'esposizione a varianti inferiori e raccogliendo dati sufficienti per l'analisi statistica.

Il catalogo degli esperimenti registra le varianti, gli esiti e le decisioni di ogni esperimento. Impedisce ai team di ripetere i test degli approcci non riusciti, diffonde gli apprendimenti in tutta l'organizzazione e crea un record condiviso di ciò che effettivamente funziona.

L'eccellenza operativa per i sistemi agentici richiede l'estensione delle procedure DevOps tradizionali per gestire le caratteristiche di intelligenza artificiale specifiche. L'osservabilità completa consente di comprendere il comportamento degli agenti emergenti. La gestione sistematica del ciclo di vita garantisce qualità, sicurezza e controllo dei costi. Le procedure di risposta agli incidenti riguardano le modalità di errore specifiche dell'agente. Il miglioramento continuo trasforma l'esperienza operativa in capacità organizzativa.

Procedure chiave per l'eccellenza operativa nei sistemi agentici:

Registrare le conversazioni complete, inclusi input, output, tracce di ragionamento, azioni ed esiti.
Monitorare continuamente la qualità della risposta attraverso metriche di precisione, pertinenza, sicurezza e soddisfazione.
Rilevare la fluttuazione del modello e le modifiche del comportamento tramite il confronto di base e il rilevamento delle anomalie.
Prompt di controllo delle versioni, configurazioni e modelli che abilitano il rollback e i test A/B.
Implementare un'implementazione graduale con flag di funzioni e distribuzioni di canarini che limitano il raggio di esplosione.
Progettare interruttori automatici e gerarchie di fallback per evitare errori a catena degli agenti.
Eseguire revisioni post-incidente senza colpa incentrate su miglioramenti sistematici.
Stabilire cancelli di qualità e processi di approvazione per impedire agli agenti problematici di raggiungere la produzione.
Creare loop di feedback che collegano la telemetria operativa al miglioramento degli agenti.
Tenere traccia degli esperimenti in modo sistematico utilizzando prove empiriche per guidare le decisioni di miglioramento.

Le organizzazioni che investono nell'eccellenza operativa per gli agenti ottengono un vantaggio competitivo sostenibile grazie a funzionalità di intelligenza artificiale affidabili e di alta qualità che evolvono continuamente in base alle esigenze aziendali.

Condividere i propri commenti sul framework ben progettato.