Come funziona davvero l'IA vocale in tempo reale (STT → LLM → TTS, spiegato)
Cosa succede tra il "pronto" e la risposta dell'agente, spiegato in parole semplici. Niente gergo, niente giri di parole.
L'IA vocale in tempo reale è una pipeline a tre stadi con due elementi di orchestrazione attorno. L'audio entra → lo speech-to-text lo trasforma in parole → un LLM decide cosa fare → il text-to-speech riconverte la risposta in audio. Attorno a tutto questo: la gestione dei turni (quando ha smesso di parlare il chiamante?) e la gestione del barge-in (cosa succede se ci interrompe?). È tutto qui.
L'intera pipeline deve concludersi in meno di ~700 ms, altrimenti smette di sembrare umana. Oltre questa soglia i chiamanti si mettono a disagio, si ripetono e riagganciano. Al di sotto, dimenticano di parlare con un'IA. Lo stack di Retell gira intorno ai 600 ms end-to-end. Non è fortuna. È il risultato di ogni stadio che alimenta in streaming quello successivo, invece di aspettare che finisca.
La maggior parte della latenza si nasconde dove non te l'aspetti. Non nello STT, non nel TTS, ma nelle decisioni sulla gestione dei turni e nel time-to-first-token dell'LLM. Se il tuo progetto sembra lento, sono questi i due punti da controllare per primi.
Lo streaming è il trucco. Lo STT emette trascrizioni parziali ogni ~50 ms invece di aspettare una frase completa. L'LLM trasmette in streaming i token man mano che vengono generati. Il TTS trasmette in streaming i frammenti audio prima ancora che la risposta completa esista. Nulla di tutto ciò funziona se anche un solo stadio aspetta che il precedente "finisca".
Gli stack del 2026 si somigliano tutti dal punto di vista architetturale. Ciò che separa il "livello produzione" dalla "demo" è la qualità dell'orchestrazione: la messa a punto del VAD, i modelli di gestione dei turni, la gestione delle interruzioni, la latenza delle chiamate a funzione. È lì che va l'effettivo investimento ingegneristico.
Togli di mezzo il marketing e un agente vocale è una pipeline. L'audio entra tramite il telefono. Il software lo trasforma in testo. Un modello linguistico legge quel testo, decide cosa dire o cosa fare e genera una risposta. Altro software riconverte la risposta in audio. L'audio esce di nuovo dal telefono. Il chiamante lo sente, dice qualcosa e il ciclo riparte. Fine. È tutto il prodotto.
Il motivo per cui quel semplice ciclo ha richiesto anni per funzionare è che tutto deve accadere in meno di un secondo. Ogni parte della pipeline deve essere in streaming. Ogni transizione tra gli stadi deve essere quasi istantanea. Due stadi devono prendere decisioni in tempo reale rigoroso: la gestione dei turni ("il chiamante ha già smesso di parlare?") e la gestione del barge-in ("il chiamante ha appena iniziato a parlarmi sopra, cosa faccio?"). Sbaglia una qualsiasi di queste cose e la conversazione va in pezzi in un modo che i chiamanti notano immediatamente, anche se non riescono a spiegare perché.
Questo articolo è la versione senza marketing di come funziona davvero un agente vocale nel 2026. Percorreremo un singolo turno di conversazione dall'inizio alla fine, vedremo dove si nasconde la latenza, parleremo dell'orchestrazione che separa gli stack di produzione dalle demo e sfateremo alcuni luoghi comuni su ciò che sta effettivamente accadendo sotto il cofano.
Se sei un PM che cerca di capire cosa stanno costruendo i tuoi ingegneri, questo fa per te. Se sei un ingegnere che valuta se scegliere una piattaforma o costruirla da solo, vale anche per te. In ogni caso: alla fine saprai cosa succede ogni volta che qualcuno dice "pronto" e un'IA risponde "ciao".
Ecco la versione da ascensore.
Un agente vocale è tre cose in fila con due cose che le avvolgono. Le tre in fila: STT → LLM → TTS. Lo speech-to-text trasforma l'audio del chiamante in parole. Un modello linguistico di grandi dimensioni legge quelle parole (più il tuo system prompt, la conversazione fino a quel punto e una descrizione degli strumenti che l'agente può chiamare) e decide se parlare o chiamare una funzione. Il text-to-speech riconverte la risposta del modello in audio.
Le due cose che avvolgono quella pipeline: la gestione dei turni e il barge-in. La gestione dei turni è il sistema che decide quando il chiamante ha terminato un pensiero, così l'agente può rispondere: molto più difficile di quanto sembri, perché gli esseri umani fanno pause a metà frase in continuazione. Il barge-in è il sistema che gestisce un chiamante che interrompe l'agente a metà risposta: anche questo più difficile di quanto sembri, perché devi fermare il TTS all'istante, scartare qualunque cosa il modello stesse per dire e rimetterti in ascolto.
Perché è difficile: ogni stadio deve essere in streaming e ogni stadio ha un budget di latenza che non puoi sforare. Porta l'intero ciclo sotto i ~700 ms e la conversazione sembra umana. Superali e non lo è più. È tutto qui il lavoro.
Percorriamo un turno di conversazione dall'inizio alla fine. Il chiamante dice "Salve, vorrei prenotare una pulizia per martedì pomeriggio prossimo" e 600 ms dopo l'agente risponde. Ecco tutto ciò che accade nel mezzo.
La chiamata colpisce per primo il tuo livello di telefonia: un SIP trunk se stai usando il tuo operatore esistente, o uno stream WebRTC se stai usando un numero Retell. In entrambi i casi, l'audio del chiamante arriva come un flusso di piccoli pacchetti, di solito da 20 ms ciascuno. Dal momento in cui il chiamante inizia a parlare, quei pacchetti scorrono nel tuo stack alla massima velocità. Il round-trip di rete è il primo pezzo del budget di latenza su cui non puoi barare: tipicamente 30-80 ms a seconda della geografia e dell'operatore, prima ancora che sia iniziato qualsiasi lavoro dell'IA.
Il VAD è il modello leggero che decide se l'audio in arrivo è parlato o silenzio. Gira su ogni frammento in ingresso, in millisecondi. Perché preoccuparsene? Due ragioni. Una: non vuoi inviare silenzio al tuo STT, spreca risorse di calcolo e confonde la gestione dei turni. Due: il VAD è il primo segnale che la gestione dei turni usa per decidere quando il chiamante ha smesso di parlare. Un VAD scadente è uno dei killer silenziosi dell'IA vocale. Regolalo troppo stretto e tagli la parola al chiamante a metà. Regolalo troppo largo e l'agente sembra lento. Gli stack di livello produzione usano per questo una piccola rete neurale addestrata specificamente su audio di chiamate telefoniche, non una generica soglia di energia.
Non appena il VAD dice "questo è parlato", l'audio viene incanalato in un motore STT in streaming. La parola chiave è streaming. Lo STT non aspetta che il chiamante finisca. Emette trascrizioni parziali ogni ~50 ms: ipotesi incomplete che vengono riviste man mano che arriva altro audio. Quindi a 200 ms la trascrizione potrebbe dire "Salve vorrei prenotare una". A 400 ms, "Salve vorrei prenotare una pulizia per". A 700 ms, la frase completa. Lo STT moderno gestisce anche la diarizzazione (chi sta parlando, utile quando c'è più di una persona in linea), la correzione interinale (rivedere "due" in "due e trenta" una volta arrivato più contesto) e la robustezza al rumore per chi chiama in vivavoce o in aeroporto.
Se ti stai chiedendo dove la maggior parte dei progetti fatti in casa fallisce in silenzio, questo è uno di quei punti. L'accuratezza del riconoscimento va bene nel 2026. La parte difficile è lo streaming, le parziali e il rilevamento della fine dell'enunciato, nessuna delle quali ottieni da una generica API di tipo "trascrivi questo file audio".
Questa è l'arte oscura. La gestione dei turni è il modello che decide quando il chiamante ha terminato un pensiero, così l'agente può rispondere. Non si tratta solo di "aspettare 500 ms dopo l'ultima parola". Gli esseri umani fanno pause a metà frase, prendono fiato, dicono "ehm" mentre pensano. Un timeout ingenuo o li interrompe ("Salve, vorrei prenotare—" "OK, cosa vorrebbe prenotare?") o sembra lento ("...per martedì pomeriggio prossimo." [silenzio] [silenzio] "Capito, controllo subito.").
La risposta di produzione del 2026 è un piccolo e veloce modello neurale di gestione dei turni che prende il flusso audio, la trascrizione parziale e il contesto della conversazione e fornisce una probabilità che il chiamante abbia terminato il proprio turno. Si aggiorna decine di volte al secondo. Quando la confidenza supera una soglia, inizia il turno dell'agente. Il modello di gestione dei turni di Retell gestisce i backchannel ("mm-hmm", "certo"), le pause di esitazione e il rilevamento della fine dell'enunciato all'interno di un budget di risposta end-to-end di circa 600 ms. (Come funziona la nostra gestione dei turni.)
Se da questo articolo dovessi portarti via una cosa sola: la maggior parte della differenza tra "sembra umano" e "sembra robotico" vive in questo stadio. In termini di budget di latenza, la gestione dei turni divora 150-300 ms del tuo tempo di risposta totale. In termini di qualità, è il singolo fattore più importante per stabilire se i tuoi chiamanti rispetteranno l'agente.
Una volta terminato il turno del chiamante, il modello linguistico viene chiamato con tutto ciò di cui ha bisogno: il tuo system prompt, la trascrizione completa della conversazione, qualsiasi conoscenza recuperata dalla tua knowledge base e l'elenco delle funzioni disponibili. Il modello ha due scelte a ogni turno: generare una risposta parlata o chiamare uno strumento (prenotare l'appuntamento, trasferire la chiamata, cercare la scheda del cliente).
La metrica di latenza che conta qui è il time to first token (TTFT). Non quanto impiega la risposta completa, ma quanto ci vuole prima che la prima parola inizi a scorrere in streaming. Un buon LLM del 2026 raggiunge un TTFT di 150-300 ms per un tipico prompt di agente vocale. Una volta che i token iniziano a scorrere, continuano a farlo a 50-100 al secondo, più veloce di quanto parli la maggior parte delle persone. Così lo stadio TTS inizia prima che il modello abbia finito di pensare. (Dettagli sui prezzi per il tier LLM.)
Se il modello decide di chiamare una funzione invece di parlare, paghi una latenza diversa: il round-trip verso il tuo webhook (prenotare lo slot in Cal.com, scrivere il lead in Salesforce). Per la maggior parte delle funzioni preimpostate, questo è veloce: poche centinaia di millisecondi. Per le API di terze parti lente, può essere più lento, e l'agente di solito dice qualcosa come "un momento, controllo subito" per colmare il divario. (Prenotazione, trasferimento, knowledge base.)
Non appena l'LLM emette i primi token, parte il TTS. Gli agenti vocali moderni trasmettono in streaming l'audio in frammenti da 200-400 ms, così il chiamante sente la prima parola prima ancora che la risposta completa sia stata generata. Questo è il trucco che fa sembrare veloce l'intera pipeline: ogni stadio emette output prima che lo stadio precedente finisca.
Il menù vocale del 2026 ha tre tier: le voci della piattaforma Retell e Cartesia per voci veloci, naturali e a bassa latenza a $0,015/min; ElevenLabs per voci di brand della massima fedeltà a $0,040/min; e una lunga coda di cloni vocali per casi d'uso premium. Il time to first audio (TTFA) è la metrica da tenere d'occhio: gli stack di produzione raggiungono i 100-200 ms. In test alla cieca con voci predefinite, la maggior parte dei chiamanti non riesce a distinguerle in modo affidabile da quelle umane. Ciò che tradisce l'IA vocale nel 2026 non è più la voce. È il timing.
La pipeline descritta sopra funziona alla grande finché il chiamante non fa ciò che gli esseri umani fanno davvero: interrompere. Iniziano a parlare sopra l'agente. Magari si sono resi conto che intendevano mercoledì, non martedì. Magari sono irritati. In ogni caso, l'agente deve smettere di parlare immediatamente, scartare il resto della risposta pianificata e rimettersi in ascolto, in fretta.
Questa è la gestione del barge-in ed è un altro killer silenzioso dell'IA vocale. Un progetto ingenuo continua a leggere il resto del TTS mentre il chiamante parla: la sensazione peggiore in una telefonata. Un buon progetto interrompe il TTS entro un singolo frammento audio (sotto i 100 ms), scarta qualunque cosa l'LLM stesse per dire e avvia un nuovo stream STT dal nuovo audio del chiamante. Punti bonus se il modello sa cosa è stato detto prima dell'interruzione, così da non ripetersi.
Somma il budget: rete (50 ms) + VAD/gestione dei turni (200 ms) + TTFT dell'LLM (250 ms) + TTFA del TTS (100 ms) = circa 600 ms. È così che un agente vocale sembra umano. Nessuno di quei numeri è magico. Sono semplicemente il risultato di uno streaming aggressivo e del non aspettare nulla che non sia necessario aspettare.
Tre aziende che operano oggi esattamente su questa pipeline, che vale la pena studiare.
Pine Park Health. Assistenza sanitaria di base per comunità di anziani. Il rimpallo delle telefonate divorava la loro agenda. Hanno messo un agente vocale Retell davanti alla loro linea di prenotazione: la stessa pipeline STT → LLM → TTS di tutti gli altri, solo orchestrata in modo abbastanza rigoroso da non far riagganciare i chiamanti. L'NPS delle prenotazioni è salito del 38%. Il loro personale clinico ha smesso di passare metà giornata al telefono.
SWTCH. Azienda di ricarica per veicoli elettrici. Quando un automobilista è bloccato a una colonnina guasta, "la richiamiamo domani" non è una risposta. Hanno messo in linea Lucas, un agente Retell. Lucas risponde in pochi secondi, guida gli automobilisti attraverso la risoluzione urgente dei problemi, e lo fa 24 ore su 24, 7 giorni su 7 sulla stessa pipeline a sette stadi. I costi di supporto sono calati di oltre il 50%.
Medical Data Systems. Recupero crediti. Regolamentato, tonalmente delicato, implacabile quando le conversazioni prendono una brutta piega. Hanno messo agenti Retell sulle chiamate inbound e ora gestiscono il 100% del volume in entrata, con solo il 30% delle chiamate trasferite a un umano, incassando circa $280.000 al mese. La pipeline è la stessa che abbiamo appena percorso. La differenza è la disciplina nell'orchestrazione e una lunga coda di piccole decisioni sulla gestione dei turni, sul barge-in e sul design del prompt. (Altre storie dei clienti qui.)
Il filo conduttore di tutti e tre: nessuno di loro ha cercato di inventare la pipeline. Hanno scelto una piattaforma che aveva risolto l'orchestrazione, hanno concentrato il proprio lavoro sulle parti effettivamente proprietarie della loro azienda — il prompt, la knowledge base, gli endpoint delle funzioni — e sono andati in produzione.
Se di questo articolo non ricordi nient'altro, ricorda questo: STT e TTS non sono i punti in cui si nasconde la maggior parte della tua latenza. Sono veloci. I due punti in cui la latenza va davvero sono la gestione dei turni e il time-to-first-token dell'LLM.
Ecco una tipica ripartizione del budget del 2026 per un turno di conversazione su uno stack di produzione:
Round-trip di rete: 30-80 ms. Perlopiù geografia e il tuo operatore SIP. Qui non puoi fare granché.
Decisione VAD + gestione dei turni: 150-300 ms. Questa è la variabile più grande. Un modello di gestione dei turni scadente ti costerà oltre 500 ms di latenza percepita senza mai comparire in un benchmark.
Trascrizione finale STT: 50-100 ms dopo la fine del parlato. Lo streaming nasconde la maggior parte di questo nello stadio precedente.
Time-to-first-token dell'LLM: 150-400 ms. Dipende fortemente dalla scelta del modello e dalla dimensione del prompt.
Time-to-first-audio del TTS: 100-200 ms.
Chiamata a funzione (se invocata): 100-500 ms a seconda dell'API.
Uno stack di livello produzione porta a termine le parti parla-o-non-parlare di tutto ciò in circa 600 ms totali. Uno stack mediocre si assesta a 1,2-1,8 secondi. Lo stack mediocre dà la sensazione di parlare con un chatbot che legge battute. Quello buono dà la sensazione di una persona.
Le due grandi leve se stai cercando di ottimizzare: scegli un LLM veloce con basso TTFT (GPT 4.1, Claude 4.6 Sonnet, Gemini 3.0 Flash raggiungono tutti gli obiettivi di produzione) e usa un modello di gestione dei turni addestrato su dati di conversazione reali, non una soglia di silenzio fissa. (Perché la latenza conta)
Vale la pena segnalare alcune cose.
"Sono solo tre API incollate insieme." Lo sono, finché non provi a farle sembrare in tempo reale. Allora ti rendi conto che l'incollaggio conta più delle API. Il livello di orchestrazione — messa a punto del VAD, modello di gestione dei turni, coordinamento dello streaming, gestione del barge-in, instradamento delle chiamate a funzione — è dove vivono davvero gli stack di livello produzione. Puoi cambiare fornitore di STT in un giorno. Non puoi cambiare l'orchestrazione senza riscrivere metà del sistema.
"LLM più grande = agente vocale migliore." Non proprio. Per la maggior parte dei casi d'uso vocali, un veloce modello di fascia media con un buon prompt batte un lento modello di punta. Il time-to-first-token conta più della pura qualità di ragionamento, perché la percezione del chiamante è plasmata quasi interamente dalla latenza. Retell ti permette di cambiare LLM con un menù a discesa proprio perché la risposta giusta dipende dal caso d'uso: per il ragionamento pesante c'è Claude 4.6 Sonnet, per l'alto volume a basso costo GPT 5 nano, per il multilingua Gemini 3.0 Flash, e il valore predefinito è GPT 4.1.
"Lo streaming è un optional." È l'intera architettura. Senza streaming, aspetti che il chiamante finisca, poi aspetti che finisca lo STT, poi aspetti che finisca l'LLM, poi aspetti che finisca il TTS, e hai speso oltre 3 secondi prima che un solo byte di audio torni indietro. L'intero motivo per cui gli agenti vocali del 2026 sembrano umani è che ogni stadio inizia a emettere output prima che lo stadio precedente sia finito.
"Serve un modello addestrato su misura per far funzionare tutto questo per il tuo caso d'uso." Quasi sempre no. Lo stack del 2026 è progettato in modo che il modello resti generico e siano il tuo prompt + la knowledge base + le funzioni a fare la personalizzazione. I modelli addestrati su misura sono più lenti da iterare, più lenti in inferenza e obsoleti nel momento in cui esce un nuovo modello base. La maggior parte dei team che "avevano bisogno di un modello personalizzato" avevano in realtà bisogno di un prompt migliore e di una knowledge base migliore.
"La voce è la parte più difficile." In realtà è una delle parti più facili ormai. Le voci TTS predefinite sono di fatto indistinguibili da quelle umane nei test alla cieca. Le parti più difficili sono la gestione dei turni e il barge-in: le cose che i chiamanti non notano consapevolmente ma percepiscono assolutamente.
L'IA vocale in tempo reale è una pipeline in streaming: audio in ingresso → STT → LLM → TTS → audio in uscita, con la gestione dei turni e il barge-in che la avvolgono. Ogni stadio emette output prima che lo stadio precedente finisca, l'intero ciclo si completa in meno di 700 ms e l'orchestrazione è ciò che separa la produzione dalla demo. Questa è l'architettura. Non è magia. Sono alcuni specifici problemi ingegneristici risolti bene.
La maggior parte degli operatori non ha bisogno di costruirla da sola. Ha bisogno di capirla abbastanza bene da sapere cosa sta acquistando, cosa chiedere e dove il progetto fallirà se sceglie il fornitore sbagliato. Se questo articolo ti ha portato quasi al traguardo, sei in buona forma.
Se vuoi vedere la pipeline in azione, il percorso più rapido è costruire qualcosa su di essa. Registrati gratuitamente su dashboard.retellai.com: i nuovi account ricevono $10 di credito, circa 90 minuti di conversazione. Oppure prenota una demo e ti guideremo attraverso l'orchestrazione nel contesto del tuo volume di chiamate effettivo. Se preferisci sentire la latenza di persona, chiama la nostra linea demo dal vivo e parla con un agente in esecuzione sulla pipeline descritta sopra.
D: Cosa significa davvero STT → LLM → TTS? R: Sono i tre stadi centrali di una pipeline di IA vocale. Lo STT (speech-to-text) trasforma l'audio del chiamante in testo. L'LLM (large language model) legge quel testo più il tuo system prompt e decide cosa dire o quale funzione chiamare. Il TTS (text-to-speech) riconverte la risposta in audio. Avvolgi attorno la gestione dei turni e del barge-in ed è tutto lo stack.
D: Quanto veloce deve essere l'IA vocale in tempo reale? R: Un tempo di risposta end-to-end sotto i ~700 ms è la soglia in cui la conversazione sembra umana. Oltre, i chiamanti iniziano a interrompere, a ripetersi e a riagganciare. Gli stack di produzione come Retell girano intorno ai 600 ms.
D: Dove va davvero la latenza? R: Perlopiù nella gestione dei turni e nel time-to-first-token dell'LLM, non nello STT o nel TTS. Un budget tipico: rete 50 ms, VAD/gestione dei turni 200 ms, TTFT dell'LLM 250 ms, primo audio del TTS 100 ms. Lo STT gira in parallelo al parlato del chiamante, quindi aggiunge quasi nulla in più.
D: Cos'è lo streaming e perché conta? R: Ogni stadio della pipeline emette output prima che lo stadio precedente finisca. Lo STT emette trascrizioni parziali ogni ~50 ms. L'LLM trasmette in streaming i token man mano che li genera. Il TTS trasmette l'audio in streaming in frammenti da 200-400 ms. Senza streaming, ogni stadio aspetta il precedente e spendi oltre 3 secondi prima che un solo byte di audio torni al chiamante.
D: Cos'è la gestione dei turni e perché è difficile? R: La gestione dei turni è il sistema che decide quando il chiamante ha finito di parlare, così l'agente può rispondere. È difficile perché gli esseri umani fanno pause a metà frase, prendono fiato e dicono "ehm" mentre pensano. Un timeout ingenuo taglia la parola ai chiamanti o sembra lento. La risposta del 2026 è un piccolo modello neurale addestrato su audio conversazionale reale che aggiorna una probabilità decine di volte al secondo.
D: Cos'è la gestione del barge-in? R: È ciò che accade quando il chiamante inizia a parlare sopra l'agente. Un buon stack ferma il TTS entro 100 ms, scarta il resto della risposta pianificata e avvia un nuovo stream STT dal nuovo audio del chiamante. Uno stack scadente continua a parlare: la sensazione peggiore in una telefonata.
D: Devo costruire io stesso la pipeline? R: Quasi mai nel 2026. L'orchestrazione — VAD, gestione dei turni, barge-in, coordinamento dello streaming, instradamento delle chiamate a funzione — è la parte in cui va il serio investimento ingegneristico. La maggior parte dei team che prova a costruirla da sola finisce con una versione più lenta e peggiore di ciò che è disponibile pronto all'uso. Costruisci le parti proprietarie della tua azienda: prompt, knowledge base, endpoint delle funzioni, workflow.
D: La scelta dell'LLM conta così tanto? R: Sì, ma perlopiù per il time-to-first-token, non per la pura qualità. Un veloce modello di fascia media con un buon prompt batte un lento modello di punta per la maggior parte dei casi d'uso vocali. Retell ti permette di cambiare LLM con un menù a discesa: GPT 4.1 è il valore predefinito, Claude 4.6 Sonnet per un ragionamento più elevato, GPT 5 nano per il volume a basso costo, Gemini 3.0 Flash per il multilingua. (Prezzi.)
D: Come si inserisce la chiamata a funzione nella pipeline? R: Quando l'LLM decide di chiamare una funzione invece di parlare, la piattaforma invia un webhook HTTPS con argomenti strutturati che il modello ha estratto dalla conversazione, poi attende la risposta. Quel round-trip aggiunge latenza: di solito qualche centinaio di millisecondi per le API veloci, di più per quelle lente. Per attese più lunghe, l'agente di solito dice "un momento, controllo subito" per colmare il divario.
D: Qual è la differenza tra IA vocale e un IVR? R: Un IVR è un albero decisionale fisso (prema 1 per la fatturazione). L'IA vocale gira sulla pipeline descritta sopra: parlato libero in ingresso, ragionamento dell'LLM nel mezzo, risposta naturale in uscita. I chiamanti non navigano menù. Parlano e basta.
See how much your business could save by switching to AI-powered voice agents.
Total Human Agent Cost
AI Agent Cost
Estimated Savings
Un numero di telefono demo di Retell Clinic Office
Start building smarter conversations today.
.avif)
.avif)
