有了pyannote，为什么还要FunASR？
从工程分工、能力边界、性能和可替代性四个层面把逻辑彻底讲清楚。
一、先给结论
pyannote 和 FunASR解决的是两个完全不同的问题，彼此不可替代，只能配合使用。
- pyannote：回答“是谁在说话、什么时候在说话”
- FunASR：回答“他说了什么”
如果你只用其中一个，会议系统一定是残缺的。
二、职责边界
1. pyannote 做什么，不做什么
pyannote 的核心输出是：
[00:01.2 - 00:03.8] Speaker A
[00:03.8 - 00:06.1] Speaker B
它的本质是：
- 语音活动检测（VAD）
- 说话人 embedding 提取
- 聚类
- 时间段标注
它完全不关心语言内容：
- 不输出文字
- 不理解中文、英文
- 不知道你说的是“开会”还是“吃饭”
一句话：
pyannote 只切人，不识字。
2. FunASR 做什么，不做什么
FunASR 的核心输出是：
00:01.2 - 00:06.1: 我觉得这个方案不太行
它的本质是：
- 把音频 → 文本
- 尽量准确、低延迟
它不区分说话人：
- 不知道是谁说的
- 多人插话会混成一段话
一句话：
FunASR 只识字，不认人。
三、为什么“有了 pyannote 还必须要 ASR”
关键原因一：pyannote 不产生“文字”
没有 ASR，你最多只能得到：
Speaker A 说了 5 秒
Speaker B 说了 3 秒
但你不知道说了什么。
会议记录在工程上是没有意义的。
关键原因二：说话人分离 ≠ 语音识别
很多人会误以为：
“既然知道是谁说的，是不是就顺便知道说了什么？”
不是。
这两个模型训练目标完全不同：
- pyannote 优化的是 说话人区分度
- FunASR 优化的是 文字准确率
四、正确的组合方式
标准流水线
音频流
├─ pyannote：切出 [时间段 + 说话人ID]
├─ FunASR：对每个时间段转文字
└─ 合并结果
最终输出才会是：
张三：我觉得这个方案不太行
李四：不对，我认为可以试一下
五、为什么不用“pyannote + Whisper”，而推荐 FunASR
这是工程选型问题，不是学术问题。
| 维度 | Whisper | FunASR |
|---|---|---|
| 实时性 | 差 | 好 |
| 流式 | 勉强 | 原生 |
| 中文会议 | 好 | 很好 |
| 延迟 | 高 | 低 |
| 可控性 | 一般 | 高 |
结论：
Whisper 更像“离线转写神器”，FunASR 更像“会议系统发动机”。
六、一个你一定会踩的坑（提前告诉你）
很多人一开始会尝试：
音频 → ASR → 再想办法区分说话人
这是走不通的，因为：
- ASR 输出已经丢失了说话人声学信息
- 后处理无法还原“是谁说的”
正确顺序一定是：
先分人，再识字。
七、再压缩成一句话（给你做决策用）
pyannote 决定“标签”，FunASR 决定“内容”，
两者结合，才是完整的会议记录系统。
如果你愿意，下一步我可以直接给你：
- 一份 pyannote + FunASR 的实时/准实时架构图
- 一段 最小可运行代码（单机）
- 或者直接帮你判断：你现在的硬件，能不能跑得动
你只需要说一句：
单麦克风还是多麦克风？GPU 有几张？
