Voce in tempo reale vs. batch — un agente AI telefonico non è un chatbot

Quando un fornitore ti propone un "agente AI telefonico", poni una sola domanda: "Qual è la vostra latenza end-to-end tra la fine del parlato dell'utente e l'inizio della risposta?"

Se la risposta supera gli 1,5 secondi, non è un agente telefonico. È un chatbot con un modulo ASR / TTS incollato davanti.

La regola degli 800 ms

Al telefono, una persona tollera il silenzio dopo la propria domanda. Ma quel silenzio ha una soglia: oltre gli 800 ms, l'interlocutore percepisce l'altro capo come "bloccato". A 1.500 ms, chi chiama dice "pronto?". A 3.000 ms, riaggancia dando per scontato un problema di linea.

L'obiettivo per un agente vocale serio è quindi: meno di 800 ms tra la fine del parlato e il primo byte udibile della risposta.

Scomponiamolo.

Il budget temporale nel dettaglio

[user speech]──▶[ASR streaming]──▶[LLM]──▶[TTS streaming]──▶[audio out]
      ~150ms          ~80ms        ~?       ~250ms             ~50ms

Degli ~800 ms disponibili, circa 270 ms sono consumati da ASR + TTS + trasporto. Restano 530 ms per l'LLM — inclusi il tempo di prefill, il ragionamento e la generazione del primo token.

Implicazioni:

• GPT-4 Turbo non-streaming: ~2.000 ms per generare una risposta da 200 token. Fuori discussione.
• GPT-4o streaming: ~400 ms al primo token nei giorni buoni, ~800 ms in quelli cattivi. Accettabile ma tirato.
• Claude Haiku streaming: ~250 ms al primo token. Comodo.
• Llama 3 8B servito da vLLM: ~150 ms al primo token. Eccellente (e privato).

Un'architettura vocale seria richiede quindi:

1. Tutto è in streaming — ASR, LLM, TTS. Nemmeno un anello in modalità batch.
2. Il modello LLM è scelto per il TTFT (time to first token), non per il punteggio MMLU.
3. Il TTS inizia a parlare al primo token ricevuto, non dopo che la risposta completa è pronta.

Barge-in

Su un canale testuale, l'utente aspetta che il bot finisca. Al telefono, interrompe. Tre volte su cinque, nelle conversazioni naturali.

Un agente vocale che non sa gestire di essere interrotto risulta "robotico" — continua a parlare mentre l'utente cerca di interromperlo. È intollerabile e segnala immediatamente un bot costruito male.

Il barge-in tecnico richiede:

• Il TTS si ferma immediatamente non appena l'ASR rileva un segnale vocale in uscita dall'utente.
• L'LLM scarta la completion in corso (senza fare storie).
• Il buffer audio in uscita viene svuotato all'istante (altrimenti si sente una mezza sillaba residua).
• La cronologia della conversazione annota che la risposta non è stata ascoltata per intero — per evitare di ripeterla inavvertitamente.

È un dettaglio tecnico che cambia tutto nel modo in cui l'interazione viene percepita.

Gestire l'incertezza

Al telefono, l'ASR commette errori regolarmente. Mentre un chatbot testuale riceve sempre il testo esatto digitato dall'utente, l'agente vocale riceve una trascrizione spesso imperfetta.

Strategie che funzionano:

• Chiedere conferma sugli elementi ad alto impatto (numero di pratica, importo, cognome insolito). Non in modo sistematico — diventa insopportabile.
• Non fidarsi ciecamente dell'LLM quando l'ASR è ambiguo. Se la frase ricevuta è "voglio disdire il mio contratto" con un punteggio di confidenza basso, è meglio chiedere "Intendeva disdire il suo contratto?" piuttosto che avviare la procedura di disdetta.
• Interrompere le derive — un agente che si allontana dal copione va riportato in carreggiata da un nodo condizione / operatore, non da un prompt che "dovrebbe bastare".

Anche il telefono è uno stack

Oltre all'AI, un agente telefonico richiede:

• Un trunk SIP di un operatore (Twilio, Voxbone, OVH, Sewan…).
• Un media gateway (LiveKit-SIP, FreeSWITCH, Asterisk) che parla SIP lato operatore e WebRTC lato piattaforma.
• Un trascrittore robusto a rumore, accenti e voci sovrapposte.
• Un sintetizzatore che pronuncia correttamente nomi propri, numeri e date.

Nessuno di questi elementi è banale. E tutti interagiscono tra loro.

Di cosa si occupa betool

L'architettura vocale di betool — LiveKit + LiveKit-SIP + worker dedicato + streaming LLM in cascata — copre di serie i requisiti sopra descritti. Tu mantieni il controllo di:

• Il trunk SIP (il tuo operatore, i tuoi numeri).
• I modelli (BYOK o modelli privati).
• I parametri (latenza target, aggressività del barge-in, fallback su voce umana).

Non configuri l'impianto in tempo reale — è compito della piattaforma. Tu progetti la conversazione, che è la vera sfida di business.