我在企业部署中见过的最昂贵的AI故障并没有产生错误。没有触发警报。仪表盘没有变红。系统完全正常运行，只是持续地、自信地出错。这就是可靠性差距。而且这是大多数企业AI项目没有设计来捕捉的问题。

过去两年，我们在评估模型方面取得了很大进展：基准测试、准确率分数、红队演练、检索质量测试。但在生产环境中，模型很少是系统崩溃的地方。崩溃发生在基础设施层、为模型提供数据的数据管道、包装模型的编排逻辑、为模型提供基础的检索系统、以及信任模型输出的下游工作流中。这些层仍在使用为不同类型软件设计的工具进行监控。

无人测量的差距

为什么这个问题难以发现：运营健康和行为可靠不是一回事，大多数监控堆栈无法区分这两者。

一个系统可能在每个基础设施指标上都显示绿色，延迟在SLA范围内，吞吐量正常，错误率平稳，同时却在处理六个月过期的检索结果，在工具调用降级后静默回退到缓存上下文，或者在代理工作流的五个步骤中传播误解。这些都不会出现在Prometheus中。没有一项会触发Datadog警报。

原因很简单：传统的可观测性是为了回答”服务是否正常运行？”这个问题而构建的。企业AI需要回答一个更难的问题：”服务是否正确运行？”这些是不同的工具。

团队通常测量什么

实际驱动AI基础设施失败的因素

• 正常运行时间/延迟/错误率
• 检索新鲜度和基础置信度
• Token使用量
• 多步骤工作流中的上下文完整性
• 吞吐量
• 真实负载下的语义漂移
• 模型基准分数
• 条件恶化时的行为一致性
• 基础设施错误率
• 推理层的静默部分故障

传统监控无法捕捉的四种故障模式

在网络运营、物流和可观测性平台的企业AI部署中，我看到了四种足够一致的故障模式，足以给它们命名。第一种是上下文衰减。模型处理不完整或过时的数据，这对终端用户是不可见的。答案看起来很完善。基础性已经消失。检测通常在几周后通过下游后果而不是系统警报发生。

第二种是编排漂移。代理管道很少因为一个组件而失败。它们失败是因为检索、推理、工具使用和下游操作之间的交互序列发生了变化…

原文链接：https://venturebeat.com/infrastructure/context-decay-orchestration-drift-and-the-rise-of-silent-failures-in-ai-systems

关注微信号：智享开源 关注微博：IMCN开源资讯网 ，可及时获取信息

蒂姆·库克缔造了什么

AI合成受众已至，或将颠覆咨询行业

购买湾区豪宅需Anthropic股权

TechCrunch交通：埃隆的坦白

SpeakOn听写设备：好创意，却受平台所困

AI需求推动，加价M4 Mac mini在eBay泛滥