AI文字起こしはなぜ専門用語を聞き間違えるのか(そして私たちはどう直したか)

7月2日、私たちはテストセッションを実施し、GeekByeに向かって声でシンプルな質問をしました。"What is the pointer in C++?"(C++のポインタとは何か?)

ライブトランスクリプトは詩的な答えを返してきました:

[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.

「pointer in C++(C++のポインタ)」が「point in life(人生の意味)」に化けたわけです。同じセッションのヘルスメトリクスが残りを物語っていました。163秒間に3回の文字起こし接続切断、そしてトランスクリプトに空いた51秒の穴。さらに、後で最も重要だと分かる手がかりがもう一つ。ローカルに保存された音声を再文字起こしして欠落を埋めるセッション後のリカバリ処理は、この文をほぼ正しく認識していました: "a pointer in plus, plus? What the pointer in plus, plus C++."

音声自体には何の問題もありませんでした。ライブモデルには、C++を予期する理由がなかっただけなのです。

これはGeekBye v2.0.11の物語を、実際のトランスクリプトと本番ログから語ったものです。

なぜ音声モデルはあなたの語彙を聞き間違えるのか

音声認識は予測問題です。曖昧な音声が与えられたとき、モデルは最も可能性の高い単語を選びます — 汎用モデルにとって、「point in life」は「pointer in C++」よりはるかにありそうなフレーズなのです。会議のトランスクリプトでKubernetesが「cube and eddies」と書き起こされるのを見たことのあるエンジニアなら、誰もがこの失敗に出会っています。

解決策は、より良いマイクではありません。keytermバイアスです。セッション開始前に、「一般的には珍しいが、あなたにとっては出現しやすい単語」をモデルに伝えること。私たちの音声プロバイダはセッションあたり最大50個のバイアス用語をサポートしています。ここが恥ずかしいところです。これらの用語のための配管は、クライアント、バックエンド、プロバイダと、スタック全体にエンドツーエンドで存在していました — しかし、そこに値を入れるものが何一つなかったのです。すべてのセッションが、ドメインの助けゼロで走っていました。

修正1: プロファイルがモデルの語彙になる

GeekByeはすでにあなたのドメインを知っています — アクティブなプロファイルに書いてあるからです。v2.0.11は、プロファイルの名前と説明からバイアス用のkeytermsを導出します。記号を含む用語(C++、Node.js)、頭字語(SQL、AWS)、キャメルケースの名前(TypeScript、PostgreSQL)、そして固有名詞。あなたのスタックに言及したプロファイルは、そのスタックを「珍しいもの」ではなく「期待されるもの」に変えます。

修正がすべてを悪化させた日

最初のバージョンは、大文字で始まる単語をすべて固有名詞として扱っていました。社内テストビルドで(これは顧客には一切届いていません)、散文で書かれたプロファイルが、次のバイアスリストをモデルに送っていました:

Senior, Writing, Direct, For, Includes, Write, Role, Intent…

音声モデルを「For」という単語に向けてバイアスするのは、バイアスしないより悪い。直後のテストセッションでは、はっきりと何度も発話した「speak」という単語が、"Clicky"、"Hey, Vicky"、*"Peter Paderty"*として返ってきました。この教訓には午後いっぱいの代償を払いました: バイアスは際立った用語だけで行う。大文字始まりの単語は、文中に現れた場合のみカウントされるようになりました(本物の固有名詞シグナルだからです)。すべての単語が大文字化されるmarkdownの見出しは、一切寄与しません。同じプロファイルは今では正確に LinkedIn, AI, CEO, MCP を導出します — そして検証セッションでは、多言語で高速に切り替わる音声を199秒連続で正しく文字起こしし、トランスクリプトセグメントは189個、エラーはゼロでした。

修正2: 接続を切断していた競合

keytermsは聞き間違いを説明しました。しかし3回の接続切断は説明できませんでした。

その手がかりは、もっと微妙な場所につながっていました。私たちのプロバイダは、自身の音声区間検出(VAD)に基づき、無音から約1秒で文字起こしをコミット(確定)します。私たちのクライアントも、宙に浮いた文の断片をフラッシュするために、無音から250ミリ秒でセーフティコミットを送ります。プロバイダから「すでにコミット済み」という確認が返ってくるまでには1〜3秒かかります。この3つの数字で計算してみてください。プロバイダが先にコミットした場合、私たちのセーフティコミットはほぼ空のバッファに対して発火します — そして、それに対するプロバイダの応答は、丁寧な拒否ではありませんでした。接続を切断したのです。 発話の合間の一時停止は、すべてコイントスでした。

v2.0.11は、これに対して2つの防御層を出荷します:

1. アプリ側: コミット済みトランスクリプトが到着した時点で、クライアントはプロバイダのバッファがフラッシュされた直後であることを把握し、冗長なセーフティコミットをスキップします。
2. バックエンド側(同日): アプリとプロバイダの間に位置するプロキシが、プロバイダの音声アカウンティングを正確にミラーリングします — すべての音声フレームとすべてのコミット確認をレイテンシゼロで見ているので、プロバイダが拒否するであろうコミットの転送そのものを拒否します。こちらは、まだアップデートしていないユーザーを含む、すべてのクライアントバージョンを一度に保護します。

本番環境で動くのを1時間以内に確認しました。ガードは、バッファ音声178msと256msを抱えた「破滅コミット」を捕捉しました — その日より前なら、そのどちらもが確実な接続切断であり、誰かの会議メモの空白でした。その日の午後の60分間の連続セッションでは、5回の捕捉とゼロ切断を記録。修正前、同じ日の朝には、実際のユーザーがまさにこのバグと格闘して、6分間に5回録音を再起動していました。

同乗する2つの小さな修正

AIインサイトは中身が揃うまで待つようになりました。 序盤の文字化けした断片は、これまでGeekByeのライブ提案チップに流れ込み、聞き間違えたC++の質問から「Defining Life's Ultimate Purpose(人生の究極の目的を定義する)」のようなトピックを自信満々に生成していました。提案は、セッションに本物の会話の質量が溜まるまで待つようになりました。

リカバリされたテキストに正しい話者が付くようになりました。 私たちのC++の質問を正しく文字起こししたリカバリ処理は、それを「Them」(相手)に帰属させていました。ローカル保存される音声タイムラインが誰の発話かを記録するようになったので、リカバリされたセグメントはYouまたはThemに正しく帰属します。

スコアボード

指標(実測値、推定ではない)	修正前	v2.0.11+バックエンドガード適用後
テストセッションでの接続切断	163秒間に3回	0
最長のトランスクリプトの穴	51秒	検証時の最悪ギャップ約6秒
"pointer in C++"	"point in life"	正しく認識(バイアス済み語彙)
プロバイダに届く破滅コミット	すべて	0(バックエンドで捕捉)

リアルタイム音声APIの上に構築しているなら

このリリースから持ち帰れる、3つの汎用的な教訓:

1. バイアス機能に餌を与える。 STTプロバイダがkeyterms/フレーズヒントをサポートしているなら、小さく、際立った語彙を投入することは、手に入る中で最も安上がりな精度向上です — そして、ありふれた単語を投入することは精度の損失です。
2. ネットワーク往復の不利な側から、プロバイダ自身のステートマシンと競争しない。 私たちのクライアントは、250ms対3秒の情報競争に勝てませんでした。ガードは両方のシグナルが合流する場所に置くべきです — 私たちの場合、それはバックエンドプロキシでした。
3. 公開前にライブビルドで検証する。 keytermsのリグレッションを捕まえられたのは、GeekByeのすべてのリリースが、出荷前に署名・公証済みビルドとして本番環境に対してテストされているからです。悪いバージョンは社内の1台のマシンに数時間存在しただけで、あなたのMacには存在していません。

GeekBye v2.0.11は現在公開中です — v2をお使いなら、自動アップデートですでに適用されています。このリリースの土台となった信頼性の取り組みについては、悪いWi-FiでAIノートテイカーが止まる理由とGeekBye v2の変更点をご覧ください。ライブ文字起こしの日常的な使い方については、GeekByeのリアルタイム文字起こしから始めてください。