Pourquoi la transcription IA écorche les termes techniques (et comment nous l'avons corrigé)
Une session en direct a entendu « what is the pointer in C++ » comme « what is the point in life ». Voici la piste forensique qui mène de cette transcription à GeekBye v2.0.11 : biasing par keyterms, une race condition qui faisait tomber la connexion, et le jour où notre propre correctif a empiré les choses.
Le 2 juillet, nous avons lancé une session de test et posé à GeekBye une question toute simple, à voix haute : « What is the pointer in C++? » (« qu'est-ce que le pointeur en C++ ? »).
La transcription en direct a répondu avec de la poésie :
[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.
Même session, et les métriques de santé racontaient le reste : 3 connexions de transcription tombées en 163 secondes et un trou de 51 secondes dans la transcription. Plus un dernier indice qui s'est avéré le plus important : notre passe de récupération post-session — qui retranscrit l'audio sauvegardé localement pour combler les trous — a presque retrouvé la phrase correcte : « a pointer in plus, plus? What the pointer in plus, plus C++. »
L'audio était bon. Le modèle en direct n'avait simplement aucune raison de s'attendre à du C++.
Voici l'histoire de GeekBye v2.0.11, racontée à partir des transcriptions et des logs de production réels.
Pourquoi les modèles vocaux écorchent votre vocabulaire
La reconnaissance vocale est un problème de prédiction. Face à un audio ambigu, le modèle choisit les mots les plus probables — et pour un modèle généraliste, « point in life » (le sens de la vie) est une phrase bien plus probable que « pointer in C++ » (le pointeur en C++). Tout ingénieur qui a vu la transcription d'une réunion transformer Kubernetes en « cube and eddies » connaît cet échec.
La solution n'est pas un meilleur micro. C'est le biasing par keyterms : dire au modèle, avant le début de la session, quels mots improbables sont probables pour vous. Notre fournisseur vocal accepte jusqu'à 50 termes de biasing par session. Et voici la partie embarrassante : la tuyauterie pour ces termes existait de bout en bout dans notre stack — client, backend, fournisseur — et rien ne l'avait jamais alimentée. Chaque session tournait avec zéro aide de domaine.
Correctif 1 : votre profil devient le vocabulaire du modèle
GeekBye connaît déjà votre domaine — il est dans votre profil actif. La v2.0.11 dérive les keyterms de biasing du nom et de la description du profil : les termes avec symboles (C++, Node.js), les acronymes (SQL, AWS), les noms en camel case (TypeScript, PostgreSQL) et les noms propres. Un profil qui mentionne votre stack rend désormais cette stack attendue plutôt qu'exotique.
Le jour où le correctif a tout aggravé
Notre première version traitait chaque mot commençant par une majuscule comme un nom propre. Sur une build interne de test (cela n'a jamais atteint les clients), un profil rédigé en prose a envoyé au modèle cette liste de biasing :
Senior, Writing, Direct, For, Includes, Write, Role, Intent…
Biaiser un modèle vocal vers le mot « For » est pire que ne pas le biaiser du tout. Dès la session de test suivante, le mot « speak » — prononcé distinctement, plusieurs fois — est revenu en « Clicky », « Hey, Vicky » et « Peter Paderty ». La leçon nous a coûté un après-midi : ne biaiser qu'avec des termes distinctifs. Les mots en majuscule initiale ne comptent désormais que lorsqu'ils apparaissent en milieu de phrase (un vrai signal de nom propre) ; les titres markdown, où chaque mot porte une majuscule, ne contribuent jamais. Ce même profil dérive maintenant exactement LinkedIn, AI, CEO, MCP — et la session de validation a transcrit correctement un audio multilingue à alternances rapides pendant 199 secondes d'affilée, 189 segments de transcription, zéro erreur.
Correctif 2 : la course qui faisait tomber les connexions
Les keyterms expliquaient les mots mal entendus. Ils n'expliquaient pas les trois connexions tombées.
Cette piste menait à quelque chose de plus subtil. Notre fournisseur committe (finalise) la transcription selon sa propre détection d'activité vocale, environ une seconde après le début du silence. Notre client envoie aussi un commit de sécurité 250 millisecondes après le début du silence, pour vider toute phrase partielle en suspens. La confirmation du fournisseur qu'il a déjà committé met une à trois secondes à revenir. Faites le calcul avec ces trois chiffres : chaque fois que le fournisseur committait en premier, notre commit de sécurité partait contre un buffer quasi vide — et la réponse du fournisseur n'était pas un simple refus poli. Il coupait la connexion. Chaque pause dans la parole était un pile ou face.
La v2.0.11 embarque deux couches contre cela :
- Dans l'app : quand une transcription committée arrive, le client sait désormais que le buffer du fournisseur vient d'être vidé et saute le commit de sécurité redondant.
- Dans notre backend, le même jour : le proxy qui se trouve entre l'app et le fournisseur reproduit exactement la comptabilité audio du fournisseur — il voit chaque frame audio et chaque confirmation de commit avec une latence nulle — et refuse tout simplement de relayer tout commit que le fournisseur rejetterait. Cette couche protège toutes les versions du client à la fois, y compris les utilisateurs qui n'ont pas mis à jour.
Nous l'avons vu fonctionner en production dans l'heure. Le garde-fou a intercepté des commits condamnés portant 178 ms et 256 ms d'audio en buffer — chacun d'eux, avant ce jour-là, une connexion coupée garantie et un trou dans les notes de réunion de quelqu'un. Une session continue de 60 minutes cet après-midi-là a enregistré cinq interceptions et zéro coupure. Avant le correctif, le matin même, un utilisateur réel avait redémarré son enregistrement cinq fois en six minutes en se battant exactement contre ce bug.
Deux correctifs plus petits qui font le voyage
Les insights IA attendent désormais de la substance. Ces fragments incompréhensibles du début alimentaient les puces de suggestions en direct de GeekBye, qui produisaient avec assurance des sujets comme « Defining Life's Ultimate Purpose » (« définir le but ultime de la vie ») à partir d'une question C++ mal entendue. Les suggestions attendent désormais que la session ait une vraie masse conversationnelle.
Le texte récupéré reçoit le bon locuteur. La passe de récupération qui avait correctement transcrit notre question C++ l'avait attribuée à « Them ». La timeline de l'audio sauvegardé localement enregistre désormais qui parlait, si bien que les segments récupérés sont correctement attribués à You ou Them.
Le tableau des scores
| Métrique (mesurée, pas estimée) | Avant | Après v2.0.11 + garde-fou backend |
|---|---|---|
| Coupures de connexion pendant la session de test | 3 en 163s | 0 |
| Plus long trou dans la transcription | 51s | ~6s de trou maximal en validation |
| « pointer in C++ » | « point in life » | correct, vocabulaire biaisé |
| Commits condamnés atteignant le fournisseur | tous | 0 (interceptés au backend) |
Si vous construisez sur des API vocales temps réel
Trois leçons transférables de cette version :
- Alimentez la fonction de biasing. Si votre fournisseur STT accepte des keyterms ou des phrase hints, les remplir avec un vocabulaire restreint et distinctif est le gain de précision le moins cher qui soit — et les remplir avec des mots courants est une perte de précision.
- Ne faites jamais la course contre la machine à états du fournisseur depuis le mauvais côté d'un aller-retour réseau. Notre client ne pouvait pas gagner une course d'information de 250 ms contre 3 s. Le garde-fou doit vivre là où les deux signaux convergent — pour nous, le proxy backend.
- Validez sur une build réelle avant de publier. La régression des keyterms a été détectée parce que chaque version de GeekBye est testée en build signée et notariée contre la production avant sa sortie. La mauvaise version a existé quelques heures sur une machine interne, pas sur votre Mac.
GeekBye v2.0.11 est disponible dès maintenant — si vous êtes sur la v2, vous l'avez déjà via la mise à jour automatique. Pour le travail de fiabilité sur lequel s'appuie cette version, voyez pourquoi votre notetaker IA s'arrête en Wi-Fi capricieux et ce qui a changé dans GeekBye v2. Pour comprendre comment fonctionne la transcription en direct au quotidien, commencez par la transcription en temps réel dans GeekBye.
