a-cdm × deer-flow 源码分析

主题

FDS-14 · B5 关键信息抽取 ​

1. 业务说明 ​

从精修后的会议文本里,把真正有用的东西逐条挑出来并归类:决策(会上拍板定下来的事)、风险(可能出问题、需要盯的隐患)、待办(谁在什么时候之前要做什么)、里程碑(关键时间节点 / 阶段交付)、关键事实(背景结论、数据、约束等需要长期记住的客观信息)。

核心做法是按类型分别抽:决策有决策的抽法,风险有风险的抽法,待办有待办的抽法——每一类用一组专门的抽取规则单独跑,各自只盯自己那一类,不互相干扰。不是把"决策+风险+待办+里程碑+事实"塞进一个大提示词一次性全抽。一次抽全部的写法在实践中会把决策抽成待办、把风险错位到别的类型、漏掉一半、还慢——这是现状(见 §9)最大的毛病。

每抽出一条,必须同时带上它在原文里的出处位置:对应到精修文本的哪一段、字符从哪到哪、是谁说的、对应录音的什么时间点。这个出处会写进项目事实库的 source_ref 字段(见 FDS-17),将来在结果页 / 看板上每条结论都能点回原文核对。没出处的条目不算数——这是后面 B6 出处校验(FDS-15)的硬门槛。

模型抽取难免有把握高低之分。把握不足的条目不直接当成定论:打上低置信标记,转交 B7 站内人工确认(FDS-16)由相关负责人拍板;把握足的也要先过 B6 出处校验,校验通过才进事实库 B8(FDS-17)。B5 自己不写库、不下最终结论,它只负责"分类型把候选挑出来、配齐出处、标好把握程度",真假由 B6 判、拿不准的由人定、落库由 B8 做。

B5 吃的是 B3 精修(FDS-12)产出的分段结构化文本——每段有序号、说话人、在原稿中的起止位置。正因为上游已经分好段、归好说话人、记好位置,B5 才能"按段抽取并精确配出处";精修质量直接决定抽取质量,这是"垃圾进垃圾出"链条的下一环。

2. 用户操作与界面 ​

  • 一般无需操作(流水线自动跑,跟在精修、纪要之后)。
  • 在会议结果页可看到分类型列出的抽取结果(决策 / 风险 / 待办 / 里程碑 / 关键事实分块展示),每条旁边有"看出处"——点开高亮原文对应片段、显示说话人与时间点。
  • 低置信条目带灰色"待确认"标识,提示这条还没定论,已转人工确认(B7);用户不在这里直接改,改在 B7 的确认任务里做。
  • 发现某一类抽得明显不对(如决策漏抽),可对该会触发重抽——重抽按类型独立跑,不必整场推倒重来。

3. 数据与接口 ​

输入:B3 精修产出的 meeting_files(kind=refined) 结构化文本 + segments(每段:序号、说话人、在原稿中的起止位置、时间点)+ 该精修文本的 content_hash(供事实库版本失效用,见 FDS-17)。

输出:一批抽取候选条目(尚未入库),交给 B6 校验。每条结构:

字段说明
kind类型:decision / risk / action(待办) / milestone / fact(与事实库 kind 对齐,见 FDS-17)
text标准化后的条目内容(一句话讲清这条是什么)
payload类型特有信息:action 带 owner/due;risk 带 severity;milestone 带 date;decision 带相关方;fact 带类别
source_ref出处:{file_id, char_start, char_end, speaker, ts} —— 精修文本的字符区间、说话人、对应时间点(写入事实库同名字段)
confidence0~1 把握度;低于该类型阈值的不直接定论,标记转 B7
extract_version产出时该类型抽取规则的版本号(规则升级 → 旧条目失效依据,见 FDS-17)
source_content_hash上游精修文本指纹(透传 B3 的 content_hash,上游变 → 失效依据)

接口:

  • 内部流水线节点产出候选 → 直接交 B6 校验节点(FDS-15),不经独立 HTTP 出口。
  • 校验通过的候选,由 B6/B8 侧经 POST /facts/commit 在事务里批量写入事实库(FDS-17);B5 本身不调用任何写库接口。
  • 低置信或 B6 判存疑的条目,经 B7 站内确认层(FDS-16)落人工任务;人答复后回灌重抽对应类型。

技能文件结构(每类型一个技能,遵循 FDS-04 规范):

skills/custom/meeting-extract-decision/      # 决策抽取
  SKILL.md          # frontmatter + "什么算决策、怎么措辞" 业务规则
  references/        # 决策措辞模板、边界细则
  eval/cases.jsonl   # 决策抽取验收样例
skills/custom/meeting-extract-risk/          # 风险抽取(同结构)
skills/custom/meeting-extract-action/        # 待办抽取(同结构)
skills/custom/meeting-extract-milestone/     # 里程碑抽取(同结构)
skills/custom/meeting-extract-fact/          # 关键事实抽取(同结构)

每个 SKILL.md 的 frontmatter(机器读):name / description(何时调用) / owner(业务方-会议域) / version(改一次升一版) / inputs(分段文本) / outputs(该类型候选条目列表) / acceptance(可证伪验收) / eval(必带样例)。正文是业务人维护的"什么算这一类、怎么措辞、什么不算"白话规则。

4. 技术实现(分步) ​

  1. 取分段输入:代码侧从 B3 产出读分段结构化文本,确认每段都带位置/说话人/时间点(精修没记位置则该会回退 B3,不带病往下抽)。
  2. 分类型并行调度(代码):对决策 / 风险 / 待办 / 里程碑 / 关键事实各起一路独立抽取,各自只加载自己那一类的技能与规则,互不串扰;五路可并行跑(不再串行等),每路只做一件事所以又快又准。
  3. 逐类型按段抽取(技能):每一路把分段文本喂给对应类型技能,技能按"什么算这一类、怎么措辞"挑出本类候选;只允许引用原文已有内容,不得臆造;输出每条候选 + 它落在哪一段。
  4. 位置装配(代码):把技能给出的"落在哪一段 / 哪句"换算成精修文本里的精确字符区间,连同该段说话人、对应录音时间点,组装成 source_ref;出处由代码确定性算出,不让模型自己报字符号(模型报的位置不可信)。
  5. 置信门(代码):每条按其类型阈值判 confidence——达标进 B6 校验;不达标不丢弃也不定论,打存疑标记直送 B7 站内确认(FDS-16)。阈值按类型分别设(如待办因要落到人、阈值更严)。
  6. 去重与归并(同场内)(代码):同一类型里指同一件事的重复候选合并为一条(保留出处最全的),避免一条决策被抽成三条。跨会的归并不在这里做(B10/FDS-19 处理)。
  7. 交接 B6:达标候选 + 完整 source_ref + extract_version + source_content_hash 一并交 B6 出处校验;校验过才由 B8 入库,存疑的进 B7。
  8. 重抽:规则升级或人触发重抽时,按类型独立重跑(只重跑受影响类型),旧条目按 FDS-17 的版本失效机制标 superseded。

5. 技能 or 代码 ​

  • 技能:每个类型的抽取规则——什么算决策 / 风险 / 待办 / 里程碑 / 关键事实、怎么措辞、什么明确不算(边界反例)。每类一个技能、各自专注,业务人可读可改、版本化(见 FDS-04)。规则会随业务理解演进,天然是技能。
  • 代码:分类型调度(决定起哪几路、并行编排)、位置装配(段 → 精确字符区间 + 说话人 + 时间点,确定性算出)、置信门(按类型阈值卡线、不达标转 B7)、同场去重归并、与 B6/B7 的衔接交接。这些是确定性、关乎正确性与不漂移,必须代码。

边界:模型只做"按这一类规则把候选挑出来并指出落在哪段",不允许它自报字符位置、不允许它下最终结论、不允许它决定某条够不够格入库。出处由代码算、真假由 B6 判、够不够格由阈值卡、拿不准由人定。判据一句(同 FDS-04):错了会算错数据 / 出假结论的 → 代码;换套"什么算决策"的规则 → 技能。

6. 二开归类 ​

🟢 复用 · 🟡 基于 · 🔴 自建(口径同 FDS-00 §二)

  • 🟡 基于 deer-flow:把"各类型抽取"做成挂在技能目录下的业务技能(决策/风险/待办/里程碑/事实各一个),跑在 deer-flow 引擎上;复用引擎的技能装配与执行机制,不动其内核。
  • 🔴 自建(acdm-backend 流水线节点):分类型调度与并行编排、位置装配、按类型置信门、同场去重归并、与 B6/B7 的交接。deer-flow 没有"按业务类型分路抽取 + 确定性出处装配 + 置信门"这套东西,必须自建。
  • 与上下游的衔接(读 B3 分段产物、交 B6 校验、不达标转 B7、达标由 B8 落库)是自建流水线节点的接线,均走 FDS-17 定义的事实库接口,不绕过。
  • 当前没有分类型抽取与出处装配(现状见 §9)。

7. 与人机协同模型关系 ​

  • B5 是任务流里的一个内层节点(AI 管"怎么把每一类挑出来"),产出落流水线状态,不直接面对用户拍板。
  • 低置信条目转 B7 → 对应人机协同里的任务卡片:相关负责人在站内确认任务上拍板,体现"AI 与人共写、拿不准不猜"。
  • 用户可在卡片层查看抽取结果、点出处核对、对某类否决重抽 → 符合"任务流可审阅 / 可回滚";按类型独立重抽使回滚粒度更细(只重跑出错那类)。
  • 抽取规则是业务人可维护的技能,挂在"业务规则可维护"(B13/FDS-22)闭环里:改规则 → 自动测试 → 人审 → 生效 → 可回退。

8. 验收(可证伪) ​

  • 可用:一场会跑完,决策 / 风险 / 待办 / 里程碑 / 关键事实分类型各自产出,不混类(随机抽 20 条,类型判对率达标,不出现决策被归成待办这类错位)。
  • 可用:每条候选都带 source_ref,点出处能高亮回精修文本对应片段,说话人 / 时间点与原文一致(配合 B6)。
  • 可用:把握不足的条目不进库而是出现在 B7 待确认列表;把握足的过 B6 后才入事实库。
  • 好用:同一场内同一件事不被抽成多条(同场去重生效);某类抽错时只重跑该类即可修复,无需整场重抽。
  • 好用:对比现状(一个大提示词串行抽全部),分类型并行后单场抽取时间显著下降,且类型错位 / 漏抽明显减少。

9. 现状 ​

能力不全且很差。现在是把文本塞进一个大提示词一次性把决策、风险、待办全抽,还开着思考模式串行跑——单场会议要等好几分钟;抽出来的东西类型互相串错位(决策被当待办、风险错归)、漏抽多、完全没有原文位置(看到一条结论没法回溯是谁在哪说的),也没有按类型的把握度判断与人工确认衔接。本章即把它改成"按类型分别抽 + 并行 + 确定性配出处 + 置信门转人工",从根上解决又慢又乱又不可追溯。

10. 风险与取舍 ​

  • 风险:类型边界模糊(一句话既像决策又像待办),分类型抽会被多路重复抽出。取舍:同场去重归并兜底;技能正文写清各类型边界与反例;真冲突的条目走 B7 由人裁定归属,不让模型硬分。
  • 风险:位置装配错位(段 → 字符区间算错)导致出处指错地方。取舍:出处一律代码按 B3 记录的段位置确定性换算,绝不采信模型自报;B6 出处校验做最终把关,对不上的不入库。
  • 风险:置信阈值设太松 → 假条目混入;太严 → 大量真条目挤进人工确认拖慢闭环。取舍:阈值按类型分别设(待办最严)、可配置,先偏严保正确,再依 B7 确认通过率回调。
  • 风险:并行五路抽取资源开销上升。取舍:每路只做一类、提示词短、关思考模式,单路更轻,总开销仍优于"一个大提示词开思考串行"的现状;必要时按会议体量调并行度。
  • 风险:业务人改某类抽取规则改坏。取舍:每个类型技能必带 eval 样例 + 改动走自动测试 + 人审(FDS-04 三条不让步),可一键回退到上一版本。

公司内部参考 · 由 claude-wiki-gen 基于源码自动生成的二次分析

a-cdm（公司内部）· deer-flow © ByteDance