オフライン音声入力で画面のテキストツリーを活用し、LLMなしで精度を向上

ある開発者が、ユーザーの画面に表示されている現在のテキストを読み取ることで精度を向上させるオフライン音声入力ツール「Handy Context」の技術的な詳細を公開しました。2026年11月に発表されたこのプロジェクトは、スクリーンショットや大規模言語モデル（LLM）ではなく、アクセシビリティツリーを使用して音声モデルにバイアスをかける方法を示しています。このアプローチは完全にローカルで動作するため、クラウドベースの文字起こしサービスに対するプライバシー保護型の代替手段を提供します。

何が起きたか

Handy Contextの開発者は、基礎となる音響モデルを再訓練せずに音声認識に画面コンテキストを組み込むパイプラインを詳細に説明しました。このシステムは、凍結された音声モデルであるParakeet-unified-en-0.6bを使用し、アクティブなウィンドウのアクセシビリティツリーからテキストを抽出することで機能を強化しています。この手法により、音声入力ソフトウェアは、コード変数、スライドタイトル、ドキュメントヘッダーなど、ユーザーの現在のワークフローに実際に存在する単語を優先的に処理できるようになります。

初期の実験では、TCPGen技法と同様にリスト内の単語をコピーするために、凍結モデルの上に追加の層を訓練しました。しかし、これらの訓練済みバージョンは、未訓練のパイプラインよりも性能が悪く、提供された単語リストが話された音声と無関係である場合によくエラーを導入していました。開発者はまた、画面の単語を可能性の高い候補に絞り込むために小さなキーワードスポッターもテストしました。これらのスポッターは、正解マッチの98%を保持しながら1,000語のリストを約3語に削減しましたが、未訓練のパイプラインの方が全体的なスコアが良かったため、訓練されたコンポーネントは最終リリースには含まれませんでした。

他のいくつかの一般的なアプローチも、性能向上にはつながりませんでした。Qwen3-ASR-1.7Bのような音声LLMを1,000語のコンテキストで使用しても、リストがない場合と比較してエラーは減少せず、実行速度は10倍遅くなりました。Whisper large-v3-turboに語彙をプロンプトとして与えると、単語誤り率（WER）が3.53%から4.8%～5.6%の間まで増加しました。同様に、VoiceInkスタイルのスワップを適用すると、実際のスライドでのエラー率が8.25%から8.79%に上昇しました。これは主に、単語の末尾が誤って変更されたことによるものです。

仕組み

システムは、ショートカットキーが押されたときに最前面ウィンドウのアクセシビリティツリーを走査してコンテキストを取得します。静的テキストフィールド、見出し、ボタン、テーブルセルなどの要素からテキストを集め、4,000要素または350ミリ秒で停止します。このデータは、ウィンドウタイトルとフォーカスされたフィールドの最後の8,000文字と組み合わされます。抽出されたテキストは用語に分割され、一般的な単語や短い文字列は除外されますが、頭字語の大文字表記は保持されます。リストは、複数形や綴りのバリエーションをカバーするために、LibriSpeech語彙で見つかる活用形で拡張されます。

音声は一度エンコードされ、異なるバイアス戦略を用いて最大9回デコードされます。コアメカニズムは、NeMoのプレフィックスツリーブースターを使用し、画面コンテキストからの用語と一致するトークンにスコアを追加します。システムは、通常のデコードと、初期トランスクリプトとの類似性に基づいて用語をフィルタリングする2パスデコードを含む複数の候補トランスクリプトを生成します。類似性は、レーベンシュタイン距離とMetaphoneコードを使用して計算されます。最終的な候補は、バイアスなしのモデル下での正確な対数尤度を計算し、拡張用語リストに現れるすべての単語に対してボーナスを加えることで選択されます。

後処理ステップにより、出力はさらに精製されます。システムは、類似性閾値を満たす場合、勝者テキストから拡張リスト上の用語へのスワップを提案します。以前の試みでよくあったエラーの原因である、単語の末尾のみを変更するスワップは回避されます。固有名詞や頭字語については、画面上の綴りに合わせて大文字表記が調整されます。このプロセス全体はローカルサーバーで実行され、短い音声入力であれば半秒以内にテキストを受け取ります。

主要な詳細

• パイプラインは、リビジョン fe53cd8 の Parakeet-unified-en-0.6b を使用しており、モデル重みのファインチューニングは行っていません。
• 画面テキストはChromiumおよびElectronアプリのアクセシビリティツリーを通じて取得されるため、現時点ではこれらのフレームワークのみがサポートされています。
• Handy Contextのメモリ使用量は約7.1 GiBであり、PyTorchランタイムの影響により、基本のHandyモデルの0.84 GiBより大幅に高くなっています。
• システムは、最適な一致を見つけるために、異なるバイアス強度と2パスフィルタリング閾値を持つ9つの並列デコードを実行します。
• SlideSpeechおよびLibriSpeechデータセットでの評価により、通常のParakeetおよびVoiceInkベースラインの両方よりもリスト内単語のエラーが少ないことが示されました。
• このツールは現在英語のみをサポートし、単一のデスクトップオペレーティングシステムで動作します。画像ベースのテキストに対するOCR機能はありません。

なぜ重要か

音声インターフェースを構築するエンジニアにとって、この取り組みは、モデルを単純にスケールアップしたり、コンテキスト認識のためにLLMを追加したりすることの限界を示しています。Qwen3-ASR-1.7Bがそのサイズにもかかわらず精度を向上できなかった失敗は、特定のタスクにおいては、パラメータの数よりもアーキテクチャの適合性と効率的なバイアス機構の方が重要であることを示唆しています。OCRやスクリーンショットの代わりにアクセシビリティツリーに依存することで、視覚処理の計算オーバーヘッドなしに低遅延のコンテキスト統合を実現しています。

メモリフットプリントは、広範な採用における大きな障壁のままです。PyTorchでフル精度モデルを実行すると7 GiB以上のRAMを消費するため、多くの消費者向けノートパソコンでは現実的ではありません。しかし、著者はパイプラインをカスタムエンジンへ移植することでこれを4 GiB未満に削減できると指摘しています。精度とリソース使用量のこのトレードオフは、エッジデバイス上でオフラインAI機能を展開しようとする開発者にとって重要な考慮事項です。

訓練された代替案よりも未訓練のパイプラインが成功したことは、ドメイン適応には常にファインチューニングが必要だという前提にも挑戦します。堅牢なデコーディング戦略と事後スコアリングを活用することで、開発者は凍結モデルでも高い精度を達成できます。このアプローチはメンテナンスを簡素化し、破滅的忘却のリスクを低減するため、コンテキストが急速に変化するアプリケーションにおいて有効なパターンとなります。

できること

• アプリケーションのアクセシビリティツリーからテキストを抽出し、音声認識タスク用の動的語彙を構築してください。
• プレフィックスツリーブースティングを使用して、再訓練なしで既存の音声モデルをドメイン固有の用語にバイアスかけてください。
• 初期トランスクリプト仮説との類似性に基づいてコンテキストリストをフィルタリングするために、2パスデコーディングを実装してください。
• 単語の末尾や接尾辞のみを変更する誤ったスワップを防ぐために、後処理ルールを適用してください。
• PyTorchモデルをデスクトップアプリケーションに統合する際はメモリ使用量を監視し、最適化のためにカスタムエンジンを検討してください。
• コンテキスト対応システムの評価には、標準的な単語誤り率に加えてリスト内単語誤り率を使用し、具体的な改善を測定してください。