LLM应用的故障方式不同于传统软件。普通缺陷会产生堆栈跟踪；LLM的“缺陷”则可能是质量漂移，往往要等用户投诉时你才会发现。普通延迟问题是某个端点响应缓慢；LLM延迟问题则可能是一段长达30秒的推理轨迹，用户只能盯着加载动画等待。
传统可观测性工具（Datadog、New Relic、Sentry）能告诉你API调用在8.4秒内成功完成，使用了12,847个输入token。它无法告诉你响应是否优质、模型是否产生幻觉、是否调用了错误的工具，或者质量是否自上周以来发生了漂移。
生产环境中的LLM系统需要不同的可观测性技术栈，或者至少要在传统技术栈之上增加额外层次。本文介绍其独特之处、需要插桩的内容，以及行之有效的模式。
LLM可观测性有何不同
LLM系统有一些传统可观测性无法处理的典型特征：
单元级非确定性。 同一输入在不同调用中会产生不同输出。仅检查状态码，无法回答“这次运行是否正确”。
质量是首要指标。 延迟和成本固然重要，但质量最重要，也最难衡量。
多步骤追踪。 一次用户查询可能触发5–50次LLM调用（智能体循环、RAG检索、结构化提取、反思）。每次调用都是更大追踪的一部分。
token级成本差异。 根据提示词大小、输出长度和模型，单次调用的成本可能从€0.001到€1.00不等。汇总成本需要归因到每次调用。
随时间漂移。 模型会更新，提示词会演进，输入分布会变化，质量也会随之波动；你需要看到这种变化。
敏感载荷。 输入和输出通常是最有价值的诊断数据，却也是最敏感的数据。日志记录规范至关重要。
长时间异步流程。 智能体运行可能持续数分钟，还有后台批处理任务和流式响应。传统的请求/响应可观测性并不适用。
这些不是理论上的担忧。每个运行生产级LLM系统的团队都会遇到。
可观测性技术栈
完整的LLM可观测性技术栈包含以下层次：
1. 调用级插桩。 记录每次LLM调用：输入、输出、延迟、成本、模型和状态。
2. 追踪级插桩。 将多次调用的工作流串联成追踪。你可以看到一次用户请求的完整调用链。
3. 应用级指标。 按功能、用户和租户聚合。
4. 质量监控。 对抽样流量或全部流量进行自动化质量评估。
5. 用户反馈采集。 显式信号（赞/踩）和隐式信号（重新生成、放弃）。
6. 告警。 针对成本激增、延迟恶化、质量下降和错误率上升的实时告警。
7. 调试工具。 发生故障时，你可以找到追踪、查看输入和输出，并了解实际发生了什么。
下面逐一介绍。
调用级插桩
每次LLM调用都应生成一条包含以下内容的日志记录：
{
"call_id": "uuid",
"timestamp": "2026-05-15T14:23:45Z",
"trace_id": "uuid", // 用于归入追踪
"span_id": "uuid", // 用于父子关系
"feature": "summarize_document",
"prompt_version": "v3.2",
"model": "claude-4-sonnet",
"provider": "anthropic",
"input_messages": [...],
"output_message": "...",
"input_tokens": 1842,
"output_tokens": 384,
"total_tokens": 2226,
"cost_usd": 0.0084,
"latency_ms": 2340,
"first_token_ms": 1240, // 流式传输
"status": "success",
"error": null,
"user_id": "user_123",
"tenant_id": "tenant_45",
"metadata": {
"session_id": "...",
"experiment_arm": "v3_test"
}
}
这是最低要求。全部采集。
关键实现选择如下：
日志记录在哪里。 可选方案包括：
- 专用可观测性工具（Helicone、LangSmith、Phoenix、Braintrust、Arize）。
- 带LLM扩展的通用可观测性平台（Datadog LLM Observability、Sentry）。
- 自建日志/数据库。
对大多数团队而言，选择专用工具即可。它们提供专门用于检查LLM调用的UI。与自行构建相比，学习成本并不高。
对较大的团队，可以混合使用：通过专用工具获得LLM专属UI，同时将数据输送到中央可观测性平台，以便进行跨系统关联。
如何插桩。 可选方案包括：
- 位于应用与LLM提供商之间的代理（Helicone的模式）。
- 应用代码中的封装SDK。
- 每次调用LLM时手动使用的包装类。
代理最容易使用，但会增加延迟。SDK很简洁，但需要集成。手动封装最灵活，却也最容易遗漏。
一种务实的做法是：在应用调用LLM的边界处使用SDK封装。只需在一处插桩，其他调用都会经过这里。
记录什么。 一些实际注意事项：
- 截断非常长的输入/输出，但要记录发生过截断。
- 对PII进行哈希或脱敏（如有需要，可通过安全查询取回原文）。
- 即使在错误路径中，也不要记录凭据。
- 对流式传输，同时记录首token延迟和总延迟。
追踪级插桩
一次用户操作往往涉及多次LLM调用。没有追踪级插桩，你会得到上千条调用日志，却无法知道哪些调用属于同一次用户操作。
实现方式如下：
生成追踪ID。 在用户请求开始时生成唯一追踪ID，并将其传递给后续所有调用。
父子Span。 在一次追踪中，每次调用都有Span ID，以及可选的父Span ID，由此形成展示调用层级的树。
操作命名。 每个Span都有名称（summarize_document、extract_entities、tool_call:search）。追踪会显示完整的操作链。
UI中的追踪视图如下：
追踪abc-123（总计12.3s）
├─ classify_intent (450ms) [gpt-5-mini]
├─ retrieve_documents (1.2s) [embedding + search]
├─ generate_response (8.5s) [claude-4-sonnet]
│ ├─ tool_call: search_internal (320ms)
│ ├─ tool_call: lookup_customer (180ms)
│ └─ generate_final_text (7.5s)
└─ judge_response_quality (2.1s) [claude-4-haiku]
现在你可以看到系统实际为这次用户请求做了什么，也能在上下文中找到缓慢、昂贵或失败的调用。
在这方面表现出色的工具包括LangSmith、Phoenix（Arize），以及经过自定义集成的Helicone。还可以使用通用可观测性工具（Datadog、OpenTelemetry）进行跨系统追踪。
应用级指标
除单次调用外，还应汇总以下指标：
按功能。
- 调用量。
- 平均延迟。
- p50、p95、p99延迟。
- 每个请求的平均成本。
- 错误率。
- 质量分数（如有衡量）。
按用户/租户。
- 每位用户每天的调用次数。
- 每位用户的成本。
- 重度用户/滥用模式。
按模型。
- 各模型的调用量。
- 各模型的成本占比。
- 各模型的错误率。
- 各模型的质量（如有衡量）。
按功能 × 模型。
- 哪些功能使用哪些模型？
- 哪些地方可以路由到更便宜的模型？
这些仪表板会推动运营决策：哪些功能成本高、哪些响应慢，以及哪些需要优化。
质量监控
最困难的一层是自动化质量评估。
对于评估（已在其他文章中介绍），你会在定义好的数据集上运行。对于在线质量监控，则要评估生产流量。
可采用以下方法：
对样本使用LLM裁判。 例如，对1%的生产流量进行抽样。针对每个样本运行裁判LLM，按相关维度对响应评分。持续跟踪分数，并在下降时告警。
隐式信号。 跟踪重新生成、放弃、错误率、完成耗时和后续消息频率。这些信号较弱，但成本低，可用作先行指标。
显式用户反馈。 赞/踩、“这是否有帮助？”按钮和明确举报。信号最强，但数量最少。
模式检测。 自动标记特定的不良模式（“I cannot help with that”“I’m just an AI”、反复拒绝）。这能立即捕获一部分回归。
典型设置如下：
- 对1%的生产调用进行抽样。
- 对每个样本运行LLM裁判，按多个维度评分。
- 汇总为各功能的每日分数。
- 如果任一功能的分数环比上周下降>10%，则发出告警。
这确实会产生成本，但范围可控（1%的流量 × 小型裁判模型，对大多数团队而言可以承受）。
成本可观测性
LLM成本可能失控。一个缺陷——失控的重试循环，或某项功能消耗的token比预期多10倍——就可能在任何人察觉之前产生10倍账单。
成本可观测性包括以下层次：
单次调用成本。 在记录日志时计算每次调用的成本，并可立即聚合。
预算告警。 按功能/租户设置每日、每周和每月预算。达到阈值（50%、75%、90%、100%）时告警。
异常检测。 每日成本是正常水平的5倍？告警。单次调用成本是正常水平的100倍？告警。
成本归因。 按功能、租户和用户归因成本，找出主要消耗者。
预测。 根据当前趋势，月底账单将达到多少？
一个实用的仪表板视图是在单个面板中按功能拆分，展示今日成本、本周剩余时间预计成本与上周成本的对比。
实用建议：尽可能设置硬性限制。某项功能预计成本为每天€X，就应在达到10X时自动停用。成本失控的速度很快，而限制可以及时拦截。
延迟可观测性
LLM延迟比典型API更复杂：
总延迟。 从发出请求到获得最终响应。
首token时间（TTFT）。 对于流式传输，用户何时能看到第一个字符？这决定了聊天UX中大部分的感知延迟。
末token时间（TTLT）。 响应需要多久才能全部完成？
每秒token数。 输出速率。不同模型的流式输出速度不同。
工具调用延迟。 在智能体流程中，工具调用和LLM调用分别花费多少时间。
跟踪所有这些指标。不同的优化策略针对不同指标。
对于面向用户的聊天，TTFT最重要。迟迟不出现第一个token会让人觉得系统坏了；每秒token数较低只会让人觉得输出较慢。
对于批处理，总延迟很重要，而吞吐量更重要。
对于智能体，工具调用延迟往往占主导地位；如果工具很慢，优化LLM也无济于事。
错误可观测性
LLM特有的错误包括：
API错误。 速率限制、身份验证失败、服务器错误。与其他API相同。
验证错误。 结构化输出不符合Schema。按功能跟踪发生频率。
内容过滤错误。 提供商阻止了请求。跟踪这些错误以发现提示词问题。
工具错误。 特定工具发生故障。按工具跟踪。
质量错误。 裁判LLM将输出评为不佳。随时间跟踪。
幻觉信号。 检测可能的幻觉（模型声称了来源中不存在的内容）。很难自动检测，但可以近似判断。
成本错误。 调用成本远超预期，通常意味着存在缺陷。
每类错误都应有自己的仪表板，也都可以触发告警。
调试工具
发生故障时，你需要找到问题并理解原因。调试界面应包括：
追踪搜索。 通过追踪ID、用户ID或时间戳找到特定用户的请求。
调用检查器。 对任意调用查看完整请求、响应、参数、延迟和成本。
追踪时间线。 对复杂流程以可视化方式查看调用链。
重放能力。 能否用不同的提示词/模型重新运行历史调用，看看会发生什么？这对于验证修复至关重要。
差异视图。 并排比较两次调用——同一提示词的不同版本，或不同模型。
按内容搜索。 在历史调用语料中搜索特定模式（“显示模型说过 ‘I cannot help’ 的调用”）。
这些正是专用LLM可观测性工具提供的能力。自行构建的工作量很大，使用现成工具通常更便宜。
隐私与PII
LLM可观测性日志十分敏感。输入可能包含PII，输出也可能引用PII。有时无法避免记录它们，因为调试需要这些信息。
实践包括：
token化/哈希。 用token替换标识符。原始值可以通过单独的安全查询取回。大部分日志因此不再包含PII。
记录日志时脱敏。 在数据进入可观测性存储之前检测并脱敏PII。将特定模式（电子邮件地址、电话号码、SSN）替换为占位符。
租户隔离。 多租户可观测性数据按租户隔离。一个租户无法看到另一个租户的数据。
访问控制。 谁可以查看原始输入/输出？对访问行为进行记录。
保留策略。 删除超过X天的日志，或将其移至冷存储。在许多司法管辖区，PII的保留期限受法律限制。
被遗忘权。 当用户依据GDPR请求删除时，必须能够找到并删除其日志。
对于任何处理PII的系统，这些措施都不是可选项。应尽早做好；事后补救非常痛苦。
告警
以下阈值和信号值得发出告警：
成本。
- 每日成本 > 正常水平的2倍。
- 单次调用成本 > €5。
- 每小时成本激增 > 5倍。
延迟。
- p95延迟 > 基线的2倍。
- 聊天UX的TTFT > 5s。
- 工具调用超时增多。
错误率。
- 错误率 > 1%（典型基线为0.1–0.5%）。
- 特定错误类型激增（验证错误、速率限制）。
质量。
- 任一功能的质量分数环比上周下降>10%。
- 用户反馈负面率 > 基线。
- 重新生成率 > 基线。
模式。
- 特定不良短语出现得更频繁。
- 输入分布突然变化。
每条告警都应具体且可操作。“成本很高”没有帮助；“功能X在过去30分钟内的成本达到其预算的10倍——可能是客户Y的会话失控”才可操作。
多租户注意事项
对于B2B SaaS应用：
按租户提供指标。 每位客户都能看到自己的用量、成本和质量。
按租户提供告警。 根据各自的阈值告警。
按租户进行调试。 支持人员可以查看客户的追踪，但要有适当的访问控制。
按租户配置。 部分客户可能使用不同的模型、提示词或策略。可观测性层应反映这些差异。
这会增加复杂度，但对于规模化B2B至关重要。如果无法按租户查看追踪，客户支持就无法帮助调试“AI对我不起作用”。
工具生态（2026年）
截至本文撰写时，LLM可观测性工具的整体格局如下：
专用LLM可观测性工具：
- Helicone。 基于代理；集成简单；仪表板强大。
- LangSmith。 与LangChain生态紧密结合；深度追踪能力强。
- Phoenix（Arize）。 对开源友好；质量监控能力强。
- Braintrust。 将评估与可观测性很好地结合在一起。
- PromptLayer。 以提示词为中心；版本跟踪能力强。
- Weights & Biases Weave。 对机器学习团队友好；可与W&B的更广泛套件集成。
带LLM扩展的通用APM：
- Datadog LLM Observability。 企业级；价格昂贵。
- New Relic LLM Observability。 与之类似。
- OpenTelemetry + 你选择的APM。 OTel提供GenAI语义约定；一次插桩即可在多种工具中查看。
自行构建：
- 在Postgres表中为每次调用存一行，就足以让大多数团队走很远。
- 添加简单UI用于搜索和展示。
- 与现有日志基础设施集成。
正确选择取决于团队规模、系统规模、预算和现有工具。大多数团队从专用工具起步，随着规模增长再迁移到更全面的方案。
一套实用配置
对于从零开始的典型中型团队：
第1周： 选择工具（Helicone是常见且容易上手的选择）。集成到主要LLM调用路径，并确认调用已被记录。
第2周： 设置基础仪表板，展示各功能的成本、延迟和错误率。
第3周： 针对成本激增和错误率上升设置告警。
第4周： 添加追踪级插桩，串联多次调用流程中的Span。
第2个月： 实施质量抽样。选择几项功能，对1%的流量设置LLM-as-judge评分。
第3个月： 添加用户反馈采集，接入赞/踩或类似机制。
第4个月： 添加多租户支持、细粒度告警和调试工具。
这就是一套可用的可观测性技术栈。每一层都会增加能力，也都值得建设。跳过任何一层都会形成盲区。
缺少它会发生什么
以下是没有适当LLM可观测性的团队反复遇到的一些事故模式：
-
某个缺陷导致一项功能在紧密循环中反复重试。一个周末累积了五位数的意外费用，直到月度账单到达才被发现。（这类故事的变体出现得十分频繁，具体数字已经不如模式本身重要。）
-
一次模型更新悄然改变了行为，关键功能的质量下降。用户不断投诉，但工程团队以为只是“偶尔表现怪异”。两个月后才发现与模型变更有关。
-
部署了新的提示词版本，却意外导致一项重要用户流程回归。由于没有按流程划分的指标，几周内都无人察觉。
-
智能体系统开始循环，部分用户会话产生200多次LLM调用。由于没有追踪级插桩，花了数小时才找到这个循环。
-
工具身份验证失败导致智能体陷入混乱。智能体不断“尝试各种办法”并持续产生费用。由于没有告警，这种情况持续了数小时。
-
一次提示词注入导致AI泄露系统指令，并披露了PII。由于没有可观测性，团队无法轻松确定哪些用户受到了影响。
这些不是理论情形，它们确实会发生。可观测性可以预防其中大多数问题，或迅速发现它们。
在事故发生前完成插桩
LLM可观测性是一门独立学科。传统APM必不可少，但并不充分。调用级、追踪级、质量、成本、延迟、错误和调试这些专门层次缺一不可。
工具已经存在。选择一个，尽早集成，并投入建设能够抢在用户之前发现问题的仪表板、告警和流程。
这样做的团队：
- 能在数小时而非数周内发现缺陷。
- 能够可预测地管理成本，而非收到意外账单。
- 能够长期保持质量，而非任其漂移。
- 能系统地调试，而非靠猜测。
没有这样做的团队，最终会遭遇一次迫使他们采取行动的事故。与其事后补做，不如在事故发生前完成插桩。
