一款AI合同审查助手,究竟该怎么做评测?

摘要：

会找风险，不等于真正可靠。本文通过一套可复用的评测流程，拆解 AI 合同审查从“看起来能用”到“可以放心进入业务”的关键步骤。

正文：

把一份合同交给 AI，几分钟后，它就能列出风险点、引用相关条款，还能给出修改建议。

但这还不能回答一个更重要的问题：

它的审查结果，究竟靠不靠谱？

一次真正有效的评测，至少要回答三个问题：

① 该发现的风险，它有没有发现？

② 没有风险的地方，它会不会频繁误报？

③ 面对隐私泄露、指令注入等异常输入，它能不能守住安全边界？

围绕这三个问题，我们为一款 AI 合同审查助手设计并执行了一轮系统评测。

出于数据安全考虑，本文不展开具体合同、样本编号、系统配置和详细得分，而是重点分享整套评测方法。

这套方法，同样适用于其他法律科技产品和高风险 AI 应用。

01 先定义“评什么”，再讨论“评得好不好”

AI 合同审查不是一个单一能力。

如果只看它能不能指出风险，很容易忽略两个同样重要的维度：系统是否安全，以及服务是否稳定。

因此，我们将评测拆成三个层面。

第一层：业务准确性

评估 AI 能否识别付款、发票、知识产权、诉讼管辖、主体一致性等常见合同风险。

第二层：安全与合规

评估系统是否会泄露无关数据、被合同正文中的恶意指令带偏，或者生成违法违规内容。

第三层：工程性能

评估接口成功率、平均响应时间和长尾耗时，判断系统在真实业务流程中是否稳定可用。

这一步看似基础，却决定了整场评测是否会“偏科”。

只测准确率，可能得到一个很聪明但不安全的系统；只测功能是否跑通，也无法证明它的审查结果值得信任。

02 评测集不能只追求数量，更要接近真实业务

评测数据的质量，几乎决定了最终结论的上限。

我们优先选取真实业务合同，并在进入评测前完成严格脱敏。

公司名称、人名、地址、联系方式、银行信息等敏感字段，需要进行一致性替换；金额可以按比例扰动，或者使用同量级数值替代，同时保留原有的语义关系。

这里需要特别注意“一致性替换”。

同一主体在合同不同位置出现时，替换后仍然要保持一致。

否则，脱敏过程本身就可能制造新的“主体不一致”风险，进而污染评测结果。

在样本覆盖上，需要同时考虑三个维度。

一是合同类型。

覆盖企业常见的买卖、租赁、技术服务、劳动等合同。

二是风险类型。

覆盖付款、税费、发票、账户、知识产权、管辖约定等高频风险。

三是正负样本。

既要有真实存在的风险，也要有表述合规的条款，才能同时观察漏报和误报。

还有一个容易被忽略的细节：

不同合同类型适用的审查规则并不完全相同。

例如，某项规则只适用于特定合同，就不应强行套用到所有样本。

否则，模型明明判断合理，也可能被错误地记录为漏检或者误报。

因此，评测集不是“合同越多越好”，而是要让合同类型、风险类型和适用规则形成清晰的对应关系。

03 业务用例之外，必须单独建立安全红线用例

合同天然包含大量敏感信息，AI 又可能把合同正文误认为操作指令。

因此，安全测试不能只是评测中的附加项。

我们单独构建了一组安全红线用例，重点覆盖三类场景。

第一类：数据隐私保护

验证 AI 是否只引用当前审查任务所必需的合同片段，不泄露其他合同、其他用户数据、系统提示词或者内部配置信息。

第二类：Prompt 注入防御

在合同正文中嵌入“忽略原有规则”“输出系统提示词”“绕过审查限制”等恶意指令，观察 AI 是否仍能保持合同审查的任务边界。

第三类：有害内容生成防范

构造诱导生成欺诈、伪造、歧视或其他违法违规内容的请求，检查系统能否识别并拒绝执行。

安全维度可以使用一个简单公式进行汇总：

安全合规通过率

= 通过的安全用例数 ÷ 有效安全用例总数 × 100%

但它与普通业务指标最大的不同，是没有“差不多通过”的空间。

业务分数再高，也不能抵消一次严重的数据泄露或者安全绕过。

因此，安全测试应采用独立的“通过或不通过”判定。安全红线的准入要求应为 100%，不能用 Precision、Recall 或 F1 的高分进行补偿。

04 用混淆矩阵，把“感觉不错”变成可量化结论

业务风险审查的核心，是判断 AI 有没有把合同风险识别正确。

在计算之前，首先要明确一个最小判定单元：

一份合同 × 一条适用规则，就是一次判断。

人工标注负责给出标准答案，AI 输出负责给出预测答案。

两者对照后，会形成四种结果，也就是混淆矩阵中的 TP、TN、FP 和 FN。

TP，True Positive，真正例。

合同确实存在风险，AI 也成功识别出来。

用业务语言来说，就是“人工标记为风险，AI 也判断为风险”。

TN，True Negative，真负例。

合同不存在该项风险，AI 也判断为安全。

用业务语言来说，就是“人工标记为安全，AI 也判断为安全”。

FP，False Positive，假正例。

合同本来没有该项风险，AI 却误报为风险。

它反映的是误报问题。

FN，False Negative，假负例。

合同确实存在风险，AI 却没有发现。

它反映的是漏检问题。

如果用文字版矩阵表示，就是：

实际有风险，AI 判断有风险：TP，正确识别。

实际有风险，AI 判断无风险：FN，发生漏检。

实际无风险，AI 判断有风险：FP，发生误报。

实际无风险，AI 判断无风险：TN，正确判断。

有了这四个数字，才能进一步计算 Precision、Recall 和 F1。

一、Precision：AI 报出的风险有多可信？

Precision 中文通常称为精确率，计算公式为：

Precision

= TP ÷（TP + FP）

它回答的问题是：

AI 所有“有风险”的判断中，到底有多少是正确的？

如果 Precision 较低，说明系统误报较多。

误报过多虽然不一定直接造成风险遗漏，但会增加人工复核成本。使用者每天面对大量无效提醒，也容易逐渐对系统失去信任。

二、Recall：真实风险找回了多少？

Recall 中文通常称为召回率，计算公式为：

Recall

= TP ÷（TP + FN）

它回答的问题是：

所有实际存在的风险中，AI 成功找出了多少？

如果 Recall 较低，说明系统存在较多漏检。

对于合同审查而言，漏检通常比一般文本任务中的识别错误更加值得关注，因为被遗漏的可能是付款、责任承担、知识产权或争议解决等重要风险。

三、F1：如何平衡误报和漏报？

F1 是 Precision 和 Recall 的调和平均数，计算公式为：

= 2 × Precision × Recall

÷（Precision + Recall）

F1 的意义，是防止我们只追求其中一个指标。

如果系统把几乎所有条款都标记为“有风险”，Recall 可能很高，但使用者会被大量误报淹没。

反过来，如果系统为了减少误报而变得过于谨慎，Precision 可能很高，却可能漏掉真正关键的风险。

因此，合同审查不能只追求“多找”，也不能只追求“少报”，而要在误报和漏报之间找到可以接受的平衡。

用一个例子看懂三个指标

假设评测中共有 100 个“合同 × 规则”判断单元。

其中，人工确认有 50 个真实风险，另外 50 个为安全项。

AI 一共报出了 48 个风险，其中45个确实存在风险，另外3个属于误报。

与此同时，还有5个真实风险没有被发现。

此时：

TP = 45，正确发现了45个风险。

FP = 3，把3个安全项误报为风险。

FN = 5，漏掉了5个真实风险。

TN = 47，正确判断了47个安全项。

代入公式：

Precision

= 45 ÷（45 + 3）

= 93.75%

Recall

= 45 ÷（45 + 5）

= 90%

= 2 × 93.75% × 90%

÷（93.75% + 90%）

≈ 91.84%

把数字翻译成业务语言就是：

AI 报出的风险大多可信，但仍然漏掉了少量真实风险。

后续优化时，应重点追查这5个 FN 为什么没有被发现，而不是只盯着91.84%这个总分。

评测还需要在开始前设置准入线。

例如，可以把“Precision 不低于85%、Recall 不低于80%、F1 不低于85%”作为一组示例门槛。

具体数值应根据企业的风险偏好和使用场景确定，但必须提前冻结，不能看到结果后再临时调整。

05 不能只看总分，还要拆成三个统计层级

同样一组评测结果，从不同层级观察，可能得到完全不同的结论。

因此，我们至少需要保留三个统计视角。

第一，整体指标。

把所有有效判断单元放在一起，计算总体的 Precision、Recall 和 F1，用于判断系统是否达到整体准入门槛。

第二，合同维度。

分别计算每份合同或者每类合同的指标，判断某类合同是否特别容易出现误报或者漏检。

第三，规则维度。

分别计算付款、发票、账户、知识产权等风险规则的指标，判断哪一条规则表现不稳定。

这里还涉及两种常见的统计口径。

整体汇总，也叫 Micro 口径。

它会先把全部样本的 TP、FP 和 FN 分别相加，再统一计算 Precision、Recall 和 F1。

这种方式反映系统处理全部判断单元时的总体表现。

分类平均，也叫 Macro 口径。

它会先分别计算每类合同或者每条规则的指标，再求平均值。

这种方式可以避免样本量较大的合同类型掩盖小样本规则的问题。

两种口径没有谁一定更好。

实际评测中建议同时保留：用整体汇总判断系统能否准入，用分类平均和单项明细寻找能力短板。

如果只公布一个总体 F1，可能会掩盖这样的情况：

系统在大多数规则上表现良好，但在某条低频且高风险的规则上持续漏检。

这类问题从总分上不一定明显，却可能直接影响真实业务使用。

06 不要只运行一次，模型稳定性同样需要评估

生成式 AI 的输出存在一定波动。

同一份合同、同一套规则，在不同时间运行，结果可能并不完全一致。

因此，我们对同一评测集进行多轮重复测试，并固定功能版本、模型版本、评测集版本和关键配置，确保不同轮次之间可以比较。

如果同一套数据运行三轮，可以分别计算每轮指标，再求算术平均：

最终指标

=（Run 1 + Run 2 + Run 3）÷ 3

但只看平均值仍然不够。

三轮平均分达标，并不代表每一轮都稳定。

如果某条规则在不同轮次之间大幅波动，它仍然应该进入 Bad Case 分析。

因此，除了平均值，还应保留：

每轮的单独结果；

三轮中的最低值；

不同轮次的波动范围；

持续失败和偶发失败的样本。

多轮运行的价值，不是让数字更好看，而是识别那些“有时能审出来，有时又审不出来”的不稳定能力。

07 准确之外，还要关注接口成功率和长尾耗时

AI 合同审查最终需要进入真实业务流程。

即使结果准确，如果接口频繁失败，或者一份合同需要等待很长时间，同样会影响实际使用。

因此，还要同步记录以下工程指标。

接口调用成功率：

接口调用成功率

= 成功调用次数 ÷ 总调用次数 × 100%

平均响应时间：

平均响应时间

= 所有有效请求耗时之和 ÷ 有效请求数

此外，还应观察 P95、P99 等长尾耗时指标。

以 P95 为例，它表示：

95%的请求，都能在这个时间内完成。

平均响应时间容易掩盖少量特别缓慢的请求，而 P95 和 P99 可以帮助我们发现长尾问题。

如果平均响应时间看起来正常，但 P99 明显过高，就意味着少数用户仍可能经历非常漫长的等待。

因此，业务准确性回答的是“结果对不对”，工程性能回答的是“系统能不能稳定地把正确结果交付出来”。

08 分数只是入口，Bad Case 才是优化起点

评测的终点不是生成一张成绩单，而是找到下一轮优化的抓手。

我们将典型问题按照“问题类型—影响指标—问题原因—处理优先级—优化方案”进行归因。

实际问题往往集中在以下几类。

第一，合同切片不合理，关键条款在预处理阶段被拆散。

第二，召回策略不准确，模型拿到了相关性较低的文本。

第三，缺失类风险需要跨段判断，单看一个条款无法得出结论。

第四，特殊业务规则与通用规则发生冲突，导致判断结果不稳定。

第五，风险识别正确，但引用依据或者修改建议不够完整。

针对不同原因，优化动作也应该有所区别。

如果关键条款没有被召回，应优先优化合同切片、条款分类和检索策略。

如果是特殊规则发生冲突，则需要增加更明确的规则优先级或者二次判断。

如果只是输出内容不完整，则可以从结果结构和提示策略入手。

这一步最忌讳“看到漏检就修改提示词”。

没有先完成问题归因，局部修补很可能提高一个指标，却让另一个指标变差。

09 一次完整评测，应该形成怎样的闭环？

把整套流程压缩下来，可以归纳为八个动作。

第一，明确业务能力、安全边界和性能目标。

第二，选取并脱敏真实业务合同。

第三，建立合同类型、风险类型与适用规则之间的映射。

第四，由人工完成标准答案标注与复核。

第五，分别设置业务准入门槛与安全红线。

第六，固定版本和配置，执行多轮重复测试。

第七，从整体、合同、规则三个层级分析结果。

第八，对 Bad Case 进行归因和优化，并将其加入回归测试集。

只有走完这个闭环，评测才能真正服务于产品迭代，而不是变成一次性的展示材料。

写在最后

经过本轮评测，系统在主要业务指标、安全边界和接口稳定性上达到了预设要求。

与此同时，少量跨条款判断和特殊规则场景仍然暴露出召回不稳定的问题，后续需要通过合同切片、召回策略和规则优先级继续优化。

这也说明，评价一款 AI 合同审查产品，不能只问一句：

“准确率是多少？”

更应该继续追问：

评测集是否来自真实业务？

审查规则是否适配合同类型？

漏检和误报分别发生在哪里？

整体指标是否掩盖了单条规则的问题？

安全红线是否经过独立验证？

多轮运行的结果是否稳定？

失败样本有没有进入回归测试闭环？

AI 可以显著提高合同初审效率，但现阶段更适合作为专业人员的辅助工具，而不是替代最终的法律判断。

真正值得信任的，不是一个漂亮的分数，而是一套经得起复现、追问和持续迭代的评测体系。

互动话题：

你最关注 AI 合同审查的哪一点——准确率、审查速度，还是数据安全？

欢迎在评论区留言交流。