Wenn das Gespräch nicht in Runden läuft

Ein Chatfenster arbeitet in Runden. Sie tippen, drücken Enter, das Modell antwortet, Sie sind wieder dran. Enter ist dabei mehr als eine Taste: Es ist das Zeichen, dass Sie fertig sind.

Im Gespräch gibt es diese Taste nicht. Jemand muss also entscheiden, wann ein Beitrag zu Ende ist, und dieser Jemand ist ein Programm.

Der Schalter davor

Bei OpenAIs Realtime-Schnittstelle und bei Gemini Live heißt das Bauteil Voice Activity Detection, abgekürzt VAD, auf Deutsch Sprach­ak­ti­vi­täts­er­ken­nung. Es sitzt vor dem Modell, hört das Mikrofon ab und schneidet den laufenden Ton in Stücke, die an das Modell gehen. Die einfache Bauart nimmt dafür die Stille: Nach der Doku zur Sprach­ak­ti­vi­täts­er­ken­nung (externe Seite, developers.openai.com) zerlegt sie den Ton selbsttätig an den Pausen.

Das klingt naheliegend und geht oft schief. Menschen machen Pausen mitten im Satz, wenn sie nachdenken, eine Nummer vorlesen oder nach dem richtigen Wort suchen. Für ein Programm, das auf Stille wartet, sieht jede Denkpause aus wie ein Satzende.

Die zweite Bauart hört auf die Wörter

Deshalb gibt es inzwischen eine andere, die den Inhalt heranzieht. OpenAI führt sie als neuen Modus namens Semantic VAD (externe Seite, developers.openai.com): Ein Klassifikator entscheidet anhand der bisher gesprochenen Wörter, ob jemand fertig ist.

Der Maßstab ist damit der angefangene Satz und seine Vollständigkeit. Den Gewinn beschreibt der Anbieter in der Sprache der Vorsicht: Mit diesem Modus fällt das Modell im Gespräch von Stimme zu Stimme seltener ins Wort (externe Seite, developers.openai.com), und es schneidet eine Abschrift seltener ab, bevor jemand ausgeredet hat.

Seltener, das ist das ganze Versprechen. Eine Garantie steht da nicht: Ob jemand fertig geredet hat, weiß im Zweifel nur er selbst.

Beide Bauarten sind Einstellungssache

Die Dokumentation führt für die erste Bauart vier Stellschrauben auf: wie laut es sein muss, wie viel Ton vor dem erkannten Beginn mitgeschickt wird, wie lange die Stille dauern soll, und ob nach dem Ende sofort geantwortet wird. Die zweite kennt stattdessen vier Stufen von zurückhaltend bis vorschnell.

Bei beiden ist die Grenze eine Einstellung, getroffen von jemandem, der die Sprecher nie gehört hat. Wer sie zu eng wählt, baut ein System, das ins Wort fällt; wer sie zu weit wählt, eines, das nach jedem Satz schweigt.

Die dritte Bauart: das Modell hört durchgehend

OpenAI hat mit GPT-Live eine Bauform vorgestellt, in der es dieses Bauteil nicht mehr gibt. Das Modell hört und spricht zugleich, was die Doku zu Sprachagenten (externe Seite, developers.openai.com) Vollduplex nennt.

Die Anwendung schneidet den Ton dann nicht mehr in Beiträge. Die Migra­ti­ons­an­lei­tung (externe Seite, developers.openai.com) für Entwickler, die von der Realtime-Schnittstelle umsteigen, sagt es als Arbeitsanweisung: Den Ton ohne Unterbrechung schicken, GPT-Live entscheidet selbst, wann es spricht, und die bisherigen Aufrufe, mit denen die Anwendung einen Beitrag abschloss oder eine Antwort auslöste, fallen weg.

Die Entscheidung, wann jemand fertig ist, verschwindet dabei nicht. Sie liegt jetzt im Modell, das den Strom zu Ende hört, und nicht mehr in einem Programm davor. Die Seiten zu GPT-Live nennen deshalb weder eine Laut­stär­ke­schwelle noch eine Stilledauer noch einen Vorlauf, und wer die Grenze verschieben will, findet dafür keine Stellschraube. Die zugehörige Meldung hält zudem fest, dass OpenAIs Bericht keine Zahlen zur Antwortzeit gegenüber der Vorgängerfassung nennt.

Die erste und die zweite Bauart gelten damit nicht überall. Sie beschreiben die Realtime-Schnittstelle von OpenAI und Gemini Live, die beide die Erkennung noch führen, aber nicht GPT-Live.

Die offene Verbindung

Der Gegensatz zum Chatfenster liegt in der Verbindung. Statt einer Anfrage mit einer Antwort läuft ein Strom, der offen bleibt, und in dem beide Seiten jederzeit etwas beitragen können. Bei Gemini Live (externe Seite, ai.google.dev) läuft die Erkennung in der Voreinstellung selbsttätig auf einem ununterbrochenen Tonstrom.

Genau deshalb steht dieses Thema in einem eigenen Kapitel, getrennt von der Erkennung in Kapitel 02. Eine offene Verbindung mit beidseitigem Zugriff gibt es auch dort, wo getippt wird, und alle Fragen dieses Kapitels stellen sich dann genauso.

Eine offene Verbindung heißt, dass beide Seiten gleichzeitig etwas tun können. Daraus folgen zwei Aufgaben, die es in einem Chatfenster gar nicht gibt.

Hineinreden

Wer merkt, dass die Antwort in die falsche Richtung läuft, sagt „nein, warte“. Der Fachbegriff dafür ist Barge-in. Wo eine Erkennung vor dem Modell sitzt, entscheidet dieselbe, die vorhin über das Ende eines Beitrags befunden hat, hier über den Anfang eines neuen. Bei Gemini Live (externe Seite, ai.google.dev) ist die Folge eindeutig: Erkennt die Erkennung eine Unterbrechung, wird die laufende Erzeugung abgebrochen und verworfen.

Der angefangene Satz ist damit verloren. Was davon in der Abschrift stehen bleibt, ist eine eigene Frage, und Kapitel 02 zeigt, warum die Abschrift beim durchgehenden Modell ohnehin auf einem eigenen Weg entsteht.

Damit ist die Hälfte der Arbeit getan. Die andere Hälfte steht in derselben Dokumentation an unauffälliger Stelle, nämlich als Kommentar im Codebeispiel zum Feld interrupted: Wenn die Anwendung den Ton selbst abspielt, muss sie an dieser Stelle das Abspielen anhalten und die Warteschlange leeren.

Der Grund ist einfach und wird trotzdem gern übersehen. Ton wird vorausgeschickt, damit er ohne Stocken läuft. Im Moment der Unterbrechung liegt also fertige Sprache beim Empfänger, und die spielt weiter, egal was der Anbieter auf seiner Seite abgebrochen hat. Ein System, das nur auf das Signal reagiert und den eigenen Puffer stehen lässt, redet weiter, solange dort Ton wartet.

Das gilt auch dort, wo gar keine Erkennung mehr vor dem Modell sitzt. OpenAIs Migra­ti­ons­an­lei­tung für GPT-Live (externe Seite, developers.openai.com) weist darauf hin, dass der Player nicht dem Server folgt: Der Server kann mit dem Erzeugen fertig sein, während beim Abspielen noch eine Sekunde Ton in der Warteschlange liegt.

Wie lange der Puffer reicht, hängt vom Aufbau ab, und die eine Sekunde ist OpenAIs Beispiel, keine Obergrenze.

Warum das System sich selbst hört

Sobald ein Lautsprecher und ein Mikrofon im selben Raum stehen, hört das Mikrofon die eigene Ausgabe. Für eine Voice Activity Detection ist das Ton wie jeder andere: Das System unterbricht sich selbst, weil es sich selbst für einen Gesprächspartner hält.

Der Griff dagegen heißt Echo-Unterdrückung, und er ist in der Spezifikation der Aufnahme im Browser (externe Seite, w3.org) beschrieben: Läuft Ton aus dem Lautsprecher, während Mikrofone aufnehmen, ist es oft erwünscht, diesen Ton aus den aufgenommenen Signalen herauszurechnen. Die Spezifikation spricht dabei von einem Versuch.

Daneben stehen dort zwei verwandte Einstellungen, die Pegelregelung und die Rausch­un­ter­drü­ckung, sowie zwei Betriebsarten für die Frage, ob nur der Ton der Gegenseite oder auch der eigene aus dem Signal gerechnet wird.

Bemerkenswert ist, wo diese Beschreibung steht. In den Dokumentationen der Sprach­schnitt­stellen von OpenAI und Google kommt Echo an keiner Stelle vor, auch nicht in den Seiten zu GPT-Live. Ob ein Modell, das ununterbrochen zuhört, die eigene Stimme besser vom Gegenüber trennt als eine Erkennung davor, sagt dort keine. Die Unterdrückung sitzt vor der Schnittstelle, im Browser oder im Gerät, und liegt damit in der Verantwortung dessen, der die Anwendung baut. Wer eine Sprachanwendung testet und dabei Kopfhörer trägt, bemerkt das Problem nie.

Das Latenzbudget

Die spürbare Wartezeit ist eine Summe, und wer sie senken will, muss wissen, welche Posten darin stehen.

Der zweite Posten ist der, den man am ehesten übersieht, weil er nach Wartezeit gar nicht aussieht. Er ist trotzdem der einzige mit einer belegten Untergrenze. Wer bei Gemini Live die Erkennung selbst übernimmt, bekommt von Google (externe Seite, ai.google.dev) eine Zahl genannt: Damit die Tonqualität erhalten bleibt, soll die eigene Erkennung erst nach mindestens 500 Millisekunden Stille ein Redeende melden.

Eine halbe Sekunde, bevor irgendetwas anderes beginnt. Der Satz gilt für den Fall, dass die Anwendung selbst erkennt; für die eingebaute Erkennung nennt die Doku gar keine Zahl. In beiden Fällen ist diese Zeit der Preis dafür, dass niemandem ins Wort gefallen wird.

Die Tabelle beschreibt eine Bauform mit eigener Erkennung vor dem Modell. Bei GPT-Live gibt es den zweiten Posten nicht mehr als eigenen Schritt, denn kein Bauteil wartet dort auf das Ende des Beitrags. Wie viel Zeit das spart, nennt OpenAIs Bericht nach der Meldung nicht. Die halbe Sekunde ist damit ein Wert dieser Bauform.

Die anderen Posten stehen hier ohne Zahlen, und das hat einen Grund: Für sie gibt es keine Herstellerangabe, die man ohne eigene Messung übernehmen könnte. Eine Summe unter diese Tabelle zu schreiben, wäre eine Rechnung aus geratenen Werten.

Bei Gemini Live läuft die Erkennung des Sprecherwechsels standardmäßig beim Anbieter. Sie lässt sich abschalten, und was dann zu tun ist, steht in der Dokumentation (externe Seite, ai.google.dev) ausdrücklich: Die Anwendung erkennt selbst, wann gesprochen wird, und schickt zur rechten Zeit zwei Signale, activityStart für den Anfang und activityEnd für das Ende eines Beitrags. Das klingt nach einer kleinen Verlagerung und ist in Wahrheit die Übernahme einer Aufgabe, die vorher jemand anders gelöst hat.

Was dabei wegfällt

Die Doku führt die Folgen in einem eigenen Abschnitt auf, und beide sind unangenehm. Die erste: Es gibt keinen Vorlauf mehr (externe Seite, ai.google.dev), der Server setzt keinen Ton mehr vor den erkannten Sprechbeginn.

Die eingebaute Erkennung schickt etwas Ton vor dem erkannten Beginn mit. Der Grund ist die Natur der Sache: Bis ein Verfahren merkt, dass jemand angefangen hat zu sprechen, ist die erste Silbe schon vorbei. Wer die Erkennung selbst übernimmt, muss diesen Vorlauf selbst mitschicken, sonst fehlt bei jeder Äußerung der Anfang. Aus „Termin verschieben“ wird „min verschieben“.

Die zweite Folge: Es gibt keine Nachsicht mehr bei Stille (externe Seite, ai.google.dev), der Server handelt auf das Signal activityEnd sofort und wartet nicht zusätzlich.

Das Ende-Signal wird also wörtlich genommen. Eine Nachdenkpause mitten im Satz beendet damit den Beitrag, wenn die eigene Erkennung sie für Stille hält, und die Antwort kommt auf einen halben Satz. Deshalb steht auf derselben Seite die Untergrenze von 500 Millisekunden, die in Tiefe 2 steht.

Daraus folgt eine klare Bedingung für diese Bauentscheidung. Die eigene Erkennung lohnt sich, wenn die Grenzen von woanders herkommen und dort sicher sind: eine Taste zum Sprechen, ein Kanal, der die Beiträge schon getrennt liefert, eine Aufnahme, die abschnittsweise eintrifft. Sie lohnt sich nicht, wenn man dabei nur dieselbe Aufgabe noch einmal lösen will.

Wenn es die Erkennung nicht mehr gibt

Bei GPT-Live stellt sich die Frage anders. Dort gibt es keine Erkennung, die man abschalten und selbst übernehmen könnte. Die Migra­ti­ons­an­lei­tung (externe Seite, developers.openai.com) verlangt das Gegenteil dessen, was oben steht: den Ton ohne Unterbrechung schicken, GPT-Live entscheiden lassen, wann es spricht, und die Aufrufe streichen, mit denen die Anwendung bisher einen Beitrag abschloss oder eine Antwort auslöste.

Die Anwendung schickt nur noch den Ton und meldet weder Anfang noch Ende. Damit entfallen auch die beiden Folgen von oben. Ein Vorlauf vor dem erkannten Beginn ist nicht nötig, wo nichts den Beginn erkennen muss, und eine Nachsicht am Ende kann niemand einstellen, wo kein Ende-Signal abgeschickt wird. Das folgt aus der Bauweise, die Anleitung sagt es nicht in diesen Worten.

Der Gewinn hat eine Rückseite. Die Taste zum Sprechen und der Kanal mit getrennten Beiträgen, die bei der eigenen Erkennung die Bedingung für den Einsatz waren, sind dort keine Hilfe mehr: Die Grenze zieht das Modell, und die Anwendung kann sie nicht festlegen. Wer Beiträge verlässlich getrennt braucht, etwa für eine Abschrift mit Zeitstempeln, muss sich auf das verlassen, was das Modell liefert.

Die Ausgabe

Auf der anderen Seite des Gesprächs steht die Sprachausgabe. Sie wird heute geführt wie ein Modell, also über eine Anweisung in Prosa: Nach der Doku zur Sprachausgabe (externe Seite, developers.openai.com) lassen sich bei gpt-4o-mini-tts Eigenschaften der Sprache per Prompt steuern. Die Doku zählt darunter auf, was dabei gemeint ist: Akzent, Gefühlsspanne, Betonung, Nachahmung, Sprechtempo, Klangfarbe und Flüstern. Die Anweisung dafür ist Prosa, im Beispiel des Anbieters ein einziger Satz („Speak in a cheerful and positive tone“).

Das Modell ist abgekündigt und verschwindet am 06.01.2027. Als Ersatz nennt dieselbe Seite gpt-realtime-2.1-mini über die Realtime-Schnittstelle.

Das ist bequem und hat den bekannten Preis. Eine Anweisung in Prosa wird ausgelegt, sie greift mal mehr und mal weniger, und sie lässt sich nur prüfen, indem man zuhört. Was für Anweisungen an ein Textmodell gilt, gilt hier genauso, siehe Grundkurs, Kapitel 06.

Die Stimme selbst ist bei den durchgehenden Modellen dieselbe wie bei der getrennten Ausgabe. Bei Google können die Modelle mit eigener Tonausgabe (externe Seite, ai.google.dev) jede Stimme benutzen, die es für die Sprachausgabe (TTS) des Anbieters gibt.

Wer die Bauform wechselt, behält also seine Stimme. Das ist keine Selbst­ver­ständ­lich­keit und einer der wenigen Punkte, an denen ein Wechsel zwischen den beiden Bauformen aus Kapitel 02 nichts kostet.

Warum die Ausgabe in Stücken kommen muss

Beides zusammengenommen, das Hineinreden aus Tiefe 2 und die stückweise Übertragung aus Kapitel 01, ergibt eine Anforderung an die Anwendung, die man beim Bau leicht übergeht.

Die Ausgabe muss an jeder Stelle abbrechbar sein. Wer den Ton erst zusammensetzt und dann abspielt, hat beim Abbruch nichts, was er anhalten könnte, und wer ihn stückweise abspielt, muss die Warteschlange kennen und leeren können. Das ist die Stelle, an der eine Sprachanwendung tatsächlich Zustand führt: Was liegt im Puffer, was davon ist schon zu hören, und was wird verworfen, wenn jemand dazwischenredet.

Ein zweiter Punkt kommt hinzu, der selten bedacht wird. Wenn die Ausgabe abgebrochen wird, hat der Nutzer einen Teil gehört, und das Modell weiß nur, dass es unterbrochen wurde. Wie viel angekommen ist, weiß die Anwendung, weil sie den Puffer verwaltet. Ohne diese Angabe wiederholt das System beim nächsten Versuch entweder alles oder setzt an einer Stelle an, die der Nutzer nie gehört hat.

Was dieses Kapitel offen lässt

Ein Punkt fehlt hier bewusst, weil der Beleg fehlt. Es ist ein Vergleich: Wie gut die Entscheidung im Modell gegenüber einer eigenen Erkennung abschneidet. Der Bericht, auf den sich die Meldung stützt, enthält nach ihr keinen Vergleich mit anderen Systemen und keine Zahlen zur Antwortzeit gegenüber der Vorgängerfassung. Ob die Entscheidung im Modell seltener ins Wort fällt als eine eigene Erkennung, ist damit nicht belegt.

Eine zweite Frage gehört in ein anderes Kapitel: wie ein System auseinanderhält, wer von mehreren Anwesenden gerade spricht. Der Fachbegriff dafür ist Diarisierung, und die Frage wird praktisch, sobald ein Gerät in einem Raum mit mehreren Menschen steht. Die Sprach­schnitt­stellen der Anbieter behandeln den Fall am Rande. Wie die Trennverfahren arbeiten und was ihre Fehlerrate misst, steht in KI jenseits der Sprachmodelle, Kapitel 07.