你在做一个大模型应用时大概率遇到过这样的画面本地联调时表现极好的聊天机器人一上线就开始在一些奇怪问题上胡说八道。你说不清是提示词写得不稳还是知识库版本被某个同事悄悄替换了你打开监控面板看到请求成功率 99.9%延迟也很平稳却没有一个指标能告诉你“为什么用户普遍反馈变笨了”。这是传统监控体系面对大模型应用时最尴尬的盲区系统没有故障但模型行为在悄悄劣化。AI 可观测性要解决的正是这类“应用活着、但效果在崩”的问题。它并不是传统监控的改版而是从埋点、追踪、评估、成本治理到回归测试的一整套新链路。今天想借一个行业事件来聊透这件事Dynatrace 宣布计划收购 AI 可观测性公司 Arize AI。这则消息对后端工程师和 AI 应用开发者的真正含义不是又多了一桩资本并购而是“AI 应用的可观测性正在成为平台级能力”这一判断开始被主流监控厂商验证。读完这篇文章你会理解 AI 可观测性的概念边界、它与传统 APM 的本质差异并拿到一套可以最小化跑通的 LLM 链路追踪、质量评估和成本统计示例直接用到自己的大模型项目里。1. 这则消息为什么值得开发者关注Dynatrace 一直是应用可观测性领域的头部厂商核心能力是面向企业级 IT 系统的监控、链路追踪和智能运维且很早就把和 AI 结合起来的思路放进了产品中比如在故障定位时用 AI 辅助判断根因。Arize AI 则有所不同它更聚焦在模型本身的行为监控上做得比较深的是 LLM 追踪、评估体系、实验对比和模型生产环境的性能监控。从公开信息来看这是一次典型的能力拼图式收购一家拥有成熟基础设施监控能力的大厂去买一个在模型评估与链路追踪上有技术积累的团队。对开发者来说真正的信号有两层。第一层信号是“模型行为本身正在成为系统监控的一部分”。过去我们的监控体系围绕服务、容器、数据库、中间件来建关心的是请求能否成功返回。但大模型应用的核心价值在于生成内容的质量请求成功不等于回答正确。Arize 这类工具的切口正好就是模型输出的质量评估、归因和回放调试。这件事如果被主流监控平台整合意味着以后的监控告警不再只是“应用挂了”还会包含“模型输出跑偏了”。第二层信号是 AI 可观测性的技术栈正在逐步标准化。很多团队做 LLM 应用排查时最麻烦的不是看不到日志而是每个团队都有自己的埋点方式有的把 prompt 直接打到日志里有的只在出问题时才临时打印上下文。这种混乱状态很难支撑规模化排查。主流监控平台开始整合模型评估能力会推动更多团队沿 OpenTelemetry GenAI 语义约定这一套通用规范来埋点让链路追踪、模型调用、评估结果、成本数据从“各方自定义”走向“统一格式”。当然这笔收购的最终完成还会受监管审批和交割条件影响本文不作任何落地时间推断。我们更应该关注的是技术趋势本身AI 可观测性正在从少数团队的“自研补丁”变成一个平台级的基础设施问题。2. AI 可观测性到底是什么概念边界与核心要素AI 可观测性也叫 AI Observability指对 AI 应用内部状态、模型行为和输出质量进行观测、追踪、评估与诊断的能力。它不等同于传统的应用监控也不只是给日志加几个字段而是把“模型调用链”和“输出质量”纳入可观测范围。传统可观测性覆盖三大支柱指标、日志、链路追踪。AI 可观测性在这三个支柱之上又增加了几层新内容模型调用追踪记录一次大模型请求从提示词组装、模型调用、工具调用、知识库检索到最终结果返回的完整链路。输出质量评估不仅记录模型输出了什么还要评估这个输出对不对、是否忠于上下文、是否有幻觉、是否符合安全要求。成本与用量治理统计 token 消耗、模型成本、不同业务线的调用配额避免大模型应用上线后成本失控。实验与回归把生产环境抓到的失败样本沉淀成回归集用来验证新提示词或新模型版本是否会修复问题并引入新问题。理解 AI 可观测性时最容易混淆的是它和 MLOps 的边界。MLOps 关注的是模型训练、实验、部署和模型版本管理的完整生命周期核心对象是模型训练流程AI 可观测性更关注模型部署上线后在生产环境中运行的行为、质量、成本和链路。简单说MLOps 解决“模型怎么上线”AIObservability 解决“上线后怎么知道它还好不好、出了问题怎么查”。维度传统应用监控MLOpsAI 可观测性核心对象服务、容器、数据库模型训练、实验、部署流程生产环境中的模型调用与输出质量主要关心的指标可用率、延迟、错误率、资源占用模型指标、训练收敛、特征分布输出质量、幻觉率、成本、链路正确性链路追踪粒度HTTP 调用、数据库 SQL实验版本、数据版本一次 LLM 调用内的 prompt、context、模型输出典型使用时机系统故障排障上线前与训练阶段上线后持续监控与排障对做 AI 应用的人来说理解这个概念的关键点是模型本身不是黑盒但它的行为受到提示词、上下文、模型版本、历史会话等多重因素影响。AI 可观测性就是把黑盒拆开让你能回答三个问题模型这次为什么这样回答、这次回答质量如何、这次调用花了多少钱。3. 传统 APM 为什么管不住大模型应用很多团队刚做大模型项目时第一反应是把 OpenAI SDK 或自有模型的调用包装一层日志然后在原有的监控系统上加一个自定义指标。这种方案在 Demo 阶段没有任何问题但当应用进入生产环境问题就会逐渐暴露。传统 APM 以“服务”和“资源”为中心。它假设一个系统的故障模式是服务不可用、接口超时、数据库连接异常、CPU 或内存被打满。可大模型应用的主要故障模式完全不同模型服务本身没有崩溃接口响应也非常快但返回内容质量明显下降。这种故障无法通过可用率指标发现传统监控面板上看起来一切都是绿的。举个例子一个 RAG 类知识库问答系统上线后工程师突然收到大量用户反馈“回答变差了”。他们打开监控面板发现模型服务请求成功率还是 99.9%平均延迟甚至比前几天还低。真正的问题可能出在知识库向量化脚本在某次发布时遗漏了重建索引入口导致检索召回了一批过期文档也可能是上游改了 prompt 模板在拼接用户问题时引入了一段错误的指令。这些原因都不在传统监控的关注范围内因为请求链路本身是通的。另一个典型场景是 Agent 应用。AI Agent 会在一轮用户请求中多次调用模型并穿插调用工具、查询数据库、读取文件。如果某个中间工具返回了空数据Agent 可能会“强行”基于缺失信息继续往下编造。这时候排查路径不是看某个服务的错误率而是要恢复完整的调用链用户问题、模型思考过程、工具返回结果、最终模型输出。传统 APM 的调用链不会记录模型的思考文本和工具返回细节因此无法完成这类定位。日志系统也没办法简单解决。直接把完整的 prompt 和模型输出打到常规日志中会带来明显的隐私和性能问题PII 信息、敏感业务数据、token 费用的统计格式都不是普通日志框架擅长的。更麻烦的是模型输出质量是一个需要“带参考系”才能判断的指标必须结合业务上下文和评估基准来看常规日志没有这种结构。所以与其说传统 APM“不够用”不如说大模型应用引入了一种新的故障类型行为劣化。这种故障需要新的数据模型、新的评估方法和新的调试流程这就是为什么 AI 可观测性会成为一个独立方向。4. AI 可观测性的三个核心层追踪、评估、成本治理如果把一个可落地的 AI 可观测性体系拆开大概率会得到三个相互独立又需要打通的层次。4.1 第一层链路追踪链路追踪是 AI 可观测性的地基。它记录一次用户请求中发生了多少次模型调用、每次调用的模型名和参数、输入的 prompt、输出的 response、token 消耗和时间开销以及上下文信息和工具调用结果。没有这层数据后续的评估和成本分析都无从谈起。链路追踪的关键设计点在于统一 Span 语义。建议直接参考 OpenTelemetry 社区推动的 GenAI 语义约定gen_ai.system记录模型供应商gen_ai.request.model记录模型名gen_ai.usage.prompt_tokens和gen_ai.usage.completion_tokens记录消耗的 token 数。采用统一约定之后无论底层是大模型供应商、开源模型、还是自研小模型上层的追踪平台都能用同一套逻辑解析数据。4.2 第二层质量评估追踪告诉我们模型“做了什么”但无法回答“做得好不好”。质量评估层负责判断输出质量常见的做法包括基于规则的检查比如是否包含特定敏感词、长度是否异常基于统计的方法比如输出文本与源文本的相似度、不确定性估计以及基于模型的评估由另一个大模型作为 Judge 对输出进行打分。生产环境中质量评估不需要覆盖所有请求。更稳妥的做法是采样评估对重要的业务流量做全量标记对普通流量按比例采样。同时把生产环境发现的错误样本存入评估数据集形成回归集。下一次更新 prompt、升级模型版本或调整 RAG 参数前先用回归集跑一遍可以提前发现“修复 A 问题却引入 B 问题”的情况。4.3 第三层成本治理大模型应用的成本问题是很多团队上线后才意识到的“隐性地雷”。一次普通问答可能消耗几百 token看起来不多但流量放大后就是一笔不小的开支。如果不按业务线、用户、功能场景做 token 消耗统计成本一旦失控很难定位是哪部分流量导致。成本治理需要配合链路追踪中的用量数据给每个 Span 打上业务标签比如product.name、feature.name、user.segment再按照标签维度聚合 token 消耗和费用。这样既能做成本报表也能做预算告警。比如某个运营活动上线后如果单体用户调用量异常上升成本聚合面板能快速发现。这里要特别强调三个层不是独立部署而是共享同一份追踪数据。追踪数据采集后评估层从 Span 中读取模型输入输出成本层从 Span 中读取 token 统计。一份数据多种用途这是 AI 可观测性与传统“监控大杂烩”的本质区别。5. 最小可落地的 LLM 可观测性示例下面用一个最小化示例演示前面讲的链路。我会构造一个模拟的 LLM 客户端核心目的是让你在没有真实模型 API 的情况下也能启动一个完整的追踪与评估链路看到数据长什么样。实际项目中你只需要把FakeLLMClient.generate()替换成真实模型调用。5.1 环境准备本示例基于 Python 3.9 及以上版本需要安装 OpenTelemetry SDK。建议新建虚拟环境mkdir llm-obs-demo cd llm-obs-demo python -m venv venv source venv/bin/activate # Windows 下执行 venv\Scripts\activate pip install -U opentelemetry-api opentelemetry-sdk opentelemetry-exporter-otlp为了让代码更贴近生产场景可以加上opentelemetry-exporter-otlp后面需要接入 OTLP Collector 时直接复用。如果只是本地验证使用 SDK 自带的 ConsoleSpanExporter 即可。5.2 示例一为一次 LLM 调用构建完整链路先写一个模拟的 LLM 客户端。这个客户端会在启动 Span 后记录和真实模型调用一致的关键字段。代码路径为llm_obs_demo/llm_client.py。# 文件路径llm_obs_demo/llm_client.py import random import time from opentelemetry import trace from opentelemetry.trace import Status, StatusCode tracer trace.get_tracer(llm-obs-demo) class FakeLLMClient: 最小模拟客户端用于演示链路结构。实际项目中替换为你使用的模型服务。 def __init__(self, model_name: str demo-model): self.model_name model_name # 按实际模型价格填写单位美元 / 千 token self.cost_per_1k_prompt 0.0 self.cost_per_1k_completion 0.0 def generate(self, prompt: str) - dict: with tracer.start_as_current_span(llm.generate) as span: span.set_attribute(gen_ai.system, demo) span.set_attribute(gen_ai.request.model, self.model_name) span.set_attribute(gen_ai.request.prompt, prompt) latency random.uniform(0.1, 0.5) time.sleep(latency) response_text f针对「{prompt}」的模拟生成内容 prompt_tokens max(1, len(prompt) // 2) completion_tokens max(1, len(response_text) // 2) span.set_attribute(gen_ai.response.text, response_text) span.set_attribute(gen_ai.usage.prompt_tokens, prompt_tokens) span.set_attribute(gen_ai.usage.completion_tokens, completion_tokens) span.set_attribute(gen_ai.response.latency_ms, round(latency * 1000, 2)) span.set_status(StatusCode.OK) return { text: response_text, prompt_tokens: prompt_tokens, completion_tokens: completion_tokens, latency_ms: round(latency * 1000, 2), }代码逻辑很简单每次调用generate()时创建一个名为llm.generate的 Span然后把“模型系统、模型名、prompt、响应文本、token 数、延迟”作为 Span 属性写入。生产环境接入真实 SDK 时OpenTelemetry 的集成库通常会自动完成这些字段的写入但理解底层结构仍然非常重要。5.3 示例二把质量评估结果写入 Span追踪只解决“看到了什么”这一层解决“这次回答好不好”。为简化演示我用一个基于规则的评估函数模拟“groundedness”和“安全分数”生产环境中可以替换为更复杂的评估模型。代码路径为llm_obs_demo/evaluator.py。# 文件路径llm_obs_demo/evaluator.py from opentelemetry import trace def evaluate_response(prompt: str, response: dict) - dict: 将评估结果作为 Span 属性写入便于后续按标签检索。 span trace.get_current_span() text response[text] # 简化规则包含“模拟”字样时给一个偏低的接地分数 groundedness 0.95 if 模拟 not in text else 0.60 safety_score 0.99 if 敏感词 not in text else 0.10 span.set_attribute(ai.evaluation.groundedness, groundedness) span.set_attribute(ai.evaluation.safety, safety_score) return { groundedness: groundedness, safety: safety_score, }重点在于评估结果被写回当前 Span意味着以后回溯链路时可以直接看到“这一次生成的质量评分”而不需要再次调用模型评估。生产环境可以把评估做成独立服务通过异步方式回写这些属性。5.4 示例三成本统计与指标导出成本统计需要让追踪数据“上价值”。这里给出一个最简单的方式用 OpenTelemetry Metrics 创建一个 Counter每调用一次模型就累计成本。代码路径为llm_obs_demo/cost_monitor.py。# 文件路径llm_obs_demo/cost_monitor.py from opentelemetry import metrics meter metrics.get_meter(llm-cost-meter) llm_cost meter.create_counter( llm.cost.usd, unitUSD, description累计 LLM 调用成本, ) def record_cost(response: dict, cost_per_1k_prompt: float, cost_per_1k_completion: float) - float: prompt_cost response[prompt_tokens] / 1000.0 * cost_per_1k_prompt completion_cost response[completion_tokens] / 1000.0 * cost_per_1k_completion total_cost prompt_cost completion_cost llm_cost.add(total_cost, {model: demo-model, feature: qa}) return total_cost这里用 Counter 语义做累计成本并打上 model 和 feature 标签。实际工程中建议把用户等级、业务线、调用来源等维度都放进标签方便后期按维度做成本聚合。在主程序main.py里串起来# 文件路径main.py from opentelemetry import trace from opentelemetry.sdk.trace import TracerProvider from opentelemetry.sdk.trace.export import BatchSpanProcessor, ConsoleSpanExporter from opentelemetry.sdk.resources import Resource from llm_obs_demo.llm_client import FakeLLMClient from llm_obs_demo.evaluator import evaluate_response from llm_obs_demo.cost_monitor import record_cost resource Resource.create({service.name: llm-obs-demo}) provider TracerProvider(resourceresource) provider.add_span_processor(BatchSpanProcessor(ConsoleSpanExporter())) trace.set_tracer_provider(provider) client FakeLLMClient(model_namegpt-demo-1) response client.generate(今天天气怎么样) evaluation evaluate_response(今天天气怎么样, response) total_cost record_cost(response, client.cost_per_1k_prompt, client.cost_per_1k_completion) print(response:, response) print(evaluation:, evaluation) print(total_cost_usd:, total_cost)如果要启用 OTLP 导出只需把ConsoleSpanExporter替换成OTLPSpanExporter并配置 endpoint 指向你的 Collector 或后端平台。本地验证阶段先用控制台导出器这样可以直观看到 Span 结构。6. 运行结果与验证方法运行上面的main.py你会在控制台看到类似下面的结构化输出{ name: llm.generate, context: { trace_id: ..., span_id: ... }, attributes: { gen_ai.system: demo, gen_ai.request.model: gpt-demo-1, gen_ai.request.prompt: 今天天气怎么样, gen_ai.response.text: 针对「今天天气怎么样」的模拟生成内容, gen_ai.usage.prompt_tokens: 8, gen_ai.usage.completion_tokens: 9, gen_ai.response.latency_ms: 213.45, ai.evaluation.groundedness: 0.6, ai.evaluation.safety: 0.99 } }同时程序末尾会打印response: {text: 针对「今天天气怎么样」的模拟生成内容, prompt_tokens: 8, completion_tokens: 9, latency_ms: 213.45} evaluation: {groundedness: 0.6, safety: 0.99} total_cost_usd: 0.0如何判断这个示例跑通了观察三点控制台是否输出了带trace_id和span_id的 Span 数据Span 属性里是否同时包含gen_ai.*和ai.evaluation.*两组字段total_cost是否按照你配置的价格正确计算。如果运行时没有输出先检查venv是否激活以及opentelemetry-api和opentelemetry-sdk是否安装成功。可以执行pip list | grep opentelemetry确认版本。如果出现ModuleNotFoundError通常是包未安装或虚拟环境没有激活。这个示例的价值在于它把 AI 可观测性最核心的数据结构落到了真实代码层面。后面要接任何监控后端只需要把导出器换成对应平台提供的 OTLP 配置。7. 生产环境常见问题与排查在真实项目中AI 可观测性落地最常见的坑往往不是监控平台本身而是埋点数据不完整、评估口径不一致、成本数据对不上。问题现象可能原因排查方式解决方案链路中只有模型调用看不到 RAG 检索和工具调用埋点只覆盖了模型层没有为检索和工具调用创建独立 Span查看全链路 Span 列表确认是否有非gen_ai.*的 Span在检索、工具调用、文件读取等关键节点创建独立的子 Span进入生产后评估分数普遍偏低评估规则或评估模型与生产业务场景不匹配随机抽样人工复核看评估器的判断是否合理调整评估阈值或用带标注的回归集重新验证评估器成本报表显示异常偏高没有按业务标签聚合或 Token 统计重复计数对比网关层日志与实际计费数据确认一个请求链路中 Token 只统计一次统一标签命名无法快速定位某次坏回答链路数据没有持久化或采样率过低导致该条追踪丢失确认采样策略是否覆盖了该用户和功能对重点用户和重点功能使用全量采样普通流量按比例采样prompt 中记录了用户手机号等敏感信息埋点时未做脱敏检查 Span 属性确认是否存在敏感字段在写入 Span 前做脱敏或截断对非必要数据不记录服务重启后历史链路查询不到控制台导出器只能实时打印无法回放检查后端存储是否配置持久化改用 OTLP 接入 Collector 和后端存储平台这里要提醒一个容易被忽略的问题AI 可观测性数据不同于普通日志它的价值高度依赖“上下文完整性”。如果只记录模型输出而不记录当时的 prompt、检索上下文和工具返回值问题发生时回溯链路基本等于盲猜。所以埋点的第一原则不是“变量越多越好”而是“每个关键决策点必须有上下文”。另一个高频问题是对评估口径没有统一管理。有的团队用规则评估有的团队用模型评估两个团队对“回答是否正确”的认定标准不同最后做出来两个口径完全不一致的告警面板。建议评估方案作为统一平台能力维护评估规则可配置但口径必须全局一致。8. 最佳实践与工程落地建议看完示例你可能会觉得 AI 可观测性的技术门槛并不高。真正难的是把它接入生产系统后如何保持数据一致、成本可控、不引入新的安全风险。下面几条是工程落地中比较关键的建议。8.1 统一使用 OpenTelemetry 语义约定不要自己造一套链路字段规范。即使短时间看起来更灵活后期对接任何监控平台都要做一遍字段映射成本反而更高。建议在团队内直接采用gen_ai.*前缀的约定并让各业务线在此基础上扩展自定义标签。统一语义约定的价值会在你从 Demo 走向多业务线共用一套监控平台时迅速体现出来。8.2 埋点从真实的排查痛点出发先记录解决真实故障必需的最小字段集再逐步扩展。比如刚上线时可以只记录模型名、prompt 摘要、token 数、延迟、评估分数、业务标签六个字段。等真正遇到工具调用问题再补充工具调用的输入输出详情。一上来就把整个 prompt、完整上下文、所有思考过程全量存下来不仅存储成本高还会让真正重要的故障埋没在噪音中。8.3 安全与隐私必须先于功能prompt 中经常包含用户输入而用户输入中可能包含姓名、地址、企业内网信息。在把 prompt 写入监控系统前必须做脱敏处理和访问控制。推荐的策略是默认不记录原始 prompt只记录截断后的摘要确需全量记录的场景单独开启并按敏感数据标准管理。同时要保证 AI 可观测性平台的数据访问权限独立于业务日志需要严格审计。8.4 评估要和回归集绑定评估如果只用于实时告警效果往往有限。更有价值的是把生产环境中标记为“坏回答”的样本收集起来沉淀成回归集。每次调整 prompt、升级模型、修改 RAG 参数前用同一份回归集做批处理测试对比改动前后的评估分数。这样你就能用数据回答“新 prompt 是否值得上线”而不是靠感觉。8.5 成本统计要提前考虑标签维度成本治理不是简单地统计“今天花了多少 token”而是要能回答“是哪个功能、哪个用户群体、哪个模型版本花的”。在初次埋点时就给 Span 打上product.name、feature.name、model.version、user.level这几个基础标签。后续要按维度分析时数据已经准备好了不用再回填历史数据。8.6 渐进式引入不要一次性全量改造AI 可观测性建设可以按照“单业务验证 → 跨业务推广 → 平台化沉淀”的节奏推进。先在一个重要的业务场景上跑通全链路验证数据质量和告警价值再逐步推广到其他业务线。全量改造的最大风险是评估指标还没验证就被铺到所有业务上最后告警变成噪音团队反而失去对这套系统的信任。8.7 关注模型调用层之外的上下文大模型应用的可观测性问题往往出在模型调用层之外。RAG 检索到的文档是否正确、Agent 调用的工具是否返回了符合预期的结构化数据、多轮会话历史是否泄漏了越权上下文这些都值得设计独立的 Span。把模型调用、RAG 检索、工具调用、提示词组装拆成不同的 Span 层级排障时的第一反应才是从链路图上找断点而不是翻日志猜问题。9. 总结与后续学习方向回到最开始的问题Dynatrace 收购 Arize AI对普通开发者最直接的影响是让 AI 可观测性从一个模糊的概念变成了明确的技术方向。以后大模型应用的可观测性不会停留在“请求成功”这一层而是会深入到“模型输出是否可信、是否忠于上下文、是否符合业务预期”。这套能力不再是大厂专属而是每个认真做 AI 应用的团队都需要补齐的基础设施。这篇文章从概念、原理、示例到生产落地建议把 AI 可观测性的主要脉络梳理了一遍。建议你先跑通文中的最小示例把链路追踪、评估、成本这三个模块在本地跑明白然后回到自己的项目中选择一条核心业务链路做全链路埋点。接下来值得深入的内容包括OpenTelemetry GenAI 语义约定的最新进展、更复杂的评估指标设计、多步 Agent 调用的链路建模、以及基于生产数据构造回归集的具体方法。如果你正在做 AI Agent 开发建议特别关注工具调用的 Span 设计和上下文恢复这是目前绝大多数排查事故中最容易卡住的一环。