LLM 应用的可观测性：记录真正要紧的东西

传统应用要么正常工作，要么抛出错误，崩溃时你读堆栈跟踪就行。LLM 应用却有第三种状态，它远为常见、也远为难调：它运行正常、不报任何错，却产出一个微妙地、或彻底地错误的答案。没有异常可捕获。LLM 应用的可观测性，就是这样一种实践——对每次交互捕获足够多的信息，好让"它给了个糟糕的答案"变成一个你真能去调查的问题。本文讲清该记录什么、为什么，以及如何做到这一点而不被数据淹没。

为什么普通监控不够用

经典的可观测性盯的是错误、延迟和资源占用。这些仍然要紧，但它们漏掉了语言模型独有的故障模式：一次彻底成功、却返回了错误内容的调用。HTTP 状态没问题，延迟正常，没什么着火——而输出是幻觉的、偏离指令的，或不安全的。

要调试这个，你需要看到交互的内部。究竟是什么提示送进了模型，包括运行时拼装的那些部分？模型返回了什么？检索并注入了什么上下文？当时上线的是哪个版本的提示？这些都无法从基础设施指标里看到。LLM 可观测性的存在，就是为了让每次交互的内容在事后可供检查，因为在某样东西出错的那一刻，唯一耐久的证据就是你记录下来的东西。

核心记录：捕获完整的交互

地基是一份对每次模型交互足够完整、能重建发生了什么的记录。它至少意味着：

• 完整的已解析提示。 不是模板——而是实际发送的文本，已填入所有变量、检索到的上下文以及对话历史。Bug 极常出在拼装出来的东西里，而不在你写的那个模板里。
• 完整的回应。 模型究竟返回了什么，在你的后处理对它重塑或截断之前。
• 模型与参数。 用了哪个模型，以及那些塑造行为的设置，比如 temperature。同一个提示在这些设置下表现各异。
• 提示版本。 当时上线的是哪个版本的提示，好让一次回退能与某个具体改动挂钩。

有了这四样，多数"它为什么那么干"的调查就变得可处理了。没有它们，你就是在猜。要养成的纪律是记录已解析的状态，因为你本意的模板与你实际发出的提示之间的那道缝隙，藏着出人意料比例的 Bug。

追踪整条链路，而不只是模型调用

现代 LLM 应用很少只是单次调用。一个请求可能先检索文档、调用模型、调用一个工具，然后再次调用模型。当最终答案出错时，原因可能在任何一步——糟糕的检索、一个格式错乱的工具结果，或者模型本身。

这正是追踪与记录同等重要的原因。一条追踪把处理同一请求的每一步串成单一的、有链接的时间线，让你能从输入跟到输出，看出它在哪里跑偏。是检索到了错误的文档吗？那就是模型在糟糕的上下文上正确地推理了，修复点在检索，而非提示。还是检索成功了、但模型忽略了上下文？那就是另一种完全不同的修复。没有端到端的追踪，多步系统几乎无法调试，因为你说不清是链条里哪一环失败了。

值得长期关注的指标

除了逐次交互的记录，还有少数几个聚合信号能告诉你系统在生产中是否健康。

• 延迟，包括首字时间。 对流式体验来说，多久开始有输出往往才是用户真正感受到的，这与总完成时间不同。
• Token 用量。 每个请求消耗的 token 直接映射成本，并随着提示和上下文增长而悄悄爬升。盯住它能及早抓住昂贵的漂移。
• 错误率与拒答率。 既包括硬性失败，也包括模型推托或含糊其辞这种更软的模式。拒答率上升往往预示着一个值得调查的提示或政策问题。
• 吞吐量与流量。 作为基线流量，好让异常在它的映衬下凸显出来。

这些并不能告诉你答案是否好——只能告诉你系统是否运转正常。它们是预警层：当某个指标变动时，你就去逐次交互的日志里找出原因。把它们当作趋势来追踪，而非单点，因为一个数字只有对照它自己的历史才有意义。

评判质量，而不只是活动量

最难观测的，是输出是否真的好，因为通常并没有单一的正确答案可供比对。有几种务实的做法能让质量至少部分可见。

在有用户信号时就捕获它们——明确的赞或踩，或者诸如用户重试、放弃、编辑输出这样的隐式信号。这些信号嘈杂却真实，它们会把你引向那些值得检视的交互。维护一组经过精选、有代表性的输入，并在上线前用新的提示或模型版本跑一遍，好让你能刻意地比较质量，而不是在生产中才发现一次回退。再以固定节奏抽样真实交互供人工审查；对实际输出的一点点例行阅读，能抓住任何指标都浮现不出来的漂移。要点不是把判断完全自动化，而是不再盲飞。

负责任地记录日志

捕获完整的提示和回应，意味着捕获用户键入的一切——其中可能包含个人或敏感信息。可观测性不能变成一个悄悄滋长的数据留存问题。

从一开始就把隐私内建进去。清楚知道存了什么，在可以的地方对敏感字段做脱敏或干脆不存，设定留存期限好让日志不至于永久堆积，并控制谁能读取它们。这里有一个真实的张力：你的日志越丰富，你的调试越好，而这些日志一旦泄露，你的暴露面也越大。要刻意地去化解它，而不是任其听天由命。OpenAI 和 Anthropic 的官方文档描述了它们各自的数据处理方式，这是图景的一部分，但你存了什么，是你自己要去治理的责任。

从小处起步，逐步生长

你不需要第一天就上一整套可观测性平台，假装需要是一种永远没法起步的好办法。先从核心记录做起——已解析提示、回应、模型和提示版本——记录每一次交互。单是这一步就能让多数早期调试成为可能。当你的系统长到超过单次调用时，再加上追踪。当你的流量足够大、趋势开始有意义时，再加上聚合指标。当你真要认真调优提示和模型时，再加上质量评估。每一层都凭实力赢得自己的位置；按你的应用实际成长的顺序去搭建它们，而不是一股脑全上。

总结

LLM 应用会以传统监控看不见的方式失败——一次成功的调用返回了错误的答案——所以可观测性必须看进每一次交互的内部，而不只是看它周围的基础设施。记录完整的已解析提示与回应，连同模型和提示版本；端到端地追踪多步请求；把延迟和 token 用量当作趋势来看；并想办法抽样质量，而不是想当然地假定它好。从一开始就把隐私设计进去，并随着系统成长而逐层生长。回报是，"它给了个糟糕的答案"不再是一个耸肩，而成了一个你能回答的问题。