LLM可观测性：Trace、Token、延迟、成本、质量、失败类型和告警
摘要
LLM 应用的可观测性不能只复用普通 Web 日志，因为一次回答往往跨越模型网关、检索、重排、工具调用、上下文组装、安全策略、流式输出和用户反馈。Trace、Token、延迟、成本、质量、失败类型和告警需要被放在同一条请求链路里理解。本文主张把可观测性从“系统有没有报错”提升为“模型为什么这样回答、花了多少、慢在哪里、失败属于哪类、是否影响业务”的证据系统。
关键词
LLM 可观测性；Trace；Token；延迟；成本；质量信号；失败分类；告警；模型网关；RAG 监控
研究问题与方法
本文讨论三个问题：一次 LLM 请求的可观测边界应从哪里开始、到哪里结束；Token、延迟和成本如何拆到业务单元，而不是只留在供应商账单里；质量和失败怎样从主观反馈变成可追踪信号。方法上，文章采用链路建模：先定义请求生命周期，再为每个阶段设计 span、指标、事件和采样策略，最后把离线评测、线上反馈和告警规则合并成持续治理闭环。
下图展示本文的观测模型。重点不是记录更多日志，而是在关键阶段保留足以定位问题、计算成本和复盘风险的证据。
单位请求成本可以拆成可归因结构：
其中 和 是输入、输出 token 数， 和 是对应单价，后面三项表示检索、重排和工具调用成本。这个分解能帮助团队判断成本上涨来自长上下文、输出冗余、检索过宽还是工具链路异常。
大模型应用上线之后，最难回答的问题往往不是“接口有没有通”，而是“为什么这一次回答慢了”“为什么成本突然上升”“为什么同一个问题昨天能答对今天答错”“为什么工具调用绕了一圈还没有完成”“为什么用户说答案不可信”。传统 Web 服务主要看请求量、错误率、耗时和资源利用率，LLM 应用还要看提示词、上下文、检索、模型、工具、token、费用、输出质量、拒答、幻觉、权限过滤和多轮状态。没有这些信息，团队只能在日志里猜。
LLM 可观测性就是为这种不确定链路建立证据。它不是把所有输入输出粗暴存下来，也不是在管理后台做几张漂亮图表，而是把一次用户请求拆成可追踪、可聚合、可评测、可告警的运行记录。一次问答可能经过鉴权、问题改写、向量检索、重排、上下文压缩、模型调用、工具调用、二次模型调用、引用校验和内容安全检查。每一步都应该能说明用了什么模型、花了多少 token、等了多久、失败在哪里、质量如何、对最终答案有什么影响。
这篇教程系统讲 LLM 可观测性。重点覆盖 Trace、token、延迟、成本、质量、失败类型和告警，也会把 OpenTelemetry、LangSmith、Arize Phoenix、OpenLLMetry、Langfuse、Helicone 等资料中的实践方法串起来。读完之后，你应该能为一个 RAG、Agent、客服助手、代码助手或企业知识库问答系统设计一套生产级观测方案，而不是只在异常时打印几行请求日志。
引言：为什么 LLM 应用不能只看普通日志
普通应用的日志通常记录请求路径、状态码、耗时、用户编号和异常栈。对于确定性业务，这些信息已经能定位大部分问题。比如订单接口返回 500，日志里可以看到数据库报错；支付接口变慢，可以看下游网关耗时；缓存命中率下降，可以看 Redis 指标。LLM 应用的问题更复杂，因为一次请求的结果受模型推理、提示词、上下文、检索资料、工具返回、输出采样和安全策略共同影响。
用户问“上个月发票为什么没有生成”，系统可能先查用户身份，再判断业务域，接着调用账单工具，然后让模型解释原因。最终回答错了，可能是账单工具超时，可能是模型没有正确读懂工具返回，可能是提示词把“未开票”和“已作废”混在一起，也可能是用户没有权限查看那张发票。只看最终接口 200 和总耗时，无法知道真正问题在哪里。
LLM 应用还存在“成功但不可接受”的情况。接口返回 200，模型也输出了一段完整文字，但答案可能没有依据、引用错误、绕开了权限、漏掉关键限制条件，或者语气不适合当前场景。传统错误率不会捕捉这种失败。对用户来说，这类失败比网络错误更危险，因为它看起来像正常答案。
所以 LLM 可观测性要把运行过程变成可检查的链条。Trace 负责展示一次请求里的步骤关系；指标负责把大量请求聚合成趋势；日志和事件负责记录重要上下文；评测负责把“答得好不好”变成可统计信号；告警负责在成本、质量、延迟或失败率异常时提醒团队。它们合在一起，才构成真正可运营的 LLM 系统。
先定义一次 LLM 请求的观测边界
做可观测性前，必须先定义“一个请求”到底包含什么。最小边界是一次模型调用，但生产系统通常不能停在那里。用户点击发送消息后，前端请求进入后端，后端可能读取会话、加载用户画像、检索知识库、调用多个工具、拼接 prompt、调用模型、解析结构化输出、再次调用工具、生成最终回复。若每个环节用不同日志记录，事后就很难拼回同一次任务。
更好的边界是把用户的一次可感知任务作为根 trace。根 trace 可以是一次聊天回复、一次报告生成、一次智能客服处理、一次代码修复建议、一次知识库问答。根 trace 下再挂子 span：鉴权、路由、检索、重排、模型调用、工具调用、后处理、引用校验、内容审核、持久化。这样既能看端到端体验，也能下钻到某一步。
OpenTelemetry 的概念里，trace 由 span 组成，span 之间有父子关系。用到 LLM 时，OpenTelemetry 的 GenAI 语义约定给模型调用、token 使用、模型名称、提供方、输入输出等字段提供统一命名。OpenInference 也把 LLM、Embedding、Retriever、Reranker、Tool、Agent、Evaluator 等操作抽象成可追踪的 span 类型。这样做的价值是避免每个团队自定义一套不可迁移的字段。
边界定义还要考虑用户隐私。不是所有 prompt、上下文和输出都应该进入观测系统。模型输入可能包含个人信息、商业合同、客户数据、源码和内部决策。生产设计应该默认记录结构化摘要和指标，敏感内容按开关、脱敏规则、采样比例和访问权限记录。OpenTelemetry GenAI 文档也提醒，完整输入输出可能很大且敏感，不应默认采集。
Trace：把一次回答拆成可追踪链路
Trace 是 LLM 可观测性的骨架。它回答“这次请求发生了什么”。一个好的 trace 页面应该能从根请求一路展开，看到模型调用前检索到了哪些文档，重排选中了哪些片段，模型用了哪个版本，工具调用返回了什么状态，最终答案用了哪些引用，哪一步最慢，哪一步失败或重试。
在 RAG 系统里，trace 至少应包含检索查询、召回数量、重排数量、最终上下文数量、引用来源、上下文 token 和生成 token。若用户投诉答案错误，团队可以打开 trace 看模型是否拿到了正确资料。若资料没有进入上下文，问题在检索或重排；若资料进入上下文但答案仍错，问题可能在提示词、模型能力或后处理；若答案引用了无权限资料，问题在权限过滤边界。
在 Agent 系统里，trace 更重要。Agent 的可见行为是一段回答，内部行为可能是多轮规划、工具选择、工具调用、观察结果、二次推理和终止判断。LangSmith 文档强调 traces 可以记录 agent 执行中的工具调用、模型交互和决策点。Phoenix 也把模型调用、检索、工具使用和自定义逻辑放进 trace，用于理解时间花在哪里。没有 trace，Agent 看起来像黑箱；有了 trace，至少能知道它是怎么走到结果的。
Trace 设计不要只追求“全量记录”。更重要的是结构一致。每个 span 要有稳定名称、操作类型、模型名、输入输出 token、状态、错误类型、耗时、用户和会话关联、功能模块、版本号、环境和关键业务标签。稳定结构让团队可以查询“某个 prompt 版本下的失败请求”“某个模型的 p95 延迟”“某个工具导致的失败率”“某类用户的平均成本”。
还要注意 trace 的粒度。粒度太粗，只看到一个“generate”耗时 12 秒，没有排障价值；粒度太细，把每个小函数都作为 span，会增加噪声和存储成本。实用做法是以用户可感知步骤和外部依赖为主：模型、检索、数据库、工具、外部 API、队列、缓存、文件解析、评测器。内部纯计算步骤只有在耗时或失败风险明显时才单独记录。
Token：LLM 应用最核心的用量单位
Token 是 LLM 系统里的燃料表。输入 token 决定模型要读多少内容，输出 token 决定模型生成多少内容，缓存 token、推理 token、音频 token、图像 token 等新类型又会影响真实计费。只看请求次数很容易误判成本。一个请求可能只有几十 token，也可能因为塞入长文档而达到几十万 token。
OpenTelemetry GenAI 指标中包含 gen_ai.client.token.usage，并区分 input 和 output token。GenAI span 语义约定也推荐记录输入 token、输出 token、缓存相关 token 和推理 token。Langfuse 的 token 与成本追踪文档同样强调，usage details 可以包含 input、output、cached tokens、audio tokens、image tokens 等不同类型。生产系统应该尽量使用模型供应商返回的 usage，而不是事后用本地 tokenizer 粗略估算。
Token 观测至少要回答六个问题。第一，每个功能每天消耗多少输入和输出 token。第二，哪个模型、哪个 prompt 版本、哪个用户或租户消耗最多。第三，平均上下文长度是否持续上涨。第四，输出长度是否出现异常膨胀。第五，缓存命中是否真的降低输入成本。第六，失败请求是否也在消耗大量 token。
Token 指标要按链路拆开。RAG 中，问题改写消耗多少，embedding 是否按字符或 token 计费，重排是否调用模型，最终生成消耗多少，引用校验又消耗多少。Agent 中，计划步骤、工具选择、每轮观察总结、最终回答都可能用 token。只记录最终生成模型的 usage，会漏掉大量隐性成本。
Token 还应该和质量一起看。低 token 不一定好，可能因为上下文不足导致回答不完整；高 token 也不一定坏，可能是复杂任务需要多证据推理。关键是单位质量成本。例如每个成功解决问题的 token 成本、每个被采纳答案的 token 成本、每个有正确引用回答的 token 成本。这样才能判断优化是否真正有效。
延迟：别只看总耗时
LLM 延迟由多个阶段组成。用户感受到的是从发送到看到首字、从发送到完整答案、从中间工具调用到最终完成的整体等待。系统内部还要拆成排队、检索、重排、prompt 构造、模型首 token、模型逐 token 输出、工具调用、重试和后处理。只看接口总耗时，会把完全不同的问题混在一起。
OpenTelemetry GenAI 指标包含操作总时长、首个输出块时间、每个输出块时间，模型服务端还可以记录首 token 时间和每个输出 token 时间。对流式应用来说，首 token 时间特别重要。用户可能能接受完整答案 15 秒，但不能接受 8 秒空白等待。若首 token 慢，可能是模型排队、输入太长、预填充阶段太重或网关拥堵；若首 token 正常但总耗时长，可能是输出太长或工具链继续执行。
延迟指标要分层看。端到端 p50 代表普通体验，p95 和 p99 代表尾部问题。平均值很容易掩盖少数慢请求。大模型应用经常有长尾：某些请求触发长上下文，某些用户文档特别多，某个工具偶发慢，某个供应商区域波动。告警应更多关注分位数、超时率和慢请求占比，而不是单纯平均耗时。
延迟还要按模型和功能拆开。一个轻量分类器 200 毫秒算慢，一个复杂报告生成 20 秒可能正常。聊天、搜索、报告、代码分析、图片理解、长文总结不能用同一阈值。生产系统应为不同操作定义预算：检索 200 毫秒以内，重排 300 毫秒以内，首 token 2 秒以内，完整回答 10 秒以内，离线报告可以更长。预算不是绝对数，而是让团队知道哪里超出了用户预期。
延迟优化也要有 trace 证据。若问题在检索，就优化索引、缓存、过滤条件和并发；若问题在 prompt 过长，就做上下文裁剪和摘要；若问题在模型输出太长，就控制回答结构；若问题在工具，就加超时和降级；若问题在供应商，就做路由和备用模型。没有分段延迟，优化很容易变成盲目换模型。
成本：从账单金额拆到业务单元
LLM 成本不能等月底账单出来再分析。生产系统需要接近实时地知道钱花在哪里。成本观测的最小粒度应该到模型调用，但管理粒度应该能上卷到用户、租户、功能、版本、渠道和业务结果。否则只知道“本月模型费很高”，不知道哪个入口、哪个客户、哪个 prompt 或哪次发布导致上涨。
成本计算要尽量贴近真实计费。不同供应商对输入、输出、缓存读取、缓存写入、推理 token、图像、音频、批处理、上下文长度分层都有不同价格。Langfuse 支持从 usage 和模型定义推断成本，也支持自定义模型价格；Helicone 文档也把成本、延迟、token、错误率作为可监控指标。对生产系统来说，必须保留模型请求名和响应模型名，因为网关、兼容接口和路由层可能让“请求的模型”与“实际响应模型”不同。
成本指标要回答三个层次的问题。第一是账务层：每天、每小时、每租户、每模型花了多少。第二是工程层：哪些 prompt、工具链、上下文策略和重试造成成本。第三是业务层：每个有效回答、每个解决会话、每个付费用户、每个工单节省的成本收益比是多少。只做账务层，团队会倾向于压缩 token；做到业务层，才能判断某些高成本步骤是否值得。
成本异常通常有几类原因。上下文拼接错误导致整篇文档被放入 prompt；Agent 死循环导致多轮模型调用；用户滥用或脚本调用导致请求暴涨；新模型价格配置错误；缓存失效导致输入 token 增加；重试策略把失败请求放大；输出约束失效导致模型生成过长。每一种都需要 trace 和指标联动定位。
成本治理不能只靠硬性额度。额度能止血，但可能直接影响正常用户。更好的设计是分层预算：个人、租户、功能、环境、模型、任务类型都有预算；超出软阈值时降级模型或缩短上下文；超出硬阈值时限制高成本操作；高价值用户和后台任务有不同策略。所有策略都要在观测系统里可见，否则运营和工程无法解释用户体验变化。
质量：把“答得好不好”变成信号
LLM 可观测性最特殊的部分是质量。传统服务可以把 2xx 当成功，把 5xx 当失败。LLM 应用不行。一个回答可能语法通顺、接口成功、耗时正常，却没有回答问题、引用了错误资料、编造了事实、违反了语气要求、泄露了敏感信息，或者没有按结构化格式输出。质量必须单独观测。
质量信号可以来自用户反馈、人工标注、规则校验、模型评审和业务结果。用户点赞点踩最直接，但噪声大；人工标注质量高，但成本高；规则适合检查格式、引用、权限和禁止词；模型评审适合批量打分，但需要校准；业务结果如工单是否解决、用户是否追问、客服是否采纳，能反映真实价值。Phoenix 文档把 evaluations 放在核心能力中，支持用 LLM 评测、代码检查或人工标签对 traces 和 spans 打分。
RAG 系统的质量至少要看四类指标。第一是检索质量：正确资料是否被召回，是否排在前面，进入上下文的片段是否相关。第二是答案忠实度：回答是否基于上下文，没有脱离资料编造。第三是引用质量：引用是否能支持答案，是否来自最新且有权限的文档。第四是拒答质量：资料不足时是否明确说明，是否避免强行回答。
Agent 系统还要看任务完成度。工具是否选对，参数是否正确，是否重复调用同一工具，是否在失败后合理恢复，是否知道停止，是否把中间结果整合成用户可用结果。一次 Agent trace 可以同时挂多个质量分数：工具选择分、任务完成分、输出格式分、用户满意分、风险分。把这些分数与 span 关联，才知道质量问题发生在哪一步。
质量指标不能只看总体均值。不同问题类型差异很大。定义类问题、流程类问题、数据查询、比较分析、长文总结、代码修改、权限敏感问答应该分开统计。某个模型总体 90 分，可能在制度问答上很好，在数值计算上很差。生产看板应该按场景、版本、知识库、用户群和模型拆开，否则平均分会掩盖风险。
失败类型：先分类，才能治理
LLM 应用失败不应该只分为成功和失败。可观测系统必须建立失败类型，因为不同失败的处理方式完全不同。一个供应商 429 需要限流或切换模型，一个 JSON 解析失败需要改输出约束，一个幻觉答案需要改检索或评测，一个权限泄露需要立即阻断和审计。
常见失败可以分为九类。第一类是供应商失败，包括超时、限流、认证失败、区域不可用、模型不存在、内容被供应商拒绝。第二类是网络和网关失败，包括连接中断、代理异常、重试耗尽。第三类是输入失败，包括 prompt 过长、文件解析失败、图片格式不支持、用户输入为空或不合法。第四类是上下文失败，包括检索为空、召回错误、权限过滤后无资料、重排误判、上下文超预算。
第五类是输出失败，包括结构化 JSON 不合法、工具调用参数不完整、输出被截断、语言不符合要求、没有引用。第六类是质量失败，包括事实错误、幻觉、引用不支持答案、漏答关键约束、答非所问。第七类是安全失败，包括敏感信息泄露、越权资料进入上下文、绕过政策、生成不允许内容。第八类是流程失败，包括 Agent 循环、工具顺序错误、重复调用、没有停止条件。第九类是成本失败，包括 token 暴涨、重试放大、异常用户消耗和缓存失效。
每个失败类型都应该有稳定字段。比如 provider_rate_limit、retrieval_empty、context_permission_filtered_empty、json_parse_error、citation_mismatch、tool_timeout、agent_loop_detected、cost_budget_exceeded。字段稳定后，告警、看板、回归测试和工单分析才能复用同一套口径。
失败分类要允许多标签。一次请求可能同时发生检索不足和模型幻觉，也可能先工具超时再触发降级模型。根 trace 可以有最终失败类型，每个 span 可以有局部失败类型。这样既能做用户体验统计，也能做工程定位。例如最终答案失败属于质量问题，但根因可能是重排把旧文档排在前面。
失败治理要形成闭环。供应商失败进入路由和重试策略；上下文失败进入知识库和检索评测；输出失败进入 prompt 和解析器改进；质量失败进入数据集和评测；安全失败进入权限模型和审核；成本失败进入预算和上下文策略。没有失败分类，团队会把所有问题都推给“模型不稳定”，最后无法改进。
告警：别等用户来告诉你系统坏了
告警是可观测性的行动出口。看板用于观察，trace 用于排障，告警用于及时响应。LLM 应用的告警不能只沿用 CPU、内存和 5xx。它还要覆盖错误率、延迟、token、成本、质量、失败类型、供应商状态、检索为空率和安全风险。
Helicone 的告警文档把错误率、成本、延迟、总 token、prompt token、completion token、缓存读写 token 和请求数列为可监控指标，并支持按时间窗口设置阈值。这个思路很适合 LLM 应用：告警指标应该与用户体验和运营风险直接相关。比如 30 分钟内某模型错误率超过 8%，某功能 p95 完整耗时超过 15 秒，某租户小时成本超过历史均值 3 倍，某知识库检索为空率突然上升。
质量告警要谨慎设计。模型评审分数本身有噪声，不适合用单个请求触发严重告警。更稳的方式是看滑动窗口趋势：低质量评分占比上升、引用错误率上升、人工差评率上升、拒答率异常、资料不足回答却仍给出肯定结论。高风险场景可以更严格，例如医疗、法律、财务和企业制度问答中，引用缺失或权限异常应直接告警。
成本告警要同时有绝对阈值和相对阈值。绝对阈值用于防止预算爆炸，相对阈值用于发现异常变化。一个大客户白天成本高可能正常，但凌晨突然高成本请求异常；一个新版本上线后平均输入 token 增加 60%，即使还没超预算，也应该提醒工程团队检查上下文策略。
告警还要防止疲劳。低流量功能中，一个失败请求就可能让错误率达到 100%，这类告警需要最小请求数门槛。周期性任务可能在整点集中运行，不能用普通在线请求阈值。供应商短暂抖动可以先自动切换备用模型，只有持续失败才升级给值班人员。好的告警不是越多越好，而是每一条都能推动明确动作。
观测字段如何设计
生产系统最好先设计字段，再接工具。工具可以换，字段口径不能天天变。一个 LLM 请求至少要有 trace id、span id、用户或租户标识、会话标识、功能名称、环境、版本、模型请求名、模型响应名、供应商、操作类型、输入 token、输出 token、缓存 token、成本、开始时间、结束时间、状态、失败类型、重试次数和关键业务标签。
RAG 还要记录知识库名称、索引版本、检索查询、召回数量、重排数量、最终上下文数量、上下文 token、文档版本、引用数量、引用校验结果、权限过滤数量和资料不足判断。Agent 要记录工具名称、工具参数摘要、工具状态、循环次数、计划步骤数、终止原因和人工接管标记。多模态应用还要记录图片、音频、视频输入的大小、数量和处理状态。
字段设计要区分高基数字段和低基数字段。模型名、功能名、失败类型适合做指标维度；用户 id、trace id、文档 id 适合放在 trace 或日志中查询，不适合直接做普通指标维度，否则会造成指标系统压力。成本和 token 可以按用户聚合，但原始明细应进入适合高基数查询的存储。
内容字段要分级。第一层只记录是否存在、长度、哈希、语言、类型和脱敏摘要。第二层记录截断后的 prompt、上下文和输出。第三层在受控权限下记录完整内容，用于少量样本排障和评测。不同层级有不同保留时间。这样既能排查问题，也能控制隐私和存储成本。
版本字段非常关键。每次 prompt、模型、检索策略、重排器、分块策略、工具定义、系统消息和安全规则变化，都应该能在 trace 中看到版本。否则质量波动发生后，团队无法判断是模型变了、prompt 变了，还是知识库索引变了。可观测性不是只记录运行时，还要记录“运行的是哪一版系统”。
采样、脱敏和保留周期
LLM trace 内容大、成本高、敏感性强，不能无脑全量保存完整内容。采样策略要按风险和价值设计。错误请求、慢请求、高成本请求、低质量请求、安全命中请求应高比例保留；普通成功请求可以只保留指标和结构化摘要；新版本灰度期间可以提高采样；稳定后降低采样。这样能把存储花在最有价值的样本上。
脱敏不只是把手机号替换掉。企业知识库里可能有合同金额、客户名称、内部项目、代码片段、医疗记录、学生信息、员工数据和商业计划。脱敏策略要结合数据分类。某些内容可以哈希，某些可以保留片段，某些只能存储长度和来源。对于必须保留原文的场景，要有访问审批、审计日志和短保留周期。
保留周期要分层。聚合指标可以保留较久，用于趋势和容量规划；完整 trace 可以保留较短，用于近期排障；被标注为典型失败或评测样本的 trace 可以进入数据集，经过脱敏后长期保存。不要把所有生产输入输出永久塞进同一个日志系统，这会带来合规和成本风险。
采样还要保证评测代表性。若只保存失败和慢请求，团队会低估普通质量；若只保存高价值用户，长尾问题会被忽略。可以采用混合采样：固定比例随机样本保证总体分布，规则样本捕捉异常，高价值样本用于人工标注。评测集要从这些样本中整理，而不是临时编几个理想问题。
从开发到生产的落地路径
第一阶段是最小可见。把每次模型调用记录为 span，包含模型、供应商、输入 token、输出 token、耗时、状态、错误和 trace id。先让团队能回答“这次请求调用了哪个模型，花了多久，用了多少 token，是否失败”。这一步不要追求复杂看板，先保证口径正确。
第二阶段是链路可见。把检索、重排、工具调用、后处理和评测接入同一个 trace。RAG 系统要能从答案追到引用和上下文；Agent 系统要能从最终回答追到每个工具动作。LangSmith、Phoenix、OpenLLMetry、Langfuse 等工具都能在不同生态里帮助建立这种链路，关键是团队要把自己的业务步骤也纳入 trace，而不是只依赖自动 instrumentation。
第三阶段是指标可运营。建立 token、成本、延迟、错误率、检索为空率、引用错误率、质量评分和用户反馈看板。看板要按模型、功能、租户、版本、环境和时间维度拆分。每个指标都要有明确解释和负责人。比如“平均成本上升”归模型网关和功能团队共同看，“引用错误率上升”归知识库和 RAG 团队看。
第四阶段是告警和自动化响应。给关键指标设置阈值和趋势告警，联动路由、降级、限流、预算、人工接管和回滚。比如供应商错误率高时切换备用模型，成本异常时限制长上下文，质量评分下降时暂停灰度版本，权限异常时阻断相关知识库回答。告警不只是通知，还要进入处理流程。
第五阶段是质量闭环。把生产 trace 中的失败样本整理成评测集，按问题类型、知识库、模型和 prompt 版本做回归测试。每次改 prompt、改模型、改检索器、改工具定义，都用同一批样本比较。这样可观测性就不只是事故排查工具，而是持续改进系统质量的基础设施。
常见架构方案
小团队起步可以采用“应用埋点加 LLM 可观测平台”。应用代码里为模型调用、检索和工具加 span，数据送到 LangSmith、Phoenix、Langfuse 或 Helicone。优点是上手快，能直接看到 trace、成本、延迟和部分评测。缺点是字段和权限要认真设计，不能把敏感内容全部默认上传。
已有云原生观测体系的团队可以采用“OpenTelemetry 统一出口”。应用和 LLM instrumentation 产生 OTel traces、metrics、logs，经 collector 处理后送到现有后端。OpenLLMetry 的思路就是在 OpenTelemetry 基础上扩展 LLM、向量数据库和框架 instrumentation。这样能复用现有告警、日志、指标和权限体系，也减少供应商锁定。
高安全企业可以采用“本地观测加脱敏评测”。完整 trace 留在私有环境，外部平台只接收聚合指标或脱敏样本。敏感 prompt 和文档内容不出内网，评测数据经过审批后进入长期样本库。这种方案工程成本更高，但适合金融、政企、医疗、教育和法律等场景。
平台型产品可以采用“模型网关统一观测”。所有模型请求经过网关，网关记录模型、token、成本、延迟、错误和路由；业务应用再补充检索、工具、用户和质量信息。网关适合统一成本和供应商可靠性，但它看不到完整业务语义，所以不能替代应用侧 trace。两层结合才完整。
复杂 Agent 平台可以采用“运行时事件流加 trace”。Agent 每一步计划、动作、观察、反思、终止都生成事件，同时关键外部调用形成 span。事件流用于回放和用户可见状态，trace 用于性能和排障，评测器在任务完成后给每个阶段打分。这类系统要特别注意循环检测、工具超时和中间状态保留。
看板应该怎么组织
LLM 可观测看板不要一开始就堆所有图。最实用的是五块。第一块是流量与可靠性：请求量、成功率、错误率、失败类型分布、供应商错误。第二块是延迟：端到端 p50/p95/p99、首 token、模型耗时、检索耗时、工具耗时。第三块是成本：总成本、每功能成本、每用户成本、输入输出 token、缓存 token、异常消耗。第四块是质量：用户反馈、评测分、引用正确率、拒答率、幻觉率。第五块是版本影响：模型版本、prompt 版本、索引版本和发布批次对前面指标的影响。
每块看板都要能下钻到 trace。看到成本峰值时，可以点进具体高成本请求；看到质量下降时，可以查看低分样本；看到延迟长尾时，可以打开最慢 trace；看到检索为空率上升时，可以看哪些知识库和查询受影响。没有下钻能力，看板只能说明有问题，不能帮助解决问题。
看板还要区分实时运营和周报复盘。实时看板关注当前是否异常，图少且阈值明确。复盘看板关注版本变化、成本趋势、质量改进和失败类型变化，可以更细。不要让值班人员面对几十张没有优先级的图，也不要让产品复盘只能看到技术指标。
业务负责人需要另一种视角。他们关心哪些功能被使用最多，哪些用户满意，哪些场景节省人力，哪些回答需要人工接管，单位业务结果成本是否可接受。工程看板和业务看板应使用同一批底层数据，但展示口径不同。这样团队讨论质量和成本时不会各说各话。
评测如何和可观测性结合
离线评测和线上观测必须打通。离线评测告诉你版本上线前是否可能变好，线上观测告诉你真实用户场景下是否真的变好。只做离线评测，样本可能不代表真实分布；只看线上反馈，发现问题时用户已经受影响。成熟团队会把线上 trace 中的典型样本沉淀到离线数据集，再用离线回归保护下一次发布。
评测样本要保留上下文。一个 RAG 失败样本不能只存用户问题和最终答案，还要存当时检索到的候选、重排结果、最终上下文、引用、模型版本、prompt 版本和知识库版本。否则以后重跑时不知道差异来自哪里。Agent 样本也要存工具结果和中间步骤，否则无法评估工具选择是否改进。
自动评测要分任务。事实问答看忠实度和引用，客服看解决度和语气，代码助手看是否通过测试，报告生成看结构和证据，数据查询看数值准确。用一个总分覆盖所有任务没有意义。Phoenix、LangSmith、Langfuse 等平台都提供评测或打分能力，但业务评分标准仍要自己定义。
评测结果应回写到 trace。这样可以查询“低分请求的共同特征”，例如某个知识库、某个模型、某个 prompt 版本、某类用户、某个工具。评测如果只存在离线表里，和生产 trace 分离，就很难解释质量问题的根因。
人工评审也要产品化。评审人员看到的不应是原始 JSON，而应是用户问题、最终回答、引用证据、检索候选、模型版本和可选择的错误类型。评审结果进入统一字段，成为后续训练、提示词改进和告警阈值的依据。人工反馈越结构化，观测系统越有价值。
生产事故中的排查顺序
当用户反馈 LLM 应用异常时，不要先猜模型。第一步看影响范围：是单个用户、单个租户、单个功能，还是全站。第二步看时间线：是否与发布、索引更新、模型路由、供应商波动或权限变更有关。第三步看 trace：慢在哪里、失败在哪里、token 是否异常、上下文是否正确、工具是否成功。第四步看质量样本：答案错在哪里，引用是否支持，是否有权限问题。
若是延迟事故，先拆端到端耗时。模型首 token 慢，检查模型供应商、输入长度、排队和路由；检索慢，检查索引、过滤条件和数据库；工具慢，检查下游接口；完整输出慢，检查输出长度和流式策略。不要把所有慢都归因于模型。
若是成本事故，先找成本贡献最大维度。按模型、功能、用户、租户、prompt 版本、时间窗口拆分。再打开高成本 trace，看是输入 token 暴涨、输出过长、多轮循环、重试放大还是异常流量。成本事故必须保留证据，否则只能粗暴限流。
若是质量事故，先确认是否拿到了正确上下文。RAG 的多数问题可以从“正确资料是否被召回”和“正确资料是否进入最终上下文”开始排查。若没有，查同步、分块、embedding、检索、重排和权限过滤；若有，查 prompt、模型、输出约束和评测。Agent 的质量事故则先看工具选择和参数。
若是安全事故，优先停止风险扩散。越权资料、敏感信息泄露、不允许内容生成，都应先阻断相关功能或知识库，再做 trace 审计。安全事故的观测字段必须能支持事后追踪：哪些用户请求受到影响，哪些文档进入上下文，哪些答案输出了敏感内容，哪个版本引入问题。
容易踩的坑
第一个坑是只记录最终 prompt 和最终回答。这样能看到模型读了什么、答了什么，却看不到 prompt 是怎么来的、上下文为什么是这些、工具是否失败、检索是否漏召回。对复杂应用来说，这只是聊天记录，不是可观测性。
第二个坑是把完整内容全量打到日志里。短期排障方便，长期会带来隐私、成本和权限风险。正确做法是结构化记录、分级采集、脱敏、采样和权限控制。敏感内容默认不采集，必要时按受控开关启用。
第三个坑是没有版本字段。上线后质量下降，却不知道 prompt、模型、索引、工具定义、重排器还是安全规则变了。LLM 应用变化频繁，版本字段是定位回归的生命线。
第四个坑是只看平均值。平均延迟、平均成本、平均质量都会掩盖长尾。用户投诉通常来自 p95、p99 和特定场景。分位数、失败类型和样本下钻比平均值更重要。
第五个坑是把用户点踩当作唯一质量指标。很多用户不会反馈，点踩原因也不一定是事实错误。质量要结合自动评测、人工标注、业务结果和引用校验。
第六个坑是告警没有行动。成本超阈值后谁处理，是否自动降级，是否暂停灰度，是否通知业务方，都要提前定义。没有处理流程的告警只会制造噪声。
第七个坑是只观测模型，不观测知识库和工具。RAG 和 Agent 的失败常常不在模型本身，而在资料、检索、权限、工具和后处理。观测边界必须覆盖完整链路。
落地清单
第一，定义根 trace 边界。以一次用户可感知任务为根，而不是以单次模型调用为根。聊天回复、工单处理、报告生成、代码建议都应有独立 trace。
第二，统一 span 类型。至少覆盖 LLM、Embedding、Retriever、Reranker、Tool、Guardrail、Evaluator、Postprocess。每类 span 有固定字段和状态。
第三，记录 token 和成本。输入、输出、缓存、推理、多模态 token 分开记录，成本按模型真实价格计算，并能按功能、用户、租户和版本聚合。
第四，拆分延迟。记录端到端、首 token、模型耗时、检索耗时、工具耗时、重试耗时和后处理耗时，使用 p50、p95、p99，而不是只看平均值。
第五，建立失败类型。把供应商、网络、输入、上下文、输出、质量、安全、流程、成本失败分开，并在 trace 和指标里使用稳定枚举。
第六，接入质量评分。把用户反馈、人工标注、规则校验、模型评审和业务结果回写到 trace，形成可查询的质量信号。
第七，设计告警。对错误率、延迟、成本、token、质量、检索为空率、引用错误率、权限异常和 Agent 循环设置阈值、窗口和最小流量门槛。
第八，控制敏感内容。默认不全量采集 prompt 和输出；需要时使用脱敏、截断、采样、访问控制和短保留周期。
第九，保留版本。模型、prompt、索引、分块、重排、工具、安全规则、应用发布都要进入 trace 标签。
第十，沉淀评测集。把线上失败、高成本、慢请求、低质量和用户投诉样本整理成回归数据集，让可观测性反哺发布质量。
参考资料
- OpenTelemetry：Generative AI spans 语义约定：https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-spans/
- OpenTelemetry：Generative AI metrics 语义约定：https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-metrics/
- OpenTelemetry：Signals 概念说明：https://opentelemetry.io/docs/concepts/signals/
- LangSmith Observability 文档：https://docs.langchain.com/oss/python/langchain/observability
- Arize Phoenix 文档：https://arize.com/docs/phoenix
- OpenInference Semantic Conventions：https://arize-ai.github.io/openinference/spec/semantic_conventions.html
- OpenLLMetry / Traceloop 介绍：https://www.traceloop.com/docs/openllmetry/introduction/what-is-open-ll-metry
- OpenLLMetry GitHub 仓库：https://github.com/traceloop/openllmetry
- Langfuse Token & Cost Tracking：https://langfuse.com/docs/observability/features/token-and-cost-tracking
- Langfuse Metrics Overview：https://langfuse.com/docs/metrics/overview/
- Helicone Alerts 文档：https://docs.helicone.ai/features/alerts
- Helicone Platform Overview：https://docs.helicone.ai/getting-started/platform-overview