Retells röstsystem fungerar som en levande kedja med tre kärnsteg. Och varje steg är beroende av steget före.
ASR → LLM → TTS
ASR (automatisk taligenkänning) lyssnar på den som ringer och omvandlar deras tal till text.
LLM (språkmodell) läser den texten, förstår vad som sades och avgör vad som ska svaras.
TTS (text-till-tal) tar det svaret och omvandlar det till talat ljud som den som ringer hör.
Så flödet är i grunden: den som ringer talar → ASR transkriberar det → LLM genererar ett svar → TTS talar tillbaka det.
När någon är i ett samtal är både ASR- och LLM-systemen de kritiska systemen som arbetar i realtid. Och båda kan fallera, bli långsammare eller bete sig oförutsägbart. Vi behöver kunna lita på att båda systemen fungerar, så vi har byggt en uppsättning som ständigt övervakar, säkerhetskopierar och kopplar om i realtid. Och så här samarbetar de två och varför dessa uppdateringar spelar roll:
Först håller vi utkik efter fördröjning (inte fel)
Vi ställer ständigt en enkel fråga: "Håller systemet jämna steg med samtalet?" Var 0,1 sekund jämför vi:
- Hur mycket ljud vi har skickat
- Hur mycket ljud som faktiskt har bearbetats
Om gapet växer bortom 5 sekunder är det vår signal: den här leverantören halkar efter. Inte död. Inte trasig. Men på väg dit. Och det är då vi agerar.
Vi håller ett levande "skyddsnät" av ditt ljud
När ljudet bearbetas håller vi en rullande säkerhetskopia av allt som ännu inte har hanterats fullt ut. Tänk på det så här:
- Om systemet bekräftar att det bearbetade något → kasserar vi det
- Om det inte har gjort det ännu → håller vi kvar det
Så vid varje ögonblick har vi en perfekt kopia av "mellanljudet", vilket är den del som löper störst risk att gå förlorad. Inga gissningar. Inga luckor.
Sedan kopplar vi in en backup
I det ögonblick vi upptäcker fördröjning väntar vi inte. Vi:
- Startar upp en backup-leverantör (det finns en prioritetsordning: snabbast, närmast, mest tillförlitlig först)
- Skickar över allt det "i limbo"-ljud så att den kan komma ikapp
- Stänger ner den kämpande leverantören
Vi ger också den nya leverantören en kort respitperiod (~20 sekunder) att stabilisera sig innan vi börjar bedöma dess prestanda.
Resultatet?
Transkriptionen bara… fortsätter. Inget hopp. Ingen tillbakaspolning. Inga konstiga luckor. Ur perspektivet hos den som ringer hände ingenting.
Varför detta spelar roll
De flesta system väntar på att en leverantör helt ska krascha innan de kopplar om.
Det gör inte vi. Vi fångar ögonblicket när den börjar kämpa och ersätter den innan den någonsin blir ett problem.
Sammanfattningsvis
- Vi väntar inte på fel
- Vi upptäcker nedgångar i realtid
- Vi bevarar varje sekund av ljud
- Vi byter leverantörer sömlöst
Så samtalet fortsätter att flyta precis som det ska.
LLM: från routing på leverantörsnivå till distributionsnivå
Så fungerar våra LLM-fallbacks
På svarssidan är fel inte lika uppenbart. Det är mer subtilt. För varje LLM-modell (dvs. GPT-4.1) har vi en uppsättning "distributioner" som betjänar den modellen. Tänk på en distribution som ett fysiskt datacenter. När vi vill generera ett AI-svar—eller hämta grundad kontext från en LLM Knowledge Graph för att förbättra precisionen och minska hallucinationer—behöver vi ange en specifik distribution som ska bearbeta den begäran.
Under huven finns det några rörliga delar och det kan bli lite komplext, men grundidén är enkel:
Vi routar till distributioner som har lägre latens
Säkerställer att svar genereras snabbare och minskar fördröjning för att hålla samtal synkroniserade i realtid.
Vi mäter & övervakar ständigt felfrekvensen för varje distribution
Och vi skär ner trafiken till dem som har hög felfrekvens.
Vi har ett behov av fart när vi skickar en begäran till en distribution
Om den är långsam väntar vi inte. Vi skickar begäran någon annanstans och fortsätter tills en svarar.
Må den bästa AI-modellen vinna
Om en modell fallerar över flera distributioner fortsätter vi inte att prova den. Vi byter till en annan och fortsätter.
Sammanfattningsvis
Vi förlitar oss inte på en modell eller en leverantör.
Vi:
- routar ständigt till det bästa alternativet
- undviker det som fallerar
- tävlar om snabbare svar
- och byter när det behövs
Så även när system har en dålig dag, gör inte dina samtal det.
.avif)
