10.6 经验总结与迁移应用

10.6经验总结与迁移应用

10.6.1八个关键经验

本章项目体量虽然不大，但涉及多模态 OCR、表格语义还原、字段语义锚定、数值校验闭环等多个关键议题。以下八条经验对同类项目具有普遍的借鉴意义。

经验一：输出端范式优于输入端范式。在数据采集场景中，必须先把“我要什么字段”完整定义清楚，再去驱动提取过程。先定义 Schema 再驱动提取，不仅显著降低 token 消耗，还能让校验闭环有明确的对象。这一原则与第 7 章经验一“提示词应描述能力，而非描述功能”在思想层面是统一的——能力的边界由目标决定，而不是由实现路径决定。

经验二：目标 Schema 必须包含元字段。仅有业务字段（如 revenue、net_profit）是远远不够的，必须在 Schema 中预留 extraction_confidence、needs_review、source_page 等元字段。这些元字段是工作流“诚实地表达不确定性”的载体，没有它们，AI 数据采集就退化为传统 OCR——只能给出“识别结果”，不能给出“识别质量”。

经验三：主图 DAG＋循环子图是多页／多对象处理的标准范式。扣子编程对“循环必须实现为子图”的硬约束，使得 OCR 节点必须在主图中以一个普通节点（ocr_loop）的形式出现，循环逻辑封装到独立的 loop_graph 子模块中。这一范式让主图保持清晰的 DAG 拓扑，同时把“对每一页做同样的事”这种循环语义集中表达。在本章实测中，OCR 循环子图占总耗时的 85%，是性能瓶颈，但也是后续并发化升级的天然抓手——只需把子图的串行迭代替换为并发调度，端到端耗时即可从“页数×单页时间”压缩到 max(单页时间)。

经验四：表格区域定位节点可以“轻量化退化”。许多初学者会跳过 table_locate 节点，直接把所有 OCR 结果丢给字段语义锚定节点，这种做法会导致字段语义锚定节点接收到大量不相关页面文本，token 消耗与错误率同步上升。但同样值得注意的是：当上游 OCR 节点已经在 OCR 同时给出页面分类信息时，table_locate 节点没必要再次调用大模型——一个简单的代码过滤就能完成任务（本章实测仅 5 毫秒）。“上游能在副产品中完成的事，下游就不必再调一次模型”，这是节点级精细化模型选型的延伸原则。

经验五：数值校验闭环必须采用“代码工具＋大语言模型”混合实现。可形式化的勾稽关系（如资产＝负债＋权益）用代码工具，速度快、零幻觉；需要语义判断的合理性校验（如同比变化是否合理、EPS 与净利润股本是否一致）用大语言模型。两层校验互补，构成可信数据采集的核心护栏。值得强调的是，校验的目的是“暴露不确定性”而非“修正数字”——本章测试中故意失衡的资产负债表数据没有被工作流“修正”，而是被诚实地标注为待复核，这正是数据采集工作流应有的态度。

经验六：异常标注必须显式化为 CSV 字段。许多 OCR 工具把置信度只输出在日志里，下游消费者根本看不到。本章工作流则把 extraction_confidence 与 needs_review 作为 CSV 的一等字段，使得下游 BI 系统可以基于这两个字段做自动化的“高置信入库／低置信复核”分支处理。元字段的显式化，是 AI 数据采集相对于传统 OCR 的核心进步。

经验七：领域专业术语是隐式角色化的最佳锚点。本章提示词没有写“请扮演财务数据分析师”，但通过“会计科目”“勾稽关系”“加权平均净资产收益率”等专业术语的密集使用，已经向模型隐式植入了专业角色。这种隐式角色化在数据采集场景下比显式角色描述更有效——专业术语本身就是最准确的角色锚点。

经验八：人工介入点必须从“事后审核”转为“按字段复核”。传统数据录入的人工介入点是“事后审核整张表”，效率极低；本章工作流把人工介入点重塑为“只复核 needs_review=Y 的字段”，把人的时间精准花在最需要的地方。当置信度足够高时，人甚至不需要看 PDF 原文，直接信任工作流即可。这种“按字段复核”模式可以让数据采集团队的产能提升 10 倍以上。

10.6.2迁移场景矩阵

本章工作流的骨架与提示词设计思路完全可以迁移到其他“非结构化输入 → 结构化输出”的场景。只需更换目标 Schema、调整字段语义锚定节点的提示词、根据领域特性调整数值校验规则，即可快速得到新的应用。表 10-8 给出了一个迁移场景矩阵。

表 10-8 AI 数据采集工作流的迁移场景矩阵

10.6.3扩展方向展望

在当前版本基础上，AI 数据采集工作流可以沿以下5个方向继续演进。

第一，把 OCR 循环子图升级为并发子图。当前实现采用顺序迭代，整体耗时与页数线性相关（本章实测 4.2 分钟即为顺序累加结果）。将子图调度模式从串行改为并发（multipart parallel），可以让端到端 OCR 耗时从“页数×单页时间”压缩到 max(单页时间)。这一升级在更长财报（如 100 页）或批量处理多份财报的场景中收益尤为显著。

第二，引入多语言支持。当前工作流主要面向中文财报，但若投研机构覆盖港股、美股，需要工作流同时支持英文报告。这一扩展不需要改变工作流结构，仅需在字段语义锚定节点的提示词中增加英文同义词列表（例如 "net profit" / "net income" / "profit attributable to shareholders"）。

第三，接入历史版本对比。在 CSV 输出节点之后，增加一个“历史版本对比”节点，把本次提取的财务数据与该公司过往年度的数据做横向比较，自动生成同比、环比指标。这一扩展可以把工作流从“采集工具”升级为“采集＋初步分析工具”。

第四，引入字段语义锚定的 few-shot 学习。当前的字段语义锚定提示词仅基于同义词列表，对长尾的非标会计科目（如某些境外子公司的特殊科目）可能误识别。改进方向是允许用户上传一份“已校对”的样例文件，工作流自动学习其字段映射规则，并应用到后续同公司、同年度的财报中。这是从“通用工作流”升级为“客户专属工作流”的关键一步。

第五，接入人工审核回流。当前工作流把 needs_review=Y 的字段写入 review_items，但用户的复核结果并未回到工作流。改进方向是接入一个“复核回流”节点：用户复核后的字段值会被记录到数据集，下次遇到同类型字段时优先使用。这一闭环可以让工作流在多次运行中持续提升精度。

10.6.4当前版本的局限性

出于工程诚实的考虑，有必要指出当前版本的5项局限。

第一，OCR 循环子图为顺序执行，端到端耗时偏长。本章实测中一份测试 PDF 的 OCR 阶段就耗时 4.2 分钟，整条工作流约 5 分钟。对于实时性要求高的场景，这一耗时仍偏高。改进方向已在 10.6.3 节第一条扩展方向中说明——子图并发化。

第二，扫描质量过低时OCR仍会失效。当 PDF 的扫描分辨率低于 100 dpi 时，多模态视觉模型的 OCR 准确率会明显下降，部分小字号字段（如表注、单位声明）几乎无法识别。改进方向是在 pdf_split 节点之前增加一个“图像增强节点”，自动做去噪、超分辨率、对比度增强等预处理。

第三，跨页表格的合并逻辑仍依赖大模型推断。当前工作流通过提示词约束模型“表格跨页时必须合并”，但合并逻辑由模型自行实现。若同一张表跨越 4 页以上，模型偶尔会出现“误合并”。改进方向是引入显式的“表格指纹”识别——基于表头列名做精确匹配，而非完全依赖模型语义判断。

第四，字段语义锚定节点对手写批注无法识别。许多财报扫描件含有审计师或公司财务总监的手写批注（如“已复核”“数据来源于子公司汇总表”等），这些批注往往含有重要的元信息，但当前 OCR 节点会忽略它们。改进方向是在 OCR 节点之后增加一个“手写检测”分支，对识别为手写的区域做二次精细 OCR。

第五，数值校验规则相对固定。当前工作流的勾稽关系检查仅覆盖了 5~8 条最常见规则；对于一些行业特有的勾稽关系（如银行业的资本充足率、保险业的偿付能力充足率），需要进一步扩展。改进方向是把校验规则提取为外部 YAML 配置文件，按行业分别配置。

这些局限同时也是后续章节可以展开的迭代起点。第 11 章在多源数据质检的场景中，将解决其中一部分问题——特别是“如何在多个来源不一致时仲裁出可信值”——大家可以把第 10、11 章合在一起读，建立对 AI 数据治理的完整范式认知。