LLM 应用的可观测性：trace、eval、监控
传统 APM 不够用——LLM 应用是非确定的、链路长的、烧 token 的。本文讲清可观测性的三层：trace（每步 LLM/工具调用）、eval（输出质量自动评测）、metric（延迟/token/成本告警），以及怎么把它们接进开发循环，让 AI 应用从"上线后黑盒"变"可调试可改进"。
本文要点
- 主题聚焦：大模型、DevOps
- 适合人群：独立开发者、全栈工程师、AI 应用开发者
- 核心价值：快速理解背景、实践路径、常见误区和工程建议
传统 Web 应用的监控，看 QPS、延迟、错误率基本够。LLM 应用加了三件麻烦：输出是非确定的（同样的请求，每次结果不同）、链路长且昂贵（一个用户请求可能触发多轮模型 + 工具）、质量比"有没有报错"更重要（200 OK 但答非所问，比 500 更糟）。
所以 LLM 应用需要一套专门的可观测性，分三层：trace、eval、metric。
一、Trace：把整条链路串起来
一个用户请求在 LLM 应用里往往是这样：
用户请求
→ 路由判断
→ query 改写（1 次模型调用）
→ 向量检索 + rerank
→ 拼 prompt（2 次模型调用：主答 + 自检）
→ 工具调用（读 DB）
→ 最终回答
中间任何一步都可能出问题：检索没召回、改写跑偏、工具返回空。没有 trace，你只看到"用户问了 X，模型答了 Y"，无从定位是哪一环的问题。
Trace 要记录每个 span：
- 每次模型调用：prompt、模型、参数、输出、耗时、token。
- 每次工具/检索：输入参数、返回结果、耗时。
- 整条链路的父子关系（一次回答里嵌套了哪些子调用）。
工具上，开源的 Langfuse / LangSmith 是这一类的事实标准（和具体框架解耦，OpenTelemetry 也能搞）。接入后你能看到每次请求的完整树状 trace，点开任一节点看输入输出。
经验：trace 是 LLM 应用的"调试器"。没有 trace 的 AI 应用上线，出问题就只能靠复现用户的输入盲猜，效率极低。
二、Eval：质量的"持续集成"
trace 告诉你"发生了什么"，eval 告诉你"好不好"。这是 LLM 应用最该补、也最常缺的一层。
核心做法：建一个评测集（几十到几百条 输入 → 期望属性/参考答案），每次改 prompt / 换模型 / 调检索，跑一遍，量化对比。
三类评测：
1. 检索评测（针对 RAG）
- Context Recall：该被召回的内容召回了多少。
- Context Precision：召回的内容里多少是相关的。
2. 生成评测
- Faithfulness（忠实度）：回答是否都能在上下文里找到依据（防幻觉）。
- Answer Relevancy：回答是否切题。
3. 业务评测（自定义）
- 格式正确率（要求 JSON 时是否合法）。
- 安全（是否触犯安全规则）。
- 业务正确性（人工标注的"好回答"集合，跑分数）。
工具：RAGAS（RAG 专用）、promptfoo / DeepEval（通用 eval 框架）。它们大多用"LLM 当裁判"自动打分，省去人工逐条标。
Eval 的价值在于可回归：没有它，改 prompt 是玄学；有了它，每次改动有客观对比。理想状态：eval 进 CI，prompt/模型改动导致评测下降就拦下来。
三、Metric：延迟、token、成本、错误
面向运营和 SLO 的指标层：
- 延迟分布：p50 / p95 / p99。LLM 应用延迟方差大，平均值骗人，看尾部。
- token 消耗与成本：按 prompt / completion、按用户 / 按功能拆。这是 LLM 应用独有的"运行成本"，不监控就是失控烧钱。
- 错误率：区分"系统错误"（超时、限流）和"业务错误"（JSON 解析失败、被安全规则拒）。
- 工具成功率：每个 tool 的调用成功率，某个工具成功率骤降往往是上游变了。
- 人工介入率 / 用户重试率：用户行为指标。用户反复重试 = 体验不好，即便没报错。
告警：token 成本异常飙升（可能被滥用）、延迟 p95 突增（可能模型侧抖动）、错误率突增，都该有告警。LLM 应用的成本曲线不像传统应用那么平稳，一个 bug 可能在几小时内烧掉可观的钱。
四、把三层接进开发循环
可观测性不是"上线后再加"，而是嵌进开发流程：
开发时：trace 调试单条请求 → 改 prompt/代码
发布前：跑 eval 集 → 量化是否变好
上线后：metric 监控 → 异常告警 → bad case 回流到 eval 集
关键闭环：线上 bad case → 进 eval 集 → 防止回归。用户反馈"答得不对"的那条，加进评测集标注期望，下次改动自动盯住它。这样 eval 集会越用越有代表性，系统越用越稳。
五、成本与隐私的取舍
完整 trace 会记录 prompt 和输出全文——这里有两个隐患：
- 成本：trace 数据本身可能很大（长 prompt × 高 QPS）。设置采样率，或只对错误/慢请求存全量。
- 隐私：用户输入可能含 PII / 敏感数据。trace 落库前脱敏（手机号、邮箱、密钥模式），或自托管 trace 服务（Langfuse 自托管，数据不出自己的机房）。
小结
LLM 应用的可观测性，三层缺一不可：
- Trace：定位"哪一环出了问题"（Langfuse/LangSmith）。
- Eval：量化"改动有没有变好"（RAGAS/promptfoo + 评测集）。
- Metric：监控"线上是否健康"（延迟/token/成本/告警）。
把这三层搭起来，再加上"线上 bad case → eval 集"的闭环，你的 AI 应用才从"上线后听天由命"变成"可调试、可回归、可控成本"的工程系统。这件事的 ROI 极高——绝大多数 AI 应用的质量问题，不是模型不行，而是没有可观测性让你发现和定位。
Related