为什么AI会议纪要总是遗漏重点？从ASR、Speaker Diarization到LLM的误差传播

随着大语言模型进入办公场景，AI会议纪要已经成为不少企业的常用工具。如今，将一段会议录音转换成文字，再利用LLM提取讨论重点、生成会议摘要，整个过程已经不需要复杂的人工操作。

但实际使用中，一个问题始终没有得到彻底解决：为什么有些AI会议纪要看起来条理清晰，却会遗漏关键决策，甚至把会议中没有确定的事情写成最终结论？

例如，一场项目会议讨论了是否推迟系统上线，最终结论是等待测试结果后再确定日期。但AI生成的纪要却写成了“会议决定下周一正式上线”。

这种问题不一定是大模型本身造成的。

在完整的会议处理链路中，ASR语音识别、VAD语音活动检测、Speaker Diarization说话人区分、长文本切分以及LLM语义理解都可能引入误差。当多个环节的错误相互叠加时，即使使用能力很强的大语言模型，也无法保证最终会议纪要准确。

一、AI会议纪要的质量问题，可能从语音识别阶段就已经开始

一套典型的AI会议纪要系统，通常包含以下处理流程：

会议音频 → 音频预处理 → ASR语音转写与发言人区分 → 文本结构化 → LLM总结 → 会议纪要生成

其中，语音识别提供原始文字，发言人区分负责建立语音与说话人的对应关系，LLM则基于这些信息理解会议内容。

这种架构存在一个容易被忽略的问题：下游模型接收到的往往已经不是原始会议音频，而是经过识别和加工的文本。

假设会议中有人说：

“这个版本暂时不能上线，接口兼容性问题还没有解决。”

ASR却识别成：

“这个版本暂时能够上线，接口兼容性问题已经解决。”

仅仅几个字的识别错误，就可能完全改变语句含义。

如果LLM没有访问原始音频的能力，也缺少额外的事实校验信息，那么它只能根据错误的转写文本进行总结，最终可能输出：

“会议确认接口兼容性问题已经解决，当前版本具备上线条件。”

从语音识别角度来看，这段话可能只包含少量字符错误，但从会议纪要角度来看，核心决策已经发生了根本性偏差。

这就是典型的误差传播（Error Propagation）。

2025年ACL发表的研究《Measuring the Effect of Transcription Noise on Downstream Language Understanding Tasks》专门分析了语音转写噪声对下游语言理解任务的影响。研究指出，不同类型和严重程度的转写错误，会对对话摘要等任务产生不同程度的影响。

这也意味着，单纯提高LLM的参数规模，并不能从根本上消除上游语音识别错误。

二、ASR准确率很高，为什么会议纪要仍然可能出错？

评价语音识别系统时，经常会使用WER（词错误率）或CER（字符错误率）。

对于中文语音识别，CER是一项常见指标：

CER = (S + D + I) / N

其中：

• S：替换错误数量
• D：删除错误数量
• I：插入错误数量
• N：参考文本的字符总数

CER越低，通常意味着语音转写的整体字符错误越少。

但是，较低的字符错误率，并不意味着较低的会议纪要事实错误率。

原因在于，不同字符对会议语义的影响程度存在明显差异。

1. 否定词错误可能直接改变决议

原始发言：

“这个方案不通过，下周继续讨论。”

识别结果：

“这个方案通过，下周继续讨论。”

仅仅遗漏一个“不”字，就可能让后续总结模型得出完全相反的结论。

2. 时间与数字错误会影响行动安排

原始发言：

“项目预算暂定十五万元，十一月六日前完成评审。”

识别结果：

“项目预算暂定五十万元，十一月十六日前完成评审。”

即使整段文字的识别准确率很高，预算金额和时间节点的错误仍然可能造成实际业务影响。

3. 专业词汇错误会影响技术结论

技术评审会议中，经常出现产品名称、接口名称、系统版本、数据库名称等专业术语。

例如，将“Redis主从切换”识别成“Redis主机切换”，虽然看起来差别不大，但对熟悉技术架构的人员来说，两者含义并不相同。

如果LLM继续根据错误内容推导技术方案，就可能产生与实际讨论不符的总结。

因此，对于AI会议纪要系统，除了通用CER，还应该关注以下信息的识别质量：

信息类型	典型内容	错误后果
否定与肯定	不通过、暂缓、确认	会议决议反转
时间日期	11月6日、下周三	任务截止时间错误
数字金额	15万元、30%	预算或指标失真
专业术语	API、数据库名称、项目代号	技术方案理解偏差
人员姓名	项目负责人、部门成员	责任归属错误

实际评估时，可以在CER之外增加关键实体准确率、决策相关语句识别率等指标。

例如，将会议中的人名、日期、金额、产品名称单独标注，并统计这些信息是否被正确识别。这样得到的结果，通常比单一的字符准确率更接近会议纪要的实际需求。

三、Speaker Diarization：为什么“谁说的”可能比“说了什么”更重要？

多人会议与普通语音转写最大的区别之一，就是存在复杂的发言关系。

一场涉及十几个人的会议中，同一个议题可能经过多轮讨论，甚至出现多位参会人员相互反驳、补充和修改方案的情况。

如果系统只能把语音转换成文字，却无法准确区分发言人，就很容易在生成纪要时发生责任归属错误。

例如：

张经理：这次上线计划谁来负责？

李工：我可以负责技术实施。

王工：测试部分由我来跟进。

张经理：好，那就按这个分工执行。

如果系统错误地将李工和王工识别为同一位发言人，生成的纪要可能变成：

“李工负责技术实施与测试工作。”

这种错误不会直接表现为文字识别不准确，却会影响最终任务分工。

1. 说话人分离标注与声纹识别的区别

多人语音处理主要涉及两种不同的技术能力。

Speaker Diarization（说话人分离标注） 负责判断不同音频片段属于哪个发言人，通常输出Speaker 1、Speaker 2等匿名标签。

典型流程包括语音活动检测、语音分段、说话人特征提取、聚类以及说话人标签分配。

Speaker Recognition（说话人识别） 则可以通过声纹特征匹配，将音频中的发言人与已建立声纹档案的人员进行关联。

前者解决的是不同语音片段是否来自同一位发言人，后者进一步解决发言人的具体身份问题。

在需要明确责任分工的企业会议中，两者结合能够为后续纪要生成提供更完整的人员信息，但声纹匹配结果仍然需要考虑误识别风险。

2. DER指标为什么值得关注？

Speaker Diarization通常使用DER（Diarization Error Rate，说话人分离标注错误率）评价效果。

DER主要由三类错误组成：

DER = Missed Speech + False Alarm + Speaker Confusion

分别对应：

• 漏检语音：实际存在发言，但系统未能识别。
• 虚警语音：将非语音片段错误判断为语音。
• 发言人混淆：将某位发言人的语音分配给另一位发言人。

这些错误在会议纪要中会表现出不同影响。

漏检语音可能导致关键观点缺失；发言人混淆可能导致责任人错误；多人同时讲话时的识别失败，则可能使反对意见、补充条件等内容无法被完整保留。

值得注意的是，DER衡量的是语音片段的说话人归属质量，并不直接等同于真实姓名识别准确率，也不能单独反映会议纪要的最终质量。

对于企业会议系统，更合理的做法是同时评估发言人区分效果、人员身份关联效果以及下游任务分工提取的准确性。

3. 为什么声纹识别对AI会议纪要有实际意义？

传统会议记录经常需要人工添加发言人姓名。

而结合声纹识别技术，系统可以在已建立人员声纹档案的情况下，将相应发言片段与具体参会人员关联，从而减少人工标注工作。

熙瑾会悟在AI会议纪要处理流程中整合了语音转写、AI声纹识别与智能纪要生成功能，能够利用语音内容和发言人信息组织会议记录。

对于多人项目评审、部门例会等场景，这种设计的意义不只是提高录音整理效率，更在于为后续提取会议决议、人员分工和待办事项提供结构化信息基础。

不过，即使具备声纹识别能力，也不能直接把所有发言人标签视为绝对准确。对于存在多人重叠发言、远距离拾音或声纹匹配置信度不足的片段，仍然有必要保留待确认机制。

四、LLM为什么会遗漏会议重点？长文本处理与语义压缩同样存在问题

即使ASR转写准确、发言人区分正确，AI会议纪要也可能出现遗漏。

一个重要原因是，会议并不是结构清晰的书面材料，而是包含大量重复、插话、话题切换和隐含上下文的连续对话。

1. 长会议中的上下文依赖

假设一场两小时的会议中，某个项目问题先后被讨论了三次：

上午10:00，有人提出将上线时间调整到周三。

上午10:40，测试团队认为周三可能无法完成验收。

上午11:20，项目负责人最终决定将上线时间调整到周五。

如果LLM只关注最初的讨论，可能会错误地把周三作为最终上线时间。

因此，生成会议纪要不能简单地提取每个时间段最重要的句子，而需要识别同一议题在整个会议过程中的演变。

2. 分段摘要可能丢失跨段信息

为了处理较长的会议记录，常见方案是将转写文本拆分成若干片段，分别生成摘要，再合并为完整纪要。

这种方法能够降低单次模型输入长度和推理成本，但也存在信息丢失风险。

例如：

第一段摘要：

“研发部门提出下周三上线。”

第二段摘要：

“测试部门认为仍需延长测试时间。”

第三段摘要：

“项目负责人确定下周五上线。”

如果最终汇总阶段无法正确处理这些信息之间的先后关系，可能同时保留多个不同的上线日期，或者将初始建议误写为最终结论。

相比简单的固定长度切分，更合理的技术路线是：

按时间和话题组织文本 → 提取议题与关键事件 → 合并同一议题的讨论记录 → 判断最终状态 → 生成正式纪要。

实际实现中，可以结合重叠窗口、主题聚类和结构化事件提取，降低跨片段信息断裂的影响。

3. 语言流畅不代表事实准确

LLM擅长将零散的语言整理成连贯文本，但这种能力也可能掩盖原始信息的不确定性。

例如，会议中有人说：

“如果测试顺利，我们争取下周交付。”

生成的纪要却变成：

“会议决定下周完成项目交付。”

从语言表达来看，后者更简洁、更正式，但它将一个有条件的计划变成了确定承诺。

2024年EMNLP发表的研究《What's under the hood: Investigating Automatic Metrics on Meeting Summarization》分析了会议摘要中的信息遗漏、语言错误和说话人动态等问题，发现不少传统自动化评价指标难以充分反映这些错误。

这说明会议纪要质量不能只看文本是否流畅、摘要是否简洁，还需要检查事实是否与原始会议内容一致。

五、如何构建更可靠的AI会议纪要生成流程？

针对前面讨论的误差传播问题，可以从语音处理、结构化表示、LLM生成策略和结果校验四个层面优化。

1. 在ASR阶段保留时间戳与关键语音信息

相比直接输出一整段连续文本，带有时间戳和发言人标签的转写结果更适合作为下游模型输入。

例如：

{
  "start": 125.3,
  "end": 131.8,
  "speaker": "Speaker_02",
  "text": "目前测试尚未完成，暂时不能确定上线日期。"
}

这种结构至少保留了三个重要维度：发言内容、出现时间以及发言人归属。

当LLM生成的纪要出现疑问时，也更容易根据时间戳回到对应音频片段进行核实。

对于识别不确定的关键语句，还可以结合ASR置信度、专业词词典或候选识别结果进行复核，而不是要求LLM凭上下文直接补全。

2. 将会议事实提取与文字润色分开

直接要求LLM“根据会议记录生成一份完整纪要”，虽然简单，但模型需要同时完成事实识别、内容筛选、逻辑判断和语言组织。

一种更可控的方法是采用两阶段生成架构。

第一阶段：结构化事实提取

从会议转写稿中提取议题、讨论内容、会议决议、责任人、截止时间以及信息来源。

例如：

{
  "topic": "项目上线时间",
  "decision": "暂不确定上线日期",
  "owner": null,
  "deadline": null,
  "status": "pending",
  "evidence": ["segment_105", "segment_128"]
}

第二阶段：纪要文本生成

根据已经提取的结构化信息，按照企业要求的模板生成正式纪要。

这种设计可以将事实抽取与语言表达分离，降低模型在润色过程中改变原始信息含义的风险。

对于无法确认的责任人、日期和会议结论，应当保留空值或待确认状态，而不是自动补充看似合理的信息。

3. 为关键决策建立原文证据关联

对于重要会议，建议让每一项关键决策都能够关联到原始转写片段。

例如：

纪要内容	原始证据	处理方式
本周完成接口联调	发言人A在15:32明确要求	记录为任务
下周一上线	有人提出建议，但未达成一致	标记为待确认
李工负责测试	发言人身份与任务均已明确	记录责任人
项目预算增加20%	转写文本存在数字歧义	回听原始音频

通过这种方式，会议纪要不再只是对原文进行压缩，而是为重要结论保留了可以追溯的依据。

对于企业管理会议、项目验收会议等场景，这种可追溯性尤其重要。

4. 将语音识别、发言人信息和纪要模板统一管理

从实际产品架构来看，会议纪要的完整处理流程并不一定需要由多个独立软件拼接完成。

例如，熙瑾会悟将ASR语音识别、AI声纹识别、智能纪要生成与自定义纪要模板整合在同一套会议系统中，并支持Word文档导出。

对于企业来说，这种完整流程的价值在于减少录音文件、转写结果和纪要文档在多个工具之间的反复处理，同时能够根据不同会议类型统一纪要输出格式。

在技术架构层面，语音转写结果、发言人身份、时间信息以及会议结构化数据的衔接，是进一步提升会议纪要质量的重要基础。

对于需要内网处理会议数据的政企单位，还可以结合私有化部署，使语音处理和智能纪要生成在内部环境中完成。

六、AI会议纪要质量应该如何评价？不能只看CER和摘要流畅度

如果要对一套AI会议纪要系统进行实际测试，单纯计算语音识别准确率或者让大模型给纪要打分，并不足以反映系统在真实会议中的表现。

更合理的评估方式是将语音识别、发言人区分和最终纪要质量分开衡量，再分析不同环节之间的关系。

评估层面	关键指标	主要考察内容
ASR识别	CER / WER	基础文字识别质量
关键实体识别	准确率、召回率	人名、时间、金额、专业术语
发言人区分	DER	发言人标签与语音片段对应情况
声纹识别	误接受率、误拒绝率等	是否正确匹配已登记人员
会议决议提取	Precision / Recall	是否完整且准确地提取决议
行动项提取	Precision / Recall	是否遗漏或错误生成任务
责任人提取	准确率	任务与负责人是否对应
事实一致性	有证据支持的结论比例	是否编造或错误解释会议内容

例如，在一场包含20项明确任务安排的测试会议中，可以人工标注所有行动项，再检查AI会议纪要实际提取出多少项，以及其中有多少项能够与原始记录对应。

如果系统生成了18项行动安排，其中16项正确，对应的行动项精确率为：

Precision = 16 / 18 ≈ 88.9%

如果人工标注的20项行动安排中，系统正确找到了16项，那么召回率为：

Recall = 16 / 20 = 80%

这类指标能够更直接地反映会议纪要的实际可用性。

当然，正确提取行动项，并不代表责任人和完成日期也全部正确。因此，任务内容、责任人、截止时间最好分别评价，再增加联合准确率，判断一条完整行动项是否能够被正确还原。

此外，测试样本也不应该只包含安静环境下的标准普通话会议。多人轮流发言、重叠讲话、专业术语密集、方言混用以及会议室混响，都会对系统产生不同影响。

如果测试目标是企业真实使用场景，就需要让评估数据尽可能覆盖这些条件。

七、AI会议纪要的下一步，重点不只是更强的大模型

过去几年，语音识别与大语言模型的发展显著降低了自动生成会议纪要的技术门槛。如今，许多工具都能够将会议录音转成文字，再生成结构完整、语言流畅的总结。

但企业真正需要的，并不只是看起来完整的摘要。

一份会议纪要必须尽可能准确地保留会议事实，区分讨论建议与最终决议，明确工作分工，并让关键内容能够被核实。

从这个角度来看，AI会议纪要更接近一个多阶段的信息处理系统，而非简单的文本生成应用。

ASR负责还原会议语言内容，Speaker Diarization与声纹识别负责建立发言人关系，LLM负责理解和组织信息，纪要模板负责将结果转化为正式文档，而事实校验机制则帮助发现上述环节未能解决的错误。

这些环节并非彼此独立。一个否定词的漏识别、一段语音的发言人错配，或者一次跨段上下文关系的丢失，都可能影响最终生成的会议结论。

因此，未来评价AI会议纪要系统时，除了关注模型规模、生成速度和文字流畅度，还应该更加重视关键事实的保留能力、决议提取准确率、责任人归属以及结果可追溯性。

AI会议纪要真正需要解决的，不只是让机器听懂会议，而是让机器在整理会议时，尽可能不改变会议原本表达的事实与决定。