話者ラベルの例

話者ラベルがどのように機能するかを示す最良の方法は、例です。 以下の例では、音声認識要求で話者ラベルを要求します。

IBM Cloud

curl -X POST -u "apikey:{apikey}" \
--header "Content-Type: audio/flac" \
--data-binary @{path}audio-multi.flac \
"{url}/v1/recognize?model=en-US&speaker_labels=true"

IBM Cloud Pak for Data IBM Software Hub

curl -X POST \
--header "Authorization: Bearer {token}" \
--header "Content-Type: audio/flac" \
--data-binary @{path}audio-multi.flac \
"{url}/v1/recognize?model=en-US&speaker_labels=true"

応答には、タイム・スタンプと話者ラベルの配列が含まれます。 timestamps 配列の各エレメントに関連付けられている数値は、speaker_labels 配列内の各単語の開始時刻と終了時刻です。

{
  "result_index": 0,
  "results": [
    {
      "alternatives": [
        {
          "timestamps": [
            [
              "hello",
              0.28,
              0.79
            ],
            [
              "yeah",
              1.07,
              1.53
            ],
            [
              "yeah",
              1.66,
              2.02
            ],
            [
              "how's",
              2.15,
              2.44
            ],
            [
              "Billy",
              2.45,
              3.03
            ],
            [
              "good",
              3.57,
              3.95
            ]
          ]
          "confidence": 0.82,
          "transcript": "hello yeah yeah how's Billy good "
        }
      ],
      "final": true
    }
  ],
  "speaker_labels": [
    {
      "from": 0.28,
      "to": 0.79,
      "speaker": 2,
      "confidence": 0.52,
      "final": false
    },
    {
      "from": 1.07,
      "to": 1.53,
      "speaker": 1,
      "confidence": 0.63,
      "final": false
    },
    {
      "from": 1.66,
      "to": 2.02,
      "speaker": 2,
      "confidence": 0.54,
      "final": false
    },
    {
      "from": 2.15,
      "to": 2.44,
      "speaker": 2,
      "confidence": 0.51,
      "final": false
    },
    {
      "from": 2.45,
      "to": 3.03,
      "speaker": 2,
      "confidence": 0.55,
      "final": false
    },
    {
      "from": 3.57,
      "to": 3.95,
      "speaker": 1,
      "confidence": 0.63,
      "final": true
    }
  ]
}

transcript フィールドには、すべての参加者が発話したとおりの単語がリストされた音声の最終書き起こしが示されます。 話者ラベルをタイム・スタンプと比較および同期すると、会話を発生順に再構築できます。 各話者ラベルの confidence フィールドは、話者の識別におけるサービスの信頼性を示します。

結果は、簡潔な 2 人の会話を明確に示しています。

• 話者 2 - "Hello?"
• 話者 1 - "Yeah?"
• 話者 2 - "Yeah, how's Billy?"
• 話者 1 - "Good."

この例では、各話者ラベルの final フィールドですが、最後のフィールドは false です。 サービスは、返された最後の話者ラベルに対してのみ、final フィールドを true に設定します。 true の値は、サービスが話者ラベルの分析を完了したことを示します。

話者ラベルの話者 ID

この例では、話者 ID の興味深い側面も示しています。 speaker フィールドでは、最初の話者の ID は 2 で、2 番目の話者の ID は 1 です。 このサービスは、音声を処理するときに話者パターンについての理解が深まります。 したがって、最終結果を生成する前に、個別の単語の話者 ID を変更し、話者を追加および削除する場合があります。

その結果、話者 ID が順次、連続、または順序付けされた状態ではない場合があります。 例えば、ID は通常 0 から始まりますが、前の例では、最も古い ID は 1 です。 サービスは、音声の詳細な分析に基づいて、話者 0 の以前の単語割り当てが省略された可能性があります。 省略は、後の話者にも発生する可能性があります。 省略すると、番号付けにギャップが生じ、0 および 2 などのラベルが付けられた 2 人の話者に対して結果が生成される可能性があります。 もう 1 つの考慮事項は、話者が会話を離れることができることです。 このため、会話の早い段階にのみ参加した参加者はその後の結果に表示されない場合があります。

話者ラベルの中間結果の要求

中間結果で話者ラベルを使用すると、サービスは最終話者ラベル・オブジェクトを複製します。 詳しくは、既知の制限事項を参照してください。

WebSocket インターフェースでは、話者ラベルとともに中間結果を要求できます (詳しくは、中間結果を参照してください)。 最終結果は、通常、中間結果よりも改善されていますが、 中間結果は書き起こしの進行と話者ラベルの割り当ての識別に役立ちます。 中間結果は一時的な話者および ID が出現および消失した時期を示すことができます。 ただし、サービスは最初に識別し、その後再考して省略した話者の ID を再利用できます。 このため、中間結果および最終結果で 1 つの ID が 2 名の異なる話者に関連する場合があります。

中間結果と話者ラベルの両方を要求すると、長い音声ストリームの最終結果を、最初の中間結果が返されてしばらくたってから受け取る場合があります。 また、一部の中間結果に、全体として書き起こしの speaker_labels フィールドおよび results フィールドがなく、result_index フィールドのみが含まれる場合があります。 中間結果を要求しない場合、サービスは results フィールドと result_index フィールドおよび単一の speaker_labels フィールドを含む最終結果を返します。

中間結果で、final フィールド内の単語の false フィールドの値が speaker_labels であることは、サービスが音声を引き続き処理中であることを示します。 サービスが、終了する前に話者の識別や個別の単語の信頼度を変更する場合があります。 サービスは、音声ストリームの完了またはタイムアウトのいずれかが発生すると、最終結果を送信します。 サービスは、いずれの場合でも返す話者ラベルの最後の単語についてのみ、final フィールドを true に設定します。

話者ラベルのパフォーマンスに関する考慮事項

上記のとおり、話者ラベル機能は、コール・センターとのやり取りなど 2 名での会話向けに最適化されています。 このため、以下の可能性があるパフォーマンス上の問題を考慮する必要があります。

• 話者が 1 名の音声に関するパフォーマンスが貧弱である可能性があります。 音声の品質や話者の音声のバリエーションによって、サービスが存在しない追加の話者を識別する場合があります。 このような話者は、幻覚と呼ばれます。
• 同様に、ポッドキャストなど、独占的な話者による音声に関するパフォーマンスが貧弱である可能性があります。 サービスは、短時間話す話者を見逃す傾向があり、幻覚を作成する可能性もあります。
• 6 名を超える話者の音声に関するパフォーマンスは、明確ではありません。 この機能は、最大で 6 名の話者を処理できます。
• クロス・トーク (話者オーバーラップ) のパフォーマンスが低下します。 クロス・トークは、どの音声についても正確に書き起こすことが困難または不可能である可能性があります。
• 短い発話に関するパフォーマンスは、長い発話よりも正確度が低下します。 このサービスでは、参加者が長い時間 (話者ごとに 30 秒以上) 発話すると、より良い結果を得ることができます。 話者ごとに使用可能な音声の相対的な量もパフォーマンスに影響を与えます。
• 発話の最初の 30 秒間はパフォーマンスが低下する可能性があります。 音声が 1 分経過すると、サービスはより多くの処理対象のデータを受け取るので、通常はパフォーマンスが妥当なレベルに改善されます。

すべての書き起こしと同様に、音声品質の低下、背景ノイズ、人の発話方法、および音声のその他の側面によってもパフォーマンスが影響を受ける可能性があります。IBM は、話者ラベル機能のパフォーマンスを改善し続けています。 最新の改善点の詳細については、 IBM Research AI Advances Speaker Diarization in Real Use Cases」を参照してください。

マルチチャネル音声の話者ラベル

チャネルで説明されているように、Speech to Text サービスは、複数のチャネルを持つ音声を 1 つのチャネル・モノにダウンミックスし、その音声を音声認識に使用します。 サービスは、話者ラベルを生成するために渡される音声を含む、すべての音声に対してこの変換を実行します。

各話者のコントリビューションを別々のチャネルに記録するマルチチャネル音声がある場合は、以下の代替方法を使用して、話者ラベルと同等の機能を実現できます。

1. 音声から個々のチャネルを抽出します。
2. speaker_labels パラメーターを使用せずに、各チャネルからの音声を個別に書き起こします。 書き起こしの単語の正確なタイミング情報を確認するには、timestamps パラメーターを含めます。
3. 個々の要求の結果をマージして、完全な交換の単一のトランスクリプトを再作成します。 個々の要求のタイム・スタンプを使用して、会話を再構成できます。

マルチチャネル方法には、speaker_labels パラメーターの使用に比べていくつかの利点があります。

• このサービスは、基本的な音声認識に依存するため、サポートされている任意の言語の音声を書き起こすことができます。 話者ラベルは、使用可能な言語のサブセットに制限されます。
• 各話者には専用チャネルがあるため、サービスは話者ラベルの場合よりも正確な結果を提供できます。 サービスは、どの話者が話しているかを判別する必要はありません。
• 各話者には専用チャネルがあるため、サービスは、クロス・トーク (話者オーバーラップ) を正確に書き起こすことができます。 マージされたチャネルでは、クロス・トークを正確に認識することが困難または不可能である可能性があります。

しかし、この方法には、注意すべき欠点もいくつかあります。

• 音声を送信する前にチャネルを分離し、結果の書き起こしをマージして会話を再構成する必要があります。 タイム・スタンプを使用すると、再構成プロセスが大幅に簡素化されます。
• IBM Cloud サービスに送信した音声は、無音部分も含めてすべて課金対象となります。 すべてのチャネルから音声全体を送信すると、認識される音声の量にチャネルの数が効果的に掛けることができます。 例えば、5 分間続く 2 チャネル交換の両方のチャネルに対して個別の要求を送信する場合、要求には 10 分間の音声処理が必要になります。 料金プランで毎分の価格設定を使用すると、音声認識のコストが 2 倍になります。 無音を除去するために音声を前処理することを検討できますが、この方法を使用すると、個別の要求の結果をマージすることがより困難になります。