可观测性

它是什么

可观测性是通过系统对外产生并能相互关联的指标、日志和追踪等信号，理解内部状态并回答“为什么会这样”的能力。监控通常检查预先定义的异常，可观测性还要求团队能从现有证据调查未预先列出的故障。OpenTelemetry 将追踪、指标和日志列为主要遥测信号，但采集信号只是手段，不是结果。[S1]

为什么需要它

AI 应用往往串联提示、检索、模型、工具和外部服务，同一种错误可能来自输入漂移、错误上下文、模型版本或工具超时。只看最终错误率无法定位原因，只保存原始对话又会带来隐私和成本问题。可观测性把质量、性能、成本和执行路径连到同一次请求，使团队能够发现、解释和修复生产问题。

它如何工作

为每次请求建立统一追踪标识，并为检索、模型调用、工具执行和后处理创建可关联步骤。记录组件与版本、耗时、错误、重试、令牌和成本，同时收集输入分布、任务结果、评分和用户反馈；指标发现异常，追踪定位路径，结构化日志提供事件细节。告警必须对应负责人和处置手册，新的生产失败还要进入离线评测。敏感输入应遵循数据最小化原则，优先不采集；确需采集时应脱敏或只记录必要特征，并设置访问和保留规则。[S1][S2][S3]

必须澄清的误会

可观测性 ≠ 评估。 评估在发布前回答「它行不行」，可观测性在发布后回答「它现在坏在哪」。只有评估没有观测，线上出的问题只能靠用户投诉反馈；只有观测没有评估，你会看到一堆数字却不知道哪条算异常。

可观测性 ≠ 记录日志。 日志只是原料。可观测性的门槛是能定位：拿到一次失败请求，能不能还原出它经过了哪些环节、在哪一步变得不一样、当时的输入是什么。做不到这一步，日志量再大也只是存储成本。

它不负责告诉你「多好算好」。 标准来自评测与业务定义，观测只负责把事实呈现出来。把两者混在一起，常见后果是团队用「线上指标没报警」替代「我们测过它」，把没监控当成没问题。

真实例子

RAG 助手的满意度突然下降，但模型 API 错误率没有变化。团队从质量告警下钻到请求追踪，发现问题集中在新版解析器处理扫描 PDF 的步骤：检索片段为空，模型仍生成流畅答案。因为追踪同时保留了解析器版本、片段数量、模型版本和反馈，团队能回滚解析器，并把“空检索仍回答”加入发布门禁，而不是盲目更换模型。

什么时候适合与不适合

多步骤、持续运行或故障代价较高的 AI 系统需要较完整的可观测性；低风险原型可以从少量关键指标和端到端追踪开始。记录越多不一定越好：字段和事件规模会推高存储与分析成本，采样可能遗漏罕见故障，原始提示和用户数据还可能泄露敏感信息。若信号无法关联到版本、任务结果和处置动作，庞大仪表盘仍只是遥测堆积。[S1][S2][S3]

亲自试一下

挑一个包含模型和工具调用的流程，画出一次请求的四个步骤。为每步写出开始时间、结束状态、版本和一个质量字段，再定义统一追踪标识、一个告警阈值和负责人。模拟工具超时后，要求另一位成员仅凭已记录信息在十分钟内定位失败步骤；若必须重新加日志才能回答，当前观测设计还不完整。

接下来学什么

用追踪理解一次请求的完整路径，以延迟和吞吐量建立运行指标，再把异常样本送回离线评估；严重问题则通过人工升级处理进入处置流程。

来源与修订

从输出理解内部状态、追踪/指标/日志及其关联方式参考 OpenTelemetry 可观测性资料 [S1]；数据校验、重要切片、真实世界指标、训练服务偏差和线上质量监测参考 Google 生产 ML 指南 [S2]；敏感数据责任、数据最小化、过滤与脱敏参考 OpenTelemetry 安全指南 [S3]。遥测协议、模型供应商、字段、阈值和隐私要求会持续变化。