Derfor hører AI-transkripsjon tekniske termer feil (og slik fikset vi det)

Den 2. juli kjørte vi en testøkt og stilte GeekBye et enkelt spørsmål høyt: "What is the pointer in C++?" ("hva er en peker i C++?").

Live-transkriptet svarte med poesi:

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

Samme økt — helsemetrikkene fortalte resten: 3 droppede transkripsjonstilkoblinger på 163 sekunder og et 51 sekunder langt hull i transkriptet. Og ett spor til som viste seg å bety mest: gjenopprettingskjøringen vår etter økten — som re-transkriberer lokalt lagret lyd for å fylle hull — fikk setningen nesten riktig: "a pointer in plus, plus? What the pointer in plus, plus C++."

Lyden var fin. Live-modellen hadde bare ingen grunn til å forvente C++.

Dette er historien om GeekBye v2.0.11, fortalt fra de faktiske transkriptene og produksjonsloggene.

Derfor hører talemodeller vokabularet ditt feil

Talegjenkjenning er et prediksjonsproblem. Gitt tvetydig lyd velger modellen de mest sannsynlige ordene — og for en generell modell er "point in life" (meningen med livet) en langt mer sannsynlig frase enn "pointer in C++" (en peker i C++). Hver ingeniør som har sett et møtetranskript gjengi Kubernetes som "cube and eddies", har møtt denne feilen.

Løsningen er ikke en bedre mikrofon. Den heter keyterm biasing: å fortelle modellen, før økten starter, hvilke usannsynlige ord som er sannsynlige for deg. Taleleverandøren vår støtter opptil 50 biasing-termer per økt. Her er den pinlige delen: rørleggingen for de termene fantes ende-til-ende i stacken vår — klient, backend, leverandør — og ingenting hadde noen gang fylt den. Hver økt kjørte med null domenehjelp.

Fiks 1: profilen din blir modellens vokabular

GeekBye kjenner allerede domenet ditt — det ligger i den aktive profilen din. v2.0.11 utleder biasing-keyterms fra profilens navn og beskrivelse: termer med symboler (C++, Node.js), akronymer (SQL, AWS), camelCase-navn (TypeScript, PostgreSQL) og egennavn. En profil som nevner stacken din, gjør nå den stacken forventet i stedet for eksotisk.

Dagen fiksen gjorde alt verre

Den første versjonen vår behandlet hvert ord med stor forbokstav som et egennavn. På en intern testbuild (den nådde aldri kunder) sendte en profil skrevet i prosa denne biasing-listen til modellen:

Senior, Writing, Direct, For, Includes, Write, Role, Intent…

Å biase en talemodell mot ordet "For" er verre enn å ikke biase den i det hele tatt. I den aller neste testøkten kom ordet "speak" — uttalt tydelig, flere ganger — tilbake som "Clicky", "Hey, Vicky" og "Peter Paderty". Lærdommen kostet oss én ettermiddag: bias kun med distinkte termer. Ord med stor forbokstav teller nå bare når de dukker opp midt i en setning (et ekte egennavnssignal); markdown-overskrifter, der hvert ord har stor forbokstav, bidrar aldri. Den samme profilen utleder nå nøyaktig LinkedIn, AI, CEO, MCP — og valideringsøkten transkriberte flerspråklig lyd med raske bytter korrekt i 199 sekunder i strekk, 189 transkriptsegmenter, null feil.

Fiks 2: kappløpet som droppet tilkoblinger

Keyterms forklarte de feilhørte ordene. De forklarte ikke de tre droppede tilkoblingene.

Det sporet ledet et mer subtilt sted. Leverandøren vår committer (ferdigstiller) transkripsjonen ut fra sin egen stemmeaktivitetsdeteksjon, omtrent ett sekund ut i stillheten. Klienten vår sender også en sikkerhets-commit 250 millisekunder ut i stillheten, for å skylle ut en eventuell hengende halvsetning. Leverandørens bekreftelse på at den allerede har committet, bruker ett til tre sekunder på veien tilbake. Regn på de tre tallene: hver gang leverandøren committet først, fyrte sikkerhets-commiten vår mot en nesten tom buffer — og leverandørens svar på det var ikke bare en høflig avvisning. Den droppet tilkoblingen. Hver pause i talen var et myntkast.

v2.0.11 leverer to lag mot dette:

1. I appen: når et committet transkript ankommer, vet klienten nå at leverandørens buffer nettopp ble tømt, og hopper over den overflødige sikkerhets-commiten.
2. I backenden vår, samme dag: proxyen som sitter mellom appen og leverandøren, speiler leverandørens lydregnskap nøyaktig — den ser hver lydramme og hver commit-bekreftelse med null latens — og nekter rett og slett å videresende enhver commit leverandøren ville avvist. Denne beskytter alle klientversjoner samtidig, inkludert brukere som ikke har oppdatert.

Vi så den virke i produksjon innen timen. Vakten fanget opp dødsdømte commits med 178 ms og 256 ms bufret lyd — hver av dem var før den dagen et garantert tilkoblingsbrudd og et hull i noens møtenotater. En 60-minutters sammenhengende økt samme ettermiddag registrerte fem oppfangninger og null brudd. Før fiksen hadde en ekte bruker samme morgen startet opptaket sitt på nytt fem ganger på seks minutter i kamp mot akkurat denne buggen.

To mindre fikser som følger med

AI-innsikter venter nå på substans. De forvrengte tidlige fragmentene matet før GeekByes live-forslagschips, som selvsikkert produserte temaer som "Defining Life's Ultimate Purpose" fra et feilhørt C++-spørsmål. Forslagene venter nå til økten har reell samtalemasse.

Gjenopprettet tekst får riktig taler. Gjenopprettingskjøringen som transkriberte C++-spørsmålet vårt riktig, hadde tilskrevet det til "Them". Tidslinjen for den lokalt lagrede lyden registrerer nå hvem som snakket, så gjenopprettede segmenter tilskrives riktig til You eller Them.

Resultattavlen

Metrikk (målt, ikke estimert)	Før	Etter v2.0.11 + backend-vakt
Tilkoblingsbrudd i testøkten	3 på 163 s	0
Lengste hull i transkriptet	51 s	~6 s verste hull i valideringen
"pointer in C++"	"point in life"	riktig, med biaset vokabular
Dødsdømte commits som når leverandøren	alle sammen	0 (fanget opp i backenden)

Hvis du bygger på sanntids-tale-API-er

Tre overførbare lærdommer fra denne utgivelsen:

1. Mat biasing-funksjonen. Hvis STT-leverandøren din støtter keyterms/frasehint, er det å fylle den med et lite, distinkt vokabular den billigste presisjonsgevinsten som finnes — og å fylle den med vanlige ord er et presisjonstap.
2. Kappløp aldri mot leverandørens egen tilstandsmaskin fra feil side av en nettverksrundtur. Klienten vår kunne ikke vinne et informasjonskappløp på 250 ms mot 3 s. Vakten hører hjemme der begge signalene møtes — for oss backend-proxyen.
3. Valider på en live-build før publisering. Keyterms-regresjonen ble fanget fordi hver GeekBye-utgivelse testes som en signert, notarisert build mot produksjon før den sendes ut. Den dårlige versjonen eksisterte i noen timer på én intern maskin, ikke på Mac-en din.

GeekBye v2.0.11 er live nå — er du på v2, har du den allerede via auto-oppdatering. For pålitelighetsgrunnlaget denne utgivelsen bygger på, se hvorfor AI-notattakeren din stopper på dårlig wifi og hva som er nytt i GeekBye v2. For hvordan live-transkripsjon fungerer i hverdagen, start med sanntidstranskripsjon i GeekBye.