音声入力アーキテクチャ: Loqua の三モデル音声入力スタックの内側

私は Shuran。音声入力を毎日使うアルゴリズム研究者の小さなチームを運営しています。Loqua を作ったのは、評価したディクテーションツール — そのほとんどがよくエンジニアリングされ、ほとんどが本当に有用 — のすべてが、コード、多言語混合、アプリ認識フォーマットで押すと同じ天井に平らになったからです。天井は構造的で、チューニング問題ではありません。これは構造が変わる必要があると決めた後で到達したアーキテクチャです。

これは論文ではありません。ブログレベルのウォークスルー — 各レイヤーの背後にある直観、出てきた数値、スタックを何に実際に使うか。より深い学術コンテキストが欲しければ、最後の参考文献セクションが私たちが引いた論文を指します。

wrap-Whisper の罠

OpenAI の Whisper は英語音声認識で可能なことを変えました。注目すべきモデルです。Whisper 論文は、弱教師あり音声訓練のスケーリングがドメインごとのファインチューニングなしで堅牢な汎用 ASR を生成することを示しました — 訛り、条件、99 言語にわたって。それは分野にとっての構造的勝利です。

しかし Whisper は ASR モデルであり、ディクテーション製品ではありません。「音声を正確に書き起こす」と「編集せずにメールに貼り付けられるテキストを生成する」の間のギャップは大きいです。wrap-Whisper アプローチ — Whisper の出力を取り、フォーマットレイヤーを通す — はそのギャップの一部を埋めます。私たちが気にした三つの場所で失敗します:

• 技術用語。 Whisper は「react query」を聞いて「react query」をくれます。あなたのコードベースではそれが @tanstack/react-query で、パッケージインポートがあなたが望んだものだと知りません。技術用語に対する NER は、音素を聞くモデルではなく、周囲のコンテキストを見るモデルを必要とします。
• アプリ認識フォーマット。 Whisper は書き起こします。Slack にいるか Python ファイルにいるかは知りません。上にフォーマッターをボルトオンするにはヒューリスティック (脆い) か発話ごとに重い LLM コール (遅くてクラウド依存) が必要です。
• 厳しいレイテンシ予算下のストリーミング。 Whisper はバッチ書き起こしには優秀です。ストリーミング、低レイテンシ、オンデバイス Whisper には妥協 (小さなモデル、低い精度) かモデルの構造に戦う積極的なエンジニアリングが必要です。

研究プロトタイプ用に wrap-Whisper 経路を試しました。アイデアをテストするには十分でした。日常ツールとして使うには十分ではありませんでした。

三モデルの直観: 異なる種類の音声認識スタック

直観は、音声入力は三つのジョブであり、同じモデルがそのすべてに苦手だということです。三つのジョブ:

1. 言葉を聞く。 音響からトークンへ。これは ASR が得意なものです。
2. 意図を理解する。 フィラー、フォルススタート、文中修正をクリーンアップ。技術エンティティを認識。ユーザーが実際にタイプしたかったものを決定。
3. 正しく配置する。 宛先アプリ用に出力をフォーマット。同じ意図が VS Code でコード、Slack で Slack メッセージ、Cursor で構造化プロンプトとして出るようにする。

すべての三つをやろうとする単一エンドツーエンドモデルには困難な構造的問題があります: 「音素を書き起こす」の損失面と「Slack 用にフォーマットする」の損失面は異なる方向を指します。共同訓練は両方を妥協します。これは自分のアブレーションで確認できます — レイヤー 2 と 3 をマルチタスクデータで訓練された一つの transformer に統合しようとし、両方の精度が落ちました。

三つに分割することで、各モデルが一つのジョブをよく行えます。コストはレイヤー間ハンドオフのための少量のレイテンシで、それは Neural Engine 上で単一パイプラインですべてを実行することで回復します。それが Loqua の音声入力アーキテクチャの心臓です: 単一のモノリシック書き起こし器ではなく、各レイヤーが問題のその部分のために目的別に訓練された小さなディクテーションモデルスタックです。

レイヤー 1: 音声認識

音響入力 → トークンシーケンス。これは Whisper の直接ラッパーではなくタスク固有の音声認識器です。アーキテクチャ選択は妥協しない三つの制約で駆動されました:

• ストリーミングファースト。 出力は話者が発話を終える前に始まります。これはデフォルトとしてフル音声シーケンスへの非因果的 attention を排除します — ストリーミングフレンドリーなバリアントを使います。
• オンデバイス Neural Engine 互換性。 モデルサイズとオペレータ選択は Apple の Core ML を介して Neural Engine で効率的に動作するものに制約されます。これは実在する制約です — 論文では問題なく見えるオペレータが Neural Engine 経路から外れて CPU バウンドになることがあります。
• 低振幅堅牢性。 訓練データには意図的にささやき音量の入力 (カフェで、深夜に静かにディクテーションする人々) が含まれます。大半の汎用 ASR 訓練データは通常音量です。ささやき音量には明示的なカバレッジが必要です。

このレイヤーの出力はタイミングと信頼度スコアを持つトークンシーケンスです。最終テキストではありません — 次のレイヤーがクリーンアップする生の認識です。

レイヤー 2: 言語インテリジェンス

トークンシーケンス → クリーンアップされ、意図解決されたテキスト。これが最大の研究投資をする場所です。ユーザー可視品質の大半がここに住むからです。

このレイヤーのジョブ: 音声モデルが聞いたものを取り、ユーザーが意図したものを生成します。三つのことが並列に起こります:

• フィラーとフォルススタートの除去。 「Um, so, basically, we should — actually wait, let me start over — we should cache this」が「これをキャッシュすべきです」になります。文中修正は尊重され、咳払いは消えます。
• 技術用語のための NER。 このレイヤーは一般的なライブラリ、フレームワーク、モデルファミリー、ファイル拡張子、ターミナルコマンド、慣用 API 表面の名前を学習します。「React query」は周囲コンテキストが JavaScript ファイルのとき @tanstack/react-query になります。内部ターゲットは curate された内ドメイン技術用語で 90 年代後半の認識で、識別子がすべての一般用語のために個人辞書を強制せずに正しく出ます。
• 構造的形成。 出力が文、ブレットリスト、markdown テーブル、コードコメントのどれになるかは、次のレイヤー (マルチモーダルコンテキスト) が宛先について何と言うかに基づいてここで決まります。

このレイヤーはパラメータ数でスタック最小のモデルですが、ユーザー体験で最高インパクトです。他の二つを合わせたよりも多くのチーム時間をここに費やしました。

レイヤー 3: マルチモーダルコンテキスト

アプリ状態 + 画面 + カーソル → フォーマット指示。これがオムニモーダルレイヤー — そしてこれをただ「ディクテーションアプリ」と呼ばない理由です。Loqua のジョブは書き起こすことではなく、意図したものを意図した場所に書くことです。

コンテキストレイヤーは macOS Accessibility 経由でアクティブアプリを、選択テキスト (あれば) を、可視近接テキストを、宛先の構造的手がかり (Gmail 作成 vs Slack スレッド vs VS Code Python ファイル vs Cursor チャットパネル) を読みます。言語レイヤーが最終テキストを整形するのに使うフォーマット指示を出力します。

より深い直観 — なぜオムニモーダルアーキテクチャが音声入力を強化するのではなく変えるか — はそれ自身のピースです。そのスレッドが欲しければ 音声と視覚の出会い: オムニモーダルモデルがコンテキスト認識ディクテーションをどう解き放つかを参照してください。

私たちが追跡する数値

これらは内部ベンチマークとドッグフード数値であり、第三者ベンチマークスイートではありません。テストセットには自身の技術用語、コードスイッチング例、訛り英語サンプル、ノイジーな日常環境が含まれます。次のコンテンツステップは、これらの数値が手を振らずに引用できるよう、公開方法論ページであるべきです。

自分たちで使うこと

このスタックについて言える最も重要なことは、私たちが使うから書いたということです。チームのすべてのメンバーが毎日ディクテーションします — コミット、PR、内部 Slack、より長い技術ライティング、(私の場合) この投稿のような大半のブログ投稿の散文。アーキテクチャを形作った決定は製品仕様ではなく、実使用から来ました。

アーキテクチャ vs 機能の区別が日常使用に現れる三つの場所:

• コードディクテーション。 NER 品質はコードのための実行可能インターフェースとしての音声と、おもちゃとしての音声の違いです。これが何を可能にするかは コードディクテーションガイドを参照してください。
• 多言語コードスイッチング。 内部 Slack の半分は北京語と英語の混合です。言語レイヤーはコードスイッチされたデータを回避するのではなく、それで訓練されています。文中切り替えはモード切り替えなしで機能します。
• アプリ認識フォーマット。 同じ音声フレーズが VS Code でコードコメント、GitHub で構造化 PR 説明になることが、音声入力と有用な製品の違いです。

私たちは小さなチームです。このストーリーの正直なバージョンは、wrap-Whisper 製品と三モデル研究スタックの両方を維持するリソースがないということです。構造的経路に賭けたのは、自分たちのために品質が必要だったからで、品質なしの幅広いものよりも品質を持つ狭いものを出荷したかったからです。

2026 年に各レイヤーがどう再構築されたか

レイヤー 1 — 音声認識。 認識器はストリーミング、低振幅音声、技術用語を中心に締められました。より深いウォークスルーは 私たちのオムニモーダル音声スタックの内側に、ポストトレーニング詳細は 私たちの音声スタックでの RL にあります。

レイヤー 2 — 言語インテリジェンス。 言語レイヤーは現在、クリーンアップ、エンティティ保持、アプリ認識構造を別々のポストプロセッサではなく一つのディクテーションモデルスタックとして扱います。そこで強化学習が最も助けます: ユーザーが最も少なく編集する出力を選ぶこと。

レイヤー 3 — マルチモーダルコンテキスト。 コンテキストレイヤーはローカル画面証拠 (アクティブアプリ、選択テキスト、可視識別子、カーソル周辺) を中心に再構築されました。アーキテクチャは 画面を見るリスナーを作るを参照してください。

次のフロンティアは非言語音響: オプションでローカルファーストなコンテキストとしての AED と音声キャプショニング。そのプロトタイプ段階の業務は sounds with meaning でカバーします。

参考文献

このブログレベルの扱いより深く行きたいなら:

• Whisper 論文 (Radford et al., 2022) — レイヤー 1 のために引いた弱教師あり音声訓練パラダイムについて。
• Apple Core ML ドキュメント — Neural Engine デプロイが実践でどう見えるかについて。
• レイヤー 3 推論のためのコンパニオンノート 音声と視覚の出会い: オムニモーダルディクテーション。
• 何が線を越え、何が越えないかについての プライバシー・バイ・デザインのハイブリッドアーキテクチャ。

アーキテクチャについて質問があるか、これらのレイヤーのいずれかをより深く掘り下げたければ、ピングしてください。私たちは小さなチームで、すべてのメールを読みます。