用 Dify + 知识库构建合同审查助手：如何处理 PDF 文档、设定检索参数

在企业场景中，合同审查并不意味着让 AI 替代法务，而更适合作为合同预审、条款识别与风险提示的第一层能力。

这类场景非常适合通过 Dify 的 Knowledge 与 Workflow 进行落地。因为合同审查的基础工作，通常可以被拆解为以下几个步骤：

1. 读取合同文本
2. 从模板、制度与规则中检索依据
3. 输出结构化的风险提示与修改建议

其中最关键的两个问题通常不是“模型够不够强”，而是：

• PDF 文档应该如何处理
• 检索参数应该如何设置，才能让结果更稳定

本文将围绕这两个问题展开，说明如何用 Dify + 知识库构建一个具备实用价值的合同审查助手。

一、先明确：合同审查助手适合承担什么角色

在企业实践中，合同审查助手更适合作为“预审工具”，而不是最终决策主体。

它更适合承担的任务包括：

• 提取合同基本信息，例如主体、金额、期限、付款条件
• 定位重点条款，例如违约责任、保密、知识产权、自动续约
• 对照企业标准模板或法务规则进行初步比对
• 输出风险提示清单
• 生成给业务或法务使用的修改建议草稿

而以下内容，通常仍应保留给人工判断：

• 重大交易结构判断
• 跨境合规问题
• 行业监管细则解释
• 超出企业既有规则体系的复杂争议

因此，一个成熟的合同审查助手，其目标并不是“替代法务”，而是优先完成标准化、重复性强、可规则化的第一轮审查工作。

二、第一步：准备两类资料

合同审查助手通常至少需要两类输入资料。

1. 待审查合同

即业务部门上传的 PDF、Word 或其他合同文本。

2. 审查依据资料

例如：

• 企业标准合同模板
• 法务审查清单
• 风险条款规则表
• 合同审批制度
• 常见问题说明
• 历史修订规范

在实际项目中，很多团队会优先上传合同本身，却忽略了“审查依据”的组织，结果系统只能给出泛化总结，而无法生成真正有价值的审查结论。

三、第二步：处理 PDF 文档

在合同场景中，PDF 是最常见、也最容易影响检索质量的文件格式之一。

常见问题

1. 扫描版 PDF 无法直接提取文本
   需要 OCR 才能进入后续流程。

2. 排版复杂
   页眉页脚、表格、签章与页码容易干扰切分效果。

3. 多份模板混在同一文件中
   会直接影响后续检索结果的稳定性。

4. 重复条款过多
   会在排序阶段挤占有效内容。

推荐处理方式

在上传前，建议对 PDF 做一次基础预处理：

• 优先使用可提取文本的 PDF
• 对扫描件先进行 OCR
• 删除无实际意义的封面、空白页与纯签章页
• 尽量保持一份合同一个文件
• 如排版复杂，可先转换为更干净的文本或 Markdown 结构

如果企业合同来源较多，建议在正式建设前，单独建立一个“合同清洗流程”，先把原始文件标准化，再导入 Dify 知识体系。

四、第三步：把知识层拆清楚

在合同审查场景中，我们不建议将所有资料直接堆入一个统一知识库，而更建议按角色拆分。

知识库 A：企业合同模板

• 标准采购合同
• 标准销售合同
• 服务合同模板
• NDA 模板

知识库 B：审查规则与红线

• 风险条款清单
• 法务审核规范
• 审批权限规则
• 例外情形说明

知识库 C：补充制度与合规资料

• 印章管理制度
• 付款审批制度
• 数据合规要求
• 行业特殊约束

这样做的价值在于：系统后续可以根据合同类型，选择更合适的知识范围，而不是在所有资料中进行无差别检索。

五、第四步：设计合同审查 Workflow

一个可落地的合同审查基础流程，通常可以设计为：

上传合同
→ 提取合同文本
→ 判断合同类型
→ 检索对应模板与审查规则
→ 抽取关键条款
→ 生成风险清单与建议
→ 输出结构化审查结果

在 Dify 中，通常可以拆分为以下节点：

1. Input：输入合同文本或上传处理后文本
2. LLM 节点：识别合同类型
3. Knowledge Retrieval：检索模板与规则
4. LLM 节点：抽取关键条款
5. LLM 节点：基于规则输出风险分析
6. Answer / JSON 输出：输出结构化审查结果

推荐的输出字段

与其输出一段自然语言总结，我们更建议采用结构化结果，例如：

• 合同类型
• 合同期限
• 付款条款摘要
• 自动续约条款
• 违约责任条款
• 潜在风险点
• 建议修改项
• 是否建议人工复审

这种结构更有利于后续接入审批系统、法务台账或内部报告流程。

六、第五步：正确理解检索参数

在合同审查助手中，检索质量决定输出质量。

如果系统没有检索到正确条款、模板或规则，那么后面的生成步骤越完整，偏差反而可能越大。

因此，在构建阶段，建议重点关注以下几个参数思路。

1. Top K 不宜过小，也不能盲目过大

Top K 表示系统一次检索返回多少条相关片段。

• 过小：容易遗漏关键依据
• 过大：容易引入过多噪音，影响模型聚焦

在合同场景中，条款定位类问题可以适当偏小，而综合审查类问题通常需要更多上下文支撑。因此，Top K 不应固定为单一值，而应根据问题类型进行调试。

2. 不要把“无效化”当作长期策略

在一些 RAG 实践中，团队会把重复或不想继续使用的片段设为无效，以为这样就不会影响结果。

但在很多情况下，重复片段仍可能对排序过程产生影响，导致真正有效的内容被挤出前列。相比依赖无效化，更稳妥的做法是：

• 上传前就清理重复条款
• 删除过时版本
• 不把清洗任务留到检索之后

3. Chunk 应符合合同结构，而不是仅按字数切分

合同并不是普通文章。如果切分过碎，条款上下文会断裂；如果切分过长，检索聚焦度又会下降。

更合理的思路通常是：

• 按条款或小节切分
• 保留条款标题
• 尽量让一个 chunk 表达一个完整规则

例如“付款方式”与“违约责任”不应落入同一大块，也不应将一个完整条款人为切成多个断裂片段。

4. 对模糊问题先做改写

在合同审查中，常见问题往往较为模糊，例如：

• “这个条款有没有风险？”
• “这里需要改吗？”
• “这份合同是否合规？”

这类问题直接进入检索，效果通常不理想。更推荐的方式，是先通过一个前置 LLM 节点，把问题改写为更明确的检索请求，例如：

• “请检查付款条款是否与公司模板一致”
• “请定位合同中关于自动续约与违约责任的内容”

这种方式可以显著提升相关性。

七、第六步：提示词必须强调“依据”与“边界”

合同审查场景最大的风险之一，是模型在资料不足时仍然输出听起来合理、但缺乏依据的判断。

因此，在回答提示词中，建议明确约束以下原则：

你是合同审查助手。
请严格基于提供的合同内容和审查规则进行分析。
要求：
- 不要编造不存在的条款
- 不要把推测当作结论
- 对每个风险点说明依据
- 如果资料不足，请明确指出需要人工复核
- 输出尽量结构化

如果企业希望进一步增强可读性，也可以增加风险分级，例如：

• 高风险
• 中风险
• 低风险
• 信息不足

八、第七步：建立小规模测试集

在正式上线前，我们建议先从一个单一合同品类开始测试，例如：

• NDA
• 标准采购合同
• 劳务服务合同

然后准备 10 到 20 份测试样本，覆盖以下情况：

1. 标准模板版本
2. 经人工修改的版本
3. 明显存在风险条款的版本
4. 信息不完整或 OCR 质量较差的版本

评估时重点关注：

• 合同类型识别是否正确
• 关键条款能否稳定抽取
• 风险提示是否有依据
• 结果是否适合业务或法务直接阅读

九、推荐的落地方式

在企业内部推动这类项目时，我们通常不建议第一阶段就将其命名为“AI 合同审查系统”。

更容易被业务与法务接受的表述通常是：

• 合同预审助手
• 合同信息提取助手
• 条款风险提示助手
• 合同模板比对助手

这种表达方式更符合当前 AI 的实际能力边界，也有助于在组织内部建立合理预期。

结语

借助 Dify + 知识库构建合同审查助手，真正决定效果的并不只是模型，而是三个基础环节是否做扎实：

• PDF 文档是否被清洗为高质量文本
• 审查依据是否被组织成清晰知识层
• 检索参数与切分策略是否围绕合同结构完成调优

当这三件事被处理好后，Dify 就能够很好地承接一个实用的合同预审流程：先提取信息，再定位条款，再基于规则输出风险提示，最后将复杂判断交还给人工复核。

这也是当前企业最容易真正用起来的一种方式：不是让 AI 直接替代法务，而是先让 AI 成为法务前的一层高效筛查能力。