Ridurre la latenza negli agenti vocali conversazionali AI: un approccio dinamico
"Pronto? Mi sente?" È quello che dicono gli utenti quando il tuo agente vocale AI arriva a 1,5 secondi di silenzio. Non perché il modello abbia fallito, ma perché nessuno ha progettato il flusso intorno all’attesa. Questo articolo analizza da dove arriva davvero la latenza, perché l’LLM ne è responsabile fino all’80% e come i filler contestuali dinamici cambiano l’esperienza senza toccare la velocità del modello.
Sommario
La latenza end-to-end negli agenti vocali AI è comunemente inquadrata come un problema di ottimizzazione delle prestazioni. Sosteniamo che sia meglio intenderla come due problemi distinti: latenza effettiva — il ritardo misurabile tra la fine del turno dell'utente e l'inizio della risposta dell'agente — e latenza percepita — il peso psicologico di quel ritardo per l'utente.
Ottimizzare solo per la latenza effettiva è necessario ma insufficiente. In questo post analizziamo lo stack di latenza di una pipeline di agente vocale in produzione, individuiamo nell'LLM il collo di bottiglia dominante (60–80% del ritardo totale su prompt complessi), esaminiamo le pratiche di mitigazione consolidate e descriviamo una tecnica proprietaria che abbiamo sviluppato in callin.io: generazione dinamica di filler contestuali tramite un sub-prompt parallelo, che riduce sistematicamente la latenza percepita indipendentemente dalla velocità del modello sottostante.
1. Introduzione
C'è un momento preciso in cui una conversazione telefonica con un agente AI smette di sembrare intelligente e inizia a sembrare rotta. Non è quando l'agente produce una risposta errata. Accade molto prima: durante quell'istante e mezzo di silenzio completo dopo che l'utente ha finito di parlare.
La linea resta muta. L'utente aspetta. Poi arriva la domanda inevitabile: "Pronto? C'è qualcuno?"
A quel punto, la conversazione è già compromessa. Anche se la risposta successiva fosse perfetta — accurata, pertinente, ben formulata — il danno è fatto. L'utente è uscito dal flusso conversazionale. Ha smesso di parlare con l'agente e ha iniziato a parlare contro di esso. La distinzione è sottile ma decisiva: è la differenza tra una chiamata che converte e una che termina in anticipo.
Questo degrado è causato dalla latenza. E, in termini pratici, è la principale modalità di fallimento degli agenti vocali distribuiti — più comune e più dannosa delle risposte errate, perché si verifica in ogni singola chiamata, indipendentemente dalla qualità del modello.
2. Scomporre lo Stack di Latenza
Per ragionare sulle soluzioni, dobbiamo prima avere un modello preciso di dove origina la latenza. Una pipeline di agente vocale non è una singola operazione — è una catena sequenziale di processi, ciascuno dei quali contribuisce con il proprio ritardo. La Figura 1 presenta un budget di latenza realistico per una distribuzione in produzione, misurato dal momento in cui l'utente smette di parlare al momento in cui ascolta la prima uscita audio dell'agente.
Figura 1. Budget di latenza per una pipeline di agente vocale STT→LLM→TTS in produzione. Gli intervalli riflettono implementazioni tipiche; prompt lunghi o intensivi sul ragionamento spingono il contributo dell'LLM verso il limite superiore.
Le soglie percettive sono ben consolidate nella letteratura sull'AI conversazionale e in larga misura coerenti con la ricerca UX sulla telefonia: ritardi inferiori a 500 ms risultano naturali; tra 500 ms e 1 secondo sono accettabili; oltre 1 secondo, gli utenti iniziano a percepire un malfunzionamento del sistema. Oltre i 2 secondi, la percezione di un guasto è quasi universale.
L'analisi ingegneristica di Twilio sull'architettura degli agenti vocali conferma la natura sequenziale della pipeline: ogni componente attende il completamento del precedente. I ritardi si accumulano — non si compensano a vicenda.
La distribuzione di quel ritardo accumulato è l'osservazione chiave. STT e TTS insieme raramente superano il 25–30% della latenza totale della pipeline. Il contributore dominante, in modo costante e con ampio margine, è la fase di inferenza dell'LLM.
3. Perché l'LLM Domina la Latenza
Un modello linguistico non produce output istantaneamente quando riceve un prompt. Il processo di inferenza coinvolge tre fasi sequenziali:
Tokenizzazione. Il testo in input — enunciato dell'utente, system prompt, cronologia della conversazione, eventuale contesto recuperato — viene convertito in una sequenza di token. Dal punto di vista computazionale è poco costosa, ma non è gratuita.
Prefill (elaborazione del contesto). Il modello elabora l'intero contesto di input per costruire la propria cache key-value (KV), da cui inizia la generazione autoregressiva. È qui che la lunghezza del prompt ha il suo impatto più significativo sulla latenza. Man mano che una conversazione progredisce e la finestra di contesto cresce, aumenta di conseguenza anche il tempo di prefill. Una conversazione di 10 turni porta con sé un contesto circa 5–8× più grande di uno scambio a 2 turni. Il modello deve rielaborare questo contesto completo a ogni nuovo turno.
Decodifica autoregressiva. Il modello genera i token di output uno alla volta, ognuno dei quali richiede un passaggio completo in avanti attraverso la rete. Questa fase è vincolata dal throughput dell'hardware (token/secondo) piuttosto che dalla lunghezza del prompt.
La metrica chiave per l'ottimizzazione degli agenti vocali è TTFT — Time to First Token: l'intervallo tra l'invio del prompt e la ricezione del primo token di output. Per un agente vocale, il budget pratico di TTFT è di circa 400 ms — il tempo che l'LLM può consumare prima che l'intera pipeline superi le soglie di tolleranza dell'utente, assumendo STT ottimizzato (~200 ms) e TTS (~150 ms con streaming).
La sfida è che molti modelli capaci — quelli che gestiscono in modo affidabile il tool calling, mantengono coerenza su più turni e performano bene nei compiti di ragionamento — superano regolarmente i 600 ms di TTFT, soprattutto su prompt lunghi o più complessi. Questo divario tra il budget di TTFT e il comportamento reale del modello è oggi il problema centrale di latenza negli agenti vocali in produzione.
4. Benchmarking della Velocità degli LLM: Risorse di Riferimento
Selezionare un modello per una distribuzione voice-first richiede l'accesso a dati di latenza affidabili e continuamente aggiornati. Le seguenti risorse sono tra le più utili a questo scopo:
Artificial Analysis — Il benchmark indipendente più citato nel settore. Traccia TTFT, token al secondo, latenza end-to-end e qualità dell'output su tutti i principali provider e modelli. Aggiornato continuamente. Essenziale per chiunque costruisca sistemi vocali in produzione.
BenchLM.ai — Classifica di velocità degli LLM — Classifica i modelli in base alla velocità di generazione (token/secondo) e al TTFT. Copre le uscite più recenti con dati attuali a livello di provider.
AIMultiple — Benchmark di latenza degli LLM — Analisi comparativa tra categorie di casi d'uso (Q&A, riassunto, ragionamento). Utile per capire come la latenza vari in funzione del tipo di attività, non solo dell'architettura del modello.
Hamming AI — Guida alla latenza della Voice AI — Una risorsa orientata ai practitioner, specifica per le distribuzioni di agenti vocali, con raccomandazioni di selezione dei modelli indicizzate per caso d'uso e requisiti di latenza.
Tra i modelli che performano in modo costante per applicazioni voice-first, i benchmark attuali indicano:
Gemini 2.5 Flash — Ottimo equilibrio tra TTFT basso, alta qualità dell'output e comportamento affidabile nel tool calling. Ampiamente distribuito in agenti conversazionali in produzione.
GPT-4o mini — TTFT basso e costo competitivo; adatto a fasi conversazionali semplici in cui non è richiesta profondità di ragionamento.
Grok 4.1 Fast — Elevato numero di token al secondo dopo l'avvio della generazione; favorevole per risposte più lunghe in cui il throughput di generazione conta più della latenza iniziale.
Qwen (varie versioni) — Modelli open-weight con profili di latenza competitivi; ben adatti a implementazioni self-hosted, dove il controllo dell'infrastruttura riduce l'overhead di rete.
Mistral Large — Tra i modelli di fascia alta, uno dei più costanti nel garantire TTFT sub-secondo su diverse lunghezze di prompt.
Sapere quali modelli sono più veloci, tuttavia, risolve solo metà del problema.
5. Pratiche Standard di Mitigazione
Prima di descrivere il nostro approccio, è utile riassumere le pratiche ingegneristiche che rappresentano lo stato dell'arte attuale per la riduzione della latenza effettiva. Sono ben comprese e ampiamente applicabili.
Streaming dei token end-to-end. L'LLM dovrebbe iniziare a inoltrare i token di output al livello di sintesi TTS man mano che vengono generati, invece di attendere la generazione completa della risposta. Con lo streaming, il TTS inizia a sintetizzare i primi token mentre l'LLM sta ancora generando il resto. Questa parallelizzazione riduce in modo significativo la latenza percepita. Come afferma la documentazione ingegneristica di Twilio, l'assenza di supporto allo streaming in un'API LLM è un motivo immediato di esclusione per le applicazioni vocali.
Disciplina della finestra di contesto. Ogni token nel prompt comporta un costo di prefill. System prompt prolissi, cronologie conversazionali non potate e contesti recuperati strutturati in modo inefficiente aumentano tutti il TTFT. I prompt vocali in produzione dovrebbero essere compatti e strutturalmente puliti, senza sacrificare le informazioni necessarie al modello per mantenere la coerenza conversazionale.
Rilevamento preciso della fine turno. Ogni millisecondo aggiuntivo che il livello VAD impiega per confermare che l'utente ha smesso di parlare contribuisce alla latenza percepita dal punto di vista dell'utente. Un VAD ben calibrato riduce il tempo morto iniziale senza troncare prematuramente gli enunciati dell'utente — un equilibrio che richiede una taratura empirica per ogni distribuzione.
Tiering del modello per fase conversazionale. Non ogni fase di una conversazione richiede il modello più capace disponibile. Saluti, conferme e semplici richieste di chiarimento impongono esigenze minime di ragionamento. Distribuire un modello leggero e veloce per queste fasi e riservare modelli di maggiore capacità ai compiti di ragionamento complesso o di tool calling riduce il TTFT medio sull'intera chiamata. Questo è il principio alla base della nostra architettura LLM Switcher, discussa in un articolo precedente.
Prossimità geografica dell'infrastruttura. Il tempo di andata e ritorno di rete tra il dispositivo dell'utente e l'host di inferenza si accumula in ogni turno della conversazione. Le distribuzioni localizzate per regione riducono strutturalmente questo overhead.
Queste pratiche affrontano collettivamente la latenza effettiva — millisecondi misurabili rimossi dalla pipeline. Tuttavia, non affrontano la latenza percepita quando la latenza effettiva non può essere ridotta sotto una certa soglia. È qui che si trova l'opportunità più significativa.
6. La Distinzione tra Latenza Effettiva e Percepita
La distinzione tra latenza effettiva e percepita è sottovalutata nella letteratura sugli agenti vocali e in larga parte assente nelle guide ingegneristiche standard.
Latenza effettiva è l'intervallo misurabile tra la fine del turno dell'utente e l'inizio della risposta dell'agente. Latenza percepita è il peso psicologico di quell'intervallo — quanto degrada l'esperienza della conversazione per l'utente.
Queste due quantità sono correlate ma non equivalenti. E la relazione non è lineare.
Una persona che chiama un call center umano non si aspetta una risposta istantanea. Capisce che l'operatore deve pensare, cercare qualcosa, ragionare sulla situazione. Ciò che non tollera è il silenzio. Il silenzio è assenza. Il silenzio è la sensazione che il sistema abbia fallito.
Gli operatori umani gestiscono questa situazione attraverso ciò che la linguistica chiama filler — elementi conversazionali che mantengono il filo interazionale mentre la cognizione procede: "Lasci che controlli...", "Allora...", "Un momento, sto guardando il suo account..." Queste frasi non portano contenuto proposizionale. La loro funzione è interamente pragmatica: segnalano che l'elaborazione è in corso, che l'interlocutore è presente, che una risposta sta arrivando.
Un agente vocale AI ingenuo ha due opzioni quando l'inferenza dell'LLM richiede più tempo della soglia percettiva: rispondere immediatamente (non possibile se il modello è lento) oppure rimanere in silenzio (cosa che innesca la cascata di fallimento descritta nell'introduzione). Nessuna delle due è soddisfacente.
La soluzione di mercato più comune è l'audio filler statico: clip preregistrate riprodotte automaticamente dopo un timeout di silenzio configurabile. Un segmento audio fisso "Un momento, per favore...", identico a ogni invocazione, indipendente dal contesto.
Questo approccio offre un miglioramento marginale rispetto al silenzio, ma introduce a sua volta dei problemi. È immediatamente riconoscibile come meccanico — gli utenti percepiscono la ripetizione. Più importante ancora, è scollegato dal contesto: un rapido "Certo, un momento!" riprodotto in risposta a un reclamo emotivamente carico produce una dissonanza che finisce per amplificare, e non mitigare, la frustrazione dell'utente.
7. Filler Dinamici Contestuali: Il Nostro Approccio
In callin.io abbiamo sviluppato una tecnica che affronta la latenza percepita attraverso un meccanismo diverso: generazione dinamica di filler consapevole del contesto tramite un sub-prompt parallelo dedicato.
L'architettura è la seguente. Quando la pipeline di inferenza principale riceve un input il cui TTFT stimato supera una soglia (fissata empiricamente intorno a 600 ms nella nostra attuale distribuzione), viene immediatamente inviato un secondo prompt indipendente a un modello leggero e veloce. Questo sub-prompt ha un unico obiettivo ristretto: generare una frase ponte che sia (a) semanticamente coerente con l'enunciato più recente dell'utente, (b) tonalmente appropriata al registro emotivo dello scambio e (c) strutturata per collegarsi in modo naturale alla risposta completa imminente.
Il sub-prompt non ragiona sulla risposta completa. Non consulta sistemi esterni. Risponde a una sola domanda: "Dato l'ultimo enunciato dell'utente e il contesto conversazionale attuale, cosa direbbe un operatore umano esperto mentre prende tempo per riflettere?"
La pipeline della risposta completa e quella della generazione del filler procedono in parallelo. Il filler arriva per primo — in genere entro 150–250 ms — viene riprodotto all'utente e la risposta principale segue subito dopo, collegata linguisticamente.
Il risultato differisce in modo fondamentale da un filler statico.
7.1 Esempio: Richiesta sulla Disponibilità di un Prodotto
Utente: "Vorrei sapere se avete ancora disponibile il modello Pro 4K per la consegna entro questa settimana — mi serve per un evento sabato."
Situazione: L'agente deve interrogare il database prodotti tramite MCP, verificare la disponibilità di magazzino e la spedizione rapida. TTFT stimato del modello principale: 900 ms.
Risposta con filler statico:
"Un momento, per favore..." [800 ms di silenzio] "Sì, il Pro 4K è disponibile e..."
Filler dinamico (callin.io):
"Capito — con l'evento di sabato, qui conta soprattutto il tempismo. Controllo subito disponibilità e opzioni di consegna rapida..." [la risposta principale continua] "...il modello è disponibile in magazzino e possiamo garantire la consegna venerdì se ordini entro le 15 di oggi."
La frase ponte codifica il vincolo specifico (l'evento di sabato), contestualizza il ritardo di elaborazione come un'azione intenzionale e passa senza soluzione di continuità alla risposta completa. L'esperienza dell'utente è quella di un agente che ha compreso l'urgenza e si è attivato di conseguenza.
7.2 Esempio: Reclamo a Forte Carica Emotiva
Utente: "È la terza volta che chiamo per lo stesso problema. Ogni volta mi dite che è risolto e poi ricomincia. Sono davvero stanco di tutto questo."
Situazione: L'agente deve recuperare la cronologia completa del cliente e la catena dei ticket precedenti. TTFT stimato: 800 ms.
Risposta con filler statico:
"Mi dispiace per l'inconveniente, un momento..." [700 ms di silenzio] "Ho qui il suo profilo..."
Filler dinamico (callin.io):
"Tre chiamate per lo stesso problema — non dovrebbe succedere, e capisco perfettamente la frustrazione. Sto aprendo adesso tutta la cronologia del caso..." [la risposta principale continua] "...vedo tutti e tre i contatti. Ha ragione — il problema non era mai stato chiuso correttamente da parte nostra."
La frase di filler si allinea al registro emotivo del reclamo, riconosce il fallimento specifico (tre contatti) e trasforma l'intervallo di elaborazione in un momento di recupero attivo, invece che in una pausa di sistema.
7.3 Esempio: Query Tecnica Complessa
Utente: "Se integro il vostro sistema con il mio CRM Salesforce tramite API, posso attivare chiamate outbound automatiche in base agli eventi di lead scoring?"
Situazione: Domanda tecnica multilivello che richiede ragionamento strutturato. TTFT stimato (Claude): 1.200 ms.
Risposta con filler statico:
"Ottima domanda, un attimo..." [1.100 ms di silenzio] "Sì, è possibile..."
Filler dinamico (callin.io):
"Sì, l'integrazione con Salesforce e i trigger di lead scoring è in realtà uno dei casi d'uso più interessanti — lasci che le spieghi come funziona nel dettaglio..." [la risposta principale continua] "...l'approccio più pulito è usare Salesforce Flow per inviare un webhook al nostro endpoint inbound quando un lead supera la soglia di scoring..."
L'utente riceve conferma immediata che la domanda è stata compresa e che si sta costruendo una risposta dettagliata — non che il sistema stia elaborando o caricando qualcosa.
8. L'Effetto Cascata: Perché il Tempo Morto si Somma
C'è una dinamica familiare a chiunque abbia gestito operazioni di contact center su larga scala: le conversazioni hanno un ritmo, e quando quel ritmo si rompe, il recupero diventa in modo sproporzionato difficile.
Il tempo morto oltre la soglia percettiva non produce semplicemente un disagio momentaneo. Innesca una cascata che degrada ogni scambio successivo:
L'utente mette in dubbio il funzionamento del sistema → la fiducia si erode
L'utente rompe il flusso conversazionale naturale → inizia a porre domande sullo stato del sistema ("Mi sente?")
L'agente risponde alla meta-domanda invece che alla richiesta originale → perde il filo conversazionale
L'utente, già scettico, applica un livello di scrutinio più alto alle risposte successive
La chiamata termina in anticipo, prima di raggiungere i risultati desiderati
Un filler dinamico contestualmente appropriato interrompe questa cascata al primo passo. Non ingannando l'utente — che sa che l'elaborazione è in corso — ma trasformando l'intervallo di attesa da una pausa di sistema in un beat conversazionale riconosciuto. La differenza tra "Pronto? C'è qualcuno?" e "Capisco — mi dia solo un secondo..." dipende interamente da ciò che riempie il vuoto.
9. Un Quadro Unificato: Latenza Effettiva e Percepita Insieme
I sistemi vocali in produzione che funzionano bene in condizioni reali affrontano entrambe le dimensioni simultaneamente.
Livello 1 — Riduzione della latenza effettiva:
Selezione del modello indicizzata ai benchmark TTFT (Artificial Analysis, BenchLM) per ogni fase conversazionale
Streaming nativo dei token da LLM a TTS senza buffering intermedio
Disciplina nell'engineering del prompt: contesto snello, cronologia conversazionale strutturata, iniezione efficiente del retrieval RAG/MCP
Taratura del VAD per un rilevamento della fine turno accurato e a bassa latenza
Distribuzione dell'infrastruttura localizzata per regione
Tiering del modello appropriato alla fase tramite LLM Switcher
Livello 2 — Riduzione della latenza percepita:
Generazione dinamica di filler consapevole del contesto tramite sub-prompt parallelo
Calibrazione tonale del filler in base al registro emotivo e informativo dell'input
Attacco linguistico fluido tra filler e risposta principale
Eliminazione degli eventi di silenzio oltre la soglia percettiva, indipendentemente dal TTFT del modello principale
L'effetto combinato è un sistema che, anche quando il modello principale impiega 1–1,5 secondi per generare una risposta completa, non smette mai di proiettare presenza, attenzione e controllo del filo conversazionale.
10. Perché Conta Oltre l'Ingegneria
La latenza non è, in ultima analisi, un problema tecnico. È un problema di conversione.
Un agente vocale che mantiene la latenza percepita sotto i 500 ms chiude più chiamate, genera maggiore fiducia nell'utente e produce tassi di abbandono in corso di chiamata più bassi. Un agente che soffre di tempo morto produce l'effetto opposto — anche quando le sue risposte sono sostanzialmente corrette.
In callin.io strumentiamo entrambe le dimensioni: la latenza effettiva a livello di componente lungo l'intera pipeline e il tasso di silenzio — la proporzione di tempo conversazionale durante il quale l'utente percepisce silenzio oltre la soglia percettiva. Nei nostri dati di produzione, il tasso di silenzio è la metrica che correla più direttamente con i tassi di completamento delle chiamate e con gli esiti di conversione.
Ridurre il tasso di silenzio non è un vezzo di UX. È un impegno progettuale fondamentale: che il sistema rispetti il contratto conversazionale di una chiamata telefonica. Le persone non chiamano per interagire con una pipeline. Chiamano per parlare con qualcosa che si comporti come se capisse che, in una chiamata telefonica, il silenzio pesa più delle parole.
Riferimenti e Ulteriori Letture
Twilio Engineering: Latenza di base negli agenti vocali AI
Hamming AI: Latenza della Voice AI — cosa è veloce, cosa è lento e come risolverlo
Softcery: Come scegliere un LLM per gli agenti vocali: velocità, accuratezza, costo
Artificial Analysis: Classifica di velocità e latenza degli LLM
BenchLM: Confronto di velocità degli LLM
AIMultiple: Benchmark della latenza degli LLM per caso d'uso
NVIDIA Technical Blog: Benchmarking dell'inferenza LLM: concetti fondamentali
callin.io è una piattaforma di agenti vocali AI costruita per le aziende che non possono permettersi di sbagliare. Se desideri valutare il profilo di latenza del tuo agente attuale o esplorare come la generazione dinamica di filler influisca sui tassi di completamento delle chiamate, contattaci.
