把一个 LLM 应用从 Demo 做成服务，最先失灵的是「传统监控的直觉」。APM 时代我们盯错误率、QPS、p99——这些对 LLM 应用依然有用，但远远不够：一个返回 200 的请求，可能是答非所问的幻觉，可能烧掉了预算的 40%，也可能在某个中间步骤悄悄把上下文撑爆。LLM 调用是概率性的黑盒，可观测性的使命就是把这个黑盒变成可审计的（这与 Agent 工程系列导读里「用确定性工程系统管理概率性组件」是同一条原则）。本文拆解要看什么、用什么看、以及怎么把看到的东西变成改进。
层面一：token 与成本——先知道钱花在哪
LLM 应用的账单有独特的「离散爆炸」特征：成本不随用户数线性涨，而随单次调用的上下文长度与调用次数涨。一个 RAG 应用检索回 20 个 chunk 塞进 prompt，一次请求的输入 token 可以是正常值的 50 倍。所以要记录的不只是总数，而是多维分解：按功能模块、按客户、按模型、按调用类型（生成/摘要/路由）分别归账。这个分解直接回答三类问题——哪个功能是成本黑洞、哪些请求可以路由到更小的模型、客户的毛利是正还是负。
实践上，token 用量要从 API 响应里取数（usage 字段）并随调用一起入库，事后用 tokenizer 估算会有版本对不上的坑。
层面二：延迟——TTFT 比总时长更重要
LLM 的延迟结构与传统服务不同：首 token 延迟（TTFT，由 prefill 决定）与逐 token 生成速度（由 decode 带宽决定）是两个独立的量。对流式产品，TTFT 就是用户感知的「响应速度」——总时长再短，首 token 慢一秒，体验就是「卡」。所以要分开埋点：
- TTFT：请求发出到首 token 到达；
- 生成速度：token/s；
- 端到端：TTFT + 生成时长 + 后处理。
分层的好处是能对症下药：TTFT 高就去压缩 prompt（prefill 与输入长度成正比）或上 prefix cache（见站内《大模型服务的缓存体系》）；生成慢则是模型尺寸与量化问题（见站内《端侧 NPU 军备竞赛 2026》的带宽账）。
层面三：质量信号——从「没报错」到「答对了」
这是 LLM 可观测性区别于传统的核心。三个由弱到强的质量信号：
- 结构信号：输出是否可解析（JSON 合法、字段齐全）、是否触发拒答/安全拦截、是否命中格式约束；
- 反馈信号：用户显式（点赞点踩、重新生成）与隐式反馈（重试率、会话中断、转人工率）——重试率高说明输出不稳定，是最便宜的坏质量探测器；
- 评测信号：LLM-as-a-judge 给每次调用打分（相关性、事实性、格式遵从），或对采样流量跑离线评测。judge 打分本身有噪声，适合看趋势与抓回归，不适合当绝对真值（评测方法的坑见站内《大模型评测基准的坑》）。
层面四：轨迹——多步调用的因果关系
Agent 与 RAG 应用一次请求背后是一串调用：检索 → 重排 → LLM → 工具 → 再 LLM……出了问题，你需要知道是哪一步坏的：检索没召回？重排把正确答案挤出去了？LLM 无视了工具结果？这就是分布式追踪的老手艺在新场景的应用——一次请求一条 trace，每个环节一个 span，父子里外串成因果链。
标准化的落点是 OpenTelemetry GenAI 语义约定：用 gen_ai.* 命名空间统一记录模型名、prompt/completion、token 用量、温度等参数，让任何兼容 OTel 的后端都能解读 LLM 调用数据。截至 2026 年这套约定仍在对齐稳定性，但 OpenLLMetry、MLflow 等生态已经采用，埋点层选 OTel 兼容方案是当下最不会后悔的选择——不锁定观测平台，后端随时可换。
工具格局：一张简图
| 工具 | 形态 | 特点 |
|---|---|---|
| Langfuse | 开源（MIT），可自托管 | 追踪 + prompt 管理 + 数据集/实验 + judge 评测的闭环，生态事实标准 |
| OpenLLMetry（Traceloop） | OTel 埋点库 | 主流 SDK 自动埋点，数据可发给 Langfuse 或任何 OTel 后端 |
| LangSmith | 商业托管 | LangChain 深度集成，托管省心 |
| Phoenix（Arize）/ Helicone / Portkey | 商业/开源混合 | 各有侧重：评测、网关级记录、多模型路由 |
选型建议一句话：埋点用 OTel 标准（OpenLLMetry 或原生 SDK），存储与工作流按团队口味选——要自托管与数据主权选 Langfuse，要省运维选托管。
生产闭环：从 trace 到回归测试
可观测性不是 dashboard 装饰，价值在闭环：
生产流量（trace 采样）
→ 挑出坏样本（差评/重试/judge 低分）
→ 修进数据集与 prompt（prompt 版本化管理）
→ 跑回归评测（新 prompt/新模型 vs 数据集）
→ 灰度上线
→ 回到监控
两个工程要点：prompt 是代码——进版本管理、走评审、带变更记录，否则「为什么上周效果变差了」永远无解；评测集从生产来——冷启动时手造的数据集会迅速过时，持续把线上 trace 沉淀成评测用例，才能跟住真实分布的漂移。
落地清单
- 第一周：接入 OTel 埋点，token/成本/TTFT 三件套先入库；
- 第一个月：trace 串联多步调用，质量信号（结构校验 + 用户反馈）上线；
- 一个季度：judge 采样评测 + prompt 版本化 + 回归测试流水线成型。
LLM 应用的可靠性不是「选个更强的模型」就能解决的——模型是概率的，工程必须确定。可观测性就是让不确定性现形的眼睛：看不见的，才真的失控。
读者留言
COMMENTS 暂无还没有留言，来说第一句？