说话者标签示例

示例是显示说话者标签工作方式的最佳方法。 以下示例使用语音识别请求来请求演讲者标签:

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 - "Hello?"
• 说话者 1 - "Yeah?"
• 说话者 2 - "Yeah, how's Billy?"
• 说话者 1-“很好”。

在该示例中，每个演讲者标签的 final 字段，但最后一个是 false。 该服务将 final 字段设置为 true，仅用于返回最后一个发言者的标签。 true 的值表明服务已完成对扬声器标签的分析。

说话者标签的说话者标识

此示例还说明了说话者标识的一个十分有意思的方面。 在 speaker 字段中，第一个演讲者的标识为 2，第二个演讲者的标识为 1。 服务会在处理音频时更好地了解扬声器模式。 因此，服务在生成最终结果之前，可能会更改单个词的说话者标识，还可能会添加和除去说话者。

因此，说话者标识可能不是顺序、连续或有序的。 例如，标识通常从 0 开始，但在先前的示例中，最早的标识是 1。 根据对音频的进一步分析，该服务可能省略了针对说话者 0 的较早的词赋值。 这样的省略操作可能还会对后面的说话者执行。 遗漏可能导致编号中出现间隔，并为标记为 0 和 2 的两个演讲者生成结果。 另一个考虑是，演讲者可以留下对话。 因此，仅参与会话早期阶段的参与者可能不会在后续结果中出现。

请求说话者标签的中间结果

将演讲者标签与中间结果配合使用时，服务会复制最终演讲者标签对象。 有关更多信息，请参阅已知限制。

通过 WebSocket 接口，可以请求中间结果以及说话者标签（有关更多信息，请参阅中间结果）。 最终结果通常会优于中间结果。 但是，中间结果可帮助识别文字记录以及说话者标签分配的变化过程。 中间结果可以指示瞬态说话者和标识在何处出现或消失。 但是，服务可以复用初始识别到，但在后续重新考虑并省略的说话者标识。 因此，一个标识在中间结果和最终结果中可能指的是两个不同的说话者。

请求中间结果和说话者标签时，长音频流的最终结果可能会在初始中间结果返回之后很久才到达。 此外，某些中间结果还可能针对文字记录整体仅包含 speaker_labels 字段，而不包含 results 和 result_index 字段。 如果不请求中间结果，那么服务返回的最终结果中包含 results 和 result_index 字段以及单个 speaker_labels 字段。

对于中间结果，针对 final 字段中的词其值为 false 的 speaker_labels 字段可能指示服务仍在处理音频。 服务在完成处理之前，可能会更改其对说话者的标识或对单个词的置信度。 音频流完成时或对超时做出响应时（以先发生者为准），服务会发送最终结果。 无论是哪种情况，服务都只会针对所返回的说话者标签的最后一个词将 final 字段设置为 true。

说话者标签的性能注意事项

如上所述，说话者标签功能已针对双人会话（例如，与呼叫中心的通信）进行了优化。 因此，您需要考虑以下潜在的性能问题：

• 单个说话者的音频性能可能不佳。 音频质量或说话者声音的变化可能会导致服务识别到不存在的额外说话者。 这类说话者称为幻影。
• 与此类似，有主说话者的音频（如播客）的性能也可能不佳。 服务往往会错过讲话时间较短的说话者，并且还可能会生成幻影。
• 超过 6 个说话者的音频性能不确定。 此功能最多可处理 6 个说话者。
• 交叉交谈或说话者重叠的性能很差。 对于任何音频，交叉交谈都可能很难或无法准确转录。
• 短时间话语的性能在准确性方面可能低于长时间话语。 参与者讲话时间越长（每个说话者至少讲 30 秒），服务生成的结果越好。 可用于每个说话者的相对音频量也会影响性能。
• 对于前 30 秒语音，性能可能会下降。 对于 1 分钟后的音频，性能通常会提高到合理水平，因为服务会收到更多数据进行处理。

与所有转录一样，性能也会受到音频质量差，背景噪声，一个人的语音方式以及音频的其他方面的影响。IBM 继续优化和提高演讲者标签功能的性能。 如需了解最新改进的更多信息，请发送电子邮件 至 IBM，查看《人工智能研究进展：实际案例中的语音识别 》。

多声道音频的扬声器标签

如 通道 中所述，Speech to Text 服务将音频与多个通道混合到单通道单通道，并将该音频用于语音识别。 服务会对所有音频 (包括传递以生成扬声器标签的音频) 执行此转换。

如果您有多声道音频将每个演讲者的贡献记录在单独的频道上，那么可以使用以下替代方法来实现等效于演讲者标签:

1. 从音频中抽取每个单独的通道。
2. 分别转录来自每个通道的音频，而不使用 speaker_labels 参数。 包含 timestamps 参数以了解文字记录的精确计时信息。
3. 合并各个请求的结果，以重新创建完整交换的单个抄本。 您可以使用各个请求的时间戳记来重构对话。

与使用 speaker_labels 参数相比，多通道方法具有一些优势:

• 由于它依赖于基本语音识别，因此服务可以转录任何受支持语言的音频。 发言人标签仅限于可用语言的子集。
• 由于每个演讲者都有专用通道，因此服务可以提供比演讲者标签更准确的结果。 该服务不需要确定哪个发言人在说话。
• 因为每个演讲者都有专门的通道，所以服务可以准确转录交叉演讲，或者演讲者重叠。 在合并的通道上，交叉对话可能难以或无法准确识别。

但这种方法也有一些你需要注意的缺点:

• 您必须在发送音频之前分隔这些通道，然后合并生成的文字记录以重构对话。 时间戳记的使用大大简化了重建过程。
• IBM Cloud 将针对发送到服务的所有音频 (包括静默) 向您收费。 如果从所有通道全部发送音频，那么有效将可识别的音频量乘以通道数。 例如，如果针对持续 5 分钟的双通道交换的两个通道提交单独的请求，那么您的请求需要 10 分钟的音频处理。 如果定价计划使用每分钟定价，那么这将使语音识别成本增加一倍。 您可以考虑预处理音频以消除静默，但这种方法会使合并单独请求的结果变得更加困难。