Angolo di Anderson
L’AI potrebbe aiutarti a raggiungere una persona reale più velocemente

Una nuova ricerca mostra che le configurazioni di AI di tipo ChatGPT open source possono potenzialmente instradare i chiamanti alla persona giusta in un call center utilizzando il linguaggio naturale, senza seguire le scelte del menu infurianti che sono diverse ogni settimana, sembrando deliberatamente ostacolanti.
Provare a raggiungere una persona reale in un call center può essere un’esperienza frustrante, a causa della necessità di navigare tra opzioni a scelta multipla a un ritmo lento – spesso senza certezza su quale delle opzioni sia adatta al proprio caso. Se nessuna di esse lo è, gli utenti esperti tendono ad adottare trucchi e soluzioni per accedere a un consulente umano di qualche tipo e per uscire dall'”inferno delle opzioni”. Molti di noi riconosceranno questo come un’esperienza più o meno “combattiva” e ostile all’utente.
Inaspettatamente, i call center sono in prima linea per l’incremento o la sostituzione con sistemi di intelligenza artificiale; e, nonostante un approccio cauto sia consigliato da alcune parti, l’automazione dei call center con l’AI rimane un obiettivo facile per i titoli tecnologici e per la prospettiva di innovazione basata sull’AI che può offrire un ROI insolitamente precoce.
Negozio chiuso
Ma ci sono alcune aree in cui i principi open source e i dati liberamente disponibili sono raramente applicati o disponibili, e questo è uno di quelli. Ha senso: qualsiasi azienda interessata ad automatizzare i propri sistemi di risposta ai clienti avrà un interesse limitato o nullo a condividere i dati che alimentano le loro intuizioni, le loro metodologie o la loro proprietà intellettuale.
Per una cosa, condividere queste risorse costerebbe loro un vantaggio sui concorrenti; più importante, dato che i sistemi di AI sono inclini a divulgare informazioni privilegiate, è legalmente rischioso.
Ciò ha portato a una serie di giocatori ben investiti a sviluppare sistemi di risposta ai call center aiutati dall’AI in modo indipendente l’uno dall’altro (presumibilmente con una certa inevitabile ridondanza di sforzi); e a una proliferazione di startup e di aziende consolidate che cercano di soddisfare la crescente domanda di capacità di risposta ai clienti guidate dall’AI.

Un assistente vocale PolyAI apre una chiamata di servizio clienti per la società di fantasia ‘Augusta Lawn Care’, attingendo a grandi quantità di conversazioni di formazione per automatizzare le risposte attraverso l’infrastruttura del call center esistente. Fonte
Inoltre, la corsa per rimuovere la frustrazione della navigazione in un labirinto di call center ha dimostrato di essere uno stimolo per gli sforzi di ricerca – sebbene la maggior parte di tali pubblicazioni tenda a verificarsi al di fuori di Arxiv e di altre reti di pubblicazione di ricerca aperta, in linea con la natura generalmente clandestina dello sviluppo di Interactive Voice Response (IVR).
Invece, la ricerca, i dati e l’intelligence aziendale relativi all’automazione dei sistemi di risposta ai clienti con l’AI sono tutti gelosamente custoditi, con poche opzioni open source disponibili – anche se l’uso di sistemi e dati FOSS offrisse un’opzione legalmente solida, il che è dubbio.
Chiamata locale
Con questo in mente, è rinfrescante vedere un nuovo articolo della Colombia che cerca di far uscire l’IVR dalla sua cassaforte aziendale, almeno un po’. Il nuovo lavoro, un contributo conciso intitolato Oltre i toni di IVR: routing delle intenzioni dei clienti utilizzando LLM, proviene da un ricercatore dell’Universidad Distrital Francisco José de Caldas a Bogotá e sostiene di essere il primo progetto non chiuso a utilizzare Large Language Models (LLM) per generare uno schema funzionante per un sistema di routing delle intenzioni dei clienti (CIR).
Invece di cercare di accedere a dati di chiamate reali o a menu proprietari, il nuovo progetto genera tutti i componenti da zero utilizzando tre modelli di AI: uno per inventare un menu di call center realistico; un altro per simulare centinaia di reclami dei chiamanti; e un terzo per agire come chatbot, cercando di instradare quei reclami alla destinazione giusta.
Il risultato è un test-bed completamente sintetico ma convincente, che presenta una società di telecomunicazioni fittizia, insieme a 920 query di utente distinte, che consentono all’esperimento di aggirare i rischi legali mentre si indaga su quanto bene l’attuale AI possa interpretare discorsi vaghi e disordinati e comunque connettere il chiamante alla persona giusta.
I test indicano che lo schema del sistema può abbinare i reclami dei chiamanti alla destinazione del call center corretta con un’accuratezza del 89,13%, soprattutto quando vengono fornite opzioni di menu “appiattite” invece di descrizioni verbali (più su questo argomento).
Lo studio ha anche scoperto che quando i chiamanti utilizzavano un linguaggio più casuale o variato, l’AI si sbagliava di più; ma che alcuni di quegli errori si verificavano non perché l’AI fraintendeva, ma perché il menu del telefono stesso era confuso.
![Esempi di interazioni con i clienti, condivisi come parte del nuovo progetto. [Fonte] https://figshare.com/articles/dataset/Beyond_IVR_Touch-Tones_Customer_Intent_Routing_using_LLMs/30118690](https://www.unite.ai/wp-content/uploads/2025/10/figshare-examples-data.jpg)
Esempi di interazioni con i clienti, condivisi come parte del nuovo progetto. Fonte
I dati per il progetto sono stati resi pubblici.
Metodo
Il primo modello nell’approccio tripartito crea un menu di telefono dettagliato per una società di telecomunicazioni fittizia; il secondo genera messaggi unici dei chiamanti – alcuni semplici, altri riformulati o resi più casual – per simulare come le persone parlano realmente quando chiamano per aiuto. A questo proposito, sono stati generati 920 esempi per il progetto.
Il terzo modello ha avuto il compito di connettere ogni chiamante alla destinazione corretta, basandosi solo sul messaggio e su una versione del menu. Questo schema ha consentito all’esperimento di essere completamente ripetibile, mentre si aggirava la necessità di dati di chiamata reali o di esporre informazioni sui clienti:
![I tre sistemi scelti per l'approccio tripartito. [Fonte] https://arxiv.org/pdf/2510.21715](https://www.unite.ai/wp-content/uploads/2025/10/table-1-5.jpg)
I tre sistemi scelti per l’approccio tripartito. Fonte
I tre modelli utilizzati, rispettivamente, sono stati gpt-3.5-turbo; gpt-4o-mini; e gpt-4.1-mini.
Per simulare un ambiente di servizio clienti convincente, è stato necessario sintetizzare un menu di telefono complesso da zero. A causa della scarsità di set di dati rilevanti, il modello gpt-3.5-turbo è stato sollecitato a generare una struttura a più rami per un fornitore di telecomunicazioni fittizio.
Ogni ramo è stato configurato per rappresentare aree di servizio come billing, supporto tecnico account management, e nuovi servizi, con opzioni realistiche e una profondità variabile nell’albero. Da questo menu artificiale, due versioni sono state create per test successivi: una come gerarchia di testo semplice, per mimare come un umano potrebbe leggere l’intero menu; e un’altra come elenco di endpoint, ciascuno con la propria sequenza di pressioni dei pulsanti.
Ciò ha consentito al sistema di essere testato sia su una versione dettagliata che su una versione “semplificata” della sfida di routing:

Due versioni del menu del telefono sono state fornite all’AI: una gerarchia di testo dettagliata e un elenco semplificato di opzioni di menu dirette, per confrontare come ciascun formato supportasse il routing dei chiamanti al posto giusto.
Per creare i messaggi dei chiamanti necessari per il test, un secondo modello di linguaggio è stato utilizzato per produrre un set di reclami o richieste originali, con dieci esempi unici creati per ogni endpoint del menu.
Ognuno di questi è stato poi ampliato in diverse versioni riformulate, per mimare la gamma di modi in cui i chiamanti reali potrebbero esprimere i loro problemi, e sono stati introdotti cambiamenti nella lunghezza, nel tono e anche in errori minori o ‘linguaggio di riempimento’.
I 920 messaggi dei chiamanti generati all’inizio sono stati progettati per testare la precisione del sistema e per simulare l’imprevedibilità del discorso reale.
La terza fase ha testato quanto accuratamente l’ultimo modello potesse mappare ogni messaggio del chiamante alla destinazione del menu giusta, basandosi sulle due diverse modalità di presentazione del sistema IVR (vedi immagine sopra).
Nella prima versione, l’AI è stata data una descrizione completa e descrittiva dell’albero del telefono, con ogni ramo e sottopzione elencato in forma di testo. Nella seconda, ha visto solo un elenco di destinazioni finali, ciascuna legata a una sequenza di pressioni dei pulsanti.
L’obiettivo era quello di vedere se una versione semplificata del menu avrebbe reso più facile per il modello decidere dove dovesse andare ogni chiamata. In entrambi i casi, il sistema ha ricevuto un messaggio alla volta e gli è stato chiesto di restituire solo il percorso, senza parole aggiuntive o spiegazioni, per facilitare la valutazione automatica.
Isolamento
Per evitare di contaminare i risultati del test, l’esperimento ha mantenuto ogni modello isolato dagli altri: il menu del telefono è stato elaborato dal primo modello, ma poi finalizzato manualmente, in modo che rimanesse sconosciuto agli altri sistemi.
I messaggi dei chiamanti sono stati generati separatamente da gpt-4o-mini, utilizzando solo i nomi degli endpoint, e senza accesso alla struttura del menu. Infine, gpt-4.1-mini, che ha gestito il routing, ha visto solo il testo del menu e i messaggi in entrata, e non ha avuto alcun coinvolgimento nella creazione di nessuno dei due.
Metriche
Per misurare quanto bene il sistema di routing abbia funzionato, sono state utilizzate due metriche standard: accuratezza è stata definita come la percentuale di casi in cui il modello ha restituito il percorso esattamente corretto (come 1‑2‑3). Per isolare la posizione degli errori, sono state generate matrici di confusione*, che mostrano quanto spesso ogni percorso sia stato confuso con altri. Le valutazioni sono state eseguite in Python utilizzando le librerie pandas e scikit-learn.
Risultati
Nei test, l’accuratezza del modello dipendeva fortemente da come il menu del telefono era presentato: quando gli veniva fornito l’elenco appiattito dei percorsi del menu, il sistema raggiungeva il 89,13% di accuratezza sul set di dati più semplice, rispetto all’81,30% quando utilizzava la versione descrittiva completa del menu:

Accuratezza di routing per il terzo modello (LLM3), attraverso diversi formati di prompt e tipi di set di dati, indicando che i percorsi del menu appiattiti hanno costantemente superato le descrizioni gerarchiche e che l’accuratezza è scesa leggermente quando gli input sono stati aumentati con linguaggio parafrasato o informale.
Questo modello si è mantenuto per il set di dati più grande e variato, dove la versione appiattita ha nuovamente funzionato meglio, segnando l’86,52% contro l’77,07% per il formato descrittivo.
Questi risultati, sottolinea l’articolo, suggeriscono che prompt più semplici e basati su elenchi hanno aiutato il modello a corrispondere le query in modo più affidabile rispetto alle descrizioni gerarchiche lunghe.
L’accuratezza è scesa leggermente quando sono state introdotte versioni parafrasate e informali dei messaggi dei chiamanti, indicando che una maggiore varietà ha migliorato la realismo, ma ha anche reso la classificazione più difficile.
L’articolo conclude:
‘I nostri risultati mostrano che gli LLM instradano le intenzioni con maggiore accuratezza quando vengono forniti percorsi IVR appiattiti (fino al 89,13%) rispetto a descrizioni di menu verbali (fino al 77,07%), suggerendo che prompt concisi e strutturati riducono il rumore e si allineano meglio con il compito di routing.
‘Ciò supporta il principio che chiarezza e brevità migliorano le prestazioni degli LLM in impostazioni di classificazione.
‘Importante, trasformare i menu in percorsi appiattiti è un processo semplice e automatizzabile per l’uso nel mondo reale.’
Conclusione
È rinfrescante vedere almeno alcuni lavori aperti che si verificano in uno dei filoni di ricerca più chiusi e esclusivi della letteratura. Ciò che rimane da vedere è se le architetture di “inquadramento” che contestualizzano gli LLM saranno necessarie in futuro o se il modello avrà solo bisogno di accedere all’intelligenza aziendale (localmente disponibile), eliminando la necessità per l’azienda di condividere dati con fornitori di terze parti.
Ultimamente, i principi di progettazione più ampi in atto qui sembrano probabilmente essere adottati naturalmente da futuri sistemi di intelligenza artificiale, anche in domini al di fuori del servizio clienti, senza richiedere un allineamento deliberato a quel caso d’uso.
* Si prega di fare riferimento all’articolo originale per questi.
Pubblicato per la prima volta mercoledì, 29 ottobre 2025












