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

Das Bauteil heißt Voice Activity Detection, abgekürzt VAD, auf Deutsch Sprachaktivitätserkennung. Es 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:

It uses periods of silence to automatically chunk the audio. (externe Seite, developers.openai.com)

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:

Semantic VAD is a new mode that uses a semantic classifier to detect when the user has finished speaking, based on the words they have uttered. (externe Seite, developers.openai.com)

Der Maßstab ist damit der angefangene Satz und seine Vollständigkeit. Den Gewinn beschreibt der Anbieter in der Sprache der Vorsicht:

With this mode, the model is less likely to interrupt the user during a speech-to-speech conversation, or chunk a transcript before the user is done speaking. (externe Seite, developers.openai.com)

Less likely, also seltener. 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.

Das ist die eigentliche Nachricht dieses Abschnitts. Wo ein Beitrag endet, ist 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 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:

By default, the model automatically performs VAD on a continuous audio input stream. (externe Seite, ai.google.dev)

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. Die Erkennung, die vorhin über das Ende eines Beitrags entschieden hat, entscheidet hier über den Anfang eines neuen, und die Folge ist eindeutig:

When VAD detects an interruption, the ongoing generation is canceled and discarded. (externe Seite, ai.google.dev)

Canceled and discarded: Der angefangene Satz wird abgebrochen und weggeworfen. 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 liegen also mehrere Sekunden fertiger Sprache beim Empfänger, und die spielen 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 noch drei Sekunden weiter, nachdem es unterbrochen wurde.

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 die 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 beschrieben:

When one or more audio streams are being played in the processes of various microphones, it is often desirable to attempt to remove sound being played from the input signals recorded by the microphones. (externe Seite, w3.org)

Daneben stehen dort zwei verwandte Einstellungen, die Pegelregelung und die Rauschunterdrü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 Sprachschnittstellen von OpenAI und Google kommt Echo an keiner Stelle vor. 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.

Posten	Was dort passiert
Aufnahme und Weg	Ton wird gepuffert, gepackt und übertragen
Ende des Beitrags	die Erkennung wartet, bis sie „fertig“ sagt
Erkennung	aus Ton wird Text, bei der Kette ein eigener Schritt
Antwort bis zum ersten Wort	das Modell beginnt zu erzeugen
Ausgabe bis zum ersten Ton	die Sprachausgabe setzt an
Rückweg	Übertragung und Abspielpuffer

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 die Erkennung selbst übernimmt, bekommt vom Anbieter eine Zahl genannt:

To preserve audio quality with manual VAD, use an end-of-speech silence threshold of at least 500ms in your client’s voice activity detector. (externe Seite, ai.google.dev)

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 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.

Die Erkennung des Sprecherwechsels läuft standardmäßig beim Anbieter. Sie lässt sich abschalten, und was dann zu tun ist, steht in der Dokumentation ausdrücklich:

In this configuration the client is responsible for detecting user speech and sending activityStart and activityEnd messages at the appropriate times. (externe Seite, ai.google.dev)

Die Anwendung schickt dann selbst zwei Signale, eines für den Anfang und eines 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.

No pre-speech buffer: The server no longer prepends audio before the detected speech start. (externe Seite, ai.google.dev)

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“.

No silence tolerance: The server acts immediately on your activityEnd signal with no additional wait. (externe Seite, ai.google.dev)

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 zitiert ist.

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.

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:

You can prompt the model to control aspects of speech (externe Seite, developers.openai.com)

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 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:

Native audio output models support any of the voices available for our Text-to-Speech (TTS) models. (externe Seite, ai.google.dev)

Wer die Bauform wechselt, behält also seine Stimme. Das ist keine Selbstverständlichkeit 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, und er fehlt, weil der Beleg fehlt: 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 Sprachschnittstellen der Anbieter behandeln den Fall am Rande. Belastbar beschrieben ist er in den Modellkarten der Trennverfahren, und die gehören in ein eigenes Kapitel. Hier steht er als Lücke, damit die Aufzählung oben nicht so aussieht, als wäre sie vollständig.