Eccellenza operativa - Schemi agentici
Ulteriori informazioni su Eccellenza operativa ben progettata → Eccellenza operativa aziendale
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Agentforce | Tracciamento delle sessioni | ✅ Utilizzare il modello di dati STDM (Session Tracing Data Model) nativo per acquisire le interazioni degli agenti in un modello di dati unificato in Data 360 anziché creare un sistema di telemetria parallelo, registrando ogni conversazione come una gerarchia di traccia di sessioni, interazioni (turn) e fasi (UserInputStep, LLMExecutionStep, FunctionStep) |
| Agentforce | Tracciamento delle sessioni | ✅ Basarsi sugli oggetti STDM standard (AIAgentSession, AIAgentSessionParticipant, AIAgentInteraction, AIAgentInteractionStep, AIAgentInteractionMessage), che acquisiscono le azioni in modo nativo come fasi di interazione anziché richiedere un registro azioni separato |
| Agentforce | Tracciamento delle sessioni | ✅ Recuperare l’utilizzo del token, il modello e i dettagli del prompt unendo le fasi di interazione ai relativi record chiamata LLM (tramite GenerationId e riferimenti GenAiGatewayRequest/Response) anziché memorizzarli come campi sessione personalizzati |
| Agentforce | Tracciamento delle sessioni | ✅ Acquisizione di tracce di ragionamento dal Motore di ragionamento Atlas — Il tracciamento della sessione registra le fasi del pianificatore come parte di ogni interazione — per rivelare i processi decisionali degli agenti e migliorare la possibilità di debug |
| Agentforce | Configurazione agente | ✅ Registrare i dettagli a livello di turno tra cui l’input dell’utente, la risposta dell’agente, la spiegazione del ragionamento, i punteggi di confidenza, il contesto recuperato, le azioni tentate e gli errori incontrati |
| Einstein | Livello Trust | ✅ Attivare l’itinerario di controllo AI generativo Einstein Trust Layer (testo del prompt e della risposta, versioni con mascheramento delle informazioni personali, dati di base, punteggi di sicurezza e tossicità, dettagli del modello) in streaming su Data 360, oltre all’intelligenza artificiale generativa Einstein e alla raccolta e archiviazione dei dati di feedback per la conservazione a lungo termine |
| Piattaforma | Oggetti personalizzati | ✅ Riservare gli oggetti di registrazione personalizzati a eccezioni deliberate, ad esempio un oggetto leggero che correla il comportamento degli agenti ai risultati aziendali, anziché renderli il substrato di registrazione principale |
| Piattaforma | Cruscotto digitale | ✅ Correlare il comportamento degli agenti ai risultati aziendali, identificare le opportunità di miglioramento tramite l’analisi degli schemi e alimentare le opportunità di apprendimento continuo con esempi con etichetta di qualità |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Oggetti personalizzati | ⚠️ Creazione manuale di oggetti transazionali personalizzati come substrato principale per la registrazione delle conversazioni anziché come modello di dati di tracciamento delle sessioni nativo, incorrendo in problemi di scala che memorizzano le conversazioni a più turni, carichi utili JSON di grandi dimensioni e rapida crescita dei dati |
| Agentforce | Tracciamento delle sessioni | ⚠️ Creazione di un sistema di telemetria parallelo quando il tracciamento delle sessioni Agentforce acquisisce già le interazioni in un modello di dati unificato in Data 360 |
| Agentforce | Configurazione agente | ⚠️ Registrare solo le risposte degli agenti senza acquisire input, tracce di ragionamento, contesto recuperato e azioni intraprese |
| Einstein | Livello Trust | ⚠️ Disabilitazione dell’itinerario di controllo Einstein Trust Layer in produzione o mancata attivazione della raccolta e dell’archiviazione dei dati di feedback per la conservazione a lungo termine in Data 360 |
| Piattaforma | Monitoraggio | ⚠️ Affidarsi esclusivamente al successo/errore della conversazione senza acquisire l’utilizzo del token, il modello e i dettagli del prompt tramite i join di chiamata LLM STDM |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Monitoraggio | ✅ Misurare la latenza delle risposte ai percentili (p50, p95, p99) rivelando le prestazioni tipiche e le esperienze peggiori |
| Piattaforma | Monitoraggio | ✅ Strumentare ogni fase di latenza separatamente (inferenza del modello, recupero del contesto, esecuzione delle azioni, rete) abilitando l’ottimizzazione mirata |
| Piattaforma | Monitoraggio | ✅ Avviso quando la latenza p95 supera le soglie che indica un deterioramento delle prestazioni |
| Piattaforma | Monitoraggio | ✅ Tenere traccia della distribuzione dei token (token di prompt, token di completamento, token totali) per conversazione, per agente e per caso d’uso |
| Piattaforma | Monitoraggio | ✅ Rileva le conversazioni anomale che consumano token eccessivi suggerendo problemi urgenti o un uso improprio |
| Piattaforma | Monitoraggio | ✅ Confrontare la produttività corrente con i limiti di traffico noti o i valori di riferimento della capacità che avvisano quando si avvicinano alle soglie |
| Piattaforma | Monitoraggio | ✅ Calcolare le percentuali di errore come percentuale del totale delle richieste abilitando il confronto tra agenti e periodi di tempo |
| Piattaforma | Monitoraggio | ✅ Distinguere tra categorie di errore (errori del modello, errori di autorizzazione, errori di integrazione) che richiedono risposte diverse |
| Piattaforma | Monitoraggio | ✅ Calcola la disponibilità come percentuale di tempo in cui gli agenti rispondono correttamente alle richieste e tengono traccia degli SLO |
| Piattaforma | Proactive Monitoring | ✅ Configurare le soglie Proactive Monitoring in base agli schemi di comportamento degli agenti di base anziché accettare le impostazioni predefinite |
| Piattaforma | Scale Center | ✅ Esaminare i dati del Centro scala dopo aver distribuito nuovi agenti o aver apportato modifiche rapide significative per convalidare che il consumo di risorse corrisponde alle aspettative |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Monitoraggio | ⚠️ Misurare solo la latenza media anziché i percentili, mascherando le esperienze utente peggiori |
| Piattaforma | Monitoraggio | ⚠️ Tracciamento della latenza totale senza strumentazione delle singole fasi (inferenza, recupero, esecuzione delle azioni) |
| Piattaforma | Monitoraggio | ⚠️ Considerare tutti gli errori allo stesso modo anziché classificarli per tipo (modello, autorizzazione, integrazione) per una risposta appropriata |
| Piattaforma | Proactive Monitoring | ⚠️ Accettazione delle soglie predefinite di Proactive Monitoring senza sintonizzarsi sugli schemi di comportamento degli agenti di riferimento |
| Piattaforma | Scale Center | ⚠️ Distribuire nuovi agenti o apportare modifiche immediate senza rivedere i dati del Centro scala per convalidare il consumo delle risorse |
| Piattaforma | Monitoraggio | ⚠️ Ignorare gli schemi di consumo dei token e non rilevare le conversazioni anomale che utilizzano token tipici 10x |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Agentforce | Centro di test | ✅ Iniziare con strumenti di test e valutazione nativi: gestire gli insiemi di casi di test riutilizzabili nel Centro test Agentforce ed eseguire gli agenti in batch, controllando se l’agente ha selezionato l’argomento e l’azione previsti e ha prodotto una risposta accettabile |
| Agentforce | Centro di test | ✅ Utilizzare valutatori nativi (dimensioni della qualità pronte all’uso e approccio LLM-as-Judge per il calcolo del punteggio della qualità della conversazione) e creare valutatori personalizzati per criteri specifici dell’organizzazione, utilizzando conversazioni rappresentative in modo che la valutazione rifletta l’utilizzo reale |
| Agentforce | Centro di test | ✅ Per le domande fattuali con risposte note, mantenere le asserzioni con risposte note come casi di test ripetibili nel Centro test; per le domande aperte, aggiungere la revisione umana delle conversazioni campione |
| Data 360 | Qualità di recupero | ✅ Per gli agenti basati su una Knowledge Base, utilizzare l’analisi della qualità di recupero nativa per valutare la pertinenza del contesto, la pertinenza delle risposte e la fedeltà (fondatezza) delle risposte |
| Einstein | Livello Trust | ✅ Affidarsi al rilevamento della tossicità in fase di esecuzione Einstein Trust Layer come prima linea di difesa dal guardrail, quindi migliorare il monitoraggio della sicurezza attraverso il filtraggio dei contenuti, il campionamento manuale, la segnalazione degli utenti e i controlli dell’equità nei gruppi demografici |
| Data 360 | GenAIFeedback | ✅ Acquisire la soddisfazione degli utenti tramite il feedback Agentforce che scorre nei DMO GenAIFeedback / GenAIFeedbackDetail in Data 360 (pollice su / giù, accetta / rifiuta, modifiche, commenti testuali) insieme alla richiesta gateway e ai dati di generazione |
| Piattaforma | Analytics | ✅ Combinare feedback espliciti (domanda prima dell’inoltro al livello superiore, dopo la conversazione, sondaggi di follow-up) con segnali impliciti (percentuali di completamento, inoltro al livello superiore, abbandono, tentativi ripetuti), correlati alle caratteristiche della conversazione per guidare la definizione delle priorità di miglioramento |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Agentforce | Centro di test | ⚠️ Creazione ed esecuzione di un cablaggio di test personalizzato anziché iniziare con gli insiemi di test riutilizzabili del Centro test Agentforce e i valutatori nativi |
| Agentforce | Centro di test | ⚠️ Affidarsi esclusivamente alla valutazione automatica senza revisione umana per la valutazione della qualità delle risposte aperte |
| Piattaforma | Monitoraggio | ⚠️ Monitoraggio solo dell’accuratezza senza tenere traccia delle dimensioni di pertinenza, sicurezza e soddisfazione degli utenti |
| Data 360 | GenAIFeedback | ⚠️ Non raccogliere alcun feedback utente (esplicito o implicito) sulla qualità della risposta dell’agente quando il feedback Agentforce scorre già nei DMO GenAIFeedback |
| Agentforce | Configurazione agente | ⚠️ Saltare i controlli di equità che valutano la distribuzione dei risultati tra i gruppi demografici |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Agentforce | Configurazione agente | ✅ Stabilire le prestazioni di base immediatamente dopo la distribuzione degli agenti misurando l’accuratezza, la pertinenza, la sicurezza e la soddisfazione in casi di test rappresentativi |
| Agentforce | Configurazione agente | ✅ Rivalutare periodicamente rispetto agli stessi casi di test che rivelano modifiche delle prestazioni indipendentemente dai turni dello schema di utilizzo |
| Piattaforma | Monitoraggio | ✅ Avvisare quando le metriche di qualità diminuiscono oltre le soglie accettabili definite dalla tolleranza dell’impatto aziendale |
| Piattaforma | Analytics | ✅ Monitorare le caratteristiche di input (lunghezza delle domande, distribuzione degli argomenti, complessità della lingua, terminologia del dominio) rilevando turni di distribuzione significativi |
| Piattaforma | Monitoraggio | ✅ Monitorare le caratteristiche della risposta (lunghezza media della risposta, percentuali di chiamata delle azioni, frequenze di inoltro al livello superiore, schemi di errore) stabilendo valori di riferimento comportamentali |
| Piattaforma | Monitoraggio | ✅ Configurare gli avvisi automatici attivati quando le metriche di fluttuazione superano le soglie attivando indagini e rimedi |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Agentforce | Configurazione agente | ⚠️ Impossibile stabilire le prestazioni di base dopo la distribuzione iniziale dell’agente, rendendo la fluttuazione non rilevabile |
| Piattaforma | Monitoraggio | ⚠️ Ignorare la fluttuazione della distribuzione quando gli schemi di input degli utenti cambiano in modo significativo rispetto a ciò che gli agenti sono stati progettati per gestire |
| Piattaforma | Monitoraggio | ⚠️ Non monitorare i cambiamenti comportamentali (lunghezza della risposta, tassi di azione, frequenze di inoltro al livello superiore) rispetto ai valori di riferimento stabiliti |
| Piattaforma | Monitoraggio | ⚠️ Non avere avvisi automatici per le metriche di deriva, affidandosi solo all’osservazione manuale per rilevare il degrado |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Monitoraggio | ✅ Monitorare le distribuzioni del consumo di token rilevando le conversazioni anomale e analizzare quelle che consumano token tipici 10x |
| Piattaforma | Monitoraggio | ✅ Rileva improvvisi aumenti delle percentuali di errore, nuovi tipi di errore non nella base di riferimento o concentrazioni di errori localizzate che interessano utenti o agenti specifici |
| Piattaforma | Analytics | ✅ Tenere traccia dell’abbandono della conversazione in base alla fase della conversazione identificando se gli utenti abbandonano durante l’interazione iniziale, a metà conversazione o dopo il completamento dell’operazione |
| Piattaforma | Monitoraggio | ✅ Instradare immediatamente i guasti critici degli agenti ai tecnici su chiamata, il deterioramento della qualità ai team di prodotto durante l’orario di ufficio e le anomalie minori ai rapporti giornalieri |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Monitoraggio | ⚠️ Trattare tutti gli avvisi con la stessa urgenza, causando stanchezza e mancati errori critici |
| Piattaforma | Monitoraggio | ⚠️ Ignorare anomalie dei costi come picchi di consumo dei token che possono indicare problemi immediati, abusi o problemi dell’infrastruttura |
| Piattaforma | Analytics | ⚠️ Non tenere traccia dei tassi di abbandono delle conversazioni o non analizzare l’abbandono per fase |
| Piattaforma | Monitoraggio | ⚠️ Attendere i rapporti utente anziché rilevare in modo proattivo i picchi di tasso di errore attraverso il monitoraggio automatico |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Controllo sorgente | ✅ Memorizzazione dei modelli di prompt in Git insieme al codice dell’applicazione che tratta i prompt come logica applicativa critica che merita revisione, test e distribuzione controllata del codice |
| Einstein | Generatore di prompt | ✅ Utilizzare il Generatore di prompt per lo sviluppo iterativo dei prompt con la cronologia delle versioni e le funzionalità di test, quindi esportare nel controllo delle versioni per le opportunità in corso di realizzazione di distribuzione |
| Piattaforma | Controllo sorgente | ✅ Memorizza le configurazioni (selezione del modello, temperatura, limiti dei token, configurazioni di recupero, autorizzazioni azioni, flag delle funzioni) come codice che abilita valori specifici dell’ambiente e rilevamento della fluttuazione |
| Piattaforma | Controllo sorgente | ✅ Applicare il controllo semantico delle versioni ai componenti degli agenti: maggiore (modifiche dell’interruzione), minore (funzionalità), patch (correzioni di bug) con i numeri di versione visualizzati nei registri |
| Piattaforma | Documentazione | ✅ Documentare cosa è cambiato, perché è cambiato, quali test hanno convalidato la modifica e quali procedure di ritiro esistono per ogni prompt e modifica della configurazione |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Einstein | Generatore di prompt | ⚠️ Apportare modifiche immediate senza revisione del codice, test o processi di distribuzione controllati |
| Piattaforma | Configurazione | ⚠️ Memorizzazione delle configurazioni degli agenti al di fuori del controllo sorgente in cui la fluttuazione non può essere rilevata e le distribuzioni non possono essere automatizzate |
| Piattaforma | Documentazione | ⚠️ Apportare modifiche immediate senza documentare la logica, i risultati dei test o le procedure di ritiro |
| Piattaforma | Controllo sorgente | ⚠️ Non applicare il controllo semantico delle versioni, rendendo impossibile correlare gli incidenti a distribuzioni specifiche |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Documentazione | ✅ Gestire un registro del modello registrando le versioni del modello distribuite, incluse famiglia di modelli, versione specifica, stato di messa a punto, ambiente, data di distribuzione e team responsabile |
| Piattaforma | Documentazione | ✅ Registrare ogni distribuzione agente, inclusi versione, ambiente, indicazione oraria, utente di distribuzione, approvazioni ottenute e risultato della distribuzione |
| Piattaforma | Documentazione | ✅ Mappare le dipendenze tra agenti, prompt, Knowledge Base, azioni e integrazioni in modo esplicito anziché scoprirle durante gli incidenti |
| Business | Processo | ✅ Stabilire una pianificazione di deprecazione con un periodo di preavviso minimo supportato dalla policy comunicato con sufficiente anticipo, abilitando le migrazioni pianificate anziché le risposte di emergenza alle deprecazioni forzate |
| Piattaforma | Documentazione | ✅ Procedure di ritiro dei documenti per ogni agente, incluse la versione di destinazione, le fasi di esecuzione, i test di convalida e i requisiti di notifica |
| Piattaforma | Gestione temporanea | ✅ Testare le procedure di ritiro in ambienti non di produzione convalidandone il funzionamento prima di dipendere da esse durante gli incidenti di produzione |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Documentazione | ⚠️ Rilevamento delle dipendenze tra agenti, prompt e Knowledge Base solo durante gli incidenti anziché mantenere mappe delle dipendenze esplicite |
| Business | Processo | ⚠️ Fornire un avviso di deprecazione insufficiente costringendo le migrazioni di emergenza anziché le transizioni pianificate |
| Piattaforma | Documentazione | ⚠️ Avere procedure di ritiro non testate che falliscono quando necessario durante gli incidenti di produzione |
| Piattaforma | Distribuzione | ⚠️ Distribuire gli agenti senza registrare versione, ambiente, approvazioni o esito, perdendo la capacità di correlare gli incidenti alle distribuzioni |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Interfaccia utente | ✅ Raccogliere feedback espliciti (pollice su / giù, punteggi di qualità, commenti) e feedback impliciti (percentuali di completamento, frequenze di inoltro al livello superiore, schemi di nuovo tentativo) in modo sistematico |
| Data 360 | Gestione dei dati | ✅ Curare i registri delle conversazioni nelle serie di dati di addestramento filtrando per qualità, eliminando esempi problematici, garantendo la rappresentatività e deduplicando |
| Data 360 | Messa a terra | ✅ Adattare gli agenti al vocabolario del dominio, ai processi aziendali e a Knowledge specifiche dell’organizzazione principalmente tramite RAG basato su Data 360 e la regolazione rapida, ovvero il percorso di adattamento nativo di Salesforce |
| Einstein | BYOLLM | ✅ Quando la messa a terra e la regolazione del prompt sono insufficienti, perfezionare un modello esternamente e collegarlo tramite BYOLLM anziché aspettarsi una regolazione generativa all’interno della piattaforma |
| Einstein | Generatore di prompt | ✅ 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 |
| Einstein | Generatore di prompt | ✅ Implementare modifiche rapide in modo incrementale con test A / B di convalida dei miglioramenti prima dell’implementazione completa |
| Agentforce | Configurazione agente | ✅ Mantenere insiemi di test che coprono percorsi felici, casi limite, input avversari e scenari di problemi storici, espandendosi continuamente man mano che vengono scoperti nuovi casi limite |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Dati | ⚠️ Tentare di migliorare senza raccogliere feedback sistematici, rendendo il miglioramento congetturato anziché basato sui dati |
| Data 360 | Gestione dei dati | ⚠️ Utilizzo di registri di conversazione non curati per la formazione, incluse violazioni della sicurezza, errori ed esempi non rappresentativi |
| Data 360 | Messa a terra | ⚠️ Raggiungere la messa a punto esterna prima di esaurire il radicamento RAG e la messa a punto rapida, il percorso nativo che risolve la maggior parte delle esigenze di adattamento del dominio senza un modello personalizzato |
| Einstein | Generatore di prompt | ⚠️ Considerare l’ingegneria tempestiva come un esercizio singolo anziché come una pratica continua adattata man mano che gli schemi di utilizzo si evolvono |
| Agentforce | Configurazione agente | ⚠️ Avere insiemi di test statici che non si espandono mai per coprire nuovi casi limite scoperti in produzione |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Tipi di metadati personalizzati | ✅ Implementare i flag delle funzioni utilizzando tipi di metadati personalizzati o impostazioni personalizzate per separare la distribuzione dal rilascio per le modifiche degli agenti ad alto rischio |
| Piattaforma | Insiemi di autorizzazioni | ✅ Implementare le distribuzioni canary rilasciando le modifiche degli agenti a un piccolo sottoinsieme di utenti utilizzando prima gli insiemi di autorizzazioni che controllano l’accesso degli agenti |
| Agentforce | Configurazione agente | ✅ Monitorare la coorte di canarini misurando intensamente le percentuali di successo, la qualità, le percentuali di errore, la latenza, il consumo di token e la soddisfazione, ed espandere l’implementazione solo quando il canarino corrisponde o migliora rispetto al gruppo di controllo che esegue la versione agente precedente |
| Piattaforma | Analytics | ✅ Definire criteri di successo prima di iniziare i test A/B per evitare risultati ambigui, in linea con gli obiettivi aziendali |
| Agentforce | Configurazione agente | ✅ Distribuire test campione-sfidante mantenendo la versione collaudata come fallback durante il confronto con la versione challenger migliorata |
| Business | Processo | ✅ Stabilire criteri di promozione obiettivi, tra cui la dimensione minima del campione, le soglie di qualità e la durata della valutazione prima delle decisioni sulla promozione |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Agentforce | Configurazione agente | ⚠️ Implementazione contemporanea delle modifiche degli agenti a tutti gli utenti senza test canarino, massimizzando il raggio di esplosione dei problemi |
| Piattaforma | Distribuzione | ⚠️ Distribuzione di modifiche degli agenti ad alto rischio senza flag delle funzioni che abilitano il ritiro immediato senza ridistribuirlo |
| Piattaforma | Analytics | ⚠️ Esecuzione di test A/B senza criteri di successo predefiniti, che portano a risultati ambigui e decisioni inadeguate |
| Piattaforma | Analytics | ⚠️ Esecuzione di esperimenti con dimensioni del campione insufficienti che producono risultati rumorosi che portano a conclusioni errate |
| Agentforce | Configurazione agente | ⚠️ Utilizzo dei flag delle funzioni per ogni piccola modifica del prompt anziché riservarli a modifiche ad alto rischio per gli agenti business-critical |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Monitoraggio | ✅ Rilevamento degli errori degli agenti tramite il monitoraggio automatico che avvisa sui tassi di errore, il degrado delle metriche di qualità, le anomalie dei costi, gli aumenti di latenza e gli inoltri degli utenti al livello superiore |
| Piattaforma | Monitoraggio | ✅ Integrare il rilevamento automatico con meccanismi di segnalazione degli utenti che consentono l’inoltro al livello superiore dei problemi mancati dal monitoraggio automatico |
| Business | Processo | ✅ 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 di ripristino |
| Piattaforma | Documentazione | ✅ Documentare le procedure di risposta iniziale come runbook eseguibili da ingegneri su chiamata senza una profonda esperienza degli agenti |
| Agentforce | Configurazione agente | ✅ Includere nella risposta iniziale: disabilitare l’agente guasto (interruttore), instradare al fallback, raccogliere la diagnostica, informare le parti interessate, avviare la comunicazione dell’incidente |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Monitoraggio | ⚠️ Affidarsi ai rapporti utente come meccanismo di rilevamento principale anziché al monitoraggio automatico degli errori degli agenti |
| Business | Processo | ⚠️ Utilizzo della classificazione soggettiva della gravità che porta a problemi reali sottodimensionati o a problemi minori sottodimensionati |
| Piattaforma | Documentazione | ⚠️ Non avere runbook, che richiedono indagini specifiche sugli incidenti da parte di ingegneri con profonda esperienza degli agenti durante ogni incidente |
| Business | Processo | ⚠️ Trattare gli errori degli agenti in modo identico agli errori delle applicazioni tradizionali senza tenere conto di allucinazioni, risposte fuori argomento o violazioni della sicurezza |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Apex | ✅ Implementare interruttori automatici con soglia di errore configurabile (ad esempio, tasso di errore del 50%), finestra di durata (ad esempio, finestra continuativa di 5 minuti) e test di ripristino (richieste di prova periodiche) |
| Agentforce | Configurazione agente | ✅ Progettare le gerarchie di fallback: Agente sofisticato principale → Agente di backup più semplice → Risposte alle domande frequenti statiche → Passaggio di consegne umano |
| Piattaforma | Orchestrazione | ✅ Implementare la logica di fallback nel livello di orchestrazione anziché all’interno dei singoli agenti abilitando un comportamento coerente in tutto l’ecosistema degli agenti |
| Agentforce | Configurazione agente | ✅ Progettare flussi di lavoro di handoff umano conservando il contesto della conversazione, comunicando il motivo della consegna e instradando a un agente umano appropriato con esperienza pertinente |
| Piattaforma | Monitoraggio | ✅ Monitorare le percentuali di trasferimento per argomento, agente e motivo dell’errore per identificare le lacune di capacità degli agenti |
| Agentforce | Configurazione agente | ✅ Quando il ragionamento sofisticato fallisce, fallback a una logica più semplice; quando i dati in tempo reale non sono disponibili, operare sui dati memorizzati nella cache; quando le integrazioni falliscono, operare in modalità di sola lettura |
| Piattaforma | Orchestrazione | ✅ Testare i percorsi di fallback regolarmente convalidandoli quando necessario |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Agentforce | Configurazione agente | ⚠️ Non avere interruttori, consentendo agli agenti in errore di influire ripetutamente sugli utenti mentre i problemi vengono risolti |
| Piattaforma | Orchestrazione | ⚠️ Implementazione della logica di fallback all’interno dei singoli agenti anziché a livello di orchestrazione, creando comportamenti incoerenti |
| Agentforce | Configurazione agente | ⚠️ Progettare agenti di passaggio/errore binari che funzionano perfettamente o completamente falliscono senza opzioni di degradazione graziose |
| Piattaforma | Orchestrazione | ⚠️ Mai testare i percorsi di fallback, scoprendo che non funzionano solo durante gli incidenti effettivi |
| Agentforce | Configurazione agente | ⚠️ Handoff umano che perde il contesto della conversazione costringendo gli utenti a ripetere le informazioni |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Business | Processo | ✅ Condurre revisioni post-incidente senza colpe concentrandosi sui miglioramenti del sistema anziché sui singoli errori che creano sicurezza psicologica |
| Business | Processo | ✅ Creare una sequenza temporale dettagliata dalle condizioni iniziali attraverso rilevamento, indagine, risposta, ripristino e convalida con indicazioni orarie |
| Business | Processo | ✅ Utilizzare la tecnica “Cinque Perché” perforando dai sintomi alle cause fondamentali piuttosto che conclusioni semplicistiche |
| Business | Processo | ✅ Analizzare i fattori che contribuiscono, tra cui il monitoraggio di lacune, lacune nei test, lacune nella documentazione, lacune nell’automazione e lacune architettoniche |
| Business | Processo | ✅ Valuta rilevamento: quale segnale avrebbe dovuto rilevare il problema prima, quale monitoraggio consente un rilevamento più rapido |
| Business | Processo | ✅ Specificare voci azioni concrete, assegnate e limitate nel tempo che impediscono la ricorrenza (ad esempio, “aggiungi avviso per la percentuale di errore superiore al 5% in 10 minuti - assegnato: Alex - due: 2 settimane”) |
| Business | Processo | ✅ Tenere traccia del completamento dell’elemento azione nelle revisioni successive assicurando che il miglioramento continuo avvenga effettivamente |
| Piattaforma | Documentazione | ✅ Documentare le revisioni post-incidente nella Knowledge Base condivisa con tag che abilitano l’analisi degli schemi in più incidenti |
| Business | Processo | ✅ Condividere le revisioni post-incidente in generale oltre i soccorritori immediati attraverso riunioni del team o sessioni di pranzo e apprendimento |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Business | Processo | ⚠️ Automi post mortem incentrate sulla colpa che riducono la sicurezza psicologica e impediscono una valutazione onesta degli insuccessi |
| Business | Processo | ⚠️ Conclusioni semplicistiche sulle cause principali (“l’agente aveva un bug”) anziché risultati specifici che consentono una risoluzione efficace |
| Business | Processo | ⚠️ Voci azioni vaghe come “migliora monitoraggio” anziché operazioni specifiche, assegnate e limitate nel tempo |
| Business | Processo | ⚠️ Bassi tassi di completamento delle voci azione che indicano un errore del processo di miglioramento continuo |
| Business | Processo | ⚠️ Mantenere gli apprendimenti post-incidente in silo per i soccorritori diretti anziché condividerli ampiamente per l’apprendimento organizzativo |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Business | Processo | ✅ Convalida l’elenco di controllo pre-distribuzione che include test, revisione della sicurezza, convalida della conformità, documentazione, configurazione di monitoraggio e approvazione degli stakeholder |
| Business | Processo | ✅ Valutare il rischio in base al raggio di esplosione, alla sensibilità dei dati, all’autorità dell’azione, alle dipendenze di integrazione, alla complessità del ripristino e alle implicazioni di conformità |
| Business | Processo | ✅ Scalare i requisiti di approvazione in base al rischio: ad alto rischio richiede l’approvazione esecutiva, la revisione della sicurezza e l’implementazione graduale; a basso rischio richiede la revisione tra pari e test standard |
| Piattaforma | Processi di approvazione | ✅ Implementare flussi di lavoro di approvazione automatizzati, tracciati e controllabili utilizzando processi di approvazione Salesforce o strumenti di distribuzione esterni |
| Business | Processo | ✅ Definire procedure di bypass di emergenza che richiedono l’approvazione esecutiva, la documentazione logica e un riesame post-distribuzione accelerato |
| Piattaforma | Monitoraggio | ✅ Tracciare le distribuzioni di emergenza separatamente; l’alta frequenza di distribuzione di emergenza indica problemi del processo che richiedono un’indagine |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Business | Processo | ⚠️ Applicare una profondità di approvazione uniforme indipendentemente dal profilo di rischio dell’agente, sprecando sforzi per gli agenti a basso rischio o sottovalutando quelli ad alto rischio |
| Business | Processo | ⚠️ Distribuzione di agenti di produzione senza convalida elenco di controllo pre-distribuzione di test, sicurezza, conformità e monitoraggio |
| Piattaforma | Distribuzione | ⚠️ Non avere procedure di bypass di emergenza, causando ritardi di correzione critici durante gli incidenti di produzione |
| Business | Processo | ⚠️ Richiede spesso distribuzioni di emergenza, indicando processi standard interrotti anziché circostanze eccezionali |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Agentforce | Configurazione agente | ✅ Caratteristiche dell’output del test (contiene le informazioni richieste, mantiene il tono appropriato, include le citazioni) anziché il testo esatto per gli output degli agenti non deterministici |
| Agentforce | Configurazione agente | ✅ Stabilire soglie minime di qualità (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%“) |
| Agentforce | Configurazione agente | ✅ Eseguire test di sicurezza con input avversari, tra cui prompt injection, tentativi di jailbreak, richiesta di inoltro al livello superiore e richieste fuori dall’ambito |
| Agentforce | Configurazione agente | ✅ Far eseguire i test di sicurezza da membri del team non coinvolti nello sviluppo degli agenti offrendo una nuova prospettiva sulle vulnerabilità |
| Platform | Test delle prestazioni | ✅ Test sotto carico realistico tra cui conversazioni simultanee, lunghezze tipiche delle conversazioni e volume di utilizzo previsto |
| Piattaforma | Sicurezza | ✅ Verificare che gli agenti non possano accedere a dati non autorizzati, non possano eseguire azioni non autorizzate e che l’iniezione rapida non possa inoltrare i privilegi al livello superiore |
| Piattaforma | CI/CD | ✅ Integrare la scansione della sicurezza nella pipeline di distribuzione utilizzando Salesforce Code Analyzer e strumenti di sicurezza AI specializzati |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Agentforce | Configurazione agente | ⚠️ Testare la corrispondenza del testo esatto sugli output non deterministici anziché testare le caratteristiche degli output |
| Platform | Test delle prestazioni | ⚠️ Test solo con scenari per utente singolo, problemi di limiti governor mancanti, vincoli delle risorse e colli di bottiglia della scalabilità |
| Agentforce | Configurazione agente | ⚠️ Ignorare i test di sicurezza o chiedere agli sviluppatori di testare i propri agenti senza nuove prospettive sulle vulnerabilità |
| Piattaforma | Sicurezza | ⚠️ Non testare se l’iniezione rapida può inoltrare al livello superiore i privilegi degli agenti o accedere a dati non autorizzati |
| Agentforce | Configurazione agente | ⚠️ Avere insiemi di test statici che non rappresentano la vera diversità di utilizzo, inclusi diversi tipi di utenti e complessità delle conversazioni |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Documentazione | ✅ Documentare ogni modifica: cosa è cambiato, perché, quali test lo hanno convalidato e quale procedura di ritiro esiste |
| Business | Comunicazione | ✅ Notifica a tutti gli stakeholder (utenti, team operativi, assistenza, business) descrivendo cosa sta cambiando, quando, quali vantaggi, quali rischi e chi contattare |
| Business | Comunicazione | ✅ Stabilire modelli di comunicazione per diversi tipi di modifica standardizzando i messaggi e riducendo il sovraccarico di preparazione |
| Piattaforma | Monitoraggio evento | ✅ Distribuzioni degli agenti del tempo durante i periodi di basso utilizzo informate dai dati di Monitoraggio evento che mostrano gli schemi di utilizzo effettivi |
| Business | Processo | ✅ Distribuire le principali modifiche degli agenti dall’inizio alla metà della settimana evitando i fine settimana con ridotta capacità di risposta agli incidenti |
| Business | Processo | ✅ Stabilire periodi di congelamento del cambiamento prima dei principali eventi aziendali (fine anno fiscale, lancio di prodotti, principali campagne di marketing) |
| Business | Processo | ✅ Modifica documento congela il calendario ogni anno comunicando periodi limitati con sufficiente anticipo |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Distribuzione | ⚠️ Distribuzione durante i picchi di utilizzo, la chiusura di fine mese, la chiusura di fine trimestre o i principali eventi aziendali |
| Piattaforma | Distribuzione | ⚠️ Distribuzione il lunedì (aumento del personale) o il venerdì (riduzione del personale) quando la capacità di risposta agli incidenti è limitata |
| Business | Processo | ⚠️ Avere un cambiamento eccessivo congela la velocità di miglioramento senza una riduzione del rischio proporzionata |
| Business | Comunicazione | ⚠️ Distribuzione delle modifiche degli agenti senza informare gli utenti, i team operativi, i team di assistenza o gli stakeholder aziendali interessati |
| Piattaforma | Documentazione | ⚠️ Apportare modifiche senza documentare la logica, creando organizzazioni che riscoprano le lezioni anziché costruire sull’esperienza |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Piattaforma | Interfaccia utente | ✅ Implementare la raccolta di feedback nell’interfaccia utente della conversazione abilitando la risposta immediata mentre l’interazione è fresca anziché raccolta ritardata |
| Piattaforma | Analytics | ✅ Eseguire query sui 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 delle conversazioni |
| Piattaforma | Analytics | ✅ Analizzare i registri errori raggruppando per tipo di errore, utenti interessati, schemi di conversazione e distribuzione temporale per rivelare problemi sistematici |
| Piattaforma | Analytics | ✅ 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 |
| Piattaforma | Monitoraggio | ✅ Stabilire valori di riferimento di qualità dopo la distribuzione iniziale e monitorare la qualità in corso rispetto ai valori di riferimento avvisando quando le tendenze diminuiscono |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Piattaforma | Interfaccia utente | ⚠️ Ritardo della raccolta di feedback (ad esempio, email di follow-up giorni dopo) riduzione dei tassi di risposta e introduzione della distorsione del richiamo |
| Piattaforma | Analytics | ⚠️ Non analizzare gli schemi di utilizzo per determinare se gli agenti giustificano la complessità operativa o se le funzionalità sono sottoutilizzate |
| Piattaforma | Analytics | ⚠️ Considerare tutti gli errori allo stesso modo anziché assegnare priorità in base alla frequenza e all’impatto sul business |
| Piattaforma | Monitoraggio | ⚠️ Prendere decisioni di miglioramento senza dati, senza valori di riferimento di qualità e monitoraggio delle tendenze |
Schemi
| Dove cercare | Che bell’aspetto |
|---|---|
| Business | Processo | ✅ Fornire una struttura coerente dell’esperimento: ipotesi, progettazione sperimentale, metriche, dimensioni del campione e criteri di successo |
| Business | Processo | ✅ Documentare gli esperimenti prima dell’esecuzione evitando interpretazioni ambigue dei risultati |
| Piattaforma | Analytics | ✅ Tenere traccia dell’assegnazione delle varianti nei metadati della conversazione abilitando la correlazione dei risultati per variante |
| Piattaforma | Analytics | ✅ Calcolare le dimensioni del campione richieste prima degli esperimenti in base alle dimensioni previste dell’effetto, alla potenza statistica e alle percentuali di errore accettabili |
| Piattaforma | Analytics | ✅ Utilizzare l’ottimizzazione delle bandite multi-braccio per allocare dinamicamente più traffico alle varianti con prestazioni migliori riducendo il costo delle opportunità |
| Piattaforma | Documentazione | ✅ Mantenere il catalogo degli esperimenti con le varianti testate, i risultati misurati, i risultati raggiunti e le decisioni prese per evitare di ripetere i test degli approcci non riusciti |
Anti-schemi
| Dove cercare | Che brutto aspetto |
|---|---|
| Business | Processo | ⚠️ Esecuzione di esperimenti senza ipotesi predefinite e criteri di successo che portano a risultati ambigui |
| Piattaforma | Analytics | ⚠️ Utilizzo di campioni di dimensioni insufficienti che producono risultati rumorosi che portano a decisioni di miglioramento inadeguate |
| Piattaforma | Documentazione | ⚠️ Non avere un catalogo di esperimenti, che fa sì che i team ripetano approcci non riusciti in precedenza e perdano Knowledge organizzativa |
| Piattaforma | Analytics | ⚠️ Non tracciare quali utenti hanno ricevuto quali varianti, rendendo impossibile la correlazione del risultato |