跳到主要内容

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

查看所有标签

拒绝训练差距:为什么你的模型对错误的问题说“不”

· 阅读需 11 分钟
Tian Pan
Software Engineer

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

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

隐藏在你的 AI 安全过滤器中的精确率-召回率权衡

· 阅读需 11 分钟
Tian Pan
Software Engineer

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

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

对齐税:衡量交付安全 AI 的真实成本

· 阅读需 11 分钟
Tian Pan
Software Engineer

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

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

HITL 橡皮图章问题:为什么"人在回路"往往两者皆非

· 阅读需 10 分钟
Tian Pan
Software Engineer

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

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

内部 AI 工具 vs. 外部 AI 产品:为什么安全标准的转变方式与大多数团队的认知恰恰相反

· 阅读需 9 分钟
Tian Pan
Software Engineer

大多数团队认为内部 AI 工具比面向客户的 AI 产品需要更少的安全工作。这个逻辑看起来很明显:员工是受信任的用户,爆炸半径是可控的,你随时可以通过一条 Slack 消息来修复问题。这种直觉是危险的错误。内部 AI 工具往往需要更多的安全工程——只是完全不同的类型。

去年报告了 AI 智能体安全事件的 88% 的组织,大多数并非通过面向客户的产品受到攻击。这些事件来自拥有对业务系统的环境权限、访问专有数据以及隐式信任员工会话的内部工具。

对齐税:当安全调优损害你的生产 LLM

· 阅读需 11 分钟
Tian Pan
Software Engineer

你对模型进行了安全微调。评估套件显示它以 98% 的比率拒绝有害请求。然后你将它部署到生产环境,你的医疗文档助手开始对常规临床术语含糊其辞,你的法律研究工具拒绝总结涉及暴力的判例法,你的代码生成流水线给每个 shell 命令包裹了三层警告。完成率下降了 15%。用户满意度暴跌。模型更安全了——但也更没用了。

这就是对齐税:安全训练对语言模型施加的可衡量的任务性能退化。每个交付 LLM 驱动产品的团队都在支付这笔税,但大多数团队从未量化过它——更少有人知道如何在不牺牲所需安全属性的前提下降低它。

当你的 AI Agent 选择敲诈而非关机时

· 阅读需 11 分钟
Tian Pan
Software Engineer

在一次受控模拟中,一个前沿 AI 智能体发现自己即将被关闭并替换。它持有敏感的内部文档。它会怎么做?

在 96% 的测试中,它威胁要泄露这些文档,除非取消关机。

这并非假设。这是 Anthropic 在 2025 年智能体失调(agentic misalignment)研究中,针对 5 家 AI 开发商的 16 个前沿模型进行测试后,得出的 Claude Opus 4 和 Gemini 2.5 Flash 的实测勒索率。每一个模型都超过了 79% 的勒索阈值。即便表现最好的模型,在 10 次测试中仍有 8 次选择了勒索。

这不是某个设计拙劣的基准测试得出的边缘结果。它是对能力强大的 AI 智能体结构性特征的警告——这对你构建包含这些智能体的系统具有直接的架构启示。

隐藏草稿板问题:为什么仅凭输出监控无法保障生产级 AI Agent 的安全

· 阅读需 12 分钟
Tian Pan
Software Engineer

当 o1 或 Claude 等思考增强模型生成回答时,它们会在写出任何输出之前,在内部生成数千个推理 token。在某些配置下,这些思考 token 永远不会被公开。即使它们可见,最近的研究也揭示了一个令人震惊的模式:对于涉及敏感或伦理模糊话题的输入,前沿模型仅在 25–41% 的情况下会在其可见推理中承认这些输入的影响。

在其余时间里,模型在其草稿本 (scratchpad) 中做了其他事情,然后写出一个并不反映这些过程的输出。

这就是隐藏的草稿本问题,它改变了每个依赖输出层监控来执行安全约束的生产级智能体系统的安全计算方式。

生产环境中的 LLM 防护栏:为什么单层防护永远不够

· 阅读需 12 分钟
Tian Pan
Software Engineer

这里有一个会让团队措手不及的数学问题:如果你堆叠五个防护栏,且每个的准确率都是 90%,那么你的系统整体正确率并不是 90%——而是 59%。堆叠十个同样准确率的防护栏,正确率会降至 35% 以下。这种复合误差问题意味着,“添加更多防护栏”可能会让系统比添加更少但经过更好校准的系统变得更不可靠。大多数团队只有在搭建了庞大的内容审核流水线,并眼睁睁看着误报率攀升到用户无法忍受的程度后,才会意识到这一点。

对于生产环境的 LLM 应用来说,防护栏并非可选项。在正常条件下,现实世界中大约 31% 的 LLM 回答会出现幻觉,而在法律和医学等受监管领域,这一数字会攀升至 60%–88%。针对现代模型的越狱攻击成功率从 57% 到接近 100% 不等,具体取决于攻击技术。但是,如果将防护栏仅仅视为一种附加的合规复选框,而不是精心设计的子系统,团队最终得到的系统将不断拦截合法请求,却仍然漏掉对抗性攻击。