Miért hallja félre az AI-átirat a szakkifejezéseket (és hogyan javítottuk meg)
Egy élő munkamenet a "what is the pointer in C++" kérdést úgy hallotta: "what is the point in life". Íme a nyomozás útja attól az átirattól a GeekBye v2.0.11-ig — keyterm biasing, egy kapcsolatbontó időzítési verseny, és a nap, amikor a saját javításunk visszafelé sült el.
Július 2-án lefuttattunk egy tesztmunkamenetet, és hangosan feltettünk a GeekBye-nak egy egyszerű kérdést: "What is the pointer in C++?" (magyarul: „mi az a pointer a C++-ban?")
Az élő átirat költészettel válaszolt:
[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.
Ugyanez a munkamenet — a többit az állapotmetrikák mesélték el: 3 bontott átírási kapcsolat 163 másodperc alatt, és egy 51 másodperces lyuk az átiratban. És még egy nyom, amely végül a legfontosabbnak bizonyult: a munkamenet utáni helyreállító lépésünk — amely a helyben mentett hangot újra átírja a hiányok pótlására — majdnem eltalálta a mondatot: "a pointer in plus, plus? What the pointer in plus, plus C++."
A hanggal minden rendben volt. Az élő modellnek egyszerűen nem volt oka C++-ra számítani.
Ez a GeekBye v2.0.11 története, a valódi átiratok és az éles üzemi logok alapján elmesélve.
Miért hallják félre a beszédmodellek a szókincsedet
A beszédfelismerés predikciós probléma. Kétértelmű hang esetén a modell a legvalószínűbb szavakat választja — és egy általános célú modellnek a "point in life" (vagyis „az élet értelme") sokkal valószínűbb kifejezés, mint a "pointer in C++" („a pointer a C++-ban"). Minden mérnök, aki látta már, hogy egy meetingátirat a Kubernetest "cube and eddies"-ként jeleníti meg, találkozott ezzel a hibával.
A megoldás nem egy jobb mikrofon, hanem a keyterm biasing: még a munkamenet kezdete előtt megmondod a modellnek, mely valószínűtlen szavak valószínűek nálad. A beszédszolgáltatónk munkamenetenként legfeljebb 50 biasing-kifejezést támogat. És most a kínos rész: az ezekhez a kifejezésekhez tartozó csővezeték végponttól végpontig létezett a stackünkben — kliens, backend, szolgáltató —, és soha semmi nem töltötte fel. Minden munkamenet nulla szakterületi segítséggel futott.
1. javítás: a profilod lesz a modell szókincse
A GeekBye már ismeri a szakterületedet — ott van az aktív profilodban. A v2.0.11 a profil nevéből és leírásából származtat biasing-keytermeket: szimbólumokat tartalmazó kifejezéseket (C++, Node.js), betűszavakat (SQL, AWS), camel-case neveket (TypeScript, PostgreSQL) és tulajdonneveket. Egy profil, amely megemlíti a stackedet, mostantól várttá teszi azt a stacket, nem egzotikussá.
A nap, amikor a javítás mindent rontott
Az első verziónk minden nagybetűs szót tulajdonnévként kezelt. Egy belső tesztbuilden (ez soha nem jutott el ügyfelekhez) egy prózában írt profil ezt a biasing-listát küldte a modellnek:
Senior, Writing, Direct, For, Includes, Write, Role, Intent…
Egy beszédmodellt a "For" szó felé terelni rosszabb, mint egyáltalán nem terelni. A rögtön következő tesztmunkamenetben a "speak" szó — tisztán, többször kimondva — így jött vissza: "Clicky", "Hey, Vicky" és "Peter Paderty". A lecke egy délutánunkba került: csak megkülönböztető kifejezésekkel tereld a modellt. A nagybetűs szavak mostantól csak akkor számítanak, ha mondat közben fordulnak elő (ez valódi tulajdonnév-jelzés); a markdown-címsorok, ahol minden szó nagybetűs, soha nem járulnak hozzá. Ugyanez a profil most pontosan ezt származtatja: LinkedIn, AI, CEO, MCP — a validációs munkamenet pedig 199 másodpercen át folyamatosan, helyesen írta át a többnyelvű, gyorsan váltó hangot: 189 átiratszegmens, nulla hiba.
2. javítás: a verseny, amely a kapcsolatokat bontotta
A keytermek megmagyarázták a félrehallott szavakat. A három bontott kapcsolatot nem.
Az a nyom valami finomabb dologhoz vezetett. A szolgáltatónk a saját hangaktivitás-érzékelése alapján commitolja (véglegesíti) az átírást, nagyjából egy másodpercnyi csend után. A kliensünk szintén küld egy biztonsági commitot 250 milliszekundumnyi csend után, hogy kiürítsön minden lógva maradt mondattöredéket. A szolgáltató visszaigazolása arról, hogy már commitolt, egy-három másodperc alatt ér vissza. Számolj utána ezzel a három számmal: amikor a szolgáltató commitolt előbb, a biztonsági commitunk egy szinte üres pufferre sült el — és a szolgáltató válasza erre nem csupán egy udvarias elutasítás volt. Bontotta a kapcsolatot. Minden beszédszünet pénzfeldobás volt.
A v2.0.11 két védelmi réteget hoz ez ellen:
- Az appban: amikor megérkezik egy commitolt átirat, a kliens mostantól tudja, hogy a szolgáltató puffere épp kiürült, és kihagyja a felesleges biztonsági commitot.
- A backendünkben, még aznap: az app és a szolgáltató között ülő proxy pontosan tükrözi a szolgáltató hangkönyvelését — minden hangkeretet és minden commit-visszaigazolást nulla késleltetéssel lát —, és egyszerűen megtagadja minden olyan commit továbbítását, amelyet a szolgáltató elutasítana. Ez egyszerre védi az összes kliensverziót, azokat a felhasználókat is, akik még nem frissítettek.
Egy órán belül láttuk működni élesben. A védelem 178 ms és 256 ms pufferelt hangot hordozó, halálra ítélt commitokat fogott el — azelőtt mindegyik garantáltan bontott kapcsolat és lyuk lett volna valakinek a meetingjegyzeteiben. Egy aznap délutáni, 60 perces folyamatos munkamenet öt elfogást és nulla bontást rögzített. A javítás előtt aznap reggel egy valódi felhasználó hat perc alatt ötször indította újra a felvételét, pontosan ezzel a hibával küzdve.
Két kisebb javítás, amely ezzel együtt érkezik
Az AI-meglátások mostantól kivárják a lényeget. Azok a torz korai töredékek korábban a GeekBye élő javaslatchipjeit táplálták, amelyek egy félrehallott C++-kérdésből magabiztosan gyártottak olyan témákat, mint a "Defining Life's Ultimate Purpose". A javaslatok most megvárják, míg a munkamenetnek valódi beszélgetési tömege lesz.
A helyreállított szöveg a megfelelő beszélőhöz kerül. A helyreállító lépés, amely helyesen írta át a C++-kérdésünket, azt a "Them" beszélőnek tulajdonította. A helyben mentett hang-idővonal mostantól rögzíti, ki beszélt, így a helyreállított szegmensek helyesen kerülnek a You vagy a Them beszélőhöz.
Az eredménytábla
| Metrika (mért, nem becsült) | Előtte | v2.0.11 + backend-védelem után |
|---|---|---|
| Kapcsolatbontások a tesztmunkamenetben | 3 db 163 s alatt | 0 |
| A leghosszabb átiratlyuk | 51 s | ~6 s legrosszabb rés a validációban |
| "pointer in C++" | "point in life" | helyes, terelt szókinccsel |
| A szolgáltatóhoz eljutó halálra ítélt commitok | mind | 0 (a backend elfogja) |
Ha valós idejű beszéd-API-kra építesz
Három átvihető tanulság ebből a kiadásból:
- Tápláld a biasing-funkciót. Ha az STT-szolgáltatód támogat keyterms/phrase hints funkciót, egy kicsi, megkülönböztető szókinccsel feltölteni a legolcsóbb elérhető pontosságnyereség — gyakori szavakkal feltölteni viszont pontosságveszteség.
- Soha ne versenyezz a szolgáltató saját állapotgépével egy hálózati round-trip rossz oldaláról. A kliensünk nem nyerhetett meg egy 250 ms kontra 3 s információs versenyt. A védelem oda való, ahol a két jel összefut — nálunk ez a backend-proxy.
- Élő buildben validálj a publikálás előtt. A keyterms-regresszió azért bukott le, mert minden GeekBye-kiadást aláírt, notarizált buildként tesztelünk éles környezet ellen, mielőtt kikerül. A hibás verzió néhány óráig létezett egyetlen belső gépen, nem a te Maceden.
A GeekBye v2.0.11 már élesben van — ha v2-n vagy, az auto-update révén már meg is kaptad. A megbízhatósági alapokról, amelyekre ez a kiadás épül, lásd: miért áll le az AI-jegyzetelőd rossz Wi-Fi-n és mi változott a GeekBye v2-ben. Arról, hogyan működik az élő átírás a mindennapokban, kezdd ezzel: valós idejű átírás a GeekBye-ban.
