大型语言模型（LLM）应用既会遇到普通软件的故障，也会增加概率性输出、模型与提示词漂移、工具行为、检索质量和随用量变化的成本等问题。有些故障会留下堆栈跟踪，另一些则只能从输出评估、用户报告或数据分布变化中发现。
传统可观测性工具（如 Datadog、New Relic 和 Sentry）可以告诉你 API 调用在 8.4 秒内成功完成，并使用了 12,847 个输入 token。但它无法判断响应质量是否合格、模型是否产生幻觉、是否调用了错误工具，或质量是否从上周开始发生漂移。
生产环境中的 LLM 系统需要在常规追踪、指标和日志之外补充语义数据。可以从 OpenTelemetry 生成式 AI 语义约定开始，仅在产品确有需要时扩展。本文给出一个示例事件结构；AI Expert 尚未发布生产追踪或仪表板来证明以下所有字段都已落地。
LLM 可观测性的不同之处
传统可观测性无法充分覆盖以下 LLM 系统特征：
单次调用具有非确定性。 相同输入在不同调用中可能产生不同输出。仅检查状态码，无法回答“这次执行是否正确”。
质量是核心指标。 延迟和成本固然重要，但质量往往最关键，也最难衡量。
多步骤追踪。 一个用户查询可能触发多个模型、检索和工具调用。每个操作都属于一个更大的追踪过程。
随用量变化的成本。 成本会随着模型、token 数量、缓存、工具和服务提供方的具体收费项目而变化。应在调用或批次层面归因实际计费用量，而不是假设一个通用的单次调用成本区间。
随时间推移的漂移。 模型会更新，提示会演变，输入分布会变化。质量在变化，你需要看到这种变化。
敏感载荷。 输入和输出通常是最有价值的诊断数据，但同时也是最敏感的信息，因此必须严格控制日志记录。
长时间异步流程。 智能体运行可能持续数分钟，还包括后台批处理和流式响应。传统的请求/响应可观测性方法不足以覆盖这些流程。
遥测设计应揭示这些故障模式；其中哪些最常见，必须根据自身实际流量判断。
可观测性堆栈
一套实用的 LLM 可观测性设计可以包含以下层次，具体选择取决于工作负载和风险：
1. 调用级遥测。 每次 LLM 调用都记录经批准的运行元数据，例如延迟、计费用量、模型与版本以及状态。只有在另有正当依据并落实控制措施时，才采集原始输入或输出。
2. 追踪级遥测。 将工作流中的多次调用关联为一条追踪，从而查看一次用户请求的完整调用链。
3. 应用级指标。 按功能、按用户、按租户的聚合数据。
4. 质量监控。 对样本或全部进行自动化质量评估。
5. 用户反馈收集。 显式（点赞/点踩）和隐式（重新生成、放弃）信号。
6. 告警机制。 及时发现成本激增、延迟恶化、质量下降和错误率上升。
7. 调试工具。 当出现问题时，授权响应人员可以检查理解问题所需的最低批准证据；原始输入和输出并不保证或普遍可用。
我们将逐一讲解。
调用级遥测
每次调用大型语言模型（LLM）都应生成一条经过批准的元数据记录。下方带注释的载荷与身份字段属于可选敏感字段，不应默认采集：
{
"call_id": "uuid",
"timestamp": "2026-08-04T14:23:45Z",
"trace_id": "uuid", // 用于归并为追踪
"span_id": "uuid", // 用于父子关系
"feature": "summarize_document",
"prompt_version": "v3.2",
"model": "provider-model-revision",
"provider": "anthropic",
"input_messages": null, // 可选；仅限经过批准的抽样或脱敏载荷
"output_message": null, // 可选；仅限经过批准的抽样或脱敏载荷
"input_tokens": 1842,
"output_tokens": 384,
"total_tokens": 2226,
"cost_usd": 0.0084,
"latency_ms": 2340,
"first_token_ms": 1240, // 流式传输
"status": "success",
"error": null,
"subject_ref": "pseudonymous_ref", // 可选；仅用于特定目的的查询
"tenant_ref": "tenant_scoped_ref",
"metadata": {
"session_id": "...",
"experiment_arm": "v3_test"
}
}
这是一个示例应用事件，而不是强制采用的 schema。只采集已定义运维目的所需的最少信息。原始提示词和输出属于可选的敏感载荷，而不是默认遥测数据。
关键实现选择：
记录位置。 选项：
- 专用的可观测性工具（如 Helicone、LangSmith、Phoenix、Braintrust、Arize）。
- 具备 LLM 扩展功能的通用可观测性平台（如 Datadog LLM Observability、Sentry）。
- 你自己的日志/数据库。
根据以下需求做出选择：OpenTelemetry 导出、追踪和工具调用可视化、数据位置、自托管、脱敏、访问控制、保留/删除 API、模型价格维护、评估支持和总成本。专用工具、现有 APM 或小型自有实现都可能是正确选择；在确定之前，请先测试导出和删除功能。
如何接入遥测。 选项：
- 位于应用程序与 LLM 提供方之间的代理（如 Helicone 的模式）。
- 在应用程序代码中使用封装 SDK。
- 为每次 LLM 调用手动调用封装类。
代理可以集中接入遥测，但会增加一次网络跳转和一个故障域。SDK 封装把遥测留在进程内，却会让代码与该集成耦合。手动封装可以更精确，但需要覆盖率测试。应测量所选方法的额外开销和故障行为。
一种务实的方法是在应用调用 LLM 的边界处进行 SDK 封装。只需接入一个位置，其余调用都会经过这里。
应记录哪些内容。 在启用载荷采集之前，应先应用数据分类和保留策略。根据 GDPR，第 5 条数据最小化和存储限制原则 仍适用于可观测性数据。
- 优先记录提示版本、哈希值、令牌数量、策略决策和派生指标，而非原始内容。
- 如果采集载荷有正当理由，应对其进行抽样、在导出前进行脱敏、加密、限制访问，并设置较短的保留期。
- 不要仅仅因为记录了脱敏副本，就保留可自动检索的原始数据；这会重新创建敏感数据存储，并需要其自身的合法目的和控制措施。
- 即使在错误路径中，也不要记录凭证。
- 对于流式传输，应同时记录首次令牌延迟和总延迟。
追踪级遥测
一次用户操作通常涉及多次 LLM 调用。如果没有请求级追踪，你可能拥有上千条调用日志，却无法判断哪些调用属于同一次用户操作。
实现：
追踪 ID 生成。 在用户请求开始时生成一个唯一的追踪 ID，并将其传递给所有后续调用。
父子 span。 在一条追踪中，每个调用都有 span ID，还可以有 parent span ID，由此形成展示调用层级的树状结构。
操作命名。 每个 span 都有一个名称（例如“summarize_document”、“extract_entities”、“tool_call:search”）。追踪会显示完整的操作链。
用户界面中的追踪视图：
追踪 abc-123（总计 12.3s）
├─ classify_intent（意图分类，450ms）[small-model-revision]
├─ retrieve_documents（检索文档，1.2s）[embedding + search]
├─ generate_response（生成响应，8.5s）[generation-model-revision]
│ ├─ tool_call: search_internal（搜索内部资料，320ms）
│ ├─ tool_call: lookup_customer（查询客户，180ms）
│ └─ generate_final_text（生成最终文本，7.5s）
└─ judge_response_quality（评估响应质量，2.1s）[claude-haiku-4-5]
现在你可以清楚地看到系统实际上为该用户请求执行了哪些操作。你可以在此上下文中找到缓慢的调用、耗费资源的调用、失败的调用等。
候选实现包括专门的 LLM 可观测性产品和使用 OpenTelemetry 的通用 APM 系统。应在代表性试用中验证追踪传播、工具调用表示、导出、脱敏、删除、访问控制和失败行为，而不是仅依赖产品列表。
应用层指标
除了单个调用之外，还可以汇总指标：
按功能划分。
- 调用次数。
- 平均延迟。
- p50、p95、p99 延迟。
- 每次请求的平均成本。
- 错误率。
- 质量评分（如已测量）。
按用户/租户划分。
- 每用户每日调用次数。
- 每用户成本。
- 高频用户 / 滥用模式。
按模型划分。
- 各模型的调用量。
- 各模型的成本占比。
- 各模型的错误率。
- 各模型的质量（如已测量）。
按功能 × 模型划分。
- 哪些功能使用了哪些模型？
- 哪些地方可以路由到更便宜的模型？
这些仪表板驱动运营决策：哪些功能成本高昂，哪些运行缓慢，哪些需要优化。
质量监控
最难的层次：自动化质量评估。
离线评测（evals）是在预先定义的数据集上运行；在线质量监控则评估生产流量。
方法：
对样本使用 LLM 裁判。 根据流量规模、风险切片、隐私约束、检测目标和预算定义抽样规则。在符合条件的示例上运行经过校准的裁判模型，对有争议或影响重大的案例保留人工裁定，并按提示词和模型版本追踪结果。裁判模型存在位置偏差、冗长度偏差和自我偏好；它们是需要验证的测量工具，而不是真值来源。
隐性信号。 追踪重新生成、放弃、错误率、完成时间和后续消息频率。这些信号较弱，但采集成本低，可作为先行指标。
显性用户反馈。 赞成/反对按钮、“这有帮助吗？“按钮、明确的报告。信号最强但数据量最低。
模式检测。 特定的不良模式（如”我无法帮助你”、“我只是一个人工智能”、重复拒绝）会自动标记。可立即发现部分退化问题。
实施记录应说明抽样规则、排除的数据、评分标准、裁判模型版本、人工校准集、不确定性、聚合窗口、告警阈值和成本上限。从重复的基线运行中推导变化阈值，并根据漏检退化问题的严重性进行调整；照搬的百分比对于不同工作负载没有统计或业务意义。
成本可观测性
重试、循环、意外的长输入或输出、路由变更以及提供商价格变更都可能迅速推高成本。应直接检测每种机制，而不是假设一个乘数。
成本可观测性层级：
单次调用成本。 每次调用的成本在日志记录时计算。聚合数据可立即获取。
预算告警。 每个功能和租户设置每日、每周或每月预算，根据预测偏差和业务关键性选择预警和强制执行阈值。
异常检测。 将成本和使用情况与正确的流量组合基线进行比较，并分别限制异常单次运行中的循环次数、token 数、工具调用、重试次数、持续时间和支出。
成本归因。 按功能、租户和用户划分成本。找出主要消耗者。
预测。 根据当前趋势，月底账单金额将是多少？
一个实用的仪表板视图：一个面板显示今天的成本与本周其余时间的成本以及上周的成本，按功能分类。
根据实测流量和业务关键性设定预算限制。优先采用分阶段控制：先告警，再限制流量，然后降级非关键路径，最后触发熔断。通用的“达到 10 倍时关闭”规则可能反应过晚，也可能中断关键工作流。
延迟可观测性
大语言模型（LLM）的延迟比典型 API 更为复杂：
总延迟。 从请求到最终响应的总时间。
首次令牌生成时间（TTFT）。 对于流式传输，用户何时看到第一个字符？这在聊天用户体验中主导了感知延迟。
完整响应时间（TTLT）。 从请求发出到响应完全生成需要多长时间？
每秒令牌数。 输出速率。某些模型的流式处理速度比其他模型慢。
工具调用延迟。 对于智能体流程，应区分工具调用和 LLM 调用各自耗费的时间。
跟踪所有这些指标。不同的优化策略针对不同的指标。
对于面向用户的聊天，首令牌时间（TTFT）是一个重要的交互指标；总完成时间、输出速率、中断情况、任务成功率和可访问性也都很重要。应根据观察到的用户行为设定目标，而不是假设单一的延迟指标主导所有界面。
对于批量处理：总延迟很重要；吞吐量更为重要。
对于智能体：工具调用延迟往往占主导地位；如果工具本身很慢，优化 LLM 并无帮助。
错误可观测性
大语言模型特有的错误：
API 错误。 速率限制、认证失败、服务器错误。与任何 API 的错误相同。
验证错误。 结构化输出不符合 schema。按功能跟踪频率。
内容过滤错误。 提供方阻止了请求。用于检测提示词问题。
工具错误。 特定工具发生故障。按工具进行跟踪。
质量错误。 裁判模型将输出评为不合格。应随时间追踪其变化。
幻觉信号。 检测到可能的幻觉（模型声称了源材料中没有的内容）。难以自动检测，但可以进行近似判断。
成本错误。 调用成本远高于预期。通常表明存在错误。
每种错误都有自己的仪表板，也都可以触发告警。
调试工具
当某事物发生故障时，你需要找到它并理解它。调试界面包括：
追踪搜索。 通过追踪 ID、获批的假名化主体引用或时间戳查找事件，同时避免暴露更广泛的租户数据。
调用检查器。 默认显示元数据。只有通过角色检查，并遵守访问日志记录、目的限制和保留规则，才能显示经批准且经过最小化的请求/响应字段；许多部署永远都不应保留完整载荷。
追踪时间线。 对于复杂流程，可以直观地查看调用链。
受控重放功能。 是否可以在禁用工具或将工具置于沙箱的隔离环境中，重新运行经批准且经过最小化的输入？绝不要重放生产调用而触发现实副作用，也不要因为重放有用就认定保留载荷具有正当理由。
差异视图。 并排比较两次调用，例如同一提示词的不同版本或不同模型的调用。
通过已批准的内容或派生字段进行搜索。 在不将遥测系统转变为无限制的客户提示语料库的情况下，搜索定义的模式。授权、最小化、索引、保留和访问日志同样适用于搜索，而不仅仅是存储。
这些功能在不同产品之间存在显著差异。应在具有代表性的试用中验证这些功能，并在比较中包括集成、存储、隐私审查、迁移和运营工作；仅凭标价本身并不能证明购买更便宜。
隐私与个人身份信息（PII）
大型语言模型（LLM）的可观测性日志属于敏感数据。输入可能包含个人数据，输出也可能引用这些数据。有时会建议采集原始载荷以进行调试，但这并不当然意味着有必要或合法；应先明确目的，并优先考虑合成复现、派生字段或短期受控样本。
实践：
假名化/令牌化。 用特定用途的令牌替换直接标识符，并单独保护用于重新识别的映射。如果仍可重新识别，这些记录依然属于个人数据，不能视为匿名的“非 PII”数据。
日志生成时的脱敏处理。 在数据进入可观测性存储之前检测并脱敏个人身份信息（PII）。特定模式（如电子邮件、电话号码、社会安全号码）将被替换为占位符。
租户隔离。 多租户的可观测性数据按租户进行隔离。一个租户的数据对其他租户不可见。
访问控制。 明确谁可以查看原始输入和输出，并记录每次访问。
保留策略。 超过规定期限的日志将被删除或转移到冷存储。在许多司法辖区，个人身份信息的保留受到法律限制。
删除与限制流程。 确保遥测记录可通过为该目的批准的标识符查找，并在主存储、索引、导出和备份中执行法律顾问规定的操作。不要将口语化的“被遗忘权”理解为绝对承诺；GDPR 删除请求有相应条件和例外。
系统需要与所处理的个人数据和用途相称的控制措施。具体组合可能有所不同，但在启用载荷遥测之前，必须确定租户隔离、授权访问、最小化、保留、删除/限制处理和可审计性要求。欧盟委员会总结了删除请求的条件和例外。
告警
触发告警的阈值和信号：
成本。
- 实际支出或预测值超过该功能的预算范围。
- 每个请求的成本超过特定工作负载的上限。
- 成本变化率超过相同流量组合的基线范围。
延迟。
- 尾部延迟超出产品定义的服务目标。
- 首个令牌生成时间或完成时间超出交互特定目标。
- 工具超时或队列时间偏离基线范围。
错误率。
- 错误率超出工作负载的错误预算。
- 某类特定错误偏离其基线范围，包括验证错误和速率限制错误。
质量。
- 经校准的指标变化超出其多次运行的方差范围，或安全切片记录了任何不允许的结果。
- 用户反馈负面率高于基线。
- 重生成率高于基线。
模式。
- 特定的负面短语出现频率更高。
- 输入分布突然发生变化。
每条告警都应明确标识功能、时间窗口、实测值与预期值、受影响的切片、追踪链接和运行手册。除非循环或重试遥测支持该判断，否则不要在告警文本中直接诊断为失控运行。
多租户考虑因素
针对 B2B SaaS 应用：
按租户划分的指标。 每位客户可以看到自己的使用情况、成本和质量。
按租户划分的告警。 依据其特定阈值进行设置。
按租户进行调试。 支持人员可以看到客户的追踪信息（需具备适当的访问控制权限）。
按租户进行配置。 某些客户可能需要使用不同的模型、提示或策略。可观测性层会反映这些差异。
对于多租户系统，为了支持和计费，可能需要标明遥测所属租户并实施隔离，但这并不当然意味着可以访问原始追踪数据。应只向支持人员提供工作所需的最少数据和能力，记录其访问，并为敏感载荷设置升级处理路径。
工具生态系统（2026）
截至撰写时，LLM 可观测性工具的全景视图如下：
专用的 LLM 可观测性工具：
- Helicone、LangSmith、Phoenix（Arize）、Braintrust、PromptLayer 和 Weights & Biases Weave 是可用于验证上述要求的候选工具。
通用 APM 与 LLM 扩展：
- 当组织已经使用 Datadog 或 New Relic 平台时，可评估 Datadog LLM Observability 和 New Relic AI Monitoring。
- OpenTelemetry + 自选 APM 工具。 OTel 提供生成式 AI 语义约定；完成一次遥测接入后，可在多种工具中查看。
自行构建：
- 当系统范围有限且实现了必要的隔离、访问、保留、删除和索引控制时，小型数据库可能已足够。
- 添加一个简单的用户界面以进行搜索和显示。
- 与现有的日志基础设施集成。
记录所选方案、被拒绝的替代方案、数据流审查、退出/导出测试以及重新评估日期。没有一种默认的迁移路径适用于所有团队。
实用设置
按依赖关系和风险排序，而非通用日历：
阶段 1： 根据需求选择一个候选方案，并使用不含敏感信息的合成追踪进行试运行。验证导出、访问、脱敏、保留、删除、故障和退出路径，不能只验证数据采集。
阶段 2： 为已定义的服务目标添加仪表板，包括按功能划分的成本、延迟分布、错误类别、模型/提示版本以及缺失遥测率。
阶段 3： 在成本、循环、延迟和错误类别上设置基于工作负载的告警。
阶段 4： 关联跨越多次调用的 span，并验证追踪上下文能否通过工具和队列正确传播。
阶段 5： 实施已批准的质量抽样，并将自动化评分与人工判断进行校准。
阶段 6： 仅在对其解释、隐私处理和响应流程有明确定义的情况下添加用户反馈。
阶段 7： 添加具有授权和访问审计功能的租户特定视图和调试能力。
每个阶段的验收记录应包括测试、数据分类、负责人、故障行为和回滚。只有在有明确理由并采取补偿控制措施的情况下，才可以跳过某项功能。
没有它的后果
以下故障模式经常出现在缺乏适当 LLM 可观测性的团队中：
-
一个功能在紧密循环中重试调用，在账单审查之前累积了意外费用。
-
模型更新改变了行为，但请求未记录模型版本，导致归因延迟。
-
一个提示版本退化了重要的流程，但部署和响应追踪无法按版本进行比较。
-
智能体陷入循环，但由于缺少步骤预算和追踪级遥测，重复状态没有被及时发现。
-
工具认证失败会触发重试，但错误类别和重试的遥测数据未被关联。
-
一个提示注入路径会导致不安全的信息泄露，但由于缺少数据血缘和策略决策的遥测数据，无法进行影响评估。
这些是需要测试的失败场景。可观测性为检测和调查提供证据；除非执行控制根据信号采取行动，否则它不会阻止根本的失败。
在事件发生前进行监控
LLM 可观测性是对常规 APM 的扩展，而非替代。根据工作负载和威胁模型，选择有必要采集的调用、追踪、质量、成本、延迟、错误和调试信号，并将这些信号连接到经过测试的响应控制措施。
生产环境的声明应按场景展示检测时间、追踪完整性、可测量的告警精确率与召回率、预算控制行为、隐私测试，以及恢复或回滚证据。应在发布前接入遥测并演练运行手册，而且只公布实际测得的结果。
