Google Cloud Speech API vs. Amazon Transcribe

文字起こしAPIガチンコバトル

ググってざっと見れた範囲の「文字起こしAPI比較してみた」系記事では、数行（もしくは数分）レベルの非常に短い文字起こしを行いgood/badを述べているものが多いです。もしくはニュース動画のような"クリアすぎる音源"に対して行っているものも多いです。Amazon Transcribeについてバズっていたブログでも、英語での文字起こしで精度が高い話をしています。自然言語処理分野では英語の精度が高いのは知られているところですが日本語だとどうかというところが気になるところです。

自分が知りたいのは、
- 日本語の音源
- Podcastのように素人収録されたある程度ノイズが含まれた音源
- 1hくらいの長尺音源
- 複数人がクロストークしている音源
というような特徴を持った音声データに対してAPIだけでどこまで戦えるか（文字起こしできるか）だったので、いろいろ検証してきました。

1本目の記事ではGoogle Cloud Speech APIの使い方についてまとめ、文字起こし精度が低い仮説を立てました。
- PythonとGoogle Cloud Speech API を使った音声の文字起こし手順

2本目の記事ではGoogle Cloud Speech APIで文字起こし精度を高めるための前処理方法について実験をしました。
- Google Cloud Speech API における音声前処理と文字起こし精度の関係調査

〆となる今回は、前回得られたベスト精度のGoogle Speech API文字起こし結果 vs. 最近話題になったAmazon Transcribeでの文字起こしを行い、文字起こしAPIの限界点の一例をまとめたいと思います。

結果だけ知りたい方は最下段の「Google Cloud Speech API vs. Amazon Transcribeの結果まとめ」項目だけお読みください。

※注: 今回得られた結論は、今回使用した音声データ、実施した前処理においての結果となります。今回の結果がAPIの性能を結論づけるものではないことをご理解ください。

Amazon Transcribeでの文字起こし

Amazonの自動文字起こしAPIであるAmazon Transcribeは以前から存在したサービスですが、2019年11月末に日本語にも対応しました。

使い方はGoogle Speech APIと比較しても非常に簡単なためここでは省略します。公式のtutorialやClassmethodさんのブログなど参照してください。

文字起こしはもちろん、Japaneseを対象に行います。

Amazon Tanscribeが処理可能としているファイル形式は、mp3, mp4, wav, flac です。Google Speech APIはmp3やwavなど一般的なファイル形式が指定できなかったので嬉しいポイントです。
audio sampling rateも自動で認識されるためGoogleのように手動で指定する必要は無いようです。便利。

ちなみに、Amazon Transcribeでは必須パラメータとは別にoptionalに独自のパラメータを指定できます。

簡単にまとめると、

• Audio identification
  • Channel identification・・・もし音源が複数チャンネルに別れている場合これをTrueにする意味がある。チャンネルとは、例えば電話カスタマーサポートの音源において、回答者と質問者が別々の音源であったときはチャンネルは2となる。Amazon Transcribeでは、このパラメータをtrueにした場合はそれぞれのチャンネルを文字起こししたものとmergeされた音源を文字起こししたものの両方を出力してくれるらしい。
  • Speaker identification・・・音源内の話者数を任意に指定できる。最大は10人。デフォルトでは2人。（なので1人が喋ってるだけの音源ならここを1にした方が良いかも？）
• Alternative results・・・Classmethodさんのブログ参照
• Vocabualry filtering・・・不適切単語のように、指定した単語を自動的にマスキングして文字起こししてくれる機能。Classmethodさんのブログ参照
• Custom vocabulary・・・特定ドメインにおける専門用語やamazon transcribeが認識できない固有名詞などのヒントを与えることで認識精度を向上するためのもの

今回用いる音源では2人の話者がいるので"Speaker identification"は2となりますが、デフォルトで2となっているらしいので特に指定せず、すべてデフォルト（全て指定なし）で実行しました。

処理時間は1hの音源で約10分でした。Google Speech APIは15分強かかったので処理時間はAmazon transcribeの方が早いです。

検証データセットと評価方法

前回と同じ、前処理パラメータを色々組み合わせて作成したNo1からNo8の音源（flacファイル）を用います。音源データはこちらにおいてるので使いたい方がもしいたらどうぞ。

同じファイルを対象にする、かつAmazon Transcribe側でoptionalなパラメータも指定せずデフォルトで実行するので、Google speech APIの結果と同じ土俵上で比較してもおかしくないはずです。

Amazon Transcribeの文字起こし出力結果はjsonになります。文字数や単語数のカウントも前回と同じ方法で行いました。（実際の処理コードはこちら）

横串比較のため、評価方法も前回と同じようにしました。

結果

定量結果

図にしたものが以下です。

サンプル間でほとんど全て同じ結果となりました。結果全体から言えそうなことは、

• Amazon Transcribeでは、Google Speech APIの結果と異なり、音声の前処理に影響を受けない（※ここで行った前処理とは、Audacityによるノイズ低減処理とLevelatorによる音量調節処理のことです。これら以外の条件ではまた結果が異なるかもしれません）

ここでは、「重複なしの名詞単語数」が（ほぼ誤差レベルですが）一番高かったNo.2の結果をAmazon transcribeでのベスト結果として代表値とします。

前処理のありなしに影響されないかもしれないということで、試しに、収録撮って出しの生のwavファイル（No.0）でもAmazon transcribeにかけて結果を出しました。

なんの前処理も行ってないこのwavファイルとNo.2のファイルの違いは何かと言えば、ステレオかモノラルかということだけです。No.2では wavからflacファイルに変換するときに同時にステレオ→モノラル の変換を行っています。これはGoogle speech APIがモノラルファイルしか受け付けないため必要な処理でした。

「重複なしの全単語数」「重複なしの名詞単語数」は厳密には、No.2のほうが高いですが、これもそれほど差がないです。前処理なし＆ステレオ⇔モノラル変換なし でもほぼ同じ精度がでるのであれば前処理の手間が不要な「生のwavファイルを突っ込む」のが一番良いですね。

Amazon TranscribeではNo.1~No.8までほぼ同じ結果でしたので、No.1~No.8間の定性結果比較はせずに、「Google Cloud Speech APIのベスト結果」と「Amazon Transcribeのベスト結果」の比較をしたいと思います。

Google Cloud Speech API vs. Amazon Transcribe

前回確認したGoogle Cloud Speech API （ベスト結果 No.8）と、今回確認したAmazon Transcribe（ベスト結果 No.2）のそれぞれの値を比較します。Googleでの結果は前回の結果から数値をとってきています。

定量結果比較

文字起こし文字数比較

1hの音源に対して、単純な文字起こし数ではAmazon Transcribeが多かったようです。

単語数比較

文字起こし数が多かったためか、重複ありの全単語数や名詞数は同じくAmazon Transcribeが多い結果でした。

一方、重複を除いた全単語数や名詞数は両者ほぼ同じとなりました。図ったように同じくらい...

定性結果比較

テキストの内容自体はどんな感じだったのかというのを、ざっくりとですが前回と同じ要領で比較していきます。

文字起こし結果

文字起こし冒頭の範囲について、見比べやすいように画像を左右に並べました。左がGoogle、右がAmazonです。

判断難しいですが、びみょうーーーーーにGoogleの文字起こしの方がまだマシな気がします。どんぐりの背比べですが。
（※ここではGoogleの結果のみ改行が入っていますが、Google・Amazon共に本来は改行付きで文字起こしをしてくれます。精度は微妙です。なのでここでは筆者によって両者とも改行削除を後処理で行っています。）

頻出名詞

Google, Amazonそれぞれで、「重複なしの名詞単語」と「そのカウント数」を見比べてみます。出現数が11回以上あった単語を試しに表示してみます。

認識できた単語数はAmazonのほうが多いようです。しかしGoogle, Amazon間で殆どの単語が重複しているので両者の文字起こし性能は大きく違わないことも表しています。Amazonの結果では"ブレインパッド"という弊社社名も抜いてこれているので上出来です。

より多くの単語を認識したいのであれば（今回の音声データにおいては）Amazonのほうが優れているようです。（意味がある単語かどうかは要確認）

ワードクラウド

流れで名詞ワードクラウドも。上記の可視化です。左がGoogle、右がAmazonです。

Google Cloud Speech API vs. Amazon Transcribeの結果まとめ

Google Cloud Speech API vs. Amazon Transcribeの結果、

• Google, Amazonともに日本語の文字起こしは、（※今回の音声データにおいて簡単な前処理をした程度でAPIを利用しただけでは） 実用的な文字起こしは無理そう
• 文字起こしできた単語数で比較すると結果は概ね同じ
• Amazon Transcribeでは前処理なしでGoogleと同精度の結果を得たため、利便性としてはAmazon Transcribeの勝ち
• SDKをインストールしてCLIでAPIを叩く方法ではなく、ブラウザ上でコンソールを操作してGUIで文字起こしをする場合（非エンジニアの人はほぼ全員こちらの方法のはず）、利用難易度は比べるまでもなくAmazon Transcribeが勝ち。というよりGoogle APIの方は非エンジニアには難しすぎる。（※ところで非エンジニアの間では最近ではGoogle Docの音声入力による文字起こしが流行っているそうです）
• 処理時間はAmazon transcribeが少し早い。1hのファイルに対して、Googleが15min強ほどかかるのに対してAmazonでは10分ほどで完了する。

個人的には、

日本語文字起こしとしてはどちらも結局実用的なレベルとはほど遠い精度なので、文字起こしAPIは単語抽出程度にしか使えない印象です。（そして単語だけ抽出できてもほとんど使いみちがない...）

そして単語抽出用途だけに使うのであれば、前処理なしで利用できる・GUIで簡単に使える・処理時間が早い という点でAmazon Transcribeが良いというのが個人的結論です。

「もっとガチの収録機材を使ってクリアな音声を撮れれば文字起こしも精度が上がる可能性(=inputする音声クオリティーを上げる)」を捨ててはいませんが、自分の収録環境（16000円前後ほどの外付けマイク使用）以上を用意するのは一般ユーザーにはそもそも敷居が高いので「APIを利用して低価格でサクッと日本語の高精度な文字起こし」は現状技術ではどのみち不可能だと思っています。日本語文字起こしは一朝一夕ではいけないようです。

なんだか釈然としないので「こうやったら文字起こし認識上がるよ」というTipsをご存じの方がいればぜひコメント頂きたいです！