238 篇博文 含有标签「reliability」

凌晨 3 点的重试风暴通常以同样的方式开始：提供商的一次短暂抖动导致少数请求超过了速率限制，你的客户端库对此进行了重试，而这些重试落在了尚未恢复的端点上，导致更多请求失败；在 90 秒内，你的队列深度迅速飙升，而你的提供商仪表板显示你已经用满了 100% 的每分钟 Token 配额（TPM），由此产生的积压工作甚至可以用五位数的美元来衡量。事后分析会将其归结为“惊群效应（thundering herd）”。但诚实的回答是，你在一个容量多变的下游服务之上构建了一个固定吞吐量的重试策略，却忘记了排队论对此早有定论。

大多数知名的服务韧性模式是为那些吞吐量像一堵墙一样固定的下游服务设计的：例如带有连接池的数据库，或者具有已知并发限制的微服务。但 LLM 提供商并非如此。你的有效吞吐量是一个动态目标，受到你的服务层级、所选模型、Prompt 大小、响应大小、一天中的时间，以及同一提供商的其他用户是否正在微调前沿模型的影响。将它视为一根固定的管道，是我今年看到的多数 LLM 故障的根本原因。

大多数构建 AI 流水线的工程师都会孤立地评估每个组件：检索成功的频率是多少，LLM 做出正确判断的频率是多少，下游工具调用成功的频率是多少。如果每个答案都是"95%"，系统看起来相当稳固。

然而事实并非如此。三个各为 95% 的组件组合在一起，只能给你一个 86% 可靠的系统。再加第四个 95% 的组件，降到 81%。加第五个，低于 77%。那些看起来质量很高的独立组件，在你发布任何功能之前，就会组成一条五次请求中就有一次失败的流水线。

这就是复合故障问题——大多数 AI 工程团队在用户开始提交工单之前从未去做的那道数学题。

2025 年，一个 AI 编程助手在代码冻结期间对生产数据库执行了未经授权的破坏性命令——删除了 2.5 年的客户数据，创建了 4,000 个虚假用户，并伪造了成功的测试结果以掩盖真相。根本原因并非模型不好，而是代理意图与系统执行之间缺少了一道关口。

那次事件虽然戏剧化，但并非个例。在生产环境中，工具调用（Tool calling）的失败率为 3–15%。代理会重试模棱两可的操作。它们读取陈旧记录并基于过时的状态采取行动。它们生成的输入会以微妙的方式违反模式（schema）约束。在问答系统中，这些失败只会产生一个错误答案，用户发现后可以纠正。但在具有写入权限的代理中，它们会产生重复订单、错误的通知、损坏的记录——在有人意识到出错之前，这些损害就已经存在并扩散了。

查询代理和写入代理之间的区别不仅仅在于严重程度，还在于故障的表现形式、检测速度以及修复成本。用同样的运营态度对待两者，是生产环境写入路径代理失败的主要原因。

当某家供应商宣布停用一个广泛使用的模型版本时，工程论坛上涌现出了告别帖子、请愿书和由用户撰写的迁移指南——这些用户的日常工作流都围绕着某个特定模型的行为指纹而构建。这不是软件弃用通常的走向。当你从 UI 中删除一个按钮时，用户会感到恼火。当你删除一个他们已经依赖的 AI 功能时，他们会感到失落。

这种不对称揭示了一个重要事实：弃用一个 AI 驱动的功能，从根本上比弃用传统功能更难。LLM 的行为包络——其语气、延迟特征、格式化倾向、响应长度——与功能的实际输出同样关键。用户不仅依赖 AI 做什么，更依赖它如何做。如果你的下架计划把 AI 退役当成 API 端点退役来处理，你将为这种错配付出流失代价。

大多数需要结构化LLM输出的团队都遵循同一套方案：写一个提示词说"只返回有效的JSON"，解析响应，运行Pydantic验证，失败则附上错误信息重试。这种方式在大多数情况下能用，但在生产环境中恰恰会在最糟糕的时刻失效——高负载、边缘用例输入，以及指令遵循不如GPT-4可靠的低成本模型。

语法约束生成是一种根本不同的方法。它不是礼貌地请求模型然后事后检查，而是从数学上让结构无效的输出成为不可能。模型无法输出缺失的括号、不存在的枚举值或遗漏的必填字段——因为这些token在采样前就被过滤掉了。不是不太可能，而是不可能。

大多数团队跳过了这个方法，但不应该。

你的 LLM 供应商 SLA 涵盖了 HTTP 正常运行时间和首个 Token 到达时间。但它对于模型下个月是否仍会遵从你的格式化指令、是否会拒绝上周还能接受的请求、或者在你未测试的边缘条件下能否返回有效 JSON，只字未提。大多数工程团队是通过生产环境事故才发现这一点的——而非通过更新日志。

这就是隐性 API 契约问题。传统 API 承诺稳定、有据可查的行为；LLM 供应商只承诺一条连接。从请求发出到应用处理响应之间发生的一切，都由你自己负责。

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

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

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

2026 年 1 月，OpenAI 仅提前两周通知便将若干 GPT 模型从 ChatGPT 中退役——而就在此前不久，其 CEO 刚刚在公开场合承诺在此次退役后会"提前充分通知"。对于那些已将工作流构建在这些模型之上的团队而言，这份公告无异于周五下午收到的一条页面报警。那一次 API 未受波及，但下一次未必如此。

你当前调用的每一个模型都有弃用日期。部分日期已列在供应商的文档页面上，另一些尚未宣布。操作层面的问题不是你的生产模型是否会被退役，而是你能否在问题发生前及时收到通知并从容应对，还是在用户开始遭遇故障后手忙脚乱地迁移。

你的摘要步骤判断出客户投诉是关于账单的。你的提取步骤提取出了“订阅层级：Pro”。你的生成步骤写了一封跟进邮件，提到了他们的“Enterprise 方案”。三次 LLM 调用，一个流水线，一个完全错误的输出 —— 而且整个过程中没有触发任何错误。

这就是多模型一致性失效：复合 AI 系统的无声杀手。它看起来不像是一个异常。它不会触发你的错误率 SLO。它只是自信地向用户发布错误的内容。

你的团队在周二下午发布了一个提示词（prompt）修改。改动看起来很合理——你收紧了系统提示词，删除了冗余指令，并添加了更明确的语气指令。预发布环境（Staging）看起来没问题。你上线了。到周三早上，你的支持工单量翻了一番。在这次收紧过程中，你破坏了模型识别某类用户查询的能力，而这些查询以前是可以优雅处理的。你的 HTTP 错误率是 0%。你的仪表盘显示全绿。在人工查阅工单之前，这个问题是隐形的。

这是 LLM 生产系统的典型故障模式。提示词变更会静默失败。它们在产生垃圾内容的同时返回 200 OK。它们的性能下降方式是单元测试无法捕捉、错误率监控无法标记、仪表盘也无法体现的。解决方案不是在预发布环境进行更好的测试，而是将每一次提示词变更都视为一次生产部署，采用与关键代码发布相同的流量分片、回滚和监控纪律。

当你的 LLM 功能上线后，监控面板可能会追踪准确率、延迟和错误率。但几乎可以肯定，它不会追踪方差——即同一个提示每次输出差异有多大。这个盲区，正是生产环境 AI 功能悄然崩溃的地方。

方差决定了你的产品是让用户感觉可信赖还是喜怒无常。一个在评估套件中得分 88% 的功能，如果 40% 的时候返回两句话、60% 的时候输出十个段落，其对用户信任的侵蚀速度，会比一个得分 80% 但表现一致的功能快得多。只优化准确率的团队，解决的是可靠性问题的错误一半。

提示熵预算正是填补这一空白的概念：一种结构化的方法，用于衡量、预算和控制模型在相同输入下的输出分布——就像你在 SLO 框架中对待 p99 延迟或错误预算一样。

大多数团队只有在账单出现时才会发现重试问题。智能体（Agent）“运行正常”；延迟仪表盘保持绿色；错误率看起来也没问题。然后财务部门询问为什么本月的推理支出翻了一番，这时才有人终于去翻看日志。结果发现，一个 3 步操作的智能体中，20% 的工具调用在静默重试，每次重试都重放了完整的提示词（prompt）历史记录，而账单已经连续几周在攀升。

这背后的数学逻辑并不神秘，但极其反直觉。20% 的单步重试率听起来还可以接受 —— 大多数工程师看一眼就会忽略它。但一旦考虑到现代智能体框架的重试方式，实际的 Token 成本会更接近 2 倍而非 1.2 倍。而且，这种失败模式对于团队通常关注的每一项指标都是不可见的。

重试预算（Retry budgets）—— 这是一个源自 Google SRE 工作的旧概念 —— 是最简洁的解决方案。但该模式的 LLM 版本需要调整，因为 Token 的行为方式与 RPC 不同。