Der Weg zur fast perfekten Spracherkennung

Vor zwei Wochen habe ich beschrieben, warum ich meine Spracherkennung selbst gebaut habe. Der Artikel endete damit, dass „sah einfach aus“ nur für den ersten Nachmittag stimmte und die Probleme danach interessanter waren als der Aufbau. Das ist dieser Artikel.

Offen geblieben waren damals diese drei Probleme:

• verschluckte Wortenden, die sich tagelang nicht reproduzieren ließen
• Wartezeiten zwischen vier und siebzehn Sekunden, ohne Zusammenhang zur Textlänge
• ein Diktat, das vollständig durch einen chinesischen Satz ersetzt wurde

Dazu kam ein vierter Fehler, den ich damals noch gar nicht bemerkt hatte: Das erste Wort fehlte.

Gekostet hat mich das alles etwa fünf Stunden, grob geschätzt, weil ich nie am Stück daran saß. Es lief eher so: diktieren, etwas fällt auf, Bescheid sagen, weiterarbeiten, später wieder testen. Die Arbeitsteilung war die ganze Zeit dieselbe. Ich habe gemerkt, dass etwas nicht stimmt, und Claude hat gemessen und repariert.

Erst messen, dann aufhören zu raten

Etwa jedes fünfte Diktat verlor sein letztes Wort, und ich konnte es nie absichtlich auslösen. Claude hat zwei Ursachen gefunden, beide am Ende der Aufnahme: Das Aufnahmeprogramm wirft beim Abbruch den zuletzt angefangenen Puffer weg, und der voreingestellte Audiotreiber liefert obendrein mit rund zwei Sekunden Verzögerung, sodass alles noch Unterwegs verloren ging. Eine höhere Abtastrate und ein anderer Treiber haben beides erledigt.

Ein Fehlschluss gehört hier dazu, und der kam von Claude. Nach einer einzelnen Messung schlug es vor, den Sicherheitspuffer am Ende deutlich zu verkürzen, weil der Verlust ja nur 60 Millisekunden betrage. Der Verlust ist aber eine Zufallsgröße, und eine einzelne Messung sagt darüber nichts. Umgesetzt hätte der Vorschlag die Ausfallrate von 22 auf 80 Prozent gehoben. Aufgefallen ist das beim Nachrechnen, nicht im Betrieb.

Bei der Wartezeit war die Reihenfolge dann richtig herum. Statt zu raten hat Claude zuerst eine Zeitmessung ins Log gebaut, die die Wartezeit in ihre Abschnitte zerlegt, und die räumte sofort mit meiner Vermutung auf. Die Spracherkennung war nie das Problem, die lag stabil unter anderthalb Sekunden. Der Ausreißer war die automatische Textkorrektur mit 1,0 bis 13,2 Sekunden, ohne jeden Bezug zur Textlänge.

Dahinter steckten zwei Sachen übereinander, und beide fand ich lehrreicher als den eigentlichen Fehler. Das Modell dachte vor der Antwort unsichtbar nach und verbrauchte für eine Zeichensetzungskorrektur 284 von 330 Tokens auf dieses Nachdenken. Erst als das abgeschaltet war, wurde die zweite Ursache sichtbar: OpenRouter verteilt Anfragen auf verschiedene Anbieter, und identische Anfragen brauchten bei einem 2,5 Sekunden und bei einem anderen 36,6. Seit die Anbieterwahl nach Durchsatz sortiert ist, liegt die Korrektur stabil bei gut zwei Sekunden.

Wo Messen nicht mehr weiterhalf

Der chinesische Satz war ein anderer Fall. Wenn ein Diktat mit einer Frage endet, die an einen Assistenten gerichtet klingt, dann antwortet das Korrekturmodell in etwa jedem fünften Fall darauf, statt den Text zu putzen. Ein Anbieter tat das mit einem vorgefertigten chinesischen „Zu dieser Frage habe ich keine Informationen“ und löschte damit mein komplettes deutsches Diktat.

Den Prompt umzuformulieren half nicht messbar, und eine Zahl, die auf eine Ursache zeigt, gab es hier nicht. Die Lösung war deshalb, der Ausgabe zu misstrauen statt die Eingabe zu verbessern. Eine echte Korrektur bleibt bei 97 bis 103 Prozent der Rohlänge, alles außerhalb von 60 bis 160 Prozent wird verworfen und das unkorrigierte Transkript gewinnt. Der chinesische Fall lag bei 17 Prozent.

Das war der wichtigere der beiden Fehler, obwohl er seltener auftrat. Ein fehlendes letztes Wort sieht man sofort, und ich habe es jedes Mal gemeldet. Ein ersetztes Transkript sieht aus wie ein fertiger Satz.

Das fehlende erste Wort, und ein Rückschritt

Beim vierten Fehler ging es zwischendurch in die falsche Richtung. Die Ursache war schnell klar: Die Meldung „Aufnahme läuft“ kam, sobald das Aufnahmeprogramm gestartet war, und das ist nicht der Moment, in dem es aufnimmt. Ich sprach los, während noch nichts ankam, und „Wir sind alle nur Menschen“ wurde zu „Alle nur Menschen“.

Gebraucht wurde also ein Signal, das echte Bereitschaft meldet, und davon hat Claude drei ausprobiert. Der erste ging nach hinten los: Er schloss von der Größe der Aufnahmedatei darauf, ob schon Ton ankommt. In einem stillen Zimmer dauerte das über drei Sekunden, weil Stille sich hervorragend komprimieren lässt, und ich bekam eine Fehlermeldung, obwohl die Aufnahme einwandfrei lief.

Der Witz daran: Schuld war eine Optimierung, die zwei Tage vorher sauber funktioniert hatte. Ich war von WAV auf Ogg umgestiegen, weil acht Sekunden Sprache als WAV 258 Kilobyte groß sind und als Ogg 42, bei zeichengleichem Transkript. Das war nicht mal Selbstzweck, sondern die Voraussetzung für die höhere Abtastrate, die das abgeschnittene Ende reparierte. Genau diese Kompression machte die Dateigröße als Signal unbrauchbar.

Der zweite Versuch scheiterte an PipeWire, der dritte fragt jetzt PipeWire direkt, ob mein Mikrofon tatsächlich läuft. Seitdem stimmt der Moment, in dem das Popup erscheint.

Frustrierend war das schon, vor allem an dem Abend, an dem das Wort immer noch fehlte, obwohl ich extra auf das Popup gewartet hatte. Aber das gehört zu einer Eigenentwicklung dazu.

Eigene Benchmarks, und warum sie fast nichts genützt hätten

Was ich unterschätzt hatte: Ohne eigene Messungen kommt man hier nicht aus. Fremde Benchmarks beantworten nicht, welches Modell meine deutschen Diktate mit meinem Prompt zu meinen Kosten am besten aufräumt.

Die Testdaten waren dabei je nach Frage unterschiedlich. Wo dieselbe Eingabe zwanzigmal identisch durch die Kette musste, kamen synthetische Sätze aus einem Sprachsynthesizer zum Einsatz. Wo es auf die Verteilung echter Fehler ankam, war mein Debug-Log die Quelle. Die Vokabelliste ist deshalb nicht geraten, sie entstand aus der Differenz zwischen Rohtext und korrigiertem Text über 80 geloggte Diktate. Dabei kam heraus, dass „Claude“ neunmal als „Cloud“ ankam und nur siebenmal richtig.

Nur hat das Ergebnis dieser Messungen den Alltag nie erreicht, und das ist mir erst viel später aufgefallen. Ich hatte zwei Modelle eingestellt und dachte, beide seien aktiv. Tatsächlich lagen sie auf verschiedenen Ebenen: das Spracherkennungsmodell deklarativ in meiner NixOS-Konfiguration, das Korrekturmodell nur als Umgebungsvariable in meiner Shell. Den Tastenkürzel-Aufruf startet Hyprland aus der Sitzung, die diese Variable nie gesehen hat. Beim Diktieren lief also weiter das alte Korrekturmodell, während ich das neue für gemessen und entschieden hielt. Aufgefallen ist das erst, als 82 Log-Einträge ausnahmslos das alte zeigten.

Das ist ein NixOS-Problem, das eigentlich keins sein sollte. Der Sinn einer deklarativen Konfiguration ist ja, dass der laufende Zustand im Repo steht. Ausgerechnet die bequemste der drei Ebenen tut aber gar nichts, wenn man sie am falschen Ort setzt, und sagt einem das auch nicht. Inzwischen stehen beide Modelle in der Konfiguration, und ein fehlender Eintrag lässt den Build abbrechen. Sauber messen reicht eben nicht, wenn das Ergebnis danach nicht dort ankommt, wo gearbeitet wird.

Was es im Alltag kostet

Voxtral kostet rund 0,18 Dollar pro Stunde Audio und damit etwa dreimal so viel wie Whisper large-v3-turbo. Was das praktisch bedeutet, habe ich jetzt eine Woche lang gezielt ausprobiert, ohne es zu übertreiben: vom 3. bis zum 9. August 88 Anfragen an die API, also gut 40 Diktate, zusammen 25.000 Token. Gekostet hat mich das 9 US-Cent.

In Teil 1 stehen 0,181 Dollar für die erste Woche und die Vermutung, die Rechnung werde steigen, weil die Textkorrektur inzwischen über ein teureres Modell lief. Sie ist stattdessen gefallen, und der Grund ist banal: Die erste Woche war keine normale. Da haben wir viel ausprobiert und ich habe bewusst mehr gesprochen, als ich es sonst tue. Die 9 Cent sind die ehrlichere Zahl für den tatsächlichen Gebrauch.

Die Abrechnung zeigt nebenbei, wie ungleich sich das verteilt. Beide Modelle bekommen ungefähr gleich viele Anfragen, aber im Kostendiagramm ist die Textkorrektur nur ein Strich am unteren Rand. Die Spracherkennung frisst rund 90 Prozent.

Interessanter als die Frage, welches der beiden Modelle teurer ist, finde ich das Verhältnis zum Rest. Wenn ich so weitermache, sind das hochgerechnet keine fünf Dollar im Jahr, Spracherkennung und Nachbearbeitung zusammen. Hardware, die das lokal könnte, liegt in einer völlig anderen Größenordnung. Ich hätte es trotzdem lieber lokal, aber rechnen würde sich die Anschaffung auf absehbare Zeit nicht.

Ein europäisches Modell reicht nicht

Dass am Ende Mistral die Textkorrektur macht, ist kein Zufall. Ich wollte europäische Anbieter nutzen, wo es geht. Ohne diese Vorentscheidung hätten wir sie nie ausprobiert, wären bei den meistgenutzten Modellen geblieben, und ich hätte nie gemerkt, dass sie für diese Aufgabe genauso gut sind. Mistral Small war am Ende sogar billiger als die Alternative von Google und minimal schneller.

Nur reicht die Modellwahl allein dafür nicht, und das hatte ich vorher nicht auf dem Schirm. OpenRouter routet ja bloß weiter, und Mistral Small wird außer von Mistral auch von Venice ausgeliefert. Ohne ausdrückliche Einschränkung ging einer von drei Testaufrufen dorthin. Dass mein Erkennungsmodell sicher war, lag nur daran, dass es zufällig genau einen Anbieter hat.

Die Anbieterliste ist deswegen jetzt eine Erlaubnisliste, die auch durchgesetzt wird: Ein unbekannter Name lässt die Anfrage scheitern, statt sie still woanders hin zu schicken. Eine Aussage über Datenhaltung ist das nicht. OpenRouter selbst ist amerikanisch, und sobald ich diktiere, liegen die Daten in einer fremden Cloud.

Fast perfekt

Was mir zum „perfekt“ fehlt, habe ich bei anderen Lösungen gesehen: eine Vorschau des gesprochenen Textes, während ich spreche, und eine zweite Vorschau des korrigierten Textes, bevor er eingefügt wird. Beides geht mit dem jetzigen Aufbau nicht. Die Kette arbeitet stapelweise, also erst vollständig aufnehmen, dann erkennen, dann korrigieren. Eine Vorschau während des Sprechens braucht einen anderen Erkennungspfad und eine echte Oberfläche statt meiner Benachrichtigungen.

Ein paar Dinge sind auch schlicht noch kaputt. Sehr kurze Diktate bringen das Korrekturmodell aus der Rolle, weil die Längenprüfung bei zwei Wörtern nicht mehr greift. Englische Begriffe in deutschen Sätzen werden weiterhin gern erfunden, mein Favorit ist „Environment-Variablen“ als „Bayern-Programm“.

Die Fehler waren am Ende lehrreicher als der Aufbau. Eine einzelne Messung hat einmal in die völlig falsche Richtung gezeigt, und eine sauber gemessene Verbesserung war gar nicht aktiv, ohne dass es jemandem auffiel. Seitdem misstraue ich Messwerten ungefähr so viel wie meinem Gefühl.

Ohne KI hätte ich das nicht gebaut

Das gehört zum ehrlichen Bild dazu: Ein großer Teil des Wissens in diesem Artikel ist nicht auf meinem Mist gewachsen. Ich wusste vorher nicht, dass ein Aufnahmeprogramm beim Abbruch einen halb gefüllten Puffer wegwirft, und ich hätte erst recht nicht gewusst, wie man so etwas einkreist. Gemessen und erklärt hat das Claude. Ich habe gemerkt, dass etwas nicht stimmt, und nachgehakt.

Für mich ist das kein Eingeständnis, sondern der eigentliche Punkt. Eine Spracherkennung mit anschließender Textkorrektur ist nichts, wovon ich je gedacht hätte, dass ich sie selbst baue. Ich hätte nach einer fertigen Lösung gesucht, und damit hätte es sich gehabt. Was sich geändert hat, ist nicht meine Fähigkeit, sondern der Zugang zu dem Wissen, das mir dafür fehlte.

Was die KI nicht liefert, ist der Wille, es tatsächlich durchzuziehen. Melden, wenn etwas nicht stimmt, nachfragen, wieder testen, an einem Abend nochmal von vorn anfangen. Diese fünf Stunden hat niemand für mich verbracht. Herausgekommen ist dabei etwas, das ich seit knapp drei Wochen jeden Tag benutze 😀