Dlaczego transkrypcja AI przekręca terminy techniczne (i jak to naprawiliśmy)
Sesja na żywo usłyszała "what is the pointer in C++" jako "what is the point in life". Oto ślad śledztwa od tego transkryptu do GeekBye v2.0.11 — keyterm biasing, wyścig zrywający połączenia i dzień, w którym nasza własna poprawka obróciła się przeciwko nam.
2 lipca uruchomiliśmy sesję testową i zadaliśmy GeekBye na głos proste pytanie: "What is the pointer in C++?" (czym jest wskaźnik w C++).
Transkrypcja na żywo odpowiedziała poezją:
[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.
Zamiast "pointer in C++" (wskaźnik w C++) model usłyszał "point in life" (sens życia). W tej samej sesji resztę opowiedziały metryki zdrowia: 3 zerwane połączenia transkrypcji w 163 sekundy i 51-sekundowa dziura w transkrypcie. I jeszcze jeden trop, który okazał się najważniejszy: nasz mechanizm odzyskiwania po sesji — który ponownie transkrybuje lokalnie zapisane audio, żeby wypełnić luki — odtworzył to zdanie niemal poprawnie: "a pointer in plus, plus? What the pointer in plus, plus C++."
Z dźwiękiem wszystko było w porządku. Model działający na żywo po prostu nie miał powodu spodziewać się C++.
To historia wydania GeekBye v2.0.11, opowiedziana na podstawie prawdziwych transkryptów i logów produkcyjnych.
Dlaczego modele mowy przekręcają Twoje słownictwo
Rozpoznawanie mowy to problem predykcji. Przy niejednoznacznym dźwięku model wybiera najbardziej prawdopodobne słowa — a dla modelu ogólnego przeznaczenia fraza "point in life" jest o wiele bardziej prawdopodobna niż "pointer in C++". Każdy inżynier, który widział, jak transkrypcja spotkania zamienia Kubernetes w "cube and eddies", zna tę porażkę z autopsji.
Rozwiązaniem nie jest lepszy mikrofon, tylko keyterm biasing: powiedzenie modelowi przed rozpoczęciem sesji, które mało prawdopodobne słowa są prawdopodobne u Ciebie. Nasz dostawca rozpoznawania mowy obsługuje do 50 terminów biasujących na sesję. A teraz wstydliwa część: cała infrastruktura dla tych terminów istniała w naszym stacku od końca do końca — klient, backend, dostawca — i nic jej nigdy nie zasilało. Każda sesja działała bez żadnej pomocy domenowej.
Poprawka 1: Twój profil staje się słownikiem modelu
GeekBye już zna Twoją domenę — jest w Twoim aktywnym profilu. v2.0.11 wyprowadza keytermy do biasowania z nazwy i opisu profilu: terminy z symbolami (C++, Node.js), akronimy (SQL, AWS), nazwy w stylu camel case (TypeScript, PostgreSQL) i nazwy własne. Profil wspominający o Twoim stacku sprawia teraz, że ten stack jest oczekiwany, a nie egzotyczny.
Dzień, w którym poprawka wszystko pogorszyła
Nasza pierwsza wersja traktowała każde słowo pisane wielką literą jak nazwę własną. Na wewnętrznym buildzie testowym (to nigdy nie trafiło do klientów) profil napisany prozą wysłał do modelu taką listę biasującą:
Senior, Writing, Direct, For, Includes, Write, Role, Intent…
Biasowanie modelu mowy w stronę słowa "For" jest gorsze niż brak biasowania w ogóle. W następnej sesji testowej słowo "speak" — wypowiedziane wyraźnie, wiele razy — wróciło jako "Clicky", "Hey, Vicky" i "Peter Paderty". Ta lekcja kosztowała nas jedno popołudnie: biasuj tylko charakterystycznymi terminami. Słowa pisane wielką literą liczą się teraz tylko wtedy, gdy występują w środku zdania (prawdziwy sygnał nazwy własnej); nagłówki markdown, w których każde słowo zaczyna się wielką literą, nigdy nie wnoszą wkładu. Ten sam profil wyprowadza teraz dokładnie LinkedIn, AI, CEO, MCP — a sesja walidacyjna poprawnie transkrybowała wielojęzyczne, szybko przełączające się audio przez 199 sekund bez przerwy: 189 segmentów transkryptu, zero błędów.
Poprawka 2: wyścig, który zrywał połączenia
Keytermy wyjaśniły przekręcone słowa. Nie wyjaśniły trzech zerwanych połączeń.
Ten trop prowadził w subtelniejsze miejsce. Nasz dostawca commituje (finalizuje) transkrypcję na podstawie własnej detekcji aktywności głosowej, mniej więcej sekundę po zapadnięciu ciszy. Nasz klient także wysyła zabezpieczający commit 250 milisekund po ciszy, żeby domknąć ewentualne wiszące, niedokończone zdanie. Potwierdzenie dostawcy, że już scommitował, wraca po jednej do trzech sekund. Policz te trzy liczby: zawsze gdy dostawca scommitował pierwszy, nasz zabezpieczający commit trafiał w prawie pusty bufor — a odpowiedzią dostawcy nie było uprzejme odrzucenie. Zrywał połączenie. Każda pauza w mowie była rzutem monetą.
v2.0.11 dostarcza przeciwko temu dwie warstwy:
- W aplikacji: gdy przychodzi scommitowany transkrypt, klient wie już, że bufor dostawcy został właśnie opróżniony, i pomija zbędny zabezpieczający commit.
- W naszym backendzie, tego samego dnia: proxy siedzące między aplikacją a dostawcą odwzorowuje dokładnie księgowość audio dostawcy — widzi każdą ramkę audio i każde potwierdzenie commita z zerowym opóźnieniem — i po prostu odmawia przekazania commita, który dostawca by odrzucił. Ta warstwa chroni każdą wersję klienta naraz, w tym użytkowników, którzy jeszcze się nie zaktualizowali.
Zobaczyliśmy, jak to działa na produkcji, w ciągu godziny. Strażnik przechwycił skazane commity niosące 178 ms i 256 ms zbuforowanego audio — każdy z nich przed tym dniem oznaczał gwarantowane zerwanie połączenia i dziurę w czyichś notatkach ze spotkania. 60-minutowa ciągła sesja tego popołudnia zanotowała pięć przechwyceń i zero zerwań. Przed poprawką, tego samego ranka, prawdziwy użytkownik pięć razy w sześć minut restartował nagrywanie, walcząc dokładnie z tym błędem.
Dwie mniejsze poprawki w pakiecie
Insighty AI czekają teraz na konkrety. Te zniekształcone wczesne fragmenty zasilały wcześniej podpowiedzi GeekBye na żywo, które z przekręconego pytania o C++ z pełnym przekonaniem produkowały tematy w rodzaju "Defining Life's Ultimate Purpose". Sugestie czekają teraz, aż sesja nabierze prawdziwej masy konwersacyjnej.
Odzyskany tekst dostaje właściwego mówcę. Mechanizm odzyskiwania, który poprawnie transkrybował nasze pytanie o C++, przypisał je do "Them" (rozmówcy). Lokalnie zapisywana oś czasu audio rejestruje teraz, kto mówił, więc odzyskane segmenty są poprawnie przypisywane do Ciebie lub rozmówcy.
Tablica wyników
| Metryka (zmierzona, nie szacowana) | Przed | Po v2.0.11 + strażnik na backendzie |
|---|---|---|
| Zerwane połączenia w sesji testowej | 3 w 163 s | 0 |
| Najdłuższa dziura w transkrypcie | 51 s | ~6 s najgorszej luki w walidacji |
| "pointer in C++" | "point in life" | poprawnie, z biasowanym słownictwem |
| Skazane commity docierające do dostawcy | wszystkie | 0 (przechwycone na backendzie) |
Jeśli budujesz na API mowy działających w czasie rzeczywistym
Trzy uniwersalne lekcje z tego wydania:
- Zasil funkcję biasowania. Jeśli Twój dostawca STT obsługuje keytermy/podpowiedzi fraz, wypełnienie ich małym, charakterystycznym słownictwem to najtańszy dostępny zysk dokładności — a wypełnienie ich pospolitymi słowami to strata dokładności.
- Nigdy nie ścigaj się z maszyną stanów dostawcy po złej stronie sieciowego round-tripu. Nasz klient nie mógł wygrać informacyjnego wyścigu 250 ms kontra 3 s. Strażnik powinien być tam, gdzie zbiegają się oba sygnały — u nas w proxy na backendzie.
- Waliduj na żywym buildzie przed publikacją. Regresję keytermów wyłapaliśmy dlatego, że każde wydanie GeekBye jest testowane jako podpisany, notaryzowany build na produkcji, zanim trafi do użytkowników. Zła wersja istniała przez kilka godzin na jednej wewnętrznej maszynie, a nie na Twoim Macu.
GeekBye v2.0.11 jest już dostępne — jeśli masz v2, aktualizacja przyszła automatycznie. O fundamentach niezawodności, na których to wydanie bazuje, przeczytasz w tekstach dlaczego Twój notatnik AI przestaje działać na słabym Wi-Fi i co się zmieniło w GeekBye v2. A o tym, jak transkrypcja na żywo działa na co dzień — zacznij od transkrypcji w czasie rzeczywistym w GeekBye.
