AI 应用可观测性商业产品平台工程 2026

一、问题的提出:LLM 应用的"看不见的黑箱"

当你把一个 RAG 应用或 Agent 应用推上生产,真正让人睡不踏实的,从来不是"模型答得对不对",而是"答得不对的时候,我能不能在三十秒内看见证据"。传统微服务的可观测性三件套(metrics/logs/traces)是为"一次 RPC 调用 + 一个状态码 + 一段延时分布"设计的;而一次 LLM 调用,内部是"几百到几万 token 的 prompt 组装 + 一次嵌入 + 一次向量检索 + 一次可选的 rerank + 一次工具调用 + 一次大模型推理 + 一次后处理 + 多次流式 chunk",每一段都可能引入延迟尖刺、token 成本失控、幻觉注入、上下文泄漏。生产事故复盘时,你会发现 80% 的"模型变笨了"不是模型变了,而是检索段被人改了一个参数、prompt 段被人改了一个词条、token 计费段被路由换了一个慢通道。没有 trace 平台,你看见的只是"昨天 14:32 用户投诉一次回答是错的";有 trace 平台,你看见的是"14:32:01.234 检索段的 top-3 文档命中分数从 0.82 跌到 0.41,根因是 14:31:50 索引段的 embedding 模型从 text-embedding-3-small 切到 text-embedding-3-large 后未做归一化补偿"。

当前业内把这件事做成了商业产品 + 开源自托管两条赛道。商业赛道以 LangSmith(LangChain 官方)、Langfuse(德国团队开源核心 + 商业云)、Helicone(主打 token cost 与路由)、Phoenix(Arize 开源)、Arize Phoenix、Arize AI(企业版)为代表,加上 Datadog LLM Observability、New Relic AI Monitoring、Dynatrace AI Observability 这些"传统 APM 厂商补 LLM 模块"的玩家;开源自托管赛道则更分裂,Langfuse 自托管、Helicone 自托管、Phoenix 自托管、OpenLLMetry(Traceloop 出品)各自有 sidecar、SDK、collector 三种部署形态。问题在于:没有标准化,每家都在发明自己的 span 属性、自己的 trace 模型、自己的 token 计费字段。今天你的 agent 代码接入了 LangSmith,明天想切到 Langfuse,需要改 trace SDK、改 span 属性命名、改 cost 计算位置;更糟的是,你没办法把"过去三个月的 trace 数据"无损迁移到新平台,因为 span schema 不兼容。

本文要回答四个问题:第一,LLM 应用的 trace 应该有什么样的最小信息单元(即"trace 四元组 + span 层级"的统一抽象,而不是每家自己造一套);第二,OpenTelemetry + OpenLLMetry + GenAI semantic conventions 这条标准化的路径走到了哪一步(以及为什么 2026 年还远未到"一次接入全平台通");第三,商业产品横评的工程真相(不是 marketing 里的 feature 列表,而是部署成本、自托管可行性、数据导出能力、多租户隔离边界);第四,自托管 vs SaaS 的决策框架(你的合规边界、你的工程师密度、你的数据量级决定了你能选哪一条)。最后一节会落到一份给 SRE 的可观测性清单,可以直接复制到团队 wiki。

二、形式化:trace 四元组 + span 层级 + cost/eval

我们用一个统一抽象来描述一次 LLM 调用,这个抽象对所有平台都成立,不管你最后接 LangSmith 还是 Langfuse 还是自建:

Trace 是用户视角的一次完整请求。从用户按下"发送"到流式响应结束(或被中断),一次 trace 包含一个 trace_id(全局唯一,贯穿前后端)、一个 session_id(用户维度的会话聚合)、一个 user_id(可空,租户维度)、一个 metadata(任意 JSON,例如环境标志、AB 实验组、客户端版本)。Span 是 trace 内部的一个逻辑段,是 trace 平台真正消费和检索的最小单元。一次典型的 LLM 调用展开成 span 树如下(简化):

trace: chat_completion (root, kind=llm, 4123ms)
├── span: prompt_assembly (kind=chain, 12ms)
├── span: retrieval (kind=retriever, 87ms)
│   ├── span: embedding (kind=embedding, 34ms)
│   └── span: vector_search (kind=tool, 53ms)
├── span: rerank (kind=tool, 41ms, optional)
├── span: llm_call (kind=llm, 3421ms)
│   ├── span: tokenizer (kind=tool, 4ms)
│   ├── span: provider_request (kind=tool, 3380ms)
│   └── span: stream_decode (kind=tool, 37ms)
├── span: post_process (kind=tool, 8ms)
└── span: cost_calc (kind=evaluator, 1ms, post-hoc)

每一类 span 都有一组强制属性(必须填,否则 trace 平台视为"低质量 trace"会降权展示)和可选属性(用来增强检索与聚合)。强制属性至少包括:

• span_id(唯一)、parent_span_id(根 span 为空)、name(可读名)、kind(枚举:llm/chain/retriever/tool/embedding/evaluator/guard)、start_time、end_time(或 duration_ms)
• LLM 类 span 额外:model(模型 ID,例如 gpt-4o-2024-08-06)、provider(openai/anthropic/azure/google/bedrock/vertex)、input_tokens、output_tokens、total_tokens、prompt_hash(用于聚合相同 prompt)、temperature、finish_reason
• Retriever 类 span:retriever_type(vector/bm25/hybrid)、top_k、query、hits(含 doc_id、score)、latency_breakdown(各子段时间)
• Tool 类 span:tool_name、tool_input_hash、tool_output_size、tool_status(ok/error/timeout)

可选属性承担"非结构化"信息,例如 error_stack、prompt_template_version、ab_group、user_tier、region、cache_hit、retry_count。

Cost 字段不是 span 的"附带字段",而是从 input_tokens/output_tokens/model 三个字段衍生的派生字段。每家平台都试图把它做成第一公民:LangSmith 早期用 usage 对象挂 cost、Helicone 直接做"cost-first"的路由层(按 cost 阈值熔断)、Langfuse 把 cost 计算放在 server 端 evaluator、Phoenix 用 span attribute 三件套(model + tokens)做离线成本归因。但工程真相是:cost 计算的"权威位置"必须是你的服务端,不是平台服务端——理由有三:(a) 你可能有内部折扣价(例如和 OpenAI 签的 enterprise agreement),平台拿不到;(b) 你可能用 vLLM 自托管,model 字段填的是 self_hosted_llama3.1-70b,平台没有该模型的定价表;(c) 你可能有混合路由(主路由 + 备用路由),cost 是分路由计算的,平台只能拿到"返回路由"的 cost,拿不到"实际选择路由"的成本决策树。正确做法:在你的 trace SDK 里,onSpanEnd 钩子里直接 cost = compute_cost(span, pricing_table),把 cost_usd、cost_breakdown 写回 span,平台只负责存储与展示。

Eval 字段同样不是"评估平台的事",而是 span 的内禀属性。评估有三层:offline eval(评测集 + 评分模型)、online eval(线上反馈回流)、human eval(标注平台)。每一层都应该在 trace 上挂一个 evaluation 对象——例如 {"metric": "faithfulness", "score": 0.87, "evaluator": "gpt-4-judge-v1", "comment": "...", "evaluator_version": "v3.2"}。多个 evaluator 给同一个 span 打分,就挂多个 evaluation 对象,绝不用 "取平均" 的方式合并——平均会丢失"faithfulness 高但 relevance 低"这种关键诊断信号。

这套抽象对应到 OpenTelemetry 语义就是 gen_ai.* 命名空间下的属性族(详见第四节),但即使是 LangSmith/Langfuse 这些没完全跟进 OTel 的平台,内部数据模型也是这个抽象的子集或变体。记住这套抽象,选型就不再被 vendor lock-in 绑架。

三、商业产品横评:LangSmith/Langfuse/Helicone/Phoenix/Arize

下面这张表是 2026 年 8 月这五家主流产品的工程真相横评,所有特性都基于公开文档与我的实测(实测日期:2026-08-05;以下价格/限制可能随时间变化,选型前必重新核对):

几个常被忽视的工程真相:

第一,LangSmith 没有自托管,这是最大的 vendor lock-in 风险。你的生产 trace 数据进了 LangChain 的服务器,合同终止、数据迁移、跨 region 合规,每一步都要走 LangChain 的法务流程。任何打算把 LLM 应用做到金融、医疗、跨境业务的团队,第一道筛选项就是"必须支持自托管",从表上看只有 Langfuse/Helicone/Phoenix 三家满足。

第二,Helicone 的"主打 cost"路线虽然工程上很优雅,但它的核心定位是"AI Gateway"(trace + cost + routing + cache),不是纯 trace 平台。如果你只想要 trace,接 Helicone 会被它的"路由 + 缓存"心智模型绑架——你想关掉它的 cache,得读它的文档,得绕过它的 SDK 强制钩子。适合场景:你正在做多模型路由(主备 + 成本熔断),Helicone 一站式解决。不适合场景:你已经有自己的 AI Gateway(比如 LiteLLM / Portkey),只想接 trace,Langfuse/Phoenix 更干净。

第三,Phoenix 的"开源 + 自托管"路线对工程师密度有要求。Phoenix 后端是 FastAPI + Postgres + ClickHouse + 一个 React 前端,自托管的运维成本不亚于自托管一个 Grafana+Prometheus+Loki(更准确的对照是 Tempo,因为 Phoenix 底层用 ClickHouse 列存做 span 检索)。中小团队没有专职 SRE,跑 Phoenix 三到六个月通常会因为"schema 升级失败导致 trace 全丢"或"ClickHouse 磁盘爆了"放弃。

第四,Arize AI 企业版是"贵但省心"的选项。它的核心差异在"评估 + 漂移检测"做得很深,例如它能自动检测"retriever 段 top-1 文档分数的分布漂移",自动告警"今天 14:00 的 retriever 质量比昨天 14:00 跌了 2 个 sigma"——这种**统计过程控制(SPC)**级别的监控,LangSmith/Langfuse/Phoenix 都还在 beta。代价是企业版价格通常是 LangSmith 的 3-5 倍,且数据必须进 Arize 美国服务器。

第五,prompt 版本化这件事 LangSmith 做得最深(它有 hub 概念,可以 fork、diff、rollback),Langfuse 次之(自带 prompt management module,但没有 hub 概念)。Helicone/Phoenix/Arize 的 prompt 版本化都比较弱,如果你重度依赖 prompt A/B 和 prompt rollback,LangSmith + 自托管 trace 备份 是当下最稳的组合。

四、标准化:OpenTelemetry + OpenLLMetry + GenAI semconv

LLM 应用的 trace 标准化,目前有三条线索在交织:OpenTelemetry(OTel)作为底座,OpenLLMetry 作为事实标准 SDK,GenAI semantic conventions 作为属性规范。2026 年的现状是:SDK 已经基本收敛(OpenLLMetry 成为事实标准),但属性规范仍在快速演化(GenAI semconv 当前在 v1.30+,每月都有 breaking change)。

OpenTelemetry 本身是为传统 RPC 设计的多语言 instrumentation 标准。它定义了 trace/span/metric/log 的数据模型、context propagation 协议(W3C Trace Context)、collector 架构(agent + gateway + backend)。对 LLM 应用来说,OTel 解决了 50% 的问题:它把 span/trace/context propagation 这套 RPC 时代的抽象原封不动搬了过来,LLM 应用可以直接复用 OTel collector 把 trace 推到 Tempo/Jaeger/Datadog/Honeycomb。剩下 50% 的问题(LLM 特有的 prompt/tokens/model/cost/retrieval hit 等)需要 GenAI semconv 解决。

GenAI semantic conventions(简称 GenAI semconv)是 OTel 的一个工作组(由 Traceloop、OpenAI、Arize 等贡献)在维护的属性规范。它定义了 LLM/Embedding/Retriever/Tool/Agent 五类 span 的强制属性集,例如:

• gen_ai.system = "openai" / "anthropic" / "azure.openai" / "bedrock" / "vertex.ai"
• gen_ai.request.model = "gpt-4o" / "claude-3-5-sonnet"
• gen_ai.usage.input_tokens / gen_ai.usage.output_tokens
• gen_ai.response.finish_reasons = ["stop"] / ["length"] / ["tool_calls"]
• gen_ai.request.temperature / gen_ai.request.top_p / gen_ai.request.max_tokens
• gen_ai.retrieval.query / gen_ai.retrieval.documents[].document.id / gen_ai.retrieval.documents[].document.score

注意:GenAI semconv 在 2026 年仍在 breaking 阶段。v1.24 把 gen_ai.usage.prompt_tokens 改成了 gen_ai.usage.input_tokens(语义更准,因为 LLM 也有 system prompt、user prompt、assistant prefix 等多种 token 来源);v1.28 把 retrieval 的 documents 从 JSON 字符串改成了 array 结构;v1.30 引入了 gen_ai.agent.* 命名空间处理 Agent 特有的属性。任何 vendor 自己定义了一套 attributes,都在赌"我的版本会成为标准"——LangSmith 的私有 schema、Helicone 的私有 schema 都是这种赌注。

OpenLLMetry 是 Traceloop(2026 年已被 Datadog 收购)出品的 Python/TS/Go SDK,实现了 GenAI semconv,对所有主流 LLM 框架(LangChain / LlamaIndex / Haystack / OpenAI SDK / Anthropic SDK / Vercel AI SDK)做自动 instrumentation。换句话说,只要你的代码用了这些框架中的任何一个,接入 OpenLLMetry 就能自动生成符合 GenAI semconv 的 span,不需要手动写 instrumentation。OpenLLMetry 的 exporter 模块可以把 trace 推到 Langfuse、Helicone、Phoenix、Arize、Honeycomb、Datadog、New Relic、Dynatrace、Jaeger、Tempo,真正的"一次接入全平台通"(理想状态)。

但工程真相是:OpenLLMetry 还远未到"无脑接入"的程度。三个常见坑:

• 手工 prompt 组装不被覆盖。OpenLLMetry 通过 monkey-patch 框架 SDK 工作,如果你的代码绕过框架直接 client.chat.completions.create(...),trace 是空的。修正:用 @track 装饰器包一层自定义 instrumentation,或者改用框架 SDK 调用。
• retrieval 的 document 关联不完整。OpenLLMetry 抓到 retriever 调用的 query 和 top-k,但抓不到"这个 doc 后续进了 prompt 的哪个位置、占多少 token、是不是被截断"。修正:在 retrieval span 的 onSpanEnd 里手动写 gen_ai.retrieval.documents[].document.context_token_count 和 gen_ai.retrieval.documents[].document.is_truncated。
• cost 计算仍是 client-side responsibility。OpenLLMetry 不替你算 cost,因为它不知道你的内部折扣价和混合路由策略。修正:自定义 cost evaluator,把 gen_ai.usage.cost_usd / gen_ai.usage.cost_breakdown 写回 span。

长期看,2026 H2 会出现"一次接入全平台通"的稳态——Langfuse、Helicone、Phoenix 已经全部支持 OpenLLMetry 协议,LangSmith 还在抗拒(它在赌自己的私有 schema 赢),Arize 在企业版支持 OTel 但社区版仍是私有 schema。选型建议:如果你还没有 trace,直接接 OpenLLMetry + 自托管 Langfuse 或 Phoenix,数据完全可控;如果你已经在用 LangSmith 且切不走,加一个 OpenLLMetry sidecar 把 trace 镜像到 Langfuse 自托管(双写)作为合规备份。

五、token 成本归因与多租户计费观测

LLM 应用的 token 成本结构,和传统 SaaS 的"CPU 核数 + 内存 GB + 存储 GB"线性计费有本质区别:token 成本是"prompt 长度 × 调用次数 × 模型单价"的三阶函数,prompt 长度随上下文变化,调用次数随对话轮数变化,模型单价随你切路由变化。一个 RAG 应用的月度账单波动 5x 是常态(月初低峰、月末高峰、季度促销期间 10x),传统计费系统根本看不懂这笔账怎么算出来的。LLM 可观测性平台的"成本归因"模块就是为这件事设计的——它需要能回答:

1. 本次调用的成本拆解:model 单价 × (input_tokens + output_tokens) = prompt_cost + completion_cost,加上 retrieval cost(向量检索 + rerank 的 GPU/IO 成本,通常按 query 计)、tool cost(工具调用的 API 费用)、embedding cost(每次 embedding 的 token 成本)。每一段独立计费、独立展示。
2. 本次调用的成本归因到租户/用户/会话:同一物理服务给租户 A 和租户 B 各跑了一次,账单必须分开。多租户隔离的 trace 平台必须有 tenant_id 维度的索引和聚合,且租户级 trace 数据互相不可见(包括成本数字)。
3. 成本异常的实时告警:某租户的 token 成本突然上涨 3x,你需要平台能自动告警"这个租户可能在跑 prompt injection(被诱导跑长 prompt),或者被滥用了"。
4. 成本优化的"模拟回放"能力:你调高了 temperature、调高了 top_p、换了一个更贵的 model,必须能在生产 trace 上回放"(原配置 vs 新配置)的成本对比"——这是 Helm/Helicone 的"cost simulator"、Langfuse 的"experiment cost"模块的核心价值。

工程实现的关键决策:cost 计算放在哪?

• 方案 A:平台服务端算(LangSmith/Langfuse 默认模式)。优点:平台能跨 trace 聚合,能展示"全站本月成本"总览。缺点:平台不知道你的内部折扣价、不知道你的私有模型单价、不知道你的混合路由策略,算出来的成本只能作为近似参考,不能作为财务对账依据。
• 方案 B:你自己的 SDK 算(推荐)。在你的 trace SDK 注入钩子里,跑 cost = pricing_table[model]['input'] * input_tokens + pricing_table[model]['output'] * output_tokens,把 cost_usd、cost_breakdown 写回 span。平台只负责展示与聚合。优点:成本数字唯一权威,可以作为财务对账。缺点:pricing_table 维护成本(每次模型调价你都得更新)。
• 方案 C:OpenLLMetry + 自定义 cost evaluator(最灵活)。OpenLLMetry 提供 CostEvaluator 接口,你自己实现一个,把定价表从 yaml 文件或 secrets manager 加载,产出成本写入 span。

多租户隔离的工程真相:自托管平台(Langfuse/Helicone/Phoenix)的租户隔离是"按 project 隔离数据 + 按 API key 隔离权限",和你传统 SaaS 的 RBAC 模型一致;SaaS 平台(LangSmith/Arize)的租户隔离多了一层"平台本身能看见所有租户数据"的合规风险——你签的 MSA 通常会写"vendor 可访问客户数据用于服务运营",在 GDPR / HIPAA / 等保 2.0 三级 的合规审计里,这是个红旗。多租户 SaaS trace 平台通常不通过金融级合规审计——这就是为什么头部金融科技公司全部自托管 Langfuse 或 Phoenix。

六、评估闭环:在线评估 + human feedback + prompt 版本化

LLM 应用的"评估"是 2025-2026 年整个行业还在野蛮生长的领域。没有任何一家平台敢说自己的评估能力"够了"——但所有平台都在堆功能。常见的评估闭环由三层组成:

第一层:离线评估(offline eval)。你在 CI 里跑一个评测集(例如 1000 条人工标注的 query + 标准答案),跑过 LLM 应用,跑过 LLM-as-judge(用 GPT-4o / Claude 3.5 打分),得到 faithfulness / relevance / harmfulness 等维度的分数。这套和 trace 平台的关系:评测集跑出来的每一条结果,必须挂回对应的 trace,这样你在 dashboard 上能看到"faithfulness 分数下降的 30 条 trace 都在 retriever 段的 top-1 score < 0.4 这个分支"。Phoenix 在这层做得最深(它的 evaluator 框架允许自定义 evaluator 并自动挂回 trace),Langfuse 次之,LangSmith 的 eval 模块偏 closed-source(只能用它定义的几种 metric)。

第二层:在线评估(online eval)。生产 trace 上来后,平台异步跑 LLM-as-judge(避免污染主路径延迟),给每条 trace 打分。这是 trace 平台最有价值的能力——它能告诉你"今天 14:00 的 faithfulness 分数分布比昨天 14:00 跌了 0.05,根因是 retriever 段的 top-1 score 跌了 0.1"。实现的关键工程问题:judge 模型本身的成本(judge 一次的成本大约是主调用的 30-100%),通常需要采样率(例如 10% 的 trace 跑 judge,而不是 100%),且采样率必须可按租户、按模型、按 prompt 版本调。

第三层:human feedback。人工标注是最贵的评估信号,但也是最可信的——LLM-as-judge 在 5-10% 的边界 case 上会说谎,只有人能判断"这条回答到底是不是真的有用"。平台提供的标注 UI(Langfuse/Arize/Phoenix 都有)需要支持:(a) 多标注者一致性(Krippendorff's alpha 之类的指标);(b) 标注任务模板(打分卡 / 偏好对比 / 自由评论);(c) 标注数据导出(JSON/CSV)供你离线分析;(d) 标注数据回流到 trace,作为 human_evaluation 字段。

prompt 版本化与 A/B。这是 LangSmith 的传统强项:你在 prompt hub 里维护一个 prompt 的多个版本(v1 / v2 / v3),在 trace 上挂 prompt_version 字段,你就能在 dashboard 上看到"v2 比 v1 的 faithfulness 高 0.03 但成本高 15%"。没有 prompt 版本化的 trace 平台,所有 prompt 改动都是"匿名改动"——你不知道是哪个版本在跑、不知道是哪个版本踩了雷。工程真相:prompt 版本化和 trace 平台最好是同一个厂商(LangSmith 是当下唯一深度整合的,Langfuse 紧随其后),如果 trace 是 A、prompt 是 B,你得自己写一个 prompt_version → trace_id 的 join 逻辑,通常 3 个月后会因为两边 schema drift 出现数据不一致。

七、自托管 vs SaaS 工程权衡

自托管的工程成本结构:首次部署 1-2 个工程师月(Langfuse 包含 Postgres + ClickHouse + Next.js + Redis + 一个 worker,Phoenix 类似),稳定运行每季度 0.3-0.5 个工程师月(schema 升级、ClickHouse 调优、备份恢复演练),数据量增长带来的扩容每半年 0.5 个工程师月。对应 SaaS 的工程成本:接入 0.1 个工程师日(注册账号 + 改 SDK + 配 API key),稳定运行几乎零(平台负责),但合规/数据迁移/成本失控时切换平台的成本是 5-20 个工程师月(数据迁移、SDK 重写、dashboard 重做)。这两条成本的对比,本质上是在赌"未来三年内你会切换 trace 平台"的概率——如果你赌"不会切",SaaS 永远便宜;如果你赌"会切",自托管是唯一不破产的选项。

自托管的真正护城河不是"省钱",而是"数据所有权 + 合规可控 + 可深度定制"。三个具体场景:

1. 金融、医疗、跨境业务:GDPR / HIPAA / 等保 2.0 / PCI-DSS 都要求"数据不能离开特定 region",SaaS 平台做不到(只有 enterprise plan 才支持 region pinning,且通常要签额外的 MSA)。自托管 Langfuse 或 Phoenix 可以跑在你自己的 region。
2. prompt / model / retrieval 知识产权保护:你的 prompt 模板是你的核心 IP,你的 retriever 索引是你的数据资产,这些 trace 进 SaaS 平台后,平台厂商的工程师在合规流程下可能访问(虽然 contract 上说不会,但工程上没法证明)。头部 AI 公司(尤其是模型层公司)100% 自托管。
3. 深度定制需求:你想把 trace 数据喂给你的内部 BI、自定义 dashboard、机器学习反哺(retriever 训练数据回流),SaaS 平台的导出接口要么收费要么限速,自托管直接 SQL 查 ClickHouse 就行。

自托管的现实障碍:(a) schema 升级失败导致 trace 全丢——Langfuse 一年内通常有 6-10 次 schema 升级,每次升级都需要备份 + 演练;(b) ClickHouse 磁盘爆——trace 数据增长极快,1M trace/月大约 50GB,一年 600GB,需要合理的 retention policy 和冷热分层;(c) 跨 region 灾备——你的生产服务通常多 region,trace 平台也必须多 region,且要做跨 region 的 trace 关联查询(用 trace_id 而非 wall clock);(d) 值班 SRE 的运维负担——半夜 ClickHouse 挂了,你的 SRE 要能 30 分钟内定位、恢复。没有成熟 SRE 团队,自托管 trace 平台 6 个月后大概率会变成"数据丢失 + 没人敢动"的状态。

混合架构(2026 年开始流行):主 trace 走自托管 Langfuse/Phoenix(合规 + 数据所有权)+ 部分高价值 trace 镜像到 SaaS 平台(享受 SaaS 的 AI 能力)。例如,你自托管 Langfuse 做核心 trace,把"被 LLM-as-judge 打分低于 0.5 的低分 trace"镜像到 Helicone 或 Arize,用 SaaS 平台的 AI 帮你诊断根因——这是当下最经济的混合方案。

八、与传统 APM 的本质区别 + 当前局限

LLM 可观测性和传统 APM 的本质区别:传统 APM 的 trace 是"确定性的"(给定相同 input,trace 结构固定);LLM trace 是"概率性的"(给定相同 input,trace 结构、span 数、token 数、retrieval hits 都可能因为模型随机性、检索召回变化、上下文动态拼接而不同)。这个根本差异带来四个传统 APM 工具解决不了的问题:

1. 不能用固定 span 数做告警阈值。传统 APM 告警"retriever span 延迟 > 200ms 告警",LLM 应用里 retriever 偶尔慢是正常的(向量索引刷新、rerank 模型加载);必须用分布式阈值(p99 > 200ms 且持续 5 分钟)而不是绝对阈值。
2. 不能用 trace 数做容量规划。传统 APM "每天 1M trace,平均 50ms,需要 5 核",LLM trace 的 span 数差异极大(简单问答 5 个 span,agent 多步任务 50-200 个 span),容量必须按 span 数 + token 数双维度规划。
3. 不能用 error rate 做 SLO。传统 APM error rate < 0.1% 是黄金标准 SLO,LLM 应用里"模型返回低相关性回答"在技术层面不算 error,但用户体验上是 error;LLM 应用的 SLO 必须基于"评估分数"而非"错误码"——faithfulness p50 > 0.85、relevance p50 > 0.80。
4. 不能用 log search 做根因分析。传统 APM "grep 日志找 error",LLM 应用里 90% 的"质量事故"在技术上是 success 的——模型成功返回,只是返回得不对;根因分析必须基于 trace + evaluation + context 三件套,而不是 log search。

当前的局限(2026 年仍在快速演进):

• 跨 trace 的关联分析能力弱。平台能聚合"某 prompt 版本在 7 天内的 faithfulness 分布",但不能聚合"用户 X 在跨 session 的对话中,token 成本是越来越高还是越来越低"——这需要 session 级 graph 查询,大多数平台还没实现。
• 长上下文(>128K token)的 trace 性能。ClickHouse / Postgres 都能存,但 span attribute 在 100K+ token 时序列化/反序列化会成为瓶颈,Phoenix 在 >500K token 的 trace 上有已知性能问题。
• 多模态 trace。图像/音频/视频的 LLM 调用,trace 平台还停留在"把 base64 编码当字符串塞 span attribute"的阶段,没有专门的多模态 span schema。GenAI semconv 的 multimodal extensions 还在 draft。
• Agent 多步 trace 的可视化。OpenLLMetry 能抓 agent 的每一步,但可视化工具(Jaeger/Tempo/Phoenix UI)在展示 50+ span 的 trace tree 时,人类肉眼已经无法定位根因——需要 AI 辅助的"trace summarizer"。Langfuse 在 beta,Phoenix 在 beta,Arize 在企业版。

长期看,trace 平台会从"数据存储 + 可视化"演化为"AI 诊断助手 + 自治修复"。例如,Arize 在 2026 年开始内测 "AutoTriage"——它会自己读 trace、自动定位根因、自动给修复建议(例如"retriever 段的 top-1 score 跌了,建议把 embedding 模型切回 text-embedding-3-small")。这条路径一旦成熟,SRE 的角色会从"看 trace 定位问题"变成"review AI 建议并执行"。

九、给 SRE 的可观测性清单 + 选型决策树

最后一份清单,可以直接复制到团队 wiki。

Step 1:决定自托管 vs SaaS

• 数据是否需要留在你的 region?→ 是:排除 LangSmith / Arize AI(SaaS-only);保留 Langfuse / Helicone / Phoenix
• 你有没有成熟 SRE 团队(每个 region 至少 2 人)?→ 否:排除全部自托管;用 SaaS + data export
• 你是否预期 3 年内会切 trace 平台?→ 是:用 SaaS(切换成本最低);否:用自托管(数据归属 + 长期 cost 更优)

Step 2:选择基座

• 你的应用大量用 LangChain/LlamaIndex 框架?→ OpenLLMetry + Langfuse(生态最齐)
• 你的应用是裸 OpenAI/Anthropic SDK + 自研 agent loop?→ OpenLLMetry + Phoenix(最干净的自托管)
• 你想做多模型路由 + cost 熔断?→ Helicone(它就是 AI Gateway,trace 是副产品)
• 你想要最深的 prompt 版本化 + A/B?→ LangSmith(私有 schema 是它的赌注,赌赢了绑定你)
• 你想要企业级评估 + 漂移检测?→ Arize AI(贵但省心,数据必须在美国)

Step 3:接入

• 用 OpenLLMetry SDK + @track 装饰器包自定义逻辑
• 在 onSpanEnd 钩子里写 cost evaluator、retrieval 关联、tool call 关联
• 把 gen_ai.usage.cost_usd / gen_ai.retrieval.documents[].document.context_token_count 等 GenAI semconv 强制属性写满
• 部署 OTel collector 做 trace 路由(允许双写:本地存储 + SaaS 镜像)

Step 4:配置告警

• retriever 段 top-1 score p50 跌 0.1(统计过程控制)
• llm_call 段 total_tokens p99 超过预算(成本熔断)
• faithfulness 分数 7 天滚动平均跌 0.05(质量退化)
• 任何 evaluator 的 score 标准差 > 平均值的 0.3(评估不稳定)

Step 5:构建评估闭环

• offline eval:每周跑评测集,挂回 trace
• online eval:10% 采样跑 LLM-as-judge,挂回 trace
• human feedback:每周抽 50 条人工标注,挂回 trace
• prompt A/B:每次 prompt 改动必走实验,trace 上挂 prompt_version

Step 6:定期演练

• 每月一次"trace 数据恢复演练"(从 ClickHouse 备份恢复)
• 每季度一次"schema 升级演练"(在 staging 跑 Langfuse/Phoenix 升级)
• 每半年一次"trace 平台切换演练"(评估自托管 → SaaS / SaaS → 自托管的成本)

摘要:LLM 应用的可观测性,本质是"把概率性调用变成可解释的 trace 四元组 + span 树 + cost/eval 字段",而当前的商业平台(LangSmith/Langfuse/Helicone/Phoenix/Arize)在 SDK、schema、self-hosting、eval 能力上各有侧重;选型必须基于数据归属、工程师密度、未来迁移概率三件事做权衡,没有"最好"只有"最适合你的阶段"。

参考文献

1. OpenTelemetry GenAI Semantic Conventions Specification v1.30, OpenTelemetry CNCF Working Group, 2026.
2. Traceloop OpenLLMetry Documentation, Traceloop Inc., 2026.
3. LangSmith Observability Documentation, LangChain Inc., 2026.
4. Langfuse Open-Source LLM Engineering Platform Documentation, Langfuse GmbH, 2026.
5. Helicone Open-Source LLM Observability Documentation, Helicone Inc., 2026.
6. Arize Phoenix Open-Source Documentation, Arize AI Inc., 2026.
7. Arize AI Enterprise Platform Documentation, Arize AI Inc., 2026.
8. Datadog LLM Observability Product Brief, Datadog Inc., 2026.
9. New Relic AI Monitoring Product Brief, New Relic Inc., 2026.
10. GDPR Article 28 - Processor Obligations, European Union, 2018 (持续更新).
11. HIPAA Security Rule §164.312 - Technical Safeguards, U.S. Department of Health and Human Services, 2026 revision.
12. 信息安全技术 网络安全等级保护基本要求 第2.0版 (等保2.0), 中国国家标准化管理委员会, 2019 (持续更新).
13. W3C Trace Context Recommendation, W3C Working Group, 2020 (持续更新).
14. ClickHouse Documentation - Column-Oriented Storage for Observability, ClickHouse Inc., 2026.