159 篇博文 含有标签「reliability」

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

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

一个市场调研流水线连续运行了 11 天。四个 LangChain Agent —— 一个分析器（Analyzer）和一个验证器（Verifier）—— 来回传递请求，在原始任务上毫无进展，并在被人发现之前累积了 47,000 美元的 API 费用。系统从未返回错误，也没有触发报警。直到损失造成几天后，计费仪表板才发现了这一异常。

这绝非个案。它是典型的 AI Agent 事故。如果你现在正在生产环境中运行 Agent，你现有的 SRE 运维手册（runbooks）几乎肯定没有涵盖这种情况。

大多数工程问题都是自找的。你部署的代码、定义的 Schema、选择的依赖——出问题时，都可以追溯到你自己的决策。AI API 集成打破了这一假设。当你构建在第三方模型 API 之上，凌晨三点一次无声的模型更新就能让你的功能降级，而你这边根本没有任何发布操作。提供商的服务中断可以让你的产品下线。价格调整可以把一个盈利的工作流变成亏本买卖。这些破坏性变化永远不会出现在你的变更日志里。

这不是回避外部 AI API 的理由，而是以"不信任"的心态来构建系统的理由。

你开启了 JSON 模式，你的 LLM 开始返回有效的 JSON，然后你发布了它。三周后，生产环境悄无声息地挂了。JSON 在语法上是有效的。Schema 在技术上也是满足的。但某个字段包含了一个虚构的实体，finish_reason 为 "length" 导致数据负载在 95% 处被静默截断，或者模型对任何人类读起来都感到刺耳的文本分类为 "positive" 情感——而你的下游流水线毫无怨言地吞下了它。

JSON 模式被解决的方式，就像“使用互斥锁（mutex）”解决并发问题一样。原语（primitive）是存在的。但故障模式并不在于你把锁放在哪里。

一个部署在医疗转录服务中的大型语言模型达到了 99% 的准确率。团队满怀信心地上线了。六个月后，一项研究发现，其转录样本中有 1% 包含原始音频中根本不存在的捏造短语——虚构的药物名称、不存在的手术操作，甚至偶尔在句子中间插入暴力或令人不安的内容。有 30,000 名医疗专业人员在使用该系统，这 1% 意味着每月数万条受污染的记录，其中一些已产生患者安全后果。

准确率数字从未改变。问题一直存在。团队只是没有做规模化的数学推算。

你的支付服务拥有 99.9% 的可用性 SLA。请求要么成功，要么以文档记录的错误代码失败。当出现故障时，你清楚地知道哪里出了问题。

现在，想象你发布了一个封装了 LLM 的智能发票解析 API。在一个周一早晨，你最大的客户打来电话：“你们的 API 返回了一个有效的 JSON 对象，但在涉及外币的发票中，total_amount 字段的值差了十倍。” 你的服务返回了 HTTP 200。你的可用性仪表板显示绿色。根据每一个传统的 SLA 指标，你都没有违反任何规定。但你确实搞砸了——而且在契约语言中，你甚至找不到词汇来描述到底哪里出了错。

这就是当今大多数 AI API 部署的核心鸿沟。管理你的 API 承诺 的契约为确定性系统而写，而 LLM 并非确定性系统。

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

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

30%的生成式AI项目在概念验证后被放弃。95%的企业试点没有产生任何可衡量的业务影响。Gartner预测，到2027年底，40%的智能体AI项目将被取消。这些并非底层技术的失败——而是演示与生产之间差距导致的失败。

演示到生产的失败模式是可预测、可重复的，也几乎完全可以预防的。它的发生是因为让演示看起来很棒的条件与让生产正常运行的条件系统性地不同。团队优化前者，却被后者打个措手不及。

大多数团队将 AI 自主性视为一个二进制开关：智能体要么受监督，要么不受监督。这种思维模式正是为什么 80% 的组织报告了智能体的意外操作，以及为什么 Gartner 预测到 2027 年底，超过 40% 的代理型 AI 项目将因风险控制不足而被放弃。问题不在于 AI 智能体天生不可信，而在于团队在赢得独立性之前就将其提升到了独立地位。

自主性应该是智能体通过展示其可靠性而逐步积累的东西，而不是你在部署时分配的一个属性。就像一名新工程师在获得生产环境访问权限之前，先从审查 PRs 开始一样，AI 智能体在建立业绩记录的过程中，其操作范围也应逐步扩大。这不仅是哲学层面的思考——它会改变你所做的具体架构决策、你追踪的指标以及你设计回滚机制的方式。

团队调度循环 AI Agent 任务最常见的方式，也是最危险的方式：一个每隔 N 分钟触发一次 REST 调用的 Cron 条目，它启动一个 LLM 工作流，任务要么完成，要么悄无声息地失败。这个模式在预发布环境看起来没什么问题，但在生产环境中，它会制造出一类极难发现、难以恢复、难以推理的故障。

Cron 诞生于 1975 年，最初是为运维脚本设计的。它所内建的假设——运行时间短、无状态执行、触发即忘——在每一个维度上都与 LLM 工作负载的现实相悖。循环 AI Agent 任务是长时运行的、有状态的、成本高昂的，其失败方式会在多次重试中不断叠加。用 Cron 来调度它们，不只是可靠性风险，更是可见性风险：出问题时，你往往浑然不知。

你的 AI 搜索功能在三个月前上线了。早期的评估结果非常亮眼——你的团队运行了 1,000 次查询，准确率达到了 83%。点赞率（Thumbs-up rates）很高，用户参与度也很好。

然而，在上线六周后，查询重构率（query reformulation rates）开始上升。会话放弃率（session abandonment）也随之增加。定性审查证实了这一点：用户提出的问题与上线前完全不同，而模型的服务质量已不如从前。

模型没有改变。底层数据也没有改变。产品质量下降是因为用户适应了它。

这就是反馈循环陷阱。它与大多数机器学习工程师习惯处理的外部概念漂移（concept drift）有着本质的不同——而且一旦开始，修复起来要困难得多。

几乎在每一个生产环境的 AI 系统中都会出现这样一种模式：团队从一个精简的系统提示词（system prompt）开始，发布功能，然后不断迭代。出现了一个新的边缘案例，于是他们添加一条规则。又来了一个工单，再加一条规则。六个月后，系统提示词已经增加到了 2,000 个 token，涵盖了 20 个不同的行为要求。对于大多数请求，AI 听起来依然连贯。但微妙的合规性失败已经潜伏了数周——这里忽略了格式，那里跳过了语气要求，一条升级规则被悄悄绕过。没有人发现，因为没有哪个单独的失败严重到需要触发警报。

这不是模型质量问题。这是基于 Transformer 的语言模型处理指令的一种基本架构特性，大量的实证研究使得这些失败模式变得可预测。理解这一点将改变你编写系统提示词的方式。