オムニモーダル音声入力: マルチモーダル理解、MoE、ストリーミングテキスト出力

私は Shuran、Loqua.ai 創業者です。これは私たちのオムニモーダル音声入力スタックの背後にあるより深いエンジニアリングノートです: なぜ意味計画レイヤーをテキストレンダリングレイヤーから分離するのか、条件付きエキスパートがどこで助け、どこで助けなかったか、そしてなぜストリーミングがほぼすべてのアーキテクチャ選択を決めたのか。

なぜモノリシック音声 LM が Mac の壁にぶつかるか

モノリシック音声言語モデルは紙の上では魅力的です: 音声、画面フレーム、テキストを一つの大きなモデルに入力し、最終ディクテーションを出力するよう頼みます。日常の Mac 使用では、その設計は三つの壁に同時にぶつかります。一つ目、レイテンシ予算が残酷です。話者が一時停止した後に最初の有用なトークンが届くなら、音声入力はタイピングではなくバッチ書き起こしのように感じます。

私たちが自分に課している予算はこうです。マイクから最初の可視文字まで、約 200 ミリ秒あります。そのうち、約 40ms がプラットフォームオーバーヘッド (Core Audio バッファリング、プロセス間配信、最終レンダリング)、60ms が音響特徴抽出とフロントエンド推論、70ms が最初の部分結果のための意味計画デコーディング、30ms が安全な早期コミットを発行するためのテキストレンダリングに残ります。すべてのステップをそのウィンドウで実行する単一の 1B+ パラメータ音声 LM は、ベンチマークマシンでは妥当ですが、ブラウザ、IDE、Zoom がすでに実行されている実際のラップトップでは信頼できません。

二つ目、ユーザー可視のジョブは単なる自動音声認識ではありません。同じ発話が Slack の段落、Git コミット件名、Cursor プロンプト、Python コメントになる必要があります。モノリシックモデルはそれらすべてを行うよう訓練できますが、すべてのアプリのフォーマット慣例を再学習し、カーソルが動くたびにそれらを再導出する必要があります。三つ目、モデルはラップトップの熱とメモリエンベロープ内に留まる必要があります。IDE インデックスの隣の VRAM にスワップされる 7B 音声-視覚-テキストモデルは、熱スロットリングとうるさいファンのレシピです。Whisper のような公開業務や最近のオムニモデルレポートは、分野が堅牢な音声とマルチモーダルモデリングを理解するのに役立ちましたが、ローカル製品を出荷するにはより狭く、より意見のある選択を強制します。

私たちの結論はシンプルでした: オムニモーダル音声入力は、単一のオールパーパスブロックではなくパイプラインであるべきです。パイプラインにより各レイヤーが小さな目的、測定可能な失敗モード、境界のあるランタイムコストを保てます。

マルチモーダル命令パイプライン

「意味計画」と「テキストレンダリング」を、認知に関する主張ではなく製品エンジニアリング名として使います。意味計画レイヤーはストリーミング音声特徴、選択された画面コンテキスト、アクティブアプリメタデータ、カーソル周辺の最近のテキストを消費します。コンパクトな意味計画を生成します: 意図、エンティティ、編集モード、ターゲットフォーマット、不確実性。

テキストレンダリングレイヤーはその計画をテキストにマテリアライズします。Loqua では、これはディクテーションの最終テキストライターです。計画が Markdown チェックリスト、文、コードコメント、構造化指示のどれになるかを決定します。この分離により、ユーザーが単に散文をディクテーションしているときに、高価なクロスモーダル推論をホットパスから出します。

各レイヤーがしてはいけないこと

規律は何を取り除いたかにあります。音響フロントエンドは言葉について賢くなろうとはしません。タイミングと信頼度を持つ音響トークンを表面化します。意味計画レイヤーは最終テキストを書きません。安価に修正可能な十分に小さい構造化計画を作ります。テキストレンダリングレイヤーは音声を再読しません。計画と宛先コンテキストを信頼します。いずれかのレイヤーがそれらの境界を越えることを許すことが、初期プロトタイプでレイテンシ回帰の最も一般的な原因でした。クロスレイヤーフィードバックループが、トレースが読まれるまで誰も気づかずにストリーミングをバッチ処理に変えるからです。

利点はデバッグ可能性です。出力が間違っているとき、認識器が間違った単語を聞いたか、意味計画が間違った意図を選んだか、テキストレンダリングが間違ったレジスタで書いたかを伝えられます。それは一つの長い隠れた軌跡を解釈するよりはるかに容易です。社内トリアージでは、ローンチ後の品質修正の約 2/3 が単一レイヤーにきれいに分離されました。残りはクロスレイヤー変更を必要としましたが、診断が明確になってからのみです。

音声エンコーダの MoE

音声エンコーダが条件付き計算が報われた場所です。すべての発話が同じ音響処理を必要とするわけではありません。静かな音声、訛りのある英語、混合英中、コード識別子、会議室背景ノイズはモデルの異なる部分にストレスをかけます。小さなエキスパート混合ルーターにより、すべてのフレームを高価にせずにエンコーダが難しい領域により多くの容量を費やせます。

ルーティングを保守的に保ちました。ルーターは個人ユーザープロファイルではなく、音響統計と浅い語彙的手がかりに条件付けされています。エキスパートは低振幅音声、速い技術ディクテーション、コードスイッチングなどのパターンに特化します。ルーティング不安定性がストリーミング動作を悪化させたので、より大きなエキスパートプールを拒否しました: 正確だが発話途中でスタイルを変えるモデルはタイピングには使えません。

試して捨てたもの

研究では魅力的に見えたが製品で失敗した二つのアイデア。一つ目、ユーザーごとのエキスパート適応: ヘビーユーザーごとに小さなアダプタを訓練。社内テストセットでコールドスタート精度を数ポイント改善したが、コールドローンチメモリフットプリントを倍増させ、プライバシー境界をより不明瞭にしました。二つ目、アクティブアプリ識別子を強い信号として取るルーター。少数の一般的なアプリにオーバーフィットし、新しいアプリで静かに劣化しました。現在の音響と語彙ルーターに置き換え、アプリ認識動作を所属するテキストレンダリングレイヤーに上げました。

実践的に、音声エンコーダ MoE は Loqua が共通経路を高速に保ちつつテールを脆くなくするのに役立ちます。それが製品価値です: ベンチマークトリックではなく、ライブラリ名、静かなフレーズ、バイリンガル断片がフローを壊す瞬間が少ないこと。

ストリーミング: トークン単位 vs フレーズ単位

ストリーミングが最も難しいトレードオフでした。トークン単位出力はレスポンシブに感じますが、早すぎる推測を露出する可能性があります。フレーズ単位出力はよりクリーンですが、遅く感じます。ハイブリッドを使います: 低リスクスパンは早期部分結果、エンティティと画面コンテキストが必要な編集は遅延コミット。

例えば、「auth client が欠落している場合は fetch profile 関数を early return するよう変更して」と言うと、システムは通常の単語を素早くストリーミングできます。しかし fetchProfile と authClient の周りのトークンは、コンテキストレイヤーが可視識別子を確認するまで待ちます。テキストレンダリングが分離されているのはこのためです: 発話全体を再開せずに、コミット前に小さなスパンを修正できます。

文中バイリンガル入力は関連ケースです。「把这个 retry 函数改成指数退避」と言うと、音響フロントエンドはテキストレンダリングに、中国語スパンと一つの英語コードトークンを織り交ぜた計画を渡します。テキストレンダリングは内部信頼閾値をクリアした瞬間に中国語文字を発行し、可視 IDE バッファに対して英語識別子を確認するために数ミリ秒余分に待ちます。ユーザーは中国語の流れを最初に、次に識別子、それから残りを見ます。出力を並べ替える方が速かったでしょうが、間違って感じました。目は左から右へのタイピングを期待します。

コミット境界が他のノブです。コミット境界とは、テキストレンダリングが修正しないと約束する瞬間です。自然な一時停止、文終止符、段落、リストアイテム、コードブロックなどの構造的遷移にそれらを固定します。コミット境界内ではテキストレンダリングは自由に修正できます。コミットされると、テキストはユーザーの視点から最終的です。その契約がストリーミングをジッタリではなく正直に感じさせるものです。

結果は、即座に感じられるが、すべての早期音響推測を最終として扱わないストリーミング音声スタックです。音声入力にとって、その妥協は生の書き起こし速度より重要です。

公開研究コンテキスト

公開研究を注意深く追っています。製品で見る問題の語彙を鋭くするからです。音声-言語モデリング、マルチモーダルエンコーダ、プリファレンス最適化に関する論文とレポートは、分割された責任、ストリーミング制約、クロスモーダルアラインメントに収束する分野を示します。背景には Whisper、Qwen2 技術報告、公開 Qwen2.5-Omni 概要から始めてください。

重要な製品境界: これらのリファレンスは文献コンテキストです。Loqua の本番スタックは Mac ディクテーションのために社内で訓練・最適化したオリジナル研究です。分野を説明するために公開業務を引用するのであって、出自を示唆するためではありません。

私たちが作ったものと次に来るもの

この方向から出荷されたものは、狭いシステムです: 聴き、ローカル画面コンテキストを読み、アプリ認識テキストを書く Mac 音声入力。次の業務はより厳密な評価です。レイテンシ、技術 NER、多言語 WER、画面コンテキスト曖昧性解消について公開方法論が必要です。主張がドッグフードループの外でレビュー可能になるように。

二番目の方向はより良いキャリブレーションです。モデルが可視識別子について不確実なとき、安全な出力形を選ぶか生のフレーズを保持することで、ユーザーから少なく頼むべきです。テキストレンダリングに軽量な不確実性マーカーも探索しています。ダウンストリーム UI が低信頼スパンをハイライトして、ディクテーションリズムを壊さずに素早いキーボード修正ができるようにするためです。

三番目の方向は非言語音響です。その業務はまだプロトタイプ段階で、別途 sounds with meaning でカバーします。強化学習とマルチモーダルリスナーに関する業務とともに、私たちのオムニモーダル音声入力スタックの次の 1 年のアジェンダを形成します。