Das Sprachsystem von Retell funktioniert wie eine Live-Kette mit drei Kernschritten. Und jeder einzelne hängt vom vorherigen Schritt ab.
ASR → LLM → TTS
ASR (automatische Spracherkennung) hört dem Anrufer zu und wandelt dessen Sprache in Text um.
LLM (Sprachmodell) liest diesen Text, versteht, was gesagt wurde, und entscheidet, was geantwortet wird.
TTS (Text-to-Speech) nimmt diese Antwort und wandelt sie in gesprochenes Audio um, das der Anrufer hört.
Der Ablauf ist also im Grunde: Anrufer spricht → ASR transkribiert → LLM generiert eine Antwort → TTS spricht sie aus.
Wenn sich jemand in einem Anruf befindet, sind sowohl das ASR- als auch das LLM-System die kritischen Systeme, die in Echtzeit arbeiten. Und beide können ausfallen, langsamer werden oder sich unvorhersehbar verhalten. Wir müssen uns darauf verlassen können, dass beide Systeme funktionieren, deshalb haben wir eine Konfiguration aufgebaut, die permanent überwacht, sichert und in Echtzeit umschaltet. Und so funktioniert das Zusammenspiel der beiden – und warum diese Aktualisierungen wichtig sind:
Zuerst achten wir auf Verzögerung (nicht auf Ausfall)
Wir stellen ständig eine einfache Frage: „Hält das System mit dem Gespräch Schritt?“ Alle 0,1 Sekunden vergleichen wir:
- Wie viel Audio wir gesendet haben
- Wie viel Audio tatsächlich verarbeitet wurde
Wenn die Lücke über 5 Sekunden wächst, ist das unser Signal: Dieser Anbieter fällt zurück. Nicht tot. Nicht kaputt. Aber auf dem Weg dorthin. Und genau dann handeln wir.
Wir halten ein Live-„Sicherheitsnetz“ Ihres Audios bereit
Während das Audio verarbeitet wird, halten wir ein rollierendes Backup von allem bereit, was noch nicht vollständig bearbeitet wurde. Stellen Sie es sich so vor:
- Wenn das System bestätigt, dass es etwas verarbeitet hat → verwerfen wir es
- Wenn noch nicht → behalten wir es
So haben wir zu jedem Zeitpunkt eine perfekte Kopie des „Zwischen“-Audios, also des Teils, der am stärksten von Verlust bedroht ist. Kein Raten. Keine Lücken.
Dann schalten wir auf ein Backup um
In dem Moment, in dem wir eine Verzögerung erkennen, warten wir nicht ab. Wir:
- Fahren einen Backup-Anbieter hoch (es gibt eine Prioritätsreihenfolge: schnellster, nächstgelegener, zuverlässigster zuerst)
- Senden all das „in der Schwebe“ befindliche Audio, damit es aufholen kann
- Fahren den überlasteten Anbieter herunter
Wir geben dem neuen Anbieter außerdem eine kurze Schonfrist (~20 Sekunden), um sich zu stabilisieren, bevor wir seine Leistung beurteilen.
Das Ergebnis?
Das Transkript läuft einfach … weiter. Kein Sprung. Kein Zurückspulen. Keine merkwürdigen Lücken. Aus Sicht des Anrufers ist nichts passiert.
Warum das wichtig ist
Die meisten Systeme warten, bis ein Anbieter vollständig abstürzt, bevor sie umschalten.
Wir nicht. Wir erkennen den Moment, in dem er anfängt zu straucheln, und ersetzen ihn, bevor er überhaupt zum Problem wird.
Fazit
- Wir warten nicht auf einen Ausfall
- Wir erkennen Verlangsamungen in Echtzeit
- Wir bewahren jede Sekunde Audio
- Wir wechseln Anbieter nahtlos
So läuft das Gespräch genau so weiter, wie es sein sollte.
LLM: von Anbieter-Ebene zu Deployment-Ebene-Routing
So funktionieren unsere LLM-Fallbacks
Auf der Antwortseite ist ein Ausfall nun nicht so offensichtlich. Er ist subtiler. Für jedes LLM-Modell (z. B. GPT-4.1) haben wir eine Reihe von „Deployments“, die dieses Modell bereitstellen. Stellen Sie sich ein Deployment als ein physisches Rechenzentrum vor. Wenn wir eine KI-Antwort generieren wollen – oder fundierten Kontext aus einem LLM Knowledge Graph abrufen wollen, um die Genauigkeit zu verbessern und Halluzinationen zu reduzieren –, müssen wir ein bestimmtes Deployment angeben, das diese Anfrage verarbeitet.
Unter der Haube gibt es einige bewegliche Teile, und es kann etwas komplex werden, aber die Grundidee ist einfach:
Wir leiten an Deployments mit geringerer Latenz weiter
Stellt sicher, dass Antworten schneller generiert werden, und reduziert die Verzögerung, um Gespräche in Echtzeit synchron zu halten.
Wir messen & überwachen ständig die Fehlerrate jedes Deployments
Und wir reduzieren den Traffic zu denjenigen mit hohen Fehlerraten.
Beim Senden einer Anfrage an ein Deployment brauchen wir Geschwindigkeit
Wenn es langsam ist, warten wir nicht. Wir senden die Anfrage an einen anderen Ort und machen weiter, bis eines antwortet.
Möge das beste KI-Modell gewinnen
Wenn ein Modell über mehrere Deployments hinweg ausfällt, versuchen wir es nicht weiter damit. Wir wechseln zu einem anderen und machen weiter.
Fazit
Wir verlassen uns nicht auf ein Modell oder einen Anbieter.
Wir sind ständig dabei:
- an die beste Option weiterzuleiten
- zu vermeiden, was ausfällt
- um schnellere Antworten zu wetteifern
- und bei Bedarf umzuschalten
Selbst wenn Systeme einen schlechten Tag haben, tun es Ihre Gespräche nicht.
.avif)