把大模型放在它擅长的位置，把确定性交给程序

合同预审如果只是“合同文本 + 一段提示词 + 一次模型调用”，就很难同时解决稳定性、可解释性、精度和性能问题。我们的预审将整个过程拆成多个职责单一的环节，模型负责合同类型识别、事实抽取和开放式语义判断；Java 负责范围过滤、数值计算、一致性比对、证据定位、法律依据校验、负向检索、状态一致性和报告组装。

端到端执行链路

flowchart LR
    A[合同正文/审批快照] --> B[文本提取与清洗]
    C[表单、收付款计划、履约任务] --> D[结构化上下文]
    B --> E[内容指纹与版本校验]
    D --> E
    E --> F[合同类型/角色/阶段/方向过滤]
    F --> G[内置专业预审]
    F --> H[数据库可配置规则]
    H --> I[抽取+程序计算/一致性比对]
    H --> J[分组感知的语义规则并行评审]
    G --> K[精审自检与动态资料补读]
    I --> L[服务端质量门禁]
    J --> L
    K --> L
    L --> M[合并、去重、分级、日志落库]
    M --> N[PC/移动端报告与反馈闭环]

1. 输入不是一段孤立文本

预审使用最新合同正文，在审批提交场景中则使用冻结快照，避免审查过程追随后续编辑而改变。文本处理会识别重复 OCR 版式元数据并去除污染前缀，同时保留合同真实文字。

结构化上下文除了合同类型、我方与对方、收支方向、金额、币种、税率、有效期和自定义表单外，还可包含审批中的临时收付款计划、履约监控项，以及履约阶段的正式任务数据。这些信息也参与内容指纹，业务数据变更后不会继续复用旧报告。

2. 双来源预审能力可独立配置、也可相互增强

预审来源分为：

  • 内置专业预审：按完整审查框架执行基础全面审查，动态加载合同类型规则、风险模式和相关模板。
  • 数据库规则增强：由管理员配置企业特有的风险规则，可按审查阶段、合同类型、父子类型路径和用户角色设定范围。

两种来源可由系统配置选择。如果其中一个来源失败，服务可保留另一来源已通过门禁的结果，并将整份报告标识为 PARTIAL，而不是把部分结果冒充为完整预审。

3. 内置预审采用“分阶段检索 + 精审自检”

内置预审首先加载通用核心知识、高风险条款模式和缺失条款模式。已知合同类型时，必读该类型的 legal_rules.json；类型不明时，先由模型给出可靠类型，再由 Java 协议锁补读对应规则包。

第一阶段产生候选结论后，系统按主体、付款、验收、质保、违约和争议等主题定向搜索标准模板与少量业务模板，再执行最终精审自检。资源读取路径、数量和最大轮次都由 Java 控制，实际读取的资料也会记录在报告中。

4. 数据库规则使用 SPLIT 引擎执行

默认 SPLIT 模式把规则分成两条互不依赖的路径：

  • 抽取 + 计算/一致性比对：先按规则聚合需要的事实字段，由 AI 分批抽取；之后使用程序表达式计算比例、日期差、金额和适用条件，或比对正文与表单。抽取不到关键字段时保守跳过，不把“抽取失败”当成“合同缺失”。
  • 语义规则分批并行：按规则分组感知合并，避免将同类规则不必要地拆散；各批使用低温度强模型并行评审。

语义评审和统一字段抽取同时启动。默认语义每批 10 条、抽取每批 18 个字段，并可配置并发上限，以兼顾上下文完整性、模型 QPS 和总体时延。LEGACY 单次全量模式仍作为回退通道保留。

5. 服务端质量门禁决定什么能展示给用户

AI 输出的 JSON 不会直接下发。它必须通过以下检查：

  1. ruleId 必须属于本批已审规则，防止模型自创规则。
  2. 语义结论必须是确定 HIT、全条件成立、置信度至少 0.85。
  3. 所有非缺失证据都必须在合同正文或表单元数据中匹配，并替换为真实子串和起止下标。
  4. 缺失结论必须包含至少两个有区分度的检索词，并通过合同全文归一化负向检索。
  5. 法律依据的文件路径必须在本轮已加载资料中，法律名称和条文编号必须真实存在于该资料。
  6. 示范条款必须是完整可执行的合同句式，而不是“建议明确”之类修改方向。
  7. 纯视觉排版推测、无根据税率推断、被反向条款推翻的结论等高发误报类型会被确定性抑制。

门禁无法确认的数据库规则可标记为 UNKNOWN，不会被悄悄归入 PASS。这个区分很重要：“证据不足”不等于“已证明合规”。

6. 异步状态机保证用户看到的是“当前合同”的报告

自动预审使用合同级状态行、内容指纹和文件版本实现并发占用与结果采纳：

  • 相同内容可识别为重复任务，减少无效重跑。
  • 频繁变更可通过冷却窗口防抖，且可保存待执行的最新内容。
  • 任务完成时使用内容指纹和快照/文件版本做 CAS 校验；合同已改变时，旧结果保留在日志中但不会被采纳为“最新报告”。
  • IN_PROGRESS 任务有租约超时恢复机制，防止进程重启或线程中断后长期卡住。
  • 页面只在报告指纹与当前合同匹配时展示报告，旧任务状态不会冒充当前结果。

7. 规则管理和反馈数据让系统可持续治理

管理端可以管理规则分组、风险级别、适用环节、合同类型范围、角色 INCLUDE/EXCLUDE 范围及启用状态。计算和一致性规则通过可视化构建器配置字段、适用条件、表达式、比较方式和缺失策略，无需管理员直接手写 JSON。新建规则默认禁用，需要经过审核后显式开启。

“有用”反馈与带原因的合同级忽略会分别持久化；反馈服务还支持按规则汇总反馈总数、有用数和误报率。这样，规则调优可以逐步从个别投诉转向可统计的真实业务数据，同时保留“业务接受风险”和“规则确属误报”两类信息的不同语义。

一套可信 AI 系统应有的底线

这套技术体系并不假设模型永远正确，而是将“模型可能不稳定”作为系统设计的前提。它允许不确定，允许部分完成，允许人工忽略并给出原因；但不允许无法匹配的引文、无法校验的法律依据和过期结果悄悄进入用户报告。

这正是预审从“AI 功能”走向“企业级风险基础设施”的关键。

实现依据