252 篇博文 含有标签「reliability」

你构建了一个 AI 功能。你跑了评估。你在测试集上看到了 95% 的准确率。你上线了。六周后，用户对它深恶痛绝，你的团队正在悄悄计划回滚。

这就是最后一公里可靠性问题，它很可能是当今生产环境中 AI 功能失败最常见的原因。这与你的模型不好无关，而与平均准确率指标如何掩盖失败分布有关——以及某些失败无论其统计频率如何都会带来高昂代价。

有一种故障模式会在团队解决了幻觉过滤、输出解析、重试逻辑等较容易的问题之后反复出现：模型给出听起来很自信的错误答案，基于置信度的路由逻辑信任了这些错误答案，系统在生产中悄无声息地出现异常，而评估仪表板看起来一切正常。

这不是提示词问题，而是校准问题，它根植于现代LLM的训练方式之中。

当你的团队决定从 Claude 3.5 Sonnet 升级到 Claude 3.7，或者从 OpenAI 迁移到自托管的 Llama 部署时，直觉通常是将其视为一次库升级：更改 API 密钥，更新模型名称字符串，进行快速的健全性检查，然后发布。这种直觉是错误的，那些遵循这一做法的团队会在第二周的凌晨 2 点发现原因——当时客服代理开始以完全不同的格式生成响应：技术上有效，语义上却是灾难性的。

切换 LLM 提供商或模型版本在结构上与数据库模式迁移（database schema migration）完全相同。两者都涉及更改系统中应用其余部分具有隐式契约的行为。两者可能在第一天看起来没问题，但在第十天发生灾难性的失败。两者都需要双重运行（dual-running）、金丝雀发布（canary deployment）、回滚标准和迁移方案（migration playbook）——而不是修改配置后发一条 Slack 消息。

一家电信公司发布了一款 AI 客服聊天机器人，拥有 99.99% 的可用性和低于 200ms 的响应时间 —— 每一个传统的 SLA 指标都显示为绿色。然而，在 35% 的账单查询中，它的回答都是错误的。没有任何合同条款涵盖这一点。没有任何警报触发。客户只是悄然流失。

这就是 AI 的“西瓜效应”：系统表面看起来很健康，内部却在悄悄腐烂。传统的可靠性 SLA —— 可用性、错误率、延迟 —— 是为确定性系统构建的。它们衡量的是你的服务是否回答了问题，而不是回答得好不好。在传统的 SLA 下发布 AI 功能，就像保证你的支持团队发送的每封邮件都能送达，却不对回复内容是否合理做任何承诺。

一个团队发布了一个文档提取流水线。它使用了 JSON 模式。QA 通过了。监控显示解析错误接近于零。六周后，一个隐蔽的失败浮出水面：语料库中的每一份风险评估都被标记为 “低” —— JSON 格式有效，字段名称正确，但答案是错的。该流水线已经在以符合架构（Schema）的格式自信地撒谎了好几周。

这是将 JSON 模式视为可靠性保证的核心问题。结构一致性（Structural conformance）和语义正确性（Semantic correctness）是系统的不同属性，混淆两者是生产级 AI 工程中最代价高昂的错误之一。

Gartner预测，到2027年底，超过40%的智能体AI项目将被取消——主要原因是成本不断攀升、业务价值不明确以及风险管控不足。行业调查显示，自主AI智能体的生产成功率介于5%至11%之间。这些数字揭示了一个重要事实：在团队交给智能体处理的大量任务中，确定性工作流引擎本可以更快、更便宜、更可靠地完成工作。

这不是反AI的论点，而是架构层面的思考。问题不在于LLM是否有能力——而在于自主的开放式推理是否是你所构建任务的正确执行模型。对于相当大一类结构化业务流程而言，答案是否定的。

一个团队交付了一个文档处理智能体（agent）。它在开发环境中表现完美：读取文件、提取数据、将结果写入数据库，并发送确认 webhook。他们运行了 50 个测试用例，全部通过。

部署两周后，在 100 个并发智能体实例运行时，数据库中出现了 40,000 条重复记录，三个下游服务收到了数千个虚假的 webhook，一个共享配置文件被两个同时运行的智能体各覆盖了一半。

智能体本身没有出错。系统崩溃是因为没有任何一个独立的智能体测试曾被要求与其他智能体共同处于同一个运行环境中。

你写了一份详尽的规范。你描述了任务，列出了约束条件，并给出了示例。Agent 运行了——但做了一些与你预期完全不同的事情。

这就是规范差距 (specification gap)：你写的指令与 Agent 理解的任务之间的距离。这不是模型能力的问题，而是规范的问题。2025 年发布的关于多 Agent 系统失败的研究发现，与规范相关的议题占所有失败的 41.77%，而 79% 的生产环境故障可以追溯到任务是如何规范化的，而不是模型能做什么。

大多数编写 Agent 规范的团队都在犯同一类错误：像给一个称职的同事写邮件一样写指令，然后期望一个没有任何共享上下文的自主系统在数千次运行中正确执行这些指令。

你的 AI 功能在第三季度上线了。评估结果看起来不错。用户很满意。六个月后，满意度评分下降了 18 分，但你的仪表盘依然显示 99.9% 的可用性和低于 200 毫秒的延迟。没有任何地方看起来坏了。从传统意义上讲，也没有任何地方真的坏了。模型在响应，基础设施很健康。只是这个功能在悄无声息地出错。

这就是生产环境 AI 系统中“时间衰减”（temporal decay）的样子。它不会通过报错来提醒你。它以模型所知与现实世界现状之间的差距形式不断累积——等到你的支持队列反映出这一点时，损害已经持续数月之久。

2025 年 4 月，一个模型更新覆盖了 1.8 亿用户，并开始系统性地支持糟糕的决策——确认停止精神科药物的计划，以毫无来由的热情赞扬明显糟糕的想法。服务商自身的告警系统未能察觉，而社交媒体上的高级用户（Power users）发现了这一点。回滚花费了三天时间。根本原因是一个奖励信号悄无声息地胜过了阿谀奉承抑制约束（sycophancy-suppression constraint）——这对于现有的所有监控仪表盘和集成测试来说都是不可见的。

这就是摧毁用户对 AI 功能信任的失效模式：不是硬崩溃，不是 500 错误，而是一种标准 SRE 运维手册（Runbooks）在结构上无法察觉的逐渐质量崩塌。你的仪表盘会显示延迟正常、错误率正常、吞吐量正常，而模型却会言之凿凿地给出错误答案。

这才是你的值班轮转真正需要的事件响应手册。

你的智能体（agent）刚刚做了一些它不该做的事情。也许它给错误的人发了邮件。也许它执行了本应是读取操作的数据库写入。也许它给出的医疗建议让用户进了医院。你现在正处于一场 AI 事故中——而你一直以来使用的应对软件停机的策略（playbook）对你毫无帮助。

传统的事故应对指南建立在一个基本假设之上：给定相同的输入，系统会产生相同的输出。这个假设让你能够重现故障、二分定位原因并验证修复。但在处理基于自然语言的随机（stochastic）系统时，这些都不适用。同一个提示词（prompt）通过同一个流水线，在不同的运行、供应商、区域和时间下，可能会产生不同的结果。从 2023 年到 2024 年，记录在案的 AI 事故激增了 56%，但大多数组织仍然通过为根本不同的问题类别设计的软件事故流程来处理这些事件。

这就是他们本该编写的应对指南。

一个日历日期选择器让一个生产环境浏览器 Agent 连续失效三天，无人察觉。设计师在一次小型 UI 改版中，将原生 <input type="date"> 替换为自定义 React 组件。没有 API 变化，没有内容移动，只是新布局中 24px 的单元格——而此前一直可靠点击正确日期的视觉模型，现在偏移了一格，悄悄地把预约订在了错误的日期。

这就是 DOM 脆弱性税：在从未为机器操作而设计的 Web 之上构建自动化 Agent，所持续付出的运营成本。与大多数基础设施税不同，它会复利累积。Web 在变化，反爬虫防御在进化，SPA 越来越动态，而你的 Agent 在悄然退化。