6 篇博文 含有标签「ai-reliability」

你的状态页显示为绿色。你的错误率为零。你的 p95 延迟看起来比上周略好。而在上周二，eval-on-traffic 指标在悄无声息中下降了四个点，整整九天都没人发现原因。因为当质量回退最终突破告警阈值时，已经有四个交织在一起的根因叠加在一起，团队已经无法分辨是哪一个最先引发了下滑。

这是 2026 年成熟智能体系统的主要故障模式，它不是任何单一组件的 bug。它是团队刻意构建的防御栈——那些出于好心、一个接一个添加的安全网——所产生的累积效应。主模型返回了垃圾内容；重试成功了。重试失败了；更便宜的回退（fallback）模型给出了答案。回退模型的输出格式错误；包装器（wrapper）将其重写为看起来合理的形状。包装器记录了一个软告警（soft warning）。没有人针对软告警设置告警。用户收到一个看似正确、交付流畅，但实际上比系统设计初衷要差的答案。

鲁棒层起作用了。质量表现却崩塌了。而告警机制是为鲁棒层存在之前的世界构建的。

Google Research 有一个令人不安的发现：当 RAG 系统检索到不足或过时的上下文时，幻觉率并不会保持不变——它会从 10.2% 飙升至 66.1%。增加一个陈旧的知识库并不会让你的 AI 帮助中心保持中立。它会让你的 AI 给出自信错误答案的可能性比你什么都不发布还要高出六倍。

大多数构建 AI 驱动的搜索和帮助中心的团队都专注于检索质量、嵌入模型和分块大小。几乎没有人建立流程来追踪语料库中的文档是否仍然准确。这种差距——文档债（documentation debt）——现在正表现为生产环境的可靠性问题，而不仅仅是内容问题。

2024 年初，谷歌的图像生成工具开始产生历史上不准确的结果，应对之策来得迅速：暂停所有人物图像生成功能。这一暂停持续了数月。想将该功能用于合法用途的用户毫无选择。等到功能重新上线时，采用率也很低——仅对一小部分订阅用户开放，受到严格限制，且声誉包袱尚未完全卸下。过度纠正本身成了一个新问题。

这是大多数团队在 AI 功能公开失败后都会掉入的陷阱。直觉没错——如果某个东西在造成伤害，就应该停止——但执行方式却错了。彻底下架功能，或者堆砌铺天盖地的护栏让其形同虚设，并不能重建信任。这只会表明你不知道如何负责任地运营 AI，也无法分辨那 0.1% 的错误输出与 99.9% 的正常输出之间的区别。

当一个 PlanCompiler 风格的智能体（agent）与直接的 LLM 生成代码模式在 300 个分层多步任务中进行基准测试时，结构化方法实现了 92.67% 的成功率，单任务成本为 $0.00128。而直接方法——即 LLM 在自由形式的循环中逐步决定行动——成功率为 62$0.0106。这意味着准确率提高了 50%，而成本仅为原来的八分之一。

差异不在于模型的能力。两种方法使用的是同一个模型。差异在于架构：一个将计划生成与计划执行分离开来；另一个则将两者混为一谈。

AI 功能拥有仪表板。提示词（Prompt）有版本控制。评估套件（Eval suite）有轮值表。然后是一个写于 2022 年的上游定时任务（cron job），由一个在两次重组前就退出了分析部门的团队负责，它生成了构建你的检索索引所需的 CSV 文件。那个定时任务没有 SLA。那个 CSV 没有 Schema 契约。负责它的团队根本不知道它正在为一个 AI 功能提供数据。当它发生变化时——它一定会变——AI 团队将花费三周时间去调试一个完全没有出错的提示词。

你即将追踪的 AI 质量回退几乎从来不是 AI 问题。它是一个穿着 AI 外衣的 ETL 问题。需要落实的规范是两者之间的衔接点——契约、血缘（lineage）、新鲜度信号、成对的轮值——而没有将其正式化的团队，所交付的 AI 功能的可靠性将受限于公司里最不受待见的定时任务。

你的 AI 智能体完成了任务。日志中没有错误。延迟看起来很正常。输出是格式良好的 JSON，语法完美的散文，或者是执行起来毫无怨言的有效 SQL 查询。仪表盘上的每一个指标都是绿色的。

而用户盯着结果，叹了口气，然后从头开始。

这就是语义失效模式 —— 这类生产环境中的 AI 失败表现为：系统运行正常，模型自信地响应，输出按时交付，但智能体并没有做用户真正需要的事情。传统的错误监控对这些失败完全视而不见，因为并没有报错。HTTP 状态码是 200。模型没有拒绝。输出符合 Schema。从每一项技术指标来看，系统都成功了。