合同审查

合同审查方案：条款能查到原文，判断仍然由人做

法务的合同知识从来不是一份模板能说清的。同一类违约条款，在不同客户、不同年份的合同里写法不同；付款节点、验收标准、争议解决方式散落在正文、附件和往来邮件里。查一份历史合同靠文件夹和记忆，比对两版差异靠人工逐条读，审阅意见留在批注里，换个人接手就要重新读一遍，遇到同一类争议还要再问一次当年为什么这样写。

RatioMax 在这个环节做三件事：把合同、附件和审阅记录收进一个知识库，检索时定位到条款原文，把改版前后的差异对比出来，并从已批准的表述里整理出一份初稿。它不做法务判断：条款是否可接受、风险如何取舍、要不要签，仍然由法务和业务负责人决定并签字。系统负责把依据摆到桌面上，让每一次判断都有原文可以核对。

流程卡点

  1. 合同散落在邮箱与个人目录

    已签合同存在个人电脑、邮箱附件和网盘里，文件夹按客户命名，同一客户还有补充协议和附件。想找一份两年前的同类条款，只能凭印象翻，找到之后还要确认是不是最终签署的那一版。

  2. 同类条款各写各的

    违约、验收、付款条件在不同项目里各写各的，没有可对照的口径。审阅时想参考上一份类似的合同，得先找到它、读完它，再判断哪一条能沿用，时间大多花在重复阅读上。

  3. 审阅经验留在批注里

    哪一条被改过、为什么改、最后接受了什么妥协，多数留在批注和邮件往来里。人一离职，这些判断依据随之消失，下一份合同遇到同样的问题要从头讨论一遍。

  4. 老合同与扫描件读不出字

    早期合同和对方发来的扫描件没有文字层，全文检索一个词都命中不了。要查一份历史约定，只能一页一页翻图核对，查得慢不说，还容易漏掉附件里的补充条款。

对应做法

  • 合同与附件统一入库

    合同正文、补充协议、附件和审阅记录归到同一知识库，按客户、项目与签署年份标注元数据，每个知识库可绑定对象存储。复杂版式 PDF 由 OpenDataLoader 解析，扫描件与图片由 PaddleOCR-VL 识别，覆盖 10 余种格式，老合同无需人工录入。

    对应能力：双引擎解析

  • 条款问答带原文出处

    向量与关键词混合检索加 ReRank，问一句「这份合同的验收标准怎么约定」直接命中条款段落，答案标注可点击的引用，点开就是那份合同的那一页。资料里没有的内容会明确说明，不替合同补写条款。

    对应能力：引用溯源

  • 改版差异看得见、回得去

    文档改动留下分块级版本快照，行级 diff 标出增删改，可一键回滚到任一版本；改版前后的条款并列展示，由法务确认取舍。跨合同的同类条款只能并列列出候选，是否沿用由人判断。

    对应能力：版本快照

  • 初稿从已批准表述拼出

    自动 Wiki 把常用条款、审阅口径和模板说明整理成相互链接的页面，写初稿时先检索到已批准过的表述，再按结构组织成草稿交人改写。页面留快照、看 diff、可回滚，表述的变化有记录。

    对应能力：自动 Wiki

落地场景

  • 销售合同送审之前

    商务收到客户版本的销售合同，先把验收、付款与违约条款调出来对照厂内标准表述，把需要法务看的点标出来，再提交审阅。

  • 续签与改版确认

    续签时调出上一版合同与当时的审阅记录，比对差异，确认哪些条款已经谈定、哪些需要重新谈，不让同样的让步再走一遍。

  • 履约与付款节点查询

    项目执行中问一句这份合同的付款节点和验收条件怎么约定，答案指向原合同页面，商务、财务与项目组按同一份约定核对。

  • 供应商协议对齐

    新的供应商框架协议进来，先检索既有同类协议的处理方式，把不一致的条款列出来再谈，减少来回口头确认的次数。

术语与知识实体

合同要素
合同成立所需的基本内容，通常包括当事人、标的、数量、价款、履行期限与违约责任，缺项会让约定变得不明确。
主体资格
签约方是否依法成立、是否具备相应资质与签约权限，是合同生效之前必须核对的基本事实，不能只凭名片判断。
违约责任
约定一方不履行或不完全履行合同时承担的责任形式，常见为继续履行、赔偿损失与支付违约金，通常同时约定上限。
不可抗力
不能预见、不能避免且不能克服的客观情况，法律上可以作为免责事由，但通知期限与举证义务要在约定时间内完成。
争议解决与管辖
约定纠纷走诉讼还是仲裁，以及由哪个法院或仲裁机构受理，直接决定处理成本、周期与执行难度，不能两选并存。
条款比对
把两个版本的合同按段落对齐，逐条找出新增、删除与改写的位置，供人判断改动是否可以接受，本身不构成结论。
用印审批
合同盖章之前走完的内部审批流程，规定谁审、审什么、留什么记录，是合同生效前的最后一道控制环节。
履约节点
合同约定的交付、验收、付款与质保起算等时间点，是执行阶段对账、催办与计算逾期责任的依据。
审阅意见
审阅人对条款提出的修改与理由，必须和所依据的合同版本一起保存，否则事后无法判断当初是在哪一版上提出的。

这些定义同时以结构化方式提供给搜索引擎与 AI 引擎，便于它们准确理解并引用业务概念。

方案常见问题

这套系统能替法务审合同吗？
不能，也不该这样用。系统做的是检索、比对和初稿：把相关条款、历史审阅意见和改版差异摆到人面前，并给出原文出处。条款是否可接受、风险怎么取舍、能否签署，仍由法务和业务负责人判断并签字，系统不替代律师意见，也不替代合规审查。
扫描件和老合同能读进来吗？
可以。复杂版式 PDF 由 OpenDataLoader 解析，图片与扫描件由 PaddleOCR-VL 识别，覆盖 PDF、Word、Excel、图片等 10 余种格式，识别结果进入检索索引，而不是只做预览。个别字词识别不确定时仍建议对照原图核对，答复会标注来源页面，方便回看。
能自动生成合同初稿吗？
可以基于已入库的批准表述拼出初稿：系统先检索到同类条款和历史处理方式，再按模板结构组织成分段草稿，交法务改写确认。初稿不是成品，措辞、责任边界与商务条件仍需人工逐条过一遍，系统压缩的是找资料和抄模板的时间。
条款比对和人工审阅是什么关系？
比对负责把差异找出来，人负责判断差异是否可以接受。系统按分块保留版本快照，行级 diff 标出增删改，可回滚到任一版本；跨合同的同类条款只能并列成候选，是否沿用由法务决定。两边分工写清楚，比对结果才能当作审阅依据，而不是结论。
涉密合同能放在公有云上吗？
多数企业不会这样做。RatioMax 支持完整私有化部署，Docker Compose 单机或 Kubernetes 集群，四个核心服务可独立扩缩容，数据不出内网；每个知识库可绑定私有 OSS 或 S3 桶，数据源与 MCP 凭据用 AES-256-GCM 加密，对外请求带 SSRF 防护。
谁能看到哪些合同？
先按空间隔离，再用四级 RBAC 控制到单个知识库：法务、商务与财务各看自己范围内的合同，每次访问写入空间审计日志；账号通过 OIDC 单点登录统一，接口调用用两级 API key 区分权限。外部协作方只拿到受控范围，看不到未授权的合同。
引用能定位到具体条款吗？
能。答案来自混合检索加 ReRank 筛出的候选段落，每条结论带可点击引用，点开定位到那份合同的页面与段落；检索时可按客户、项目、签署年份等元数据过滤。平台用 Langfuse 与 W3C 跨服务追踪保留每次回答的检索结果，事后可以回放核对。
怎么和现有合同系统对接？
通过 API 与 MCP 接入：平台提供约 360 个 API 端点，MCP 服务对外提供 29 个标准工具，支持 stdio、SSE 与 HTTP 传输并用 OAuth2 授权，涉及敏感操作时需人工确认后才执行。合同原件仍在原系统里管理，知识库负责检索、比对与问答这一段。

其他方案