Warum KI-Transkription Fachbegriffe falsch versteht (und wie wir das behoben haben)
Eine Live-Session verstand "what is the pointer in C++" als "what is the point in life". Hier ist die forensische Spur von diesem Transkript zu GeekBye v2.0.11 — Keyterm-Biasing, eine Race-Condition, die die Verbindung abbrechen ließ, und der Tag, an dem unser eigener Fix nach hinten losging.
Am 2. Juli haben wir eine Testsession gefahren und GeekBye laut eine einfache Frage gestellt: "What is the pointer in C++?" („Was ist der Pointer in C++?")
Das Live-Transkript antwortete mit Poesie:
[23:16:37] You: Tell me, what is the point in life? [23:16:52] You: Handy Plus. [23:17:02] You: What the pointer in Plus Plus? [23:17:09] You: C.
Dieselbe Session, die Health-Metriken erzählten den Rest: 3 abgebrochene Transkriptionsverbindungen in 163 Sekunden und ein 51-Sekunden-Loch im Transkript. Und noch ein Hinweis, der sich am Ende als der wichtigste herausstellte: Unser Recovery-Durchlauf nach der Session — der lokal gespeichertes Audio neu transkribiert, um Lücken zu füllen — bekam den Satz fast richtig hin: "a pointer in plus, plus? What the pointer in plus, plus C++."
Das Audio war in Ordnung. Das Live-Modell hatte nur keinen Grund, C++ zu erwarten.
Das ist die Geschichte von GeekBye v2.0.11, erzählt anhand der echten Transkripte und Produktionslogs.
Warum Sprachmodelle dein Vokabular falsch verstehen
Spracherkennung ist ein Vorhersageproblem. Bei mehrdeutigem Audio wählt das Modell die wahrscheinlichsten Wörter — und für ein Allzweckmodell ist "point in life" (der Sinn des Lebens) eine weitaus wahrscheinlichere Phrase als "pointer in C++" (der Pointer in C++). Jeder Engineer, der schon einmal zusehen musste, wie ein Meeting-Transkript Kubernetes als "cube and eddies" wiedergibt, kennt diesen Fehler.
Die Lösung ist kein besseres Mikrofon. Sie heißt Keyterm-Biasing: dem Modell vor Sessionbeginn mitteilen, welche unwahrscheinlichen Wörter für dich wahrscheinlich sind. Unser Speech-Provider unterstützt bis zu 50 Biasing-Begriffe pro Session. Und jetzt der peinliche Teil: Die komplette Leitung für diese Begriffe existierte in unserem Stack von Ende zu Ende — Client, Backend, Provider — und nichts hatte sie je befüllt. Jede Session lief ohne jede Domänen-Hilfe.
Fix 1: dein Profil wird zum Vokabular des Modells
GeekBye kennt deine Domäne bereits — sie steckt in deinem aktiven Profil. v2.0.11 leitet Biasing-Keyterms aus Name und Beschreibung des Profils ab: Begriffe mit Sonderzeichen (C++, Node.js), Akronyme (SQL, AWS), CamelCase-Namen (TypeScript, PostgreSQL) und Eigennamen. Ein Profil, das deinen Stack erwähnt, macht diesen Stack jetzt erwartbar statt exotisch.
Der Tag, an dem der Fix alles schlimmer machte
Unsere erste Version behandelte jedes großgeschriebene Wort als Eigennamen. Auf einem internen Test-Build (das hat nie Kunden erreicht) schickte ein in Prosa geschriebenes Profil diese Biasing-Liste ans Modell:
Senior, Writing, Direct, For, Includes, Write, Role, Intent…
Ein Sprachmodell in Richtung des Wortes "For" zu lenken ist schlimmer, als gar nicht zu lenken. In der allernächsten Testsession kam das Wort "speak" — mehrfach klar und deutlich gesprochen — als "Clicky", "Hey, Vicky" und "Peter Paderty" zurück. Die Lektion hat uns einen Nachmittag gekostet: Biasing nur mit unverwechselbaren Begriffen. Großgeschriebene Wörter zählen jetzt nur noch, wenn sie mitten im Satz stehen (ein echtes Eigennamen-Signal); Markdown-Überschriften, in denen jedes Wort großgeschrieben ist, tragen nie bei. Dasselbe Profil leitet jetzt exakt LinkedIn, AI, CEO, MCP ab — und die Validierungssession transkribierte mehrsprachiges, schnell wechselndes Audio 199 Sekunden am Stück korrekt, 189 Transkript-Segmente, null Fehler.
Fix 2: die Race-Condition, die Verbindungen abbrechen ließ
Die Keyterms erklärten die falsch verstandenen Wörter. Sie erklärten nicht die drei abgebrochenen Verbindungen.
Diese Spur führte an eine subtilere Stelle. Unser Provider committet (finalisiert) die Transkription anhand seiner eigenen Voice-Activity-Detection, ungefähr eine Sekunde nach Beginn der Stille. Unser Client schickt zusätzlich 250 Millisekunden nach Beginn der Stille einen Sicherheits-Commit, um hängengebliebene halbe Sätze zu flushen. Die Bestätigung des Providers, dass er bereits committet hat, braucht ein bis drei Sekunden für den Rückweg. Rechne mit diesen drei Zahlen: Immer wenn der Provider zuerst committete, feuerte unser Sicherheits-Commit gegen einen fast leeren Puffer — und die Antwort des Providers darauf war nicht bloß eine höfliche Ablehnung. Er brach die Verbindung ab. Jede Sprechpause war ein Münzwurf.
v2.0.11 liefert zwei Schutzschichten dagegen:
- In der App: Wenn ein committetes Transkript ankommt, weiß der Client jetzt, dass der Puffer des Providers gerade geflusht wurde, und lässt den redundanten Sicherheits-Commit aus.
- In unserem Backend, am selben Tag: Der Proxy zwischen App und Provider spiegelt die Audio-Buchführung des Providers exakt — er sieht jeden Audio-Frame und jede Commit-Bestätigung mit null Latenz — und weigert sich schlicht, einen Commit weiterzuleiten, den der Provider ablehnen würde. Diese Schicht schützt jede Client-Version auf einmal, auch Nutzer, die noch nicht aktualisiert haben.
Wir sahen den Fix innerhalb einer Stunde in Produktion arbeiten. Der Guard fing zum Scheitern verurteilte Commits mit 178ms und 256ms gepuffertem Audio ab — jeder davon wäre vor diesem Tag eine garantiert abgebrochene Verbindung und eine Lücke in jemandes Meeting-Notizen gewesen. Eine durchgehende 60-Minuten-Session am selben Nachmittag verzeichnete fünf Abfangvorgänge und null Abbrüche. Vor dem Fix hatte ein echter Nutzer noch am selben Morgen seine Aufnahme fünfmal in sechs Minuten neu gestartet — im Kampf mit genau diesem Bug.
Zwei kleinere Fixes im Gepäck
KI-Insights warten jetzt auf Substanz. Diese verstümmelten frühen Fragmente fütterten bisher GeekByes Live-Vorschlags-Chips, die daraus selbstbewusst Themen wie "Defining Life's Ultimate Purpose" aus einer falsch verstandenen C++-Frage produzierten. Vorschläge warten jetzt, bis die Session echte Gesprächsmasse hat.
Wiederhergestellter Text bekommt den richtigen Sprecher. Der Recovery-Durchlauf, der unsere C++-Frage korrekt transkribierte, hatte sie "Them" zugeordnet. Die lokal gespeicherte Audio-Timeline hält jetzt fest, wer gerade sprach, sodass wiederhergestellte Segmente korrekt You oder Them zugeordnet werden.
Die Bilanz
| Metrik (gemessen, nicht geschätzt) | Vorher | Nach v2.0.11 + Backend-Guard |
|---|---|---|
| Verbindungsabbrüche in der Testsession | 3 in 163s | 0 |
| Längstes Loch im Transkript | 51s | ~6s schlimmste Lücke in der Validierung |
| "pointer in C++" | "point in life" | korrekt, dank Vokabular-Biasing |
| Zum Scheitern verurteilte Commits, die den Provider erreichen | alle | 0 (im Backend abgefangen) |
Wenn du auf Realtime-Speech-APIs baust
Drei übertragbare Lektionen aus diesem Release:
- Füttere das Biasing-Feature. Wenn dein STT-Provider Keyterms/Phrase-Hints unterstützt, ist ein kleines, unverwechselbares Vokabular der günstigste Genauigkeitsgewinn überhaupt — und ein Vokabular aus Allerweltswörtern ein Genauigkeitsverlust.
- Liefere dir nie ein Rennen mit der State Machine des Providers von der falschen Seite eines Netzwerk-Roundtrips. Unser Client konnte ein 250ms-gegen-3s-Informationsrennen nicht gewinnen. Der Guard gehört dorthin, wo beide Signale zusammenlaufen — bei uns: der Backend-Proxy.
- Validiere auf einem Live-Build, bevor du veröffentlichst. Die Keyterms-Regression wurde gefunden, weil jedes GeekBye-Release vor dem Versand als signierter, notarisierter Build gegen Produktion getestet wird. Die kaputte Version existierte ein paar Stunden auf einer internen Maschine — nicht auf deinem Mac.
GeekBye v2.0.11 ist jetzt live — wer auf v2 ist, hat es per Auto-Update bereits. Für die Zuverlässigkeits-Grundlagen, auf denen dieses Release aufbaut, siehe warum dein KI-Notetaker bei schlechtem WLAN aussteigt und was sich in GeekBye v2 geändert hat. Wie Live-Transkription im Alltag funktioniert, zeigt Echtzeit-Transkription in GeekBye.
