实时转写只是第一步：一套会议AI系统背后还有哪些技术链路？

很多人第一次接触AI会议助手，最直观的判断标准往往是"能不能实时转文字"。

麦克风开始收音，屏幕上不断出现文字，延迟控制在几百毫秒到几秒之间，看起来一套会议系统最重要的工作似乎已经完成了。

但真正把语音识别模型接入会议场景之后，很快就会发现：ASR输出文字，只解决了"声音里说了什么"的问题，却没有解决"谁在什么时间说了什么、这句话属于哪个上下文、最终应该怎样进入会议记录"的问题。

从工程角度看，一套完整的会议AI系统通常不是一个ASR模型，而是一条持续运行的语音处理链路。

大致可以抽象成：

text 复制代码

音频采集
   ↓
音频预处理
   ↓
VAD / 语音分段
   ↓
ASR语音识别
   ↓
Speaker Diarization
   ↓
时间戳与文本对齐
   ↓
上下文整理
   ↓
结构化信息提取
   ↓
会议纪要生成
   ↓
存储、检索与权限管理

而真正影响使用体验的，恰恰经常是ASR之外的这些环节。

一、第一道问题其实发生在模型之前：音频输入

ASR模型看到的并不是"会议"，而是一串数字化后的音频采样。

因此，一套会议系统的效果首先取决于进入模型的音频质量。

在理想测试集中，音频往往来自近距离麦克风，说话人清晰、背景噪声较少，也很少存在明显的混响。但真实会议室完全不同。

空调持续低频噪声、键盘敲击、纸张翻动、投影设备风扇声都可能进入麦克风。远端参会人的声音还可能经过扬声器重新被本地麦克风拾取，形成回声；多人同时发言时，不同声音又会在同一时间段内重叠。

因此，会议系统通常首先需要处理降噪、自动增益、回声抑制以及音频通道管理等问题。

这一层如果处理不好，后面的ASR模型再强，也只能在一个质量已经下降的输入上工作。

这也是为什么同一个语音模型，在耳麦录音和大型会议室远场录音中的表现可能存在明显差异。问题不一定来自模型本身，也可能来自前端声学链路。

二、VAD决定的不是"有没有声音"，而是模型应该处理什么

连续两个小时的会议音频中，并不是每一毫秒都有人讲话。

其中存在大量静音、停顿、噪声和非语音事件。如果将完整音频不加处理地持续送入后端模型，会增加计算资源消耗，也容易影响识别边界。

因此，大多数语音系统都会使用VAD，也就是Voice Activity Detection，对连续音频进行语音活动检测。

它要解决的核心问题是：

text 复制代码

当前这一段音频是否包含有效人声？

看起来非常简单，但在会议环境中，VAD的阈值实际上会影响后面很多结果。

切得太激进，一句话可能被拆成：

text 复制代码

我们下周......
完成......
第一版测试......

切得太宽松，又可能把长时间静音和背景噪声一起送入ASR。

尤其是在实时系统中，还要在"等待更多上下文"和"尽快返回结果"之间寻找平衡。

等待时间越长，模型获得的上下文通常越完整；等待时间越短，实时字幕延迟越低。

因此，实时会议转写本身就是一个延迟与完整性之间的工程权衡。

三、ASR识别正确，并不意味着会议记录正确

经过前面的处理之后，才真正进入大家最熟悉的ASR阶段。

模型的任务可以简单理解为：

text 复制代码

Audio → Text

例如：

text 复制代码

输入音频：
/我们下周三之前完成第一版测试/

ASR：
我们下周三之前完成第一版测试。

如果只是制作字幕，到这里已经解决了核心问题。

但会议记录还有一个非常关键的信息没有出现：

这句话是谁说的？

假设实际会议里有三个人：

text 复制代码

张三：接口什么时候完成？
李四：我们下周三之前完成第一版测试。
王五：测试环境我来准备。

如果系统最后输出成：

text 复制代码

Speaker 1：接口什么时候完成？
Speaker 1：我们下周三之前完成第一版测试。
Speaker 2：测试环境我来准备。

即使所有文字一个字都没有识别错，这份会议记录依然存在明显问题。

所以，对于多人会议来说，ASR准确率并不是唯一决定最终质量的指标。

四、Speaker Diarization解决的是"谁在什么时候说话"

多人会议系统通常还需要Speaker Diarization，也就是所谓的说话人日志、说话人分离或发言人区分。

它需要回答两个问题：

text 复制代码

什么时候有人说话？
这一段是谁说的？

典型流程往往包括：

text 复制代码

音频
 ↓
语音分段
 ↓
Speaker Embedding
 ↓
相似度计算
 ↓
聚类
 ↓
Speaker 1 / Speaker 2 / Speaker 3

其中Speaker Embedding会把一段语音转换成一个能够表征说话人特征的向量，再比较不同语音片段之间的相似程度。

理论上，同一个人的Embedding应该更加接近。

但会议场景会让这个问题迅速复杂起来。

一个人可能离麦克风忽远忽近，也可能侧身讲话；长会议中声线会发生变化；两位发言人的音色可能非常接近；某些人一次只说"可以""好的""没问题"这种非常短的语句。

这些情况都会增加聚类难度。

更麻烦的是多人抢话。

如果某个时间段同时存在两个人的声音，问题已经不再是简单地把音频归入Speaker 1还是Speaker 2，而是需要判断重叠语音如何处理。

所以，从工程角度看，"支持多人识别"和"长时间稳定地区分多人"实际上是两件不同的事情。

五、真正容易被忽略的是：ASR和说话人结果还要重新对齐

ASR与Speaker Diarization通常不会天然得到完全一致的时间边界。

ASR可能输出：

text 复制代码

10.2s - 15.8s
我们下周三之前完成第一版测试

Speaker Diarization得到的却可能是：

text 复制代码

10.1s - 12.4s Speaker 2
12.7s - 16.0s Speaker 2

系统最终必须把两套结果重新映射。

更复杂的情况是，一段ASR文本内部发生了说话人切换：

text 复制代码

张三：什么时候上线？
李四：下周三。

如果ASR恰好把这两句话识别成了一个连续Segment，那么系统必须结合更细粒度时间戳，把文本重新拆开，再分配给不同Speaker。

因此，会议系统真正输出：

text 复制代码

李四：我们下周三之前完成第一版测试。

之前，实际上已经完成了多次时间轴操作。

这也是为什么"实时字幕效果不错"和"最终会议记录可用"之间仍然存在一段距离。

六、进入LLM之前，还需要先把语音结果变成可理解的会议上下文

现在很多会议系统会继续把转写结果交给大语言模型生成摘要。

表面上看，这一步似乎很简单：

text 复制代码

Transcript → LLM → Meeting Summary

但如果直接把大量原始ASR结果丢给模型，效果往往并不稳定。

一场两小时会议可能包含数万字文本，其中既有正式讨论，也有寒暄、重复表达、口头禅和被打断的句子。

因此在进入大模型之前，系统通常还需要完成一定程度的文本整理。

例如：

恢复标点与句子边界；
合并被VAD拆开的连续语句；
保留发言人关系；
处理重复识别；
建立时间顺序；
控制输入上下文长度。

只有在这些基础信息比较稳定之后，大模型才适合进一步抽取：

text 复制代码

会议主题
决策事项
待办任务
负责人
截止时间
争议点
后续行动

这也是为什么"接一个LLM生成摘要"和"真正生成可用会议纪要"之间依然存在工程差距。

七、实时转写和最终纪要，本质上其实是两个不同任务

很多会议产品界面会同时提供实时字幕和会后纪要，看起来只是同一份数据的两种展示方式。

但从系统设计来看，它们的目标并不完全相同。

实时字幕优先考虑的是：

低延迟。

用户说完一句话之后，希望尽快看到文本，因此系统不能等待过长时间。

而最终会议记录更看重：

完整性和一致性。

系统可以在会议结束后重新执行部分处理，对短句进行合并，对Speaker结果重新校正，对标点和上下文进行二次整理。

因此，一个比较合理的架构通常不是简单地把实时字幕直接保存下来作为最终纪要，而是允许实时链路与会后处理链路承担不同任务。

例如：

text 复制代码

                ┌→ 实时ASR → 实时字幕
音频处理 ──────┤
                └→ 完整音频 → 二次处理
                              ↓
                       Speaker校正
                              ↓
                       文本重新对齐
                              ↓
                        LLM纪要

这种设计会增加系统复杂度，却更符合会议场景本身的需求。

八、真正的会议AI，难点在于让这些链路一起稳定工作

如果把上述环节拆开来看，其中很多能力都已经存在成熟模型或者开源方案。

VAD有成熟模型，ASR有大量开源大模型，Speaker Diarization也有不同技术路线，大语言模型更不缺选择。

但真正把它们组成会议系统之后，困难会从"单模型能力"变成"系统协同"。

例如：

ASR改变分段方式，可能影响Speaker时间轴；

Speaker结果发生变化，又会影响文本归属；

文本归属发生变化，最终又会影响LLM对"谁负责什么"的判断。

换句话说，一个上游错误可能不断向后传播。

这也是完整会议AI产品与"调用几个模型API"的区别之一。

从熙瑾会悟目前呈现出的产品形态来看，也可以看到这种完整链路思路：它面向用户呈现的是一个完整会议助手，而不是单独暴露ASR、说话人识别或纪要生成模块。语音进入系统以后，需要在同一场会议上下文中连续完成转写、发言人区分以及内容整理。

如果反过来从这样的产品形态推导内部技术需求，就会发现真正需要解决的并不是某一个模型是否达到足够高的Benchmark，而是多个模块能否围绕同一条时间轴稳定协作。

九、评价会议AI，也应该从"模型指标"走向"系统指标"

因此，在测试会议AI时，只用几十秒标准录音观察识别结果，其实很难判断真实效果。

更接近实际使用场景的测试应该包括：

长时间连续会议、多人轮流发言、短句频繁切换、远近距离变化、背景噪声、专业术语，以及一定比例的重叠发言。

同时还应该观察几个不同层面的结果：

text 复制代码

音频层：
是否出现明显漏音、截断

ASR层：
文字识别是否准确

Speaker层：
发言人是否稳定

对齐层：
文字是否归属到正确人员

实时层：
字幕延迟是否可接受

纪要层：
决策、任务、责任人是否正确

这些指标组合在一起，才更接近一套会议AI系统真正的能力。

结语

过去评价语音产品时，人们很容易把注意力集中在ASR准确率上，因为它最直观，也最容易量化。

但会议是一个典型的长链路场景。

从麦克风收到声音开始，音频需要经过预处理、VAD、ASR、说话人区分、时间轴对齐、文本整理，再进入大模型完成结构化提取和纪要生成。

其中任何一个环节发生明显错误，都可能影响最后结果。

所以，"能实时转写"越来越像是一套会议AI系统的起点，而不是终点。

真正决定它能不能进入实际工作流的，是整条处理链在一场真实会议中，能否持续、稳定地把声音、文字、人物和上下文对应起来。