Waarom AI-transcriptie technische termen verkeerd verstaat (en hoe wij dat oplosten)
Een live sessie verstond "what is the pointer in C++" als "what is the point in life". Dit is het forensische spoor van dat transcript naar GeekBye v2.0.11 — keyterm-biasing, een race die de verbinding liet vallen, en de dag dat onze eigen fix averechts werkte.
Op 2 juli draaiden we een testsessie en stelden we GeekBye hardop een simpele vraag: "What is the pointer in C++?"
Het live transcript antwoordde met poëzie:
[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.
Dezelfde sessie, en de gezondheidsmetrieken vertelden de rest: 3 weggevallen transcriptieverbindingen in 163 seconden en een gat van 51 seconden in het transcript. Plus nog één aanwijzing die uiteindelijk het belangrijkst bleek: onze herstelronde na de sessie — die lokaal opgeslagen audio opnieuw transcribeert om gaten te vullen — kreeg de zin bijna goed: "a pointer in plus, plus? What the pointer in plus, plus C++."
De audio was prima. Het live model had alleen geen enkele reden om C++ te verwachten.
Dit is het verhaal van GeekBye v2.0.11, verteld aan de hand van de echte transcripten en productielogs.
Waarom spraakmodellen jouw vocabulaire verkeerd verstaan
Spraakherkenning is een voorspellingsprobleem. Bij ambigue audio kiest het model de waarschijnlijkste woorden — en voor een algemeen model is "point in life" (de zin van het leven) een veel waarschijnlijkere frase dan "pointer in C++" (een pointer in C++). Elke engineer die ooit een meetingtranscript Kubernetes heeft zien weergeven als "cube and eddies" kent deze fout.
De oplossing is geen betere microfoon. Het is keyterm-biasing: het model vóór de start van de sessie vertellen welke onwaarschijnlijke woorden voor jou juist waarschijnlijk zijn. Onze spraakprovider ondersteunt tot 50 biasing-termen per sessie. En dan het gênante deel: het leidingwerk voor die termen bestond end-to-end in onze stack — client, backend, provider — en niets had het ooit gevuld. Elke sessie draaide zonder enige domeinhulp.
Fix 1: jouw profiel wordt het vocabulaire van het model
GeekBye kent jouw domein al — het staat in je actieve profiel. v2.0.11 leidt biasing-keyterms af uit de naam en beschrijving van het profiel: termen met symbolen (C++, Node.js), acroniemen (SQL, AWS), camel-case-namen (TypeScript, PostgreSQL) en eigennamen. Een profiel dat jouw stack noemt, maakt die stack nu verwacht in plaats van exotisch.
De dag dat de fix alles erger maakte
Onze eerste versie behandelde elk woord met een hoofdletter als eigennaam. Op een interne testbuild (dit heeft nooit klanten bereikt) stuurde een profiel geschreven in proza deze biasing-lijst naar het model:
Senior, Writing, Direct, For, Includes, Write, Role, Intent…
Een spraakmodel richting het woord "For" biasen is erger dan helemaal niet biasen. In de eerstvolgende testsessie kwam het woord "speak" — duidelijk uitgesproken, meerdere keren — terug als "Clicky", "Hey, Vicky" en "Peter Paderty". De les kostte ons één middag: bias alleen met onderscheidende termen. Woorden met een hoofdletter tellen nu alleen mee als ze midden in een zin staan (een echt eigennaam-signaal); markdown-koppen, waarin elk woord een hoofdletter krijgt, dragen nooit bij. Datzelfde profiel levert nu exact LinkedIn, AI, CEO, MCP op — en de validatiesessie transcribeerde meertalige, snel wisselende audio correct gedurende 199 aaneengesloten seconden, 189 transcriptsegmenten, nul fouten.
Fix 2: de race die verbindingen liet vallen
De keyterms verklaarden de verkeerd verstane woorden. Ze verklaarden niet de drie weggevallen verbindingen.
Dat spoor leidde naar iets subtielers. Onze provider commit (finaliseert) transcriptie op basis van zijn eigen voice-activity-detectie, ongeveer één seconde na het begin van stilte. Onze client stuurt ook een veiligheidscommit na 250 milliseconden stilte, om een hangende halve zin door te spoelen. De bevestiging van de provider dat hij al gecommit heeft, doet er één tot drie seconden over om terug te komen. Reken die drie getallen maar na: telkens wanneer de provider eerst committe, vuurde onze veiligheidscommit tegen een bijna lege buffer — en de reactie van de provider daarop was niet zomaar een beleefde afwijzing. Hij liet de verbinding vallen. Elke spreekpauze was een muntworp.
v2.0.11 levert hiertegen twee lagen:
- In de app: wanneer een gecommit transcript binnenkomt, weet de client nu dat de buffer van de provider zojuist geleegd is en slaat hij de overbodige veiligheidscommit over.
- In onze backend, dezelfde dag: de proxy tussen de app en de provider spiegelt de audio-boekhouding van de provider exact — hij ziet elk audioframe en elke commit-bevestiging met nul latentie — en weigert simpelweg elke commit door te sturen die de provider zou afwijzen. Deze laag beschermt elke clientversie tegelijk, ook gebruikers die nog niet geüpdatet hebben.
We zagen het binnen het uur werken in productie. De guard onderschepte gedoemde commits met 178ms en 256ms aan gebufferde audio — elk daarvan was vóór die dag een gegarandeerd weggevallen verbinding en een gat in iemands meetingnotities. Een continue sessie van 60 minuten die middag noteerde vijf onderscheppingen en nul drops. Vóór de fix had een echte gebruiker diezelfde ochtend zijn opname vijf keer in zes minuten herstart, vechtend tegen precies deze bug.
Twee kleinere fixes die meeliften
AI-inzichten wachten nu op substantie. Die verhaspelde vroege fragmenten voedden voorheen de live suggestiechips van GeekBye, die vol zelfvertrouwen onderwerpen produceerden als "Defining Life's Ultimate Purpose" uit een verkeerd verstane C++-vraag. Suggesties wachten nu tot de sessie echte conversationele massa heeft.
Herstelde tekst krijgt de juiste spreker. De herstelronde die onze C++-vraag correct transcribeerde, had hem toegeschreven aan "Them". De lokaal opgeslagen audiotijdlijn registreert nu wie er sprak, zodat herstelde segmenten correct worden toegeschreven aan You of Them.
Het scorebord
| Metriek (gemeten, niet geschat) | Voor | Na v2.0.11 + backend-guard |
|---|---|---|
| Verbindingsdrops in de testsessie | 3 in 163s | 0 |
| Langste gat in het transcript | 51s | ~6s slechtste gat in validatie |
| "pointer in C++" | "point in life" | correct, gebiast vocabulaire |
| Gedoemde commits die de provider bereiken | allemaal | 0 (onderschept in de backend) |
Als je zelf bouwt op realtime speech-API's
Drie overdraagbare lessen uit deze release:
- Voed de biasing-feature. Als je STT-provider keyterms/phrase hints ondersteunt, is die vullen met een klein, onderscheidend vocabulaire de goedkoopste nauwkeurigheidswinst die er bestaat — en die vullen met alledaagse woorden is nauwkeurigheidsverlies.
- Race nooit tegen de state machine van de provider vanaf de verkeerde kant van een netwerk-roundtrip. Onze client kon een informatierace van 250ms tegen 3s niet winnen. De guard hoort daar waar beide signalen samenkomen — voor ons: de backend-proxy.
- Valideer op een live build vóór publicatie. De keyterms-regressie werd gevangen omdat elke GeekBye-release als ondertekende, genotariseerde build tegen productie wordt getest voordat hij uitgaat. De slechte versie bestond een paar uur op één interne machine, niet op jouw Mac.
GeekBye v2.0.11 is nu live — zit je op v2, dan heb je hem al via auto-update. Voor het betrouwbaarheidsfundament waarop deze release voortbouwt, zie waarom je AI-notetaker stopt bij slechte wifi en wat er veranderde in GeekBye v2. Voor hoe live transcriptie er in de dagelijkse praktijk uitziet, begin bij realtime transcriptie in GeekBye.
