什么是说话人分离？工作原理及应用场景

说话人分离可处理说话人数未知的音频流，并生成带标签片段的时间轴：说话人 A 从 0:00 到 0:42，说话人 B 从 0:42 到 1:15，之后又是说话人 A。系统不知道说话人是谁，但知道他们是不同的人，并会在整段录音中保持标签一致。

这一过程让多说话人音频变得可用。会议纪要、呼叫中心分析、访谈转写、播客编辑和法律记录，不仅需要知道说了什么，还需要知道是谁说的。 

本指南将介绍说话人分离的工作原理、它与分段和识别等相关技术的区别、可用于此任务的开源工具，以及如何衡量说话人分离系统的表现。

摘要

• 说话人分离按说话者切分音频录音，生成带标签的说话轮次，但不会按姓名识别说话人。
• 说话人分离不同于说话人分段，后者用于找出说话人何时变化；也不同于说话人识别，后者将声音匹配到真实姓名。
• 说话人分离性能通过说话人分离错误率（DER）衡量整体准确性，并通过 Jaccard 错误率（JER）检查每位说话人的准确性是否一致。

什么是说话人分离？它如何工作？

说话人分离是按说话者将音频流划分为多个片段的过程。带有说话人分离的转写会为每段音频标注说话人身份。简单来说，它回答的是“谁在何时说话？” 

原始会议转写只提供文字，而经过说话人分离的转写会告诉你：说话人 1 提出了问题，说话人 2 作了回答，说话人 3 中途插话。

大多数说话人分离系统都遵循一个包含 4 个阶段的流程：

下面详细介绍这些阶段。

语音活动检测（VAD）

语音活动检测可将语音与其他声音分开：静音、背景噪声、音乐或键盘敲击声。只有包含实际语音的音频片段会进入下一阶段。

这一阶段出现的任何错误，都会传递到后续阶段。

分段

随后会在说话人可能变化的位置切分这些含语音片段，例如声调变化、说话轮次之间的停顿，或音高模式变化。大多数系统会直接比较候选边界两侧的声学特征，以检测这些变化点。 

有些分段工具会将音频切成统一的短窗口，例如每段 2 秒，然后依靠聚类阶段合并属于同一说话人的相邻窗口。

嵌入提取

每个语音片段都会转换为说话人嵌入，即一个捕捉该片段说话者声音特征的数值向量。同一说话人的嵌入在向量空间中彼此接近，不同说话人的嵌入则相距较远。

聚类

随后对嵌入进行分组，让来自同一说话人的片段共享标签。系统通常无法预先知道说话人数，因此聚类算法必须推断人数，判断声音略有不同的片段是新说话人，还是同一个人以不同语调说话。

输出是一组附有时间范围的说话人标签，通常会与转写文本配对。例如，双人通话的说话人分离转写如下：

• [speaker_0] 感谢来电。有什么可以帮你？
• [speaker_1] 你好，我想咨询上个月的账单。
• [speaker_0] 好的，我来查一下。

这些标签是匿名的，且内部一致。每次出现的 speaker_0 都是同一个声音，但系统不知道 speaker_0 名叫 Fergal。关联真实身份是另一项任务，下面会介绍。

说话人分段与说话人识别的主要区别

说话人分段和说话人识别都与说话人分离密切相关，因此这 3 个概念经常被混淆。

它们各自解决的问题略有不同，因此评估工具时理解其区别很重要。

如前所述，说话人分段是说话人分离流程早期的一个步骤。它会找出说话人从一个声音变为另一个声音的边界，但不分配标签。分段会告诉你在 0:42 发生了变化。说话人分离则进一步对所得片段进行分组，生成完整标注的输出，让你知道 1:15 的声音与录音开头说话的是同一人。

说话人识别是说话人分离之外的一项独立功能，但常与其结合使用。识别用于确定这些说话人实际是谁。识别系统会将声音与已注册的声纹进行比较，利用已知说话人参考信息返回身份。识别后，speaker_0 和 speaker_1 就会变成“Fergal”和“Eric”。

许多产品会组合这些工具，以生成更完整的最终转写。会议工具可能自动完成这一过程（甚至可能读取某人在 Teams 或 Meet 中设置的姓名等字符串），让每位参会者的发言都能按姓名归属，无需人工审核。 

热门开源说话人分离工具和库

需要控制力、灵活性或本地部署时，开源说话人分离工具值得考虑。最佳选择取决于处理的音频类型（电话、会议、播客、广播）、延迟要求，以及可投入的工程时间。 

以下是一些最热门的选择。

Pyannote.audio

Pyannote.audio 是一个基于 PyTorch、专为说话人分离构建的工具包，也是最常用的开源选项之一。它提供涵盖完整说话人分离技术栈的预训练流程，包括 VAD、分段、嵌入和聚类，以及可基于自有数据训练或微调模型的构建模块。 

其预训练模型通过 Hugging Face 分发，常被用作大型转写项目中的说话人分离层。

WhisperX

WhisperX 将 OpenAI 的 Whisper ASR与说话人分离和强制对齐相结合。Whisper 本身能生成高质量转写，但不会分配说话人标签，时间戳也只是近似值。WhisperX 增加词级时间戳对齐，并集成基于 pyannote 的说话人分离，生成的转写中每个词都带有准确时间戳和说话人标签。

NVIDIA NeMo

NVIDIA NeMo 将说话人分离纳入其更广泛的对话式 AI框架。它提供可训练的说话人分离模型，包括可处理重叠语音的端到端方法，面向在 GPU 基础设施上大规模构建定制语音系统的团队。

这些工具都要求你管理说话人分离基础设施，包括模型部署、扩缩容、监控和更新。不希望承担这类运维开销的团队，可以选择托管式说话人分离 API 这一更简单的方案。它们既可集成到现有 workflow，也可处理整个说话人分离流程，适合用于生产场景，例如客户支持分析、会议转写和播客处理。

实时说话人分离：挑战和应用场景

实时说话人分离远比处理已完成录音更困难，因为系统必须在上下文不完整的情况下作出决策。

离线系统在做出任何判断前能看到整段录音。它可以比较第 2 分钟和第 40 分钟的声音，并有把握地判定它们来自同一说话人，因为两个时刻的音频都可同时获取。实时系统没有这种条件：语音一到就必须标注，无法得知后续内容，且一旦作出决策，几乎没有机会修改。 

缺少未来上下文，使以下 3 个问题在实时场景中更难解决：

• 延迟与准确性：无法纵览整段对话时，满足更严格的响应时间预算会直接牺牲准确性。
• 重叠语音：当人们同时说话时，可重新处理音频的系统或许能将其拆分。实时系统则必须即时将其归为单一标签，或依赖专门的重叠感知模型。
• 短语句：简短的“是”或“请说”几乎无法为系统提供足够的声音信息；在没有周围上下文可参考的情况下，系统仍须立即确定标签。

尽管困难重重，有些应用无法等待录音结束。实时字幕用于会议和广播时，需要在人们说话的同时提供说话人标签。呼叫中心软件在通话中向智能体提供指导时，需要实时了解客户在说什么。语音智能体处理多方参与的通话时，需要毫不延迟地跟踪是谁在问什么。在每种情况下，准确性略低但即时的系统，都优于更准确却有延迟的系统。

对于不真正需要实时标签的工作负载，例如分析、合规审查和转写生成，批量说话人分离仍是更好的选择，因为其准确性高得多。

如何评估说话人分离性能

衡量说话人分离准确性时，最重要的两个指标是：反映整体准确性的说话人分离错误率（DER），以及检查每位说话人准确性是否可靠的 Jaccard 错误率（JER）。

DER 专门计算被错误归属的语音时间占总语音时间的比例。它结合了 3 类错误：

• 误报语音：无人说话时，系统将片段标为语音。
• 漏检语音：有人在说话，但系统将其标为静音。
• 说话人混淆：检测到了语音，但归属给错误的说话人。

DER =（误报 + 漏检语音 + 说话人混淆）/ 总语音时长

DER 为 10% 表示这 3 类错误合计占总语音时间的十分之一。数值越低越好，且只有在相同条件下对相同数据测得的分数才可比较。DER 会随音频质量、说话人数和录音中的重叠程度而大幅变化。

Jaccard 错误率（JER）会分别衡量每位说话人的说话人分离准确性，再对所有说话人的结果取平均值。对于每位参考说话人，评估器会匹配系统中最接近的说话人标签，并将正确重叠的时长与分配给任一说话人的总时长进行比较。

例如，假设一场 60 分钟会议中，说话人 A 说了 50 分钟，说话人 B 说了 10 分钟。说话人分离系统正确标注了说话人 A 的 50 分钟中的 48 分钟，但只正确标注了说话人 B 的 10 分钟中的 4 分钟。由于会议大部分时间属于说话人 A，整体 DER 看起来可能仍较好。JER 会让说话人 B 的较差结果同等计入，因为它先独立评估说话人 A 和说话人 B，再对分数取平均值。

JER_speaker = 1 -（correct_overlap /（ref_time + sys_time - correct_overlap））

最终 JER 是各说话人错误率的平均值：

JER = （1 / N）* Σ[JER_speaker_i]，其中 i = 1..N

同时跟踪 DER 和 JER，可更全面地了解说话人分离的准确性：DER 衡量整体准确性，JER 则衡量这种准确性是否覆盖每位参与者，包括发言较少的人。

使用代表生产环境的音频进行测试

评估说话人分离系统时，应在符合实际部署条件的音频上计算 DER 和 JER：典型说话人数、音频质量和串音程度。 

公开的基准分数可能在干净、受控的数据集上测得，例如录音室录音；这类数据很少与真实通话录音或实时会议的声音相符。基准测试表现良好的系统，在嘈杂、重叠的真实音频上仍可能明显表现不佳。在决定使用某款说话人分离产品前，请先使用自己的数据进行测试。

使用 ElevenAPI 开始说话人分离

如果已准备好构建支持多说话人的转写功能， Scribe v2 来自 ElevenLabs，可通过单个说话人分离功能使用文本转语音 API。将 diarize=true 与音频一同发送到端点，JSON 响应会为每个词标注说话人 ID，最多支持 32 位说话人、90 多种语言和最长 10 小时的文件。

两个选项可扩展标准的说话人分离输出。对于通话录音，detect_speaker_roles=true 会将说话人标为智能体和客户，而非匿名编号。如果工作区中已注册说话人资料，use_speaker_library=true 可将检测到的说话人与已注册音色匹配，在一次请求中结合说话人分离和识别。 

一个说话人分离阈值参数可让你调整过度切分与合并说话人之间的取舍。当说话人已隔离在不同音频通道中，例如立体声通话录音，多通道转写会按通道分配说话人，并完全跳过说话人分离。

文本转语音快速入门会逐步介绍首次集成。对于受监管的部署，平台符合 SOC 2、ISO 27001、PCI DSS L1 和 HIPAA 标准，并提供 EU 数据驻留和零保留模式。

准备好在系统中构建说话人分离功能了吗？先获取 API 密钥，或查看 ElevenLabs 文档了解更多。

常见问题