Dify+RAG合同生成：条款级工作流案例拆解

推荐语

Dify+RAG合同生成技术揭秘：如何实现条款级精准仿写，告别模板化风险。

核心内容：
1. NDA协议动态生成的核心价值与业务场景适配性
2. 历史合同预处理与条款级RAG召回机制详解
3. 并行生成架构设计及复杂跨文档计算技术预告

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

上周知识星球内有个关于合同生成的提问，就是想把历史文档作为知识库在工作流中召回仿写。实际我在 4 月底就在星球中回复过合同生成的相关实现思路参考，大致就是 LLM 负责理解与初步生成，使用 Code 节点接收 LLM 提取出的结构化信息，最后使用 LM 负责最终润色。

这部分内容我分两篇文章来介绍，这篇先聚焦于构建一个基于知识库的智能合同生成工作流。通过“离线知识预处理”与“在线并行生成”相结合的架构，实现针对不同业务场景的、高质量的 NDA（保密协议）动态生成。下一篇介绍如何在这篇的基础上，如何进一步实现从多个异构源文档中进行精准的结构化数据提取，并结合代码节点完成复杂的跨文档计算，最终生成一份高度格式化的报告。

这篇试图说清楚：

基于业务场景动态生成合同的价值所在、历史合同如何进行预处理得以符合知识库的要求、条款级并行处理的工程实现，以及下一篇涉及复杂跨文档计算的报价单生成内容预告。

以下，enjoy:

1

为什么选择 NDA

保密协议是企业在进行商业合作、技术交流、员工招聘等几乎所有重要活动前，必须签署的基础法律文件。从使用频率和普适性上来说，这玩意确实是横跨所有行业、所有规模的企业。这也使得根据业务场景自动化生成的 ROI（投资回报率）很高。

NDA 的结构非常经典且模块化，通常包括：定义条款 、保密义务、除外条款、保密期限、信息返还与销毁、违约责任、适用法律与争议解决。从落地可行性上来说，这也是天然的适合 LLM 解析+Code 精确填充的做法。

但需要说明的是，虽然结构标准，但条款的具体措辞根据业务场景不同还是有很大差别。一份定义不清、权责不明、期限不当的 NDA，导致核心信息潜在泄露的风险也会让公司陷入很大的被动。当然，这也是 RAG 在这个应用场景发挥用武之处的关键所在。

比如对“保密信息”的定义是宽泛还是具体？是否要包含口头披露的信息？在下述演示中 RAG 发挥的效果类似：当 LLM 生成此条款时，会从历史合同知识库中，召回多个不同版本的“保密信息定义”条款。例如，召回“投资尽调场景下的宽泛定义条款”、“技术外包场景下的具体定义条款”等，供 LLM 参考，从而生成最贴合当前"purpose": "评估潜在的技术合作"的条款内容。

2

为什么要动态生成合同

在正式开始介绍前，还有个很根本的问题需要再澄清下。就是有盆友可能会有疑问，如果自己的公司已经有非常完善的合同模板库了，平时只需要改改甲乙方、金额、日期，不也很快吗？为什么还需要一个这么麻烦的去构建一个复杂的工作流？

2.1

业务场景的特殊要求

一份“通用 NDA 模板”在面对“A 轮融资尽调”和“技术 API 对接”这两种截然不同的场景的时候，内部条款（如保密信息定义、知识产权归属）的最优写法是完全不同的。简单替换主体信息，会埋下巨大的法律风险。

后文要介绍的案例 ，是能够根据用户输入的“合作目的”，自动从知识库中调用最贴合当前场景的历史范例。换句话说，既能为融资场景生成一份定义宽泛、严格保护我方的条款；又能为技术合作场景生成一份权责对等、包含“残存信息”的条款。这种基于场景的深度定制能力，是静态模板无法比拟的。

2.2

知识库的更新问题

公司传统的模板库通常更新缓慢，依赖少数资深法务定期手工维护。但现实情况是，随着公司业务线不断丰富，会在原有的特定模板基础上，衍生出多个针对不同合作方定制签署的版本，这些衍生版本也是经过合作双方的前中后共同确认的条款内容，但又都有其特定适用场景。

基于下述条款级知识库的构建思路，每当公司完成一份高质量的新合同后，可以将其预处理后加入知识库中。这意味着 LLM 生成特定条款的能力”也在持续学习和进化，它能自动吸纳最新的、经过业务检验的条款写法，并应用到未来的合同生成中。

3

系统架构梳理

回答完上述两个问题后，这里开始正式介绍案例的实现过程。为了方便各位能快速理解，这部分先快读阅览下整体的架构思路。

3.1

第一阶段：离线知识库预处理

格式统一

首先，把原始的 Word 版合同（.docx）批量转换为易于处理的 Markdown（.md）格式。

注：这三份 NDA 合同包含了投资尽调调查、核心岗位员工、软件外包开发三个使用场景，是我在实际项目中进行必要脱敏后的参考版本。实际复现时各位也可直接用自己手头的合同，文档格式是 docx 即可。

智能拆分与富化

接着，对 Markdown 文本进行深度处理，将其自动拆分为独立的条款。同时，为每个条款标注好元数据，如“保密义务”、“知识产权”等，形成结构化的数据。

数据匿名化

最后，为确保数据安全与合规，对所有条款进行匿名化处理，将公司、人名等敏感信息替换为通用占位符。

3.2

第二阶段：dify 工作流生成

需求输入

用户在界面输入新合同的关键要素，如甲乙方信息、合作目的、有效期限等。

智能检索与草拟

系统根据需求从知识库中精确检索出最相关的条款范例，并交由 LLM 进行内容生成，确保条款既专业又贴合本次业务目标需求，这个过程会并行处理合同的各个部分。

自动组装与交付

所有条款生成完毕后，会自动将它们组装成一份格式完整的 Markdown 合同，并最终转换为标准的 Word（.docx）文档进行输出。

4

本地预处理说明

了解清楚了整体处理思路后，我们从最基础也是最重要的知识库预处理上开始介绍。这个演示项目中，整个处理流程分为三个主要步骤，由三个独立的脚本按顺序执行：

├── 三份NDA参考合同/          # 存放原始的 .docx 合同文件├── 三份NDA参考合同\_md/      # \[自动生成\] 存放转换后的 .md 文件├── dify_knowledge_base/        # \[自动生成\] 存放结构化处理后的知识库文件├── dify_knowledge_base_anonymized/ # \[自动生成\] 存放最终匿名化后的文件├── convert_contracts.py      # 脚本1：DOCX -> MD├── split_contracts.py        # 脚本2：MD -> Dify格式└── anonymize_contracts.py    # 脚本3：Dify格式 -> 匿名化

4.1

格式转换

将 Word 文档（.docx）转换为 Markdown（.md）格式，便于后续的文本处理。这部分没啥好说的，也可以转换为 md 也可以考虑 txt 或者 html 格式均可。

4.2

结构化处理

简单说，就是“按条款拆分”、“为每个条款添加元数据头部”、“用---分割符连接”这三步：

按“条款”进行物理拆分

脚本会读取整个 Markdown 合同文件的内容，然后使用正则表达式来查找所有条款的标题。 查找模式：它会寻找符合 ### 第 X 条 ... 或 ## 第四条 ... 这种格式的行（即 Markdown 的三级或二级标题，内容为条款编号）。

然后以每个条款标题作为起点，把整个文档切割成一个列表。列表中的每一项就是一个完整的条款文本块，从标题一直到下一个条款标题之前的所有内容。文档开头不带“第 X 条”的部分，则被视为“前言”。 这样，一份合同就被拆分成了类似下面这样的片段： 

片段 1: [合同的引言、各方信息...] 片段 2: [### 第一条 定义 的全部内容...] 片段 3: [### 第二条 保密义务 的全部内容...]

为每个片段添加元数据

拆分完成后，脚本会为每一个片段生成一个包含三项核心元数据的“头部信息”：

meta_doc_id: 文档 ID。这是一个唯一的标识符，用于追踪这个条款源自哪一份原始合同。例如，investment_nda_001 代表它来自第一份“投资尽调 NDA”合同。

meta_contract_type: 合同类型。直接从文件名获取，用于表明该条款所属的合同类型，如 投资尽职调查 NDA。

meta_clause_type: 条款类型。脚本会分析条款的标题（如 ### 第二条 保密义务），通过关键词（如“保密”、“知识产权”、“违约责任”）来判断并赋予一个标准化的类型。如果条款是合同开头的部分，则类型为 前言。

组合与格式化

脚本将上一步生成的“元数据头部”和“条款原文”组合在一起，形成一个完整的知识区块。一个区块的最终格式大致如下：

meta_doc_id: investment_nda_001meta_contract_type: 投资尽职调查NDAmeta_clause_type: 保密义务### 第二条 保密义务
1. 双方承认并同意，任何一方（“披露方”）向另一方（“接收方”）披露的任何与“星尘”AI模型相关的商业、技术或财务信息......（条款正文）...

使用分割符连接所有区块

脚本将所有处理好的知识区块放入一个最终的 .txt 文件中，并使用一个非常明确的分割符将它们隔开。--- （三个短横线，单独占一行） 这个分割符是特意为 Dify 这类知识库系统设计的。当 Dify 读取这个文件时，它会根据 --- 分割符自动将文件内容切分成多个独立的知识片段，并正确解析每个片段头部的元数据。

4.3

数据匿名化

扫描并替换处理后的文本中的敏感信息，如公司名称、人名、地址、身份证号等。跳过这一步，不会从技术上导致后续的模块填充失败（代码依然可以替换占位符），但它会严重影响 LLM 生成条款内容的质量和可靠性。

无匿名化的风险是，当 LLM 看到的参考内容是：“...若远见资本违反本协议，奇点未来有权...”。当让它为“星尘探索”生成新条款时，LLM 有相当大的概率会发生“事实串扰”，在生成的新条款中错误地写入“远见资本”或“奇点未来”的名字，而不是在当前任务中指定的新主体。

抛开合规性的问题，匿名化本质上是教 LLM 学习条款的“模式”（Pattern）而非“实例”（Instance）。它能更好地理解一个“保密义务”条款的通用结构，而不是仅仅记住“奇点未来”的那个特定版本。这使得它在面对全新的、多样化的需求时，表现得更加稳健和灵活。

5

并行处理实现

5.1

为什么要条款级处理

让 LLM 专注于生成一个 200 字的独立条款，远比生成 5000 字的长文要容易得多，也更容易通过 Prompt 进行精确控制。当我们为生成“违约责任”条款而专门召回 3-5 个历史合同中的“违约责任”范例时，提供给 LLM 的上下文 100%都是高相关信息。LLM 可以集中全部“注意力”来学习这些范例的专业措辞、逻辑结构和风险考量，从而生成质量极高的条款内容。

另外从模块化与可维护性的角度来说，分条款生成，也意味着整个合同被拆解成了独立的、可插拔的模块。如果测试中发现例如“知识产权”条款的生成效果不佳，则只需要去优化那一个特定的“知识产权生成”分支，而无需触动整个的工作流。这大大降低了维护成本。

5.2

知识库检索词的动态实现

Dify 的知识库检索节点本身不支持复杂的 Jinja2 模板语法，它需要一个固定的、纯文本的查询输入。因此，在“知识库检索”节点前插入一个“模板（Template）”节点，是实现动态查询（Dynamic Query）的标准且最佳的实践。

因为 Loop 节点适用于对一个列表中的每个同类项执行完全相同的操作，而案例演示的方案任务是“异构”的，每个条款生成的逻辑和参考重点都不同。所以采用并行分支，最后由一个 Code 节点统一合并是更合理的做法。

6

两个测试用例

这部分提供两个测试用例，并针对两个场景中的一些侧重点进行针对性的结果校验。

6.1

融资尽调场景

这个场景模拟创业公司向风险投资机构披露核心机密，要求最高级别的信息保护。

定义”条款的广度

生成的“第一条 定义”应该非常宽泛，将所有可能披露的信息（技术、商业、财务、运营）都囊括在内，以提供最全面的保护。

保密义务”条款的严格性

生成的“第二条 保密义务”应该非常严格，明确限制乙方（红杉资本）只能为投资评估这唯一目的使用信息，并且需要对其团队成员的违约行为承担连带责任。

关键条款的缺失

一份对甲方有利的融资 NDA，通常不应包含“残存信息（Residuals）”条款。检查最终生成的合同中是否没有这一对投资机构有利的条款。

6.2

软件开发合作场景

这个场景模拟两家技术公司进行合作开发，信息双向流动，权利义务相对平等。

知识产权条款的专业性

这是此场景的核心。生成的“第三条 知识产权”应该非常专业，明确约定最终开发成果的知识产权归属于甲方（奇点未来），但可能会包含关于乙方“背景技术”权利保留的条款。

关键条款的出现

与用例一相反，技术合作 NDA 中通常会包含“残存信息（Residuals）”条款，以平衡双方开发者在合作中无意获取的通用技能。检查最终生成的合同中是否恰当地包含了这一条款。

争议解决方式的差异

检查最终生成的“第六条”是否正确地将争议解决方法设定为“仲裁”（与用例一的“诉讼”形成对比），这在商业合作中非常常见。