Därför hör AI-transkribering fel på tekniska termer (och hur vi fixade det)

Den 2 juli körde vi en testsession och ställde en enkel fråga högt till GeekBye: "What is the pointer in C++?" ("vad är en pekare i C++?").

Live-transkriptet svarade 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.

Samma session — hälsomätvärdena berättade resten: 3 tappade transkriberingsanslutningar på 163 sekunder och ett 51 sekunder långt hål i transkriptet. Och en ledtråd till som visade sig betyda mest: vår återställningskörning efter sessionen — som transkriberar lokalt sparat ljud på nytt för att fylla luckor — fick meningen nästan rätt: "a pointer in plus, plus? What the pointer in plus, plus C++."

Ljudet var felfritt. Live-modellen hade bara ingen anledning att vänta sig C++.

Det här är historien om GeekBye v2.0.11, berättad utifrån de faktiska transkripten och produktionsloggarna.

Därför hör talmodeller fel på din vokabulär

Taligenkänning är ett prediktionsproblem. Givet tvetydigt ljud väljer modellen de mest sannolika orden — och för en generell modell är "point in life" (meningen med livet) en betydligt mer sannolik fras än "pointer in C++" (en pekare i C++). Varje ingenjör som sett ett mötestranskript återge Kubernetes som "cube and eddies" har mött det här felet.

Lösningen är inte en bättre mikrofon. Den heter keyterm-biasing: att före sessionen tala om för modellen vilka osannolika ord som är sannolika för just dig. Vår talleverantör stöder upp till 50 biasing-termer per session. Här kommer den pinsamma delen: rörläggningen för de termerna fanns end-to-end i vår stack — klient, backend, leverantör — och ingenting hade någonsin fyllt den. Varje session kördes med noll domänhjälp.

Fix 1: din profil blir modellens vokabulär

GeekBye känner redan till din domän — den finns i din aktiva profil. v2.0.11 härleder biasing-keyterms från profilens namn och beskrivning: termer med symboler (C++, Node.js), akronymer (SQL, AWS), camelCase-namn (TypeScript, PostgreSQL) och egennamn. En profil som nämner din stack gör nu den stacken väntad i stället för exotisk.

Dagen då fixen gjorde allt värre

Vår första version behandlade varje ord med stor bokstav som ett egennamn. I en intern testbuild (den nådde aldrig kunder) skickade en profil skriven i löpande prosa den här biasing-listan till modellen:

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

Att styra en talmodell mot ordet "For" är värre än att inte styra den alls. I nästa testsession kom ordet "speak" — tydligt uttalat, flera gånger — tillbaka som "Clicky", "Hey, Vicky" och "Peter Paderty". Läxan kostade oss en eftermiddag: bias:a bara med distinkta termer. Ord med stor bokstav räknas nu bara när de dyker upp mitt i en mening (en äkta egennamnssignal); markdown-rubriker, där varje ord har stor bokstav, bidrar aldrig. Samma profil härleder nu exakt LinkedIn, AI, CEO, MCP — och valideringssessionen transkriberade flerspråkigt, snabbt växlande ljud korrekt i 199 raka sekunder, 189 transkriptsegment, noll fel.

Fix 2: racet som fällde anslutningarna

Keytermsen förklarade de felhörda orden. De förklarade inte de tre tappade anslutningarna.

Det spåret ledde någonstans subtilare. Vår leverantör committar (slutför) transkriberingen utifrån sin egen röstaktivitetsdetektering, ungefär en sekund in i tystnaden. Vår klient skickar också en säkerhetscommit 250 millisekunder in i tystnaden, för att spola ut en eventuellt hängande halv mening. Leverantörens bekräftelse på att den redan committat tar en till tre sekunder på vägen tillbaka. Räkna på de tre siffrorna: närhelst leverantören hann först avfyrades vår säkerhetscommit mot en nästan tom buffert — och leverantörens svar på det var inte bara ett artigt avslag. Den fällde anslutningen. Varje paus i talet var en slantsingling.

v2.0.11 levererar två lager mot detta:

1. I appen: när ett committat transkript anländer vet klienten nu att leverantörens buffert precis tömts och hoppar över den överflödiga säkerhetscommiten.
2. I vår backend, samma dag: proxyn som sitter mellan appen och leverantören speglar leverantörens ljudbokföring exakt — den ser varje ljudram och varje commitbekräftelse med noll latens — och vägrar helt enkelt vidarebefordra varje commit som leverantören skulle avvisa. Den här skyddar alla klientversioner på en gång, även användare som inte uppdaterat.

Vi såg den fungera i produktion inom en timme. Spärren fångade dödsdömda commits med 178 ms respektive 256 ms buffrat ljud — var och en av dem hade före den dagen varit en garanterat tappad anslutning och en lucka i någons mötesanteckningar. En 60 minuter lång oavbruten session samma eftermiddag noterade fem infångningar och noll tappade anslutningar. Före fixen hade en riktig användare samma morgon startat om sin inspelning fem gånger på sex minuter i kamp mot exakt den här buggen.

Två mindre fixar som följer med

AI-insikter väntar nu på substans. De förvanskade tidiga fragmenten matade tidigare GeekByes live-förslagschips, som självsäkert producerade ämnen som "Defining Life's Ultimate Purpose" ur en felhörd C++-fråga. Förslagen väntar nu tills sessionen har verklig samtalsmassa.

Återställd text får rätt talare. Återställningskörningen som transkriberade vår C++-fråga korrekt hade attribuerat den till "Them". Tidslinjen för det lokalt sparade ljudet registrerar nu vem som talade, så återställda segment attribueras korrekt till You eller Them.

Resultattavlan

Mätvärde (uppmätt, inte uppskattat)	Före	Efter v2.0.11 + backend-spärr
Tappade anslutningar i testsessionen	3 på 163 s	0
Längsta hålet i transkriptet	51 s	~6 s värsta lucka i valideringen
"pointer in C++"	"point in life"	korrekt, med biasad vokabulär
Dödsdömda commits som når leverantören	allihop	0 (fångade i backend)

Om du bygger på realtids-tal-API:er

Tre överförbara lärdomar från den här releasen:

1. Mata biasing-funktionen. Om din STT-leverantör stöder keyterms/frasledtrådar är det billigaste träffsäkerhetslyftet som finns att fylla den med en liten, distinkt vokabulär — och att fylla den med vanliga ord är en träffsäkerhetsförlust.
2. Tävla aldrig mot leverantörens egen tillståndsmaskin från fel sida av en nätverksrundresa. Vår klient kunde inte vinna ett informationsrace på 250 ms mot 3 s. Spärren hör hemma där båda signalerna möts — för oss backend-proxyn.
3. Validera på en live-build före publicering. Keyterms-regressionen fångades för att varje GeekBye-release testas som en signerad, notariserad build mot produktion innan den skeppas. Den dåliga versionen fanns några timmar på en intern maskin, inte på din Mac.

GeekBye v2.0.11 är live nu — kör du v2 har du den redan via automatisk uppdatering. För tillförlitlighetsgrunden som den här releasen bygger vidare på, se varför din AI-anteckningsapp stannar på dåligt wifi och vad som är nytt i GeekBye v2. För hur live-transkribering fungerar i vardagen, börja med realtidstranskribering i GeekBye.