接口返回 200、耗时也正常，答案却是错的——这是 AI 应用最典型的故障形态。传统监控只能证明”服务活着”，AI 可观测性要回答的是”模型为什么给出这个回答”。本文讲清 Trace、指标、评估三支柱的分工，Trace 的 Span 拆分方法，LangSmith/Langfuse 类平台的能力模型，以及线上质量监控与成本观测的做法。

它解决什么问题

传统后端可观测性围绕 QPS、错误率、P99 延迟与慢查询展开，前提是”接口成功 ≈ 结果正确”。这个前提在 LLM 应用里不成立：一次 RAG 问答可能经历问题改写、向量检索、重排、上下文拼装、模型生成多个环节，每一步都”调用成功”，错误却一路传导，最终输出一段格式完美、内容错误的回答。Agent 场景还要叠加多步规划、循环重试与并行子任务，任何一步的偏差都会被后续步骤放大——工具接口返回 200，响应体里却可能是”库存不足”；一次超时重试，可能把有副作用的写操作执行了两次。

AI 可观测性的目标，是把”模型收到什么、检索命中什么、工具做了什么”串成一条可回放的证据链，让 Badcase 复盘不靠猜。

观测三支柱：Trace、指标与评估

支柱 回答的问题 典型内容
Metrics（指标） 系统整体是否异常 请求量、错误率、P95 延迟、Token 用量、TTFT、工具失败率
Trace（追踪） 这一次请求经历了什么 模型调用、检索、工具执行、重试及其父子关系
Evaluation（评估） 输出质量是否合格 正确性、忠实度、任务完成率、安全性打分

三者的协作可以概括成一句话：指标发现异常，Trace 定位过程，评估判断质量。例如 Token 消耗突增先由指标告警，顺着告警时间窗捞出高消耗 Trace，发现某个 Agent 循环调用了十几次模型；至于这十几次调用是否必要、答案是否正确，交给评估规则判断。日志也没有被淘汰——异常堆栈与状态变更仍走日志，只要带上 traceId/spanId，就能在日志与调用链之间双向跳转。

Trace 的 Span 结构

ID 层级通常是：Session（一段多轮会话）→ Run（一次任务，可能因人工审批跨多条 Trace）→ Trace（一次端到端执行）→ Span（链路上的一个操作）→ Attempt（同一操作的第几次重试）。每次重试应新建 Span 并标注 attempt，否则”第一次超时、第二次成功”会混成一条记录。

Span 拆分粒度决定 Trace 是否好用：太粗只剩”Agent 执行了 8 秒”，太细则被无意义的方法节点淹没。一般满足下列条件之一才值得独立成 Span：调用了外部系统（模型、向量库、业务 API）；是检索、重排、校验这类关键阶段；有独立的超时、重试或降级策略；需要单独统计成本与错误率。一条典型的 Agent Trace：

agent.run
├── llm.chat                     # 意图识别
├── rag.retrieve                 # 检索阶段
│   ├── embedding.embed          # 查询向量化
│   ├── vector.search            # 向量库召回
│   └── rag.rerank               # 重排
├── llm.chat                     # 生成（可能多轮）
│   ├── tool.execute: query_order
│   └── tool.execute: create_refund
└── output.validate              # 结构化校验

两个工程细节值得注意。其一，Span 名称必须稳定、低基数，execute_tool query_order 是好的命名；把订单号、用户原话拼进名称会让索引爆炸。其二，属性要分高低基数：模型名、工具名、状态这类低基数字段可以进指标做聚合；user_id、session_id、文档 ID 只进 Trace；Prompt 原文与工具返回属于敏感高体积内容，默认只存哈希或摘要，按需开启并配合脱敏与权限。

LangSmith/Langfuse 类平台的能力模型

这类 LLM 观测平台的能力可归纳为四块：

  1. Trace 采集与展示：以调用树还原每次请求的模型调用、检索与工具执行，展示 Prompt、补全、Token 与耗时；
  2. 数据集与评估：把 Trace 一键加入数据集，支持人工标注与 LLM-as-Judge 打分，做版本间实验对比与发布回归；
  3. 线上监控：延迟、成本、用户反馈分的仪表盘与告警；
  4. 治理能力：数据脱敏、权限隔离、保留周期与审计。

LangSmith 与 LangChain 生态绑定更紧，Langfuse 走开源自托管路线，两者都提供 SDK 埋点。如果团队已有 OpenTelemetry 体系，也可以让应用统一输出 OTLP，把 LLM Span 与普通 HTTP、数据库 Span 留在同一条分布式 Trace 里。选型时重点确认：对 OTel GenAI 语义约定的支持度、哪些字段属于平台私有扩展、敏感内容的脱敏粒度、Trace 能否回流评测集，以及平台故障是否会反噬主链路——遥测导出必须异步、限时并设队列上限，观测后端挂了可以丢数据，不能拖垮业务请求。

线上质量监控

质量监控不等于技术指标监控，它由三个机制组成。

反馈采集：显式反馈是点赞、点踩与申诉入口；隐式反馈是用户是否采纳答案、是否换个问法重问、会话是否中途流失。隐式信号噪声大但覆盖面广，两者结合才能估计真实满意度。

漂移检测：供应商静默升级模型、用户问题分布变化、知识库内容更新，都会让线上表现偏离基线。需要持续跟踪输入侧（问题长度、语言、意图分布）、检索侧（空召回率、相似度分布）与输出侧（拒答率、答案长度、忠实度抽样分）的分布，按场景建立基线、偏离即告警，而不是给所有场景套同一个固定阈值。

回放：确认过的失败 Trace 脱敏后沉淀为 Badcase 集。回放分两种目标——复现问题时要固定模型版本、Prompt 版本与检索快照，尽量还原当时条件；验证新版本时把同一批输入交给新配置，对比正确率、延迟与成本。只保存一句用户问题是没法精确复现的，动态数据要留存当时的工具返回或可追溯的数据版本。

成本观测

LLM 应用的成本单位是 Token，观测必须回答”钱花在哪”。实践上按模型、场景、租户三个维度归因输入、输出与缓存命中 Token，并监控单位业务动作的成本（例如每次成功售后工单的平均 Token 消耗）。平均值会掩盖长尾——Agent 偶尔陷入循环时均值变化不大，P95 与最大值会先暴露。采样策略也要配合成本目标：普通成功请求低比例采样控制存储，高 Token、高费用、循环次数异常的 Trace 尽量全量保留；涉及资金与写操作的审计记录则应走独立链路，不随 Trace 采样丢弃。

常见误区

  • 只在最外层记一条”模型调用成功”，多次检索与工具调用全部不可见；
  • 把 HTTP 200 当业务成功，忽略响应体里的业务错误码；
  • 默认全量上报 Prompt 与工具返回，引入泄露风险与索引膨胀；
  • 把用户 ID、问题原文塞进指标标签，制造高基数时间序列；
  • 依赖框架自动埋点却不验证跨线程、跨服务场景的上下文传播；
  • 收了大量 Trace 却从不回流评测集，同类问题反复出现。

面试视角

AI 可观测性和传统可观测性最大的区别？ 传统监控面向确定性的服务行为，AI 输出是概率性的，接口成功证明不了结果正确，所以必须把 Trace 与评估结合，并覆盖模型、Prompt、检索、工具这些传统链路里没有的环节。

Trace 和 Evaluation 是什么关系？ Trace 还原”系统做了什么”，评估回答”做得好不好”。线上失败 Trace 脱敏后进入评测集，修复后离线回放与版本对比，形成”发现—修复—回归”的闭环。

小结

  1. 三支柱分工明确：指标发现异常、Trace 定位过程、评估判断质量，日志通过 traceId 与之关联。
  2. Span 拆分要克制：外部调用、关键阶段、独立容错策略、独立统计需求，满足其一才建 Span；名称低基数，内容分层存储。
  3. LangSmith/Langfuse 类平台的核心价值在 Trace 展示、数据集评估、监控告警与治理四块能力；有 OTel 体系的团队可用 OTLP 保持链路统一。
  4. 线上质量靠反馈采集、漂移检测与回放三个机制维持；成本观测以 Token 为核心，按模型、场景、租户归因。
  5. 不可观测的 Agent 不可运维——没有 Span 级证据，Badcase 复盘只能猜。