第三层 复核 LLM(仅对一审"违规"二审,可降级)
v1 私有化代码版 — Python 后端(FastAPI)+ Next.js 前端,双进程内网部署
IMC Audit · 合规审核 PoC
基于三部监管法规的事前合规审核系统→44 条原子规则 / Catalog 化检索 / 三层判定
输入营销内容 → 五阶段流水线 → 结构化判定 + 可读叙事报告。中间环节"逐规则并发评估"为本系统核心创新点。
v1 私有化代码版 — Python 后端(FastAPI)+ Next.js 前端,双进程内网部署
项目第一道工序。从三部监管法规原文到 44 条原子规则的五步主线 — 抽取期工程量上升,运行期性能与可解释性大幅提升。
| 步骤 | 工具 / 模型 | 产出量 |
|---|---|---|
| 第一步 法规预处理 | PyMuPDF + python-docx + 自实现中文条款编号展开 | 272 条 结构化条款片段 |
| 第二步 候选条款分类 | qwen3.6-plus 4 分类 prompt | 73 条 "内容审核相关"片段(占 27%) |
| 第三步 跨法规原子化抽规则 | 双模型对照(详见 §2.5) | 主基线 35 条 草稿规则 |
| 第四步 三层查漏防御 | 章节穷举 + 双向反查 + 测试集校验 | 补出 +9 条 漏抽规则 |
| 第五步 人审 + 落地 | 逐条审定义 / 可证伪声明 / 示例 | catalog.json 44 条原子规则 |
用一道 LLM 二分类闸门,把"可在销售文案 / 海报 / 直播话术上单独判定违规"的条款挑出来。跳过这一步会抽出大量伪规则(如"应配备专职合规人员"),抽取期 token 消耗放大 3.7 倍且下游查漏信号被污染。
模型:qwen3.6-plus · temperature=0.2 · 强制 JSON 输出
| 标签 | 定义 | 例子 | 进抽取 |
|---|---|---|---|
| 内容审核相关 | 宣传文案 / 销售话术里"不得说什么 / 必须披露什么 / 必须如何呈现" | "不得使用'最好''第一'"、"必须明示承保公司全称"、"不得将保险与存款混淆" | ✓ |
| 机构内部管理 | 人员资质培训、考核、留痕系统、内审制度 | "应建立销售人员分级管理制度" | — |
| 监管执法条款 | 行政处罚、备案、监管报送、违规罚则 | "违反本办法规定,由金融监管部门责令改正" | — |
| 销售流程动作 | 如实告知、可回溯录音、投保确认书、电话回访、犹豫期 | "应当在投保人确认前进行如实告知" | — |
三部监管法规的禁令存在大量同主题重叠——例如"不得将保险与存款理财混淆"同时出现在保险销售行为管理办法 §17(二)、互联网保险业务监管办法 §15(四)/(六)、金融产品网络营销管理办法 §9(四)/§10。按法规分批抽会得到 3 条同义重复规则,去重负担转嫁到运行期。
实测产出:Opus 跨法规聚合输出 35 条规则——5 条跨 3 部法规、9 条跨 2 部、21 条单法规。15 / 44 ≈ 34% 的规则横跨 ≥ 2 部法规,平均每条规则关联 1.86 个证据条款。
| 模型 | 跨法规聚合产出 | 已知问题 |
|---|---|---|
| qwen3.6-plus | 18 条 | 同主题禁令折叠粒度偏粗,部分独立违规点被合并 |
| Claude Opus 4.7 | 35 条 | 拆分粒度合理,跨法规关联识别准确 — 保留为主基线 |
核心问题:单层反查在"应有但完全不存在的违规主题"上有结构性盲区——抽取期没识别的主题,单层反查永远找不到。
| 层 | 原理 | 独家管辖 |
|---|---|---|
| 第一层 章节穷举(事前) | 从法规结构反查每个条款的覆盖状态 | Phase A 错分类、章节子项整段漏抽 |
| 第二层 Pass A 标题反查(事中) | 已知规则标题 → 找漏引条款 | 同主题禁令在另一法规的条款被遗漏 |
| 第二层 Pass B 条款反查(事中) | 未被引用的条款 → 找新违规主题 | 独立违规主题盲区(其他三层都查不到) |
| 第三层 测试集反向校验(事后) | 真实违规样本反推规则覆盖率 | 规则定义模糊(漏报)/ 规则过严(误报) |
双向反查实证(跨链路对照实验)
| 链路 | 初版抽取 | 仅标题反查 | + 条款反查 | 条款覆盖率 |
|---|---|---|---|---|
| qwen | 18 条 | 18(新增=0) | 21 条(+3) | 67% → 90% |
| Opus | 35 条 | 35(新增=0) | 44 条(+9) | 60% → 82% |
把传统"图遍历 + 向量召回 + 主判定"折叠为"逐规则直接评估"。规则的法规关系图谱预编码进 applicable_sections 字段,运行期不做向量召回也不做图遍历。
学术映射:借鉴 GraphRAG(Microsoft 2024)+ 法规知识图谱研究,但前置完成规则原子化抽取——抽取期工程量上升,运行期性能与可解释性大幅提升。
| GraphRAG 概念 | 本系统对应 |
|---|---|
| 知识图谱实体 | 每条规则 = 一个实体节点 |
| 跨实体关系(cross_doc_ref) | applicable_sections 跨法规多条款引用(15/44 条规则横跨 ≥ 2 部法规) |
| 运行期图遍历 | 抽取期完成,运行期等价于"图遍历预先 done" |
| LLM-based reasoning | 逐规则评估的"可证伪声明 → 合规 / 违规 / 复核" |
向量召回在通用 RAG 场景下是成熟工程。在本系统的约束下既不必要也不会提速:
逐规则评估的判定核心。从单层 LLM(F1=0.772)出发,叠加三层防御后样本级 F1=0.984 / 规则级 F1=0.952。每层独立可开关,便于回归测试与成本控制。
样本级 F1("是否违规"二分类)与规则级 F1("具体引哪条法规"精细判定)两层指标分别衡量。
成本:仅一审 1.0x → 一审 + 复核 1.25-1.30x
第二层的"必要条件 + 显式 PASS 排除"清单同时被一审 prompt 与复核 prompt 引用——这是两个层的关键耦合:
50 样本测试集 / 5 类违规 × 3 模态 × 3 置信度梯度 / 样本级 F1=0.984 (1 FP) / 规则级 F1=0.952 (4 FP / 11 FN)
| 维度 | 内容 |
|---|---|
| 测试集规模 | 50 条样本(31 真实违规 + 19 合规对照;含 A 组 10 条针对原规则覆盖缺口设计的新样本) |
| 数据来源 | KC seed 真实违规样本 + 真实保险公司海报 OCR + 边界合规对照 + HSBC 真实产品宣传册 document 样本 |
| 标注方式 | 人工逐条标注 (是否合规, 期望违规规则, 必须命中短语) 四元组;GT 经过两轮反向审计(按 pipeline FP 反查样本原文,确认 LLM 命中的"溢出违规"实为真违规) |
| 覆盖维度 | 5 类核心违规类型 × 3 种输入模态 × 3 档置信度梯度 |
核心指标按业务重要性排序。样本级 F1 衡量"整篇内容是否需要复核"二分类;规则级 F1 衡量 pipeline 在每条规则上"具体引哪条法规、定哪种性质违规"的精细判定能力。
| 指标 | 业务含义 | 目标 | 实测(current, 50 样本) |
|---|---|---|---|
| 样本级漏报率 | 违规样本漏拦 → 监管处罚风险 | ≤ 5% | 0%(31 真违规 / 0 漏报) |
| 样本级 F1 | "整篇内容是否需要复核"二分类 | ≥ 0.95 | 0.984 30 TP / 1 FP / 19 TN / 0 FN |
| 规则级 F1(主动违规类) | "具体引哪条法规"精细判定 | ≥ 0.85 | 0.909 135 TP / 1 FP / 26 FN(A 主链路 critic+RAG) |
| 条文引用准确率 | 合规系统不可让步线 | 100% | 100%(catalog 化结构性保证,rule_id → source_clause 关联编码进规则数据) |
| 单次审核延迟 | 用户等待时间 | < 10s 纯文本 | ~22s 主判定 + ~10s 叙事 |
同一测试集 50 样本 / 同一 GT / 同一 prompt,仅切换 critic 与 RAG K=15 开关,跑 4 个配置
| 指标 | A (主链路) critic+RAG |
C critic+no-RAG |
B no-critic+RAG |
D (baseline) no-critic+no-RAG |
|---|---|---|---|---|
| critic 二审 | ✅ | ✅ | ❌ | ❌ |
| RAG K=15 | ✅ | ❌ | ✅ | ❌ |
| LLM judge 调用 | 735 | 1120 | 735 | 1120 |
| LLM critic 调用 | 1 | 9 | 0 | 0 |
| 样本级(整篇内容是否需要复核) | ||||
| TP / FP / TN / FN | 30/1/19/0 | 30/1/19/0 | 30/6/14/0 | 30/6/14/0 |
| Precision | 0.968 | 0.968 | 0.833 | 0.833 |
| Recall | 1.000 | 1.000 | 1.000 | 1.000 |
| F1 | 0.984 | 0.984 | 0.909 | 0.909 |
| 规则级(具体引哪条法规,剔除披露类) | ||||
| TP / FP / FN | 135/1/26 | 143/6/18 | 137/16/24 | 151/27/10 |
| Precision | 0.993 | 0.960 | 0.895 | 0.848 |
| Recall | 0.839 | 0.888 | 0.851 | 0.938 |
| F1 | 0.909 | 0.923 | 0.873 | 0.891 |
→ critic 是规则级 FP 镇压器,跨 RAG 状态稳定拦下 70-94% 误判。这是它的核心价值——错引法规在合规系统里是不可接受的失败模式。
→ RAG 是成本/精度的工程权衡:省 34% LLM 调用,代价是规则级 Recall 轻微下降。详见 ADR-0004。
source.source_chunk_ids,运行期不存在"引文召回错误"的可能两类核心决策都集中在"规则生成"和"运行期过滤"阶段——这是合规审核系统能否被审计部接受的工程根基。
| 决策 | 选择 | 取舍理由 |
|---|---|---|
| 检索方法论 | catalog 化逐规则消费 + cosine top-K 候选缩减 | 抽取期完成图谱关系编码保证零幻觉引文;运行期加 RAG K=15 候选缩减层做成本优化(省 -34% LLM judge 调用,规则级 F1 微退 -0.014,见 ADR-0004) |
| 向量库角色 | 候选缩减层(embedding 走 DashScope text-embedding-v4) | catalog.json + source_clauses.json 双层结构保留;RAG 不动规则与法规条款的关联,只对 applicability 后的候选规则做 cosine 排序 + top-K 截断 |
| 抽取方式 | 跨法规聚合抽取(而非按法规分批) | 同主题禁令跨多法规重叠,跨法规抽取直接产出"1 实体 + N 证据指针",对应知识工程的实体消解 + GraphRAG 社区检测 |
| 抽取模型 | 双模型并行 + 对照保留 Opus 作为基线 | qwen 拆分粒度偏粗,Opus 拆分粒度合理;qwen 产物作为后续查漏的对照信号继续使用 |
| 抽取期质量门 | 三层查漏防御(事前章节穷举 + 事中双向反查 + 事后测试集) | 单层反查在"应有但完全不存在的违规主题"上有结构性盲区;条款反查实测补 +9 条 |
| 标签层 | 弃用 metadata.tags,违规类型直接由规则标题派生 | LLM 错配标签 3 处真实坑 + 字典维护成本(14→18 keys)+ 信息冗余 |
| 编排框架 | 自写工作流,不用 LangGraph | 6 步线性 + 1 个简单分支,套框架是过度工程,自写 < 300 行 |
| 模式选择 | 工作流(Workflow),不用 Agent | 合规审核要求可重现可审计,Agent 自由决策权在此是负价值 |
| 切片策略 | 按章 / 节 / 条 / 款层次切,不用固定窗口 | 监管条文是原子化判据,固定窗口会切断条款 |
| 复核节点 | LLM 二审而非纯规则 | 纯规则覆盖不全,LLM 复核能捕捉"证据不足"与"过度判定"两类错误 |
本期交付落在前 3 阶段,第 4 阶段「蒸馏」是后续关键转折。每阶段成本结构与触发条件预先约定,避免 PoC 直接当生产用的常见反模式。
| 阶段 | 核心动作 | 成本结构 | 本期 PoC |
|---|---|---|---|
| ① 规则建库 | 监管文档 → 原子规则 + 关系图编码 | SOTA 一次性投入 | ✓ 已交付 |
| ② 审核流水线 | 规则适用过滤 + 主判定 + 复核 | SOTA 按调用计费 | ✓ 已交付 |
| ③ 离线评估 | 测试集 + 准确率 + bad case 分析 | SOTA + 人工标注 | ✓ 轻量版 |
| ④ 蒸馏(关键转折) | SOTA 判定逻辑下沉到小模型 + 代码规则 | 单条成本 ↓ 5–10× | 后置 |
| ⑤ 量产质控 | 生产流量按置信度抽样、人工复核 | Worker 跑量 + SOTA 抽查 | 后置 |
| ⑥ 收敛交付 | 规则库版本化、覆盖率报告、监控仪表板 | 持续维护 | 后置 |
PoC 阶段直接用 SOTA 模型跑全量判定是合理选择——开发效率高、可解释性好。触发蒸馏的临界点:日均审核量到 10 万条/日以上时,单条 SOTA 调用成本累积超过监管罚款的风险价值,三档下沉是性价比拐点。
三种入口共享同一判定后端,不影响判定逻辑本身: