为什么 AI 可观测性和传统后端不一样
传统后端观测三件套：指标、日志、追踪。AI 应用在这之上多了三个只有 AI 才有的观测维度：
- 成本：每次调用都有 token 账单，且随上下文长度非线性变化。
- 质量：HTTP 200 不等于答对了——幻觉、跑题、拒绝率，都要量化。
- 语义层：检索命中、上下文长度、模型路由是否走对，都会影响结果和钱。
埋点什么：最小集 = 一张「调用记录表」
从第一行代码就埋，别等上线。每条 LLM 调用至少记录：
| 字段 | 为什么记 |
|---|---|
| 时间 / 功能 / 用户维度 | 按功能切成本，谁涨了当天能定位 |
| 模型名 / 路由结果 | 是不是该走小模型的走了大模型 |
| prompt 与输出（脱敏后） | 出问题能回放，这是定位幻觉的唯一手段 |
| 输入/输出 token 数 | 成本归因 + 上下文膨胀预警 |
| 延迟（首 token / 总时长） | 用户体感与容量规划 |
| 检索命中情况（RAG 场景） | 召回是质量瓶颈的第一嫌疑 |
| 业务结果标记（成功/拒绝/降级） | 拒绝率、降级率是质量代理指标 |
提示：prompt 和输出可能含用户数据，记录前脱敏是硬要求——把姓名、账号、敏感字段替换后再落库。
观测什么：四张面板
- 成本面板：按 功能 × 模型 × 日均 token 切，每天看趋势。异常上涨当天定位（方法见成本控制篇）。
- 延迟面板：分「首 token 延迟」（体感）和「总延迟」（容量），P50/P95 分开看，别只看均值。
- 质量面板：拒绝率（该说不知道的比例）、降级触发率、缓存命中率——这三个是「答得对不对」的代理指标，因为真实正确率需要标注集才能测。
- 回放台：能按 request_id 回放某次完整调用（prompt → 检索 → 输出），做案例复盘——没回放能力，出了幻觉你只能靠猜。
工具与埋点方式
- 工具：先用 Langfuse 自托管（或 LangSmith 体验版），它把 trace、成本、评测串起来了；等规模大了再决定要不要自建（工具行有实测）。
- 标准：OpenTelemetry 的 GenAI 语义约定（
gen_ai.*属性）可以直接接，避免自造一套。 - 告警：成本日环比、P95 首 token、拒绝率突变，三条规则起步，别一上来就 30 条（告警疲劳见排障工具链）。
落地清单
- 调用记录表从第一行代码就埋（含脱敏规则）
- 成本 / 延迟 / 质量 / 回放四张面板上线
- 拒绝率、降级率、缓存命中率作为质量代理指标
- 三条告警起步，每条有处置预案
- 发布评审加一条：新功能的可观测字段是否齐全