从一段会议录音到结构化待办清单：在一把 key 上串起转写、抽取与去重

为什么把流水线拆成多个环节

直接用一个大模型「一把梭」处理会议录音，通常有两个问题：一是音频转写本身并不是所有模型都擅长，二是长文本里抽取待办项需要稳定的结构化输出，单次调用很难同时兼顾质量与可控性。

更实用的做法是把任务拆成几个职责单一的环节，每个环节选当时最合适的后端：

• 转写：把音频变成带说话人、带时间戳的纯文本
• 抽取：从文本中抽取结构化待办项
• 去重合并：把不同模型或不同分片给出的重复项收敛成一份清单

在聚合站上，这三步可以共用同一个 API key，只是调用时换不同的模型名，不需要为每家厂商单独申请凭证。

第一步：转写

转写环节的目标不是「文本好看」，而是「后续抽取不丢信息」。几个实践要点：

• 保留时间戳。后续待办项如果带「约在 12:30 提到」这类定位，人工复核会快很多。
• 保留说话人标签。很多待办隐含在「你来跟进一下」这类句子中，说话人决定了责任人是谁。
• 不要在这一步做摘要。摘要会丢掉「谁、什么时候、要做什么」的细节，而这三样恰好是待办项的核心字段。

如果录音较长，按话题或静音段切片是常规做法。切片时让相邻片段有少量重叠，能减少句子被切断导致的抽取遗漏。

第二步：抽取

抽取环节建议让模型输出严格的结构化格式，而不是自然语言列表。字段可以设计得克制一些，例如：

• task：要做什么，一句话
• owner：责任人，未知则留空
• due：时间点或期限，未知则留空
• evidence：原文中的依据片段

evidence 字段很关键：它是后面去重和人工复核的依据，也让模型不容易凭空造出待办项。

在提示中明确「只抽取明确被指派或明确承诺的事项」，比笼统地说「提取所有待办」效果好得多。会议里大量的「我们以后可以考虑」并不构成待办。

第三步：跨模型去重

同一段文本交给不同模型抽取，得到的清单往往互有交集但不完全重合。有三种处理思路：

按字段做归一化后比对。 把 task 转成小写、去掉标点与语气词，再比较相似度。同一件事的不同措辞会落到相近的字符串上。

以 evidence 为锚点。 两条待办如果指向同一段原文依据，基本可以判定是同一件事，即使措辞差异很大。这比单纯比较任务描述更可靠。

取并集而非交集。 去重的目标是收敛重复，不是筛掉「只有某一个模型提到」的项。后者往往是漏抽的信号，更值得保留并标注来源。

一个务实的合并规则是：先按 evidence 聚类，再在簇内选表述最完整的一条作为代表，其余作为别名保留。这样既得到干净清单，又没有丢失信息。

多后端协作的实际配置

在一把 key 调多模型的前提下，流水线各环节可以这样分工：

• 转写用一个在长音频上稳定的模型
• 抽取用两到三个不同家族的模型并行跑，制造差异以便去重阶段收敛
• 合并阶段可以用一个擅长结构化输出的模型，也可以直接用规则代码实现

因为调用的是同一个聚合入口，切换模型只是改请求里的模型名，密钥管理、配额查看、账单都在一处。计费按官方价乘固定系数结算，跑多模型并行时成本是可预期的，不需要为每家单独对账。

常见坑

• 切片边界切断待办。 用重叠切片缓解，并在抽取提示里说明「片段可能不完整」。
• 责任人错位。 说话人标签错乱会直接导致 owner 填错，转写阶段就要检查。
• 相对时间未归一。 「下周三」需要结合会议日期才能落成具体日期，这一步要么在抽取时传入会议时间，要么在合并阶段统一处理。
• 去重过度。 两个相似但实际不同的任务被合并，比留下两条重复更麻烦。合并阈值宁可保守。

小结

把会议录音变成待办清单，难点不在单次模型调用，而在环节拆分与结果收敛。用一把 key 串起转写、抽取、去重三步，每个环节挑合适的后端，再用 evidence 作为去重锚点，得到的清单既干净又可回溯。