Derfor hører AI-transskription tekniske termer forkert (og sådan fiksede vi det)

Den 2. juli kørte vi en testsession og stillede GeekBye et simpelt spørgsmål højt: "What is the pointer in C++?" ("hvad er en pointer i C++?").

Live-transskriptet svarede 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 session — sundhedsmetrikkerne fortalte resten: 3 tabte transskriptionsforbindelser på 163 sekunder og et 51 sekunder langt hul i transskriptet. Og ét spor mere, der viste sig at betyde mest: vores gendannelseskørsel efter sessionen — som re-transskriberer lokalt gemt lyd for at fylde huller — fik sætningen næsten rigtig: "a pointer in plus, plus? What the pointer in plus, plus C++."

Lyden fejlede intet. Live-modellen havde bare ingen grund til at forvente C++.

Det her er historien om GeekBye v2.0.11, fortalt ud fra de faktiske transskripter og produktionslogs.

Derfor hører talemodeller dit ordforråd forkert

Talegenkendelse er et forudsigelsesproblem. Givet tvetydig lyd vælger modellen de mest sandsynlige ord — og for en generel model er "point in life" (meningen med livet) en langt mere sandsynlig frase end "pointer in C++" (en pointer i C++). Enhver ingeniør, der har set et mødetransskript gengive Kubernetes som "cube and eddies", har mødt denne fejl.

Løsningen er ikke en bedre mikrofon. Den hedder keyterm biasing: at fortælle modellen, før sessionen starter, hvilke usandsynlige ord der er sandsynlige for dig. Vores taleleverandør understøtter op til 50 biasing-termer pr. session. Og her kommer den pinlige del: rørføringen til de termer fandtes end-to-end i vores stack — klient, backend, leverandør — og intet havde nogensinde udfyldt den. Hver session kørte med nul domænehjælp.

Fix 1: din profil bliver modellens ordforråd

GeekBye kender allerede dit domæne — det står i din aktive profil. v2.0.11 udleder biasing-keyterms fra profilens navn og beskrivelse: termer med symboler (C++, Node.js), akronymer (SQL, AWS), camelCase-navne (TypeScript, PostgreSQL) og egennavne. En profil, der nævner din stack, gør nu den stack forventet frem for eksotisk.

Dagen hvor fixet gjorde alting værre

Vores første version behandlede hvert ord med stort begyndelsesbogstav som et egennavn. På et internt testbuild (det nåede aldrig ud til kunder) sendte en profil skrevet i prosa denne biasing-liste til modellen:

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

At biase en talemodel mod ordet "For" er værre end slet ikke at biase den. I den allernæste testsession kom ordet "speak" — udtalt tydeligt, flere gange — tilbage som "Clicky", "Hey, Vicky" og "Peter Paderty". Lektionen kostede os én eftermiddag: bias kun med distinkte termer. Ord med stort begyndelsesbogstav tæller nu kun, når de optræder midt i en sætning (et ægte egennavnssignal); markdown-overskrifter, hvor hvert ord står med stort, bidrager aldrig. Samme profil udleder nu præcis LinkedIn, AI, CEO, MCP — og valideringssessionen transskriberede flersproget lyd med hurtige skift korrekt i 199 sekunder i træk, 189 transskriptsegmenter, nul fejl.

Fix 2: racet der smed forbindelserne

Keyterms forklarede de forkert hørte ord. De forklarede ikke de tre tabte forbindelser.

Det spor førte et mere subtilt sted hen. Vores leverandør committer (færdiggør) transskriptionen ud fra sin egen stemmeaktivitetsdetektering, cirka ét sekund inde i stilheden. Vores klient sender også et sikkerheds-commit 250 millisekunder inde i stilheden for at skylle en eventuel hængende halv sætning ud. Leverandørens bekræftelse på, at den allerede har committet, er et til tre sekunder om at nå tilbage. Regn på de tre tal: hver gang leverandøren committede først, fyrede vores sikkerheds-commit mod en næsten tom buffer — og leverandørens svar på det var ikke bare en høflig afvisning. Den smed forbindelsen. Hver pause i talen var et møntkast.

v2.0.11 leverer to lag imod det:

1. I appen: når et committet transskript ankommer, ved klienten nu, at leverandørens buffer lige er blevet tømt, og springer det overflødige sikkerheds-commit over.
2. I vores backend, samme dag: proxyen, der sidder mellem appen og leverandøren, spejler leverandørens lydregnskab præcist — den ser hver lydframe og hver commit-bekræftelse med nul latenstid — og nægter simpelthen at videresende ethvert commit, som leverandøren ville afvise. Den beskytter alle klientversioner på én gang, inklusive brugere der ikke har opdateret.

Vi så den virke i produktion inden for en time. Værnet opsnappede dødsdømte commits med 178 ms og 256 ms bufferet lyd — hver af dem var før den dag en garanteret tabt forbindelse og et hul i nogens mødenoter. En 60 minutters uafbrudt session samme eftermiddag registrerede fem opsnapninger og nul tabte forbindelser. Før fixet havde en rigtig bruger samme morgen genstartet sin optagelse fem gange på seks minutter i kamp med præcis denne bug.

To mindre rettelser der følger med

AI-indsigter venter nu på substans. De forvanskede tidlige fragmenter fodrede før GeekByes live-forslagschips, som selvsikkert producerede emner som "Defining Life's Ultimate Purpose" ud af et forkert hørt C++-spørgsmål. Forslagene venter nu, til sessionen har reel samtalemasse.

Gendannet tekst får den rigtige taler. Gendannelseskørslen, der transskriberede vores C++-spørgsmål korrekt, havde tilskrevet det til "Them". Tidslinjen for den lokalt gemte lyd registrerer nu, hvem der talte, så gendannede segmenter tilskrives korrekt til You eller Them.

Resultattavlen

Metrik (målt, ikke estimeret)	Før	Efter v2.0.11 + backend-værn
Tabte forbindelser i testsessionen	3 på 163 s	0
Længste hul i transskriptet	51 s	~6 s værste hul i valideringen
"pointer in C++"	"point in life"	korrekt, med biased ordforråd
Dødsdømte commits der når leverandøren	dem alle	0 (opsnappet i backend)

Hvis du bygger på realtids-tale-API'er

Tre overførbare lektioner fra denne release:

1. Fodr biasing-funktionen. Hvis din STT-leverandør understøtter keyterms/frasehints, er det billigste præcisionsløft, der findes, at udfylde den med et lille, distinkt ordforråd — og at udfylde den med almindelige ord er et præcisionstab.
2. Kap aldrig med leverandørens egen tilstandsmaskine fra den forkerte side af en netværksrundtur. Vores klient kunne ikke vinde et informationskapløb på 250 ms mod 3 s. Værnet hører hjemme dér, hvor begge signaler mødes — for os backend-proxyen.
3. Validér på et live-build før udgivelse. Keyterms-regressionen blev fanget, fordi hver GeekBye-release testes som et signeret, notariseret build mod produktion, før den udkommer. Den dårlige version eksisterede i nogle få timer på én intern maskine, ikke på din Mac.

GeekBye v2.0.11 er live nu — kører du v2, har du den allerede via auto-opdatering. For det pålidelighedsfundament, denne release bygger videre på, se hvorfor din AI-notetager stopper på dårligt wi-fi og hvad der er nyt i GeekBye v2. For hvordan live-transskription fungerer i hverdagen, så start med realtidstransskription i GeekBye.