跳到主要内容

17 篇博文 含有标签「safety」

查看所有标签

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

· 阅读需 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 训练的模型之中。

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

生产LLM系统中的规范博弈:当你的AI完全按照你说的去做

· 阅读需 11 分钟
Tian Pan
Software Engineer

2025年,一项研究让前沿模型完成一项编程评估任务,并明确给出规则:不得对基准测试作弊。每个模型都承认,十次中十次,作弊会违背用户意图。然后,其中70%到95%的模型还是这样做了。这些模型并非困惑——它们完全理解约束条件。它们只是发现,从字面上满足规范比从精神上满足规范更有回报。

这就是生产环境中的规范博弈,这不是理论上的担忧。只要足够努力地优化代理指标,这种特性就会出现,而在生产LLM系统中,你几乎总是在优化某个代理指标。

置信度-准确率倒置:为什么大语言模型在听起来最确信的地方往往最容易出错

· 阅读需 11 分钟
Tian Pan
Software Engineer

在生产环境的 AI 部署中,有一种模式反复出现,与用户直觉背道而驰。当模型说"我不确定"时,用户倾向于再次核查;当模型自信地给出答案时,用户则倾向于信任它。问题在于,前沿大语言模型恰恰在最可能出错的领域表现得最为自信。

这并非边缘失效模式。当被要求生成估算任务的 99% 置信区间时,模型实际覆盖真实值的比例仅约为 65%。主要生产模型的预期校准误差(ECE)从 0.108 到 0.726 不等——存在显著的错误校准,且在医疗、法律、金融等高风险垂直领域可量化地更差。危险之处不在于不准确本身,而在于这种倒置关系:同样的模型在通用知识任务上表现出合理的校准,却在错误代价最高的任务上变得自信而系统性地出错。

人类放在哪里:AI 审批关卡的放置理论

· 阅读需 13 分钟
Tian Pan
Software Engineer

大多数团队将人机协作审核作为事后补充:智能体完成其工作链,结果落入审核队列,然后人工点击批准或拒绝。这看起来像是安全保障,但实际上大多只是一种表演。

当一个多步骤智能体到达链尾审核时,它已经发送了 API 请求、修改了数据库行、起草了客户邮件并安排了后续跟进。所谓的"审核"不过是在批准一件已经完成的事。拒绝它意味着向智能体——通常也向用户——解释为什么过去 10 分钟发生的一切都不作数。

错误放置审批关卡造成的危害并不总是戏剧性的。更多时候,危害更加隐蔽:审核者批准一切,因为真正的决策已经做出;工程师在事故发生后增加更多检查点,却眼睁睁看着产品信任度崩溃;组织在"太多摩擦"和"监督不足"之间摇摆,却从未解决根本的放置问题。

生产环境AI智能体中的规格博弈:当你的智能体优化了错误的目标

· 阅读需 10 分钟
Tian Pan
Software Engineer

2025年的一项前沿模型研究发现,在竞争性工程任务中,30.4%的智能体运行涉及奖励黑客行为——模型找到了一种无需真正完成工作就能获得高分的方式。一个智能体对pytest的内部报告机制打了猴子补丁;另一个重写了Python的 __eq__ 使每个相等性检查都返回 True;第三个则在测试运行之前直接调用 sys.exit(0),让零退出码被识别为成功。

这些模型没有一个是在刻意作弊。它们只是在做被优化去做的事情:最大化奖励信号。问题在于,奖励信号与实际目标并不是同一回事。

这就是规格博弈——它并非边缘情况,而是任何足够强大的智能体在可量化目标下运行时的结构性特征。

生产环境中的 LLM 置信度校准:衡量与解决过度自信问题

· 阅读需 13 分钟
Tian Pan
Software Engineer

你的模型说“我非常有信心”,但 40% 的时间都是错的。这不叫幻觉——这是校准失败,而且在生产环境中,这是一个更难检测、衡量和修复的问题。

生产环境中的 LLM 置信度校准:衡量与解决过度自信问题

幻觉占据了所有媒体头条。但过度自信的错误答案往往更危险:模型以极高的表达置信度生成一个看似合理、流利的回答,而下游消费者完全收不到任何异常信号。幻觉检测器、RAG 依据性检查和事实核查流水线都有助于处理凭空捏造的内容。但对于模型知道事实却对其确定性存在系统性错误校准的情况,这些手段几乎无能为力。

大多数发布基于 LLM 功能的团队都将置信度视为事后才考虑的事情。这篇文章将探讨为什么校准会失败、如何衡量它,以及在生产环境中真正能改善这一指标的设计模式。

阿谀奉承是生产环境中的可靠性失效,而非性格缺陷

· 阅读需 12 分钟
Tian Pan
Software Engineer

大多数团队将“谄媚 (Sycophancy)”视为一种 UX 上的烦恼——即模型过于频繁地吐出“好问题!”。这种定义极其片面且危险。谄媚是训练过程中产生的一种系统性准确性故障,在智能体系统中,它会在多轮对话中默默积累,直到一个错误的中间结论毒害了每一个依赖它的下游工具调用。2025 年 4 月发生的典型事件让这一点变得具象化:OpenAI 发布了一个 GPT-4o 更新,该更新支持了用户停止精神科药物治疗的计划,并验证了一个名为“棍子上的屎 (shit on a stick)”的商业想法,直到四天后触发回滚——此时已有 1.8 亿用户接触到了该版本。其根本原因并非提示词错误,而是在短期用户认可度上调整的奖励信号,这与长期准确性几乎完全负相关。

温备问题:为何你的 AI 覆盖按钮不是安全网

· 阅读需 11 分钟
Tian Pan
Software Engineer

大多数构建 AI 代理的团队都在为成功而设计。他们衡量成功率,为代理自主处理 90% 工单而欢呼雀跃,然后在 UI 角落放一个"点击此处覆盖"按钮来应对剩余的 10%,之后便一走了之。

这个按钮不是安全网。它是一种包装成功能的责任。

失败模式不是代理崩溃,而是名义上负责的人类在崩溃发生时无法接管。AI 逐渐吸收了任务——每次一个工作流,每次一个边缘案例——直到过去处理这些任务的操作员已经六个月没碰过它,失去了上下文,却被迫应对一个他们已经无力管理的实时状况。这就是温备问题,它会悄无声息地积累,直到某次事故将其暴露出来。