Eine Echtzeit-Sprachpipeline aufbauen: vom Roh-Audio zur KI-Antwort
Das Herzstück von TAMSIV ist die Stimme. Kein Gadget – die Stimme IST die Hauptschnittstelle. Eine Echtzeit-Sprachpipeline im Alleingang aufzubauen, bedeutet, in eine Welt einzutreten, in der jede Millisekunde zählt.
Die Architektur der Pipeline
Audio PCM 16kHz mono → WebSocket (JWT) → Deepgram Live STT (VAD) → OpenRouter LLM → Function calling → OpenAI TTS → Audio responseDas Audio muss in PCM 16 Bit, 16kHz, mono sein. Das Telefon sendet rohe binäre Chunks über WebSocket.
Der authentifizierte WebSocket
JWT Supabase Token im Query String: ws://backend:3001?token=eyJhbG.... Validierung bei der Verbindung. Wenn der Token während eines Gesprächs abläuft, automatische Wiederverbindung mit einem frischen Token.
Deepgram Live STT und VAD
Die VAD (Voice Activity Detection) von Deepgram erkennt, wann der Benutzer aufgehört hat zu sprechen. Ohne VAD bräuchte man ein Silence-Timeout auf Client-Seite – zu kurz schneidet ab, zu lang verzögert. Deepgram verwaltet dies präzise.
Die Schwierigkeit: Umgang mit Zwischenergebnissen (is_final: false) vs. Endergebnissen (is_final: true). Man muss die Endergebnisse akkumulieren, um die vollständige Transkription zu erstellen.
Die LLM-Orchestrierung
Die Transkription geht an OpenRouter mit Function Calling. Das Modell ist konfigurierbar mit automatischem Fallback. Die Gesamt-Latenz: STT-Finalisierung (~200ms) + LLM (~800ms-2s) + TTS (~500ms). Zwischen 1,5 und 3 Sekunden.
OpenAI TTS
Stimme nova. Das Audio wird über denselben WebSocket zurückgestreamt. Das Frontend beginnt mit der Wiedergabe der ersten Chunks, ohne auf die vollständige Antwort zu warten.
Die Lehren aus der Echtzeit
Alles kann jederzeit fehlschlagen. Intelligente Retries, Circuit Breaker, Fallbacks in jedem Schritt. Die Pipeline ist heute robust, aber jede Zeile der Fehlerbehandlung repräsentiert einen erlebten Bug.