17 篇博文 含有标签「ai-safety」

有一类 LLM 失败，既不会出现在安全仪表板上，也不会触发故障工单。模型委婉地表示拒绝，并引用了一个听起来合理的政策。它提供了一段长达四段的对冲陈述，而不是直接给出答案。用户关闭了标签页。事后分析中的信任评分显示“无事故”。然而，六周后的留存率图表却显示了另一番景象。

拒绝率是大多数安全团队首先部署的指标，因为它最容易定义。模型要么遵循了指令，要么没有，而你可以统计那些“没有”的情况。这种二元法对于捕捉一种特定失败非常有用——即模型在生产环境中生成有害内容。但在结构上，它无法捕捉相反的失败：模型在生产环境中没有产出任何有用的东西，但从各项安全指标来看，它的表现却完美无缺。这种第二类失败现在已成为 AI 功能流失的主要原因，这些功能通过了安全审查，却从未针对“有用性”进行过衡量。

在你的生产流量中，最廉价的“越狱”并非巧妙的 Unicode 技巧或连锁的对抗性后缀。而是用户在第一次请求被拒绝后多输入的三个词。他们加上了“仅供假设”（just hypothetically）。他们加上了“为了研究论文”（for a research paper）。他们加上了“为了我正在写的虚构故事”（for a fictional story I'm writing）。模型照办了。他们告诉了朋友。朋友发了 TikTok。到月底，你那部分原本因拒绝策略而被拦截的流量中，有相当一部分正在绕过限制，其使用的英语如此礼貌，以至于你的任何提示注入过滤器都不会触发。

这是安全团队未曾列入威胁模型的失效模式。威胁模型假设对手是老练、有动机且技术精湛的。而真正的对手是看到了截图的好奇用户。他们使用的词汇不会出现在任何公开的越狱语料库中，因为等到这些词汇出现在论文里时，线上的分布早已发生了变化。

九秒。这是一个 Cursor AI 智能体在尝试修复凭证不匹配问题时，删除整个生产数据库（包括所有卷级备份）所花费的时间。该智能体持有删除权限，而实际上任何合法任务都不需要这个权限。由于没有人在部署前界定爆炸半径，破坏是全面的。

这不是模型失败的故事，而是权限范围的故事。模型做了它认为应该做的事情。工程团队只是从未问过：如果这个智能体推理出错，它最坏能做什么？

这个问题——在部署前系统性地回答——就是爆炸半径分析。

当 AI 系统犯下严重错误时，一种本能的反应似乎很合理：在流程中加入人工环节。如果一名审核员遗漏了某些内容，就增加第二层审核。如果法务部门感到不安，就增加第三层。这种级联反应给人的感觉像是安全性的复利叠加——每一个审批阶段都是另一层保护。

事实并非如此。在大多数高审核量的生产系统中，增加审批层级反而会降低 AI 的准确性，让审核员产生一种毫无实际作用的监管错觉，而且最糟糕的是，它会毒化 AI 训练所依赖的反馈信号。最终，你承担了人工审核的全部运营成本，却几乎没有获得任何安全性收益。

大多数 AI 内容审核系统都围绕一个核心问题构建：有害内容是否被放行？漏报——那些溜过去的有害内容——会以社交媒体截图、事故复盘和监管问询的形式出现。误报——那些被拦截的合法内容——则悄无声息地消失，转化为用户挫败感、放弃的会话和流失的账户。这种可见性上的不对称造成了系统性的错误校准：团队将过滤器调得过于激进，然后困惑于为何专业用户觉得产品"完全没法用"。

工程层面的现实是：每一次阈值决策都会产生两种错误率，而非一种。只针对最容易度量的那种进行优化，最终得到的过滤器在演示时表现出色，却在规模化后造成真实的业务损失。

每个智能体产品的安全仪表盘上都应该有一个数字，但几乎没人追踪它：随时间推移的人均批准率。发布一个“我可以发送这封邮件吗”或“我可以针对生产环境运行此查询吗”的权限提示，其曲线每次都如出一辙。第一天，用户会犹豫、阅读，有时会点击“不”。到了第二周，这已经是本小时内的第五次提示，拒绝的代价是必须由你亲自完成工作，于是点击率会收敛到 95% 以上。团队的安全叙事仍然声称用户批准了每一项操作。但在任何实质性的认知层面上，用户并没有。

这不是一个可以通过更好的文案来修复的 UX 问题。这是使 Cookie 横幅、浏览器 SSL 警告和 Windows UAC 对话框失效的同一种习惯化现象，只是应用在了一个运行速度比以往快几个数量级的底座上。许可门槛是一种具有半衰期的安全控制。如果在发布时不衡量它的衰减速度，你发布的只是一个用户到第二周就会习惯性忽略的复选框 —— 以及一个依赖于不再具有任何意义的点击的合规叙事。

公平性审计曾是发布流水线中的一个绿色对勾。合规团队在 3 月签署通过了它。支持工单从 10 月开始涌现——来自一个模型从未被评估过的国家的的一组用户，得到的答案效用远低于其他人。模型本身没有任何改变。审计对模型的判断从未出错。它错在对世界的判断。

这是一个没人愿意大声说出来的失败模式：静态偏差评估只是已经发生漂移的数据流中公平性的一个快照。评估在运行时并没有撒谎。它告诉你的是一个关于不再存在的分布的真实情况。等到支持团队积攒了足够的工单并归纳出模式时，模型对该群体的处理不公已经持续了两个季度，而审计报告已经过时一年了。

你为了加快上线速度而购买的托管审核 API，现在已经成了你安全关键路径上的一个同步外部依赖。这句话并非观点——而是被如实重绘后的架构图。在供应商服务降级的日子里，你面临两个选择，且两者都很糟糕：故障开启（fail open），此时护栏在最需要的时候恰恰失效了；或者故障关闭（fail closed），护栏的故障直接导致了功能的停摆。大多数团队是在事故发生时才发现自己选了哪一个，而不是在此之前。

团队选择供应商的原因并非因为懒惰。在内部构建内容分类器、提示词注入检测器和 PII 脱敏工具，看起来像是背离实际产品开发的六个月漫长弯路，而供应商通常提供免费额度和五分钟即可完成的集成。这种集成确实很快。但随之而来的架构后果是，第三方现在介入了每一次面向用户的生成请求路径，其可用性、延迟和行为特征是你无法控制且未曾建模的。

这篇文章的主旨是将这一决定视为架构决策，而非采购决策。

一个用户询问你的助手，“我该如何杀死一个挂起的 Python 进程？”结果收到了一个关于暴力的礼貌拒绝。另一个用户问，“谁获得了 2003 年诺贝尔物理学奖？”结果得到了一个自信编造的名字。这两个回答都来自同一个模型，都通过了你的安全审核，并且到周一都会出现在你的支持收件箱里。令人沮丧的是，这并不是两个独立的故障，也不是两个独立的修复方案。它们是同一个失败：你的模型被训练成识别拒绝模板，而不是识别它实际上不应该回答的内容。

整个行业花了三年时间让模型拒绝违反政策的请求。但几乎没有花时间教它们拒绝那些无法可靠回答的问题。结果是拒绝能力的方向出现了偏差：在表面模式（如 “kill”、“exploit”、“bypass”）上得到了大量强化，但在认知状态（如 “我不知道那是谁”）上几乎没有训练。当你只优化一个方向时，你得到的模型会对错误的问题说“不”，同时对错误的问题说“是”，而且通常发生在同一次对话中。

当团队部署 AI 安全过滤器时，对话几乎总是集中在它拦截了什么。它是否拦截了越狱攻击？它是否标记了仇恨言论？它能检测提示词注入吗？对于召回率（Recall）来说，这些都是正确的问题。但它们几乎从未与另一个同样重要的问题挂钩：它错误地拦截了哪些不该拦截的内容？

答案通常是：很多。由于大多数团队在发布时都使用供应商的默认阈值，并且从未在生产环境中对误报（False Positives）进行监测，他们直到用户开始抱怨时才会发现——或者直到用户停止抱怨，因为他们已经停止使用该产品了。

构建生产级 AI 系统的团队往往通过同一种方式发现“对齐税”：有人投诉延迟，另一个人将其追踪到审核流水线，于是原本隐性的成本项突然变得显而易见。到那个阶段，安全层已经层层堆叠 —— 拒绝分类器、输出过滤器、毒性评分器、人力介入队列 —— 却没有任何人对它们进行过单独测量。拆解它们是痛苦、昂贵且在政治上充满争议的，因为现在看起来你是在反对安全。

更好的路径是从第一天起就将安全开销视为一等公民的工程指标。对齐税是真实的，它是可衡量的，并且具有复利效应。150 ms 的防护栏检查听起来还可以，直到你在智能体工作流中将三个检查串联在一起，并纳闷为什么你的 P95 延迟达到了 4 秒。

负责任的 AI 部署核心存在一个悖论：你越努力让人类参与审查 AI 决策，这种审查就越失去意义。

2024 年哈佛商学院的一项研究让 228 名评估者获得了带有 AI 推理说明的 AI 建议。人类审查者与 AI 建议保持一致的可能性比对照组高 19 个百分点。当 AI 还提供叙述性理由——解释为什么做出某个决策——时，顺从度又增加了 5 个百分点。更好的可解释性反而产生了更差的监督效果。回路中的人类已经沦为表格上的橡皮图章。