LLM 可观测性落地：从 Token 指标到“回答 SLO”

做传统后端时，我们很习惯把系统健康讲清楚：延迟、错误率、吞吐、饱和度。

做 LLM 应用后，我发现一个尴尬现实：

你明明有 200 个指标
但当业务问“今天这玩意儿好用吗”
你还是答不上来

因为 Token、请求数、缓存命中率都很努力，但它们不回答“用户是否得到解决”。

这篇文章写我今年上半年做的一件事：把 LLM 应用的观测从“工程指标”推进到“回答 SLO”，让模型质量可以像服务质量一样被管理。

1. 先承认一个事实：LLM 应用的失败不是 500

LLM 应用最常见的失败是“软失败”：

答非所问
编造细节
格式漂移
不问澄清就瞎答
说得很像、但落不了地

它们不会触发 500，却会触发用户的离开。

所以我们需要一组能捕捉软失败的信号。

2. 我们最后保留下来的观测切面

切面 A：成本与延迟（它们是底座）

input/output token
工具调用次数
端到端延迟 P50/P95
缓存命中率（prompt cache / retrieval cache）

切面 B：行为（它们解释“为什么这样”）

澄清率（need_clarification=true 的比例）
追问率（同一会话 2 次以上追问）
拒答率（合规拒答 vs 非预期拒答）
结构化输出失败率（schema 校验失败）

切面 C：结果（它们回答“好不好用”）

我们定义了一个很土的指标：解决率。

判定方式不完美，但足够实用：

用户没有追问
没有转人工
且在 5 分钟内没有重复发起同一意图

它像一个“近似的首次解决率”。

3. 回答 SLO 怎么定

我们把 LLM 应用当成一个服务来写 SLO：

SLI：解决率、追问率、结构化失败率
SLO：例如 28 天窗口内，解决率 ≥ 70%，结构化失败率 ≤ 1%

flowchart LR
  A[用户请求] --> B[LLM+Tools]
  B --> C{是否解决?}
  C -- 是 --> D[计入成功]
  C -- 否 --> E[追问/转人工/重复请求]
  E --> F[计入失败]

这件事的价值在于：

你能把“模型质量”变成可对齐的目标
你能为版本发布设门槛
你能在事故时明确“降级策略”

4. 降级不是耻辱，是体系的一部分

我们做了三个常用降级：

降模型：从大模型降到便宜模型，保证可用性
降能力：关闭深度分析，只保留检索问答
降工具：工具失败时不再强行调用，改为提示用户手动操作

关键是：降级必须可观测。

否则你会以为系统稳定了，实际只是悄悄变差。

5. 最好用的一招：把失败样本“产品化”

我们每周会抽 30 分钟看失败样本，不讲大道理，只问三件事：

失败是否可复现（是否保存了命中片段与最终 prompt）
失败属于哪类（幻觉/澄清不足/工具错误/格式漂移）
下一步动作是什么（修提示/修工具/加规则/加评测）

这让观测从“看图”变成“改系统”。

结语

今年 AI 的热点很多：推理、Agent、工具协议、长上下文。

但真正决定一个 LLM 应用能不能活下去的，往往是最不性感的部分：可观测性与 SLO。

当你能用一句话回答“今天系统好用吗”，并且知道“不好用时该怎么降级”，你就从 Demo 走进了生产。

琅琊苑