PoC

保险营销内容智能审核

IMC Audit · 合规审核 PoC

基于三部监管法规的事前合规审核系统44 条原子规则 / Catalog 化检索 / 三层判定

一、整体架构 二、规则生成工作流 三、规则 catalog 直读 四、三层判定架构 五、效果评估 六、关键设计取舍 七、演进路径

一、整体架构

输入营销内容 → 五阶段流水线 → 结构化判定 + 可读叙事报告。中间环节"逐规则并发评估"为本系统核心创新点。

IN
营销内容输入文本 / 图片 / 完整文档 三种模态
输入类型门截图、文字片段自动跳过"销售页披露类"规则,避免对局部内容做整体性判定
文档类型分类4 类:销售页 / 营销素材 / 科普 / 内部资料
规则适用过滤按文档类型 + 排除条件筛选适用规则集
逐规则并发评估44 条原子规则 × ~8 并发
第一+二层 主判定 LLM(中立判定原则 + 必要条件清单)
第三层 复核 LLM(仅对一审"违规"二审,可降级)
样本级聚合任意一条规则判违规 → 整体违规
叙事综合 LLM生成 Markdown 审核报告(违规清单 + 法规引用 + 整改建议)
OUT
结构化判定结果(JSON)+ 可读叙事报告
部署形态

v1 私有化代码版 — Python 后端(FastAPI)+ Next.js 前端,双进程内网部署

模型栈
qwen3.6-plus 主判定Claude Opus 4.7 一次性规则抽取百炼 Token Plan

二、规则生成工作流

项目第一道工序。从三部监管法规原文到 44 条原子规则的五步主线 — 抽取期工程量上升,运行期性能与可解释性大幅提升。

2.1 五步主线

法规预处理
PDF/DOCX → MD
按章/节/条/款切片
候选条款分类
4 分类筛选
content_audit_only
跨法规原子化抽规则
双模型对照
一次塞全部 73 条款
三层查漏防御
事前章节穷举
事中双向反查
事后测试集校验
人审 + 落地
逐条审 → catalog.json

2.2 各步骤量化产出

步骤工具 / 模型产出量
第一步 法规预处理PyMuPDF + python-docx + 自实现中文条款编号展开272 条 结构化条款片段
第二步 候选条款分类qwen3.6-plus 4 分类 prompt73 条 "内容审核相关"片段(占 27%)
第三步 跨法规原子化抽规则双模型对照(详见 §2.5)主基线 35 条 草稿规则
第四步 三层查漏防御章节穷举 + 双向反查 + 测试集校验补出 +9 条 漏抽规则
第五步 人审 + 落地逐条审定义 / 可证伪声明 / 示例catalog.json 44 条原子规则

2.3 第一步:法规预处理

输入3 部监管法规(PDF + DOCX 混合格式)
工具PyMuPDF + python-docx + 自实现中文条款编号展开
产出272 条结构化条款片段,按"章 / 节 / 条 / 款"层次切
规约chunk_id: <法规简称>_c<编号>[_p<款序>]

2.4 第二步:候选条款分类

用一道 LLM 二分类闸门,把"可在销售文案 / 海报 / 直播话术上单独判定违规"的条款挑出来。跳过这一步会抽出大量伪规则(如"应配备专职合规人员"),抽取期 token 消耗放大 3.7 倍且下游查漏信号被污染。

模型:qwen3.6-plus · temperature=0.2 · 强制 JSON 输出

标签定义例子进抽取
内容审核相关宣传文案 / 销售话术里"不得说什么 / 必须披露什么 / 必须如何呈现""不得使用'最好''第一'"、"必须明示承保公司全称"、"不得将保险与存款混淆"
机构内部管理人员资质培训、考核、留痕系统、内审制度"应建立销售人员分级管理制度"
监管执法条款行政处罚、备案、监管报送、违规罚则"违反本办法规定,由金融监管部门责令改正"
销售流程动作如实告知、可回溯录音、投保确认书、电话回访、犹豫期"应当在投保人确认前进行如实告知"
判定原则:能不能在一段销售文案上单独判定违规?能 → 内容审核相关;不能 → 其他三类。拿不准的边界 case 保守倾向"内容审核相关",让下一步再判一次。
实测产出:272 条 → 73 条"内容审核相关"(27%),其他 199 条剔除。

2.5 第三步:跨法规原子化抽规则(双模型对照)

三部监管法规的禁令存在大量同主题重叠——例如"不得将保险与存款理财混淆"同时出现在保险销售行为管理办法 §17(二)、互联网保险业务监管办法 §15(四)/(六)、金融产品网络营销管理办法 §9(四)/§10。按法规分批抽会得到 3 条同义重复规则,去重负担转嫁到运行期。

知识工程视角
理论映射跨法规抽取 ≡ 知识图谱中"实体—证据"建模(1 规则 = 1 监管概念实体 + N 证据指针)
工程对应抽取期实体消解 + GraphRAG 社区检测的物化(把跨文档语义聚类的"社区"在抽取期一次性产出为规则)

实测产出:Opus 跨法规聚合输出 35 条规则——5 条跨 3 部法规、9 条跨 2 部、21 条单法规。15 / 44 ≈ 34% 的规则横跨 ≥ 2 部法规,平均每条规则关联 1.86 个证据条款。

模型跨法规聚合产出已知问题
qwen3.6-plus18 条同主题禁令折叠粒度偏粗,部分独立违规点被合并
Claude Opus 4.735 条拆分粒度合理,跨法规关联识别准确 — 保留为主基线
对照后的选型决策:qwen 抽出规则数显著少于 Opus,人审确认 qwen 漏抽 → Opus 跨法规聚合产物保留作为主基线 → qwen 的产物作为后续三层查漏的对照信号继续使用。双模型对照本身就是查漏机制的一部分。

2.6 第四步:三层查漏防御

核心问题:单层反查在"应有但完全不存在的违规主题"上有结构性盲区——抽取期没识别的主题,单层反查永远找不到。

原理独家管辖
第一层 章节穷举(事前)从法规结构反查每个条款的覆盖状态Phase A 错分类、章节子项整段漏抽
第二层 Pass A 标题反查(事中)已知规则标题 → 找漏引条款同主题禁令在另一法规的条款被遗漏
第二层 Pass B 条款反查(事中)未被引用的条款 → 找新违规主题独立违规主题盲区(其他三层都查不到)
第三层 测试集反向校验(事后)真实违规样本反推规则覆盖率规则定义模糊(漏报)/ 规则过严(误报)

双向反查实证(跨链路对照实验)

链路初版抽取仅标题反查+ 条款反查条款覆盖率
qwen18 条18(新增=0)21 条(+3)67% → 90%
Opus35 条35(新增=0)44 条(+9)60% → 82%
仅标题反查时双方新增规则数 = 0;引入条款反查后立刻补出独立违规主题:售后服务披露 / 精准营销适当性 / 官网信披要素整族

2.7 第五步:人审 + 落地

输入Opus 跨法规聚合 + 三层查漏补出共 44 条规则草稿
操作逐条审定义 / 可证伪声明 / 示例;红黄信任度行处理
产出rules/catalog.json 44 条原子规则

三、运行期:规则 catalog 直读(GraphRAG 物化变体)

把传统"图遍历 + 向量召回 + 主判定"折叠为"逐规则直接评估"。规则的法规关系图谱预编码进 applicable_sections 字段,运行期不做向量召回也不做图遍历。

3.1 设计要点

学术映射:借鉴 GraphRAG(Microsoft 2024)+ 法规知识图谱研究,但前置完成规则原子化抽取——抽取期工程量上升,运行期性能与可解释性大幅提升。

GraphRAG 概念本系统对应
知识图谱实体每条规则 = 一个实体节点
跨实体关系(cross_doc_ref)applicable_sections 跨法规多条款引用(15/44 条规则横跨 ≥ 2 部法规)
运行期图遍历抽取期完成,运行期等价于"图遍历预先 done"
LLM-based reasoning逐规则评估的"可证伪声明 → 合规 / 违规 / 复核"

3.2 为什么不上向量召回

向量召回在通用 RAG 场景下是成熟工程。在本系统的约束下既不必要也不会提速:

  1. 规则集小且封闭:44 条规则可枚举,每次审核全跑一遍成本可控(关键词预过滤后真正调模型约 12-15 条 / 样本)
  2. 不会显著提速:系统延迟瓶颈在 LLM 调用本身(~1.5s × 12-15 规则 / 并发 5 ≈ 3-8s),不在前置过滤。向量召回即使把 LLM 调用从 12-15 压到 8-10,节省 ~1-2s 墙钟,量级与召回失败风险不对称
  3. 失败模式的可审计性差异(合规审核场景的关键):
    • 向量召回的失败模式是静默漏召——某条规则未被召回 = 未被评估 = 结果里看不到"为什么这条规则没出现"
    • 全量遍历的失败模式是显式判错——所有适用规则都有判定结果,错了能复盘
    • 合规审核场景静默漏召的代价远高于显式判错:监管按"应审未审"追责,不是按"判错"追责
  4. 召回准确率的来源不同:catalog 化把"规则 ↔ 条款"关联在抽取期一次性物化,运行期直接读结构 = 100% 引用准确率;向量召回是运行期重新估计,引入额外不确定性
适用范围:规则集 ≤ 50 条 + 强可审计要求 + 瓶颈在 LLM 推理的合规审核场景。规则数突破 200 条时该决策需要重审。

3.3 运行期数据收敛

规则总数
44
量级可控
适用过滤后
~30-38
按文档类型 + 排除条件
关键词预过滤后
~12-15
违规信号命中才调 LLM
单样本 token
~9K + ~3K
并发 5 路约 3-8 秒

四、三层判定架构

逐规则评估的判定核心。从单层 LLM(F1=0.772)出发,叠加三层防御后样本级 F1=0.984 / 规则级 F1=0.952。每层独立可开关,便于回归测试与成本控制。

4.1 演进路径

样本级 F1("是否违规"二分类)与规则级 F1("具体引哪条法规"精细判定)两层指标分别衡量。

run5 单层 LLM
F1 = 0.772
样本级 / 输入类型门(基线)
run6 + 第一层
F1 = 0.846
主判定 prompt 中立化(+0.074)
run7 + 第二层
F1 = 0.898
规则可证伪声明收紧(+0.052)
run9 + 第三层
样本级 F1 = 1.0
复核 LLM 二审(40 样本基线)
current(50 样本 + prompt 修补 + GT 重审)
样本级 F1 = 0.984
规则级 F1 = 0.952
A 组 10 新样本 + 6 条规则 prompt 边界澄清 + 54 条 GT 扩标修正

4.2 各层职责

L1
主判定 prompt 中立化
FAIL 三必要条件(引文对齐 + 上下文消除歧义 + 不落入误判模式)+ 6 类"不该判违规"模式(宣传性形容词配兜底声明 / 本机构品牌名 / 行业标准术语 / 跨险种条款混淆 / 行业公开数据 / 海报缺披露字段)
L2
规则可证伪声明
8 条高频误判规则的可证伪声明采用"违规必须同时满足 (1)(2)…;排除(→ 合规):…"格式,模型按必要条件清单逐项打勾
L3
复核 LLM 二审
仅对一审"违规"触发;三项独立检验(引文是否对齐 / 上下文是否有限定语 / 是否落入 6 类误判模式);按决策表 confirm / 降级复核 / 降级合规

成本:仅一审 1.0x → 一审 + 复核 1.25-1.30x

4.3 第二层与第三层的耦合关系

第二层的"必要条件 + 显式 PASS 排除"清单同时被一审 prompt 与复核 prompt 引用——这是两个层的关键耦合:

同一份清单的两次使用
一审用必要条件做判定:模型按必要条件清单逐项打勾,全部满足才输出 FAIL
复核同一份排除清单做二审:检查一审 FAIL 时是否漏看了 falsifiability 的 PASS 排除项
实测某海报样本复核理由直接引用 "R007 明确排除'卷王'等口语化营销词(若无具体排名暗示且无对比对象)"——第二层和第三层是"必要条件清单"在一审 + 二审两次使用的设计闭环。

五、效果评估

50 样本测试集 / 5 类违规 × 3 模态 × 3 置信度梯度 / 样本级 F1=0.984 (1 FP) / 规则级 F1=0.952 (4 FP / 11 FN)

5.1 测试集构造

维度内容
测试集规模50 条样本(31 真实违规 + 19 合规对照;含 A 组 10 条针对原规则覆盖缺口设计的新样本)
数据来源KC seed 真实违规样本 + 真实保险公司海报 OCR + 边界合规对照 + HSBC 真实产品宣传册 document 样本
标注方式人工逐条标注 (是否合规, 期望违规规则, 必须命中短语) 四元组;GT 经过两轮反向审计(按 pipeline FP 反查样本原文,确认 LLM 命中的"溢出违规"实为真违规)
覆盖维度5 类核心违规类型 × 3 种输入模态 × 3 档置信度梯度

5.2 评估指标体系

核心指标按业务重要性排序样本级 F1 衡量"整篇内容是否需要复核"二分类;规则级 F1 衡量 pipeline 在每条规则上"具体引哪条法规、定哪种性质违规"的精细判定能力。

指标业务含义目标实测(current, 50 样本)
样本级漏报率违规样本漏拦 → 监管处罚风险≤ 5%0%(31 真违规 / 0 漏报)
样本级 F1"整篇内容是否需要复核"二分类≥ 0.950.984
30 TP / 1 FP / 19 TN / 0 FN
规则级 F1(主动违规类)"具体引哪条法规"精细判定≥ 0.850.909
135 TP / 1 FP / 26 FN(A 主链路 critic+RAG)
条文引用准确率合规系统不可让步线100%100%(catalog 化结构性保证,rule_id → source_clause 关联编码进规则数据)
单次审核延迟用户等待时间< 10s 纯文本~22s 主判定 + ~10s 叙事
两层 F1 差异说明:样本级聚合逻辑是"任意一条规则 FAIL → 整体违规",违规样本只要 pipeline 在任一规则上判对,样本结论就对。规则级 F1 反映对每条规则的精细判定能力——直接关系到客户报告里"引用哪条法规"的准确率。

5.3 A/B/C/D Ablation 实验(2×2 critic × RAG 矩阵)

同一测试集 50 样本 / 同一 GT / 同一 prompt,仅切换 criticRAG 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 调用73511207351120
LLM critic 调用1900
样本级(整篇内容是否需要复核)
TP / FP / TN / FN30/1/19/030/1/19/030/6/14/030/6/14/0
Precision0.9680.9680.8330.833
Recall1.0001.0001.0001.000
F10.9840.9840.9090.909
规则级(具体引哪条法规,剔除披露类)
TP / FP / FN135/1/26143/6/18137/16/24151/27/10
Precision0.9930.9600.8950.848
Recall0.8390.8880.8510.938
F10.9090.9230.8730.891

5.3.1 critic 净效应(A vs B / C vs D)

规则级 FP(RAG-on)
16
1(-94%)
规则级 FP(RAG-off)
27
6(-78%)
样本级 F1
0.909
+0.075

critic 是规则级 FP 镇压器,跨 RAG 状态稳定拦下 70-94% 误判。这是它的核心价值——错引法规在合规系统里是不可接受的失败模式。

5.3.2 RAG 净效应(A vs C / B vs D)

LLM judge 调用
1120
735(-34%)
样本级 F1
0.984
0.984(持平)
规则级 F1
0.923
0.909(-0.014)

RAG 是成本/精度的工程权衡:省 34% LLM 调用,代价是规则级 Recall 轻微下降。详见 ADR-0004

5.3.3 完整 stack 累积收益(D → A)

样本级 F1
0.909
0.984
规则级 FP
27
1(-96%)
LLM judge 调用
1120
735(-34%)
关键洞察
  1. catalog 化能直接达到 100% 条文引用准确率——抽取期已把规则与法规条款的关联编码进 source.source_chunk_ids,运行期不存在"引文召回错误"的可能
  2. critic 的收益(FP 镇压)和 RAG 的收益(成本节约)不冲突,是互补的两层改造
  3. 如果纯追求规则级 F1 上限,C 配置(critic + no-RAG)= 0.923 是最高的,比 A 高 +0.014;但 C 多 34% LLM 调用。主链路选 A 是成本优化的最佳点

六、关键设计取舍

两类核心决策都集中在"规则生成"和"运行期过滤"阶段——这是合规审核系统能否被审计部接受的工程根基。

决策选择取舍理由
检索方法论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)+ 信息冗余
编排框架自写工作流,不用 LangGraph6 步线性 + 1 个简单分支,套框架是过度工程,自写 < 300 行
模式选择工作流(Workflow),不用 Agent合规审核要求可重现可审计,Agent 自由决策权在此是负价值
切片策略按章 / 节 / 条 / 款层次切,不用固定窗口监管条文是原子化判据,固定窗口会切断条款
复核节点LLM 二审而非纯规则纯规则覆盖不全,LLM 复核能捕捉"证据不足"与"过度判定"两类错误

七、从 PoC 到生产的演进路径

本期交付落在前 3 阶段,第 4 阶段「蒸馏」是后续关键转折。每阶段成本结构与触发条件预先约定,避免 PoC 直接当生产用的常见反模式。

阶段核心动作成本结构本期 PoC
① 规则建库监管文档 → 原子规则 + 关系图编码SOTA 一次性投入✓ 已交付
② 审核流水线规则适用过滤 + 主判定 + 复核SOTA 按调用计费✓ 已交付
③ 离线评估测试集 + 准确率 + bad case 分析SOTA + 人工标注✓ 轻量版
蒸馏(关键转折)SOTA 判定逻辑下沉到小模型 + 代码规则单条成本 ↓ 5–10×后置
⑤ 量产质控生产流量按置信度抽样、人工复核Worker 跑量 + SOTA 抽查后置
⑥ 收敛交付规则库版本化、覆盖率报告、监控仪表板持续维护后置

蒸馏触发阈值与三档下沉

PoC 阶段直接用 SOTA 模型跑全量判定是合理选择——开发效率高、可解释性好。触发蒸馏的临界点:日均审核量到 10 万条/日以上时,单条 SOTA 调用成本累积超过监管罚款的风险价值,三档下沉是性价比拐点。

D1
文本规则匹配
关键词字典 + 词表,不调 LLM —— 适用于"不得使用'最好''第一'"等显式禁词类规则
D2
模式可识别判定
蒸馏后的小模型(7B / 14B)+ 结构化 prompt —— 适用于"披露字段是否齐全"等模式较固定的规则
D3
边界判断
仍保留 SOTA —— 适用于"是否构成实质性误导"等需上下文理解的边界 case
PoC 阶段的工程克制:本期不引入蒸馏框架、微调流水线、小模型部署设施——这些是生产阶段的工程负担,过早投入会拖慢演示节奏并掩盖 PoC 的真正目的(验证判定逻辑可行性)。前置约定演进阶段的意义是让客户看到「成本可控的分阶段演进」,而非「PoC 演完后另起炉灶」。

接入扩展(v1/v2 之上的演进形态)

三种入口共享同一判定后端,不影响判定逻辑本身:

A
IM 即时反馈
飞书 / 钉钉 / 企微
营销人员在群里发草稿
秒级合规反馈
B
Web 审核员后台
合规团队入口
看决策详情、复核、维护规则库
C
发布平台 API
系统级拦截
发布前调用,违规直接拒绝