Het voice-systeem van Retell werkt als een live keten met drie kernstappen. En elke stap is afhankelijk van de stap ervoor.
ASR → LLM → TTS
ASR (automatic speech recognition) luistert naar de beller en zet hun spraak om in tekst.
LLM (language model) leest die tekst, begrijpt wat er gezegd is en bepaalt wat het terugzegt.
TTS (text-to-speech) neemt dat antwoord en zet het om in gesproken audio die de beller hoort.
De flow is dus in feite: beller spreekt → ASR transcribeert het → LLM genereert een antwoord → TTS spreekt het terug.
Wanneer iemand in gesprek is, zijn zowel het ASR- als het LLM-systeem de kritieke systemen die in real time werken. En beide kunnen falen, vertragen of zich onvoorspelbaar gedragen. We moeten erop kunnen vertrouwen dat beide systemen werken, dus hebben we een opzet gebouwd die voortdurend monitort, back-upt en in real time schakelt. En zo werken de twee samen en waarom deze updates belangrijk zijn:
Eerst letten we op vertraging (niet op falen)
We stellen voortdurend één eenvoudige vraag: "Houdt het systeem het gesprek bij?" Elke 0,1 seconde vergelijken we:
- Hoeveel audio we hebben verstuurd
- Hoeveel audio er daadwerkelijk is verwerkt
Als het verschil groter wordt dan 5 seconden, is dat ons signaal: deze provider raakt achterop. Niet dood. Niet kapot. Maar op weg daarnaartoe. En dan komen we in actie.
We houden een live "vangnet" van je audio aan
Terwijl audio wordt verwerkt, houden we een doorlopende back-up bij van alles wat nog niet volledig is afgehandeld. Zie het zo:
- Als het systeem bevestigt dat het iets heeft verwerkt → gooien we het weg
- Als dat nog niet zo is → houden we het vast
Op elk moment hebben we dus een perfecte kopie van de "tussenliggende" audio, het deel dat het grootste risico loopt om verloren te gaan. Geen gissen. Geen gaten.
Vervolgens wisselen we een back-up in
Op het moment dat we vertraging detecteren, wachten we niet af. We:
- Starten een back-upprovider op (er is een prioriteitsvolgorde: eerst de snelste, dichtstbijzijnde, meest betrouwbare)
- Sturen alle "in limbo" audio door zodat die kan bijtrekken
- Zetten de worstelende provider uit
We geven de nieuwe provider ook een korte overgangsperiode (~20 seconden) om te stabiliseren voordat we de prestaties gaan beoordelen.
Het resultaat?
Het transcript gaat gewoon… door. Geen sprong. Geen terugspoelen. Geen vreemde gaten. Vanuit het perspectief van de beller is er niets gebeurd.
Waarom dit belangrijk is
De meeste systemen wachten tot een provider volledig crasht voordat ze schakelen.
Wij niet. Wij pakken het moment waarop het begint te worstelen en vervangen het voordat het ooit een probleem wordt.
Kort samengevat
- We wachten niet op falen
- We detecteren vertragingen in real time
- We bewaren elke seconde audio
- We schakelen naadloos van provider
Zo blijft het gesprek precies stromen zoals het hoort.
LLM: van provider-level naar deployment-level routing
Hoe onze LLM-fallbacks werken
Aan de antwoordkant is falen minder duidelijk. Het is subtieler. Voor elk LLM-model (bijv. GPT-4.1) hebben we een set "deployments" die dat model bedienen. Zie een deployment als een fysiek datacenter. Wanneer we een AI-antwoord willen genereren—of gefundeerde context willen ophalen uit een LLM Knowledge Graph om de nauwkeurigheid te verbeteren en hallucinaties te verminderen—moeten we een specifieke deployment aanwijzen om dat verzoek te verwerken.
Onder de motorkap zijn er een paar bewegende delen en het kan wat complex worden, maar het kernidee is eenvoudig:
We routeren naar deployments met lagere latency
Dit zorgt ervoor dat antwoorden sneller worden gegenereerd en vermindert vertraging om gesprekken in real time gesynchroniseerd te houden.
We meten & monitoren voortdurend het foutpercentage van elke deployment
En we snijden het verkeer af naar degene met hoge foutpercentages.
We hebben behoefte aan snelheid bij het versturen van een verzoek naar een deployment
Als het traag is, wachten we niet. We sturen het verzoek ergens anders heen en gaan door totdat er één reageert.
Moge het beste AI-model winnen
Als een model faalt over meerdere deployments, blijven we het niet proberen. We schakelen over naar een ander en gaan door.
Kort samengevat
We vertrouwen niet op één model of één provider.
We zijn voortdurend bezig met:
- routeren naar de beste optie
- vermijden wat faalt
- racen voor snellere antwoorden
- en schakelen wanneer nodig
Dus zelfs wanneer systemen een slechte dag hebben, hebben je gesprekken dat niet.
.avif)