AI 时代的新可观测性：不只看系统崩没崩，还要看模型有没有胡说
文章正文
背景：传统可观测性为什么不够
Nic 把 New Relic 16 年的演进复盘为三段式：
- Instrumentation 时代（~2008-2012）：核心问题是"怎么给更多语言做插桩"，Ruby / Java / .NET / Python 一路铺过去。很快数据量大到处理不过来。
- Data Platform 时代（~2013-2017）：推出 NRDB，核心价值是"你可以问那些你原本不知道该问的问题"——数据先全收进来，再探索。这一阶段撑起了 dashboards / data explorer / alerts 一整套能力。
- Intelligence 时代（2023 至今）：关键不再是"你能问什么"，而是系统主动告诉你"你应该问什么、该看什么"。
但 Nic 自己也承认：dashboards 变漂亮了、alerts 变多了、查询语言从 Tcl/Tk 换成 NRQL，但本质上和 90 年代做的事没区别——只是从 3 个图变成 300 个图。
没有任何一个 dashboard 小到可以让你"看见一切"。当我们意识到这一点时，就明白了：以 dashboards 和 alerts 为核心的 observability，已经走到尽头了。
dashboard 和 alert 只是工具，不是目标。这是 New Relic 这几年最大的认知转变。
核心维度升级
文章把"AI 时代的可观测性"拆成两个方向：
方向一：AI for Observability
用 AI 增强传统监控能力。三层技术栈必须叠加：
| 层级 | 能力 | 典型场景 |
|---|---|---|
| 统计方法 | signal analysis、baseline deviation、anomaly detection | 先把 petabyte 数据从 10 亿级筛到万级 |
| Machine Learning | hyperparameter 自动调整告警基准 | MLOps，把"内存 80% 报警"优化为 86.2% 动态阈值 |
| Neural Networks (LLM) | 模式理解、模糊判断、推理归因 | 把"可疑片段"交给 LLM 判断是否真有意义 |
关键工程化要求：不能直接把 petabyte 级数据喂给 LLM，成本不可承受。必须先统计降噪、再 LLM 总结。同时需要三样基础设施：
- 海量数据输入
- 结构化数据（指标↔系统映射）
- 空间+时间维度的图谱关联（用户→服务→基础设施）
方向二：Observability for AI
当 AI 本身成为系统的一部分，传统三支柱不够用。文章明确指出要新增的"AI Golden Signals"：
| 维度 | 说明 |
|---|---|
| Token 使用量 | 输入/输出 token 分项统计 |
| 成本 | 按请求、按用户、按 feature 归因 |
| 响应质量 | 答案是否正确、是否符合预期 |
| 用户情绪 (sentiment) | 用户对回答的反馈 |
| 幻觉率 | 是否在胡说，趋势是涨是跌 |
| 输出漂移 (drift) | 模型升级后行为是否变化（如 Sonnet 4.5 → 4.6） |
| 采样评估 | 每 1000 个请求抽 1 个，用更强模型评判 |
Nic 举了个很有画面感的比喻：
你实际上是创建了一个由一群不太靠谱的员工组成的"虚拟呼叫中心"。你需要一个"主管"，在走廊里来回巡视，确保这些 AI Agents 没在胡说八道。
真正的 source of truth
文章反复强调一个反共识：业务指标才是终极观测对象，不是 CPU、不是 latency。
2000 年初在创业公司，办公室角落有台电视只显示一个图：每分钟的销售额。系统出问题，这个数字一定会掉。这个图不会告诉你"哪里坏了"，那是 alerts 的工作。这个图回答的是更重要的问题：你的业务目标有没有达成？
电商看成交、社交看互动——不管栈多复杂，source of truth 始终是业务本身。
业界方案对比
| 方案 | 优势 | 局限 |
|---|---|---|
| New Relic AI Monitoring | 完整的 APM 全栈 + AI 黄金信号；与 OpenTelemetry 深度集成；提供 opinionated guidance（默认判断） | 商业 SaaS，私有化部署贵；早期版本基于自家 agent（偏向 New Relic） |
| LangSmith | LangChain 官方 tracing；prompt 版本管理体验最好；原生支持 LangGraph 多 agent 评估 | 强绑定 LangChain 生态；非 LangChain 项目集成成本高 |
| Langfuse | 开源、可自托管；trace + eval + prompt management 一体；OTel 兼容 | UI 还在迭代；大规模数据下需要自己运维存储 |
| Helicone | 轻量 proxy 模式，零代码改动接入；按请求级别记录 token/cost/latency | 评估能力较弱，深度依赖第三方 LLM-as-judge |
| Arize Phoenix | 开源 + 强大的 eval/drift 检测；支持 embedding drift；学术背景强 | 自托管运维成本不低；不是全链路 APM，更偏 ML observability |
| Datadog LLM Observability | 与 Datadog 既有基础设施无缝衔接；trace 上下文传递完整；企业级合规 | 价格最贵；和 Datadog 生态深度绑定，迁出成本高 |
| OpenTelemetry GenAI | 厂商中立的标准；社区驱动；未来事实标准 | 标准刚起步，工具链成熟度参差不齐 |
工程化关键点
文章里能直接落到工程实践的关键点：
- 分层降噪再上 LLM：统计方法 → ML → LLM，三层叠加，不要直接上 LLM 啃原始数据。
- 告警疲劳的两层治理：
- 第一层：用 intelligence 在通知人之前过滤 alert（像 on-call 工程师的直觉——6 个系统同时报才会立刻冲键盘）。
- 第二层：反向优化 alert 本身——哪些总是一起触发？哪些从来不可操作？哪些只是闪一下就消失？
- 结构化关联是根因分析的前提：用户→浏览器→服务→基础设施的图谱关系，缺一不可。
- "5 分钟拿到价值"是产品目标：刚上线系统就要能看到"Sonnet 4.5 升级到 4.6 后购买流程回答变奇怪了"这种关键信息。
- tooling 厂商必须提供 opinionated guidance：不能只说"你想监控什么都可以"，必须告诉新手团队"哪些信号最重要、合理范围在哪"。
- 数据隐私是 LLM-as-judge 的硬约束：评估数据要发给外部吗？发多少？这是设计评估链路时必须前置考虑的问题。
- On-call 会消失：当检测、响应、修复都发生在机器尺度（毫秒级），on-call 这个概念会慢慢消失，就像现在没人觉得"程序崩溃自动重启"是技术能力一样。
- 抽象层持续上移：编译器 bug、hex editor 调试这些底层挣扎已经被腾出去了，腾出来的脑力应该用于系统架构、数据流、petabyte 级数据治理。
- 永远记得业务指标：任何技术栈最后都要回答"业务目标有没有达成"这个问题。
Rainsho 视角
这篇 New Relic 自家战略官的访谈，本质是给商业 APM 卖"AI observability"这个新概念背书——把它当结论看要打折。但抛开商业意图，文章里有几个真正值得工程团队停下来想一想的判断：(1) dashboard + alert 范式走到尽头不是预言，是已经发生的事实，Kubernetes 集群动辄数百节点数千 Pod，"加更多 alert"的反身性已经开始反噬响应速度；(2) AI 系统的可观测性核心难点是非确定性——同一 prompt 两次返回不一样，传统"是否 2xx + 延迟 P99"完全失效，token / cost / 语义质量 / drift 这套新维度是必须补的，不是锦上添花；(3) 但要警惕厂商刻意制造的新焦虑——很多团队连 trace 上下文都没串通，就开始堆 LLM-as-judge，本质是把 observability 的债务从"告警"转移到"评估"上。我自己的判断是：先把 OpenTelemetry 那一层 trace + token + cost 打通，比选 LangSmith 还是 Langfuse 重要 10 倍。标准先于选型，语义质量评估是最后才需要上的高级货，不是一上来就该花精力的地方。