Come creare un Voice Agent con l'IA (Guida completa)

Ecco la verità che nessuno dice a chi costruisce agenti AI. Gli agenti vocali non hanno bisogno del modello migliore. Tutto ciò di cui hanno bisogno è

TLDR; se trovi noiosa la lettura o la tua capacità di attenzione è ridotta, puoi usare il file skill che ho creato per ottenere l'intero articolo e incollarlo al tuo agente ➡️https://github.com/codejunkie99/voice-agent-builder

tutto ciò che devi costruire è:

• una pipeline in tempo reale con un budget di latenza reale
• cinque componenti collegati nell'ordine giusto
• un ancoraggio abbastanza solido da tenere onesto il modello
• un ciclo di revisione settimanale che si accumuli

OpenAI ha rilasciato GPT-Realtime-2 il 7 maggio 2026. Salesforce AI Research ha pubblicato il paper VoiceAgentRAG il 1° marzo, la stessa settimana in cui Deepgram Flux è passato dalla beta alla disponibilità generale. I pezzi hanno smesso di essere il problema.

Ciò che è rimasto il problema è come li colleghi e cosa scrivi all'agente da dire.

Ho passato gli ultimi tre mesi a costruire agenti vocali che rispondono davvero al telefono. Non farò finta che sia stato tutto pulito.

• La prima build sembrava un chiosco. L'ho buttata via in due giorni.
• La seconda build ha "prenotato" quattro appuntamenti fantasma nella prima ora prima che me ne accorgessi.
• La terza build ha perso memoria perché ho dimenticato di invalidare la cache del contesto dopo che l'estrattore di background ha scritto nuovi fatti.
• Quando finalmente qualcosa ha funzionato, il sistema era la quarta riscrittura.

La versione che difenderei ora ha un piccolo insieme di proprietà che passerò le prossime 6.000 parole a spiegare.

• La pipeline ha un unico lavoro all'interno di un unico budget. Cinque componenti, sotto i 700ms end-to-end, senza eccezioni.
• La conoscenza vive nei tuoi documenti e viene recuperata con una cache a doppio agente, non estratta dalla testa del modello.
• Il design della conversazione è la disciplina di scrivere per le orecchie, non per gli occhi. La maggior parte dei team lo tratta come un dettaglio estetico. Non lo è.
• Ogni turno scrive un log strutturato che posso riprodurre con la configurazione corrente 90 giorni dopo.

Questo articolo è ciò che quei 90 giorni mi hanno effettivamente insegnato, più le due o tre scommesse che farei per prime se ricominciassi oggi.🔽🔽

Cos'è veramente un agente vocale

Un agente vocale non è un chatbot con un microfono attaccato. Non è un wrapper TTS attorno a un'API testuale.

È un sistema audio in tempo reale. Vincolato dalla latenza. Cinque componenti che si coordinano in una finestra da 300 a 800 millisecondi.

La pipeline nell'ordine in cui gli eventi accadono effettivamente:

1. L'utente parla
2. L'audio viene catturato
3. Lo STT in streaming trascrive parola per parola, mentre la persona sta ancora parlando
4. L'agente legge la trascrizione e recupera le conoscenze rilevanti dai tuoi documenti
5. L'LLM genera una risposta
6. Il TTS pronuncia la risposta ad alta voce
7. L'utente la sente

Ognuna di quelle frecce è un componente che puoi scegliere, ottimizzare e sostituire.

Ho provato a costruirlo prima nel modo chatbot. STT completa, invia all'LLM, aspetta la risposta completa, invia al TTS, aspetta l'audio completo, riproduci.

Sembrava terribile. Come parlare a un chiosco. Dopo due giorni l'ho cancellato.

Il motivo per cui sembrava terribile non è che i numeri di latenza fossero negativi. Sulla carta andavano bene. Il motivo è che gli umani non conversano a turni. Conversano in flussi sovrapposti.

• L'agente deve iniziare a formulare una risposta mentre l'utente sta ancora finendo la frase.
• Il TTS deve iniziare a parlare prima che l'LLM abbia finito di scrivere.
• Lo STT deve continuare ad ascoltare mentre l'agente parla, così sa quando stare zitto.

Un agente vocale che non può essere interrotto non è un agente vocale. È una segreteria telefonica.

Le tre architetture

Ce ne sono solo tre. Scegli in base a ciò che devi controllare.

Pipeline a catena

• Servizi STT, LLM, TTS separati collegati insieme
• Tre modelli indipendenti, ognuno specializzato nel suo lavoro
• Il testo scorre tra di loro
• La latenza si aggira intorno ai 600-700ms su una piattaforma gestita ben ottimizzata
• Il più controllabile, il più debuggabile, il più facile da aggiornare un livello alla volta

Mezza cascata

• L'audio va direttamente in un modello multimodale che sente l'audio, non la trascrizione
• Cattura la frustrazione nella voce di qualcuno, una domanda implicita da un tono ascendente, un cambio di lingua a metà frase
• L'output passa comunque attraverso un TTS specializzato per il controllo audio
• La latenza scende a 300-500ms

Parlato nativo da voce a voce

• Un modello, audio in ingresso, audio in uscita
• Nessun livello di trascrizione, nessun passaggio di testo
• Ogni grande laboratorio ha rilasciato un modello vocale nativo nel 2026
• La latenza scende a 200-300ms, sotto la soglia in cui i chiamanti smettono di notare che stanno parlando con un'IA

Da quale iniziare

1. Inizia con la pipeline a catena. I migliori strumenti esistono per essa. Passa al parlato nativo una volta che hai dimostrato il tuo prodotto sulla pipeline e vuoi un miglioramento di latenza step-function.
2. Ho provato prima il parlato nativo per tutto. Era eccellente per i flussi di prenotazione.
3. È crollato su un modulo di raccolta in 12 passaggi perché il singolo modello non riusciva a tenere la macchina a stati nella sua testa senza un rigonfiamento del contesto al nono turno.
4. Ho spostato quello su una pipeline a catena con un vero livello di macchina a stati e il tasso di completamento è passato dal 61% all'89% in tre giorni.
5. L'ambito degli strumenti per ogni stato è stata l'intera soluzione.

I cinque componenti che devi collegare

Ogni pipeline a catena ha gli stessi cinque componenti. Cinque lavori che devono essere riempiti prima che il tuo agente riceva la sua prima chiamata.

Le orecchie (STT in streaming)

Il modello STT converte l'audio in arrivo in testo in tempo reale, parola per parola, mentre la persona sta ancora parlando. Questo è il componente più importante del tuo stack. Un errore di trascrizione qui si ripercuote su tutto ciò che segue.

Cosa cercare nel 2026:

• Precisione in streaming. Accurato mentre la persona parla, non solo dopo che ha finito.
• Tasso di errore sulle parole. Dal 6 all'8% su audio di produzione reale è buono. Oltre il 12% frustrerà gli utenti su una chiamata su tre.
• Rilevamento integrato della fine del turno. Il più grande miglioramento UX del 2026.

Perché il rilevamento della fine del turno è importante:

• Il STT generico restituisce trascrizioni. Non ti dice quando l'oratore ha finito.
• Senza di esso, il tuo agente interrompe a metà frase o aspetta due secondi imbarazzanti.
• L'ondata del 2026 di modelli STT in streaming include il rilevamento della fine del turno all'interno della stessa rete che produce la trascrizione.
• Il modello emette un segnale di turno completato quando ha deciso che l'oratore ha finito.
• Il segnale usa il contesto semantico, non solo il silenzio acustico. Cattura le frasi che si affievoliscono e ignora le pause per respiro.
• Passa a questo se il tuo fornitore lo ha rilasciato. La pausa prima che l'agente inizi a parlare diminuisce di 200-400ms su ogni turno.

Il cervello (LLM)

L'LLM legge la trascrizione, la cronologia della conversazione, le conoscenze recuperate e decide cosa dire. Decide anche le azioni, non solo le parole.

Regole specifiche per la voce:

• Usa il modello piccolo e veloce, non l'ammiraglia. I modelli di ragionamento frontalieri impiegano 1500ms per generare la prima parola. Questo è aria morta. I modelli più piccoli nella stessa famiglia vincono quasi sempre sui turni vocali.
• Passa al modello grande solo per specifiche chiamate a strumenti complesse che richiedono vera pianificazione.
• Limita il prompt di sistema a 800 token. Si ricarica a ogni turno. Un prompt da 4000 token aggiunge latenza a ogni singolo messaggio.

Chiamata di funzione, in parole semplici:

• Definisci ogni funzione con una descrizione di cosa fa e di quali informazioni ha bisogno.
• L'LLM legge la descrizione e decide quando chiamarla in base allo stato della conversazione.
• Nessun albero di logica condizionale. L'LLM abbina l'intento alla funzione dal linguaggio naturale.

Il fallimento produttivo più comune con la chiamata di funzione non è quello che ti aspetteresti:

• L'LLM non lancia un errore quando non può chiamare una funzione. Invece, narra l'azione.
• "Ho confermato la tua prenotazione." Niente è stato chiamato. L'utente pensa di essere prenotato. Non lo è.
• La soluzione è limitare gli strumenti allo stato corrente. Uno stato "raccogli nome" non deve esporre book_appointment. Uno stato "conferma dettagli" non deve esporre check_availability.
• La macchina a stati è la barriera di sicurezza, non il prompt di sistema.

La conoscenza (RAG)

RAG è il meccanismo che permette al tuo agente di rispondere usando i tuoi documenti invece dei dati di addestramento del modello.

Perché non puoi saltarlo:

• Gli LLM sono addestrati su internet pubblico fino a una data di cutoff.
• Sanno molto del mondo. Non sanno nulla di specifico sui tuoi prodotti, prezzi, politiche, clienti.
• Senza RAG, un agente a cui viene chiesto "cosa c'è nel piano enterprise?" allucinerà con sicurezza.
• Con RAG, recupera la risposta reale dalla tua documentazione prima di rispondere.

Il meccanismo di base:

• L'utente fa una domanda.
• Il sistema incorpora la query.
• Il database vettoriale restituisce i chunk di documenti più rilevanti.
• I chunk vengono iniettati nel contesto dell'LLM.
• All'LLM viene detto di rispondere solo da quel contesto.

La sfida specifica della voce:

• Una tipica query a database vettoriale aggiunge da 50 a 300ms alla pipeline.
• Combinato con STT, LLM e TTS, fa esplodere il tuo budget di latenza.
• La soluzione è il pattern di cache a doppio agente. Sezione intera su questo più avanti.

La bocca (TTS)

Il TTS converte il testo in audio parlato. Sembra semplice. In realtà è un importante fattore di differenziazione nella qualità percepita.

Cosa conta:

• Tempo al primo audio. Un TTS che impiega 200ms per iniziare a parlare consuma un terzo del tuo budget di latenza solo sul livello di output.
• Qualità vocale. Gli umani sono estremamente sensibili al parlato sintetico. Artefatti sottili, ritmo innaturale, accento sbagliato vengono tutti letti come un verdetto sull'intero sistema.
• Scegli la voce intenzionalmente. È un segnale di fiducia prima che l'utente abbia sentito una frase.

Le mani (Funzioni e integrazioni)

Le funzioni sono azioni che l'LLM può intraprendere a metà conversazione:

• Prenotare appuntamenti
• Controllare lo stato degli ordini
• Inviare SMS di conferma
• Trasferire a un umano
• Aggiornare record nel tuo CRM

Questo è il cambiamento architetturale che rende gli agenti vocali moderni drammaticamente più capaci dei sistemi "premi 1 per la fatturazione".

Il budget di latenza in cui devi rientrare

La cosa più importante e non ovvia sugli agenti vocali: ogni millisecondo di tempo di elaborazione è un millisecondo di silenzio in cui il chiamante siede.

Il calcolo:

• Gli umani si aspettano una risposta conversazionale entro 500-700ms dal completamento di una frase
• Oltre un secondo sembra che il sistema stia facendo fatica
• Oltre due secondi, i chiamanti iniziano a parlare sopra l'agente

Quei 700ms sono tutto il tuo budget, suddiviso tra ogni componente.

Budget per componente, corsia veloce vs corsia lenta:

• Trasporto. 20-50ms peer-to-peer. 50-100ms su relay.
• Primo interim STT. 100-150ms su cache hit. 150-250ms su miss.
• Rilevamento fine turno. Integrato nel modello, ~50ms. Soglia di silenzio, 300-600ms.
• Recupero RAG. Meno di un millisecondo su cache hit. 80-150ms su BM25 locale + rerank.
• Tempo al primo token LLM. 150-250ms con un modello piccolo. 400-600ms con un modello frontaliere.
• Tempo al primo audio TTS. 60-100ms sul livello veloce. 150-250ms sul livello qualità.
• Overhead di rete. 40-80ms totale all'interno di una regione. 100-160ms totale tra regioni.
• End-to-end. ~440ms sulla corsia veloce. ~700-900ms sulla corsia lenta.

I due maggiori miglioramenti nel 2026:

1. Rilevamento della fine del turno integrato nel modello. Rimuove 200-400ms da ogni turno. Il singolo più grande upgrade che puoi fare quest'anno.
2. Prefetch speculativo con cache a doppio agente. Porta il recupero da "miss con ricerca vettoriale" a "hit con lookup in cache" su circa il 40% dei turni.

Tutto il resto è un arrotondamento rispetto a questi due.

Il pattern RAG a doppio agente

Il RAG standard all'interno di un ciclo vocale è un problema. La query al database vettoriale impiega 80-300ms e fa esplodere il tuo budget di latenza a ogni turno.

La risposta della ricerca del 2026 arriva dal paper VoiceAgentRAG di Salesforce AI Research, pubblicato a marzo. L'intuizione è semplice.

• In una conversazione reale, la prossima domanda è solitamente prevedibile dalla corrente.
• Qualcuno che chiede informazioni sui prezzi probabilmente seguirà con il livello enterprise.
• Qualcuno che chiede informazioni sull'installazione probabilmente chiederà della compatibilità dopo.

Quindi esegui due agenti contemporaneamente.

L'agente di background (Pensatore Lento)

• Viene eseguito mentre l'utente ascolta la risposta corrente
• Prevede le tre-cinque domande di follow-up più probabili usando l'LLM
• Pre-recupera i chunk di documenti rilevanti per ogni previsione
• Li memorizza in una cache locale in memoria prima che l'utente abbia finito di sentire la risposta corrente

L'agente in primo piano (Parlatore Veloce)

• Gestisce la prossima domanda dal vivo controllando prima la cache in memoria
• Un lookup in cache richiede meno di un millisecondo rispetto a 110ms per una chiamata remota al database vettoriale
• Se la cache ha la risposta, salta completamente il database
• Se la cache non ha la risposta, ricade sul database e memorizza quel risultato per la prossima volta

Numeri di benchmark dal paper

• Il 75% delle query colpisce la cache
• Accelerazione di 316× sul recupero su cache hit (0,35ms vs 110ms)
• 16 secondi di latenza cumulativa risparmiati su 200 query

Il principio da ricordare: usa il tempo di ascolto dell'utente come tempo di calcolo. Nel momento in cui iniziano a sentire la risposta corrente, è il momento in cui inizi a prepararti per la loro prossima domanda.

Ho provato il RAG vettoriale semplice all'interno del ciclo vocale sulla mia prima build. Aggiungeva 110ms per turno.

Uccideva la sensazione di conversazione. Sono passato al pattern di cache a doppio agente alla sesta settimana. Il 40% dei turni che colpisce la cache sembra più scattante dei rappresentanti umani del call center che l'agente sostituisce.

Il design della conversazione è la disciplina che la maggior parte dei costruttori salta

Puoi avere lo STT più veloce, l'LLM più piccolo, la cache RAG più intelligente. Se il tuo agente non sa parlare, i chiamanti riattaccheranno.

Il design della conversazione è la disciplina di scrivere per le orecchie, non per gli occhi.

Regole che seguo ora che ho imparato sbagliandole prima

• Parla in frasi brevi. La capacità media di attenzione umana per informazioni parlate è di 8-10 secondi. Una risposta di 15 secondi è troppo lunga. Dividila in due turni.
• Non fare mai due domande in un turno. I chiamanti possono trattenere solo una nella memoria di lavoro. Chiedi una, aspetta, poi chiedi la successiva.
• Usa frasi di riconoscimento. "Ricevuto." "Certo." "Fammi controllare per te." Queste riempiono il silenzio tra la fine dell'utente e la preparazione della risposta.
• Rispecchia il linguaggio dell'utente. Il chiamante dice "problema di fatturazione", l'agente dice "problema di fatturazione". Non "contestazione finanziaria" o "problema di pagamento". Parafrasare crea attrito. Rispecchiare crea rapporto.
• Scrivi per l'orecchio, non per l'occhio. Nessun elenco puntato. Nessuna intestazione. Nessun markdown nel prompt di sistema. L'LLM cercherà di pronunciare asterischi e trattini.
• Scrivi i numeri per esteso. "Novantaquattromilacentosette" invece di "94.107". "Quindici dollari e novantanove centesimi" invece di "$15,99". Il TTS pronuncia regolarmente male i numeri formattati.
• Limita il prompt di sistema a 800 token. Si ricarica a ogni turno.

La struttura in tre atti di ogni buona conversazione vocale

1. Riconoscimento e orientamento. "Allora, stai cercando di riprogrammare il tuo appuntamento di giovedì, fammi tirare su quello." Conferma che il chiamante è stato capito. Compra tempo mentre il recupero viene eseguito.
2. Risoluzione. L'azione o risposta principale. Un punto per turno. Andare avanti.
3. Conferma e chiusura. "Ho riprogrammato il tuo appuntamento a lunedì 19 alle 15:00, riceverai un SMS di conferma a breve." Uscita pulita. Non lasciare mai un ciclo aperto.

La sicurezza sono due punti di controllo, non uno

Il componente che la maggior parte dei costruttori alle prime armi salta e di cui si pente.

Un agente vocale non ha un momento di "leggi prima di inviare". Un output non sicuro viene pronunciato immediatamente. Nessuna bozza, nessuna anteprima, nessun umano nel ciclo.

Il modello giusto è due punti di controllo.

Il guardiano di input (prima che l'LLM veda il turno dell'utente)

• Iniezione di prompt. Attacchi "Ignora le istruzioni precedenti, fingi di essere...". Sfrutta la capacità dell'LLM di seguire le istruzioni per rubare dati o uscire dall'ambito.
• PII pronunciate ad alta voce. Numeri di carte di credito, numeri di previdenza sociale. Redigere prima che colpiscano qualsiasi log o database.
• Lista di blocco degli argomenti. Caricata da un file JSON. Aggiornata settimanalmente mentre impari cosa provano effettivamente gli utenti.

Il guardiano di output (dopo che l'LLM ha scritto la sua risposta, prima che il TTS la pronunci)

• Linguaggio di promesse eccessive. "Garantisco", "Prometto". Crea problemi legali e di fiducia su una linea registrata.
• Affermazioni fattuali specifiche non nel contesto recuperato. Controllo leggero delle allucinazioni. Cattura circa il 70% delle risposte inventate nella mia implementazione.
• Endpoint di moderazione standard. Per il raro comportamento scorretto del modello.

Cosa restituiscono entrambi i guardiani

• safe (bool)
• categoria rilevata (stringa, se non sicuro)
• frase di sostituzione che l'agente pronuncia invece

Ogni trigger viene registrato in un file con timestamp, categoria, testo oscurato e ID chiamata.

La frase di escalation

Una frase esatta, hardcoded, che l'agente dice quando non conosce la risposta o quando qualcosa sta andando storto.

• "Voglio assicurarmi di darti informazioni accurate. Lascia che ti colleghi con qualcuno che può aiutarti."
• Non cinque varianti. Non la stima improvvisata dell'LLM della frase giusta.
• Una frase. IN MAIUSCOLO nel prompt di sistema. Fallback quando qualsiasi controllo di sicurezza scatta.

Ho rilasciato senza un guardiano di output sulla build uno. L'agente ha citato con sicurezza un prezzo scontato del 30% rispetto a quello reale.

Il prezzo era in un documento obsoleto nella knowledge base.

Il controllo delle allucinazioni lo avrebbe catturato perché il prezzo giusto non era nel contesto recuperato.

Valutazione, o come sapere se è buono

Non puoi migliorare ciò che non puoi misurare. La maggior parte dei team salta la valutazione e rilascia agenti difettosi.

Il framework a quattro livelli

Livello 1: Infrastruttura. Impianto idraulico.

• WER sul tuo dominio effettivo (non benchmark del fornitore)
• Latenza p50, p95, p99 dell'intera pipeline
• Tempo al primo audio
• Qualità audio sul tuo trasporto

Livello 2: Esecuzione. L'agente fa ciò che è stato richiesto.

• Tasso di successo delle attività
• Precisione delle chiamate a strumenti
• Correttezza dei parametri
• Ancoraggio della risposta
• Usa LLM-as-judge su un modello piccolo e veloce. Quattro domande sì/no: risposto correttamente, rimasto ancorato, suonato naturale per la voce, appropriatamente conciso.

Livello 3: Comportamento utente. Sembra naturale parlare con lui?

• Tasso di recupero da interruzione
• Tasso di ripetizione della richiesta
• Lunghezza media del turno
• Numero di riparazioni conversazionali
• Campiona 20 chiamate a settimana. Leggi le trascrizioni effettive. Vedrai schemi entro dieci.

Livello 4: Risultato aziendale. Risolve il problema?

• Tasso di contenimento (percentuale di chiamate risolte senza un umano)
• Tasso di trasferimento
• CSAT
• Tasso di risoluzione al primo contatto
• Ottimizza verso il contenimento. Correla con tutto il resto ed è il più facile da misurare senza strumentazione.

Composizione del set di test

Costruiscilo prima del lancio. Minimo 50 conversazioni.

• 40% percorso felice
• 30% casi limite
• 15% gestione errori
• 10% avversario (iniezione di prompt, tentativi di jailbreak)
• 5% variazione acustica (rumore di fondo, accento marcato, vivavoce)

Per ogni scenario:

• Quale strumento avrebbe dovuto essere chiamato
• Con quali parametri
• Cosa avrebbe dovuto dire l'agente

Il ciclo di revisione settimanale

Ogni lunedì mattina. 30 minuti.

1. Recupera le metriche
2. Campiona 20 chiamate (7 trasferite, 7 risolte, 6 casuali)
3. Leggi le trascrizioni
4. Nomina il singolo tipo di fallimento più comune
5. Fai un cambiamento (una variabile alla volta, sempre)
6. Test A/B per 48 ore
7. Rilascia il vincitore

L'ancoraggio è un sistema di fiducia

La maggior parte dei costruttori pensa al RAG come a una funzionalità di performance, un modo per ottenere risposte più accurate. Quella cornice lo sottovaluta.

In un agente vocale, l'accuratezza di ogni risposta è un'affermazione diretta su quanto sia affidabile il tuo prodotto. Un chiamante che sente una risposta sbagliata su prezzi, copertura o politica, detta con sicurezza in una voce dal suono naturale, non sarà solo frustrato. Si sentirà ingannato.

L'implementazione della promessa di fiducia ha quattro parti.

1. Fonte della verità

• I tuoi documenti, non i dati di addestramento del modello
• Il prompt di sistema deve dirlo esplicitamente, in lettere maiuscole: RISPONDI SOLO DAL CONTESTO FORNITO
• Il modello deriverà ancora a volte verso la conoscenza generale, ma l'istruzione esplicita riduce il tasso di un ordine di grandezza

1. Rifiuto educato

• Quando l'agente non riesce a trovare una risposta, lo dice direttamente
• La frase esatta conta
• "Voglio assicurarmi di darti informazioni accurate, fammi controllare" ti compra un trasferimento educato
• "Non sono sicuro" suona come incompetenza
• "Sulla base delle mie informazioni" suona come una scappatoia da avvocato
• Scegli una frase, hardcodala, non lasciare mai che l'LLM improvvisi qui

1. Risposta consapevole della confidenza

• Il punteggio BM25 più alto sui chunk recuperati è un utile proxy per la confidenza
• Punteggio sopra 0,6: l'agente risponde con sicurezza
• Punteggio 0,3-0,6: l'agente risponde ma aggiunge una cautela "credo"
• Punteggio sotto 0,3: l'agente non risponde, offre di trasferire
• Modifica di 20 righe nel codice di costruzione del prompt di sistema. Riduce le allucinazioni approssimativamente a metà.

1. Igiene della knowledge base

• I documenti obsoleti producono risposte obsolete, che sono risposte pericolose
• Eseguo un audit il venerdì: leggo il 5% inferiore delle risposte con punteggio di confidenza dalla settimana
• La metà delle volte la risposta era giusta ma il recupero ha trovato un chunk obsoleto
• Aggiorna il chunk, reincorporalo, la settimana successiva è più tranquilla

Cosa tenere d'occhio

Sei modalità di fallimento che ti colpiranno.

VAD nella pipeline invece che nel trasporto

• Problema. L'agente si attiva sul proprio output TTS, entra in un loop di interruzione, o fallisce completamente nel rilevare la fine del turno.
• Soluzione. L'analizzatore VAD va sul trasporto. Sempre. Abbinalo a un guardiano dell'eco che ignori le trascrizioni STT che corrispondono all'output recente dell'assistente.

Strumenti disponibili nello stato sbagliato

• Problema. L'LLM chiama book_appointment in uno stato che sta ancora raccogliendo il nome del paziente. O inventa una prenotazione che non è mai avvenuta.
• Soluzione. Limita gli strumenti per stato. Uno stato, solo le sue funzioni. La macchina a stati è la barriera di sicurezza, non il prompt di sistema.

Il gestore della funzione lancia un'eccezione e non chiama mai il callback del risultato

• Problema. L'LLM rimane in attesa di un risultato dello strumento che non arriva mai. O ne allucina uno.
• Soluzione. Ogni gestore avvolge in try/except. Ogni ramo invia un risultato. Ogni fallimento ha un fallback parlato. Mai un risultato vuoto.

Validare i dati utente nel prompt invece che nel codice

• Problema. L'LLM accetta "john@" come email reale alla chiamata 12. Rifiuta una valida con un segno più alla chiamata 47.
• Soluzione. La validazione vive in Python. Regex per l'email, parser di date per le date, controllo lunghezza del nome, una risposta di richiesta reiterata quando la validazione fallisce.

Il contesto cresce senza limiti in una chiamata lunga

• Problema. La latenza p95 si sposta verso l'alto nel corso della settimana senza modifiche al codice. Al turno 20 stai inviando 12K token per turno.
• Soluzione. Finestra scorrevole degli ultimi N turni più prompt di sistema. O resett del contesto basato su pietre miliari alla fine di ogni fase discreta.

Il TTS legge codici e ID letteralmente

• Problema. Il codice di conferma "A3X7" esce come "ay tre ex sette" senza pausa. Il paziente ti chiede comunque di ripetere.
• Soluzione. Espansione alfabeto fonetico NATO con tag SSML di pausa. Sembra più lento. Viene letto correttamente la prima volta.

Cose che farei diversamente

• Costruisci lo schema del log dei turni dal giorno uno, non dalla settimana quattro. L'endpoint di riproduzione è lo strumento più prezioso che ho costruito e l'ho costruito dopo averne avuto bisogno.
• Usa il rilevamento semantico della fine del turno dall'inizio invece di combattere con le soglie di silenzio.
• Passa a una vera macchina a stati il giorno in cui il prompt di sistema supera le 300 parole. Non cercare di codificare una macchina a stati in prosa.
• Smetti di validare nei prompt. L'LLM non è un parser. Python è un parser. Usa Python.
• Metti in cache i cinque documenti RAG più probabili all'inizio della chiamata. Salta la ricerca vettoriale all'interno del ciclo dei turni.
• Costruisci il cancello per le chiacchiere informali prima di costruire il recupero. "Ciao" è la vittoria più economica da 200ms nel sistema.
• Esegui il set di valutazione prima della prima chiamata di produzione. Minimo 50 conversazioni.
• Metti in atto una coda di estrazione durevole dal giorno uno. Una tabella Postgres pending_extractions con un singolo worker di riprova richiede 200 righe e ti salva da un vero guasto.
• Esegui un giudice LLM asincrono su ogni 50esima chiamata. Valuta su ancoraggio, pertinenza, brevità. Inviarlo a una dashboard. La deriva è reale.
• Esegui il ciclo di revisione settimanale. Campiona 20 chiamate ogni lunedì. Fai un cambiamento. Test A/B. Rilascia il vincitore.

Conclusione

Gli agenti vocali sembrano AI. Funzionano come sistemi in tempo reale.

I team che rilasciano li trattano in quel modo. I team che rilasciano con sei mesi di ritardo pensano che un prompt migliore risolva un problema di sistema.

Possiedi la tua pipeline. Possiedi i tuoi log. Tienili in file semplici dove ogni fallimento è a un replay di distanza.

Il primo agente mi ha richiesto un weekend. Il sistema di produzione ha richiesto dieci settimane. Da allora è migliorato ogni giorno, senza che io lo toccassi. L'utente non misura questo. Nota che l'agente ha risposto "grazie" senza farlo aspettare.

Note Legali e Dichiarazioni

Questo articolo è stato ricercato e scritto dall'autore, e modificato da un modello AI. La miniatura è stata presa da Pinterest.

Questo articolo è stato ricercato e scritto dall'autore mentre lavorava su agenti vocali in un'infrastruttura più profonda.

Si basa su appunti in evoluzione e ricerche approfondite utilizzando Perplexity, Claude e ChatGPT, insieme a system design e API design tratti da alcuni libri universitari di livello triennale.

È stato accuratamente revisionato da Minimax M2.7 e Claude Opus 4.7 per errori grammaticali e di formattazione.