合同抽取为什么需要离线评测 | 聂二

做合同信息抽取时，最容易掉进的坑是把问题理解成“prompt 写得还不够好”。

这当然有一部分是真的。合同里的费率、份额结构、申赎规则、投资策略、参考基准等字段，确实需要清晰的字段定义、边界条件和输出格式约束。但在真实企业项目里，prompt 只是抽取链路的一层。真正决定系统能不能上线、能不能迭代的，是有没有一套离线评测机制。

没有评测时，团队通常会这样工作：发现某份合同抽错了，就补一句 prompt；又发现另一份合同漏了，就再补一句；过几天旧样本又坏了。每次修改看起来都在解决问题，但没有人能回答一个更基本的问题：这一版到底比上一版更好，还是只是修了一个点、弄坏了三个点？

合同抽取的错误不是单一类型

合同抽取和普通摘要不一样。它不是“意思差不多就行”，而是要把一组字段稳定落到业务系统里。

常见错误至少有几类：

字段值错了：比如把管理费率、托管费率、销售服务费率混在一起。
字段范围错了：比如只抽到了 A 类份额，没有抽到 C 类份额。
单位或口径错了：比如把年化费率、一次性费用、阶梯费率写成同一种表达。
证据位置错了：字段值看起来对，但引用的原文不是支持它的条款。
缺失判断错了：合同里没有明确写，模型却根据相似合同补了一个看似合理的值。
合并逻辑错了：同一字段在正文、附件、补充条款里多次出现，最终结果没有按规则取舍。

这些错误很难只靠“再把 prompt 写详细一点”解决。因为每类错误对应的原因不同：可能是 PDF 解析漏字，可能是分块切断了跨页表格，可能是字段定义不清，可能是模型对同义表述不稳定，也可能是后处理合并规则有问题。

如果没有评测，所有问题都会被粗暴归因成“模型不够准”。

Golden set 是工程基线，不是展示材料

合同抽取的第一步评测资产，是一批脱敏后的 golden set。

它不需要一开始很大，但必须覆盖真实难点：不同格式的合同、不同份额类别、不同费率表达、正文和附件重复出现的字段、表格跨页、字段缺失、字段存在但需要条件判断的情况。

每个样本至少要包含三类内容：

标准答案：字段值、适用范围、单位、是否允许为空。
证据片段：支持该字段的原文位置或原文摘录。
标注说明：为什么这样标，哪些相似表述不应该算对。

很多团队只标字段值，不标证据。这样短期更快，但后面会很痛苦。因为字段值相同并不代表抽取逻辑正确。模型可能只是从别处猜到了一个值；一旦合同结构变化，它就会失效。

证据校验能把“答案看起来对”变成“答案由合同文本支持”。这对合同抽取尤其重要，因为用户最终复核的不是模型自信程度，而是原文条款。

字段级评测比整份合同打分更有用

合同抽取不能只看整份合同的通过率。一个样本里通常会有多类字段，有些字段简单，有些字段高风险。把它们混成一个总分，容易掩盖真正需要修的地方。

更有用的做法是字段级评测：

每个字段单独统计准确率、召回率和缺失率。
对高风险字段单独设更严格的阈值。
区分 exact match、规范化后匹配、部分匹配和不可判定。
对多值字段按集合比较，而不是按字符串整体比较。
对费率、日期、金额等字段先做单位和格式归一化，再比较。

例如，同一个年化费率可能被写成百分比、中文数字或条款描述；不同费率类别也可能使用相近措辞。评测脚本需要理解这些差别，而不是只做字符串相等判断。

证据校验能压住幻觉和误归因

在合同抽取里，我更倾向于把字段值和证据一起作为输出契约。

一个字段如果没有证据，即使值看起来合理，也应该降低置信度，甚至进入人工复核队列。证据校验至少要回答三个问题：

证据片段是否真的来自当前合同。
证据片段是否包含或支持该字段值。
证据片段是否对应正确字段，而不是相邻条款或相似字段。

这一步不是为了让系统“看起来可解释”，而是为了把错误暴露出来。很多抽取问题只有看证据才会发现：值是对的，但模型引用了错误段落；或者证据里写的是托管费，输出却填到了管理费。

证据校验还能帮助人工复核提速。复核人员不需要在整份合同里重新找条款，而是直接检查系统给出的来源是否成立。

错误归因决定下一步改哪里

离线评测不只是算分。更关键的是错误归因。

同样是字段抽错，处理方式可能完全不同：

解析错误：PDF 文本缺字、表格顺序错乱、页眉页脚干扰，需要改解析和清洗。
定位错误：相关条款没有进入模型上下文，需要改分块、召回或全文兜底策略。
字段定义错误：标注规范不清，prompt 和 golden set 都需要统一。
模型判断错误：上下文足够但模型仍选错，需要改提示词、示例或模型调用策略。
后处理错误：多个候选值合并、去重、单位转换时出错，需要改程序逻辑。
金标错误：评测样本本身标错，需要修标注，而不是迁就错误答案。

如果没有这层归因，团队会把所有失败都推给 prompt。最后 prompt 越写越长，规则越来越多，但系统未必更稳。

版本比较比单次准确率更重要

合同抽取系统一定会迭代：换分块策略、加字段、调整提示词、改后处理、替换模型、修 PDF 解析。每次变更都可能产生回归。

所以评测要支持版本比较：

这一版新增修复了哪些字段。
哪些旧字段发生回归。
回归集中在哪类合同或哪类表达。
高风险字段是否稳定。
修改带来的成本和耗时是否可接受。

这会改变团队讨论问题的方式。不是“我感觉新 prompt 更好”，而是“新版在费用类字段上修复了若干历史错误，但在多份额结构上出现回归，原因是合并规则把不同份额的字段压平了”。

这种结论才值得进入工程迭代。

Prompt 仍然重要，但它应该被评测约束

我不是说 prompt 不重要。合同抽取里，字段定义、反例、输出格式、缺失处理、证据要求都应该写清楚。

但 prompt 修改应该在评测框架里发生。每次改动后，都应该能看到字段级结果、证据结果、错误归因和版本差异。否则，团队只是在用人工直觉替代工程反馈。

对合同抽取这类高价值、高风险的信息抽取任务，我更信任这样的迭代闭环：

先建立脱敏 golden set。
为每个字段定义标准答案和证据规则。
跑字段级评测，而不是只看整份合同。
对错误做归因，区分解析、定位、模型、后处理和金标问题。
每次改动都做版本比较，明确收益和回归。

这套东西看起来比“改 prompt”慢，但它会让系统越改越稳。没有它，合同抽取很容易停在一个尴尬状态：demo 看起来能跑，人工复核时却不知道哪些结果该信。

如果你正在做企业 RAG、知识库、AI 客服或 Agent 工作流，可以通过页面下方微信二维码或邮件沟通，邮箱：contact@aildnc.com。