Condividi tramite

Livello 4: Analizzare i modelli e migliorare continuamente l'agente

Dopo aver gestito i singoli fallimenti dei casi di test, potresti applicare correzioni e non vedere alcun miglioramento significativo delle prestazioni complessive dell'agente. Questo risultato spesso indica un problema sistemico, non una raccolta di errori non correlati.

L'analisi dei pattern consente di esaminare più casi di test falliti per identificare i segnali ricorrenti e le cause comuni sottostanti. Usare l'analisi dei modelli per concentrarsi sulle modifiche che affrontano contemporaneamente i gruppi di errori anziché correggere ogni errore in isolamento.

Importante

Usare queste indicazioni dopo aver completato la valutazione degli errori e applicare le modifiche di correzione. L'analisi dei modelli è più utile dopo un'analisi preliminare di almeno cinque errori.

Quando usare l'analisi dei modelli

L'analisi dei criteri è più utile quando si osserva una o più delle condizioni seguenti:

  • Molti errori nello stesso set di valutazione.
  • Errori ripetuti con sintomi simili.
  • Miglioramenti ai singoli test case che non spostano i punteggi complessivi.
  • Miglioramenti in un'area che causano regressioni in un'altra.

La correzione degli errori uno per uno è inefficiente in queste situazioni. L'analisi dei criteri consente di identificare gli errori comuni, in modo da poter risolvere la causa sottostante.

Analisi della concentrazione

Dopo aver classificato singoli errori, cercare i modelli nel set completo.

Modello Che cosa indica Azione consigliata
80% o più errori sono problemi di configurazione della valutazione La suite di valutazione richiede la calibrazione, non i cambiamenti all'agente Sospendere l'iterazione dell'agente. Controllare e correggere prima la qualità della valutazione, quindi rieseguire per ottenere un segnale pulito.
80% o più errori sono problemi di configurazione dell'agente in un'area (ad esempio, tutte le informazioni correlate) Lacuna nella configurazione dell'agente sistemico Concentrare la correzione su quell'area. Questo problema è spesso un problema di architettura (ad esempio, struttura dell'origine delle informazioni), non singole correzioni del test case.
80% o più errori sono limitazioni della piattaforma L'agente raggiunge i limiti della piattaforma Rivaluta l'ambito operativo dell'agente. Esegui l'escalation al team della piattaforma. Modificare le soglie o considerare gli elementi interessati come limitazioni note, se appropriato.
Gli errori si distribuiscono uniformemente tra i tipi di causa radice Nessun singolo problema sistemico Continuare la correzione del caso usando il mapping delle correzioni.

Come eseguire l'analisi della concentrazione

  1. Conteggio degli errori classificati per tipo di causa radice:

    • Problemi di configurazione della valutazione
    • Problemi di configurazione dell'agente
    • Limitazioni della piattaforma
    • Non classificato

  2. Calcolare la percentuale per ogni tipo.

  3. Se un singolo tipo è pari o superiore all'80%, a indicare un problema sistemico, risolvi la categoria, non i singoli casi.

  4. Se i problemi di configurazione dell'agente si concentrano in un segnale di qualità (ad esempio, cinque di sei sono nozioni di base), tale modello punta a una causa radice dell'architettura.

Modelli di segnale incrociato

Quando gli errori si estendono su più set di valutazione, spesso puntano a una causa radice condivisa. Cercare i modelli seguenti:

Modello Ciò che probabilmente indica Cosa analizzare
Accuratezza dei fatti e fondamento della conoscenza, entrambi in fallimento. Problema relativo all'origine delle informazioni (errato, mancante, inaccessibile o non aggiornato) Configurazione delle informazioni, stato di indicizzazione e aggiornamento del contenuto
La chiamata dello strumento e l'instradamento del trigger entrambi non riusciti Problema di configurazione dell'orchestrazione: gli argomenti e gli strumenti non sono connessi correttamente Esaminare come gli argomenti vengono indirizzati agli strumenti. Verificare la presenza di flussi disconnessi o non configurati correttamente.
Il tono non è stato rispettato ma la precisione è stata mantenuta. L'agente ottiene la risposta giusta, ma lo fornisce male Concentrarsi sulle istruzioni stilistiche del prompt; l'infrastruttura di accuratezza è solida.
Superamento criteri di sicurezza ma non quelli di accuratezza L'agente potrebbe essere eccessivamente vincolato, troppo cauto, rifiuta di rispondere quando dovrebbe Esaminare le istruzioni di sicurezza per restrizioni eccessivamente ampie che bloccano le risposte legittime.
Tutto passa ad eccezione dei casi limite Il comportamento principale è solido Concentrarsi sull'espansione della robustezza ai margini; questo modello è un buon segno.
Miglioramento dell'accuratezza ma riduzione del tono Conflitto di istruzioni: le nuove direttive sulla precisione potrebbero sovrapporsi alle linee guida sul tono Esaminare le modifiche recenti alle richieste e tenere presente il "budget delle istruzioni".
Molteplici set di valutazione si degradano tutti simultaneamente Probabilmente una singola causa radice con un impatto ampio Verificare la presenza di modifiche recenti al prompt del sistema, aggiornamenti dell'origine delle informazioni o aggiornamenti del modello della piattaforma.

Cosa fare con i modelli di segnale incrociato

  1. Identificare la causa radice condivisa: se due segnali hanno esito negativo insieme, è probabile che condividano una dipendenza, ad esempio un'origine della knowledge base, una sezione del prompt o una configurazione dello strumento.
  2. Correggere la dipendenza condivisa: non correggere ogni segnale in modo indipendente.
  3. Eseguire nuovamente entrambi i set di valutazione: dopo la correzione, confermare che entrambi i set migliorano.
  4. Se ne migliora solo uno, i segnali non condividono effettivamente una causa radice. Valutare gli errori rimanenti in modo indipendente.

Analisi delle tendenze tra iterazioni

Tenere traccia del modo in cui i punteggi cambiano nei cicli di iterazione per capire se la strategia di correzione funziona.

Tendenza Interpretazione Action
Miglioramento dei punteggi tra iterazioni La correzione funziona Continuare fino a quando non vengono soddisfatte le soglie.
Punteggi flat nonostante le modifiche La correzione non è rivolta alla vera causa principale Rivalutazione; la classificazione della causa principale potrebbe essere errata.
Punteggi degradanti dopo una modifica Regressione: la modifica ha interrotto qualcosa Annulla la modifica. Esaminare cosa è regredito e perché.
Miglioramento di un set di valutazione, un altro che si degrada Compromesso: la correzione di una dimensione compromette un'altra Analizzare l'accoppiamento, spesso causato da un conflitto di istruzioni (vedere Journey 3).
Punteggi fluttuanti tra diverse esecuzioni (variazioni superiori al ±10%) Instabilità del grader o non determinismo agente Convalidare prima l'affidabilità del grader (fare riferimento alla convalida di Grader). Eseguire almeno tre volte per iterazione.

Creazione di una visualizzazione delle tendenze

Dopo ogni iterazione, registrare:

  • Date
  • Modifica apportata
  • Set di valutazione
  • Punteggio prima
  • Punteggio dopo
  • Delta

Queste informazioni consentono di:

  • Verifica che tu stia convergendo verso le soglie
  • Identificare rapidamente le regressioni
  • Rilevare per tempo le stagnazioni (Viaggio 2)

Errori dei documenti

I record degli errori strutturati creano conoscenze istituzionali nei cicli di iterazione. Senza documentazione, i team spesso ripetono lo stesso lavoro di indagine.

Perché gli errori dei documenti

  • Accelerare la valutazione futura: Si riconoscono immediatamente i modelli di errore noti.
  • Creare prove di escalation: Accumula record di limitazione della piattaforma per rendere più efficaci i casi al team della piattaforma.
  • Abilitare l'apprendimento per i team: Il log consente di evitare indagini duplicate quando più persone lavorano sullo stesso agente.
  • Tenere traccia delle lacune note: Non dimenticare di tenere traccia degli errori classificati come "non correggeranno" o "limitazioni note".

Usare il modello di log degli errori

Usare il modello di log degli errori per acquisire gli errori in un formato leggero o dettagliato, a seconda delle dimensioni del team e della maturità dei processi.

Cosa registrare

Acquisire almeno le informazioni seguenti per ogni errore triaggiato:

  1. Quale caso di test non è riuscito.
  2. Come hai classificato il tipo di causa radice.
  3. Cosa è andato storto in modo specifico.
  4. Cosa hai cambiato per correggerlo.
  5. Indica se la correzione ha funzionato.

Per gli errori non risolti, registrare anche:

  • Quello che hai provato finora.
  • Perché rimane irrisolto.
  • Quando rivalutare (ad esempio, "dopo l'aggiornamento della piattaforma X").

Flusso di lavoro di miglioramento continuo

Usare questo elenco di controllo dopo ogni ciclo di valutazione e correzione per confermare l'acquisizione dei risultati e dei passaggi successivi.

Lista di controllo post-iterazione

Fatto? Attività
✓ Registrare tutti i fallimenti classificati nel registro dei fallimenti.
✓ Identificare e prendere nota delle concentrazioni della causa radice.
✓ Controllare i modelli di segnale incrociato.
✓ Registrare i punteggi per il rilevamento delle tendenze.
✓ Documentare le limitazioni note con le soluzioni alternative.
✓ Identificare le priorità di iterazione successiva in base agli errori rimanenti.
✓ Impostare il programma di riesecuzione (quali set di valutazione, quando).

Quando arrestare l'iterazione

Interrompere l'iterazione quando:

  • Tutti i set di valutazione superano le soglie.
  • Hai documentato le lacune conosciute.
  • I punteggi sono coerenti (< 5% varianza).
  • Nessun problema di configurazione dell'agente aperto per i segnali di blocco.

Non interrompere l'iterazione quando:

  • Non sono stati esaminati gli errori persistenti.
  • Hai rimosso i casi di test rigidi per raggiungere gli obiettivi.
  • Non hai documentato le limitazioni della piattaforma.

Per altre informazioni, vedere Determinare quando l'iterazione è completa.

Passaggi successivi

  • Last updated on