在很多会议智能产品里“语音转文字”往往被认为是核心能力。但在真实政企、医院、高校、金融、制造等场景中会议系统真正难的并不是把音频转成文本而是把一次会议中的人、事、物、决策、任务和历史上下文组织起来。换句话说会议智能的关键问题不是这段话说了什么而是谁在什么背景下提出了什么问题这个问题和过去哪次会议有关最终形成了什么决议后续任务分配给了谁这件事有没有闭环下次开会时系统能不能自动带出相关历史信息这也是会悟在会议智能能力上持续演进的核心方向从“离线转写工具”逐步升级为“会议知识沉淀与追踪系统”。本文主要讨论会悟在会议内容结构化、事件抽取、知识图谱构建和检索增强问答方面的一些工程实践。一、会议智能为什么不能只做 ASRASR 解决的是声音到文本的问题。在会议场景中ASR 的输出通常是这样的张总这个项目下周必须完成联调接口问题由研发这边负责。 李工目前主要卡在第三方系统返回超时我们需要运维协助排查网络。 王经理那这件事今天先定下来研发负责接口运维负责网络周五前给结果。这段文字看起来已经有信息了但如果只停留在纯文本层面系统很难回答下面的问题项目的当前阻塞点是什么谁负责接口问题谁负责网络问题截止时间是什么这次会议形成了什么决议这个问题是不是上次会议也提到过后续有没有人反馈处理结果也就是说ASR 输出只是原始材料。真正有业务价值的是结构化之后的会议知识。会悟在这条链路上要解决的是从“文本”到“知识”的转换。整体流程可以抽象为Audio ↓ ASR 转写 ↓ 说话人分离 / 说话人识别 ↓ 段落级语义切分 ↓ 实体识别 / 事件抽取 / 关系抽取 ↓ 会议知识图谱 ↓ 纪要生成 / 待办追踪 / 历史检索 / 问答增强其中ASR 是入口知识图谱才是后续能力复用的底座。二、会议内容结构化的核心难点会议文本和普通文档不一样。普通文档通常有比较稳定的段落结构而会议文本具有明显的口语化、跳跃性和上下文依赖。在实际落地中会悟遇到的典型问题包括1. 口语表达不稳定同一个任务会议里可能有多种说法这个接口你们研发跟一下。 这个问题研发先接过去。 这块还是张工负责推进。 下周前把联调结果给出来。这些句子表面形式不同但背后的结构可能是类似的责任人研发 / 张工 任务接口联调 截止时间下周前 动作推进 / 跟进 / 给出结果如果只做关键词匹配很容易漏掉大量表达。2. 任务和决议经常跨句出现会议里很少有人按照“主语 谓语 宾语 截止时间”的标准格式说话。更多情况是多轮补充A这个接口现在还没通。 B是第三方返回超时。 C那研发和运维一起看一下。 A我们这边可以先排接口日志。 C行周五前给一个结论。真正的任务结构需要跨多轮对话合并任务排查接口超时问题 责任方研发、运维 截止时间周五前 背景第三方系统返回超时 来源本次项目推进会这要求模型不仅理解单句还要理解会议上下文。3. 说话人信息会直接影响语义在会议场景中同一句话由不同角色说出来含义可能完全不同。例如“这个问题我来处理。”如果说话人是项目经理可能表示任务分配确认。如果说话人是研发负责人可能表示研发侧承接。如果说话人是客户代表可能只是业务侧配合。因此会悟在结构化时不能只看文本内容还要结合说话人、角色、部门、历史上下文等信息。这也是会议系统区别于普通文本处理系统的一个关键点。三、从文本纪要到会议事件图谱传统会议纪要通常是线性的一、项目进展 二、存在问题 三、后续安排这种格式方便人阅读但不方便机器理解。会悟更关注的是将会议内容转成事件图谱。一个会议事件可以表示为Event { type: 任务分配, subject: 研发组, action: 排查, object: 接口超时问题, time: 周五前, source_meeting: 2026-xx-xx 项目推进会, participants: [张三, 李四, 王五], related_project: A 项目 }进一步可以转成图结构A项目 ──存在问题── 接口超时 接口超时 ──由谁排查── 研发组 接口超时 ──协同方── 运维组 排查任务 ──截止时间── 周五前 排查任务 ──来源── 项目推进会 项目推进会 ──参会人── 张三 / 李四 / 王五这样做以后会议内容不再是一段孤立文本而是一个可以被查询、关联和推理的结构化网络。例如用户可以直接问A 项目最近有哪些未闭环问题 张三在最近三次会议中被分配了哪些任务 接口超时这个问题最早是哪次会议提出的 本周有哪些会议决议需要跟进这类问题如果只靠全文检索很容易得到一堆相关段落而基于知识图谱可以直接返回实体、关系、时间线和任务状态。四、早期规则抽取方案的问题在早期版本中会议结构化可以采用规则 模板 关键词的方式实现。例如如果句子中出现 “负责”、“跟进”、“处理”、“推进” 并且附近出现人名或部门 则判定为任务分配事件伪代码大致如下defextract_task(sentence):action_words[负责,跟进,处理,推进,排查]ifany(winsentenceforwinaction_words):assigneefind_person_or_department(sentence)deadlinefind_time_expression(sentence)objfind_task_object(sentence)returnTaskEvent(assignee,obj,deadline)returnNone这种方法的优点是可控、可解释、上线快。但它有三个明显问题。1. 规则覆盖率有限真实会议表达非常灵活。规则能覆盖一部分高频说法但很难覆盖所有语义变体。比如下面几句话都可能表示任务分配这块研发先接一下。 后面你们把这个事情闭一下。 这个风险需要运维同步看。 会后麻烦产品拉一下需求清单。这些表达并不一定包含“负责”或“处理”但语义上仍然是任务安排。2. 跨句关系难以处理规则系统通常以单句为单位处理。但会议里的关键信息经常分散在多句话里A现在主要问题是模型响应慢。 B慢在哪 A首 token 时间比较长。 C那算法组会后看一下。 B明天下午前给一个优化方案。如果不做上下文合并很难得到完整结构任务优化模型首 token 延迟 责任方算法组 截止时间明天下午前3. 规则维护成本随场景膨胀不同客户、不同行业、不同会议类型的表达方式并不一样。医院会议、项目例会、审计会议、教学会议、生产调度会对“任务”“决议”“风险”“问题”的表达都不同。规则系统会逐渐变成规则越来越多 冲突越来越多 维护越来越难 泛化越来越差这也是会悟后续引入事件抽取模型和图谱表示学习的原因。五、会悟的结构化理解框架在新的实现中会悟将会议理解拆成多阶段管线。核心思想是不要求单个模型一次性完成所有事情而是把会议理解拆成多个可控模块每个模块负责一个相对明确的目标。整体架构如下ASR 文本 ↓ Speaker-aware Segment ↓ Topic Segmentation ↓ Entity Recognition ↓ Event Extraction ↓ Relation Linking ↓ Graph Construction ↓ Graph Retrieval / QA / Summary1. Speaker-aware Segment会议文本不能只按时间切分还要保留说话人信息。一个基础结构可以表示为{speaker:Speaker_01,start:12.5,end:18.7,text:这个接口问题我们研发这边先排查一下。}说话人信息会参与后续任务识别、责任人归因和会议纪要生成。2. Topic Segmentation长会议通常会讨论多个议题。如果不做议题切分后续摘要和图谱构建容易混在一起。会悟会根据语义边界、停顿、关键词迁移、说话人轮次变化等信号将会议拆成多个主题段Topic 1项目进展同步 Topic 2接口超时问题 Topic 3上线计划确认 Topic 4后续任务分配每个主题段内部再做事件抽取和关系建模可以显著降低上下文噪声。3. Entity Recognition会议中的实体不仅包括人名、机构、时间还包括大量业务实体人员张三、李四、王经理 部门研发组、运维组、产品部 项目A 项目、二期平台、数据治理系统 问题接口超时、模型延迟、权限异常 任务日志排查、方案评审、环境部署 时间周五前、下周一、月底实体识别的关键不只是“识别出来”还要做归一化。例如张工、张三、研发张三在图谱中应该尽可能指向同一个实体。否则图谱会出现大量重复节点影响后续检索和推理。4. Event Extraction会议中的事件可以分成多类问题提出事件 决议形成事件 任务分配事件 风险提示事件 进度同步事件 需求变更事件 责任确认事件每类事件都有不同 schema。以任务分配事件为例{event_type:task_assignment,task:排查接口超时问题,assignee:研发组,collaborator:运维组,deadline:周五前,source_sentence:研发和运维一起看一下周五前给一个结论。}这种 schema 化结果可以直接进入任务看板、会议纪要和图谱系统。六、关系链接从抽取结果到知识图谱抽取实体和事件之后还需要解决一个更关键的问题这些信息之间到底是什么关系例如研发组 接口超时问题 A 项目 周五前 项目推进会这些节点之间可能存在多种关系研发组 - 负责 - 接口超时问题 接口超时问题 - 属于 - A 项目 接口超时问题 - 来源 - 项目推进会 接口超时问题 - 截止时间 - 周五前在会悟中关系链接不是简单地靠距离判断而是综合多种信号文本语义相似度说话人上下文句法位置议题段归属时间邻近性历史会议关联图结构邻居信息。一个简化的关系评分可以写成Score(h, r, t) α · Sim_text(h, t) β · Sim_topic(h, t) γ · Speaker_context(h, t) δ · Graph_context(h, t) ε · Time_decay(h, t)其中h表示头实体r表示关系t表示尾实体Sim_text表示文本语义相似度Sim_topic表示议题一致性Speaker_context表示说话人上下文Graph_context表示图结构上下文Time_decay表示时间衰减。这类综合评分比单纯规则更稳定也更适合多轮会议场景。七、为什么需要图谱表示学习当会议数量较少时图谱可以依赖显式规则构建。但随着系统长期运行会议图谱会不断增长会议节点越来越多 人员节点越来越多 任务节点越来越多 项目节点越来越多 历史决议越来越多 跨会议关系越来越复杂这时系统需要的不只是“建图”还需要“理解图”。例如下面这个问题这个接口超时问题和上个月的系统卡顿问题是不是同一类风险这不是简单关键词匹配能解决的。因为两个问题表述不同但可能在图结构上连接到相似的系统、相似的责任部门、相似的故障类型和相似的处理路径。因此会悟可以在图谱之上引入表示学习。基本思路是为每个节点学习一个向量表示NodeEmbedding f(text, attribute, graph_context)这个向量同时融合节点文本语义节点属性邻居结构历史关系时间信息。这样系统就可以进行更高层的能力相似问题发现历史案例推荐任务风险预测会议主题聚类决议闭环分析跨会议知识检索。八、GNN 在会议知识图谱中的作用会议知识图谱天然适合 GNN。因为会议中的一个节点往往要通过邻居才能理解。例如“接口超时”这个问题节点如果只看文本它只是一个技术问题。但如果看它的邻居语义会更完整接口超时 ├── 属于A 项目 ├── 责任方研发组 ├── 协同方运维组 ├── 来源6 月项目推进会 ├── 状态待处理 └── 历史相似问题第三方系统响应慢GNN 的 message passing 机制可以将这些邻居信息聚合进节点表示。简化公式如下h_v^(k) UPDATE( h_v^(k-1), AGGREGATE({h_u^(k-1), u ∈ N(v)}) )其中h_v表示当前节点向量N(v)表示当前节点的邻居集合AGGREGATE表示邻居聚合UPDATE表示节点状态更新。经过多层传播之后一个节点不仅包含自身文本信息也包含周围子图结构。这对于会议知识追踪非常重要。九、多模态融合文本、结构、角色与时间会议图谱和普通知识图谱相比有一个明显特点它不只有实体关系还有说话人、时间线、音频片段、会议上下文和业务状态。因此会悟的图谱表示不能只看文本或拓扑而要做多模态融合。可以抽象成Z Fusion( E_text, E_graph, E_speaker, E_time, E_attribute )其中E_text文本语义向量E_graph图结构向量E_speaker说话人和角色向量E_time时间位置和时间衰减特征E_attribute任务状态、项目类型、部门属性等结构化特征。直接 concat 是最简单的方式Z [E_text; E_graph; E_speaker; E_time; E_attribute]但在实际工程中简单拼接容易出现一个问题某一种模态过强导致其他模态被淹没。例如文本 embedding 很强时系统可能过度依赖文本相似度而忽略真实图结构。在会议场景中这会导致一些表面相似但业务无关的问题被错误关联。因此更稳妥的做法是引入门控机制g_i sigmoid(W_i · E_i b_i) Z Σ g_i · E_i让模型根据当前样本动态决定不同模态的权重。例如对任务分配角色和说话人权重更高对相似问题检索文本和图结构权重更高对进度追踪时间和状态权重更高对历史会议关联图结构和议题上下文权重更高。这比固定权重更适合复杂会议场景。十、RAG 与知识图谱的结合很多会议智能系统会直接使用 RAG用户问题 ↓ 向量检索 ↓ 召回相关会议片段 ↓ 大模型生成答案这个方案能解决一部分问题但在会议场景中仍然有缺陷。例如用户问A 项目接口问题现在是谁负责纯向量检索可能召回很多包含“A 项目”“接口问题”的片段但不一定能准确判断最新责任人。因为它缺少结构化状态。会悟更适合采用 GraphRAG 思路用户问题 ↓ 实体识别 ↓ 图谱定位 ↓ 关系扩展 ↓ 片段召回 ↓ 结构化上下文拼装 ↓ 大模型生成答案例如Query: A 项目接口问题现在是谁负责 Step 1: 识别实体 A 项目、接口问题 Step 2: 在图谱中找到相关任务节点 Step 3: 查询任务当前责任人、状态、截止时间 Step 4: 回溯来源会议和原始发言 Step 5: 生成可追溯回答最终回答可以是A 项目的接口问题当前由研发组负责运维组协同排查。 该任务来源于 6 月 12 日项目推进会会上明确要求周五前给出处理结论。 原始依据来自王经理的发言“研发和运维一起看一下周五前给一个结论。”这类回答比普通 RAG 更可靠因为它不仅给出答案还能给出来源、关系和上下文。十一、会议纪要生成为什么也需要图谱会议纪要看起来是生成式任务但高质量纪要并不能完全依赖大模型自由生成。原因很简单会议纪要必须准确。尤其在政企、医院、高校、金融等场景中会议纪要往往涉及责任边界、任务分配和后续检查不能随意发挥。因此会悟更适合采用“结构化信息约束生成”的方式。流程可以表示为ASR 文本 ↓ 结构化事件抽取 ↓ 任务 / 决议 / 风险 / 问题归类 ↓ 图谱关系校验 ↓ 纪要模板组织 ↓ 大模型语言润色也就是说大模型不是直接从长文本里自由生成纪要而是在结构化结果的约束下生成。例如先抽取出{issues:[接口超时,上线环境未验证],decisions:[周五前完成接口排查,上线前完成环境验证],tasks:[{task:排查接口超时问题,assignee:研发组,deadline:周五前},{task:验证上线环境,assignee:运维组,deadline:上线前}]}然后再生成纪要。这种方式的优势是纪要结构更稳定任务不容易漏责任人不容易错后续可以直接进入待办系统可以回溯到原始会议片段。十二、工程落地中的几个关键问题1. ASR 错误会向下游传播ASR 是整个链路的入口。如果转写阶段把人名、项目名、专业术语识别错下游实体识别和图谱构建都会受影响。因此会悟在私有化场景中通常需要结合客户词表、项目词典、部门人员名单和业务术语进行增强。例如通用 ASR三期平台 业务词典三清平台 通用 ASR微服务网关 业务词典会悟网关这些词如果不纠正后续图谱会出现错误节点。2. 说话人分离不等于真实身份识别说话人分离只能知道“这是第几个说话人”并不天然知道这个人是谁。例如Speaker_01 Speaker_02 Speaker_03要映射到真实人员还需要结合会议签到声纹库发言自报身份上下文称呼参会人员名单人工确认机制。因此在工程设计上不能把 diarization 结果直接当作真实姓名使用。更合理的做法是Speaker_01 → 候选人张三 / 李四 置信度不足时 → 标记待确认 确认后 → 回写图谱这样可以避免错误归因。3. 图谱去重比建图更难构建知识图谱时一个常见问题是节点爆炸。例如同一个项目可能被写成A 项目 A项目 一期 A 项目 A 平台 A系统如果不做实体归一化图谱会变得非常混乱。会悟需要在实体层做多级归一字符串规则归一 ↓ 业务词典匹配 ↓ 向量相似度匹配 ↓ 上下文关系校验 ↓ 人工确认或低置信度挂起实体归一化的质量往往直接决定图谱可用性。4. 长会议不能一次性丢给大模型很多会议持续一两个小时甚至更长。即使大模型支持长上下文也不意味着应该把完整转写文本一次性丢进去。原因有三个成本高延迟大细节容易丢失。更稳妥的方式是分层处理句子级清洗 ↓ 段落级摘要 ↓ 议题级结构化 ↓ 会议级汇总 ↓ 跨会议图谱沉淀这种方式可以降低长文本处理压力也更容易做错误定位。十三、效果评估不能只看“摘要好不好”会议智能系统的评估维度应该拆开看。如果只问“纪要好不好”很难定位问题。更合理的评估指标包括模块评估指标ASR字错率、术语识别准确率、时间戳对齐说话人分离DER、说话人切换准确率实体识别Precision、Recall、F1事件抽取事件类型准确率、参数完整率关系抽取关系分类准确率、误连率任务提取责任人准确率、截止时间准确率纪要生成事实一致性、遗漏率、可读性图谱检索命中率、可追溯率、答案一致性其中对企业用户最重要的通常不是“语言是否优美”而是任务有没有漏 责任人有没有错 时间有没有错 结论有没有编 来源能不能追溯这也是会悟做结构化约束和知识图谱的核心原因。十四、最终架构总结会悟的会议智能能力可以概括为一个多层架构┌─────────────────────────────┐ │ 会议应用层 │ │ 纪要 / 待办 / 检索 / 问答 │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ 知识服务层 │ │ GraphRAG / 图谱查询 / 追溯 │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ 图谱构建层 │ │ 实体 / 事件 / 关系 / 状态 │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ 语义理解层 │ │ 议题切分 / 事件抽取 / 归一化 │ └──────────────┬──────────────┘ ↓ ┌─────────────────────────────┐ │ 音频处理层 │ │ ASR / 说话人分离 / 时间戳 │ └─────────────────────────────┘从这个角度看会悟并不是简单地把会议录音转成文字也不是只做一份自动纪要。它真正要解决的是如何把每一次会议产生的信息沉淀为可检索、可追溯、可复用、可闭环的组织知识。这要求系统同时具备四类能力音频理解能力把会议声音稳定转成带时间戳、带说话人信息的文本语义结构化能力从口语化会议内容中提取议题、任务、决议、风险和问题图谱建模能力把一次次会议中的实体和事件连接成长期知识网络检索问答能力基于图谱和原文证据回答可追溯的业务问题。会议智能的终点不是“生成一篇纪要”而是让会议真正进入组织的知识流和任务流。当会议内容能够被结构化、被关联、被追踪、被复用会议系统才不只是一个记录工具而是企业知识管理和协同决策的基础设施。这也是会悟持续建设会议知识图谱能力的核心价值。