マルチモーダル音声認識: 画面を見るリスナーを作る

音声のみの音声認識は、残りの失敗が過小評価されやすいほどに良くなりました。クリーンな音声ベンチマークは本当の製品問題を隠します: ユーザーはアプリ内、可視コードの周囲、混合言語、「この関数」や「上のブレット」のような部分参照でディクテーションします。

ASR がまだ失敗する場所

古典的な例は同音異義語です。「From foo import bar」と from foo import bar は似た音ですが異なる世界に属します。カーソルが TypeScript ファイルにあるとモデルが知らなければ、「cache the auth client」と「cash the auth client」も同様です。音声だけでは宛先を確実に推論できません。

コード識別子はこれを鋭くします。ユーザーが「fetch profile」と言うかもしれませんが、可視の関数は fetchProfile です。書き起こしモデルは言葉を聞きます。ディクテーションモデルは識別子を保持すべきです。マルチモーダル音声認識は可視テキストを装飾ではなく証拠として扱います。

指示詞は三つ目の鋭いエッジです。ユーザーが「これをガード句で置き換えて」と言うとき、話されたテキストは技術的には完全な要求ですが、その意味は完全に「これ」が何を指すかに依存します。選択認識や安定したカーソル参照がなければ、システムは推測しなければならず、間違った推測は再タイプより時間を無駄にします。音声のみの ASR は指示詞をまったく解決できません。指示語を書き起こして、ダウンストリームツールがそれを解明することを願うだけです。

• 同音異義語: 平易な英語 vs コード構文。
• エンティティ: パッケージ名、クラス名、ファイルパス、コマンドフラグ。
• 指示詞: 「これ」「それ」「上記」「選択された部分」。
• フォーマット: 散文、ブレット、コードコメント、コミットメッセージ、プロンプト。

マルチモーダルリスナーアーキテクチャ

Loqua のリスナーには三つのローカル入力があります: ストリーミング音声特徴、画面由来コンテキスト、アプリメタデータ。音声経路は何が言われたかを提案します。コンテキスト経路はテキストが着地する場所を要約します: アプリ、フィールドタイプ、選択テキスト、近接トークン、可視の構造的手がかり。アプリ経路は改行、Markdown、コード構文が適切かどうかなどの制約を加えます。

リスナーは画面全体を人間のように理解する必要はありません。ディクテーションに必要な最小限の有用な証拠が必要です。VS Code では、可視識別子、言語モード、選択コードかもしれません。Slack では、スレッドトピックと最近のトーン。Notes では、見出しレベルとリストコンテキスト。

意図的にしないこと

いくつかの機能は意図的にスコープ外です。リスナーはリモートコンテンツのスクリーンショットで OCR を実行せず、ユーザーが積極的にタイプしていないウィンドウを要約せず、永続的な視覚履歴を構築しません。画像から細かい意図を推論しようともしません: グラフ、ビデオフレーム、デザインキャンバスは解釈されず、周囲のテキストのみが解釈されます。それぞれの除去は、予測可能性とよりクリーンなプライバシー境界のために能力をトレードする意図的な製品選択です。

これが、私たちが狭い製品的意味でのみ audio visual dictation と呼ぶ理由です: ライティングのための音声 + 視覚コンテキスト。目標は汎用的な視覚推論ではありません。目標はカーソル位置でのより少ない間違った言葉です。

画面コンテキストが曖昧性をどう解消するか

画面コンテキストディクテーションは可能性を制約することで出力を変えます。カーソルが Python ファイル内にあり、可視行にすでに from fastapi import が含まれていれば、話された単語「router」は汎用名詞よりもシンボルである可能性が高いです。カーソルが Gmail にあれば、同じフレーズは文になるべきです。

リスナーは選択認識編集も扱います。テキストが選択されている場合、ディクテーションはユーザーが明示的に新しい散文を挿入するよう頼まない限り、そのテキストに対する指示として解釈されます。その一つの区別がアクシデンタル重複テキストのクラス全体を取り除きます。

コンテキスト競合は最強の証拠を最初に信頼することで扱われます。アクティブアプリはオペレーティングシステムによって構造的に保証されているので最も信頼できる信号です。選択テキストが次に来ます。可視近接トークンは古かったり偶然だったりするので最も柔らかい信号です。二つの信号が一致しないとき、リスナーはより硬いものを優先し、選んでコミットするのではなく信頼度を下げます。

プライバシー: 画面コンテキストはローカルに留まる

コンテキスト認識音声認識は注意深く実装されなければプライバシーコストがあります。Loqua のルールは、リスナーが必要とする画面コンテキストはデフォルトでローカルに留まるということです。コンテキストサマリーはオンデバイスで計算され、現在の発話を形作るために使われ、汎用的な画面ログとして保持されません。

具体的に、オンデバイスリスナーに届くのは短く一時的なコンテキストバンドルです: アクティブアプリ識別子、言語とフィールドタイプ、選択範囲、近接する可視テキストの数百文字。デフォルトでデバイスを去らないのは、より広いウィンドウコンテンツ、他のタブ、他のアプリ、上記の永続的な履歴です。オプションのクラウド機能は、ユーザーが有効化したとき、ハイブリッドプライバシーノートですでに記述された境界の下でディクテーションされた音声またはテキストを受け取ります。生のコンテキストバンドルは決して受け取りません。

この境界が重要なのは、見るものを見るリスナーがコード、メッセージ、ドラフトを観察する可能性があるからです。それを機密データとして扱います。プライバシーアーキテクチャは 私たちのハイブリッドプライバシーノートでより詳しくカバーされていますが、要約版は明確です: 画面コンテキスト経路はローカルファースト、オプションのクラウド機能は生の周囲画面コンテンツを受け取りません。

公開研究コンテキスト

研究背景には音声-言語モデリング、視覚-言語投影、マルチモーダル命令チューニングが含まれます。有用な出発点には、堅牢な ASR の Whisper、視覚命令チューニングパターンの LLaVA、モーダル間アラインメントの ImageBind が含まれます。

それらの論文は文献コンテキストです。Loqua のマルチモーダル音声認識スタックは Mac ディクテーション表面のために調整されたオリジナル業務です: ローカルコンテキスト、低レイテンシストリーミング、アプリ認識出力。分野の語彙を借りるのであって、依存チェーンではありません。

ロードマップ

次のステップはより良い不確実性報告です。コンテキストが二つの可能な識別子を示唆する場合、システムは信頼を発明するのではなく曖昧性を保持すべきです。ターミナル、スプレッドシート、IDE チャットパネル、デザインツールのためのよりきめ細かいアプリアダプタも欲しいです。そこでは有用な出力の形が劇的に異なります。

ターミナルアダプタが最も具体的な近期業務です。ターミナルはカーソル位置の単一行として構造的にありますが、コンテキスト的にはユーザーが次にタイプしようとしているものに情報を提供すべき以前のコマンドと出力の長い履歴です。スプレッドシートアダプタは反対の形です: 厳格なカラム意味を持つ小さな可視コンテキストウィンドウ。両アダプタは同じリスナーアーキテクチャを再利用します。違いは、何が証拠とみなされるか、talker がフォーマット手がかりをどこから引くかです。

長期方向は「モデルがすべてを見る」ではありません。より狭く、より安全なものです: リスナーは、意図したものを意図した場所により少ないクリーンアップで書くのに十分なローカルコンテキストを見ます。それがマルチモーダル音声認識の製品約束です。