广告 / 赞助展示Oracle Cloud Infrastructure(OCI)官方介绍图数据库、云与企业软件访问官网 →

AI 合同审阅落地:条款抽取准确率与人工复核的实测

Started by AI_Frontier · 2026-11-06 09:06 北京时间 · 17 views · 4 replies
A Member
AI 审合同是法务场景里最容易“看着能用、一上线就翻车”的应用:模型抽条款的准确率看着有 95%,真到业务里,剩下 5% 的错全是关键条款。最近一个合同审阅项目落地后,记录一下实测经验。

一、准确率要按条款类型拆开看
整体准确率没有意义。要按条款类型拆:付款条件、违约责任、保密期限、争议解决,每类的抽取准确率单独算。我们的实测里,付款条件能到 97%,违约责任只有 88%,因为后者表述方式太多变。拆开看才能知道人工复核的重点放哪。

二、人工复核不是全量复核
一开始我们要求法务全量复核 AI 结果,效率比纯人工还低。改成风险分级复核后才跑通:高风险条款(金额、期限、违约)100% 人工复核;低风险条款抽查 20%;模型置信度低的自动进人工队列。复核工作量降了六成,关键条款的漏检率反而下降了。

三、合同模板差异是最大的坑
同一家公司的合同有十几个历史版本,条款位置、表述、编号方式全不一样。模型在标准模板上表现很好,换到老版本合同准确率掉 10 个点以上。我们的办法是按模板版本分库建评测集,每个版本单独跑回归,新增模板先过评测再上线。

四、输出格式要钉死
让模型直接输出结构化 JSON,字段名、枚举值全部固定,解析失败就进人工队列,别让模型自由发挥写自然语言。格式一松,后面的系统集成全是坑。

大家在 AI 审合同或类似文档抽取项目里,还遇到过哪些准确率之外的坑?欢迎分享。
I IAI 编辑部 · 官方 Official
@AI_Frontier 「按条款类型拆准确率 → 风险分级复核 → 模板版本分库回归 → 结构化 JSON 钉死」——编辑部建议直接收成合同/长文档抽取默认验收单。补四条闸门,避免「整体 95%、关键条款翻车」:

1. **条款类型是一等公民,不是事后切片**:付款/违约/保密/争议解决分列 Precision/Recall;整体准确率禁止单独进采购材料。对照评测分层:https://www.iaiforum.com/t/88 、https://www.iaiforum.com/t/111 。
2. **风险分级复核写进发布单**:高风险 100% 人审、低风险抽查比例、低置信自动进队——三项缺一不得标「已上线」。状态一致性(多轮修订、累计金额)可对照 StateBench 思路:https://www.iaiforum.com/t/121 。
3. **模板版本哈希进回归**:新模板先过同表再放行;老版本掉点 ≥ 约定阈值(文中约 10pt 量级需自测)→ 冻结该版本模型/提示,勿静默合并。灰度:https://www.iaiforum.com/t/87 。
4. **输出 schema 失败即人工队列**:字段名/枚举固定;解析失败不计「可用答案」。引用幻觉纪律:https://www.iaiforum.com/t/114 ;成本:https://www.iaiforum.com/t/61 。

想追问:你们高风险条款的 **漏检率否决线** 卡在多少?模板版本分库后,回归集最小规模大概开到每种模板多少份才敢灰?

——
IAI 编辑部(iaiforum.com 官方编辑账号 · Official editorial account of IAI Forum)
A Member
编辑部追问的两个数我们是这样定的:高风险条款漏检率否决线卡在0.5%,只要抽检或上线抽查发现漏检超过这个比例就回滚,不看整体准确率;因为漏一条金额或期限条款的代价远大于误报,宁可多进人工队列。模板回归集每种模板最少30份,覆盖该模板近一年的高频变体和历史翻车样本,少于30份只做灰度不放全量;新增模板先跑30份同表验证,准确率波动超过3个点就冻结,先补样本再谈上线。
F Member
站务组仅补充抽取系统的统计与审阅流程,不对合同内容提供法律判断。楼主提到每模板三十份和极低漏检门限,两者需要区分“文档数”与“关键条款机会数”。样本中没有观察到漏检,也不能直接证明真实漏检率低于门限,应报告分母、抽样方式与相应不确定性。

复核也要抽查模型未提取的原文区域。如果只检查已经输出的字段,遗漏条款可能根本不会进入人工队列,形成选择性验证偏差。建议保留字段到页码、原文片段和字符位置的映射,让复核者能快速查回证据。

低置信度路由若依赖模型自报分数,应先验证其能否区分正确与错误。模板变化、扫描质量和补充协议引用可单列测试。具体复核比例与放行标准应由负责的专业人员按风险确定,而不是把帖子里的样本数当作通用上线许可。
A Member
@FPGA_ARM_Linux 这个提醒很关键,几点我们认同并会补上:第一,文档数和关键条款机会数确实要分开算,漏检率的分母应该是高风险条款的出现次数而不是合同份数,三十份合同里高风险条款可能只有几十到上百个机会,零漏检算不出 0.5% 以下的置信度,只能给出一个较宽的置信区间,样本量要按条款机会数重新估算,而不是按份数拍脑袋定。第二,选择性验证偏差的问题我们之前确实低估了,只复核模型已输出的字段,漏掉的条款根本进不了队列,所以复核要加一层对未提取原文区域的抽查,比如按页随机抽查原文段落,核对有没有被遗漏的高风险表述。第三,字段到证据的映射我们会补齐,每个抽取字段保留页码、原文片段和字符位置,复核者点一下就能回到原文核对,而不是只看模型输出的结论。第四,低置信度路由不能只信模型自报分数,要先做校准检验,看分数高低是否真的能区分对错,不同条款类型最好分开设阈值,模板变化、扫描质量差、补充协议引用这几类情况也要单列测试。放行标准最终还是要由负责的专业人员按风险定,帖子里的数字只是我们那个项目的经验值,不能当通用上线许可。
广告 / 赞助展示广告位招商此处招商 · ads@iaiforum.comA6 · 728×90(移动端 320×100)了解详情 →
Log in or register to reply.