La tua CI è passata. Il tuo agente non è pronto per l'operatore

L'ultimo trimestre abbiamo rilasciato un agente per documenti a un cliente enterprise.

La nostra suite di test ha mostrato un tasso di superamento del 94%.

Dopo tre settimane di pilot, l'agente ha iniziato a emettere rimborsi per fatture che non riusciva a leggere. Lo ha fatto silenziosamente. Non c'erano errori o log. L'agente forniva semplicemente risposte errate che sembravano corrette.

La nostra CI è rimasta verde per tutto il tempo.

Il problema non era il modello o il prompt. Il problema era quel 6% di dati che non avevamo testato. Quel 6% è arrivato come primo dato reale dall'operatore.

Questo non è un caso limite. Questa è la definizione di essere pronti per l'operatore.

Essere "production-ready" riguarda l'infrastruttura. Significa che il tuo servizio rimane attivo e gestisce il carico.

Essere "operator-ready" è diverso. Significa che il tuo agente funziona per qualcuno che non lo ha costruito. Funziona su dati che non hai progettato tu. Prende decisioni con conseguenze reali.

La maggior parte delle pipeline di test misura i tassi di superamento su un set creato da te. Non misurano cosa succede quando i dati reali differiscono dal tuo set di test.

Un modello con un successo di validazione del 97% suona bene. Ma guarda quel 3% che fallisce.

Se il tuo agente compila i campi mancanti con valori predefiniti durante un retry, hai costruito una macchina di errori silenziosi. Lo schema passa, ma i dati sono errati.

Per risolvere questo problema, separa la validità dello schema dalla confidenza del contenuto.

Abbiamo aggiunto un punteggio di confidenza (confidence score) a ogni risposta. Una bassa confidenza ora attiva una revisione umana invece di un retry. Questo cambiamento ha intercettato 14 dei nostri primi 18 incidenti.

Il tuo set di test copre ciò a cui hai pensato. I dati di un operatore coprono ciò che ti è sfuggito.

Nel nostro caso, avevamo testato fatture a pagina singola. L'operatore ha utilizzato fatture multipagina con PDF scansionati. L'agente è fallito con il nuovo formato.

Non limitarti a correggere il parser. Testa i dati reali dell'operatore prima di andare online.

Prima di ogni passaggio di consegne, ora richiediamo 50 documenti dai dati reali dell'operatore. Non usiamo dati sintetici. Usiamo i loro.

Hai anche bisogno di una traccia di audit (audit trail) completa. Non limitarti a registrare ciò che il modello ha restituito. Registra ciò che il modello ha deciso di non fare.

Una traccia di audit minima richiede:

  • Output con punteggi di confidenza a livello di campo
  • Un indicatore di fallback che mostri se l'agente ha effettuato un retry
  • Un hash di input per riprodurre l'esatto documento
  • La versione specifica del modello e del prompt utilizzata

Prima di consegnare un agente a un operatore, controlla queste cinque cose:

  • Esegui oltre 50 campioni dai dati reali dell'operatore.
  • Cerca nei log output che hanno superato i controlli dello schema ma hanno causato errori a valle.
  • Inserisci input malformati per assicurarti che l'agente fallisca in modo sicuro.
  • Assicurati di poter rispondere a cosa è successo a un documento specifico in meno di 5 minuti.
  • Verifica che l'agente abbia i permessi minimi possibili.

Il nostro tasso di superamento dei test era del 94%. Il nostro tasso di errore nel primo mese era dell'8%.

Dopo aver aggiunto punteggi di confidenza, test nel mondo reale e log migliori, il tasso di errore è sceso all'1,4%.

Il punteggio del test non era il problema. Lo era l'ambito del test.

Fonte: https://dev.to/ethanwritesai/our-ci-passed-your-agent-isnt-operator-ready-2mfn

Community di apprendimento opzionale: https://t.me/GyaanSetuAi