Il modo in cui un voicebot AI elabora la voce determina se suona naturale o lento e inaffidabile. Al momento ci sono due architetture in circolazione tra i costruttori, e la scelta tra loro ha conseguenze sull’esperienza della chiamata, sull’affidabilità del sistema e su ciò che il bot può ricavare da una conversazione. L’approccio più vecchio collega tre componenti separati uno dietro l’altro, mentre il metodo più recente elabora l’intera conversazione in una volta.

Schema in cui da sinistra ci sono tre componenti impilati e da destra un unico modello vocale realtime

L’approccio classico: stitching

Quando i primi voicebot sono stati costruiti, era logico collegare tre componenti già esistenti. La voce in arrivo passava attraverso un motore di riconoscimento vocale che ne creava il testo, dopodiché un modello linguistico leggeva quel testo e formulava una risposta, e infine un motore di sintesi vocale convertiva quella risposta di nuovo in voce udibile. Questa architettura è chiamata “stitching” nel settore, perché colleghi tre sistemi indipendenti insieme in una catena.

Per un certo tempo ha prodotto risultati utilizzabili, e per i team che non volevano addestrare un modello vocale proprio era l’unico percorso pratico. Tuttavia, nella pratica emergono tre vulnerabilità, perché ogni collegamento può guastarsi indipendentemente. Il riconoscimento vocale può udire male una frase, il modello linguistico può dare una risposta lenta o errata e la sintesi vocale può guastarsi nel momento sbagliato. Molti team quindi costruiscono un backup con un fornitore TTS o LLM alternativo, affinché il bot continui a funzionare in caso di guasto. Questo risolve l’interruzione, ma i chiamanti sentono improvvisamente una voce completamente diversa e diventano confusi su con chi stanno effettivamente parlando.

Il secondo svantaggio potrebbe pesare ancora di più. Nello stitching, il modello linguistico vede solo una trascrizione testuale, quindi non può percepire il tono, il volume, l’esitazione e l’emozione del chiamante. Un cliente irritato e uno soddisfatto suonano identici al modello una volta che le loro parole sono scritte, il che compromette la sensibilità al contesto che rende prezioso un dialogo. I segnali sulla presunta età, sulla lingua madre o sull’umore vanno persi nella traduzione verso il testo, mentre proprio questi segnali spesso determinano come un operatore condurrebbe una conversazione.

Il nuovo approccio: un unico modello vocale realtime

Dal momento che OpenAI il 24 febbraio 2026 ha reso disponibile gpt-realtime-1.5, esiste un secondo modo di costruire voicebot che nella maggior parte dei casi funziona meglio. Invece di tre componenti separati uno dietro l’altro, un unico modello ascolta e parla direttamente, eliminando l’intero livello intermedio di trascrizione e sintesi. Il modello comprende le parole, il tono e l’emozione del chiamante contemporaneamente, permettendogli di rispondere direttamente. Quanto fluida sia questa modalità di funzionamento nella pratica lo mostra bene una demo di Charlierguo.

Questo produce vantaggi concreti nell’uso quotidiano. C’è solo un punto in cui qualcosa può guastarsi invece di tre, il che riduce significativamente le probabilità di interruzione. Il tempo di risposta è tipicamente inferiore a 400 millisecondi, quindi la conversazione procede naturalmente senza il ritardo che si verifica con lo stitching. La multilingualità è integrata, consentendo lo stesso modello di passare facilmente tra italiano, inglese, tedesco e altre lingue senza che tu debba preconfigurare quel passaggio. E poiché il modello elabora l’audio anziché il testo, riconosce un cliente irritato dalla sua voce e può trasferirlo direttamente a un operatore senza la necessità di una parola chiave o di un’escalation esplicita.

Quando lo stitching è ancora la scelta giusta

Rimane una nicchia dove l’architettura più vecchia si adatta meglio, ovvero situazioni in cui non è necessario condurre una conversazione dal vivo ma piuttosto analizzare una registrazione successivamente. Quando un call center vuole far riassumere, codificare o scremare le conversazioni per conformità dopo la chiamata, non c’è requisito di latenza e puoi tranquillamente scegliere un modello linguistico specializzato. Pensa a un modello linguistico medico che riconosce abbreviazioni e terminologia specializzata dell’assistenza sanitaria, o a un motore di riconoscimento vocale appositamente addestrato su un dialetto regionale. In questi scenari, la precisione su quel singolo componente pesa più dell’esperienza complessiva della conversazione, perché non c’è un chiamante in linea in attesa di risposta.

La nostra raccomandazione

Per le aziende che desiderano che un voicebot gestisca conversazioni dal vivo, consigliamo nella stragrande maggioranza dei casi l’approccio realtime. La combinazione di risposta più veloce, minore vulnerabilità ai guasti, multilingualità senza configurazione e sensibilità al tono produce un’esperienza di chiamata che i chiamanti non percepiscono come robotica. Per analisi post-chiamata e altri scenari in cui la precisione su uno specifico componente è decisiva, continuiamo a utilizzare architetture di stitching, perché continuano a produrre il risultato più forte lì.

Il nostro team costruisce in entrambe le architetture

CallFactory costruisce voicebot in entrambe le architetture, a seconda di ciò che meglio si adatta al tuo flusso di chiamata. Sia che tu voglia una soluzione completamente gestita in cui il nostro team configura tutto da inizio a fine, o preferisci un IVR dedicato sulla tua infrastruttura, forniamo implementazioni conformi al GDPR disponibili 24 ore su 24, sette giorni su sette.

Contatta il nostro team per discutere quale architettura si adatta alle tue conversazioni, come procede l’integrazione con i tuoi sistemi esistenti e entro quale termine il voicebot può andare in diretta. In questo modo riceverai una chiara stima dei tempi di consegna e dell’investimento, e da giorno uno puoi far gestire le chiamate in arrivo e in uscita da un voicebot che parla e ascolta a un livello che fino a poco tempo fa era impensabile.