2000 份合同里同时存在三类完全不同的问题：查原文、算数字、追关系。把它们交给同一种检索方式，系统迟早会在最关键的地方出错。一套可靠的设计，是先分工，再把证据合并成回答。

有客户问过一个很现实的问题：

我们积累了 2000 多份采购和工程合同，主合同、补充协议、扫描件、技术附件都在。能不能做一个 AI，让业务、法务和财务都能查？

答案当然是能。

但如果做法只是“全部上传、切片、向量化”，最终得到的很可能是一个会聊天、却不敢在关键问题上相信它的合同库。

因为合同管理里同时存在三类完全不同的问题：查原文、算数字、追关系。把它们交给同一种检索方式，系统迟早会在最关键的地方出错。

01 · 先看清：2000 份合同真正难在哪里

合同数量本身不是最大问题。难的是它们不是 2000 个彼此独立的文件。

一份主合同，可能有多份补充协议；一份工程合同，会关联项目、物料、验收、发票、付款申请和质保责任；同一供应商还可能有集团主体、子公司、担保关系和不同签约身份。

实际业务会问：

• 某项目当前有效的质保条款是什么？
• 某型号物料相关合同累计金额是多少？
• 某供应商发生违约，哪些项目和客户可能被波及？
• 某笔付款是否满足合同约定的验收条件？

这四类问题表面上都在“查合同”，底层却完全不同。

02 · 第一层：把确定事实从合同里抽出来，交给数据库

合同进系统后的第一步，不应是立即切片，而应先提取关键主数据。

至少包括：

这些字段进入关系型数据库后，金额、日期、状态、数量、排名等问题都走 SQL。

例如“去年涉及某型号电机的合同总额是多少”，系统应该直接查字段、汇总结果，并列出明细；而不是让大模型在几十份合同里找数字再做加法。

凡是需要精确计算的内容，都不能把可靠性押在语言模型的临场发挥上。

03 · 第二层：把合同之间的关系连起来，交给关系模型

合同最容易出风险的地方，往往不是某一条写得难懂，而是它和别的文件之间的关系没有被追到。

可以先建立最小的合同关系骨架：

关键不在于画多少节点，而在于几个高价值关系是否可信：

• 哪份补充协议修改了哪份主合同；
• 修改的是全文还是具体条款；
• 哪个主体是签约方、担保方还是关联方；
• 哪个项目、物料或订单与合同对应；
• 当前有效版本是什么。

有了这些关系，系统处理“某供应商相关合同风险”时，才能不止看供应商名称本身，还能沿着主体、项目和合同版本继续追溯。

04 · 第三层：原文条款仍然交给 RAG

结构化字段和关系图谱不能替代合同原文。

业务人员仍然需要问：

• 该违约条款具体怎么写？
• 对延期交付的免责条件是什么？
• 某项质保责任的适用边界有哪些？

这时，RAG 的价值才真正发挥出来：在已经确认合同、版本和条款类型的范围内，找出相关原文，提供页码、章节和上下文，再由大模型转述解释。

换句话说：

不是三个系统各自为政，而是根据问题分工，再把证据汇到同一个回答里。

05 · 一个可靠的回答，应该长什么样？

比如业务问：

不可靠的系统可能只找到主合同，告诉你“扣 10%”。

可靠的系统应该完成：

1. 通过项目编码锁定合同；
2. 检查主合同是否有补充协议；
3. 沿覆盖关系找到最新有效条款；
4. 从条款原文中摘取依据；
5. 给出清晰结论和来源。

最终回答应类似：

注意最后一句。系统可以把证据链和风险点整理出来，但涉及付款、合同效力和客户承诺，仍需要有授权的人确认。

06 · 这类项目最大的风险，不在模型，在数据底座

混合知识库不是把 SQL、图数据库、向量库都买一遍就能成功。

最常见的失败原因是：合同编号不统一、主体名称多种写法、扫描件 OCR 错误、补充协议没有关联母合同、历史文件没有标注有效状态。

因此，项目先做的不是“大模型选型”，而是这四件事：

• 制定合同、项目、主体、物料的唯一标识；
• 建立主合同、补充协议、变更单的版本规则；
• 选出业务最常问的 30 个高价值问题；
• 定义每个问题的可信数据源、人工确认点和责任人。

07 · 最现实的落地顺序：不要一口吃成胖子

对大多数企业而言，推荐分三步：

第一步：先做高质量合同 RAG。  清洗文件、保留版本和页码、做好元数据过滤，让业务能可靠查原文。

第二步：补合同主数据与 SQL 查询。  先解决金额、时间、状态、统计这类确定性问题。

第三步：围绕高风险关系局部建图。  优先做补充协议覆盖、主体关联、项目—合同—付款节点等关系，而不是全量建图。

这才是企业真正需要的混合知识系统。