Retells stemmesystem fungerer som en live kæde med tre kernetrin. Og hvert trin afhænger af trinnet før.
ASR → LLM → TTS
ASR (automatisk talegenkendelse) lytter til den, der ringer, og omdanner deres tale til tekst.
LLM (sprogmodel) læser den tekst, forstår, hvad der blev sagt, og beslutter, hvad der skal svares.
TTS (tekst-til-tale) tager det svar og omdanner det til talt lyd, som den, der ringer, hører.
Så flowet er grundlæggende: den, der ringer, taler → ASR transskriberer det → LLM genererer et svar → TTS taler det tilbage.
Når nogen er i et opkald, er både ASR- og LLM-systemerne de kritiske systemer, der arbejder i realtid. Og begge kan fejle, blive langsommere eller opføre sig uforudsigeligt. Vi har brug for at kunne stole på, at begge systemer virker, så vi har bygget en opsætning, der konstant overvåger, tager backup og skifter i realtid. Og her er, hvordan de to arbejder sammen, og hvorfor disse opdateringer er vigtige:
Først holder vi øje med forsinkelse (ikke fejl)
Vi stiller konstant ét enkelt spørgsmål: "Følger systemet med i samtalen?" Hvert 0,1 sekund sammenligner vi:
- Hvor meget lyd vi har sendt
- Hvor meget lyd der faktisk er blevet behandlet
Hvis gabet vokser til over 5 sekunder, er det vores signal: Denne udbyder er ved at komme bagud. Ikke død. Ikke i stykker. Men på vej derhen. Og det er dér, vi handler.
Vi holder et live "sikkerhedsnet" af din lyd
Efterhånden som lyd bliver behandlet, holder vi en løbende backup af alt, der endnu ikke er fuldt håndteret. Tænk på det sådan her:
- Hvis systemet bekræfter, at det har behandlet noget → smider vi det væk
- Hvis det ikke har endnu → holder vi fast i det
Så vi har til enhver tid en perfekt kopi af "mellemliggende" lyd, som er den del, der er mest i risiko for at gå tabt. Ingen gætterier. Ingen huller.
Så skifter vi over til en backup
I det øjeblik vi registrerer forsinkelse, venter vi ikke. Vi:
- Starter en backup-udbyder op (der er en prioritetsrækkefølge: hurtigst, tættest på, mest pålidelig først)
- Sender al den "i limbo" lyd over, så den kan indhente det
- Lukker den kæmpende udbyder ned
Vi giver også den nye udbyder en kort tilvænningsperiode (~20 sekunder) til at stabilisere sig, før vi begynder at bedømme dens ydeevne.
Resultatet?
Transskriptionen bare… fortsætter. Intet spring. Ingen tilbagespoling. Ingen mærkelige huller. Fra perspektivet hos den, der ringer, skete der ingenting.
Hvorfor dette er vigtigt
De fleste systemer venter, til en udbyder er fuldstændig gået ned, før de skifter.
Det gør vi ikke. Vi fanger øjeblikket, hvor den begynder at kæmpe, og udskifter den, før den nogensinde bliver et problem.
Konklusion
- Vi venter ikke på fejl
- Vi registrerer opbremsninger i realtid
- Vi bevarer hvert sekund af lyd
- Vi skifter udbydere problemfrit
Så samtalen fortsætter med at flyde præcis, som den skal.
LLM: fra routing på udbyderniveau til implementeringsniveau
Sådan fungerer vores LLM-fallbacks
På svarsiden er fejl ikke så åbenlys. Den er mere subtil. For hver LLM-model (dvs. GPT-4.1) har vi et sæt "deployments", der betjener den model. Tænk på en deployment som et fysisk datacenter. Når vi vil generere et AI-svar—eller hente forankret kontekst fra en LLM Knowledge Graph for at forbedre nøjagtigheden og reducere hallucinationer—skal vi angive en bestemt deployment til at behandle den forespørgsel.
Under motorhjelmen er der et par bevægelige dele, og det kan blive lidt komplekst, men kerneidéen er enkel:
Vi router til deployments, der har lavere latens
Sikrer, at svar genereres hurtigere, og reducerer forsinkelse for at holde samtaler synkroniseret i realtid.
Vi måler & overvåger konstant fejlraten for hver deployment
Og vi skærer trafikken til dem, der har høje fejlrater.
Vi har brug for fart, når vi sender en forespørgsel til en deployment
Hvis den er langsom, venter vi ikke. Vi sender forespørgslen et andet sted hen og fortsætter, indtil en svarer.
Må den bedste AI-model vinde
Hvis en model fejler på tværs af flere deployments, bliver vi ikke ved med at prøve den. Vi skifter til en anden og fortsætter.
Konklusion
Vi er ikke afhængige af én model eller én udbyder.
Vi:
- router konstant til den bedste mulighed
- undgår det, der fejler
- kapløber om hurtigere svar
- og skifter, når det er nødvendigt
Så selv når systemer har en dårlig dag, gør dine samtaler ikke.
.avif)
