7 篇博文 含有标签「guardrails」

第一次验证器捕捉到糟糕的 LLM 输出时，感觉像是一场胜利。第二次，你会调整提示词以降低失败的可能性。到第二十次时，团队中没人能解释为什么提示词中存在那三个段落 —— 它们是早已被遗忘的事故留下的瘢痕组织，而模型在阅读警告上花费的 Token 比推理实际任务还要多。

这就是验证器陷阱。你添加的每一个事后防护（post-hoc guard）—— JSON 模式检查、正则表达式、内容分类器、第二个作为裁判的 LLM —— 都会对上游提示词施加反馈压力。提示词会增加防御性指令来安抚验证器，验证器反过来又会捕捉到一类新的失败，接着你又会添加更多指令。每一次迭代在局部看来都是合理且明智的。但总体而言，系统变得越来越慢、越来越贵，而且在原本设计的任务上的表现也明显变差了。

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

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

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

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

大多数团队引入护栏的方式，和引入日志一样随意：直接挂上去，以为代价很小，然后继续往下走。但代价并不小。一次内容审核检查要花 10–50ms，再加上 PII 检测，又是 20–80ms；再叠上输出 schema 校验和毒性分类器，在第一个 token 到达用户之前，串行开销就已累积到 200–400ms。加上 500ms 的模型响应，你那个"快速"的 AI 功能现在给人的感觉就是迟钝。

把锅甩给 LLM 是错的。护栏才是瓶颈。解决方案不是去掉安全措施，而是停止把安全检查当成一堆无差别的任务，改用架构思维来对待它。

在 2025 年，工程组织的运维琐事上升到了 30% —— 这是五年来的首次增长 —— 尽管在 AI 工具上的投入创下了纪录。原因并非 AI 失败了。原因在于团队部署 AI Agent 时，并没有采用像对待人类值班工程师那样严格的标准：没有 Runbook，没有升级路径，没有影响范围（Blast-radius）限制。Agent 可以对日志进行推理，但没有人告诉它它被允许做什么。

“能够诊断的 AI”与“能够安全缓解故障的 AI”之间的差距，并不是模型能力问题。这是一个系统工程问题。解决这个问题需要 SRE 团队已经应用在人类操作员身上的同样纪律：结构化的 Runbook、分层权限和强制性的升级点。

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

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

大多数团队在发布他们的第一个 LLM 功能后，会在生产环境中因糟糕的输出而受挫，然后紧急加上护栏进行损害控制。结果是一个脆弱的系统，它会阻止合法的请求，减慢响应速度，并且在关键的边缘情况下仍然失效。护栏值得做好——但天真的方法会以你意想不到的方式伤害你。

以下是实际的权衡取舍，以及如何构建一个不会悄悄破坏你产品的护栏层。