Testare l'agente prima della messa in funzione

Un agente che il mese scorso rispondeva bene può iniziare a rispondere male dopo una modifica al prompt o un cambiamento nella conoscenza. La pagina di valutazione lo intercetta prima che lo facciano i visitatori: si mantiene un insieme di domande di prova, lo si esegue sulla bozza dell'agente e si decide che cosa comporta per un deploy un'esecuzione fallita.

Costruire il golden set#

Aprire Evaluation nella console e scegliere un agente. Ogni caso è una domanda più almeno un'aspettativa:

• l'expected answer, giudicata in base al significato anziché alla formulazione esatta,
• una risposta contrassegnata never repeat (un errore passato confermato),
• oppure il comportamento richiesto: citare i propri documenti, passare a un operatore o rifiutare di rispondere.

Un caso privo di aspettative non può fallire, quindi l'editor non lo salva.

Il modo più rapido per ottenere un set utile: premere Import confirmed-wrong reports. Ogni risposta che i revisori hanno confermato errata nella pagina Answer feedback diventa un caso che l'agente non deve mai ripetere, con allegata la domanda originale del visitatore. Importare due volte è sicuro: i casi esistenti vengono saltati, mai sovrascritti, quindi le proprie modifiche restano.

Eseguirlo#

Run the set pone ogni domanda alla bozza dell'agente, con le sue istruzioni e la sua conoscenza, e un giudice automatico valuta ogni risposta. L'esecuzione archiviata mostra un esito positivo o negativo per ogni caso, il motivo del fallimento e che cosa è cambiato rispetto all'esecuzione precedente: quali casi hanno iniziato a fallire, quali sono tornati a funzionare, quali sono stati aggiunti.

Le esecuzioni vengono conservate per sempre, quindi «che cosa aveva superato questa versione prima della messa in funzione» ha sempre una risposta.

Decidere che cosa significa un fallimento#

Il gate di deploy è un'impostazione valida per l'intero progetto, con tre posizioni:

• Off: le esecuzioni sono puramente informative.
• Avviso: un deploy effettuato nonostante un'esecuzione fallita riesce, ma indica quale esecuzione è fallita.
• Blocco: il deploy viene rifiutato finché l'esecuzione non viene superata o il gate non viene abbassato.

Solo un'esecuzione realmente fallita attiva il gate. Un'esecuzione terminata in errore perché il meccanismo di prova stesso ha avuto un problema non blocca mai il deploy.

Sorvegliare la qualità in produzione#

La stessa pagina ospita gli allarmi di qualità del progetto: un tetto massimo per il tasso di allucinazioni (risposte non supportate dai propri documenti, misurate da un giudice automatico su un campione di conversazioni reali) e uno per il tasso di presa in carico da parte di un operatore. Quando un tasso supera il proprio tetto, viene inviato un evento di allerta ai canali configurati, e un altro quando rientra. La dashboard mostra gli stessi numeri: risposte documentate, feedback negativi e chat risolte senza una persona.

Il report operativo periodico#

Operations report nella console è lo stesso report di qualità riferito a un intero periodo di calendario, conservato come documentazione anziché come indicatore in tempo reale.

Attivare la pianificazione, scegliere ogni mese o ogni trimestre e aggiungere gli indirizzi che devono riceverlo. Al termine di ogni periodo il report viene generato e inviato via email sotto forma di foglio di calcolo. Viene inoltre conservato qui, così è possibile leggerlo o scaricarlo senza attendere l'email. Senza indirizzi viene comunque generato e conservato, semplicemente non viene inviato a nessuno.

Ogni report si apre con l'indicatore principale attorno al quale è costruito: la quota di chat del sito web che si sono concluse senza che nessuno abbia chiesto di parlare con una persona, con accanto l'obiettivo, raggiunto o meno. Sotto viene l'intero progetto, poi la stessa serie di numeri per ciascun agente: conversazioni gestite, quante sono state risolte senza escalation, quante risposte erano supportate dai propri documenti, valutazioni negative, come sono state percepite le conversazioni dall'inizio alla fine, l'argomento più ricorrente, quante richieste dei chiamanti hanno trovato corrispondenza in un intento configurato e le esecuzioni di valutazione del periodo.

Non è necessario attendere la fine di un periodo. Generate produce su richiesta un report per qualsiasi mese o trimestre passato e propone due pulsanti: generarlo senza inviarlo, per leggerlo prima, oppure generarlo e inviarlo agli indirizzi della pianificazione.

La generazione su richiesta è limitata a pochi report all'ora. Ognuno di essi legge tutte le conversazioni, le valutazioni e le esecuzioni di valutazione del periodo prima di rispondere, e invia un foglio di calcolo via email a meno che non sia stato chiesto il contrario: il limite è quindi ciò che impedisce a pochi clic di diventare un carico sugli stessi archivi che stanno usando le conversazioni in corso. Lavorare sui tre mesi di un trimestre in un'unica sessione rientra ampiamente nel limite. Se lo si raggiunge, la console lo segnala e chiede di attendere qualche minuto; il report pianificato non ne risente mai, perché il limite riguarda soltanto la generazione su richiesta.

Ogni numero del report deriva dallo stesso calcolo che leggono la dashboard e il proprio monitoraggio. Un periodo che ha raggiunto un limite di lettura lo dichiara sulla propria riga: i numeri sono allora un limite inferiore riferito alle conversazioni più recenti anziché all'intero periodo.

Quando il punteggio si muove e nessuno ha toccato l'agente#

Attivare Drift detection accanto al gate di deploy e il golden set viene rieseguito automaticamente: con la cadenza che si stabilisce e di nuovo ogni volta che cambiano i modelli alla base delle chiamate. Ogni esecuzione viene confrontata con la precedente dello stesso agente e si riceve un avviso quando il punteggio scende oltre il limite impostato.

Avvisa in caso di calo, non di soglia minima, ed è questa la differenza che lo rende utilizzabile. Un agente che ha sempre ottenuto il 60 per cento su un set volutamente difficile non è in deriva. Uno che ieri ha ottenuto 92 e oggi 84 lo è, e solo il secondo merita di svegliare qualcuno.

L'avviso raggiunge gli stessi canali degli allarmi di qualità e indica i casi che l'ultima volta erano stati superati e ora falliscono. Una riesecuzione dichiara nell'elenco delle esecuzioni il motivo per cui è avvenuta: secondo pianificazione oppure perché sono cambiati i modelli.

È disattivato per impostazione predefinita, perché ogni riesecuzione costa una risposta dell'agente e un passaggio di valutazione per ogni domanda del set.