【ITニュース解説】Critical-entity error rate: the metric WER can't see

音声認識システムは、私たちが声で操作する多くのサービス、例えば電話の自動応答システム（IVR）などで不可欠な技術である。これらのシステムが正確に意図を理解することは極めて重要だが、その性能を評価する従来の指標「単語誤り率（WER: Word Error Rate）」には限界がある。WERはシステムが認識した単語と本来の発話単語との誤りの数を単純に数えるが、すべての単語の誤りを同じ重みで扱ってしまう。

例えば、「私は豆を食べました」と「1万ドルを振り込みます」という発話で、それぞれ単語が一つ誤認識されたとする。WERはどちらも同じ程度の誤りとして評価する可能性がある。しかし、実際のシステム運用では、豆の誤認識は軽微であるのに対し、金額の誤認識は顧客に重大な被害をもたらし、企業に深刻な影響を与える可能性がある。WERは、このような「誤りの重要度の違い」を区別できないのだ。

IVRシステムのようなタスクにおいて、システムが誤動作する原因となるエラーは、単語全体に均等に散らばっているわけではない。むしろ、金額、日付、口座番号、肯定/否定、キャンセル/確認といった「重要エンティティ」と呼ばれる特定の情報に集中している。これらの重要エンティティが誤って認識されると、たとえそれ以外の一般的な単語が多数誤って認識されてもタスク自体は完了するが、その完了が意図と異なる結果を招くことがある。そして、誤った完了は、タスクが完了しないことよりも悪い結果を生む可能性がある。

そこで注目されているのが「重要エンティティ誤り率（CEER: Critical-Entity Error Rate）」という新しい評価指標である。CEERは、前述の「重要エンティティ」における破損のみを数え、それ以外の単語の誤りは考慮しない。これにより、システムの機能にとって本当に致命的な誤りに焦点を当てて評価できる。

CEERは、システムが認識すべきだった重要エンティティのセット（参照）と、実際に認識した重要エンティティのセット（観測）を比較して測定される。エンティティは「タイプ」と「正規化された値」のペアで表現される。例えば、「（タイプ：金額、正規化された値：50ドル）」といった形である。正規化とは、「500」と「five hundred（五百）」が同じ金額を意味する場合、これらを一つのエンティティとして扱う処理であり、本質的な意味の誤りに焦点を当てるために行われる。

CEERの計算はシンプルで、「（本来あるべきものがなかったエンティティの数 ＋ 本来ないはずなのにあったエンティティの数） ÷ 本来あるべきだったエンティティの総数」で算出される。つまり、欠落したエンティティと余計に生成されたエンティティの合計を、期待されるエンティティの数で割る。

CEERには二つの重要な特性がある。一つは「無制限である」という点だ。CEERの値は1.0を超えることがある。例えば、「50ドル」と言うべきところで「15ドル」と認識された場合、これは「50ドル」というエンティティの欠落と、「15ドル」というエンティティの誤生成として二重にカウントされる。そのため、CEERは2.0となる。これは、誤った金額で行動することが、金額がない状態で行動することと同じではないという、タスクへの影響の深刻さをより正確に表現するための設計である。

もう一つは「管理すべきエンティティがない試行では『null』を報告する」という点だ。試行中に重要エンティティが一つも含まれていない場合、CEERは「0（誤りなし）」とはならない。測定対象がないため、「測定されなかった」という意味で「null」と報告される。これは、システムが重要エンティティをどれだけカバーしているかを正直に示す仕組みである。

具体的なシナリオでWERとCEERの違いを比較してみよう。

例えば、金額の誤り。「50ドルを貯蓄口座に送金してください」が「15ドルを貯蓄口座に送金してください」と認識された場合、WERは0.20と比較的低い。しかし、CEERは2.0となる。これは、タスクの核心である金額情報が完全に誤ったためであり、ビジネスへの影響は大きい。WERは単語の誤りを数えるだけだが、CEERは重要情報の破壊を指摘する。

次に、日付の誤り。「5日に請求書を支払ってください」が「9日に請求書を支払ってください」と認識された場合、WERは0.17とさらに低い数値だが、CEERは再び2.0となる。支払い日の遅延は延滞料や追加対応の発生につながり、WERでは捉えきれない深刻な問題だ。

一方、「カードをキャンセルしないでください」が「カードをキャンセルしてください」と認識されたケースでは、WERは0.33と3つの例の中で最も高い。しかし、CEERは0.5と最も低い値を示す。なぜなら、この発話には「否定」と「キャンセル行動」という二つの重要エンティティがあり、誤ったのは「否定」の部分だけで、「キャンセル行動」自体は認識されたと判断されるためである。

これらの例から明らかなように、WERが最も悪い試行がCEERでは最も良い結果を示し、逆にWERが最も良かった試行がCEERでは最も悪い結果を示している。つまり、WERとCEERは異なるものを測定し、異なる優先順位を導き出す。WERでエラーを分類すると、ビジネスへの影響が小さい問題を優先的に修正してしまう可能性があるが、CEERで分類すれば、コンプライアンスチームも同意するような、より重大な問題を優先できる。

CEERの測定フレームワークは、計算方法などを規定する一方で、「何が重要エンティティか」という具体的な定義は、各システムを開発・運用するチームが決定することになっている。システムが言葉で何を行うかによって、重要視すべきエンティティは異なるため、この柔軟性は重要である。また、CEERの信頼性は、エンティティのアノテーション（注釈付け）の正確さと網羅性に依存する。アノテーションされていないデータではCEERは「null」と報告され、実際のカバー率を示唆する。

CEERは、システムがタスクを失敗させた原因（アトリビューション）と組み合わせることで、さらに詳しい洞察を提供する。例えば、音声認識が原因でタスクが失敗した場合（SPEECH_ATTRIBUTABLE）、CEERの値によってその問題が「認識器による重要エンティティの破損」なのか、それとも「単語の誤りがあったが、下流システムがそれを処理できてタスクは完了したものの、NLU（自然言語理解）に堅牢性の問題がある」のかを区別できる。これにより、問題の担当チームと具体的な修正方法を明確に特定できるため、両方の指標が必要となるのだ。

現時点では、CEERの仕組みは確立されているものの、まだ実際のデータセットに広範囲にわたる重要エンティティのアノテーションはなされていない。そのため、現在CEERは主に illustrative（例示的）なインプットで動作を確認している段階であり、本格的な測定値は今後のアノテーションの進展を待つことになる。

運用上の重要な教訓は、システムのリリース承認基準を「単語の誤り」ではなく、「重要エンティティの破損」に設定することである。例えば、新しいシステム候補がWERをわずかに改善してもCEERが悪化している場合、それはシステムが見た目だけ良く見せながら、実は重要な情報を誤認識するようになっている可能性があるため、リリースすべきではない。WERだけでは、このような危険な変化を見抜くことは不可能である。あなたのチームは、前回のリリースにおける音声認識エラーが、どれだけ重要エンティティに影響を与えていたかを把握しているだろうか。もし知らないのであれば、あなたのシステムの最も重要な部分は無防備なままになっているかもしれない。