ウェイクワード検出を有効にしたときだけ、ローカル音声モデルの処理が遅延するのはなぜですか？
ウェイクワード検出を有効にすると、常時稼働する検出器が前処理、バッファリング、スケジューリング、音声の引き渡し処理を追加で行うため、ローカル音声モデルの反応が遅くなることがあります。
ウェイクワードを使わない場合、ユーザーはボタンを押して、1つの雑音の少ない録音を音声認識へ直接送信できます。ウェイクワードを使うと、ホームサーバーは短い音声フレームを継続的に取得し、特徴量を抽出し、トリガーモデルを評価し、プリロール音声を保持し、音声活動検出と文字起こしへ制御を移すタイミングを判断します。これらの処理がCPUコア、オーディオデバイス、キュー、メモリを共有している場合、音声モデル自体が変わっていなくても、追加されたゲート処理によって、もともと高速だったローカルモデルの動作が遅くなることがあります。
ウェイクワード検出は常時稼働する推論ループを追加する
ウェイクワードエンジンは、ユーザーが録音を開始した後だけでなく、音声を継続的に検査する必要があります。信号を繰り返しフレーム化し、音響特徴量を計算し、小型の分類器を評価します。
Picovoiceのウェイクワードガイドでは、検出器を、より大規模な音声パイプラインの前段で動作する常時稼働の起動レイヤーとして説明しています。
小型のモデルでも、CPU時間とメモリ帯域を継続的に消費します。リソースに余裕のないホームサーバーでは、この継続的な負荷によって、VAD、Whisper、音声合成に必要な短時間のCPU処理が奪われることがあります。
ウェイクワードと音声認識で音声前処理が重複することがある
検出器と音声モデルがそれぞれ個別に音声のリサンプリング、振幅の正規化、スペクトログラムの計算、チャンネル変換を行う場合があります。別々のコンテナで実行していると、この重複を把握しにくくなります。
実際のWhisperパイプラインを検証した記事では、共有ストリーミング設計なしに音声前処理の各段階を連結すると、レイテンシが積み重なることが示されています。
各コンポーネントを単独でベンチマークすると良好でも、パイプライン全体は遅くなります。1つのデコード済み音声ストリームと、対応する1つのサンプルレートを再利用すれば、認識品質に寄与しない変換を減らせます。
検出器が原因ではなく、オーディオアダプターが行っている処理が原因になっていないよう、特徴量抽出とリサンプリングはモデル推論とは分けて測定してください。
プリロールバッファが検出後の引き渡しを遅らせることがある
音声システムでは通常、ウェイクワードの直前から音声を保持して、コマンドの冒頭が失われないようにします。検出後、このバッファを再生するか、認識エンジンのストリームへコピーする必要があります。
Rhasspyのユーザーは、トリガー検出からASRがコマンドを受信し始めるまでの再生バッファによるレイテンシについて説明しています。
大きすぎるプリロール、ブロッキングコピー、バッファ全体のフラッシュによって、最初の推論が遅れて開始されているだけなのに、認識エンジンの動作が遅いように見えることがあります。
トリガーの発生時刻、最初のASRフレーム、発話終了の判定時刻、最初の文字起こし結果を記録してください。最も大きな時間差から、遅延が認識前に発生しているのか、認識処理中に発生しているのかを特定できます。
共有CPUコアとオーディオキューが競合を生む
ウェイクワード検出、VAD、エコーキャンセル、文字起こし、音声合成は、すべて同じCPUで実行されることがあります。スレッドスケジューリングやオーディオキューの満杯によって、ある処理が別の処理を遅らせる可能性があります。
ローカル音声アシスタントの構築例では、音声処理全体のレイテンシは、言語モデルや音声モデルだけでなく、パイプライン全体に左右されると説明されています。
ZimaSpaceによるサーバーの隠れた飽和状態に関する説明も当てはまります。CPU使用率の平均が低くても、1つのコアや直列化された1本のオーディオスレッドに負荷が集中していることがあります。
すべてのコンポーネントを別々のコアに固定する必要があるとは限りませんが、キューの深さ、スレッドごとのCPU使用率、音声フレーム1つあたりの処理時間は、実際のリアルタイムフレーム間隔を下回る状態に保つ必要があります。
誤検出によって高負荷な処理が繰り返し起動されることがある
ウェイクワードの誤検出が発生すると、VADの開始、音声モデルのロードまたは起動、バッファ音声の再生、コマンドを待つ処理が実行されることがあります。しかし、実際にはコマンドが存在しない場合もあります。
ウェイクワードのアーキテクチャに関する記事では、誤受理と、トリガーの取りこぼしや検出遅延とのバランスを取る必要性が説明されています。
似た音声による誤反応が頻繁に起きると、音声パイプラインが起動済みまたは処理中の状態になり、本当のコマンドが破棄されたセッションの後ろで待たされることがあります。
トリガーの信頼度、トリガーの頻度、セッション時間、利用可能な音声が続いたかどうかを記録してください。しきい値を上げる方法は、誤棄却が許容できないほど増えない場合にのみ有効です。
検出器と引き渡しを別々のレイテンシ段階としてベンチマークする
プッシュ・トゥ・トーク、ウェイクワード有効、ASR停止状態でのウェイクワード有効、通常のバックグラウンド負荷下でのウェイクワード有効を比較してください。マイク、コマンド、音声モデルは同じものを使用します。
技術解説では、ウェイクワードシステムを、各段階に個別の計算予算とレイテンシ予算があるカスケード型ストリーミングシステムとして説明しています。
音声フレームの遅延、検出時間、キュー待ち時間、バッファ再生、モデルの起動、ASRのプリフィル、デコード時間を記録します。そのうえで、ウェイクワードを有効にしたときに変化する段階を最適化してください。
実際の解決策は、小型の検出器、共有オーディオ前処理、短いプリロール、上限付きキュー、専用スレッド、または音声モデルの常駐化かもしれません。音声が届く前に遅延が発生しているなら、音声モデルを置き換える必要はありません。
おすすめ商品
テック＆AIハブ
もっと読む
機密ファイルを取り巻くホームAIの信頼境界を実現する機能とは？
家庭用AIの信頼境界は、保存時暗号化、最小権限のアクセス許可、ランタイムサンドボックス化、スコープを限定した検索を組み合わせたものであり、単一の機能だけでは成り立ちません。
プライベート検索結果が頻繁に編集されたファイルを優先する原因とは？
頻繁に編集されるファイルは、更新のたびに鮮度、チャンク、バージョン、またはインタラクションシグナルが追加され、ソースによる正規化が行われない場合、ランキング上の優位性を獲得します。
スマートホームの在宅検知モデルが来客と住人を混同する原因とは？
システムが世帯の活動パターンを観測していても、その活動を生み出している人物の安定した識別情報がない場合、来訪者が居住者のように見えることがあります。
