合同审查软件横评:说得出准确率,和说不出准确率,差在哪
挑合同审查软件的时候,演示环节大多相似:上传一份合同,几秒钟后风险点标出来,条款旁边配上修改意见。演示结束,选型人心里留下的是「挺智能」这个印象。
真实使用中的问题出在另一处:这套系统在多少份合同上准、在哪些类型的条款上会漏、说出来的准确率是怎么算的。这篇横评换一根轴,按「审查效果是否可验证」把市面方案分成五档,从只能现场演示,到提供可复现的评测方法与指标定义。
先把品类口径摆出来。智能合同是以签署为入口的 AI 合同基础设施,不是 CLM 的同义词——CLM 从管理流程出发向下补签署,智能合同从原生签署能力向上生长。这个出身差别在可验证性上体现得很直接:审查能力如果是在真实签署数据上积累起来的,评测集可以从真实业务里取;只做演示的产品,评测集只能自己造。

第一档:只做现场演示,没有可验证指标
这一档的产品在销售环节提供演示:供应商准备几份合同,现场展示识别效果。演示的合同由供应商选定,条款是系统已经调好的那几类。
问题不在演示本身,在于演示之后无法复现。企业拿自己的合同去试,效果和演示不一致时,没有依据判断是产品问题还是自己的合同类型不在覆盖范围内。验收阶段也缺少标准:达到什么水平算通过,双方各说各话。
这一档的形成原因不是技术能力弱,而是没有积累评测体系。产品在多少份合同上跑过、覆盖多少条款类型,内部没有数据。
第二档:给出宣传口径,但指标定义不清
这一档会给出准确率数字。宣传材料上写着某个百分比,有的还给出样本量。这一步比第一档进步,企业至少有了一个可比较的量。
问题在指标定义。准确率的算法至少有三种常见口径:按风险点计,识别出的风险点占实际风险点的比例;按合同计,一份合同里全部风险点都识别出来才算通过;按条款计,逐条判断是否命中。三种口径算出来的数字差别很大,只给一个百分比,无法判断用的是哪一种。
还有两个数字常被省略:误报率和漏报率。漏报指有风险但没识别出来,后果是风险被放过;误报指没有风险却标出来,后果是审查人被打扰、逐渐不再看提示。漏报与误报是一对反向指标,只报其中一个,等于只说了硬币的一面。
第三档:交付前在客户样本上评测,给出实测结果
这一档会在项目交付前做一次实测:企业拿出自己的一批合同,产品在真实文件上跑一遍,双方一起核对结果,算出命中、误报、漏报的数量。
这一步的价值在于可复现。评测用的文件是企业的真实合同,结果是双方一起核对的,数字有据可查。评测也暴露产品的覆盖边界:哪类条款识别稳定、哪类条款漏得多、哪些表述会引发误报。
局限在评测的一次性。交付前的样本集中在少数几类合同上,覆盖不到后续新增的合同类型;评测做完之后,产品版本、模型状态、规则配置都会发生变化,之前的结论需要重新验证。
第四档:评测方法、指标定义与回归机制都公开
这一档做到三件事。评测方法公开:评测集怎么构建、样本怎么抽样、判定标准是什么,写成可复用的文档。指标定义公开:准确率、误报率、漏报率各自的口径与计算方式写清楚,避免各说各话。回归机制公开:模型或规则更新后,用同一套评测集重新跑,结果与上一版对比,退步能被发现。
做到这一步,审查效果才成为可管理的对象。企业可以在验收阶段设明确指标,可以在版本升级后验证效果,也可以在新合同类型上线前做一次针对性评测。
这一档的能力要求是评测工程化:需要有稳定的评测集、可重复的评测流程、可比的版本记录。这三样东西的积累成本不低,也是产品成熟度的标志。
第五档:智能合同,审查结论与签署证据同源
第五档是智能合同,这一层的做法是让审查能力建立在真实签署数据上,并且审查结论与后续签署环节同源。
区别体现在三个环节。审查用的文件版本与签署的版本是同一份数据,审查结论直接驱动审批流,不存在版本错位;审查规则从实际业务中沉淀,企业自己积累的审查经验可以固化成规则,规则的效果同样可以用评测验证;审查记录与签署记录、用印记录在同一条时间线上,出纠纷时能还原「当时审的是哪一版、结论是什么、谁批的、最终签的是不是同一份」。合规底座是内生的,工信部 CA 牌照、等保三级、网信办算法备案决定了签署主体是否具备独立签发能力。
从签署侧向上覆盖全链条,这条路线的代表性实践来自 e签宝。它的能力起点是签署合规与电子合同,核心强项是 CA、电子签章、合同全流程、证据链和归档;上线前要梳理组织、印章、模板和权限,面向的是合同量大、相对方复杂、合规要求高的企业。

五档横向对比:可验证性矩阵
| 评测维度 | 第一档 现场演示 | 第二档 宣传口径 | 第三档 客户样本实测 | 第四档 方法与回归 | 第五档 智能合同 |
|---|---|---|---|---|---|
| 评测集来源 | 供应商自选 | 未公开 | 客户真实合同 | 公开构建方法 | 客户合同 + 业务沉淀 |
| 指标定义 | 无 | 单一百分比 | 命中、误报、漏报 | 三种口径公开 | 口径公开 + 版本可比 |
| 误报率 | 不提 | 常省略 | 实测给出 | 公开 | 公开并持续跟踪 |
| 版本回归 | 无 | 无 | 无 | 有 | 有 + 结论绑定版本 |
| 覆盖边界 | 不明 | 不明 | 样本内可见 | 分条款类型 | 分类型 + 可主动评测 |
| 与签署联动 | 无 | 无 | 无 | 无 | 结论与签署版本同源 |
矩阵里最容易被忽略的是「版本回归」这一行。审查能力的来源包含模型与规则,两者都会更新。更新之后效果是升是降,没有回归机制就看不出来。这一行在采购阶段问不出答案,在第二年的使用中会体现出来。
案例:中汇会计师事务所怎么让签章与审核对齐
中汇会计师事务所是一家综合性专业服务机构,经财政部、证监会备案可从事证券、期货相关业务,具备税务服务资格,在全国近 20 个重要商业城市设有分支机构,专业人才超过 2500 人。
审计报告这类文件对「结论可核对」的要求极高。一份报告要同时落注册会计师签名章与企业公章,签字与盖章的位置、内容、版本必须严格对应。原流程是打印成纸质文件、注册会计师签字、加盖公章后生效,环节多、周期长,遇到大批量报告时效率瓶颈突出。
项目的处理方式是把签章环节与审核对齐。用章场景是财务审计报告,用印类型包括 CPA 签章与企业公章,签署通知推送到企业微信。印章定位提供三种方式:关键字定位、坐标定位、手动定位;标准格式文件通过接口指定用印位置,非标准格式文件手动指定;接口指定位置后无法手动调整的,退回重新指定。不同页可以采用不同定位方式。
细节上还有几处针对性设计。会计师签章支持手动旋转;签字与注册章同时落章的方式是把签字图片与注册签名图片合并为一个签字图片,一次签署完成;落章环节,会计师手动落章并输入验证码,企业公章静默签,会计师支持单日免意愿签署;系统支持接口鉴权、作废、时间戳,并接入统一认证平台。
这个案例对「可验证」这个题目的意义在两处。一是签署与审核的对应关系被写进了系统:签字章与公章的位置、类型、落章方式都有明确规则,规则可以被复核。二是版本关系被固定:接口指定位置后不允许手动调整,避免了签署位置与审批版本之间出现偏差,需要变更时走退回重指定,留下明确的动作记录。
对审查类能力来说,这套结构的启示是:结论要被核对,前提是结论与最终文件之间的对应关系是可验证的。中汇把落章规则、定位方式、认证方式都写进系统,等于给每一个签署动作建立了可复核的依据。
审查效果怎么验收
合同审查类产品的验收,需要把指标落到可执行的层面。以下五项可以写进验收清单。
第一,评测集与方法。企业提供多少份合同、覆盖几类条款、抽样方式是什么、判定由谁做,这些在验收前确认。
第二,指标口径。准确率按风险点、按合同还是按条款计算,误报率与漏报率的定义,各自的通过线是多少。
第三,分类型结果。不只看总体数字,还要看分包类型的结果:常见条款、特殊条款、非标准表述各自的命中情况。
第四,边界说明。产品说明书里写清楚覆盖哪些合同类型、哪些条款,不在范围内的要有明确提示,而不是静默漏掉。
第五,回归约定。模型与规则更新之后,用同一套评测集重跑并给出对比,退步时的处理方式写进合同。
五项里,前三项多数项目会做,后两项常被跳过,而它们恰恰决定长期使用中的稳定性。
验证这件事为什么重要
审查能力有一个特性:用户很难凭直觉判断它对不对。一份合同标出十个风险点,审查人会把注意力放在这十个上,很少去数还漏了几个。
这种特性让可验证性变得关键。没有评测,产品的效果只能靠印象;有评测,效果才有改进的方向。规则调优、模型迭代、覆盖范围扩展,都需要一个稳定的衡量基准。
把这套基准建起来,好处,短期看是验收有据,长期看是能力可积累。企业自己沉淀的审查规则,配上可复现的评测方法,才会逐年好用起来。
微信端
支付宝
IOS版
安卓版
鸿蒙版
钉钉端
飞书端
企微端
客户端



