Qual è il metodo migliore per valutare l'effetto causale dell'implementazione di un assistente AI generativo nella prima linea di supporto clienti sulla soddisfazione degli utenti (CSAT) e sui costi operativi, se il completo A/B testing non è possibile a causa del rischio di degrado del servizio durante le ore di punta, esiste un effetto di apprendimento sia per gli operatori che per gli utenti, e parte dei dialoghi richiede l'escalation a un essere umano, creando una dipendenza tra il gruppo di test e il gruppo di controllo?

Risposta alla domanda

Storicamente, il supporto clienti è passato da una monopolizzazione da parte di operatori umani all'automazione tramite chatbot basati su regole, che però spesso frustavano gli utenti a causa di scenari rigidi. L'attuale fase è caratterizzata dall'implementazione di Large Language Models (LLM) come GPT-4 o Claude, in grado di sostenere dialoghi contestuali e risolvere compiti complessi senza una programmazione logica rigida. Il problema della valutazione dell'efficacia di tali sistemi è aggravato dal fatto che le metriche tradizionali (tempo di risoluzione, cost-per-ticket) correlano in modo non lineare con la qualità del servizio: la riduzione dei costi può portare a un calo del CSAT, mentre un aumento dell'automazione può portare a una crescita della frustrazione in caso di escalation non riuscite.

La formulazione del problema richiede l'isolamento dell'effetto pulito dell'assistente AI, separato dalla stagionalità (le vendite festive cambiano il profilo delle richieste), dall'effetto novità (gli utenti sperimentano maggiormente con il chatbot nelle prime settimane) e dall'endogenicità dell'auto-selezione (le richieste semplici vengono gestite dal bot, quelle complesse direttamente dagli umani). La classica randomizzazione non è possibile, poiché disattivare il supporto per il gruppo di controllo durante le ore di punta crea rischi etici e commerciali e l'escalation del dialogo dal bot all'umano inquina l'effetto pulito.

La soluzione ottimale è l'uso del Regression Discontinuity Design (RDD) al di sopra di una soglia di attesa. Quando il numero di utenti in attesa supera una soglia N (ad esempio, 5 persone), il sistema offre automaticamente l'assistente AI come alternativa all'attesa per l'operatore. Questo crea un esperimento naturale: gli utenti a sinistra e a destra della soglia sono statisticamente identici per caratteristiche osservabili e non osservabili. Per tenere conto dell'effetto di apprendimento del modello si applica Difference-in-Differences con un gruppo proxy - ad esempio, gli utenti notturni, dove il bot funziona costantemente, vengono confrontati con una finestra temporale simile prima dell'implementazione. Per analizzare l'eterogeneità degli effetti (diverso impatto per diverse categorie di richieste) si utilizzano Causal Forests, che permettono di costruire effetti medi condizionati (CATE).

Situazione reale

In un grande progetto di e-commerce con 500K richieste al mese, il team ha deciso di implementare un assistente LLM per gestire richieste come "dove è il mio ordine" e "modifica indirizzo di consegna". Il problema era che il pilota coincideva con la stagione natalizia, quando il traffico era aumentato di 3 volte, e i dati storici mostrano un calo stagionale del CSAT a causa dei ritardi nella logistica indipendentemente dalla qualità del supporto.

Il primo approccio considerato è stato il confronto diretto delle metriche mese prima e mese dopo l'implementazione. Vantaggi: semplicità di implementazione, non richiede modifiche all'infrastruttura. Svantaggi: totale assenza di controllo sulla stagionalità, impossibilità di separare l'effetto dell'AI dall'effetto della crescita del traffico generale e dal cambiamento dell'assortimento (i prodotti natalizi hanno un diverso profilo di restituzione). Questo approccio è stato subito scartato.

Il secondo approccio è uno split A/B geografico, dove in alcune regioni il bot è attivo e in altre no. Vantaggi: pura randomizzazione, semplice interpretazione. Svantaggi: effetti di rete (un utente può vivere nella regione A, ma effettuare un ordine nella regione B per un amico), diversa infrastruttura logistica influenza la natura delle richieste, e nelle ore di punta un sovraccarico in una regione creerebbe il rischio di perdere clienti. Si è deciso di cercare un'alternativa.

La soluzione scelta è stata RDD con una soglia di attesa di 3 persone. Quando la coda superava 3 in attesa, il sistema proponeva l'assistente AI con la possibilità di rimanere in attesa per l'umano. Per correggere l'effetto di escalation è stata utilizzata un'analisi Intent-to-Treat (ITT): si è confrontato tutti a cui è stato proposto il bot, indipendentemente dall'utilizzo effettivo, evitando così il bias di auto-selezione per competenze tecniche. Inoltre, è stato costruito un Synthetic Control dai dati storici di categorie di richieste simili, dove il bot non è stato utilizzato (ad esempio reclami complessi), per filtrare le fluttuazioni stagionali.

Risultato finale: è stato possibile misurare che l'assistente AI riduce il tempo medio di risoluzione delle richieste semplici da 8 a 2 minuti senza un calo statisticamente significativo del CSAT (una differenza di 0.1 punti all'interno dell'intervallo di confidenza). Tuttavia, è stato scoperto un effetto negativo per il segmento "restituzioni": durante l'escalation dal bot all'umano il CSAT era inferiore del 15% rispetto a una richiesta diretta all'operatore, il che ha portato alla creazione di un percorso fast-track separato per tali richieste. I costi operativi sono diminuiti del 30% grazie al rilascio della prima linea.

Cosa i candidati spesso tralasciano

Come gestire correttamente l'endogenicità dell'escalation, quando un utente, deluso dal bot, passa a un umano con frustrazione aumentata?

I candidati spesso propongono di confrontare solo dialoghi di successo con il bot contro dialoghi con un umano, ignorando il bias di sopravvivenza. L'approccio corretto è analizzare il Local Average Treatment Effect (LATE) attraverso variabili strumentali: l'uso di guasti tecnici casuali nel funzionamento del bot (quando è temporaneamente non disponibile) come strumento per valutare l'effetto specificamente per coloro che sarebbero stati serviti dal bot se tale opportunità fosse esistita. Questo permette di separare l'effetto della tecnologia stessa dall'effetto della selezione per tipo di richiesta.

Perché le metriche standard di accuratezza del bot (F1-score, BLEU) non sono corrette per la valutazione del causal impact del prodotto?

Spesso gli analisti si concentrano sulla qualità della generazione delle risposte, dimenticando che l'obiettivo del prodotto è cambiare le metriche di business, non la perfezione tecnica. LLM può generare risposte corrette, ma irrilevanti, o viceversa, fornire istruzioni tecnicamente imprecise, ma risolutive per il problema dell'utente (ad esempio, "prova a riavviare l'applicazione"). L'approccio corretto è valutare uplift a livello di sessione utente utilizzando Propensity Score Matching per allineare la complessità delle richieste, non la precisione nella generazione del testo.

Come considerare la non-stazionarietà dell'effetto durante l'addestramento continuo del modello su nuovi dati?

I candidati tralasciano che LLM in produzione è soggetto a continual learning: il modello viene riaddestrato su dialoghi etichettati quotidianamente, quindi l'effetto della settimana 1 non è comparabile con quello della settimana 4. È necessario utilizzare modelli Time-Varying Treatment Effects con valutazioni a rolling window o Bayesian Structural Time Series (BSTS) per la correzione dinamica del baseline. Ignorare questo porta a una sottovalutazione dell'effetto a lungo termine, quando il bot "impara" dalla specificità del prodotto, o a una sovrastima dell'effetto novità.