La voce in tempo reale offre alle persone un modo radicalmente diverso di interagire con le applicazioni basate sull'IA. Anziché digitare o navigare tra menu, gli utenti parlano in modo naturale e ricevono risposte con un ritmo in tempo reale e un contesto emotivo.
Creare un'eccellente esperienza vocale in tempo reale significa coordinare un'interazione dal vivo. È qui che inizia il vero lavoro sul prodotto. L'esperienza in tempo reale è immediata e naturale; creare un'applicazione capace di mantenerla tale costituisce una sfida ingegneristica specifica.
Il modello è solo una parte del sistema. Le applicazioni in produzione richiedono un'infrastruttura nativa per la voce, una netta separazione tra il flusso della conversazione e il ragionamento più approfondito e un controllo basato sugli eventi per gestire la sessione mentre si svolge.
Le misure di protezione e la valutazione concentrano gran parte delle difficoltà ancora irrisolte. I controlli di sicurezza devono tenere il passo con l'audio dal vivo, mentre qualità conversazionali effimere come tempi, tono e fluidità sono difficili da misurare con le strategie di valutazione tradizionali.
Oggi, la maggior parte delle applicazioni di IA con funzionalità vocali opera ancora allo stesso modo: riceve il parlato, lo converte in testo, un modello elabora la risposta e una voce sintetizzata la legge. Funziona. Ma l'interazione rivela la propria natura: è una pipeline, non una conversazione.
La voce in tempo reale cambia tutto. Gli utenti parlano in modo naturale e ricevono risposte dotate di ritmo, tono e contesto emotivo. L'esperienza è più rapida e fluida rispetto alle pipeline concatenate di conversione da voce a testo: ricorda più una conversazione con una persona che l'utilizzo di un sistema.
Abbiamo visto questa tecnologia aprire opportunità di prodotto difficili da cogliere con le architetture a pipeline. Gli agenti vocali in tempo reale possono gestire interazioni con il servizio clienti che altrimenti richiederebbero lunghi e rigidi menu IVR e trasferimenti tra reparti. Possono offrire formazione, accompagnare l'inserimento, migliorare l'accessibilità su diversi canali e molto altro. Ovunque la conversazione orale offra un vantaggio sulle interfacce testuali, vale la pena sviluppare soluzioni vocali in tempo reale.
La maggior parte delle applicazioni vocali utilizza il cosiddetto «approccio concatenato»: una pipeline di modelli separati per la conversione da voce a testo, l'elaborazione del linguaggio e la conversione da testo a voce. Questi sistemi funzionano bene e offrono numerose opportunità, ma l'audio è presente solo alle estremità della pipeline. I passaggi distinti impongono una struttura e introducono latenza, rendendo l'interazione meno naturale di una vera conversazione.
La voce in tempo reale adotta un approccio diverso. Anziché affidarsi a modelli distinti per ascoltare, pensare e parlare, un unico modello gestisce nativamente tutte e tre le attività, comprendendo e generando simultaneamente sia l'audio sia le trascrizioni. Input e output vengono elaborati senza interruzioni, consentendo al sistema di rispondere con tempi naturali ed espressività emotiva, nel ritmo realistico di una conversazione dal vivo. Di conseguenza, tempi, tono e gestione delle interruzioni diventano elementi centrali del prodotto.
L'esperienza in tempo reale è attraente perché appare immediata; è difficile da realizzare perché nessuno aspetta il proprio turno. Per supportarla non basta generare audio in modo rapido e accurato. La parte difficile è tutto il resto. Il modello opera all'interno di una sessione dal vivo; tutto ciò che lo circonda — stato, sicurezza, orchestrazione e controllo — deve procedere in parallelo alla conversazione e allo stesso ritmo.
In un'applicazione vocale concatenata, le conversazioni a turni offrono una chiara struttura di botta e risposta. L'utente parla, il sistema risponde e inizia il passaggio successivo. La voce in tempo reale non offre questa struttura. Entrambe le parti possono parlare contemporaneamente oppure può esserci un silenzio in cui nessuno parla. Un utente può interrompere il sistema a metà risposta o fare una domanda di approfondimento prima che abbia finito di parlare. Le interruzioni smettono di essere casi limite e diventano una modalità di interazione fondamentale.
È proprio questo a rendere le applicazioni in tempo reale essenzialmente un problema di coordinamento e a far sì che il sistema intorno al modello conti quanto il modello stesso.
Per supportare su larga scala un sistema di questo tipo occorre progettarlo specificamente per l'interazione dal vivo, considerando tre aspetti ricorrenti nei sistemi che arrivano in produzione.
Le sessioni vocali in tempo reale devono gestire lo streaming audio, l'alternanza dei turni, le interruzioni, il ciclo di vita della connessione e l'esecuzione dell'agente. A seconda dell'ambiente in cui viene distribuita l'applicazione, potrebbe essere necessario anche il supporto telefonico. Sono elementi fondamentali dell'esperienza e indispensabili per rendere scalabile l'applicazione.
Il primo requisito è un livello di sessione nativo per la voce. I framework di comunicazione in tempo reale (RTC) offrono all'applicazione un ambiente in cui gestire i partecipanti, trasmettere l'audio ed eseguire gli agenti in un contesto telefonico. Nella nostra esperienza, Livekit si è rivelato particolarmente utile grazie a uno stack WebRTC a bassa latenza, con cancellazione del rumore di alta qualità e riduzione del jitter integrate. Implementare internamente questo livello raramente giustifica la maggiore complessità.
Un'architettura multi-agente per la voce in tempo reale si basa essenzialmente sulla separazione delle responsabilità.
I modelli vocali in tempo reale sono molto efficaci nello streaming di audio conversazionale, ma non sono ottimizzati per un ragionamento più approfondito. Attività come le chiamate di strumenti, il recupero di informazioni o le decisioni strutturate traggono vantaggio dall'esecuzione mediante un modello diverso.
Un modello utile è l'architettura risponditore-pensatore.
Il risponditore è l'agente vocale in tempo reale. Ha il compito di mantenere viva l'interazione: ascolta, parla, gestisce le interruzioni e preserva la fluidità della conversazione. La sua progettazione privilegia reattività, chiarezza e continuità emotiva.
Il pensatore è un agente separato, basato su un modello capace di ragionamento. Opera fuori dal flusso principale e gestisce attività come l'uso di strumenti, il recupero di informazioni e la pianificazione. Il risponditore può interpellarlo quando necessario e integrare i risultati nella conversazione.
In alcuni casi, il pensatore può gestire direttamente il ragionamento. In altri, può orchestrare un insieme di agenti specializzati. L'idea centrale è affidare questo lavoro a un modello più adatto alle attività di ragionamento.
Il vantaggio è semplice: il risponditore rimane rapido, colloquiale e concentrato, mentre il pensatore gestisce il lavoro che richiede più tempo, contesto o struttura.
I futuri sviluppi dei modelli di frontiera potrebbero rendere superfluo questo approccio, ma per ora abbiamo riscontrato che questo schema supera con regolarità le soluzioni basate su un singolo agente.
I sistemi vocali in tempo reale producono naturalmente un flusso continuo di eventi.
Gli utenti iniziano a parlare, fanno pause e interrompono. Le trascrizioni vengono aggiornate progressivamente. Le risposte vengono generate e trasmesse in streaming. Arrivano risultati esterni. Le condizioni interne alla sessione cambiano. Tutti questi elementi possono essere acquisiti, trasmessi e archiviati come eventi chiave che hanno determinato lo stato attuale della conversazione. Senza questi eventi, perdiamo la capacità di intervenire in modo granulare e mirato.
Un approccio basato sugli eventi offre un modo chiaro per gestire tutto questo. Il sistema acquisisce gli eventi nel momento in cui si verificano, aggiorna lo stato della sessione e attiva le azioni successive appropriate.
Gestori leggeri mantengono reattivo il percorso in tempo reale, mentre le attività più complesse — come aggiornare le macchine a stati, registrare le metriche, rimuovere informazioni sensibili, aggiornare i database e chiudere una sessione — vengono avviate come processi asincroni in background.
Con l'aggiunta di nuove funzionalità, il numero di queste attività in background può crescere rapidamente. Anche piccole modifiche al prodotto possono introdurre nuovi flussi di eventi e nuove dipendenze. Un'architettura ben strutturata per gestire questa concorrenza è importante affinché il sistema resti comprensibile e affidabile durante la sua evoluzione.
Questo approccio basato sugli eventi risponde anche a un'esigenza essenziale del prodotto: dare forma alla conversazione stessa. Un sistema audio in tempo reale non si limita a generare risposte: gestisce il ritmo, i silenzi e le interruzioni e decide come e quando concludere una sessione. Questi comportamenti fanno parte dell'esperienza del prodotto e richiedono una progettazione esplicita.
Man mano che lo stato della sessione cambia in base al numero di turni, al tempo trascorso o al comportamento dell'utente, il sistema può fornire indicazioni mirate al risponditore. Potrebbe suggerire all'agente di aiutare l'utente a concludere quando si avvicina il limite della sessione oppure fornire chiarimenti se l'interazione si blocca. Questi interventi sono leggeri, ma rendono l'esperienza intenzionale e coerente.
Un sistema ben progettato mantiene una visione chiara dello stato della sessione: chi sta parlando, come procede la conversazione e quali condizioni sono state soddisfatte. Questo stato, aggiornato continuamente dal flusso di eventi, consente di fornire le indicazioni giuste al momento giusto.
Le misure di protezione sono indispensabili nei sistemi di IA rivolti agli utenti. Gestiscono sicurezza, conformità, usi impropri e affidabilità. In un sistema a turni, è evidente quando eseguirle: dopo che l'utente ha parlato o prima di trasmettere una risposta.
La voce in tempo reale elimina quasi tutti questi comodi punti di controllo. L'input dell'utente arriva in modo continuo. L'output audio potrebbe essere già in streaming. Le trascrizioni complete spesso arrivano dopo l'audio. Se il sistema attende messaggi completi prima di controllarli, la conversazione non sembra più in tempo reale.
Le misure di protezione devono invece operare in parallelo alla conversazione per preservare la naturalezza dell'interazione. Un approccio consiste nel trasmettere l'audio a un buffer e valutare in modo asincrono i frammenti di trascrizione non appena disponibili. In questo modo, i controlli di sicurezza possono essere eseguiti quasi in tempo reale senza bloccare l'interazione.
Quando si attiva una misura di protezione, il sistema può reagire nel contesto reindirizzando la conversazione, modificando il comportamento o, se opportuno, terminando la sessione. In questo modo, le misure di protezione operano in tempo reale senza compromettere l'esperienza utente.
L'aspetto più difficile nel valutare un sistema conversazionale in tempo reale è che alcune delle qualità più importanti — tempi, interruzioni, fluidità e tono — non possono essere rilevate da test basati solo sulle trascrizioni.
Le pipeline di valutazione standard sottopongono al sistema scenari realistici, ne osservano gli output e assegnano loro un punteggio. Per i sistemi testuali o con audio concatenato è semplice: si invia testo e si controlla il testo restituito. In tempo reale, l'input è audio dal vivo e le dinamiche conversazionali più importanti si sviluppano nel tempo: come l'agente gestisce la sovrapposizione del parlato, quanto rapidamente risponde e come riprende dopo un'interruzione.
I test manuali, parlando direttamente con l'agente, rilevano queste qualità ma non sono scalabili. L'automazione basata sulle trascrizioni è scalabile, ma elimina il segnale che distingue una buona esperienza in tempo reale da una scadente.
Nessun metodo è sufficiente da solo. La soluzione pratica è combinarne diversi:
Valutazioni tra agenti: un secondo agente in tempo reale, istruito a impersonare uno specifico profilo utente, conversa con il sistema sottoposto a test. Un terzo LLM, nel ruolo di giudice, assegna un punteggio all'interazione. Questo permette di testare su larga scala l'intero percorso audio, inclusi i tempi e la gestione delle interruzioni.
Metriche non funzionali: il tempo necessario per il primo output audio e l'analisi del sentiment delle trascrizioni forniscono indicatori quantitativi indiretti della qualità della conversazione.
Revisione qualitativa manuale: resta essenziale per individuare i problemi che sfuggono alle metriche automatizzate, soprattutto in relazione al tono e alla naturalezza.
Nessun metodo copre ogni aspetto. Per distribuire agenti in tempo reale in produzione è necessario combinare tutti e tre i metodi. Anche così, gli strumenti per valutare l'audio in tempo reale restano meno maturi rispetto a quelli per l'IA basata sul testo.
La voce in tempo reale cambia la natura del prodotto. Per gli utenti, tempi, interruzioni, silenzi e riprese contano quanto le parole.
Questo significa che il modello è solo una parte del sistema. Un sistema vocale in tempo reale pronto per la produzione richiede un livello di sessione nativo per la voce, una netta separazione tra parlato e ragionamento e un controllo basato sugli eventi durante la sessione dal vivo. Le misure di protezione restano il collo di bottiglia della latenza, ma approcci creativi possono preservare gran parte dell'esperienza in tempo reale.
La valutazione resta l'elemento più debole dello stack. Non esiste ancora un metodo consolidato per valutare le qualità che rendono piacevole la voce in tempo reale: tempi, tono, gestione delle interruzioni e fluidità della conversazione. Finché non esisterà, i team che sviluppano questa tecnologia dovranno combinare test automatizzati, sessioni tra agenti e revisioni manuali.