|
上周知识星球内有个关于合同生成的提问，就是想把历史文档作为知识库在工作流中召回仿写。实际我在 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 软件开发合作场景 这个场景模拟两家技术公司进行合作开发，信息双向流动，权利义务相对平等。 | |
|---|
| | | | | 合作开发“幻影”AI 图像生成引擎的 API 接口 | | | | | | |
知识产权条款的专业性 这是此场景的核心。生成的“第三条 知识产权”应该非常专业，明确约定最终开发成果的知识产权归属于甲方（奇点未来），但可能会包含关于乙方“背景技术”权利保留的条款。 关键条款的出现 与用例一相反，技术合作 NDA 中通常会包含“残存信息（Residuals）”条款，以平衡双方开发者在合作中无意获取的通用技能。检查最终生成的合同中是否恰当地包含了这一条款。 争议解决方式的差异 检查最终生成的“第六条”是否正确地将争议解决方法设定为“仲裁”（与用例一的“诉讼”形成对比），这在商业合作中非常常见。 | 
