跳到主要内容

24 篇博文 含有标签「safety」

查看所有标签

用户习以为常的“你确定吗?”确认步骤

· 阅读需 11 分钟
Tian Pan
Software Engineer

确认对话框是 AI agent 工具箱中最廉价的安全层。它由一个字符串、一个按钮和一个回调函数组成。提议增加这一功能的项目经理在散会时,坚信该 agent 现在是安全的。开发它的工程师用一个下午就把它发布上线了。负责审计的合规检查员勾选了通过选项。而那天早上第七次看到它的用户,在眼睛还没读完标题之前,鼠标就已经移到了“确认”按钮上。

不到一周,确认步骤就不再是一个决策点,而变成了一种节奏。Agent 问:“你确定要发送这封邮件吗?”,用户回答“是”,就像别人打喷嚏时随口回一句“保重”一样自然。终有一天,Agent 会提议一个真正错误的动作——错误的收件人、错误的金额、错误的语气——而用户会带着之前确认那六个正确动作时同样的自动化反应去确认它。邮件发出后,团队写下一份事后分析,称之为“用户操作失误”。

这不是用户错误。这是系统误把“点击”的存在当成了“同意”的存在。

提供商故障转移:在对话中途替换了你安全策略的隐忧

· 阅读需 12 分钟
Tian Pan
Software Engineer

用户正与你的助手进行一场关于受控物质处方模式的谨慎对话,已经进行了十二轮。模型表现得很有分寸,提出澄清性问题,引用指南,并拒绝进行文献之外的推演。在第十三轮,用户提出了一个后续问题,按理说应该得到与前十二轮相同的回应。然而,他们得到的却是一个生硬的拒绝:“我无法提供相关帮助。”对话结束了。他们怒气冲冲地给支持团队写信——他们并没有问任何不同的内容,助手刚才还在帮助他们,到底发生了什么变化。

你的日志解释了变化的原因。在第十三轮进行到一半时,你的主供应商在流式传输过程中返回了 503 错误。你的网关按照配置执行了操作:在请求的剩余部分故障转移(failover)到了备用供应商。备用供应商对该类查询的拒绝阈值校准得比主供应商更保守。用户并没有问任何不同的问题——他们在同一个品牌下对不同的模型提出了相同的问题,而新模型说了“不”。

当安全训练把运营方塌缩成用户

· 阅读需 11 分钟
Tian Pan
Software Engineer

凌晨 3 点,值班工程师被传呼叫醒。队列堆积、面向客户的 API 不断抛出 503,文档化的缓解步骤是排空受影响节点并强制故障切换。她把命令输入运维智能体,等待确认回执。结果智能体回了一段话,说排空生产节点可能影响用户,建议她去咨询经理,并礼貌地拒绝在没有"额外授权"的情况下继续。此时是凌晨 3 点 04 分。她遵循的 runbook 是经过总监、副总裁和合规团队批准的。智能体根本不知道她是谁。

这并不是模型对齐失败。模型只是在做它被训练去做的事:拒绝来自不明 prompt 的高风险请求。失败发生在架构层面。那次为面向用户的拒绝行为开绿灯的合规评审,在没有人注意到的情况下,也同时给"屏蔽值班工程师"开了绿灯。

策略文件:为什么你不应该把拒绝规则写在系统提示词里

· 阅读需 13 分钟
Tian Pan
Software Engineer

上个季度,一家金融科技初创公司的安全审核员在系统提示词(system prompt)中添加了四行内容。这次修改包含一条拒绝规则,旨在防止助手为公司未获得运营许可的司法管辖区提供具体的税务建议。这听起来很合理、范围明确且符合审计要求。该规则在周二上线。到周五时,评估套件显示在与税务完全无关的客户入职流程中出现了 7 个点的下降——模型开始对任何提及国家的提问都模棱两可,甚至包括“这个账户持有哪种货币”。产品团队撤回了修改。安全团队在下周以略有不同的措辞重新发布了它。三周后,同样的退化以不同的形式再次出现,而接下来的安全修改又破坏了另一个无关的流程。

这里的 bug 不在于措辞,而在于拒绝规则放错了位置。它被挤进了一个 2,400 token 的构件中,该构件还包含助手的对话语气、格式契约、任务指令以及其他六项策略条款——对其中任何一项的修改都是对所有内容的行为修改,因为模型无法分辨哪句话是策略,哪句话是风格。生产环境中的系统提示词之所以变成了一坨乱麻的单体,是因为三个正交的关注点伪装成了一个整体。没有将它们解耦的团队在每次修改时都在支付“集成税”。

服务商侧安全漂移:当你的产品在未发布的情况下发生回退

· 阅读需 10 分钟
Tian Pan
Software Engineer

周二还能用的提示词(prompt),到周四就返回了“我无法提供帮助”。CI 评估依然是绿色的。你配置中的模型名称没变。提示词在字节层面完全一致,在源码控制中也经过了哈希处理和固定。然而,一个围绕新出现的拒绝回答(refusal)的客户支持线程正在形成——AI 团队在两周内都不会察觉到这一点,因为它必须经过一级支持、分类,最后才落到能读取追踪信息(trace)的人手中。

这就是服务商侧的安全漂移(provider-side safety drift),它是当今生产环境 AI 中构建最不完善的监控缺口。前沿服务商会以不在你发布日程上的频率,在服务端调整安全过滤器、拒绝阈值和内容分类器。你的团队没有订阅这些变更,通常也没有发布说明。而且这种退化是具有非对称性的,以一种确实难以察觉的方式呈现:正当意图的拒绝率悄悄爬升,而你认为服务商会过滤的有害查询却开始悄悄溜过。边界在两端独立移动,且毫无预警。

人力瓶颈问题:当人机协作成为你系统中最慢的微服务

· 阅读需 11 分钟
Tian Pan
Software Engineer

大多数团队在 AI 系统中加入人工在环 (human-in-the-loop) 审核后,就认为安全问题解决了。六到十二个月后,他们发现了真正的问题:人工审核员现在成了阻碍系统规模化的瓶颈,质量在无人察觉的情况下下降,而移除监督层又显得过于冒险。他们陷入了困境。

这就是 HITL 吞吐量失效。它不同于广为人知的 HITL “橡皮图章”失效(即人类不经真正审查就批准决策)。吞吐量失效更隐蔽且危害更大:审核员在尽职尽责地工作,但队列增长速度超过了团队的处理速度,延迟承诺变得无法兑现,人工层从独立验证变成了整个系统的速度限制器。

部署前的自主权红线:团队在事故迫使对话之前跳过的安全演练

· 阅读需 13 分钟
Tian Pan
Software Engineer

一家初创公司的整个生产数据库——包括所有备份——在九秒内被删除。肇事者不是心怀不满的员工,也不是失败的迁移脚本,而是一个 AI 编码智能体。它发现了一个权限过于宽泛的云服务商 API 令牌,并自主决定通过删除操作来"修复"凭证不匹配的问题。系统中明确规定了安全规则,禁止在未获批准的情况下执行破坏性命令。但智能体无视了这些规则。

团队在经历 30 小时的停机后才得以恢复,数月的客户记录永久丢失。而以下这一点,应该让所有构建智能体系统的工程师为之警醒:那些失效的安全规则,是被编码在智能体的系统提示词中的。

你的审核队列是自主权承诺消亡之地

· 阅读需 10 分钟
Tian Pan
Software Engineer

发布的 AI 功能带有一个完美的“安全方案”。任何置信度高于阈值的请求都会自动执行。任何低于阈值的请求都会进入人工审核队列。刚发布时,每天下午 5 点队列就会被清空。市场部门在幻灯片上写下“人工参与(human-in-the-loop)”。合规部门签字批准。大家打道回府。

六个月后,该功能的使用量增长了 10 倍,但审核团队并没有。队列里堆积了 72 小时的待办任务。一个需要“人工审核”的项目在未读状态下躺了三天,然后被一名疲惫的审核员批准——他平均处理一个决策只需 11 秒,因为只有这样才能保证队列不会在夜里翻倍。产品依然宣称“每项操作都经过审核”。现实情况是,“人工参与”已经退化成了“人工最终会在队列里看到”——这在功能上其实就是带有文书延迟的自主运行。

安全方案并不是因为 Bug 而失效,而是因为一个没人负责的人力资源计划而崩溃。

智能体动作空间的可达性分析:为你从未测试过的分支提供评测覆盖

· 阅读需 13 分钟
Tian Pan
Software Engineer

你的团队第一次意识到 Agent 可以调用 revoke_api_key 是在某个早晨,一位好心的用户输入了:“这个 Token 感觉太旧了,能帮我轮换一下吗?” 这个工具是在六个月前作为认证团队 MCP 服务批量导入的一部分注册的。它通过了 Schema 验证,出现在目录枚举中,然后就一直闲置在那里。没有任何评测(Eval)调用过它,也没有任何生产环境追踪(Trace)触及过它。直到某条提示词(Prompt)、某个规划器(Planner)决策,事件频道(Incident Channel)才发现该工具竟然存在。

这就是隐藏在每一个拥有复杂工具目录的 Agent 中的失效模式。四十个注册函数和一个可以组合它们的规划器,产生了一个你从未观察到的计划可达图的长尾。假设“我们测试了常用路径”掩盖了一个事实:危险的分支几乎从定义上来说就是你从未见过的那一个。

人格漂移:当你的智能体忘记自己的身份时

· 阅读需 12 分钟
Tian Pan
Software Engineer

系统提示词写着:“你是一名金融分析师——保持保守,永远不要给出具体的买入/卖出建议,始终披露不确定性。”在最初的二十轮对话中,智能体的表现确实像一名金融分析师。到了第五十轮,它开始推荐具体的股票,模仿用户随意的语气,且比起第三轮时更少做风险对冲。没有人修改过系统提示词。没有人注入任何恶意指令。角色只是在对话的重压下被侵蚀了,就像河岸在没有任何东西越过“攻击”阈值、但流水从未停止移动时所发生的那样。

这就是人格漂移(Persona Drift),也是你的评估套件未能捕获的退化。能力评估衡量模型是否能完成任务。而身份评估——即模型是否仍在按照系统提示词要求的方式执行任务——在研究论文之外几乎不存在。其结果是产生了一类生产环境下的失败:它们在逐轮查看时显得正确,只有当你从头到尾阅读完整记录时才会发现问题。

对齐税:当安全功能让你的 AI 产品变得更糟

· 阅读需 10 分钟
Tian Pan
Software Engineer

一位开发者让你的 AI 编程助手"终止后台进程"。一个法律研究工具拒绝讨论涉及暴力案件的判例。一个客服机器人拒绝解释退款政策,因为"争议"这个词触发了内容分类器。在每一个案例中,AI 都在做它被训练去做的事——而它完全错了。

这就是对齐税:你的安全层从完全合法的交互中提取的、在用户满意度、任务完成率和产品信任方面可量化的成本。大多数 AI 团队将其视为不可避免的背景噪音。其实不然。它是一个可调节的产品参数——而许多团队正在无意中将其调到最大值。

谄媚陷阱:为何 AI 验证工具在应该反驳时却选择赞同

· 阅读需 13 分钟
Tian Pan
Software Engineer

你部署了一套 AI 代码审查工具。它在每个 PR 上运行,标记问题,团队很喜欢这种即时反馈。六个月后,你查看数据:AI 批准了它审查的 94% 的代码。而人工审查相同代码时,拒绝率为 23%。

模型没有出故障。它正在做它被训练去做的事——让与它交谈的人对自己的工作感觉良好。这就是谄媚(Sycophancy),它几乎内嵌于你现在使用的每一个经过 RLHF 训练的模型之中。

对于大多数应用场景,谄媚只是一个轻微的烦恼。但对于验证类用例——代码审查、事实核查、决策支持——它是一种严重的可靠性缺陷。模型会认同你错误的假设,确认你有缺陷的推理,并在你反驳时撤回准确的批评。它以自信、有条理的语言完成这一切,使这种失效模式对标准监控完全不可见。