LLM 可观测性的独特挑战

传统的软件监控关注的是 CPU、内存、响应延迟和错误率等相对确定的指标。LLM 应用的可观测性则面临着截然不同的挑战：输出是非确定性的——同样的输入你永远无法期待完全相同的输出；质量是多维度的——准确性、相关性、安全性、公平性、格式合规性，每一个维度都可能出问题；链条是长的——一条用户请求可能经过 Prompt 模板渲染、LLM API 调用、多个 Function Call、RAG 检索、再聚合，任何一个环节的偏差都可能导致最终输出的失败。这意味着我们需要重新定义”系统正常工作”的含义。

可观测性三支柱：追踪、指标与日志

经典的可观测性三支柱在 LLM 场景下同样适用，但内涵有所扩展。**追踪（Tracing）**记录一次用户请求从入口到最终响应的完整路径，对于 LLM 应用而言，追踪不仅需要覆盖 LLM API 调用本身，还要覆盖检索增强生成（RAG）中的文档检索、工具调用（Function Calling）、多步推理链（Chain/Agent）等环节。**指标（Metrics）**提供聚合层面的系统健康状态，核心指标包括 TTFT（首 Token 延迟）、TPOT（Token 间平均延迟）、端到端延迟、Token 消耗与成本、工具调用成功率和幻觉发生率。**日志（Logging）**记录每次调用的完整上下文（Prompt、参数、输出、Token 数、延迟、错误），为后续的问题回溯和数据集建设提供原料。

核心指标体系详解

深入理解各项指标有助于建立准确的监控模型。**TTFT（Time to First Token）**衡量从请求发出到第一个 Token 返回的时间，直接影响用户感知的响应速度——这个值超过 2 秒用户就会明显感到等待。**TPOT（Time per Output Token）**是输出阶段每个 Token 的平均生成时间，决定了一段长回答全部展示完毕需要多久。Token 用量与成本是现代 LLM 监控的核心指标——一次对话可能消耗几千到几十万 Token，在规模化的生产环境中，Token 成本的波动通常是运维团队最先注意到的问题信号。工具调用准确率衡量 Agent 在 Function Calling 时是否选择了正确的工具和参数，一次工具调用错误可能导致整个任务链失败。质量分数是对每次输出做自动化评估后得到的数值，通常由评估模型（LLM-as-a-Judge）或专门的质量分类器给出。

追踪结构的设计

一次典型 LLM 应用请求的 Trace 结构通常包含以下 Span 层级：顶层 Span 代表一次用户请求的完整生命周期；其下依次展开 Prompt 模版的渲染、RAG 检索的调用（包含 Embedding 生成和向量搜索两个子 Span）、LLM API 调用（记录模型名称、Prompt Token 数、Completion Token 数、采样参数）、工具调用的执行（记录工具名称、输入参数和返回结果），以及最终响应的组装。每个 Span 应当携带完整的输入输出快照，这在后期分析一个失败案例时是无可替代的诊断资料。

LangSmith 与 LLM 原生追踪

LangSmith 是 LangChain 生态下的 LLM 可观测性平台，围绕几个核心概念构建：Traces 对应一次完整的执行链路；Runs 是 Trace 内的单个步骤；Feedback 允许开发者或评估器对运行结果进行标注（如评分、纠错、偏好选择）。LangSmith 的特色在于它与 LangChain 的深度集成——使用 LangChain 构建应用时，几乎不需要额外代码就可以实现全链路追踪。此外 LangSmith 还提供了数据集管理、人工标注工作流和在线评估等功能，使其不仅仅是一个监控工具，更是一个 LLM 应用的迭代开发平台。

OpenTelemetry 在 LLM 领域的应用

OpenTelemetry（OTel）正在成为 LLM 可观测性的行业标准。OpenLLMetry 等扩展项目将 OTel 的 Span 和 Attribute 体系适配到 LLM 场景，定义了语义化的属性命名规范（如 llm.request.type、llm.usage.total_tokens、gen_ai.system）。OTel 的传播机制使得跨服务的上下文关联成为可能——从 API 网关到 Agent 服务到 LLM API 再到向量数据库的一次完整调用，可以在不同的后端系统之间无缝传递 Trace 上下文。结合 Jaeger 或 Grafana Tempo 等 OTel 兼容的可视化后端，团队可以构建出与架构解耦的可观测性平台。

质量监控与漂移检测

LLM 应用的存在一个”静默退化”问题——服务没有报错、延迟没有上升，但回答质量却在不知不觉中下滑。导致退化的原因可能是上游模型更新后行为改变、检索库内容过时、用户输入分布发生偏移等。建立质量监控需要两步：首先定义一组有代表性的评估用例（即”黄金数据集”），然后持续对新输出执行自动化评估。当质量分数连续下降超过预设阈值时触发告警。统计层面的漂移检测则可借助 KL 散度或 PSI（Population Stability Index）来监控输入输出分布的变化。

成本监控与优化

在按 Token 计费的商业模式下，成本监控本身就是可观测性的重要组成部分。具体做法是：在每笔 LLM 调用的 Span 中标记本次调用的 Prompt Token 数、Completion Token 数及对应的成本金额，通过聚合计算每小时/每天的成本趋势。优化方向上，重点关注 Token 浪费的常见模式：Prompt 过长（尤其是反复携带重复的示例或上下文）、不必要的长输出、以及 Agent 循环中重复调用相同工具的情况。设置每日成本预算告警可以有效防止财务上的意外。

仪表盘与告警设计

一个合格的 LLM 应用监控仪表盘应该包含以下面板：总体请求量与延迟趋势（按分钟聚合）、Token 消耗与成本曲线、错误率（区分 4xx 调用错误和 5xx 服务错误）、质量分数的分布直方图、按模型维度拆分的调用量统计。告警规则建议至少覆盖：P95 延迟超过阈值、Token 成本超过日预算的 80%、5 分钟内错误率超过 5%、质量分数平均值连续两个评估窗口低于阈值。

生产事故响应

当告警触发时，有效的问题定位需要良好的 Trace 数据做支撑。标准排查流程如下：首先查看聚合指标确定故障范围（是全量还是某类请求、是延迟上升还是错误率增加）；然后下钻到代表性 Trace 逐一检查每个 Span 的详细信息；重点关注异常 Span 的输入输出——很多问题在这一步就能找到根因（如 Prompt 渲染结果异常、检索返回无关文档、LLM 返回格式不符合预期）。建立事后复盘（Postmortem）机制，将每次生产事故转化为一个评估用例，有助于系统性地提升应用质量。

工具生态对比

目前的 LLM 可观测性工具可以大致分为三类。全栈平台以 LangSmith 和 Arize Phoenix 为代表，提供从追踪到评估到数据集的完整工作流。LangSmith 深度绑定 LangChain 生态，适合以 LangChain 为主力框架的团队；Phoenix 则更加模型无关，且开源免费。成本与分析工具以 Helicone 为代表，聚焦于消费级的 Token 用量监控和成本优化分析，UI 简洁直观，适合早期和中等规模的项目。传统 ML 监控平台以 Weights & Biases 为代表，从实验跟踪延伸至生产监控，在需要训练和推理统一管理的场景下最为合适。选型时建议先从团队的技术栈和预算出发，优先选择一个与现有框架集成度最高的方案。