2 篇博文 含有标签「tracing」

你的 Datadog 仪表板显示 99.4% 的在线率，低于 500ms 的 P95 延迟，以及 0.1% 的错误率。一切都是绿色的。与此同时，你的支持队列却充满了抱怨 AI 给出了完全错误答案的用户。你毫无头绪，因为每个请求都返回了 HTTP 200。

这是传统可观测性与你在 LLM 系统中真正需要的可观测性之间的本质区别。语言模型可能会以标准 APM 工具无法留下痕迹的方式发生故障：幻觉事实、从错误的产品版本中检索文档、在代码更改修改了系统提示词后将其忽略，或者在模型更新后对特定查询类型静默降级。在你的延迟图表上，这些看起来都一切正常。

你的监控堆栈会告诉你关于请求率、CPU 和数据库延迟的一切。但它几乎无法告诉你，你的 LLM 是否刚刚幻觉出了一个退款政策，为什么一个面向客户的智能体（Agent）循环调用了三次工具才回答了一个简单的问题，或者你产品中的哪个功能正在每天悄无声息地烧掉价值 800 美元的 Token。

传统的可观测性是围绕确定性系统构建的。LLM 在结构上完全不同 —— 同样的输入，每次的输出都可能不同。它的失败模式不是 500 错误或超时；而是一个听起来很有道理、非常自信但恰好错误的回答。成本不再是稳定且可预测的；当一个配置错误的 Prompt 遇到流量高峰时，成本会激增。调试也不再是“在堆栈跟踪中查找异常”；而是“重构为什么智能体在周二凌晨 2 点选择了这个工具路径”。

这就是 LLM 可观测性要解决的问题 —— 并且在过去的 18 个月里，这一领域已经显著成熟。