LLM observability:log、trace、eval 三件事

大部分 LLM 产品蒙眼在做。团队写个 prompt 出货,收到 bug 报告但重现不了,乱试一些修法希望有一个会中。半年下来,没人知道最近一次模型升级是让事情变好还是变坏。

Observability 是让你的 LLM 系统「可读」的纪律。三层 —— log、trace、eval —— 把黑盒子变成可以 debug 的东西。

为什么一般 APM 不够用

Datadog、New Relic、Sentry 这些对 HTTP 请求流很好。它们告诉你某个 request 花了 800ms,某 endpoint 99% 成功。但它们不是为这些 LLM 特定问题设计的:

• 为什么模型给这个答案? 你要看完整 prompt,含动态检索的 context。
• 模型用对工具了吗? 你要看 agent 决策链的每一步。
• 这个对话是不是越跑越烂? 你要比较第 5 轮跟第 1 轮,不只是看单一 HTTP call。
• 新 prompt 是不是把什么弄坏了? 你要在固定 eval set 上做 before/after。

这就是专门 LLM observability 在解的事。

第 1 层:结构化 log

最低限度有用的 log,每次 LLM 调用要记:

• 完整 request body。 模型名称、system prompt、user prompt、所有 messages、工具定义、temperature、max_tokens、所有 sampling 参数。
• 完整 response body。 所有输出区块(文字、tool_use、reasoning 模型的 thinking block)、stop_reason、finish_reason。
• token 用量。 输入 token(如果用 prompt caching 要拆成 cached vs non-cached)、输出 token。
• 延迟。 time-to-first-token、总时间。
• 成本。 用 token 数跟当下定价算出来。
• trace ID。 把这次调用连回触发它的用户 request 的唯一 ID。

开发环境不要遮蔽 prompt。production 如果隐私要求需要,在存储前遮 PII。

小提示:把 log 存成可查询格式(Postgres 里的 JSON、S3 里的 Parquet、或托管 observability 工具)。纯文字 log 过了 1000 笔就没用了。

第 2 层:trace

单一 LLM 调用很少是全貌。真实系统是多步骤的:

user_request -> retrieve(query) -> rerank -> llm_call(plan) -> tool_call(search) -> llm_call(answer) -> response

Trace 把这些都记成嵌套 span,像 Jaeger 或 OpenTelemetry trace 但有 LLM 特定字段。你看到:

• 完整时间轴。
• 哪一步造成延迟。
• 哪次检索返回哪些文档。
• 模型为什么选工具 X(它完整的推理文字)。
• 错误发生在哪。

对 agent 来说 trace 是必备。没有它,debug「agent 在第 4 轮做错事」是不可能的。

第 3 层:eval

Eval 是 LLM 行为的测试。两种:

• 离线 eval。 固定的输入 + 预期行为数据集,每次改 prompt 或换模型就跑,有 regression 就挡 deploy。RAG evaluation 那篇有详细介绍。
• 在线 eval。 对真实生产流量近实时打分。LLM-as-judge 跑在抽样 X% 对话上,标出低质量答案让你 review。

组合起来很强:离线在 deploy 前抓蓄意破坏,在线抓 eval set 没涵盖的真实使用漂移。

2026 工具现况

主要玩家、各自强项跟弱点:

• Langfuse(开源)。trace 很强、原生 eval 支持、可自架。对成本敏感团队的默认选项。
• LangSmith(LangChain)。如果你已经在 LangChain/LangGraph 上,首选。深度整合、付费。
• Helicone(开源)。轻量,proxy 方式接入很容易。入门好用。
• Arize Phoenix(开源)。RAG 特定指标跟视觉化很强。
• Honeyhive / Galileo / Patronus(商用)。企业导向,更多 guardrails-as-a-service。
• OpenTelemetry GenAI semantic conventions。 LLM tracing 正在浮现的标准,上面工具都在向它收敛。

2026 年从零开始:Langfuse 自架或 Helicone proxy 都行,两个都不到一小时搞定。等规模长大再重评。

该设告警的四个信号

Observability 接好之后,dashboard 跟告警设在这些上:

1. 每用户 / 每请求成本。 一个 bug 把 token 用量翻三倍会悄悄把你的账单翻三倍。任一单一用户超过中位数 10 倍就告警。
2. 失败率。 API 错误、timeout、拒答。爆冲代表有东西坏了(厂商宕机、key 过期、prompt 改过头撞 context)。
3. 延迟 p95。 LLM 延迟会漂。同一个 prompt 在 UTC 下午两点跟晚上八点可能差 3 倍。p95 超过 8 秒通常代表你该上 streaming。
4. 质量信号。 用户赞踩、解决时间、重试率。最难打点但最重要。如果质量周对周掉 10% 你没发现,你的产品在悄悄死掉。

有了 observability 之后可以做什么

以前做不到的事突然可以了:

• 任何 bug 几秒内重现。 点一个 trace,复制 exact request,对任何模型重播。
• 科学地比较模型升级。 把上个月流量重跑 GPT-5 跟 Claude 4.7,看谁在你真实分布上比较好。
• 追踪 prompt 变动。 每个 prompt 标版本,看每版本在几千次对话上的表现。
• 抓最烂 1%。 按用户踩数或延迟排序对话,修长尾不修平均。
• 成本优化。 看哪个 prompt 太肥、哪些检索文档多余、哪个模型 tier 大材小用。

什么时候还不要投资

• 单人创始人、第一天、没用户。 Console.log 就够,时间花在出货。
• 原型阶段。 先把原型出去拿 10 个用户,再加 observability。太早加 observability 是沉没成本。
• 单一短 prompt、没有 agent、没检索。 把 input/output 记到 DB 表就好,别过度工具化。

认真投资的触发点:你开始一周问「它为什么这样?」超过一次而且答不出来。

务实起手栈

2026 年有真用户的产品:

• Langfuse 自架 做 trace 跟 log(免费、开源)。
• 30 题回归 eval 放版本控制,每次 prompt 改在 CI 跑。
• PostHog 或 Mixpanel 做用户层事件(signup、chat_completed、thumbs_down),让质量信号接回产品指标。
• Sentry 处理真 bug(typeerror、500)—— 不是 LLM 特定但还是需要。
• 每周 review 会议 找人读 50 段随机对话。最便宜、信号最强的 eval。

等这套不够用再升级花俏工具。

下一步

• Langfuse 文档跟范例。
• OpenTelemetry GenAI semantic conventions(W3C 草案)。
• Honeycomb 博客的 observability 基础(通用,不是 LLM 特定,但心智模型可转移)。
• 查这些词:LLM-as-judge、online evals、drift detection、prompt versioning。