Die Anatomie eines Voice-AI-Calls

Die Frage

Warum spricht ein KI-Telefonassistentflüssig — oder eben nicht? Warum hat der eine diese typische "Denkpause" von zwei Sekunden, während der andere antwortet, als wäre ein Mensch am Apparat?

Die intuitive Antwort — "bessere KI" — greift zu kurz. Es liegt an der Architektur. An der Entscheidung, ob Audio durch eine Kette aus drei separaten Diensten geschickt wird — oder ob ein einziges Modell Audio nativ versteht und nativ antwortet. Und genau deshalb haben wir Sontor von Grund auf anders gebaut.

Die Architektur entscheidet darüber, ob ein Anrufer Vertrauen fasst oder auflegt. Die Psycholinguistik-Forschung am Max-Planck-Institut zeigt: Im natürlichen Gespräch erwarten wir eine Reaktion in etwa 200 Millisekunden. Nicht weil wir ungeduldig sind, sondern weil unser Gehirn das Ende eines Satzes vorhersagt und die eigene Antwort bereits plant, bevor der andere fertig gesprochen hat (Stivers et al., 2009).

Wenn ein KI-Telefonassistent zwei Sekunden braucht, registriert der Anrufer — bewusst oder unbewusst — eine Störung. Das Gespräch fühlt sich falsch an. Die Konversion bricht ein.

Um zu verstehen, warum das so ist und wie man es vermeidet, muss man unter die Haube schauen.

Was unter der Haube passiert

Die kaskadierende Pipeline

Fragt man Anbieter, wie ihr Voicebot funktioniert, bekommt man fast immer dieselbe Antwort. Eine Kette aus drei Bausteinen:

1. Speech-to-Text (STT): Der Anrufer spricht, eine Engine wandelt das Audio in Text.
2. LLM: Der Text geht an ein Sprachmodell, das eine Textantwort generiert.
3. Text-to-Speech (TTS): Ein dritter Service liest die Antwort vor.

Das klingt logisch. Und es war jahrelang der einzige Weg. Aber diese Pipeline hat ein physikalisches Problem, das sich nicht wegoptimieren lässt: Die Latenz ist additiv.

Das STT-Modul muss warten, bis der Mensch seinen Satz beendet hat — die sogenannte "Time to Final Segment" (TTFS). Dann braucht das LLM Zeit zum Denken — "Time to First Token" (TTFT). Und am Ende muss die TTS-Engine den generierten Text in Audio umwandeln — "Time to First Byte" (TTFB). Dazwischen: Netzwerk-Handshakes, Warteschlangen, Serialisierung. Benchmarks von Deepgram (2024) zeigen, dass diese Kette selten unter 1,2 Sekunden kommt. Bei komplexeren Antworten eher 1,5 bis 2 Sekunden.

Das ist sechs- bis zehnmal langsamer als das, was ein Mensch im Gespräch erwartet.

Der Sontor-Ansatz: Audio-nativ

Die nächste Generation Sprachmodelle — und die Architektur, die Sontor verwendet — funktioniert grundlegend anders. Es gibt keinen Text-Umweg mehr auf dem kritischen Pfad.

Moderne multimodale Modelle können Audio direkt verarbeiten. Ton rein, Ton raus. Native Speech-to-Speech. Die OpenAI Realtime API ist ein Beispiel dafür: Statt drei separate Services zu orchestrieren, öffnet man eine einzige persistente WebSocket-Verbindung. Das Audio des Anrufers wird in Echtzeit gestreamt, das Modell antwortet in Echtzeit mit Audio.

Das Entscheidende: Es gibt kein Speech-to-Text-Modul mehr, das die Antwort blockiert. Die Transkription — also die Frage "Was wurde eigentlich gesagt?" — läuft asynchron im Hintergrund. Sie dient ausschließlich der Dokumentation: Datenbank-Logs, E-Mail-Zusammenfassungen nach dem Anruf. Sie steht niemals auf dem kritischen Pfad.

Was die meisten übersehen

Hier ist meine kontroverse These, die nur entsteht, wenn man diese Systeme selbst baut:

Die meisten Anbieter optimieren die falschen Komponenten.

Ich beobachte regelmäßig, wie Teams versuchen, die Latenz ihrer STT→LLM→TTS-Pipeline durch ein schnelleres Whisper-Modell oder eine optimierte TTS-Engine zu senken. 50 Millisekunden hier, 80 dort. Das ist Symptombekämpfung.

Wenn die grundlegende Architektur drei sequenzielle Netzwerk-Roundtrips erfordert, kann man jede einzelne Komponente optimieren und kommt trotzdem nicht unter 800ms. Das Problem ist nicht die Geschwindigkeit der Teile — sondern dass es drei Teile sind.

Die eigentliche Stellschraube sitzt eine Ebene tiefer: der Transport-Layer.Die Entscheidung zwischen HTTP-Request-Response (bei dem jede Frage eine neue Verbindung aufbaut) und einer persistenten WebSocket-Verbindung (bei der der Audio-Stream durchgehend fließt) macht den Unterschied zwischen "fühlt sich wie ein Gespräch an" und "fühlt sich wie eine Hotline aus den 90ern an".

In Sontor messen wir die Latenz exakt: die Zeit zwischen dem Moment, in dem der Anrufer aufhört zu sprechen, und dem ersten Audio-Byte der Antwort. Diese Metrik — Time to First Voice — ist der einzige KPI, der wirklich zählt. Und sie ist nur dann niedrig genug, wenn der Transportweg stimmt.

Drei Fehler, die ich immer wieder sehe

Aus der Erfahrung, diese Systeme selbst aufzubauen und zu betreiben, sind mir drei Muster aufgefallen, die erstaunlich häufig vorkommen:

Fünf Fragen an Ihren Anbieter

Wer vor der Entscheidung steht, einen KI-Telefonassistenten einzuführen, sollte nicht auf Feature-Listen schauen. Stellen Sie stattdessen diese fünf Architektur-Fragen:

Fazit

Die alte Architektur — Sprache abtippen, in Text verwandeln, Text durch ein Modell jagen, Text wieder vorlesen — hat ihren Zenit überschritten. Sie funktioniert, aber sie funktioniert zu langsam für echte Telefonate.

Die nächste Generation eliminiert den Text-Umweg: Audio rein, Audio raus. Über persistente Verbindungen, die den Stream nie abreißen lassen. Das ist kein theoretischer Vorteil — es ist der Unterschied zwischen einem Anrufer, der dranbleibt, und einem, der auflegt.

Wer KI-Telefonassistenten evaluiert, sollte nicht nach Features fragen, sondern nach Architektur. Die Latenz ist keine Nebensache. Sie ist das Fundament.