技术杂谈

Appearance

合同智能审计系统说明 ​

1. 系统定位与目标 ​

  • 系统定位：面向甲方团队的「合同智能审计中台」，基于 Spring Boot + AI 模型 + 规则引擎，实现对合同条款的智能审查。
  • 核心功能：
    • 通过 AI 语义分析 + 数据库规则引擎 的双重机制，发现合同中对甲方不利的修改；
    • 支持甲方通过配置规则和模板，灵活调整风险判定标准，而不是完全依赖模型“黑盒”结果；
    • 与现有合同管理、权限系统深度集成，形成企业内部闭环能力。

2. 核心架构与流程 ​

2.1 技术架构概览 ​

  • 后端框架：Spring Boot
  • 数据访问：合同、规则、Prompt 模板均落在数据库中
  • AI 接入层：统一的 AI 调用封装层，支持：
    • 单 Provider 多模型（多模型并行审计与结果选择）
    • 多 Provider 多模型（不同厂商、多模型协同）
  • 核心模块（逻辑划分）：
    • 合同审计引擎：负责完整审计流程编排
    • 规则管理模块：负责审计规则的配置、存储与生效
    • Prompt 模板模块：管理系统消息、用户消息和条款片段模板
    • 配置中心：负责条款类型、模型列表、评分策略等运行参数

2.2 审计主流程 ​

整体由合同审计引擎服务驱动，可概括为：

  1. 预处理与条款解析

    • 从数据库 contract 表或请求参数中加载原始合同全文、修改后全文：
      • 若 originalContent 为空，则自动从 contract 表按 contractId 读取；
    • 通过 extractAllClauses 等方法，将文本按条款编号（如 7.1、7.2.1）拆分；
    • 支持两种差异识别模式：
      • 显式模式：前端已传入 clauses 或 modifications（包含条款号、修改类型等），系统直接构造 ContractClause；
      • 智能对比模式：如果仅提供原文和修改后全文，则通过 smartDiffClauses 自动对比，识别“新增 / 删除 / 修改”的条款。

  2. 条款类型识别（Clause Type）

    • 当前默认使用配置的关键词规则识别条款类型（如“租金条款”“终止条款”“违约责任”等），保证行为稳定、可预期；
    • 系统预留了通过 AI + 模板（如 CLAUSE_TYPE_RECOGNITION）自动识别条款类型的能力，可在后续按需要启用，用于进一步提升识别准确率。

  3. Prompt 构建与 AI 审计

  • System Message（系统消息）：

    • 通过 ContractAuditPromptService.getSystemMessage(...) 从 contract_audit_prompt_template 表按范围（GLOBAL / CONTRACT_TYPE / CONTRACT）选出最适合的系统模板，例如：
      • SYSTEM_DEFAULT：全局默认系统消息；
      • SYSTEM_LEASE：房屋租赁合同专用系统消息；
    • 模板中明确 AI 的角色、立场（保护甲方/出租方利益）、重点关注的风险点等。

  • User Message（用户消息）：

    • 使用 ContractAuditPromptService.buildUserMessage(params) 构建：
      • 合同基本信息：合同类型、甲乙方、合同 ID；
      • 当前条款信息：条款编号、条款类型、修改类型；
      • 原始合同全文或与该条款相关的上下文；
      • 原始条款 / 修改后条款内容；
      • 从 SECTION 模板中匹配到的标准条款参考（如租金条款、终止条款、违约责任等）；
      • 从数据库规则生成的 审计规则 YAML（auditRules）。
    • 对于没有单独提供原始条款的场景，系统内置专门模板（如 USER_WITHOUT_ORIGINAL_CLAUSE），指导 AI 自己先从原始合同全文中定位条款原文，再进行差异对比。

  • 调用 AI：

    • 条款数量较少、总字符数较小：使用批量模式 batchAuditClauses，一次请求审多条条款，要求 AI 返回 JSON 数组；
    • 字数或条款数较大：使用逐条模式 performMultiModelAudit，每条条款单独构建 Prompt 调用；
    • 支持多模型 / 多 Provider 并行，由 AI 模块聚合多个模型结果并给出“最佳答案”和模型共识度。
  1. AI 结果解析和容错
  • 强制要求 AI 按严格 JSON 格式输出（包括单条和数组两种格式），系统通过 extractJson / extractJsonArray 从回复中抽取 JSON 文本；
  • 利用 ObjectMapper 将 JSON 映射为结构化对象：
    • riskPoints：风险点列表；
    • riskLevel：高/中/低；
    • riskScore：0–100 数值分；
    • impactAnalysis：对甲方影响分析；
    • legalBasis：法律依据或条款依据；
    • suggestions：修改建议；
    • confidence：AI 自信度；
    • originalClauseFound：AI 从原文自动匹配到的条款原文。
  • 若解析失败或格式不符合预期，会退回到一个“默认分析结果”，同时提示需要人工复核，避免系统“静默失败”。
  1. 规则引擎二次校验（基于数据库规则）
  • 规则定义在 contract_audit_rule 表，与代码解耦，可通过后台管理界面配置；
  • 规则类型包括：
    • BLACKLIST / WHITELIST：对甲方/乙方名称、文本内容做黑白名单检查；
    • VALUE_RANGE：对数值型字段（如宽限期天数、违约金百分比）检查是否在允许范围内；
    • KEYWORD：必须包含 / 禁止包含某些正则或关键字；
    • CUSTOM：预留 SpEL 表达式扩展能力；
  • 在规则校验阶段：
    • 按 priority 从高到低遍历启用规则，检查每条条款是否违反；
    • 命中规则时：
      • 在条款 riskPoints 中追加带规则编号的风险说明；
      • 在 suggestions 中追加“强制修改 / 建议修改 / 注意”级别的整改建议；
      • 记录命中规则中 最高的 priority 作为规则侧评分 bestRuleScore。
  1. 最终评分与等级合成（规则可控）

  • 系统通过配置项 allowRuleToLowerRisk 提供一个核心控制开关：

    • 用于控制规则是否可以降低 AI 模型给出的风险评分和风险等级；
    • 为 true 时，规则可以把 AI 判定的高风险降为较低风险；
    • 为 false 时，规则只允许抬高或保持风险，不允许比 AI 更低。

  • 对每条条款：

    1. AI 先给出初始 riskScore 和 riskLevel；
    2. 规则引擎找出所有命中规则的 priority，取最大值 bestRuleScore；
    3. 根据开关合成最终分数：
      • 若 allowRuleToLowerRisk = true：
        • finalScore = bestRuleScore（完全由规则最高分决定，可压低 AI 风险）；
      • 若 allowRuleToLowerRisk = false：
        • finalScore = max(aiScore, bestRuleScore)（规则只能抬高或不改变 AI 风险，不能降低）；
    4. 再根据 finalScore 统一映射风险等级：
      • >= 80：高风险；
      • 50–79：中风险；
      • < 50：低风险。

  • 这一机制使得：

    • 在 风险偏保守 的场景，可以关闭“降分”能力，让规则只做加严；
    • 在 业务灵活 的场景，甲方可以通过规则配置把某些模型眼里的“高风险”视为“可接受风险”，从而降低不必要的拦截率。
  1. **审计报告生成
  • 系统最终生成结构化的审计报告对象，包括：
    • 整体风险分数与等级；
    • 高/中/低风险条款数量统计；
    • Executive Summary（高层关键发现摘要）；
    • 每条条款的详细条款级风险分析记录；
    • 综合建议部分（必须修改 / 建议修改 / 注意事项 / 谈判要点 / 底线条款）；
    • 是否建议人工复核标识（高风险或模型共识度低时）。

3. 与 n8n / Dify 等通用平台的对比 ​

3.1 与 n8n 的对比 ​

  • n8n 的特点：

    • 通用工作流编排工具，适合“调用接口 → 判断条件 → 发通知”这类流程自动化；
    • 节点可视化、易于搭建简单流程。

  • 在合同审计场景中的问题：

    • 缺少领域建模：
      • 条款对象、规则对象、合同模板等都需要通过变量在节点间手工传递，逻辑分散，难以做版本管理和合规审查；
    • 规则与流程强耦合：
      • 业务规则一旦变化，需要修改大量节点，难以维护；
    • 评分与规则机制难以精细实现：
      • “多模型并行 + 模型共识度 + 规则优先评分 + 是否允许降级”这种组合逻辑，在 n8n 里需要大量自定义脚本节点，实际上等同于“重写一套后端”；
    • 与核心业务系统的集成成本高：
      • 合同原文、用户权限、日志审计等需要在 n8n 与主系统之间频繁同步，数据链路复杂。

  • 本系统相对优势：

    • 有完整的 合同 / 条款 / 规则 / 模板 / 审计报告 领域模型，清晰可审计；
    • 规则存储在数据库，以规则记录为核心，可配置、可版本化，而不是散落在工作流节点中；
    • 审计逻辑集中在一个清晰的服务实现中，更易于 code review、合规审查和回溯；
    • 易于和现有合同管理、权限、工单系统做深度集成，形成企业内部一体化解决方案。

3.2 与 Dify 的对比 ​

  • Dify 的特点：

    • 通用 LLM 应用开发平台，适合快速搭建 AI Demo 或中轻量级应用；
    • 提供工作流、Agent、工具调用、知识库等能力。

  • 在严肃合同审计中的局限：

    • 规则与策略难以做精细映射：
      • Dify 多数情况下把规则写在 Prompt 或 Flow 中，不易被法务/风控独立 review 与版本管理；
      • 很难像本系统一样，用一张规则表 + Java 规则引擎实现细粒度、可配置、可测试的风险策略；
    • 条款级审计复杂度高：
      • 要在 Dify 中实现按条款编号对比原文/修改后文本、再叠加数据库规则，需要大量自定义逻辑，运维和二次开发成本高；
    • 数据安全与部署形态：
      • Dify 通常作为独立平台部署，涉及合同文本在不同系统之间流转；
      • 对于要求“合同数据只在企业后端内部闭环流转”的客户，本系统更容易满足合规要求。

  • 本系统相对优势：

    • 审计逻辑与数据全在企业自有后端中运行，便于统一访问控制、审计日志与安全加固；
    • 规则、模板、评分策略均可通过数据库与后端服务集中管理，更适用于中长期持续演进的企业级项目；
    • 更容易做自动化测试与持续集成（CI/CD），保证每一次规则调整都可以被回归测试覆盖。

4. 总结：为什么选择这套架构 ​

  • 专为“合同审计”这一垂直场景设计，而非通用 AI 工作流工具：
    • 完整的条款级建模、规则建模和审计报告结构；
  • AI + 规则双引擎：
    • 模型提供语义理解能力，规则提供企业风控策略，二者结合既智能又可控；
  • 风险可控、策略可调：
    • 通过数据库规则和评分开关，客户可以精细控制“哪些条款视为高风险，哪些属于可接受风险”；
  • 与现有系统深度耦合能力强：
    • 作为后端服务内生能力，易于接入合同管理、权限、工单、审核流等现有系统；
  • 可审计、可测试、可演进：
    • 所有关键逻辑都在代码和数据库中有明确记录，可以进行 code review、合规审查和自动化测试，适合长期运维和演化。

Copyright © 2025-present | 网站备案号:豫ICP备19038229号-1