KAI hört zu.
Und antwortet.
Wie aus einem Chatbot ein Gesprächspartner wurde: Architektur, Ideen und Umsetzung des Sprachgesprächs mit KAI, vom Mikrofon bis Gemini Live und zurück.
Ein Kollege am Telefon,
der alle Bedingungen kennt.
Natürlich
Sprechen statt tippen. Nachfragen, ins Wort fallen, Rückbezüge wie „und bei Sturm?“. KAI verhält sich wie ein Mensch am Telefon und überbrückt Wartezeit hörbar.
Verlässlich
Jede fachliche Aussage stammt aus der KAI-Recherche über freigegebene Quellen. Dieselbe Pipeline, derselbe Kundenkontext und dieselbe Abnahme wie im Textchat. Das Sprachmodell erfindet nichts.
Nachvollziehbar
Der Chat schreibt mit: Fragen, entstehende Antworten, Quellen. Nach dem Auflegen bleibt ein normaler, gespeicherter Chatverlauf zum Nachlesen und Weiterarbeiten.
So fühlt es sich an, und das passiert dahinter.
Am Telefon ist Stille der Feind.
So lange dauert eine Recherche. Schnell: einige Sekunden. Vertieft: oft bis zu einer Minute. Schon drei Sekunden Stille wirken am Telefon wie ein Verbindungsabbruch.
„Non-blocking“ Toolcalls
Die Live API dokumentiert behavior: NON_BLOCKING. Das Modell spricht weiter, während ein Werkzeug arbeitet. Genau das, was man braucht.
Gibt es dort nicht.
Die FunctionDeclaration in Vertex kennt das Feld nicht und ignoriert es. Toolcalls blockieren: Das Modell schweigt, bis die Antwort da ist. Die Google-Dokumentation widerspricht sich hier.
Sofort reden. Parallel suchen.
Zwei Rollen, klar getrennt.
Gemini Live: die Stimme
- hört zu, erkennt Sprechpausen
- spricht natürlich, überbrückt Wartezeit
- lässt sich unterbrechen
- versteht Rückbezüge aus dem Chatverlauf
- hat kein Fachwissen
KAI: das Wissen
- dieselbe Pipeline wie der Textchat
- Schnell (RAG), Vertieft (agentisch), Allgemein
- freigegebene Quellen, LAS-Kundenkontext
- Speicherung, Quellenanzeige, Abnahme
- spricht nicht selbst
Vier Systeme, zwei WebSockets, ein Gespräch. Klicken Sie auf eine Komponente.
Eine Frage, Schritt für Schritt.
Bereit
Mit „Weiter“ oder „Abspielen“ läuft eine fachliche Frage im Modus Schnell durch alle beteiligten Komponenten.
Die Höflichkeitsregel: Unterbrechen darf nur der Nutzer.
Echte Gespräche sind unordentlich.
Ins Wort fallen
Gemini erkennt den Barge-in und meldet interrupted. Der Browser stoppt alle geplanten Audioquellen sofort und verwirft nachlaufendes Audio. Echo-Unterdrückung verhindert, dass das Modell sich selbst hört.
Neue Frage schlägt alte
Fragt der Nutzer während der Recherche etwas Neues, bekommt das Modell nur noch das neue Ergebnis. Die alte Recherche läuft für den Chat zu Ende. Keine veralteten Antworten im Ohr.
Doppelter Aufruf
Ruft das Modell KAI ohne neue Nutzereingabe ein zweites Mal auf, startet keine zweite Recherche. KAI beantwortet genau diesen Call mit dem laufenden Ergebnis, sobald es da ist.
Modell bricht ab
Sendet Gemini toolCallCancellation, erscheint das Ergebnis nur im Chat. Das Modell bekommt nichts mehr, das Gespräch bleibt konsistent.
Auflegen mitten drin
Die Antwortgenerierung läuft im Backend entkoppelt weiter und wird gespeichert. Der Chat lädt neu und holt offene Antworten über den vorhandenen Resume-Mechanismus.
Fehler
Scheitert eine Recherche, sagt das Modell nur „Die Bedingungen konnten gerade nicht abgefragt werden.“ Interna bleiben im Log, damit nichts davon vorgelesen wird. Verbindungsabbrüche enden mit klarer Meldung.
Bis zu einer Minute recherchieren, ohne Funkstille.
„Schreib mir eben eine Mail.“ Die Stimme sagt es, der Chat schreibt es.
Vier Takte, mehrere Iterationen bis es rund war.
Was ohne klare Regeln passiert
- Das Modell kündigt erst an und ruft das Werkzeug danach. Das Schreiben startet spät.
- Das Modell behauptet „steht im Chat“, bevor etwas da ist.
- Lange Texte werden komplett vorgelesen.
Wie es gelöst ist
- Eigener System-Prompt für die allgemeine KI mit klarer Reihenfolge
- Tool-Bestätigung als Regieanweisung: „Bestätige nur, dass du die Aufgabe jetzt bearbeitest.“
- Das Live-Modell erhält den vollständigen Text, fasst aber nur zusammen und kann Rückfragen beantworten
- Abgesichert durch einen eigenen Prompt-Test
Gesprochenes ist flüchtig. Der Chat bleibt.
- Eine ID für alles. VoiceResearch erzeugt die Message-ID, die Datenbank speichert unter ihr, der Chat zeigt unter ihr an.
- Gespeichert wie getippt. Frage, Antwort, Quellen und Kundenkontext landen wie bei einer Textfrage in PostgreSQL. Feedback und Chathistorie funktionieren normal.
- Kein doppelter Stream. Gesprächsnachrichten sind als „direkt gestreamt“ markiert, damit der Chat keinen zusätzlichen Resume-Stream öffnet.
- Robust beim Auflegen. Die Generierung läuft im Backend als eigener Task weiter. Danach lädt der Chat neu und übernimmt offene Antworten.
- Gleiches DTO. kai_answer nutzt denselben Mapper wie der Textchat, inklusive Quellen und Kundenkontext-Aufbereitung.
Jede Sekunde in der Pipeline ist hörbar.
| Schritt | Textchat | Voice | Warum |
|---|---|---|---|
| Frage umformulieren (Rewriter) | ja | entfällt | Das Live-Modell stellt bereits eine eigenständige Frage. |
| Folgefragen-Vorschläge | ja | entfällt | Im Gespräch fragt man einfach nach. |
| Quellenfilter (Schnell) | vor der Antwort | nach der Antwort | Antwort sofort ans Modell, gefilterte Quellen kommen als zweites Ergebnis nach. |
| Hinweis „Antworte möglichst kurz“ | nein | als Kontext | Wird vorgelesen; der Hinweis wird nicht als Teil der Frage gespeichert. |
| Speicherung, Quellen, Kundenkontext | ja | ja | Gleiche fachliche Qualität und Nachvollziehbarkeit. |
Die Audio-Strecke: binär, schlank, unterbrechbar.
Gebaut für den Konzernbetrieb.
Token nie in der URL
Browser können beim WebSocket keine Header setzen. Das Keycloak-Token reist als Subprotocol bearer.<jwt>. Der Server bestätigt nur kai.voice.v1, nie das Token.
Prüfung vor dem Accept
Token-Validierung wie bei REST, bevor die Verbindung angenommen wird. Ein Gespräch ist nur im eigenen Chat möglich, sonst Close 1008.
Geheimnisse bleiben am Server
Das KIRA-Token, System-Prompts und die Gesprächslogik liegen im Backend. Der Browser spricht nie direkt mit KIRA oder Google.
Keine Inhalte im Log
Transkripte werden weder geloggt noch im Tracing erfasst. Audio wird nicht gespeichert. Ein Test sichert das ab.
Kundenkontext-Filter
Ohne aktiven Kundenkontext gelangen keine Vertragsdaten aus früheren Chatnachrichten in den Prompt des Live-Modells.
Fehler bleiben generisch
Feste Meldungen an Nutzer und Modell. Die Startnachricht ist vor Validierungs-Logs geschützt (hide_input_in_errors).
Messbar: wie viel Wartezeit überbrückt wurde.
OpenTelemetry → Jaeger. Logs enthalten Ablaufschritte und IDs, aber keine Inhalte. Matomo zählt „Gespräch gestartet“ und „beendet“.
14 Entscheidungen, die das System prägen.
architektur.md
Fertig gebaut. Bereit für den Fachtest.
Ehrliche Grenzen
- Prompttreue (nichts Fachliches ohne KAI) ist gesteuert, nicht technisch erzwungen.
- Nach einem Verbindungsabbruch startet das Gespräch neu; die Chat-Antworten bleiben.
- Modus ist pro Gespräch fest.
- Zwischenstände sind noch allgemein, obwohl KAI den Rechercheschritt kennt.
- Der Client hängt noch nicht in der Trace-Kette.
Nächste Schritte
- Fachliche Bewertung der gesprochenen Antworten auf F durch die Sparten
- Datenschutzfreigabe und Lastbetrachtung für Q und P
- Zwischenstände mit konkretem Rechercheschritt anreichern
- Sitzungsfortsetzung nach Abbruch prüfen
- Ende-zu-Ende-Latenz aus Nutzersicht messen
Gespräch beendet.
Der Chat bleibt.
Drei Ideen tragen KAI Voice: Gesprächsführung und Wissen getrennt, sofort reden und parallel suchen, und ein Chat, der mitschreibt.
architektur.md
kurzfassung.md
voice-architektur.drawio