4月底时，知识星球里有个关于在 RAG 流程中，如何实现基于 Bad Cases（负面案例）的合同审查和合同生成（基于合同模板）的提问，算是一个很有代表性的进阶 RAG 应用方向，这篇针对其中的合同审查场景来做些介绍和演示。
注：“整体文档理解”（Bad Cases 分析）和“结构化对象检索”（模板匹配）
合同审查场景里，利用历史上的“坏案例”（Bad Cases，包含合同原文和审查结果）来辅助新合同的审查，而不仅仅依赖预设规则是个很实际的业务需求。但标准 RAG 主要召回与问题语义相似的片段，确实很难让 LLM 理解一个 Bad Cases 的整体情况和参考价值。直接将整个 Bad Cases 作为知识源，又面临上下文窗口限制和召回不精确（可能只匹配了表面相似性，而非关键问题点）的挑战。
结合我过去几个月一些相关项目中的实践经验，这篇基于 dify 工作流和设计的样例数据，向各位展示一个可快速上手的解决方案示例。
以下，enjoy:
1
现代合同审查工具及其局限性
正式开始介绍前，我们先来回顾下，在没有 LLM 和 RAG 技术普及之前，市场上常见合同审查工具以及其背后的规则引擎做法。
1.1
核心做法
知识库构建与规则编码：
传统规则引擎主要来自法律专业知识、行业惯例和公司自身的风险策略等方面，并且需要人工持续维护和更新。具体来说，通常来说包括：完整性检查、风险模式识别、一致性与准确性、合规性检查、量化指标监控等维度。
其次，需要将这些知识转化为一系列明确的、可执行的规则。例如：“合同必须包含‘争议解决’条款。” 、“‘责任限制’条款的上限不得低于合同总金额的 X%。”、“若合同类型为‘保密协议’，则保密期限不得少于 N 年。” 等。最后将这些规则用特定的语法（如正则表达式、关键词匹配、逻辑判断式）编码到规则引擎中。
自动化扫描与标记：
有了上述规则库之后，在实际使用时需要通过工具读取合同文本（通常使用 OCR 处理扫描件），规则引擎逐条或并行匹配合同内容与规则库中的规则，标记出违反规则、缺失条款、与标准范本不一致或存在预警关键词的地方。输出一般则是高亮显示问题条款、生成风险提示列表、给出初步的风险等级评分等。
1.2
局限性
语义理解的缺失：
规则引擎的主要实现逻辑是基于关键词、句式结构等表面特征进行匹配，很难理解语言的细微差别、上下文含义或真实意图。另外，对于规则库中没有预设到的措辞或条款变体，即使意思相同，也可能漏报或误报。 例如一个条款单独看可能没问题，但与其他条款结合起来就可能产生风险。
僵化与维护成本高：
其次，这种人工驱动的规则库需要持续、大量的更新和维护，成本高且容易滞后。尤其是为了覆盖更多场景，规则数量会急剧增加，导致规则间的冲突、管理复杂度会逐渐失控。
用户体验与解释性：
传统方法输出一般是一堆“规则违反”列表，缺乏对风险的深入解释和业务影响的分析，以及具体的、有针对性的修改建议，这点对于用户而言也是显然不够友好。
2
通用规则 vs Bad Cases
梳理了传统规则引擎的实现逻辑和局限性，这里接着介绍下这篇要展示的工作流编排逻辑。
2.1
优势互补
首先需要说明的是，这两者在合同审查中都非常重要，但扮演着不同且互补的角色。 通用规则 (上文说的传统规则引擎)作用是基础框架与合规性检查，它更像一个“体检表”，用于快速判断合同在结构上是否完整，核心条款是否缺失，以及是否存在一些基础的、普遍适用的法律或商业实践要求未被满足。通用规则也是审查的基石和起点，保证了合同的“骨架”基本正确。
而上文一直提到的负面案例 (Bad Cases)主要作用则是审查的深度和经验的体现。或者换句话说，是具体风险场景的警示。在真实业务合同中的某些条款的缺失、模糊或不当设计是如何导致实际问题的（如争议、损失、败诉等）。Bad Cases 往往与特定的合同类型、行业背景或业务逻辑紧密相关，使得风险分析更具针对性。
总结来说， 通用规则更像是“静态的知识库”，告诉你“应该是什么样的”。 而 Bad Cases 是“动态的经验库”，告诉你“曾经发生过什么问题，为什么会发生，后果如何”。 在审查中，通常会先用通用规则进行一遍“扫描”，确保基础项没有问题。然后，针对合同的特定类型、交易背景以及在初步扫描中发现的潜在疑点，去 Bad Cases 库中寻找相似情境，以进行更深入、更具针对性的风险评估和条款优化。
两者哪个更重要？ 它们都重要，缺一不可，是相辅相成的。如果只看通用规则，审查可能流于表面，无法预见复杂风险；如果只看 Bad Cases，可能会缺乏系统性，遗漏一些基础但关键的问题。
2.2
Bad Cases 召回策略
进一步来说，在 Dify（或类似）工作流汇总召回 Bad Cases 时，为了确保相关性和有效性，可以考虑以下优先级顺序：
问题条款相似性:
如果新合同中的某个条款的措辞、结构或潜在逻辑缺陷，与某个 Bad Case 中明确指出并导致问题的条款高度相似，那么这个 Bad Case 的参考价值是最大的。无论合同类型或行业是否完全一致，相似的问题条款往往意味着相似的风险逻辑。 例如: 新合同的验收条款约定“甲方收到乙方交付物后，如无书面异议，则视为验收合格”，这与某个 Bad Case 中因此类“默认合格”条款引发争议高度相关。
合同类型:
这点不言自明，相同类型的合同往往具有相似的交易结构、核心目标和常见的风险领域。例如，软件开发合同通常会关注知识产权、交付验收、维护责任等，而租赁合同则更关注租赁物状况、租金支付、违约责任等。因此，来自同一合同类型的 Bad Case 更可能触及与当前审查合同直接相关的议题。 例如: 审查一份新的“软件外包开发合同”时，来自历史“软件开发服务合同”的 Bad Case 通常比来自“房屋租赁合同”的 Bad Case 更具参考性。
业务场景相似性:
行业特性和具体的业务场景会显著影响合同条款的风险权重和解释。某些在某个行业是标准做法的条款，在另一个行业可能就是重大风险。业务场景决定了合同履行的具体环境和可能的矛盾点。 例如: 一份涉及处理大量个人敏感数据的市场推广合同，在召回 Bad Case 时，与数据合规、隐私保护相关的案例（即使合同类型略有差异，但如果行业同为互联网广告或涉及用户数据处理）可能比一个不涉及敏感数据的普通服务合同的 Bad Case 更重要。
总结来说,首先看“问题像不像”：条款本身是否存在已知的风险模式？ 其次看“合同大类像不像”：是不是同一类型的法律关系和交易框架？ 再看“具体环境像不像”：行业惯例、业务流程是否会让这个风险更加突出或具有不同的表现形式？ 在理想情况下，工作流能够综合评估这些因素，并根据匹配度给出一个加权排序的 Bad Case 列表。例如，一个与当前新合同条款高度相似、合同类型一致且行业背景也相近的 Bad Case，这样参考价值无疑是最高的。
3
样例数据解析
下文工作流演示中所采用的样例数据包括：3 份典型的待审查合同、5 份负面案例（Bad Cases），以及 1 套基础的审查规则。除了因为保密协议无法直接使用接触的商业项目资料外，通过模拟数据其实可以更有针对性地设计合同条款和潜在风险点，从而清晰地展示工作流在识别、分析和处理这些特定问题时的核心逻辑和能力。这比使用结构复杂、包含大量无关信息的真实合同更能突出重点。
3.1
合同类型的多样性：
NC001: 软件外包开发合同：这是常见的技术服务类合同，涉及项目范围、交付、验收、知识产权等多个关键点，能充分测试工作流对复杂业务逻辑的理解。
NC002: 单向保密协议 (接收方视角)：这类合同专注于信息保密，条款相对聚焦，但对定义的准确性、义务的合理性要求很高。从“接收方视角”出发，可以测试工作流是否能识别出对单方不利的潜在风险。
NC003: 市场推广服务合同：这类合同通常包含效果承诺（KPI）、成果归属等，能测试工作流对服务效果衡量、知识产权转移等方面的审查能力。
三份合同里经过设计都预埋了些对应场景中一些典型风险点，这些新合同中的条款，很多都能直接或间接地与 Basic_rules.md 中的通用规则以及 Bade cases 文件夹中案例的风险点对应起来，便于工作流进行参照和匹配。
3.2
负面案例 (Bad Case 1-5) 的设计
覆盖常见的合同类型和风险领域
BC001: 软件开发服务合同 - 验收、违约责任、争议解决。
BC002: 保密协议 (NDA) - 保密范围、期限、违约责任。
BC003: 房屋租赁合同 - 交付标准、押金、提前终止、续租。
BC004: 产品采购合同 - 质量标准、验收期、责任限制。
BC005: 咨询服务合同 - 付款条件、成果交付、知识产权、终止条款。
这种多样性确保了工作流的知识库具有一定的广度。
结构化的风险总结
每个 Bad Case 都清晰地列出了 identified_risks, problematic_clauses_summary, 和 suggestion_or_lesson。这种结构化信息非常适合 LLM 进行学习和提取，能够让工作流更准确地理解历史风险的上下文和解决方案。
此外，这些案例中暴露的问题，如定义模糊、权利义务不对等、缺少关键保护、责任限制不合理等，都是合同审查中非常经典和常见的风险类型，具有很好的代表性。
通过这种设计，当新的待审查合同进入工作流时，通用规则（Basic_rules.md）提供了普适性的检查清单。新合同中的潜在风险点，可以通过与 Bad Cases 中的 keywords_for_retrieval 和 identified_risks 进行匹配，快速找到相似的历史案例。Bad Cases 中的 suggestion_or_lesson 可以为新合同的审查报告提供具体的修改方向和风险警示。
4
工作流编排逻辑
这个工作流实现了一个多阶段的合同审查流程，具体来说分为以下四个部分：
4.1
输入收集与预处理
收集用户提供的合同文件、特定关注点、合同类型和通用审查规则，提取并转换合同文本。
工作流触发的输入页面
注：“合同文本提取”节点输出的是包含单个字符串的列表'合同内容'，而后续 LLM 或 Template 节点可能期望的是纯字符串合同内容。最初我忽略了这种细微的类型差异，导致 Prompt 渲染异常或 LLM 理解偏差，后来增加 Template 节点进行显式数据类型转换。
4.2
初步风险识别
使用 LLM 对合同文本进行初步分析，快速识别潜在风险点。
4.3
相似案例检索与分析
根据初步风险和合同类型，从知识库中检索相关的历史风险案例 (bad cases)，并由另一个 LLM 提取这些案例的关键风险点。
4.4
综合审查与报告生成
将新合同文本、初步风险分析、相关历史案例风险、通用审查规则以及用户特定关注点整合起来，形成一个详细的提示，交由一个强大的 LLM 进行深度审查，并生成结构化的合同审查报告。
注：即便所有输入信息都正确传递给了最终的审查 LLM，它也可能因为 Prompt 不够优化而无法产出高质量的、有针对性的报告。解决方案是优先使用大参数的高阶 LLM，其次是尽可能设计结构化、任务明确、信息聚焦的最终 Prompt。
5
运行结果展示
6
三点优化方向参考
感兴趣的推荐从输入信息质量深化（Bad Case 处理）、输出结果行动性增强（修改建议）和系统整体智能与用户体验提升（迭代与反馈）三点着手。
6.1
通过 Loop 节点对召回的 Bad Cases 进行逐一分析
当前的 Bad Case 风险点总结是将所有召回的 Bad Cases 结果作为一个整体交由单个 LLM 调用进行处理，要求其“对于输入文本中明确存在的每一个案例”进行总结。 可以考虑换成引入一个 Loop（循环）节点。 循环的输入是召回的 Bad Case 列表，每次迭代处理一个 Bad Case，进行更细致的关联性分析。
6.2
引入“条款级风险定位与具体修改建议生成”能力
当前工作流的输出是一份“合同审查报告”，其中包含修改建议，但工作流本身不能直接生成可用的、具体的条款修改文本。 可以考虑调整“新合同的审核”节点的 LLM 提示词，明确要求其不仅识别风险，还要定位到新合同中的具体问题条款编号和原文，进而针对识别出的每一个主要风险点，尝试生成 1-2 个具体的、可操作的条款修改建议文本。
6.3
建立迭代式审查与用户反馈机制
当前工作流是一个单向的处理流程，用户输入合同，得到一份审查报告。在输出审查报告后，如果能允许用户选择报告中的某个风险点，然后触发一个新的、更聚焦的 LLM 调用，针对该点进行更深入的解释、提供更多替代修改方案、或分析特定修改方案的利弊，会更助于得到一个更加理想的结果。（这点类似 OpenAI、Gemini 的 Deep Research 的交互逻辑。）
7
RAG 进阶方向探讨
RAG 的进阶应用，不仅仅是简单的信息检索和问答，是利用 RAG 作为核心能力之一，结合更复杂的逻辑、多步骤处理、外部工具调用、模型间的协作，来完成更复杂的任务或驱动更智能的交互。
24 年对于 Agent 爆发的预期越来越高，在多个细分场景 RAG（特别是能够处理企业内部各种静态文档、数据库，并能连接外部工具和信息的进阶 RAG）将不再是“锦上添花”，而是会成为构建企业级大模型应用落地的基础要求和核心组件。它解决了 LLM 的幻觉问题、知识更新问题，并为 Agent 提供了行动和决策的“事实依据”。这篇介绍的合同审查工作流也是这个理念的实践，合同生成的案例预计 6 月初发出，欢迎蹲一蹲。
Anyway，充分实践才是硬道理。
