多人会议分轨：先分离说话人还是先识别

2026-08-24

**一份能用的会议纪要，需要的不只是一串文字，还得知道每句话是谁说的。**没有说话人标签的转写稿读起来像一段没有换行的独白，你分不清哪句是提问、哪句是拍板，也提取不出”谁答应了什么”。

要把标签补上，就绕不开一个工程选择：**说话人分离（diarization）和语音识别（ASR），谁先谁后。**这两条路线在实现复杂度、声学一致性和错误传导方式上完全不同。

先搞清楚 diarization 在做什么

说话人分离回答的是”谁在什么时候说话”。它输出的是匿名标签——说话人1、说话人2、说话人3——它并不知道谁是张三。要把匿名标签换成真名，还得再接一步声纹比对，那是另一件事，具体辨析见说话人分离和声纹识别的区别。

经典的 diarization 流程有五步：

分段：用 VAD 找出有人说话的片段，再用说话人变更检测把长片段在换人处切开。VAD 这一环的作用见VAD 是什么。
提取说话人嵌入：把每个片段转成一个定长向量，理想情况下同一个人的向量彼此靠近、不同人的相互远离。
聚类：把这些向量按距离分组，每一组对应一个人。
指派标签：给每一组编号，写回到对应的时间段上。
与 ASR 结果按时间对齐：让”某人在第 12.3 秒到 15.8 秒说话”这条信息，和转写文本上的时间戳对上。

注意最后一步：diarization 本身不产生文字，只产生”时间段 + 说话人编号”，文字要靠 ASR。两者怎么合流，就是顺序问题的由来。

两种顺序的取舍

维度	先分离再识别	先识别再对齐
做法	按 diarization 的时间段切音频，每个说话人的片段单独送 ASR	先整段跑 ASR 拿到带时间戳的转写，再按 diarization 的时间段贴标签
实现复杂度	高。要管切分、多路调度、结果拼回原时间轴	低。两条管道各跑各的，最后做一次时间轴匹配
声学一致性	好。同一个人的音量、音色、远近相对稳定，识别器面对的输入更同质	一般。整段音频里各人混在一起，识别器要不断适应变化
误差怎么传导	分离的边界误差直接进入识别输入——切早了吞字，切晚了带进别人的半个字	识别不受分离影响，但贴标签时会错——某句话被划给了隔壁的人
适合什么场景	单声道、说话人差异大、对每人转写质量要求高（如访谈逐字稿）	大多数通用会议转写，尤其是要快速上线的产品

先识别再对齐是工业上更常见的做法，原因很实际：它把两个复杂系统解耦了，两条管道各自独立升级，中间只靠时间戳这一个契约连接。而先分离再识别把两者串成强耦合链路，上游一动，下游全要重测。

真正的难点在边界，两种顺序都躲不掉

这是本篇最该讲透的一点：换顺序不能免除边界问题，只能改变错误出现的位置。

设想一个典型场景。A 说完”这个方案我觉得可以”，B 立刻接上”但是成本呢”，两人之间几乎没有停顿。分界点到底落在哪一毫秒？

走先分离这条路：分界点定早了，“可以”的尾音被切进 B 的片段，识别器可能把它和”但是”粘成一个奇怪的词；定晚了，A 的片段里带进了 B 的起音，同样干扰识别。错误进入了识别输入，会被放大。
走先识别这条路：识别器完整地转出了两句话，但时间戳落在”可以”和”但是”之间的那个瞬间，未必和 diarization 给出的分界点重合。结果就是”但是”这两个字被贴上了 A 的标签。识别是对的，归属是错的。

两条路的共同前提是：边界本身是个连续量，而标签是个离散量，把连续切成离散必然有误差。ASR 时间戳自身也不是绝对精确的，不同的时间戳生成方式各有偏差特性，这一点在时间戳是怎么算出来的里讲得更细。

工程上能做的不是消灭边界误差，而是让它落在代价小的地方：把标签指派的粒度从”字”放大到”句”或”发言轮次”，让个别字的归属误差被吸收掉。

至于两人真的同时开口的重叠段，那是一个被单独建模的子任务——pyannote.audio 就把重叠语音检测列为独立构件，和语音活动检测、说话人变更检测、说话人嵌入并列。展开见两个人同时说话怎么办。

说话人有几个，你事先并不知道

这是另一个被低估的现实问题。聚类算法通常需要你告诉它分成几类，可会议开始前没人知道今天来了几个人——有人中途加入，有人全程没发言，有人只说了一句”收到”。

于是只有两条路：预先指定人数，或者让算法自动判断。前者在会议场景基本不可行，后者则会以两种方式出错：

合并：两个音色相近、或者都通过同一个远场麦克风采集的人，嵌入向量挨得太近，被并成了一个说话人。纪要里表现为”这个人自己跟自己对话”。
拆分：同一个人前半程在会议室、后半程走近麦克风，或者情绪从平静转向激动，嵌入向量漂移到了另一簇，被拆成两个说话人。纪要里表现为凭空多出一位从未存在的与会者。

这两类错误的产品后果不对称。多拆一个人，用户看一眼就能合并；把两个人合成一个，用户往往察觉不到，直接把 B 说的话当成 A 说的记下来。所以在拿不准的时候，宁可倾向于拆细。

能上多路麦克风，就别跟算法较劲

有一个工程直觉值得单独说：如果每个人有独立的麦克风，整个问题基本消失了。

每人一路音轨，说话人归属就是一个物理事实，不需要嵌入、不需要聚类、不需要猜人数。剩下只有串音要处理——别人的声音也会漏进你的麦克风，按能量比较各路信号就能判断当前是谁在主讲，这比在混合音频里做声学聚类可靠得多。

视频会议软件天然就有分路音频，硬件会议系统的鹅颈麦阵列也是一路一人。真正被逼着做单声道 diarization 的，往往是”一台手机放在桌子中间录下整场会议”这类场景。

选型时值得先问一句：这个场景有没有可能拿到分路音频？如果有，把工程投入放在采集侧，比放在算法侧回报高得多。

工业管道倾向于打包成一条流水线

从落地形态看，说话人这件事很少被当作一个孤立模块。FunASR 的 AutoModel pipeline 输出的是带说话人 id、时间戳和标点的结构化文本——也就是说，VAD、识别、标点恢复、说话人标注被打包进了同一条 pipeline，一次调用直接吐出可以渲染成会议纪要的结构化结果。

这个设计取向和”先识别再对齐”是一致的：各子模块保持独立可替换，由 pipeline 负责在时间轴上把它们缝合起来。整条链路的分环节视角见语音识别的四个环节。

需要单独的说话人构件时，可选的开源项目有 pyannote.audio、WeSpeaker、3D-Speaker，它们分别提供说话人嵌入、验证、识别与分离方向的能力。具体怎么组合取决于部署形态和许可证要求，请以各仓库官方文档为准。

常见问题

问：分离出来的”说话人1""说话人2”能自动变成真名吗？

不能自动变。diarization 给的是匿名标签，变成真名需要额外一步声纹比对，而声纹比对要求事先注册——每人先留一段样本音频。会议场景更常见的做法是让用户手动把标签和参会名单对应一次，同一场会沿用。

问：先识别再对齐的时候，标签贴错了能事后修吗？

可以，这正是它的优势。转写文本和说话人标签是两份独立数据，改标签不影响文字。产品上通常提供”把这段改成某某说的”的编辑入口，用户改一处，同一簇的其余片段可批量跟着改。

问：两个人声音特别像，有什么办法吗？

单声道下没有可靠的通用办法——嵌入向量本就是按音色区分的，音色接近就是这套方法的固有边界。可行路径有两条：上分路麦克风，或在产品层面把不确定性暴露出来，让用户校正一次，而不是假装分对了。