ビームサーチは、複数の有力な文字起こし候補を保持することで、ローカル音声認識の精度を向上させられます。ただし、ビーム幅を広げると、デコーダーの処理量、メモリ使用量、応答遅延が増加します。
このトレードオフは、明瞭な音声なら小さなビームでも正しくデコードできる一方で、ノイズの多い音声、名前、曖昧なフレーズでは、より多くの仮説を保持したほうが有利になる場合に現れます。
貪欲デコーディングは1つの経路に早く決めすぎる
音声認識器は、トークンや記号ごとの確率を出力します。貪欲デコーディングでは、その時点で最も有力な選択肢だけを残します。高速である一方、後になってより有力になる可能性のある別の候補を破棄してしまうことがあります。
PyTorchのCTCデコーディングチュートリアルでは、語彙と言語モデルに対応したビームサーチを紹介しており、1つの経路ではなく複数の部分仮説を保持します。PyTorchは、CTCビームデコーディングとより単純なデコーディング経路を対比し、複数の仮説を保持することで、初期段階での貪欲な決定を避けられる理由を示しています。詳しくはPyTorchのCTCビームサーチデコーダーをご覧ください。
これは、音響的な証拠が曖昧な場合に重要です。一時的には2番目に有力なトークン列でも、後になれば最も可能性の高い完全な文字起こしになることがあります。
ビーム幅が検索予算を決める
ビーム幅は、各展開ステップで何本の候補列を生き残らせるかを制御します。
ビーム幅を広げると、初期段階の局所的な誤りから回復できる可能性が高まります。
Torchaudioでは、beam_widthを検索中に使用するビームサイズとして公開しています。生き残る仮説が増えるほど、スコアリング、メモリ、比較に必要な処理も増えます。NVIDIA Rivaではビーム方式のデコーディングオプションを提供しており、ビーム幅が音響エンコーダー自体の特性ではなく、設定可能な検索予算であることを示しています。詳しくはNVIDIAのビームデコーダーのドキュメントをご覧ください。
正しい列がすでに小さなビームの上位に留まっている場合、ビームを広げても意味のある精度向上はなく、処理量だけが増えます。効果は誤りの分布によって異なります。
枝刈りで組み合わせ爆発を防ぐ
枝刈りを行わなければ、各仮説は各ステップで多数のトークンに分岐する可能性があります。
ビームサーチでは、スコアの低い分岐を繰り返し削除し、候補集合の大きさを一定範囲に保ちます。
PyTorchは専用のCTCビームサーチデコーダーを提供し、検索ロジックを音響モデル自体から分離しています。SpeechBrainでは、デコーディング中に候補列を枝刈りするCTCビームサーチのパラメーターを公開しており、SpeechBrainのCTCビームデコーダーで説明されている検索制御の仕組みを利用できます。
したがって、遅延の原因は考えられるすべての文字起こしを列挙することではなく、追加の仮説を管理してスコアリングすることにあります。
言語モデルによって勝者となる仮説が変わる
音響スコアだけでは、もっともらしい2つのフレーズを区別できない場合があります。デコーダーは語彙や言語モデルのスコアを追加できるため、音響的にはやや劣る経路でも、そのフレーズの言語的な自然さが高ければ上位に入る可能性があります。
PyTorchの例では、ビームデコーディング中のKenLMと語彙制約を明示的にサポートしています。CTCとアテンションを組み合わせたデコーディングの研究では、複数のモデルスコアをビームサーチの順位付けに利用できることが示されています。詳しくはCTC・アテンション統合ビームサーチをご覧ください。
これは、言語モデルが家庭内の人名や繰り返し使われるフレーズを適切に表現している場合に役立ちます。一方で、発音自体は正しい珍しい用語が、一般的な別の候補に偏ってしまうこともあります。
ビームサーチが増やすのは主にデコーダーの遅延であり、エンコーダーの処理量とは限らない
ビームサーチでは通常、音響特徴量が生成された後の処理量が増加します。
エンコーダーは同じ速度で動作していても、より多くの仮説を展開するため、文字起こし全体の遅延が増えることがあります。
PyTorchでは、CUDAベースのCTCビームサーチデコーダーについても説明しており、検索処理をアクセラレーターに移せる実装があることを示しています。GPUで高速化したビームサーチに関する研究では、デコーディング自体が無視できない計算段階になり得ることが示されており、GPU高速化ASRビームサーチで述べられている遅延の違いを裏付けています。
ZimaSpaceのローカル音声アシスタントの遅延分析では、インタラクティブな音声リクエストにおいて、デコーディングは全体の一段階にすぎないという、より広い視点を解説しています。
有用なビームとは、精度を維持できる最小のビーム
ビーム幅は、家庭内の実際の音声を使い、単語誤り率とエンドツーエンドの遅延を基準に調整する必要があります。目標は、サーバーが維持できる最大のビーム幅ではありません。
TorchaudioはストリーミングRNN-Tビームサーチに対応しているため、インタラクティブな音声操作では遅延が特に重要になります。ベクトル化ビームサーチに関する研究では、有用な仮説を維持しながら検索コストを削減することに焦点を当てており、ベクトル化ビームサーチの研究で示されている実用的な打ち切り基準を裏付けています。
それでも、上流の音声品質が回復可能な範囲を制限します。ZimaSpaceの遠距離音声認識の失敗分析では、検索では再構成できない情報損失について解説しています。
よくある質問
ビーム幅を広げれば、必ず単語誤り率は下がりますか?
いいえ。改善効果が頭打ちになることがあり、言語モデルの重み付けや枝刈りが適切でない場合は、誤りがなくなるのではなく別の誤りに置き換わることもあります。
外部の言語モデルがなくてもビームサーチは役立ちますか?
はい。音響的に有力な複数のトークン経路を保持できます。外部の言語モデルは、追加のスコアリング信号です。
ビームサーチによって音声モデル自体の処理が遅くなりますか?
主に増えるのはデコーダーと検索の処理です。音響エンコーダーは同じ速度で動作していても、文字起こし全体の遅延は増加する可能性があります。
テック&AIハブ
もっと読む

Home Assistantにおけるランタイム状態と永続状態:再起動後も維持すべきものは?
Home Assistantはすべてのライブ値を永続化するわけではありません。設定、レジストリ、選択された復元状態、履歴、デプロイデータは、再起動時にそれぞれ異なる役割を果たします。

Home Assistantはローカルセッションとリモートセッションをどのように認証しますか?
ローカルおよびリモートのHome Assistantセッションでは、同じサーバー側のIDモデルを使用します。リモートアクセスによって変わるのは経路とTLSの境界であり、トークンフローの中核ではありません。

Recorderデータが増えると、なぜHome Assistantの履歴クエリは遅くなるのですか?
レコーダーの成長に伴い、要求された範囲に含まれる行数が増えたり、キャッシュミスが増加したり、ストレージやインデックス処理が遅くなったりすると、履歴クエリのコストが上昇する可能性があります。

