【モデル選定】 通話記録の要約にAmazon TranscribeとClaude-instantを選んだ経緯

はじめに

こんにちは、Airion株式会社でインターンをしている欄木です。

今回、ラクスル株式会社さんとともに、顧客応対電話音声を文字起こし、要約するシステムの開発をしました。その際に、実用化レベルとして十分な音声認識モデル・要約モデルの選定や、音声認識・要約の精度を上げる取り組みを行いました。

今回のプロジェクトの総まとめを音声モデルの選定、音声モデル及び要約モデルのチューニングの2段階で紹介させていただきます。

音声認識モデルの選定

音声認識に用いるモデルを以下の5つのサービスから選定しました。

• Amazon Transcribe（Amazon）
• Azure Speech to Text（Microsoft）
• Whisper（OpenAI）
• Google Cloud Speech-to-Text（Google）
• AmiVoice（アドバンスト・メディア）

whisperとGoogle Cloud Speech-to-Textはデフォルトでは話者認識機能が備わっていないため、Pyannoteを用いて話者分離を実装しています。

評価基準としては、音声認識の精度・処理時間・価格などありましたが、今回は特に音声認識の精度について重点的に紹介します。

アノテーション作業

会話音声は、フィラーが多く含まれることや、二人同時に発声することなどから、正確な文字起こしが難しいという問題があります。

そこで今回は、複数の顧客応対電話音声を文字起こしして作成されたスクリプトを元に、再現音声を作成することで、正確なアノテーションがつけられた音声データを作成しました。プロジェクト終盤で行った本番トライアルまではこれらの音声について検証を行っています。

認識誤りの数（CER・WER）の評価

まず、CERやWERを用いた認識誤り数の評価を行いました。漢字変換を含めた比較であるCER・WERに加え、純粋に音が聞き取れたかを評価するためにかな変換や音素変換をした、かなCER・音素CER・かなWERも評価しました。

各検証音声のCER・WER値のアノテーションデータの文字数に応じた加重平均を以下に示します。各セルの左右にそれぞれ話者分割をしない場合とした場合の値を載せています。

CERやWERはズレの大きさを測るので、値が小さい方が高精度です。

検証の結果、話者分割無しではAmiVoiceが高精度なのですが、話者分割有りにするとAmazon Transcribe、Azure Speech to Textが高精度であると評価されました。この結果を見ると、AmiVoiceは、純粋な音の検知は得意だが、話者分割の精度が低いということが分かります。

また、Whisper及びGoogle Cloud Speech to Textの音声認識の精度が低いのですが、これは恐らくPyannoteを用いた話者認識の実装の影響であると考えられます。また、この実装故に音声認識の処理時間がDiarization録音データの実時間を大きく超えており、実用的では無いと判断しこれ以降の検証対象から外しました。

認識誤りの程度（BertScore）の評価

次にBertScoreを用いた意味的な評価を行いました。

各検証音声のBertScore(F値)のアノテーションデータの文字数に応じた加重平均を以下に示します。

BertScoreは、単語ベクトル内積を取っている感覚に近く、大きさが1に近い程、高精度です。

検証の結果、意味的な評価でも、3つのモデルの精度は大きく変わらないということが分かりました。

要約の精度（目視）による評価

最後に要約モデルを用いた検証を行いました。文字起こしの内容に誤りが多数含まれており、さらにAmiVoice以外のモデルではフィラー除去が十分に出来ない（詳しくは「フィラー除去」の項目に書きました。）ので、この状況でも十分な精度の要約が出来る音声認識モデル及び要約生成モデルのセットを調査しました。

認識誤り程度の評価同様に、参照文をアノテーションにしたBertScoreを用いた定量的な評価が一般的に用いられていますが、重要な出来事のみの要約文よりも、全ての出来事を記述する方が高精度と判別される指標となっており、更にプロンプト指示の内容を考慮できないため、今回は使用しませんでした。

そこで、文字起こしされた文章がプロンプト指示の内容に沿って要約されているかどうか定性的に評価しました。評価の結果、そこまでAPI代の高くないLLMのClaude-instantを用いても、3モデル全ての書き起こし結果を十分に要約出来ることが分かりました。

評価項目の総まとめ

Amazon Transcribe、Azure Speech to Text、AmiVoiceの3モデルについて音声認識の精度・処理時間・価格のそれぞれの評価項目から見た、それぞれの音声認識モデルの性能をまとめます。料金及び、処理時間についてはラクスルでの1日分のトライアル結果を元に、大凡の比率を載せます。

• 認識精度
  • 3モデルの音声認識精度には大きな差が無い。 辞書登録まで行うと、Azure Speech to Textがやや高精度か（詳しくは「辞書登録」の項目に書きました。）
• 処理時間
  • Amazon Transcribeが最短、Azure Speech to Textが約1.8倍、AmiVoiceが約3.4倍
• 価格
  • Azure Speech to Textが最安、AmiVoiceが約3倍、Amazon Transcribeが約4倍
    　

以上の結果を踏まえて、音声認識モデルとしてAmazon Transcribeを、要約モデルとしてClaude-instantを用いることが決定しました。（詳しくは要約モデルの選定）今回は通話終了後なるべく早く要約記録を確認したいという要望から、処理速度を重視しています。（因みに、BIZTELというサービスを用いて通話記録を取得しています。）

音声モデル及び要約モデルのチューニング

Claude-instantのプロンプトチューニング

プロンプトは、タスクについての説明・入力の注意事項・出力の注意事項・出力形式の4段落で構成されています。初めにシンプルなプロンプトを作成し、そこから本番トライアルを繰り返して、カスタマーサポートセンター担当者さんの意見をお伺いしながら、プロンプトチューニングを行いました。

プロンプトを長く書くほど、一つ一つの文章が無視されやすくなるので、重要なことのみを書き、特に重要な文言は2度書くなどの工夫をしました。最終的に採用となったプロンプトを一部公開します。

辞書登録

ラクスルで扱う専門用語の多くはデフォルトでは音声認識されません。そこで、専門用語を辞書登録することで、音声認識されるようにしました。基本的な方針としては、印刷業界の専門用語集や、本番トライアル中に含まれていた専門用語などを登録しています。

結果として、「入稿」や「オペレーターチェック」といった専門用語（同音異義語も含む）が認識可能になりました。一方で、「入稿」（⇔「入港」）などの同音異義語については、モデルがコンテクストを解釈して正しい方を選ぶ精度は高くないので、出現頻度が高い場合のみ登録する方針となりました。また、語彙としてベースモデルに含まれていない単語（「ラクスル」等）は、そもそも雑音として認識され、音を聞き取らないことが多く、この問題に関しては、辞書登録では改善できなかったです。

因みに、Azure Speech to Textでは、辞書登録によって「ラクスル」を認識出来るようになったりしました…。

付録

要約モデルの選定

会話要約に用いるモデルを以下の5つのサービスから選定しました。

• GPT-4（OpenAI）
• GPT-3.5（OpenAI）
• Claude 2（Anthropic）
• Claude-instant（Anthropic）
• Azure AI Language summarization（Microsoft）

Azure AI Language summarizationは、会話の要約に特化したサービスであり、英語においてはGPT-4と同程度の性能をしていましたが、日本語での精度が悪く、プロンプトによるチューニングが出来無い上に、価格もGPT-4の20倍程度でした。

ラクスルの顧客応対電話音声は1時間を超えるものもあり、GPT-3.5の最大トークン数16kでは一度に入力・要約することが出来ず、要約の精度が他に比べて下がってしまいました。因みに、次に最大トークン数が小さいものはClaude-instantの100k（バージニア北部リージョンのみ）で、7時間程度の文字起こしを入力可能です。

また、GPT-4及びClaude 2はClaude-instantの10倍程の料金がかかるが、Claude-instantを用いた要約で精度が十分だと判断したため、今回はClaude-instantを選びました。

その他

• フィラー除去
  • 背景：AmiVoiceにはデフォルトで高機能のフィラー除去の機能がついているが、Amazon_Transcribe、Azure Speech to Textにはフィラー除去の機能が無い。
  • GiNZAやChatGPTを用いた手法を試したが、処理時間が伸びる割にフィラー除去の精度がAmiVoiceに比べて低かった。
  • フィラー除去をしても、要約タスクの精度には大きな影響は無かった。
• 音声ファイル形式
  • 背景：音声認識モデルは、二人同時に発声したときに片方のみが発声していると認識し、話者認識および音声認識の精度が下がることが考えられた。
  • 上り下り分離した音声での検証を行ったが、価格や処理時間の倍増に見合うほど、精度が向上しなかった。
  • 今回はモノラル音声を採用した。
• 音声認識モデルのファインチューニング
  • 背景：ファインチューニングによって、辞書登録と同様に専門用語の認識精度が向上することや、フィラー除去の精度が向上することが考えられた。
  • アノテーション作業が大変なため、今回は行わなかった。