De ce transcrierea AI înțelege greșit termenii tehnici (și cum am rezolvat problema)
O sesiune live a auzit "what is the pointer in C++" ca "what is the point in life". Iată traseul criminalistic de la acel transcript până la GeekBye v2.0.11 — keyterm biasing, o cursă de timing care rupea conexiunea și ziua în care propriul nostru fix a dat înapoi.
Pe 2 iulie am rulat o sesiune de test și i-am pus lui GeekBye o întrebare simplă, cu voce tare: "What is the pointer in C++?" (în română: „ce este pointerul în C++?")
Transcriptul live ne-a răspuns cu poezie:
[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.
Aceeași sesiune, iar metricile de sănătate au spus restul: 3 conexiuni de transcriere rupte în 163 de secunde și o gaură de 51 de secunde în transcript. Plus încă un indiciu care s-a dovedit cel mai important: pasul nostru de recuperare post-sesiune — care re-transcrie audio-ul salvat local pentru a umple golurile — a nimerit propoziția aproape corect: "a pointer in plus, plus? What the pointer in plus, plus C++."
Audio-ul era în regulă. Modelul live pur și simplu nu avea niciun motiv să se aștepte la C++.
Aceasta este povestea lui GeekBye v2.0.11, spusă direct din transcrierile reale și din log-urile de producție.
De ce modelele de recunoaștere vocală îți înțeleg greșit vocabularul
Recunoașterea vocală e o problemă de predicție. Dat fiind un audio ambiguu, modelul alege cuvintele cele mai probabile — iar pentru un model generalist, "point in life" (adică „rostul vieții") e o expresie mult mai probabilă decât "pointer in C++" („pointerul în C++"). Orice inginer care a văzut un transcript de ședință redând Kubernetes drept "cube and eddies" a întâlnit acest tip de eșec.
Soluția nu e un microfon mai bun. E keyterm biasing: îi spui modelului, înainte să înceapă sesiunea, care cuvinte improbabile sunt probabile pentru tine. Providerul nostru de speech suportă până la 50 de termeni de biasing per sesiune. Iar acum partea jenantă: instalația pentru acei termeni exista cap-coadă în stack-ul nostru — client, backend, provider — și nimic nu o populase vreodată. Fiecare sesiune rula cu zero ajutor de domeniu.
Fix 1: profilul tău devine vocabularul modelului
GeekBye îți știe deja domeniul — e în profilul tău activ. v2.0.11 derivă keyterms de biasing din numele și descrierea profilului: termeni cu simboluri (C++, Node.js), acronime (SQL, AWS), nume camel-case (TypeScript, PostgreSQL) și nume proprii. Un profil care îți menționează stack-ul face acum ca acel stack să fie așteptat, nu exotic.
Ziua în care fixul a înrăutățit totul
Prima noastră versiune trata fiecare cuvânt scris cu majusculă drept nume propriu. Pe un build intern de test (nu a ajuns niciodată la clienți), un profil scris în proză a trimis modelului această listă de biasing:
Senior, Writing, Direct, For, Includes, Write, Role, Intent…
Să ghidezi un model de recunoaștere vocală spre cuvântul "For" e mai rău decât să nu-l ghidezi deloc. Chiar în următoarea sesiune de test, cuvântul "speak" — rostit clar, de mai multe ori — s-a întors ca "Clicky", "Hey, Vicky" și "Peter Paderty". Lecția ne-a costat o după-amiază: fă biasing doar cu termeni distinctivi. Cuvintele cu majusculă contează acum doar când apar în mijlocul propoziției (un semnal autentic de nume propriu); titlurile markdown, unde fiecare cuvânt e cu majusculă, nu contribuie niciodată. Același profil derivă acum exact LinkedIn, AI, CEO, MCP — iar sesiunea de validare a transcris corect audio multilingv, cu schimbări rapide de limbă, timp de 199 de secunde fără întrerupere, 189 de segmente de transcript, zero erori.
Fix 2: cursa care rupea conexiunile
Keyterms au explicat cuvintele auzite greșit. Nu au explicat însă cele trei conexiuni rupte.
Acea pistă a dus spre ceva mai subtil. Providerul nostru face commit (finalizează) transcrierea pe baza propriei detecții de activitate vocală, la circa o secundă de liniște. Clientul nostru trimite și el un commit de siguranță la 250 de milisecunde de liniște, ca să golească orice frază parțială rămasă în aer. Confirmarea providerului că a comis deja durează între una și trei secunde pe drumul de întoarcere. Fă calculul cu aceste trei numere: ori de câte ori providerul comitea primul, commit-ul nostru de siguranță se declanșa pe un buffer aproape gol — iar răspunsul providerului la asta nu era doar un refuz politicos. Rupea conexiunea. Fiecare pauză în vorbire era un joc de noroc.
v2.0.11 livrează două straturi împotriva acestei probleme:
- În aplicație: când sosește un transcript comis, clientul știe acum că bufferul providerului tocmai a fost golit și sare peste commit-ul de siguranță redundant.
- În backend-ul nostru, în aceeași zi: proxy-ul care stă între aplicație și provider oglindește exact contabilitatea audio a providerului — vede fiecare frame audio și fiecare confirmare de commit cu latență zero — și pur și simplu refuză să trimită mai departe orice commit pe care providerul l-ar respinge. Acesta protejează toate versiunile de client deodată, inclusiv utilizatorii care nu au făcut update.
L-am văzut funcționând în producție în mai puțin de o oră. Guard-ul a interceptat commit-uri condamnate care purtau 178ms și 256ms de audio în buffer — fiecare dintre ele, înainte de acea zi, o conexiune ruptă garantat și o gaură în notițele de ședință ale cuiva. O sesiune continuă de 60 de minute din acea după-amiază a înregistrat cinci interceptări și zero întreruperi. Înainte de fix, un utilizator real, în aceeași dimineață, își repornise înregistrarea de cinci ori în șase minute luptându-se exact cu acest bug.
Două fix-uri mai mici care vin la pachet
Insight-urile AI așteaptă acum substanță. Acele fragmente distorsionate de la început alimentau chip-urile de sugestii live din GeekBye, care produceau cu încredere subiecte precum "Defining Life's Ultimate Purpose" dintr-o întrebare despre C++ auzită greșit. Sugestiile așteaptă acum până când sesiunea are masă conversațională reală.
Textul recuperat primește vorbitorul corect. Pasul de recuperare care ne-a transcris corect întrebarea despre C++ o atribuise lui "Them". Timeline-ul audio salvat local înregistrează acum cine vorbea, astfel încât segmentele recuperate se atribuie corect către You sau Them.
Tabelul de scor
| Metrică (măsurată, nu estimată) | Înainte | După v2.0.11 + guard-ul de backend |
|---|---|---|
| Conexiuni rupte în sesiunea de test | 3 în 163s | 0 |
| Cea mai lungă gaură din transcript | 51s | gaură maximă de ~6s la validare |
| "pointer in C++" | "point in life" | corect, cu vocabular biasat |
| Commit-uri condamnate ajunse la provider | toate | 0 (interceptate în backend) |
Dacă și tu construiești pe API-uri de speech în timp real
Trei lecții transferabile din acest release:
- Populează funcția de biasing. Dacă providerul tău de STT suportă keyterms/phrase hints, popularea lor cu un vocabular mic și distinctiv e cel mai ieftin câștig de acuratețe disponibil — iar popularea lor cu cuvinte comune e o pierdere de acuratețe.
- Nu concura niciodată cu mașina de stări a providerului de pe partea greșită a unui round-trip de rețea. Clientul nostru nu putea câștiga o cursă de informație de 250ms contra 3s. Guard-ul aparține locului unde converg ambele semnale — pentru noi, proxy-ul de backend.
- Validează pe un build live înainte de publicare. Regresia cu keyterms a fost prinsă pentru că fiecare release GeekBye e testat ca build semnat și notarizat, pe producție, înainte să fie livrat. Versiunea proastă a existat câteva ore pe o singură mașină internă, nu pe Mac-ul tău.
GeekBye v2.0.11 e live acum — dacă ești pe v2, îl ai deja prin auto-update. Pentru fundația de fiabilitate pe care se construiește acest release, vezi de ce notetaker-ul tău AI se oprește pe Wi-Fi slab și ce s-a schimbat în GeekBye v2. Pentru cum funcționează transcrierea live zi de zi, începe cu transcrierea în timp real în GeekBye.
