Per què la transcripció amb IA sent malament els termes tècnics (i com ho vam arreglar)
Una sessió en directe va entendre "what is the pointer in C++" com "what is the point in life". Aquest és el rastre forense des d'aquell transcript fins a GeekBye v2.0.11 — keyterm biasing, una cursa de temps que feia caure la connexió, i el dia que la nostra pròpia solució ens va sortir malament.
El 2 de juliol vam executar una sessió de prova i vam fer a GeekBye una pregunta senzilla en veu alta: "What is the pointer in C++?"
El transcript en directe va respondre amb poesia:
[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.
A la mateixa sessió, les mètriques de salut explicaven la resta: 3 connexions de transcripció caigudes en 163 segons i un forat de 51 segons al transcript. I una pista més que va acabar sent la més important: la nostra passada de recuperació post-sessió — que torna a transcriure l'àudio desat localment per omplir forats — va encertar gairebé la frase: "a pointer in plus, plus? What the pointer in plus, plus C++."
L'àudio estava bé. El model en directe simplement no tenia cap motiu per esperar C++.
Aquesta és la història de GeekBye v2.0.11, explicada a partir dels transcripts reals i dels logs de producció.
Per què els models de veu senten malament el teu vocabulari
El reconeixement de veu és un problema de predicció. Davant d'un àudio ambigu, el model tria les paraules més probables — i per a un model de propòsit general, "point in life" (el sentit de la vida) és una frase molt més probable que "pointer in C++" (un punter en C++). Qualsevol enginyer que hagi vist un transcript de reunió convertir Kubernetes en "cube and eddies" coneix aquest error.
La solució no és un micròfon millor. És el keyterm biasing: dir-li al model, abans que comenci la sessió, quines paraules improbables són probables per a tu. El nostre proveïdor de veu admet fins a 50 termes de biasing per sessió. I aquí ve la part vergonyosa: la canonada per a aquests termes existia d'extrem a extrem al nostre stack — client, backend, proveïdor — i mai res no l'havia omplert. Cada sessió funcionava amb zero ajuda de domini.
Solució 1: el teu perfil es converteix en el vocabulari del model
GeekBye ja coneix el teu domini — és al teu perfil actiu. La v2.0.11 deriva keyterms de biasing del nom i la descripció del perfil: termes amb símbols (C++, Node.js), acrònims (SQL, AWS), noms en camel case (TypeScript, PostgreSQL) i noms propis. Un perfil que esmenta el teu stack ara fa que aquest stack sigui esperat en lloc d'exòtic.
El dia que la solució ho va empitjorar tot
La nostra primera versió tractava cada paraula amb majúscula inicial com un nom propi. En una build de prova interna (això no va arribar mai als clients), un perfil escrit en prosa va enviar aquesta llista de biasing al model:
Senior, Writing, Direct, For, Includes, Write, Role, Intent…
Esbiaixar un model de veu cap a la paraula "For" és pitjor que no esbiaixar-lo gens. A la següent sessió de prova, la paraula "speak" — pronunciada amb claredat, diverses vegades — va tornar com "Clicky", "Hey, Vicky" i "Peter Paderty". La lliçó ens va costar una tarda: esbiaixa només amb termes distintius. Les paraules amb majúscula ara només compten quan apareixen a mitja frase (un senyal genuí de nom propi); els encapçalaments de markdown, on cada paraula va amb majúscula, no hi contribueixen mai. Aquell mateix perfil ara deriva exactament LinkedIn, AI, CEO, MCP — i la sessió de validació va transcriure correctament àudio multilingüe i de canvi ràpid durant 199 segons seguits, 189 segments de transcript, zero errors.
Solució 2: la cursa que feia caure les connexions
Els keyterms explicaven les paraules mal enteses. No explicaven les tres connexions caigudes.
Aquell rastre portava a un lloc més subtil. El nostre proveïdor fa commit (finalitza) de la transcripció segons la seva pròpia detecció d'activitat de veu, aproximadament un segon després que comenci el silenci. El nostre client també envia un commit de seguretat 250 mil·lisegons després del silenci, per buidar qualsevol frase parcial penjada. La confirmació del proveïdor que ja ha fet commit triga entre un i tres segons a tornar. Fes els comptes amb aquests tres números: sempre que el proveïdor feia commit primer, el nostre commit de seguretat es disparava contra un buffer gairebé buit — i la resposta del proveïdor no era només un rebuig educat. Feia caure la connexió. Cada pausa en la parla era llançar una moneda a l'aire.
La v2.0.11 incorpora dues capes contra això:
- A l'app: quan arriba un transcript commitejat, el client ara sap que el buffer del proveïdor s'acaba de buidar i s'estalvia el commit de seguretat redundant.
- Al nostre backend, el mateix dia: el proxy que hi ha entre l'app i el proveïdor replica exactament la comptabilitat d'àudio del proveïdor — veu cada frame d'àudio i cada confirmació de commit amb latència zero — i simplement es nega a reenviar qualsevol commit que el proveïdor rebutjaria. Aquesta capa protegeix totes les versions del client alhora, inclosos els usuaris que encara no s'han actualitzat.
El vam veure funcionar en producció en menys d'una hora. La guarda va interceptar commits condemnats que portaven 178ms i 256ms d'àudio al buffer — cadascun, abans d'aquell dia, una connexió caiguda garantida i un forat a les notes de reunió d'algú. Una sessió contínua de 60 minuts aquella tarda va registrar cinc intercepcions i zero caigudes. Abans de la solució, un usuari real aquell mateix matí havia reiniciat la gravació cinc vegades en sis minuts lluitant exactament contra aquest bug.
Dues correccions més petites que hi viatgen
Els insights d'IA ara esperen que hi hagi substància. Aquells fragments inintel·ligibles del principi alimentaven abans els xips de suggeriments en directe de GeekBye, que produïen amb tota confiança temes com "Defining Life's Ultimate Purpose" a partir d'una pregunta de C++ mal entesa. Els suggeriments ara esperen fins que la sessió té massa conversacional real.
El text recuperat rep el parlant correcte. La passada de recuperació que va transcriure correctament la nostra pregunta de C++ l'havia atribuïda a "Them". La línia de temps de l'àudio desat localment ara registra qui parlava, de manera que els segments recuperats s'atribueixen correctament a You o Them.
El marcador
| Mètrica (mesurada, no estimada) | Abans | Després de v2.0.11 + guarda al backend |
|---|---|---|
| Caigudes de connexió a la sessió de prova | 3 en 163s | 0 |
| Forat més llarg al transcript | 51s | ~6s de forat màxim en validació |
| "pointer in C++" | "point in life" | correcte, vocabulari esbiaixat |
| Commits condemnats que arriben al proveïdor | tots | 0 (interceptats al backend) |
Si estàs construint sobre APIs de veu en temps real
Tres lliçons transferibles d'aquesta versió:
- Alimenta la funció de biasing. Si el teu proveïdor de STT admet keyterms/phrase hints, omplir-la amb un vocabulari petit i distintiu és el guany de precisió més barat que existeix — i omplir-la amb paraules comunes és una pèrdua de precisió.
- No competeixis mai amb la màquina d'estats del proveïdor des del costat equivocat d'un viatge d'anada i tornada per la xarxa. El nostre client no podia guanyar una cursa d'informació de 250ms contra 3s. La guarda ha d'anar allà on convergeixen els dos senyals — en el nostre cas, el proxy del backend.
- Valida amb una build real abans de publicar. La regressió dels keyterms es va detectar perquè cada versió de GeekBye es prova com a build signada i notaritzada contra producció abans de sortir. La versió dolenta va existir unes hores en una màquina interna, no al teu Mac.
GeekBye v2.0.11 ja està disponible — si ets a la v2, ja la tens via actualització automàtica. Per als fonaments de fiabilitat sobre els quals es construeix aquesta versió, consulta per què el teu notetaker d'IA es para amb mala Wi-Fi i què ha canviat a GeekBye v2. Per saber com funciona la transcripció en directe en el dia a dia, comença per transcripció en temps real a GeekBye.
