在单人录音里，语音识别系统的目标通常比较明确：把声音尽可能准确地转换成文字。

但会议场景会多出一个非常现实的问题：

如果一场会议只有ASR结果，最终得到的可能是：

这个版本什么时候可以提测？
周三之前可以完成。
测试环境今天准备好。


从文字本身看并没有明显问题。

但真正用于会议记录时，更希望得到：

Speaker A：这个版本什么时候可以提测？
Speaker B：周三之前可以完成。
Speaker C：测试环境今天准备好。


进一步还可能需要映射成真实参会人：

张经理：这个版本什么时候可以提测？
李工：周三之前可以完成。
王工：测试环境今天准备好。


所以，多人会议转写实际上不是一个单纯的ASR问题，而是至少需要同时解决两件事：

ASR：
Audio → Text

Speaker Diarization：
Audio → Who spoke when


最终系统需要把这两条结果重新合并，得到真正有用的：

这也是会议语音系统中最容易被低估的一条工程链路。

一、ASR和Speaker Diarization解决的是两个不同问题

00:12.4 - 00:16.8
“我们周三之前完成第一版。”


至于这句话是谁说的，ASR本身通常并不关心。

它更关注音频时间轴上的说话人变化，例如：

00:12.1 - 00:14.5   Speaker 1
00:14.6 - 00:18.2   Speaker 2


它甚至不需要知道两个人具体说了什么。

因此两套模型可能同时处理同一段音频，但输出的数据结构完全不同。

                     ┌── ASR ─────────→ Transcript
音频 → VAD / 分段 ───┤
                     └── Diarization ─→ Speaker Timeline
                                         │
                                         ↓
                                  时间戳匹配 / 对齐
                                         ↓
                                Speaker + Transcript


看起来只是把两份结果按时间戳合起来，但真正实现以后，事情远没有这么简单。

二、第一个难点：两套模型的分段边界通常不会一致

10.20s - 15.80s

这个问题我来处理，测试环境你负责。


10.10s - 12.90s   Speaker A
12.95s - 15.90s   Speaker B


这意味着ASR认为这是一整句话，但说话人模型认为中途已经换人。

A：这个问题我来处理。

B：测试环境你负责。


如果系统简单按照“最大时间重叠”给整个ASR片段分配Speaker，那么最终很可能变成：

Speaker A：
这个问题我来处理，测试环境你负责。


文字没错，Speaker聚类也可能没错，但最终结果还是错了。

因此ASR和Diarization之间往往还需要一层更细粒度的时间对齐。

如果ASR能够输出词级或字级时间戳，就可以进一步判断：

这个问题我来处理
10.20 - 12.82

测试环境你负责
13.01 - 15.80


然后分别和Speaker时间段进行匹配。

这类问题本质上不是模型准确率，而是

三、VAD不能只是ASR前面的一个简单开关

会议系统中通常还会使用VAD，也就是Voice Activity Detection。

但VAD的切分方式会同时影响ASR和Speaker Diarization。

我们……
周三之前……
完成……
第一版……


ASR获得的上下文变少，Speaker模型能够提取的说话人特征也会减少。

又可能把多个说话人塞进同一个Segment。

因此真实系统通常不会简单采用：

VAD Segment
↓
同时送ASR和Speaker模型
↓
结束


而可能需要维护不同粒度的时间结构。

原始音频流
↓
粗粒度语音区间
├─→ ASR Segment
└─→ Speaker Segment
        ↓
   后续重新对齐


也就是说，ASR和Speaker Diarization虽然处理同一场会议，却未必应该完全共享同一种分段策略。

四、短句为什么特别容易出现Speaker错误

对。

可以。

没问题。

继续。

我同意。


这类片段对ASR来说并不一定困难。

但对Speaker识别来说，问题要明显得多。

Speaker Embedding需要从语音中提取能够区分说话人的声学特征。如果只有几百毫秒音频，可以利用的信息非常有限。

Speaker 1：这个方案先这样定。

Speaker 3：对。

Speaker 1：后续我再补详细方案。


实际上中间的“对”仍然可能来自Speaker 1。

如果系统对每一个短Segment都进行完全独立的Speaker分类，就容易发生这种跳变。

也就是说，Diarization输出并不一定应该被直接当作最终人物标签。

它更像是一层需要继续维护和修正的中间状态。

五、多人抢话会直接破坏“一段音频对应一个人”的假设

会议里另一个难点是Overlapped Speech，也就是重叠语音。

A：这个接口我觉得需要重新——

B：对，这里确实有问题。


B在A说完之前就已经开始讲话。

于是某一个时间区间里同时存在两个Speaker。

那么这一段必然会丢失一部分信息。

这个接口我觉得需要重新这里确实有问题


也可能漏掉其中一个人的部分内容。

此时整个链路的问题开始相互影响：

Overlap
↓
VAD边界异常
↓
ASR文本异常
↓
Speaker边界异常
↓
文本与Speaker重新对齐失败


所以多人会议中的错误经常不是“某个模型单独错了一次”，而是上游偏差逐层传递到了最终输出。

六、长会议真正考验的是Speaker状态能不能保持稳定

短音频测试中，Speaker聚类通常相对容易。

但会议持续一两个小时之后，同一个人的声学特征并不会完全保持不变。

会议场景中的ASR + Speaker Diarization链路设计

本文揭示了会议场景中的ASR + Speaker Diarization链路设计

人工智能

音视频

算法

会议转写需同时处理ASR识别文本与说话人分离，关键难点包括时间戳对齐、短句误判、重叠语音及长会说话人漂移。系统需统一时间轴，维护分段、映射与修订机制，确保“谁在何时说了什么”的完整记录。

语音产品特惠新用户14.9元起


2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

会议场景中的ASR + Speaker Diarization链路设计

会议场景中的ASR + Speaker Diarization链路设计

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐