Perché la Trascrizione AI Fraintende i Termini Tecnici (e Come l'Abbiamo Risolto)
Una sessione live ha sentito "what is the pointer in C++" come "what is the point in life". Ecco la traccia forense da quel transcript a GeekBye v2.0.11 — keyterm biasing, una race condition che faceva cadere la connessione e il giorno in cui il nostro stesso fix ci si è ritorto contro.
Il 2 luglio abbiamo fatto una sessione di test e abbiamo posto a GeekBye una domanda semplice, a voce alta: "What is the pointer in C++?" (cos'è il puntatore in C++?)
Il transcript live ha risposto con la 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.
Stessa sessione, le metriche di salute hanno raccontato il resto: 3 connessioni di trascrizione cadute in 163 secondi e un buco di 51 secondi nel transcript. E un altro indizio che si è rivelato il più importante: il nostro passaggio di recupero post-sessione — che ritrascrive l'audio salvato in locale per colmare i buchi — ha quasi azzeccato la frase: "a pointer in plus, plus? What the pointer in plus, plus C++."
L'audio era a posto. Il modello live semplicemente non aveva motivo di aspettarsi C++.
Questa è la storia di GeekBye v2.0.11, raccontata a partire dai transcript reali e dai log di produzione.
Perché i modelli vocali fraintendono il tuo vocabolario
Il riconoscimento vocale è un problema di previsione. Davanti a un audio ambiguo, il modello sceglie le parole più probabili — e per un modello generalista "point in life" (il senso della vita) è una frase molto più probabile di "pointer in C++" (il puntatore in C++). Ogni ingegnere che ha visto un transcript di riunione rendere Kubernetes come "cube and eddies" ha già incontrato questo fallimento.
La soluzione non è un microfono migliore. È il keyterm biasing: dire al modello, prima che la sessione inizi, quali parole improbabili sono probabili per te. Il nostro provider di speech-to-text supporta fino a 50 termini di biasing per sessione. E qui viene la parte imbarazzante: l'impianto per quei termini esisteva end-to-end nel nostro stack — client, backend, provider — e niente l'aveva mai popolato. Ogni sessione girava senza alcun aiuto di dominio.
Fix 1: il tuo profilo diventa il vocabolario del modello
GeekBye conosce già il tuo dominio — è nel tuo profilo attivo. La v2.0.11 deriva i keyterm di biasing dal nome e dalla descrizione del profilo: termini con simboli (C++, Node.js), acronimi (SQL, AWS), nomi in camel case (TypeScript, PostgreSQL) e nomi propri. Un profilo che menziona il tuo stack ora rende quello stack atteso invece che esotico.
Il giorno in cui il fix ha peggiorato tutto
La nostra prima versione trattava ogni parola con la maiuscola come un nome proprio. Su una build di test interna (non è mai arrivata ai clienti), un profilo scritto in prosa ha spedito al modello questa lista di biasing:
Senior, Writing, Direct, For, Includes, Write, Role, Intent…
Orientare un modello vocale verso la parola "For" è peggio che non orientarlo affatto. Nella sessione di test immediatamente successiva, la parola "speak" — pronunciata chiaramente, più volte — è tornata come "Clicky", "Hey, Vicky" e "Peter Paderty". La lezione ci è costata un pomeriggio: fare biasing solo con termini distintivi. Le parole con la maiuscola ora contano solo quando compaiono a metà frase (un vero segnale di nome proprio); i titoli markdown, dove ogni parola è maiuscola, non contribuiscono mai. Quello stesso profilo ora deriva esattamente LinkedIn, AI, CEO, MCP — e la sessione di validazione ha trascritto correttamente audio multilingue con cambi rapidi per 199 secondi di fila, 189 segmenti di transcript, zero errori.
Fix 2: la race condition che faceva cadere le connessioni
I keyterm spiegavano le parole fraintese. Non spiegavano le tre connessioni cadute.
Quella traccia portava a qualcosa di più sottile. Il nostro provider committa (finalizza) la trascrizione in base alla propria voice activity detection, circa un secondo dopo l'inizio del silenzio. Il nostro client invia anche un commit di sicurezza 250 millisecondi dopo l'inizio del silenzio, per svuotare eventuali frasi parziali rimaste in sospeso. La conferma del provider di aver già committato impiega da uno a tre secondi per tornare indietro. Fai i conti con questi tre numeri: ogni volta che il provider committava per primo, il nostro commit di sicurezza scattava contro un buffer quasi vuoto — e la risposta del provider non era solo un rifiuto cortese. Faceva cadere la connessione. Ogni pausa nel parlato era un lancio di moneta.
La v2.0.11 introduce due livelli di difesa:
- Nell'app: quando arriva un transcript committato, il client ora sa che il buffer del provider è appena stato svuotato e salta il commit di sicurezza ridondante.
- Nel nostro backend, lo stesso giorno: il proxy che sta tra l'app e il provider rispecchia esattamente la contabilità audio del provider — vede ogni frame audio e ogni conferma di commit con latenza zero — e si rifiuta semplicemente di inoltrare qualsiasi commit che il provider rifiuterebbe. Questo livello protegge tutte le versioni del client in una volta sola, compresi gli utenti che non hanno ancora aggiornato.
L'abbiamo visto funzionare in produzione entro un'ora. La guardia ha intercettato commit destinati a fallire con 178ms e 256ms di audio nel buffer — ognuno dei quali, prima di quel giorno, era una connessione caduta garantita e un buco negli appunti di riunione di qualcuno. Una sessione continua di 60 minuti quel pomeriggio ha registrato cinque intercettazioni e zero cadute. Prima del fix, quella stessa mattina un utente reale aveva riavviato la registrazione cinque volte in sei minuti combattendo esattamente contro questo bug.
Due fix minori al seguito
Gli insight AI ora aspettano la sostanza. Quei frammenti confusi iniziali alimentavano i suggerimenti live di GeekBye, che producevano con sicurezza argomenti come "Defining Life's Ultimate Purpose" da una domanda su C++ fraintesa. I suggerimenti ora aspettano che la sessione abbia una vera massa conversazionale.
Il testo recuperato riceve lo speaker giusto. Il passaggio di recupero che aveva trascritto correttamente la nostra domanda su C++ l'aveva attribuita a "Them". La timeline dell'audio salvato in locale ora registra chi stava parlando, così i segmenti recuperati vengono attribuiti correttamente a You o Them.
Il tabellone
| Metrica (misurata, non stimata) | Prima | Dopo v2.0.11 + guardia backend |
|---|---|---|
| Cadute di connessione nella sessione di test | 3 in 163s | 0 |
| Buco più lungo nel transcript | 51s | ~6s di gap peggiore in validazione |
| "pointer in C++" | "point in life" | corretto, con vocabolario orientato |
| Commit destinati a fallire arrivati al provider | tutti | 0 (intercettati nel backend) |
Se stai costruendo su API di speech in tempo reale
Tre lezioni trasferibili da questa release:
- Alimenta la funzione di biasing. Se il tuo provider STT supporta keyterm/phrase hints, popolarla con un vocabolario piccolo e distintivo è il guadagno di accuratezza più economico che ci sia — e popolarla con parole comuni è una perdita di accuratezza.
- Non gareggiare mai con la state machine del provider dal lato sbagliato di un round-trip di rete. Il nostro client non poteva vincere una gara di informazioni da 250ms contro 3s. La guardia va messa dove i due segnali convergono — per noi, il proxy del backend.
- Valida su una build reale prima di pubblicare. La regressione dei keyterm è stata individuata perché ogni release di GeekBye viene testata come build firmata e notarizzata contro la produzione prima di uscire. La versione difettosa è esistita per qualche ora su una macchina interna, non sul tuo Mac.
GeekBye v2.0.11 è già disponibile — se sei sulla v2, ce l'hai già tramite aggiornamento automatico. Per il lavoro di affidabilità su cui questa release si appoggia, leggi perché il tuo notetaker AI si blocca con il Wi-Fi instabile e cosa è cambiato in GeekBye v2. Per come funziona la trascrizione live giorno per giorno, parti da trascrizione in tempo reale in GeekBye.
