コールセンターの音声認識辞書を改善する ー 品番・氏名・住所のテスト手順

Amazon Transcribeのドキュメントは、カスタム語彙が有効なのはブランド名や略語、固有名詞など、ドメイン固有の語だと明記している。Google Cloud Speech-to-Textも同様に、モデルアダプテーションを「特定の語やフレーズを他の候補より優先して認識させる」機能として説明する。つまりどちらも、認識エンジンそのものを賢くするのではなく、候補の優先順位を傾ける仕組みである。

この区別が曖昧なまま辞書登録をすると、登録したのに現場の聞き間違いが減らない、あるいは別の単語が誤認識され始める、という事態になる。ここで立てたい問いは、辞書を変えた前と後で、業務上の聞き間違いが本当に減ったとどう言えるのかである。私の立場を先に書けば、辞書運用の本体は登録作業ではなく、登録前後を同じ条件で比べる検証設計のほうにある。

なお本記事のテスト手順は編集部が組み立てた実務設計案であり、特定製品の推奨手順ではない。適用可能なモデル・API版・語数上限・音声の利用権限は、各社のドキュメントと自社の契約で必ず確認してほしい。

1. 誤認識を品番・氏名・住所に分ける

「固有名詞が取れない」とまとめてしまうと打ち手が決まらない。コールセンター（コンタクトセンター）の通話で問題になる固有名詞は、少なくとも次の3種類に分けたほうが扱いやすい。辞書は薬に近い。 症状が違えば効く薬も違い、効かない薬を増やすと副作用だけが残る。

重要なのは、この3つで業務インパクトの大きさが違うことである。品番を1文字間違えれば違う商品が出荷される。氏名の漢字違いは本人確認で気づける場合が多い。住所の町名違いは配送で止まる。以前WERの数字と業務インパクトのズレについて書いたが、辞書改善でも同じことが起きる。全体の誤認識率を1ポイント下げるより、品番の誤認識を半分にするほうが業務では効く場合がある。

まず1〜2週間分の通話テキストから、有人で訂正が発生した箇所を抽出し、この3分類でタグ付けする。分類の件数分布を見ずに辞書を書き始めるのが、いちばんよくある失敗である。