PROJEKTEINBLICK ·
Wann beginnt eine Antwort wirklich?
In Teil 2 hatte ich die langen Pausen meines Assistenten mit Streaming und einem vorbereiteten Whisper-Server verkürzt. Mit der Weboberfläche kamen weitere Schritte hinzu. Ein schneller Modellaufruf allein sagte mir jetzt noch weniger darüber, wann ich die Antwort tatsächlich hören würde.
Ich konnte auf einen Mikrofonknopf klicken, sprechen und auf die Antwort warten. Hinter diesem scheinbar einfachen Vorgang lagen aber mehrere Übergänge: Aufnahme oder Browser-Erkennung, Textübertragung, Routing, Modellantwort, Spracherzeugung und schließlich Wiedergabe im Browser.
Jeder einzelne Abschnitt konnte funktionieren, während sich das Gespräch insgesamt trotzdem zäh anfühlte. Genau diese Erfahrung kannte ich schon aus den ersten Sprachversuchen. Die Weboberfläche gab ihr weitere Stellen, an denen ich genauer hinsehen musste.
Der Klick sollte sofort etwas auslösen
Beim Mikrofonknopf begann die Wahrnehmung von Geschwindigkeit schon vor meiner eigentlichen Frage. Ich wollte erkennen können, dass der Assistent jetzt zuhörte. Wenn nach dem Klick erst andere Prüfungen liefen, entstand bereits hier eine Pause.
Für den schnellen Browserweg wurde deshalb ein klarer Ablauf festgehalten. Die Spracherkennung startet unmittelbar aus dem Klick. Der Bestätigungston läuft parallel. Während ich spreche, kann ein vorläufiger Text im Eingabefeld erscheinen.
Dieser vorläufige Text ist aber noch kein fertiger Auftrag. Erst wenn das Transkript vollständig final ist, wird es weitergesendet. Ein Klick soll zu einer Eingabe und einer Antwort führen.
- Erkennung direkt mit dem Mikrofonklick starten.
- Den Ton parallel abspielen, statt darauf zu warten.
- Vorläufigen Text anzeigen, aber noch nicht absenden.
- Das fertige Transkript einmal an die Anwendung übergeben.
- Nach der Antwort oder einem Abbruch wieder bereit sein.
Es ging also auch darum, unnötige Arbeit aus diesem Weg herauszuhalten. Eine zusätzliche Modellkorrektur des Transkripts konnte einen weiteren Aufruf bedeuten. Zwei gleichzeitig gestartete Aufnahmewege konnten aus einer Eingabe mehr als einen Vorgang machen.
Zwei Wege dürfen sich nicht in die Quere kommen
Der schnelle Webpfad verwendete die Spracherkennung des Browsers. Lokales Whisper blieb als eigener, wählbarer Weg vorhanden. Die beiden sollten nicht unbemerkt gleichzeitig für denselben Mikrofonklick arbeiten.
Damit änderte sich auch eine wichtige Eigenschaft gegenüber dem frühen Aufbau. Browser-Spracherkennung ist ein anderer Dienst als mein lokaler Whisper-Server. Aus der Tatsache, dass mein Sprachmodell lokal läuft, folgt keine Offline-Zusage für die gesamte Browser-Erkennung.
Diese Unterscheidung musste im Ablauf klar bleiben. Sonst konnte eine gut gemeinte Erweiterung die direkte Bedienung verschlechtern, obwohl jeder Baustein für sich sinnvoll wirkte.
Die richtige Zahl messen
Auch bei den Messwerten musste ich genauer unterscheiden. Ein kompletter Gesprächsdurchlauf konnte lange dauern, weil ich lange sprach oder weil die Antwort ausführlich war. Das war etwas anderes als eine lange stille Pause vor dem ersten Wort.
| Messbereich | Was ich damit unterscheiden konnte |
|---|---|
| STT | Zeit für die Umwandlung meiner Sprache in Text |
| ROUTE | Zeit für die Erkennung des passenden Verarbeitungspfads |
| WAIT | Vom finalen Transkript bis zum ersten gestarteten Audio im Browser |
| VOICE | Spracherzeugung und Wiedergabe der Antwort |
| TURN | Der gesamte Vorgang einschließlich Zuhören und Ausgabe |
Für mich begann die gesprochene Antwort erst, wenn ich sie hören konnte.
Der erste Text vom Modell war ein hilfreicher Messpunkt. Bis zur hörbaren Ausgabe fehlten aber noch Schritte: eine geeignete Satzgrenze, die Sprachsynthese, die Übertragung und der Start der Audiowiedergabe.
Deshalb konnte ich nicht einfach einen guten Modellwert nehmen und ihn als Antwortzeit des ganzen Assistenten ausgeben. Die Messung musste zu der Erfahrung passen, die ich verbessern wollte.
Der Cold Start blieb ein eigenes Thema
In den späteren Messungen zeigte sich erneut der Unterschied zwischen einem geladenen Modell und einem echten Neustart des Modells. Warme Antworten konnten serverseitig schnell beginnen. Ein vollständiges Nachladen brauchte wesentlich länger.
Das passte zu der Erfahrung aus der Whisper-Pipeline: Vorbereitung sollte möglichst vor dem Gespräch stattfinden. Auch beim Sprachmodell waren Warm-up und ein kontrollierter Modellwechsel wichtig.
Entscheidend war für mich, wie lange es nach meiner Frage still blieb. Deshalb musste ich im Browser den gesamten Weg bis zur ersten hörbaren Antwort betrachten.
Schnell musste auch verlässlich bleiben
Eine Optimierung half mir wenig, wenn danach doppelte Antworten entstanden oder das Mikrofon beim nächsten Klick nicht mehr bereit war. Der schnellere Ablauf musste ebenso nach einem Fehler, Abbruch oder Verbindungsverlust wieder funktionieren.
Damit ging es bei der Performancearbeit zunehmend um die Übergänge zwischen den Teilen. Ich wollte einen frühen Beginn der Antwort und danach einen sauberen Gesprächsfluss. Einzelne gute Zahlen reichten dafür nicht aus.
Die Regeln für diesen Mikrofonweg wurden deshalb ausdrücklich dokumentiert. Neue Ideen sollten nicht nebenbei den Pfad verändern, den ich gerade erst schneller und berechenbarer gemacht hatte.
