Echtzeit-Sprache vs. Batch — ein Telefon-KI-Agent ist kein Chatbot

Wenn Ihnen ein Anbieter einen „Telefon-KI-Agenten“ anpreist, stellen Sie ihm eine Frage: „Wie hoch ist Ihre Ende-zu-Ende-Latenz zwischen dem Ende der Nutzeräußerung und dem Beginn der Antwort?“

Übersteigt die Antwort 1,5 Sekunden, ist es kein Telefonagent. Es ist ein Chatbot mit einem vorne angeklebten ASR-/TTS-Modul.

Die 800-ms-Regel

Ein Mensch am Telefon toleriert Stille nach seiner Frage. Aber diese Stille hat eine Schwelle: Ab 800 ms fühlt sich die Gegenseite „eingefroren“ an. Bei 1.500 ms sagt der Anrufer „Hallo?“. Bei 3.000 ms legt er auf und vermutet ein Leitungsproblem.

Das Ziel für einen ernstzunehmenden Sprachagenten lautet daher: unter 800 ms zwischen dem Ende der Äußerung und dem ersten hörbaren Byte der Antwort.

Schlüsseln wir es auf.

Das Zeitbudget im Detail

[user speech]──▶[ASR streaming]──▶[LLM]──▶[TTS streaming]──▶[audio out]
      ~150ms          ~80ms        ~?       ~250ms             ~50ms

Von den verfügbaren ~800 ms werden etwa 270 ms von ASR + TTS + Transport verbraucht. Es bleiben 530 ms für das LLM — einschließlich Prefill-Zeit, Reasoning und Generierung des ersten Tokens.

Auswirkungen:

• GPT-4 Turbo ohne Streaming: ~2.000 ms, um eine Antwort mit 200 Tokens zu generieren. Ausgeschlossen.
• GPT-4o Streaming: ~400 ms bis zum ersten Token an guten Tagen, ~800 ms an schlechten. Akzeptabel, aber knapp.
• Claude Haiku Streaming: ~250 ms bis zum ersten Token. Komfortabel.
• Llama 3 8B, bedient von vLLM: ~150 ms bis zum ersten Token. Exzellent (und privat).

Eine ernstzunehmende Spracharchitektur erfordert daher:

1. Alles ist Streaming — ASR, LLM, TTS. Nicht ein einziges Glied im Batch-Modus.
2. Das LLM-Modell wird nach TTFT ausgewählt (Time to First Token), nicht nach MMLU-Score.
3. TTS beginnt beim ersten empfangenen Token zu sprechen, nicht nachdem die vollständige Antwort fertig ist.

Barge-in

Auf einem Textkanal wartet der Nutzer, bis der Bot fertig ist. Am Telefon unterbricht er — drei von fünf Malen in natürlichen Gesprächen.

Ein Sprachagent, der es nicht verträgt, unterbrochen zu werden, wirkt „robotisch“ — er redet weiter, während der Nutzer versucht zu unterbrechen. Das ist unerträglich und signalisiert sofort einen schlecht gebauten Bot.

Technisches Barge-in erfordert:

• TTS stoppt sofort, wenn das ASR ein ausgehendes Sprachsignal des Nutzers erkennt.
• Das LLM verwirft die laufende Completion (ohne zu murren).
• Der ausgehende Audiopuffer wird sofort geleert (andernfalls ist eine restliche Halbsilbe hörbar).
• Der Gesprächsverlauf notiert, dass die Antwort nicht vollständig gehört wurde — um ein versehentliches Wiederholen zu vermeiden.

Es ist ein technisches Detail, das alles daran ändert, wie sich die Interaktion anfühlt.

Umgang mit Unsicherheit

Am Telefon macht das ASR regelmäßig Fehler. Wo ein Text-Chatbot stets den exakt vom Nutzer getippten Text erhält, empfängt der Sprachagent eine häufig unvollkommene Transkription.

Strategien, die funktionieren:

• Bestätigung anfordern bei folgenreichen Elementen (Aktenzeichen, Betrag, ungewöhnlicher Nachname). Nicht systematisch — das wird unerträglich.
• Dem LLM nicht blind vertrauen, wenn das ASR mehrdeutig ist. Lautet der empfangene Satz „Ich möchte meinen Vertrag kündigen“ mit einem niedrigen Konfidenz-Score, ist es besser zu fragen „Meinten Sie, Ihren Vertrag kündigen?“, als das Kündigungsverfahren auszulösen.
• Entgleisungen unterbinden — ein Agent, der vom Skript abweicht, sollte durch einen Bedingungs-/Operatorknoten zurückgeholt werden, nicht durch einen Prompt, der „eigentlich genügen sollte“.

Das Telefon ist ebenfalls ein Stack

Über die KI hinaus erfordert ein Telefonagent:

• Einen SIP-Trunk von einem Carrier (Twilio, Voxbone, OVH, Sewan…).
• Ein Media-Gateway (LiveKit-SIP, FreeSWITCH, Asterisk), das auf der Carrier-Seite SIP und auf der Plattformseite WebRTC spricht.
• Einen Transkribierer, der gegen Rauschen, Akzente und überlappende Stimmen robust ist.
• Einen Synthesizer, der Eigennamen, Zahlen und Daten korrekt ausspricht.

Keines dieser Elemente ist trivial. Alle interagieren miteinander.

Was betool übernimmt

Die Spracharchitektur von betool — LiveKit + LiveKit-SIP + dedizierter Worker + kaskadiertes LLM-Streaming — deckt die obigen Anforderungen out of the box ab. Sie behalten die Kontrolle über:

• Den SIP-Trunk (Ihr Carrier, Ihre Nummern).
• Die Modelle (BYOK oder private Modelle).
• Die Parameter (Ziellatenz, Aggressivität des Barge-in, Fallback auf eine menschliche Stimme).

Sie konfigurieren nicht die Echtzeit-Klempnerei — das ist Aufgabe der Plattform. Sie gestalten das Gespräch, was die eigentliche geschäftliche Herausforderung ist.