不用大模型，20秒查合同冲突
Isaacus 开源了一套法律文档冲突检测方案，用 Encoder、NLI 和重排模型筛查合同偏差与缺失条款。它比直接让大模型通读更可控，但距离完全本地、开箱即用仍有距离。
不用大模型，20秒查合同冲突
11 月 13 日，Isaacus 法律工程师 Tabs 发布了一套法律文档冲突检测工具，用 Encoder、自然语言推理和重排模型比对两份合同中的条款偏差与内容缺口。项目代码以 MIT 许可证放在 GitHub，原始介绍发布于 Reddit r/MachineLearning，随后因社区的自推广版规被移除，但代码仓库和教程仍然可用。(reddit.com)
这套工具最值得关注的地方，不是它又做了一个合同审查界面，而是它把大模型从冲突判定的核心路径中拿掉了。生成式模型只在最后负责总结、建议和改写，真正决定两项条款是否相关、是否存在实质差异的，是更小、更稳定的判别式模型。
作者给出的极端数字很直观：如果两份合同各有 133 项条款，逐条两两比较需要处理 133 × 133，也就是 17,689 个条款组合。若每一个组合都交给 Claude、GPT 或其他生成式模型独立判断，成本、延迟和结果稳定性都很难接受；而这套方案先用向量相似度砍掉绝大多数无关组合，再让分类器和重排模型审查候选项，最长的示例文档组合可以在 20 秒以内完成。
这不是传统的文本找不同
**法律文档冲突检测是一种按法律效果而非字符变化识别文档差异的任务。**它要发现的不是把「30 天」改成「45 天」这么简单，而是两段措辞看起来不同，却实际规定了同一项义务；或者两段都在谈责任限制，但一份合同只限制供应商责任，另一份合同同时限制双方责任。
项目把结果分成两类：
- Deviation（偏差）：两项条款讨论同一事项，但产生的法律效果不同。
- Gap（缺口）：一份文档存在某项规定，另一份文档没有对应内容。
这个区分很重要，因为合同审查真正消耗时间的，往往不是确认文字有没有变化，而是回答「这个变化是否影响权利、义务、金额或责任分配」。Word 修订模式擅长字符级红线，却无法发现整段条款被换一种说法重新表达，更无法判断模板要求的知识产权归属条款是否彻底缺失。
NLI 和 Encoder 各自干什么
**自然语言推理（NLI）是判断两个文本之间属于蕴含、矛盾还是中立关系的分类任务。**经典 SNLI 数据集包含约 57 万对人工标注句子，标签就是 entailment、contradiction 和 neutral，这类任务天然适合回答「条款 A 是否支持、反对或无法覆盖条款 B」。(huggingface.co)
**Encoder 模型是把输入文本编码为向量或分类分数、但不继续生成长文本的模型。**它不像聊天模型那样逐词预测答案，而更像一个受过训练的审查员：读完两段条款后，只输出相关度、冲突概率或分类标签。
**Bi-encoder 和 Cross-encoder 的分工构成了这套系统的性能基础。**Bi-encoder 分别编码两项条款，可以提前保存向量并快速计算余弦相似度；Cross-encoder 或重排模型则把两个文本放在一次前向计算中联合阅读，速度较慢，但更擅长识别否定、金额、实体和细粒度语义差异。生产检索系统常见的结构正是「Bi-encoder 粗排，Cross-encoder 精排」。(huggingface.co)
| 方案 | 比对方式 | 主要优势 | 主要问题 | 适合场景 | |---|---|---|---|---| | Word 修订与字符 Diff | 字符、单词和段落位置 | 精确显示编辑痕迹 | 无法判断法律效果，跨段改写容易失效 | 同一合同的版本校对 | | 直接上传生成式大模型 | 长上下文整体阅读 | 能解释、总结和改写 | 召回率不稳定，难证明做过完整两两比较 | 快速理解单份合同 | | 纯条款两两调用大模型 | 每个条款组合单独推理 | 单次判断能力较强 | 组合数量呈平方增长 | 小型文档、高价值复核 | | Encoder + NLI 流水线 | 向量召回、分类与重排 | 批量处理快、输出结构稳定、容易调阈值 | 依赖切分质量，复杂跨条款推理较弱 | 模板审查、Playbook 检查 | | 混合方案 | 判别模型发现问题，大模型解释 | 兼顾召回、成本与可读性 | 工程链路更复杂 | 企业级合同审查系统 |
七步完成一次合同审查
**第一步是把文档转换为稳定的 Markdown 结构。**项目会修复乱码、弯引号、不间断空格、控制字符和多余空白，并尽量保留标题层级，因为合同中的章节结构本身就是重要语义。
**第二步是把整份文档切成可比较的条款节点。**Kanon 2 Enricher 会识别标题、容器、普通条款、定义条款和列表项，并维护父子层级；系统还会切掉嵌套子条款已经占用的文本，避免同一句话在父节点和子节点中被重复计算。
**第三步是为每个条款生成向量表示。**Kanon 2 Embedder 将条款编码成向量，后续的多数粗筛只需要矩阵运算，不需要让模型重新阅读原文。
**第四步是过滤脚注、引文、签字栏和纯标题。**项目先利用文档解析器的类别标签排除前言、后记和注释，再使用 Kanon Universal Classifier 判断剩余文本是否属于具有实际约束力的条款。
**第五步是构造条款相似度矩阵并建立候选列表。**默认配置要求余弦相关度至少达到 0.5，同时每项条款只保留任意一侧排名最高的 3 个候选；双向选择可以避免参考合同中的缺失条款因为没有被输入合同主动选中而彻底消失。(raw.githubusercontent.com)
**第六步是计算同一事项概率和实质差异概率。**系统先得到 $P(same)$，表示两个条款讨论同一事项的可能性，再通过四组信号计算 $P(differs)$：
- 条款是否只是样板措辞、标题、签字信息或定义；
- 当事方是否会在意两项条款适用哪一个版本；
- 律师是否会把两项条款视为需要比较的内容；
- 条款是否包含金额、比例或责任上限。
**第七步是把概率校准为冲突结论。**项目默认要求 $P(same) 不低于 0.3，并在 $P(conflict) 达到 0.728 时标记为偏差；没有找到同一事项条款的内容则进入 Gap 列表。每项条款最终只有三种状态：偏差、已覆盖或缺口。(raw.githubusercontent.com)
从 2.6 万个组合缩到 197 个
**官方示例展示了候选漏斗为什么比直接两两调用更实用。**参考文档 Common Paper Cloud Service Agreement 被切成 106 项条款，输入文档 Mistral AI Terms of Use 被切成 251 项条款，理论上需要检查 26,606 个组合。
过滤阶段从输入文档排除 25 项非实质内容，从参考文档排除 1 项，向量召回之后只剩 197 个候选组合进入分类器和重排器。也就是说，需要深度处理的组合数量降至理论全集的约 0.74%。
缓存对重复审查同样有效。官方 Notebook 给出的参考结果中，106 项条款的首次索引耗时约 3.21 秒，从缓存重新读取只需 0.02 秒，耗时减少约 99.4%；对于企业长期使用的模板库，这意味着参考合同通常只需解析一次。(raw.githubusercontent.com)
最终示例报告识别出 56 个偏差，整理为 54 行结果，同时产生多项双向缺口。责任限制案例的 $P(same) 为 0.68，$P(differs) 为 0.99，最终 $P(conflict) 为 0.81，超过默认的 0.728 阈值：参考合同限制双方责任，而 Mistral 条款只明确限制了自身责任。(raw.githubusercontent.com)
实战部署：先跑通，再调阈值
**项目适合具备 Python 基础的开发者直接从 Notebook 开始验证。**运行环境要求 Python 3.11 以上和 uv，代码仓库可以直接克隆：
git clone --depth 1 https://github.com/isaacus-dev/cookbooks.git
cd cookbooks/cookbooks/conflict-detector
**首次测试最好先使用仓库自带的 Markdown 样本。**项目虽然能把纯文本转成 Markdown，但扫描 PDF、复杂表格、跨页条款和 OCR 错误不会自动消失；如果文档解析阶段把表格责任上限拆错，后面的模型再强也只能精确地分析错误输入。
**阈值调整应优先围绕召回率，而不是追求一张干净的结果表。**法务审查系统漏掉高风险条款的代价通常高于多看几个误报，因此第一轮可以适当降低冲突阈值，再通过标注数据寻找平衡点。
SHORTLIST_MIN_RELEVANCE = 0.50
SHORTLIST_TOP_K = 3
SAME_THRESHOLD = 0.30
CONFLICT_THRESHOLD = 0.728
**企业落地前至少应建立 100 至 300 组人工标注条款对。**标注集要覆盖金额变化、义务主体变化、否定词变化、期限变化、定义替换、例外条款、交叉引用和完全缺失等情况，然后分别统计偏差检测召回率、缺口召回率、误报率以及不同合同类型的表现。
**缓存和审计记录比漂亮的自然语言解释更重要。**项目会保存 report.json、pairs.json 和参数文件，因此开发者可以在不重新执行完整模型流程的情况下重新调整权重与阈值，也可以追溯某项结论来自哪两个原始文本区间。
这套方案的真正价值
**这套工具最适合承担合同审查的第一道机器筛查，而不是代替律师作最终判断。**采购协议、SaaS 条款、劳动合同、隐私政策和内部制度都包含大量可重复的条款主题，判别模型可以先把几百项内容压缩成几十项需要人工查看的问题。
**它比纯大模型方案更像搜索系统，而不是聊天机器人。**搜索系统要求每个结果有来源、有分数、有阈值和可重复的处理步骤；聊天机器人则更擅长在拿到少量材料之后解释结果。把两者拆开，才是目前更可靠的合同 AI 架构。
**它也不是一套完全本地的开源法律模型栈。**仓库代码采用 MIT 许可证，但核心的 Kanon 2 Enricher、Embedder、Reranker 和 Universal Classifier仍通过 Isaacus 服务运行，需要相应访问凭证并消耗模型额度；开发者可以审计流程和修改业务逻辑，却不能仅凭仓库在离线环境复现全部模型能力。(github.com)
**复杂法律推理仍然是 Encoder 流水线的短板。**如果一项风险必须结合定义条款、附件、司法辖区、多个例外和四处分散的交叉引用才能成立，单个条款对的 NLI 判断可能无法捕获完整逻辑；金额单位、时间条件和否定范围也需要单独的规则或结构化解析器兜底。
OpenAI Hub 观点
**这次开源真正证明的是，合同审查不必默认从大语言模型开始。**当任务可以被拆成切分、召回、分类、排序和校准时，Encoder 模型往往更快、更稳定，也更方便企业审计。
**最合理的产品形态仍然是判别模型找问题、生成模型讲问题。**前者负责尽可能完整地扫出偏差和缺口，后者只读取已定位的原文，生成摘要、谈判建议或改写版本；即使生成内容出现错误，也不会反过来凭空制造一项不存在的合同冲突。
**这套工具目前更像一份高质量工程蓝图，而不是可以直接交给法务部门的成熟产品。**它已经把候选召回、概率校准、双向 Gap 检测和结果追溯做得相当清楚，但 OCR、权限管理、数据隔离、批注工作流、人工反馈和不同法域的评测仍要由实施团队补齐。
对于正在开发合同审查、政策一致性检查或法律 RAG 系统的团队，这个项目值得看的不是界面，而是那条清晰的漏斗：先用便宜模型缩小问题，再把有限算力花在真正可能冲突的条款上。
参考来源
- Reddit：I built a Legora-style legal conflict detector：项目作者最初发布的背景介绍与性能说明，原帖现已被版主移除。
- GitHub：Isaacus Cookbooks：项目主仓库，包含许可证、示例与其他法律 AI 实战项目。
- GitHub：Conflict Detector Notebook：完整实现流程、阈值配置、样本输出与运行说明。
- Hugging Face：SNLI 数据集：自然语言推理任务及蕴含、矛盾、中立三类标签的经典数据集。
- Hugging Face：Sentence Transformers：Bi-encoder、Cross-encoder、向量检索和重排模型的相关资源。
