Vai al contenuto principale
Tutti i lavori
LOG-01In produzione2025–26

Migrare un voicebot da 70K conversazioni al giorno dall'NLU a una GenAI ibrida

Superare la classificazione degli intenti in un assistente regolamentato e ad alti volumi, senza rompere ciò su cui contano clienti e azienda.

Contesto
Grande azienda italiana · regolamentata · voce + chat
Ruolo
Specialista GenAI nel team di deployment: architettura, valutazione, KPI, rollout
Dimostra
Responsabilità end-to-end di una migrazione in produzione: divisione dell'architettura, eval, nuovi KPI, SLA con i fornitori, gestione del cambiamento.
70K+
conversazioni al giorno nel perimetro
~15%
conversazioni perse per le frasi con più richieste, prima della migrazione
6 sett.
per ricostruire i KPI di un sistema probabilistico

Problema

L'assistente si basava sulla classica classificazione degli intenti: centinaia di intenti, migliaia di frasi di esempio, un team di conversation designer a tenerlo in piedi. Funzionava, finché i clienti non hanno cominciato a parlare come si parla davvero. "Devo cambiare indirizzo, e poi ho una domanda sull'ultima bolletta" viene riconosciuto come un solo intento. L'altro si perde, il cliente ripete tutto e spesso riattacca. Circa il 15% delle conversazioni falliva così.

Vincoli

  • Settore regolamentato. Tutto ciò che tocca soldi, identità o modifiche ai dati personali non può essere improvvisato da un modello.
  • Volumi. Decine di migliaia di conversazioni al giorno: una regressione dell'1% sono centinaia di clienti scontenti prima di pranzo.
  • Contratti e KPI scritti per sistemi deterministici. "Accuratezza degli intenti al 99,5%" non ha un equivalente generativo.

Architettura

Non siamo passati a una GenAI pura. Il percorso è diviso per livello di rischio, con un livello di orchestrazione che decide in tempo reale a quale lato appartiene ogni richiesta.

                 ┌──────────────────────────┐
  cliente  ───▶  │ orchestrazione / routing │  ◀── contesto, stato auth, policy di rischio
                 └────────────┬─────────────┘
              ┌───────────────┴────────────────┐
              ▼                                ▼
   ┌─────────────────────┐          ┌──────────────────────┐
   │ FLUSSI DETERMINIST. │          │  FLUSSI GENERATIVI   │
   │ auth · pagamenti ·  │          │  FAQ · triage ·      │
   │ modifica dati pers. │          │  troubleshooting     │
   └──────────┬──────────┘          └──────────┬───────────┘
              └──────────────┬─────────────────┘
                             ▼
              passaggio all'operatore con riassunto

Il livello di orchestrazione è il componente meno affascinante, ed è quello dove il sistema riesce o fallisce.

Cosa ho fatto

  • Ho ridefinito i KPI. Contenimento e "conversazioni non gestite" perdono significato quando un bot può sempre dire qualcosa. Siamo passati a completamento del task, qualità della conversazione valutata da un LLM-as-judge calibrato e sforzo del cliente (turni fino alla risoluzione).
  • Ho sostituito la suite di test. I test unitari sugli intenti sono diventati golden dataset costruiti da trascrizioni reali di produzione, valutati su più dimensioni.
  • Ho organizzato il rilascio a tappe. Lab → shadow → pilota → rollout. In shadow mode il sistema ha risposto in silenzio su oltre 500 conversazioni campionate al giorno, per una o due settimane, prima di parlare con un cliente.
  • Ho riscritto gli SLA con i fornitori per un sistema probabilistico, insieme all'ufficio legale e ai partner tecnologici.

Cosa si è rotto

  1. Tutti i KPI. Sei settimane per ricostruire il sistema di misura.
  2. Il processo di QA. "Lancia la suite" è diventato "giudica la qualità su più dimensioni". Competenze diverse; non tutti hanno fatto il salto.
  3. I contratti. Tre mesi di rinegoziazione: nessuno, da nessuna delle due parti, aveva mai visto uno SLA per un sistema generativo.
  4. La fiducia delle operations. Le operations sapevano prevedere un diagramma di flusso; non sapevano prevedere un modello. Guardrail, filtri in tempo reale e un processo di gestione degli incidenti per i contenuti generati dall'AI sono arrivati prima della fiducia.

Cosa farei diversamente

Mettere in conto il 30% dello sforzo per la tecnologia e il 70% per tutto quello che le sta intorno, e poi dare per scontato di aver comunque sottostimato quel 70%. Partire con la revisione di KPI e SLA dal primo giorno, non dopo il pilota.