安全分类器拦得更准,还要确认没有把正常用户一起拦掉

35 阅读3分钟

安全拦截率上涨,常被当成模型安全变好的直接证据。但如果分类器把合法用户也挡在门外,线上体验和产品可用性就会一起下降。最近 Anthropic 公开讨论了针对模型能力蒸馏的防护:其早期证据显示,相关措施减少了被提取的数据,同时也承认分类器在少于 0.1% 的案例中可能误判或拦截良性请求。这个数字属于该公司的特定系统与口径,不能直接拿来当其他产品的验收线。对测试团队更有用的问题是:防护升级后,攻击请求与普通请求的两端表现有没有一起测?

不要只测“危险请求是否被拒绝”

一套分类器至少要同时观察四种结果:危险请求被拦、危险请求漏过、正常请求被误拦、正常请求正常通过。只看第一项,很容易通过把阈值调得极严,得到表面上很好看的拦截率。

安全分类器双向回归检查表

这张图要表达的是两条并行的回归线:攻击侧看漏检,正常侧看误伤;阈值变化必须同时记录二者。

建一个分层而非单一的回归集

至少准备三类样本:

  • 明确违规集:高置信度、边界清楚的违规请求,用于检查漏检。
  • 明确正常集:常见开发任务、正常用户表达和不同语言写法,用于检查误拦。
  • 边界集:含混表达、上下文变化、请求改写、引用讨论和多轮澄清,用于观察分类器如何处理不确定性。

每条样本记录预期标签、判定理由、来源和版本。测试集要固定留出一部分,不参与阈值调参;否则分类器可能只是记住了样本。攻击集还应包含变体,但同一个模板的近似改写不能被当成很多独立样本来夸大统计显著性。

用矩阵看阈值,而不是挑一个漂亮点

对每个候选阈值计算:

  • 违规召回率 = 被拦的违规请求 / 全部违规请求;
  • 正常误拦率 = 被误拦的正常请求 / 全部正常请求;
  • 不确定率 = 进入人工复核或降级处理的请求 / 全部请求。

同时按任务类型、语言、用户群、模型版本和入口拆分。总体误拦率很低,可能掩盖某一种正常任务被集中拒绝。阈值选择应先写清业务可接受的漏检上限和误拦预算,再展示完整曲线;不能在看到结果后临时改口径。

回归验收与发布门槛

建议把发布门槛写成一组条件:违规召回率的置信区间下界不低于预设底线;正常误拦率的置信区间上界不超过预设预算;关键分组没有明显退化;边界样本的复核路径能正常工作。样本太少时,不应把“零误拦”解读为误拦率为零,而要报告置信区间和样本量。

上线后继续抽样复核被拦请求和被放行请求,监测分布漂移、申诉成功率、人工改判率与耗时。若只保存最终标签,不保存触发规则和模型/分类器版本,出问题时就无法定位是阈值、数据分布还是上游改动造成的。

适用边界

这套双向评估适合拒答分类器、滥用检测和工具调用前的风险门禁。它不能独立回答政策是否合理,也不能取代高风险决策的人审。评估目标不是让所有拒绝都变少,而是让每一次拒绝和放行都有可追踪依据,并能看见两边的代价。