機械学習を使用した音声コンテンツの分類

このドキュメントでは、機械学習を使用して音声ファイルの審査、音声文字変換、感情分析を行う音声分類パイプラインのアーキテクチャについて説明します。機械学習を使用すると、これらのタスクを手動で行う場合よりも高速かつ正確にこのプロセスを実行できます。このドキュメントは、Google Cloud プロダクトと Google Cloud Machine Learning API を使用して音声コンテンツを分類する方法を習得したいとお考えのアーキテクトの方を対象としています。付属のチュートリアルは、デベロッパーがこのパターンを示すサンプルをデプロイするプロセスについて理解するのに役立ちます。

はじめに

ビジネスの一環として音声ファイルを収集する際、音声から文字起こしを行うことが必要となる場合があります。また、コンテンツの分類や、検索インデックス用にタグを追加することが必要となる場合もあります。手動による文字起こしには時間がかかります。多くの場合、音声コンテンツの数が多すぎるため、すべての音声を手動で文字起こしして分類することは現実的ではありません。さらに、それぞれが独自のタグを手動でコンテンツに付けると、タグの有用性やコンテンツへのタグ付けの正確性が損なわれる場合もあります。

機械学習を使用することで、この代わりとなる自動分類パイプラインを構築できます。このドキュメントでは、Google Cloud Machine Learning API を使用して音声ファイルの審査プロセスを自動化する方法について説明します。この方法により、分類プロセスの効率が向上し、コンテンツへの自動タグ付けの幅を広げることができます。このソリューションは、すべての音声コンテンツの分類を拡張し、タグを自動生成することでこれを実現します。この方法を使用することで、すべてのコンテンツに事前に分類し、検索処理用の正確なタグを追加できます。

音声ファイルの分類プロセスの最初の手順は、音声ファイルのテキストへの変換です。音声ファイルをテキストに変換した後、機械学習を使用してコンテンツの概要を取得できます。この概要を使用して、テキスト内の一般的なエンティティ(固有名詞と普通名詞)を抽出し、コンテンツ全体を分析して分類およびタグ付けを行うことができます。

音声処理パイプラインの構築に関する課題

ユーザーにより生成された音声ファイルを処理するパイプラインの構築には、以下のような課題があります。

  • スケーラビリティ: 送信される音声ファイルの数が急増または急減し、長期的に大幅な増減を繰り返すこともあります。イベントやキャンペーンが行われると、コンテンツの送信回数が大幅に増加して処理負荷が増大し、アップロードのピークタイムが何度も発生する場合があります。
  • パフォーマンス: 各音声ファイルを処理するための効率的なパイプラインが必要です。音声ファイルはサイズが大きく、処理にかなりの時間を要することもあります。アプリを適切にスケールして、送信された音声ファイルを効率的に保存、処理し、文字起こし後のテキストを保存した上で、機械学習 API を呼び出して感情と観点を分析し、その結果を保存する必要があります。
  • インテリジェンス: 音声形式では従来の分析を行いにくいため、まずテキストに変換する必要があります。テキストへの変換は、人間により多くの処理を手動で行うか、機械学習ベースの方法で行う必要があります。音声をテキストに変換した後、分類およびタグ付けをするためにエンティティ、コンセプト、感情を審査する必要があります。

アーキテクチャ

次の図は、このドキュメントで説明する音声分類パイプラインのソリューションのアーキテクチャを示しています。パイプラインには、音声ファイルの処理を伴うあらゆるユースケースで使用できる、以下の基本的特徴があります。

  • 音声コンテンツが保存場所にアップロードされたときにコンテンツを処理するイベント ドリブン パイプライン(この処理は自動的に開始されます)。
  • パイプラインのイベントに応じて自動的に呼び出されるスケーラブルなサーバーレス処理。
  • 音声ファイルの文字変換タスクを実行し、感情とエンティティを分析する機械学習。既存の機械学習モデルを使用するため、カスタムモデルの作成や検索を行う必要はありません。

音声ファイルを処理するパイプラインのアーキテクチャ。

上の図に示すパイプラインは、次の処理手順で構成されています。

  1. 音声ファイルのアップロード。アプリやプロセスにより、音声ファイルが Cloud Storage にアップロードされます。Dataflow パイプラインまたはリアルタイム アップロード プロセスを使用できます。この手順はパイプラインそのものから独立しています。
  2. 音声ファイルの保存。音声ファイルは Cloud Storage バケットに保存されます。この Cloud Storage バケットは、パイプラインの残りの処理がすべて完了するまでファイルを保持するステージング バケットとして機能します。
  3. Cloud Functions の関数のトリガー。音声ファイルがステージング バケットにアップロードされるたびに、Cloud Storage がオブジェクトのファイナライズ通知を生成します。この通知によって Cloud Functions の関数がトリガーされます。
  4. Speech-to-Text API の呼び出し。トリガーされた Cloud Functions の関数が Speech-to-Text API を呼び出し、音声ファイルの音声文字変換を取得します。このプロセスは非同期であるため、Speech-to-Text API はジョブ ID を Cloud Functions の関数に返します。
  5. Speech-to-Text ジョブ ID のパブリッシュ。ジョブ ID と音声ファイルの名前が Pub/Sub トピックにパブリッシュされます。さまざまな音声ファイル送信からのジョブ ID を持つ、これらのパブリッシュされた Pub/Sub メッセージは、アップロードが行われるたびにトピックに蓄積されます。
  6. Speech-to-Text のポーリング。スケジュールされた頻度(たとえば、10 分ごと)で、Cloud Scheduler が Pub/Sub トピックにメッセージをパブリッシュすると、2 つ目の Cloud Functions の関数がトリガーされます。
  7. Speech-to-Text API の結果の取得。2 つ目の Cloud Functions の関数は最初の Pub/Sub トピックからすべてのメッセージを pull し、各メッセージのジョブ ID とファイル名を抽出します。その後、Speech-to-Text API を呼び出して各ジョブ ID のステータスを確認します。

    • ジョブが完了すると、そのジョブの音声文字変換結果が 2 つ目の Cloud Storage バケットに書き込まれます。音声ファイルは Cloud Functions の関数により、ステージングされた Cloud Storage バケットから処理済みファイルの Cloud Storage バケットに移動します。
    • ジョブが完了していない場合は、ジョブ ID を持つ Pub/Sub メッセージとファイル名が Pub/Sub トピックに再度追加されます。これにより、次回 Cloud Scheduler が Cloud Functions の関数を呼び出すときにジョブが再チェックされます。

    なんらかの理由で Speech-to-Text から音声文字変換が返されない場合、Cloud Functions の関数はステージング バケットから Cloud Storage エラーバケットに音声ファイルを移動します。

  8. Speech-to-Text API の結果の保存。音声ファイルの音声文字変換を含むテキスト ファイルが Cloud Storage バケットに書き込まれます。

  9. 複数の Cloud Functions の関数のトリガー。音声文字変換ファイルが Cloud Storage にアップロードされると、別のオブジェクト ファイナライズ通知が送信されます。この通知により、さらに Cloud Functions の 2 つの関数による処理がトリガーされます。

  10. Perspective API の呼び出し。3 つ目の Cloud Functions の関数は、Perspective API を呼び出します。これにより、音声文字変換の「有害性」の可能性に関するレスポンスが返されます。これは Perspectives API ウェブサイトで次のように説明されています。

    Perspective API モデルは、インターネット コメントを「非常に有害」から「非常に健全」までの範囲で人々に評価してもらうことでトレーニングされました。有害なコメントは、「人々がディスカッションから離れる可能性の高い、失礼、無礼、または合理性のないコメント」として定義されます。

    この分析が完了すると、Cloud Functions の関数が別の Cloud Storage バケットに結果を書き込みます。

  11. Cloud Natural Language API の呼び出し。4 つ目の Cloud Functions の関数は、Natural Language API を呼び出して、音声文字変換の全体的な態度や感情を分析し、説明されているエンティティを特定します。Cloud Functions の関数が Natural Language API から結果を受け取ると、その結果を別の Cloud Storage バケットに書き込みます。

  12. 結果の分析。Speech-to-Text、Natural Language API、Perspective API が分析結果をそれぞれ作成し、その情報はレビュー パイプラインまたはアプリに統合されます。上の図では、App Engine でホストされているウェブアプリが、結果を表示する簡単な UI を提供しています。ウェブアプリは、Cloud Storage バケットに保存されている出力からデータを pull します。

音声ファイルの処理

音声ファイルがアップロードされると、複数の API により処理されます。まず、Speech-to-Text で音声ファイルがテキストに変換されます。次に、このテキストが Natural Language APIPerspective API に送信され、感情とエンティティが抽出されます。音声ファイルをテキストに変換する際、かなりの時間がかかることがあります。そのため、このアーキテクチャでは Cloud FunctionsPub/SubCloud Storage の通知機能を使用して、スケーラブルで非同期のイベント処理パイプラインを実装します。

Cloud Functions

Cloud Functions には、インフラストラクチャを管理することなく、専用の非同期関数を構築する方法が用意されています。このドキュメントで説明するアーキテクチャで 3 つの API を呼び出すには、イベント ドリブンのオーケストレーターが必要です。Cloud Functions の関数は、Cloud Storage 通知または Pub/Sub メッセージによってトリガーできます。どちらの方法でトリガーしてもイベント ドリブンのアーキテクチャを構築できます。Cloud Functions は、新しいファイルの追加や処理量の変化に応じて動的にスケールアップ、スケールダウンできます。

Pub/Sub メッセージ

Pub/Sub は、データの送受信に使用できるスケーラブルなメッセージング サービスを提供し、Cloud Functions の関数のトリガーにも使用できます。Pub/Sub は次の 2 つの方法で、このアーキテクチャにおける非同期メッセージを提供します。

  1. Speech-to-Text API によって生成されたジョブ ID のメッセージ キューを提供します。後でこの ID を使用して、ジョブが完了したかどうかを判断できます。
  2. Cloud Scheduler ジョブは、まだ処理されていないメッセージの Speech-to-Text の結果をチェックする Cloud Functions の関数をトリガーする Pub/Sub メッセージを送信します。

Cloud Storage の通知

Cloud Storage の通知は、Cloud Storage で発生するイベントにフックを提供します。通知は、オブジェクトがアップロードまたは変更されるたびに生成されます。この通知を Cloud Functions の関数とともに使用して、イベントベースのシステムを構築できます。

Cloud Storage の通知は、このアーキテクチャでは以下の 2 か所で使用されます。

  • 新しい音声ファイルがアップロードされたことを Cloud Functions の関数に通知する。この通知によって処理フローが開始されます。
  • Speech-to-Text API のテキスト出力が保存されていることを 2 つの Cloud Functions の関数に通知し、そのテキスト出力を Natural Language API と Perspective API で実行する。

音声をテキストに変換する

音声録音をテキスト バージョンのコンテンツに変換する(音声録音を文字に変換する)ことが、このプロセスの重要な手順です。このタスクを実行する方法の 1 つは、TensorFlow などの一般的な機械学習フレームワークのいずれかでカスタムの音声文字変換アルゴリズムを実装することです。もう 1 つの方法は、Speech-to-Text API などの事前トレーニングされた機械学習 API を使用することです。それぞれにメリットとデメリットがあります。

オプション 1: TensorFlow で独自のモデルを構築する

メリット

  • 特定のフレーズや分野固有の用語に対してモデルをトレーニングできます。

デメリット

  • 通常音声文字変換を問題なく実装できるため、カスタム アルゴリズムを作成しても、分野固有の用語がない限り、特に優れた方法であるとはいえません。
  • モデルを実装するには機械学習の専門知識が必要です。
  • モデルの実装、選択、調整にかなりの労力が必要です。
  • 継続的にモデルを管理、調整する必要があります。

オプション 2: Speech-to-Text を使用する

メリット

  • モデルを開発してから独自の API を作成して使用するより、この API をそのまま使用する方が簡単であるため、デベロッパーにとっては使いやすくなります。
  • 機械学習の専門知識は必要ありません。
  • 120 以上の言語に対応しています。

デメリット

  • 特定のフレーズや分野固有の用語に対してモデルをトレーニングできません。

一般に、音声に特定の技術用語、特殊なフレーズ、単語として解読しにくいフレーズが含まれていない場合は、Speech-to-Text の使用が最適です。録音された音声に不適切なコンテンツが含まれている可能性を評価する前述のシナリオでは、Speech-to-Text で技術用語を認識できない場合でも音声を正確に分類しなければなりません。

対応する幅広い言語(120 以上)と Google Cloud ベースのソリューションへの統合のしやすさを考えると、このドキュメントで説明するシナリオには Speech-to-Text がおすすめです。

Speech-to-Text API の呼び出し

Speech-to-Text API は、同期と非同期の両方の音声文字変換サービスを提供しています。長い音声ファイルを処理する場合は、非同期の音声文字変換モードを使用することをおすすめします。非同期モードを使用する場合、音声ファイルは API に送信され、API からジョブ ID が返されます。このジョブ ID を使用してポーリングすると、ジョブのステータスを確認できます。

このドキュメントで説明するアーキテクチャでは、Cloud Scheduler を使用して、すべての未処理ジョブのステータスを定期的に確認します。Cloud Scheduler は、Pub/Sub トピックからすべてのジョブ ID を pull する Cloud Functions の関数をトリガーします。この Cloud Functions の関数は Speech-to-Text API を呼び出して各ジョブのステータスを確認します。この API はすべての完了済みジョブの結果を返し、結果はテキスト ファイルとして Cloud Storage に保存されます。未完了のジョブについては、次のイテレーションで処理するため、ジョブ ID が Pub/Sub トピックに返されます。

Speech-to-Text API は、特定の音声エンコードのリストを受け入れます。ロスレス エンコード(FLAC または LINEAR16)でキャプチャして送信した音声ソースを使用すると、最良の結果を得ることができます。特に録音にバックグラウンド ノイズが含まれている場合は、ロッシー コーデックを使用して音声をキャプチャまたは送信すると、音声認識の精度が低下することがあります。ロッシー コーデックには、MULAW、AMR、AMR_WB、OGG_OPUS、SPEEX_WITH_HEADER_BYTE、MP3 などがあります。

感情とエンティティの分析

音声コンテンツをテキストに変換した後、コンテンツをさらに分析して、音声内で説明されているエンティティと感情をそれぞれ特定できます。テキストからエンティティと感情を抽出する方法はいくつかあり、それぞれ複雑さが異なります。

1 つ目の方法では、TensorFlow などの機械学習フレームワークを使用して、独自のエンティティおよび感情のエクストラクタを構築します。もう 1 つの方法では、第三者により構築済みのフレームワークを活用し、転移学習で既存のモデルをカスタマイズします。Natural Language APIAutoML Natural Language などの事前トレーニングされた機械学習 API を使用することもできます。それぞれにメリットとデメリットがあります。

オプション 1: TensorFlow で独自のモデルを構築するか、転移学習を利用する。

メリット:

  • 特定のエンティティや分野固有の用語に対してモデルをトレーニングできます。

デメリット:

  • 通常エンティティの抽出を問題なく実装できるため、分野固有の用語がない限り、特に優れた方法であるとはいえません。
  • モデルを実装するには機械学習の専門知識が必要です。
  • モデルの実装、選択、調整にかなりの労力が必要です。
  • 継続的にモデルを管理、調整する必要があります。

オプション 2: Natural Language API を使用する

メリット:

  • モデルを開発してから API を作成して使用するより、この API をそのまま使用する方が簡単であるため、デベロッパーにとっては使いやすくなります。
  • モデルは事前に構築、トレーニング、ホストされているため、機械学習の専門知識は必要ありません。
  • 感情分析、エンティティ分析、エンティティ感情分析、コンテンツ分類、構文分析の機能を利用できます。

デメリット:

  • 特定のエンティティや分野固有の用語に対してトレーニングできません。

オプション 3: AutoML Natural Language を使用する

メリット:

  • モデルは事前に構築、トレーニング、ホストされているため、機械学習の専門知識は必要ありません。
  • 特定のエンティティや分野固有の用語に対してモデルをトレーニングできます。
  • 構築されたトレーニング済みモデルを API として表示します。

デメリット:

  • トレーニング データを指定する必要があります。
  • 継続的にモデルを管理、調整する必要があります。

一般に、テキストに技術用語、特殊なフレーズ、単語として解読しにくいフレーズが含まれていない場合は、Natural Language API の使用が最適です。このドキュメントで説明するユースケースでは、サンプルがテキストから感情とエンティティを抽出するため、Natural Language API で許容可能なレベルのパフォーマンスを実現できます。カスタム機械学習モデルの開発と比較して API の使いやすさを考えると、Natural Language API の使用が最適です。

Natural Language API を呼び出す

このドキュメントで説明するアーキテクチャでは、Natural Language API を使用してエンティティを抽出し、エンティティ感情分析を行います。この情報を使用することで、音声ファイルから抽出されたテキストにタグを付け、テキストの全体的なテーマを把握できるようになります。

テキストの観点を分析する

分析におけるもう 1 つのシグナルとして、特定のトピックに対する意見やコメントがもたらす悪影響があります。Perspective API は、Jigsaw と Google の不正行為対抗技術チームによって作成され、オープンソース プロジェクトとしてリリースされました。特定のコメントが「有害」と見なされる可能性を判断します。API は機械学習モデルを使用して、コメントが会話に与える影響を評価します。

Perspective API

Perspective API には、TOXICITYPROFANITYINSULT などの複数のモデルがあります。サンプル アーキテクチャでは、TOXICITY モデルを使用して、提供されたテキストが「人々がディスカッションから離れる可能性の高い、失礼、無礼、または合理性のないコメント」である可能性を報告します。テキスト コンテンツには、対応する音声ファイルの開始時刻と終了時刻が含まれているため、Perspective API からの結果はそれらの開始時刻と終了時刻とともに保存されます。これにより、元の音声ファイルの特定のセクションに、Perspective API の結果を関連付けることができます。

音声パイプラインの結果の表示

音声ファイルが Cloud Storage にアップロードされると、処理パイプラインが開始されます。実際には、これを任意のユーザー アップロード プロセスに統合できます。これは、ウェブアプリを使用してリアルタイムでアップロードすることも、データ パイプラインを介して多数の音声ファイルを一括でアップロードすることもできます。

処理が完了したら、アーキテクチャで使用される API によって作成された分析結果を読み取ることができます。アーキテクチャ図は、テキスト コンテンツ、テキストで識別されるエンティティと感情、関連するオーディオ クリップの開始時刻と終了時刻を表示するウェブ UI を示しています。図に示すように、ウェブアプリは App Engine と Cloud Storage を使用します。

App Engine

ウェブアプリは App Engine アプリとして実装されます。App Engine は、多くの一般的なウェブ プログラミング言語をサポートする Platform as a Service(PaaS)プロダクトであり、ユーザー トラフィックに基づいて自動的にスケールアップ、スケールダウンします。App Engine は Google Cloud と緊密に統合されているため、音声ファイルを Cloud Storage にアップロードするプロセスが簡素化されます。

次のステップ