从可用到可控：LLM应用为何需要可观测性

随着大语言模型应用进入生产环境，传统系统监控已难以解释回答质量、成本波动和链路异常。LLM可观测性通过追踪请求、提示词、检索、工具调用与模型输出，帮助团队建立从故障定位到持续优化的完整闭环。

大语言模型应用的上线，并不意味着工程问题已经解决。相反，当应用开始面对真实用户、复杂任务和持续增长的调用量时，团队往往会遇到一系列传统监控难以回答的问题：为什么同一个问题在不同时间得到不同答案？一次错误回答究竟来自提示词、检索结果、模型本身，还是外部工具？成本为何突然升高？延迟增加又发生在哪个环节？

这些问题推动了LLM可观测性的形成。它不是简单地给模型调用增加几条日志，而是围绕大模型应用的输入、推理过程、外部依赖和输出结果，建立可追踪、可分析、可评估的运行体系。

LLM可观测性究竟要观察什么

传统软件可观测性通常依赖日志、指标和链路追踪，重点关注服务是否可用、请求是否成功以及系统资源是否充足。LLM应用同样需要这些能力，但还必须补充语义层面的信息，因为一次HTTP请求成功，并不代表应用真正完成了任务。

在LLM应用中，一次完整请求可能包含用户输入、系统提示词、上下文拼接、向量检索、重排序、模型调用、函数或工具调用、结果解析以及最终回复。可观测性需要将这些步骤关联起来，形成一条完整的执行链路。

为什么传统监控无法独立解决问题

在传统应用中，HTTP状态码为200通常意味着请求成功。但对LLM应用而言，状态码正常只能说明服务完成了通信，无法说明回答真实、相关、完整或安全。模型可能在没有报错的情况下生成事实错误，也可能因为上下文缺失而给出看似流畅但无法使用的结果。

此外，大模型输出具有概率性。同一套代码在不同模型版本、不同采样参数或不同上下文下，可能产生不同结果。因此，单纯记录CPU、内存和接口耗时，无法解释质量变化；单纯保存最终文本，也无法还原问题是如何产生的。

LLM可观测性需要把技术指标与语义指标结合起来。技术指标用于判断系统是否稳定，语义指标用于判断系统是否有效，二者共同构成生产环境中的质量判断基础。

一条完整的LLM链路应该如何记录

合理的追踪模型通常以一次用户请求作为根节点，并将每个关键步骤记录为可关联的跨度。根请求可以包含用户标识、会话标识、应用版本和环境信息；子跨度则分别记录检索、模型调用、工具执行和结果处理。

每个跨度至少应包含开始时间、结束时间、执行状态、输入摘要、输出摘要和错误信息。对于模型调用，还应记录模型名称、模型版本、温度、最大输出令牌数、输入令牌数、输出令牌数以及供应商返回的请求标识。

记录内容需要在完整性与隐私保护之间取得平衡。开发和测试环境可以保留更多原始输入，生产环境则应根据数据敏感等级进行脱敏、截断或加密。密码、访问令牌、个人身份信息和业务机密不应因为调试便利而被无条件写入日志。

提示词版本必须可追踪

提示词往往是LLM应用中变化最频繁、影响最直接的组成部分。生产系统不应只记录提示词文本，还应记录提示词模板的版本、发布批次、变量来源和所属实验组。这样，当质量发生变化时，团队才能判断问题来自模型升级、提示词修改，还是上下文数据变化。

检索增强生成需要观察证据链

对于检索增强生成应用，仅保存最终回答是不够的。系统还应记录原始查询、查询改写结果、召回文档标识、相似度或排序分数、最终注入上下文以及模型实际引用的内容。

通过这些数据，团队可以区分知识库没有相关信息、检索系统没有召回信息、上下文拼接出现截断，以及模型没有正确使用证据等不同问题。不同原因需要不同的修复方式，不能都归结为模型能力不足。

LLM可观测性的核心指标

指标设计不应追求数量越多越好，而应围绕用户体验、系统稳定性、模型质量和运营成本建立分层体系。指标既要能够形成趋势，也要能下钻到具体请求。

首令牌延迟和完整响应延迟应分别关注。前者反映用户多久开始看到反馈，后者反映任务何时真正完成。对于流式输出应用，二者对体验的影响不同，不能用一个平均响应时间替代全部判断。

从故障定位走向质量评估

LLM应用的质量评估通常需要自动评估、人工评估和用户反馈共同参与。自动评估可以用于大规模筛选，例如检查输出是否符合格式、是否包含必要字段、是否引用了指定来源。人工评估适合判断复杂任务中的事实性、表达质量和业务适用性。用户反馈则能够反映真实场景下的满意度和采纳行为。

评估结果应与原始追踪数据关联，而不是停留在孤立的评分报表中。例如，一次回答得分下降后，团队应能继续查看对应的模型版本、提示词版本、检索文档和工具结果。只有评分与链路结合，评估才具备诊断价值。

建立可重复的评估集

团队应从真实请求中整理具有代表性的测试样本，覆盖常见问题、边界问题、容易混淆的问题和高风险问题。评估集需要进行版本管理，并在模型、提示词、检索策略或工具逻辑发生变化时自动执行。

评估结果不应只关注平均分。平均分可能掩盖少数但严重的失败案例，因此还需要观察关键场景通过率、最差样本、不同用户群体之间的差异以及高风险错误数量。

成本与隐私是落地中的关键约束

LLM调用成本通常与输入和输出令牌数量直接相关。随着上下文变长、检索文档增多以及多智能体链路变复杂，单次任务的实际调用次数可能快速增加。可观测性应将成本拆解到应用、用户、功能、模型和请求级别，帮助团队识别高成本路径。

隐私保护同样不能后置处理。生产环境中的追踪数据可能包含用户问题、企业文档、客户资料和工具返回结果。系统应明确数据保留周期、访问权限、脱敏规则和审计机制，并为调试场景提供受控的数据还原能力。

一种更稳妥的做法是对敏感字段进行分类处理：对无需恢复的内容进行哈希或摘要，对需要排查的问题保留受控加密副本，对高风险字段直接删除或替换。观测数据越丰富，权限管理和数据治理就越重要。

常见误区与改进方向

• 只记录最终回答：这种方式无法判断错误发生在提示词、检索还是工具环节。应保存可关联的中间步骤和版本信息。
• 只看模型调用成功率：调用成功不等于回答正确。应增加任务完成率、事实性和安全相关指标。
• 无差别记录全部原文：这会增加隐私和合规风险。应根据数据敏感等级进行脱敏和访问控制。
• 只依赖人工抽查：人工评估难以覆盖大规模请求。应将人工样本与自动规则、用户反馈结合起来。
• 把所有问题归咎于模型：很多质量问题实际上源于知识库、权限、工具或上下文构造。应沿链路逐层排查。
• 没有变更关联：如果不知道何时修改了提示词或升级了模型，就很难解释指标波动。应建立发布记录与追踪数据的关联。

构建落地路线

LLM可观测性不必从复杂平台开始。第一阶段应先统一请求标识、模型调用记录、错误分类和令牌统计，确保团队能够回答请求去了哪里、耗费了多少资源以及在哪一步失败。

第二阶段可以补充检索和工具链路，建立提示词与模型版本管理，并将关键业务场景纳入离线评估。此时，系统不仅能定位故障，也能比较不同方案的质量、成本和延迟。

第三阶段则应建立面向生产的质量监控和自动化反馈机制，包括异常检测、质量回归告警、敏感信息检测、用户反馈闭环以及模型和提示词的灰度发布。对于高风险业务，还需要引入人工审核和明确的降级策略。

结语

LLM可观测性的核心，不是把更多数据堆积到监控平台，而是让团队能够理解一次模型任务从输入到输出的完整过程，并将技术运行状态与业务结果联系起来。

当应用能够追踪提示词、检索证据、模型调用、工具执行和最终反馈时，LLM系统就不再是难以解释的黑箱。团队可以更快定位故障，更准确评估质量，更有效控制成本，也能在模型和业务持续变化的情况下建立稳定的改进闭环。