WERは、名前の間違いや数字の間違い、抜けた「not」を、「the」の脱落と同じ重みで数えます。文字起こしシステムは見出しの数値ではなく、どの誤りを捕まえるか、そして修正を確認できるかで判断してください。
単語誤り率（WER）は、音声認識を評価する標準的な物差しです。人が確認した参照用の文字起こしを用意し、機械の出力を単語ごとに突き合わせて、三種類の誤りを数えます。置換（間違った単語）、挿入（言われていない単語の追加）、削除（欠けた単語）です。これらを合計し、参照文の単語数で割ります。
WER = (置換 + 挿入 + 削除) / 参照文の単語数
突き合わせは目視で行うわけではありません。二つの文字起こしは、最小編集距離（レーベンシュタイン距離を文字ではなく単語に適用したもの）によって揃えられます。出力と参照文を対応づける全ての方法のうち、採点者は編集回数が最も少ないものを選び、その回数を数えます。挿入も数えられ、分母は参照文の長さなので、WER は 100％ を超えることがあります。静かな一分間に文章を書き足すモデルは、何も書かないモデルより悪い点数になるのです。
参照文が「we will meet Dr Okafor at nine on Thursday」という九単語で、機械が「we will meet the doctor at nine on Tuesday」と書いたとしましょう。置換は三つ（Dr、Okafor、Thursday）で、九単語に対して三つなので、WER は 33％ です。単語の三分の二は合っていますが、それでも間違った会議に、間違った曜日で出席することになります。間違っているのが「Thursday」だけなら、点数は 11％ になります。全ての単語が合っていて、誰も言っていない「um」が一つ加わっただけでも、やはり 11％ になります。挿入は置換と同じ重みで数えられるからです。
数える前に、両方の文章は通常正規化されます。そして、その際の選択が、モデルの性能と同じくらいスコアを動かします。「Dr」と「Doctor」は同じ単語として扱うのか。「nine」と「9」は同じなのか。大文字小文字や句読点は数えるのか。厳密な採点では、「Dr」と「Doctor」は置換として誤りになります。公表されているスコアの多くは、比較の前に全てを小文字にし、句読点を取り除き、数字は単語か数字のどちらかに統一します。ベンダーの数値は、外からは見えない正規化の仕組みに、密かに依存しているのです。中国語、日本語、タイ語のように単語の間に空白がない言語には、明確な単語の境界がありません。そのため、代わりに文字誤り率（CER）で採点されます。同じ計算式を、単語ではなく文字に適用するものです。
ここから二つのことが言えます。第一に、WER が 5％ だとは、二十語に一語が誤りだということで、一時間の話では数百語に相当します。目安として、人間の書き起こし担当者は会話音声で 4〜5％ 程度とされることが多く、2017年の広く引用される結果では、電話音声コーパスの Switchboard で機械が約 5.1％ でした。ただし、どちらの数値も音声の内容と採点ルールによって変わります。第二に、この数値はテスト音声に完全に依存します。明瞭な読み上げ音声では一つの数値になり、訛りや話者の重なりがある騒がしいパネル討論では、まったく違う数値になります。WER の見出し数値は、そのベンダーのシステムだけでなく、ベンダーのテストセットも同じくらい表しているのです。
ここまでが数え方です。WER が見落としているのは、読み手にとっての各誤りのコストです。
WER はあらゆる単語を同じ重みで扱います。しかし読み手にとっては、そうではありません。
これらはそれぞれ、WER の列では一つか二つの誤りにすぎません。読み手の列では、何の影響もないものから、別の日の別の会議にまで及ぶものまで様々です。ですから問うべきは「誤り率はいくつか」だけではなく、「どのような誤りなのか、そして何がそれを捕まえるのか」なのです。
いくつかの層が、認識の誤りを捕まえます。そして全ての変更は記録されるので、検査も取り消しもできます。ライブの文字起こしでは、これは文章が届いている最中に行われます。各行はまず、まだ変わる可能性のある下書きとして表示され、その後確定します（ライブ翻訳の遅延についてで理由を説明しています）。
音は合っていても、文に合わない誤りがあります。たとえば、文が「there」を必要とする場所に「their」と書かれている場合です。こうした誤りは文脈から捕まえられ、修正は読み手には目に見える更新として伝わります（API では transcript.amended）。黙って書き換えられることはありません。文脈は、文が予測できる単語には強いです。しかし予測できない単語には、まったく役に立ちません。
名前や専門用語は、文脈では直せない誤りです。名前は一度しか出てこないことが多く、それを予測させる周囲の語がないからです。参照スクリプトがこの問題を解決します。話し言葉、スライド、名前や用語のリストを、始める前にシステムに渡しておけば、その語はエンジンが聞き違えた語より優先されます。収録中、スクリプトはプロンプターのように文字起こしに沿って進むため、ホストはエンジンの進み具合を確認できます。スクリプトは予測できる語を扱いますが、雑音や訛りが生む語は扱えません。
誤りの中には、部屋にいる人にしか見えないものがあります。手動修正では、文字起こしがまだライブの間に、ホストがどの単語や行も書き直せます。そして、ブロードキャストの全視聴者にその変更が見えます。システムはホストに修正すべき候補を指し示します。エンジンが確信を持てなかった単語には色が付き下線が引かれ、ホストは全文を読み直す代わりに、不確かな区間を一つずつ順に確認できます。API では、GET /v1/recordings/{id}/corrections で収録の修正一覧を取得し、POST /v1/corrections/{id}/revert で一件を取り消せます。詳しくは API リファレンス をご覧ください。ただし、部屋にいる人であっても、誰にも聞き取れなかった行は修正できません。
最後の層は、回復できない音声があることを受け入れます。行の信頼度が文字起こしの信頼度のしきい値（confidence.hideBelow、既定値 0.60）を下回った場合、視聴者にはその代わりに「Audio unclear」と表示され、推測は表示されず、その行が読み上げられることもありません。読み手は行を失いますが、捏造された行を得ることはありません。
これらの層を形作った問いは、どのベンダーの精度の主張にも当てはまります。VocalStack の主張も例外ではありません。
どの精度の主張も読むための、短いチェックリストです。
VocalStack は、内部の WER の数値を公表していません。理由は一つ目に述べたとおりです。その数値は当社のテストセットを表すもので、お客様の音声を表すものではないからです。当社は精度を継続的に計測しています。他システムと比較する場合は、公開されている独立したベンチマークとベンダーが公表した数値を使い、非公開のテストは使いません。残りはお客様ご自身の音声で判断してください。
