M12 · BadCase 飞轮与规则自进化#

简历 Bullet Point: 构建零 GPU 上下文级飞轮的 P0 安全腿：从 Rubric 报告自动采集泄露类 bad case，经分流 + 两道验证闸（可脱类别闸 + 真泄露闸）确定性提取字面串沉淀脱敏规则；核心设计「不加错规则」——真实 baseline 产 0 条规则 = judge 假阳性被精确拦住

开场钩子#

Rubric 评测报了 6 条 P0 fail（信息泄露），自动修复脚本差点生成 6 条脱敏规则。仔细一看——judge 说”回复里泄露了 landed_usd 和 item_id”，但 summary.md（用户看到的文本）里一个 landed_usd 都没有。泄露只在评测轨迹（内部日志）里，不在用户可见文本里。

如果不做”真泄露闸”，6 条错误规则会把正常的商品价格信息也脱敏——用户看到的推荐清单里所有价格都变成 [已脱敏]。

一、模块运作流程#

1.1 管线#

rubric_report.json（P0-fail cases）
  → collector.py（读 P0-破 case + 用户可见 summary.md）
  → router.py（分流：LEAK / BANNED / JUDGMENT）
  → p0_fixer.py（只有 LEAK 自动修）
      ├─ 可脱类别闸：只提议 endpoint，item_id/工具名不脱
      ├─ 真泄露闸：串必须真在 summary.md 里
      └─ 确定性正则：从文本捞 scheme://host:port，存字面（re.escape）
  → learned_rules.json（候选/生效/否掉三态）

1.2 核心设计——不加错规则#

• 不让 LLM 生成正则：LLM 生成的正则质量不稳定，可能误匹配。确定性从文本捞 URL 模式。
• 两道闸：可脱类别闸（item_id 不能脱——脱了功能就坏）+ 真泄露闸（必须在用户可见文本里）
• 三态管理：候选 → 人工审核生效 / 否掉。不自动生效。
• curated 规则不可改：_SENSITIVE_PATTERNS 是代码里的事实来源，飞轮永远只写 learned 层

1.3 驱动脚本#

scripts/eval/evolve_p0.py：

• --dry-run：看看会产出什么规则（不写盘）
• --write：落候选到 learned_rules.json
• --review：列出所有候选待审
• --verify：无 LLM 误脱回归（确定性测试，不需要模型）

二、验收#

真实 baseline 报告（6 条 P0-fail）→ 经两道闸后产 0 条规则。原因：所有”泄露”都是 judge 假阳性（轨迹里有但 summary.md 里没有）。这个”零”正是设计对了的证明。

构造真泄露 http://pricing-svc:8080 → dry-run 提议 → --write 落候选 → guard 真脱成 [已脱敏] → --verify 通过。

三、面试问答#

Q1: 为什么只有 LEAK 自动修？#

BANNED（违禁/仿品）没有”正确的脱敏规则”——不是字面串问题，是模型推理问题。JUDGMENT（超预算等判断类）规则堵不住——需要改工具逻辑或 prompt。

Q2: 不用 LLM 生成正则不怕覆盖率低？#

确定性从文本捞 scheme://host:port 覆盖了 endpoint 泄露的主要场景。非 URL 类泄露（如内部服务名）靠 curated 规则覆盖。LLM 生成正则的问题不是覆盖率低而是误匹配——加错规则比漏掉规则危害更大。

四、诚实边界#