Il sistema vocale di Retell funziona come una catena dal vivo con tre passaggi fondamentali. E ognuno dipende dal passaggio precedente.
ASR → LLM → TTS
ASR (riconoscimento vocale automatico) ascolta chi chiama e trasforma il parlato in testo.
LLM (modello linguistico) legge quel testo, comprende ciò che è stato detto e decide cosa rispondere.
TTS (sintesi vocale) prende quella risposta e la trasforma in audio parlato che chi chiama ascolta.
Quindi il flusso è sostanzialmente: chi chiama parla → l'ASR trascrive → l'LLM genera una risposta → il TTS la pronuncia.
Quando qualcuno è in chiamata, sia il sistema ASR che quello LLM sono i sistemi critici che lavorano in tempo reale. Ed entrambi possono guastarsi, rallentare o comportarsi in modo imprevedibile. Abbiamo bisogno di poter contare sul funzionamento di entrambi i sistemi, quindi abbiamo creato una configurazione che monitora, esegue backup e commuta costantemente in tempo reale. Ed ecco come i due lavorano insieme e perché questi aggiornamenti sono importanti:
Prima, teniamo d'occhio il ritardo (non il guasto)
Ci poniamo costantemente una semplice domanda: "Il sistema sta tenendo il passo con la conversazione?" Ogni 0,1 secondi confrontiamo:
- Quanto audio abbiamo inviato
- Quanto audio è stato effettivamente elaborato
Se il divario supera i 5 secondi, quello è il nostro segnale: questo provider sta rimanendo indietro. Non è morto. Non è rotto. Ma sta andando in quella direzione. Ed è allora che agiamo.
Manteniamo una "rete di sicurezza" dal vivo del tuo audio
Mentre l'audio viene elaborato, manteniamo un backup progressivo di tutto ciò che non è ancora stato gestito completamente. Immaginalo così:
- Se il sistema conferma di aver elaborato qualcosa → lo scartiamo
- Se non lo ha ancora fatto → lo conserviamo
Quindi in ogni momento abbiamo una copia perfetta dell'audio "intermedio", ovvero la parte più a rischio di andare persa. Nessuna supposizione. Nessuna lacuna.
Poi inseriamo un backup
Nel momento in cui rileviamo un ritardo, non aspettiamo. Noi:
- Attiviamo un provider di backup (esiste un ordine di priorità: prima il più veloce, il più vicino, il più affidabile)
- Trasferiamo tutto quell'audio "in sospeso" così da poter recuperare
- Spegniamo il provider in difficoltà
Diamo inoltre al nuovo provider un breve periodo di tolleranza (~20 secondi) per stabilizzarsi prima di iniziare a valutarne le prestazioni.
Il risultato?
La trascrizione semplicemente… continua. Nessun salto. Nessun riavvolgimento. Nessuna strana lacuna. Dal punto di vista di chi chiama, non è successo nulla.
Perché questo è importante
La maggior parte dei sistemi aspetta che un provider si blocchi completamente prima di commutare.
Noi no. Cogliamo il momento in cui inizia ad avere difficoltà e lo sostituiamo prima che diventi un problema.
In sintesi
- Non aspettiamo il guasto
- Rileviamo i rallentamenti in tempo reale
- Preserviamo ogni secondo di audio
- Commutiamo i provider senza interruzioni
Così la conversazione continua a fluire esattamente come dovrebbe.
LLM: dal routing a livello di provider a quello a livello di deployment
Come funzionano i nostri fallback LLM
Ora, sul lato risposta, il guasto non è così evidente. È più sottile. Per ogni modello LLM (ad es. GPT-4.1) abbiamo un insieme di "deployment" che servono quel modello. Immagina un deployment come un data center fisico. Quando vogliamo generare una risposta con IA—o recuperare contesto fondato da un LLM Knowledge Graph per migliorare l'accuratezza e ridurre le allucinazioni—dobbiamo specificare un particolare deployment che elabori quella richiesta.
Dietro le quinte ci sono alcune parti in movimento e la cosa può diventare un po' complessa, ma l'idea di fondo è semplice:
Indirizziamo verso deployment con latenza inferiore
Garantisce che le risposte vengano generate più velocemente e riduce il ritardo per mantenere le conversazioni sincronizzate in tempo reale.
Misuriamo e monitoriamo costantemente il tasso di errore di ogni deployment
E tagliamo il traffico verso quelli che hanno tassi di errore elevati.
Abbiamo bisogno di velocità quando inviamo una richiesta a un deployment
Se è lento, non aspettiamo. Inviamo la richiesta altrove e continuiamo finché uno non risponde.
Vinca il miglior modello di IA
Se un modello si guasta su più deployment, non continuiamo a provarlo. Passiamo a un altro e proseguiamo.
In sintesi
Non ci affidiamo a un solo modello o a un solo provider.
Noi costantemente:
- indirizziamo verso l'opzione migliore
- evitiamo ciò che si sta guastando
- gareggiamo per risposte più rapide
- e commutiamo quando necessario
Così, anche quando i sistemi hanno una giornata storta, le tue conversazioni no.
.avif)