LLM 应用的可观测性
在传统应用中，可观测性通过采集日志、指标和追踪信息，帮助开发者了解系统内部状态。对于 LLM 应用，可观测性还包括监测和理解模型的输入、输出及中间步骤，以保障可靠性。LLM 具有不确定性，相同输入可能得到不同甚至出乎预期的结果，因此调试比常规应用更有挑战。可观测性通过记录模型交互与性能数据，帮助开发者了解这些“黑箱”模型。
有效的可观测性为何重要
- 可靠性与调试：当 LLM 应用返回错误、异常的回答，或者运行报错时，开发者需要迅速查明原因。结构化日志、详细追踪等方法可以记录请求经过的各个组件，支持根本原因分析。例如，聊天助手回答错误时，可以据此判断问题来自不合适的提示词、检索失败，还是模型幻觉。
- 优化与性能：用户希望 LLM 应用快速、高效，但模型可能响应缓慢或消耗大量资源。可观测性可以记录延迟、吞吐量等关键指标，定位性能瓶颈。监测请求延迟、token 使用量和系统资源，可以识别需要优化的环节。使用量数据也有助于发现提示词或模型选择中的低效之处，从而优化成本。
- 注意：多数现代 LLM 可观测性平台尚未直接提供系统资源指标的原生追踪能力。
- 质量保障：开发数据可能无法覆盖真实使用中的全部交互方式，用户也可能触发边界情况。可观测性有助于监测生产环境的输出质量，例如统计令人不满意或包含幻觉的回答出现频率。记录输出及用户反馈，可以及时发现回答与预期要求之间的差距。
LLM 应用的可观测性通过收集和分析应用行为产生的日志、指标与追踪数据，帮助开发者理解、调试和改进具有不确定性的系统。
可观测性的三项基础
现代可观测性通常包含日志（Logs）、指标（Metrics）和追踪（Traces）。它们在 LLM 系统中的用途如下。
日志
日志记录应用运行中的事件和数据，包括输入、输出及错误。对于 LLM 应用，建议采用结构化日志记录提示词和响应，主要包括：
- 用户输入和提示词：记录发送给 LLM 的提示词，包括系统提示词。输出错误时，可以追溯产生该输出的提示词。还可以记录所用提示词模板的版本，从而支持提示词版本管理。
- LLM 输出：记录模型的原始输出。如果应用还会解析或转换输出，可以同时保存原始文本和解析结果，这些数据有助于分析失败原因。
- 错误与异常：记录 LLM API 返回的限流、超时等错误，以及应用自身的代码异常。统一记录错误有助于统计失败率，并判断问题来自应用逻辑还是外部 API。
- 元数据：每条日志可以附带时间戳、请求或会话 ID、使用的模型名称等信息。这些信息支持日志筛选，例如查找某个模型版本的全部输出，也有助于按时间顺序调查问题。
LLM 应用的日志范围通常比部分传统应用更加广泛。记录全部请求和响应，可以在之后检索特定交互，例如查找模型多次陈述某个错误事实的记录，并审查系统行为。
指标
指标是随时间追踪 LLM 应用性能和使用情况的数值。应当确定一组关键监测指标，常见指标包括：
- 延迟：处理一次请求所需的时间。可以监测从用户请求到最终回答的端到端延迟，也可以分别统计 LLM API 调用、检索等步骤的耗时。监测延迟有助于发现性能下降。
- 吞吐量与请求速率：每秒或每分钟处理的请求数量。这有助于确认系统能够扩展，并将成本控制在预设范围内，也能发现流量突增或一天内的流量变化规律。
- token 使用量：追踪每次请求的输入和输出 token 数量，以监测和优化成本。如果提示词过长，或者模型生成了没有必要的长回答，指标能够反映这些情况。监测单次请求和一段时间内的 token 总量，可以发现意外的成本增长。
- 提示词长度：以 token 数或字符数记录提示词长度。提示词模板或检索上下文过长，可能拖慢响应或超过模型限制。监测长度有助于遵守上下文限制，并优化提示词构建方式。
- 错误率：监测产生错误或失败的请求比例，也可以按错误类型分别统计。错误率升高意味着可靠性出现问题。例如，如果 5% 的请求超时，就需要及时了解并调查原因。
- 资源使用量：理想情况下，还应追踪 CPU、GPU 利用率及内存使用量等系统指标。许多 LLM 应用主要调用外部 API；如果自行管理模型服务器或向量数据库，这些指标尤其重要。
- 评估分数：这里关注生产环境的评估。在预算允许的范围内，应对生产流量执行 LLM 评估，发现此前未覆盖的边界情况。这些数据对系统持续开发也很重要。
采集指标后，可以建立仪表板并追踪变化趋势。例如，一个仪表板显示每小时的平均延迟和吞吐量，另一个显示每天的 token 总消耗量及成本。
追踪
追踪记录请求经过 LLM 应用各个组件的执行流程。一次 trace 表示一次用户交互从开始到结束的完整过程，由一个或多个 span 组成；每个 span 对应工作流中的一个步骤或操作。
下面展示一个朴素检索增强生成（RAG）工作流的追踪示意图。
trace 表示端到端的数据流，从用户提交查询开始，到用户收到答案结束。
这一流程包含三个主要 span：
A．查询改写与增强
包含一个子 span：
1．改写用户的原始查询。
B．检索
包含两个子 span：
2．为查询生成嵌入。
3．从向量数据库中检索与查询嵌入最接近的前 k 个元素。
C．生成
同样包含两个子 span：
4．将用户查询和检索上下文填入提示词模板，生成完整提示词。
5．将完整提示词提交给 LLM，并把生成的答案返回给用户。
追踪有助于理解复杂 LLM 应用的执行过程，尤其适用于调用链或智能体等包含多个步骤的系统。在这个例子中，追踪信息可以显示哪个步骤最耗时。例如，向量搜索耗时 500 毫秒，LLM 调用耗时 2 秒，开发者就能据此定位瓶颈。
追踪在 LLM 应用中的主要价值包括：
- 端到端可见性：完整 trace 展示请求经过系统的路径。对于每次用户查询，可以查看数据检索、智能体调用的工具、LLM 回答生成以及后处理等子操作。智能体和多步骤系统的执行顺序可能动态变化，按时间展示的追踪记录有助于重现实际过程。
- 各步骤延迟：trace 记录每个 span 的耗时，便于了解时间消耗的位置。例如，用户反映响应缓慢时，可能发现 90% 的时间用于 LLM 调用；使用多个工具时，也可能发现某次搜索 API 调用耗时最长。
- 逻辑与错误调试：trace 通常记录每个 span 的输入和输出。出现错误时，可以定位出错的 span。最终答案有误时，可以检查中间步骤，例如检索环节可能缺少上下文，或者检索内容与问题无关。
- 理解智能体决策：对于动态决定是否调用工具等操作的 LLM 智能体，追踪可以帮助理解其思维链。逐步查看执行过程，有助于分析智能体为何执行某个动作，或者为何持续重复某个循环。
观察 LLM 应用，需要同时关注系统性能，例如延迟、吞吐量、错误和成本，以及模型行为，例如回答内容、出错频率和输入处理方式。为这些信息设置仪表板和告警，AI 工程师就能及时发现异常并持续改进应用。