AI原生应用可观测性实践：从传统监控到LLM与RAG链路观测

最近圈子里不少人在聊AI原生应用到底该怎么监控，正好看到观测云和百胜软件在合作推进AI原生时代的可观测性，这个方向我很早就想梳理一下。今天就不聊那些概念堆砌的东西了，直接从我在实际项目中趟过的坑出发，聊聊AI原生应用的可观测性到底新在哪里、传统监控为什么不够用、以及如果你现在要给自己团队的一套AI业务搭观测体系，第一步该干什么。

标题里有两个关键词：一个是"观测云"，做可观测性平台的产品和技术方案都比较成熟；另一个是"百胜软件"，零售行业里做数字化和软件下沉的老兵。这两家凑到一块，表面看是一次行业合作，实际上折射出一个非常现实的问题——当AI应用真正跑到生产环境里，那些看似花哨的框架和大模型，一旦出故障，你要怎么定位、怎么排查、怎么止损。

1. AI原生时代，可观测性到底哪里不一样

这一节先聊个最基础但很多人想不明白的问题：AI原生应用和传统应用在监控上有什么本质区别。如果你觉得"不就是接口慢了加机器嘛"，那后面基本也不用看了。

1.1 传统可观测性的三板斧，打在AI问题上显得力不从心

过去十年，监控领域沉淀出来的经典三板斧是指标、日志、链路追踪，也就是大家常说的Metrics、Logs、Traces。这套东西在微服务和云原生时代解决了很多实际问题，比如某个服务CPU飙高，或者某个接口P99延迟变大，通过指标曲线配合链路采样，基本能在一刻钟内定位到瓶颈。

但AI原生应用有个特别折磨人的特性：它的故障不是"崩溃"，而是"劣化"。传统应用挂了会报错，数据库连不上会超时，这些都能触发明确的告警。AI应用不一样，模型服务一直在线，接口也一直返回200，但返回的内容可能是错的、答非所问的、甚至是带幻觉的。你总不能给每个文本响应都配一条告警规则。

再说链路追踪。传统APM追踪的是HTTP调用、数据库查询、MQ消息，这些调用关系是确定性的、有固定拓扑的。AI应用里涉及到的调用经常是非确定性的，比如一轮对话可能触发一次RAG召回，也可能触发三次；同一个Prompt在不同模型版本下走的分支完全不一样。传统的Trace语义在描述"这一次回答是怎么想出来的"这件事上，能力非常弱。

1.2 AI原生业务真正需要观测的四个新对象

那么AI原生的监控到底要比传统监控多关心什么？结合我自己的实践，核心有四个对象，这四个对象在传统监控体系里几乎是不存在的：

第一个是LLM调用本身的质量和成本。 每次大模型调用消耗了多少Token，输入Token和输出Token的比例是多少，在多轮对话里上下文是不是在膨胀，这些直接关系到成本，也关系到响应延迟。尤其是输出Token数，很多团队上了Stream模式之后，发现首字延迟挺快，但整体完成时间很长，问题就出在生成长度上。

第二个是RAG链路的各环节质量。 RAG现在是企业落地AI最主流的方案，它的链路包括Query改写、Embedding向量化、向量检索、重排序、上下文拼装、LLM生成。每一步都可能出问题，而且问题会逐层放大。我见过最典型的场景是，用户明明问A问题，结果Query改写之后变成B问题的检索词，向量库里捞出完全不相干的内容，最后模型一本正经地基于错误上下文编了一堆看似合理的答案。这种问题传统监控根本看不见，因为没有报错。

第三个是Agent的决策轨迹。 现在很多AI应用不再是一问一答了，而是Agent自主调用工具、规划步骤、执行动作。观测Agent的每一次工具调用、每一步规划、每个中间结果，比观测最终输出更靠近问题根源。

第四个是模型版本和Prompt版本的状态漂移。 线上跑的Prompt可能每周都在调，模型也可能从V1切到V2，什么时候切的、切了之后回答风格有什么变化、是变好了还是变差了，必须要有可追溯的观测手段。

所以，AI原生时代的可观测性，本质上是在传统指标、日志、链路之上，再加一层"语义和质量维度"的观测。观测云这类平台现在做的，其实就是把这两层打通，用一套数据底座同时承接传统技术栈和AI技术栈。

2. 观测云与百胜软件的合作背后，是一条可复用的落地路径

看完理念上的差异，再说说我对这次合作的实际理解。百胜软件不是做AI框架的公司，也不卖GPU，它是做零售行业软件的老牌服务商。它选择跟观测云一起探索AI原生可观测性，不是因为赶时髦，而是因为它的客户已经把AI应用跑在业务线上了，出了问题，它得能给别人一个交代。

2.1 从百胜的业务场景看AI监控的刚需

百胜软件服务的零售企业，这两年上AI的场景非常具体：智能客服、商品推荐、导购话术辅助、经营数据分析。这些场景看着不复杂，但有个共同点——都是直接面向业务决策和消费者体验的。

就拿导购话术辅助来说，一个门店的导购在跟顾客沟通时，AI实时给出话术建议。如果这个建议回答慢了3秒，导购肯定不会等，直接用自己经验去应对；如果建议内容出现明显错误，导购可能当场失去信任，以后再也不用这个功能。这种场景下，AI的"可用性"定义已经变了，不是你服务进程活着就算可用，而是"在准确的时间返回语义准确的内容"才算可用。

还有经营数据分析的AI问答。老板问"上个月华东区销售额为什么下降了"，如果这个AI助手告诉你的原因是不相干的、甚至是瞎编的，老板不会觉得是模型问题，他会觉得是系统不好用。这类场景对可观测性的要求非常高，因为你得能从一次问答的完整链路里找出"哪一步的上下文是错误的"，才能解释为什么AI给出了一个糟糕的回答。

2.2 统一可观测底座解决了什么实际问题

百胜这种体量的服务商，它的技术栈往往是混合的：交付给客户的系统里有传统的Java微服务、有MySQL、有Redis，也有新上的向量数据库和大模型API。在过去，日志一套系统、监控一套系统、链路追踪又一套系统，出了问题大家先在群里互相猜。观测云的做法，是把指标、日志、链路、以及AI调用相关的数据统一沉淀到一套平台上，通过关联分析来还原问题现场。

这个思路听起来简单，做起来很考验平台能力。因为AI链路的数据和传统链路的数据格式差异很大，传统Trace是Span树，AI调用还需要额外的Prompt内容、Token用量、模型名称、温度参数、检索片段的得分等等。能把这两类数据放到一个时间轴上，让工程师既能看基础设施指标，又能看到某次具体问答的完整语义链路，这是解决问题的关键。

我自己的体会是：AI原生应用的故障排查，最怕的不是技术难，而是数据散。 一旦数据散落在三四个系统里，你定位一个"AI回答变差"的问题，可能要反复切换界面、手动对齐时间戳，效率极低。统一可观测底座最大的价值，就是把人从"数据搬运工"的角色里解放出来，把精力花在实际分析上。

2.3 这次合作给同行带来什么参考

从行业视角看，观测云和百胜软件这种"可观测平台+行业ISV"的组合，其实是非常典型的一条路径。对绝大多数企业来说，自建一套AI可观测平台是不划算的，不如选择一个能覆盖传统与AI场景的可观测底座，然后结合自己的业务场景去做定制化。

百胜的做法可以作为参考模板：先梳理自己场景里的关键AI链路，再选定可观测平台做数据接入，最后把观测能力沉淀成面向客户的服务。这个路径比我见过的一些"先建平台再造轮子"的做法务实得多。要知道，AI业务跑起来了，业务方最关心的是稳定性和效果可解释性，这些不会因为你用了多少花哨框架而改变。

3. 实操过程：帮你给AI应用搭一套能落地的观测体系

讲到这儿，理论基础差不多了，该聊点能直接上手的东西了。如果你现在就要给自己团队的一套AI应用搭可观测体系，又不想一上来就铺太大的摊子，可以参考下面这个三步走方案。这套方法我在多个项目里验证过，不需要一步到位，但每做一步都能解决一个实际问题。

3.1 第一步：先定位好你的"关键事件"和"关键指标"

很多人搭监控喜欢一上来就选工具、搭平台，这是错的。第一步应该先做梳理。

你要打开自己的AI应用，把核心链路画出来。举个例子，一个RAG问答系统，链路大概是：用户输入 → 服务网关 → 鉴权 → 意图识别 → Prompt构造 → Embedding召回 → 重排序 → 上下文拼装 → LLM生成 → 返回。画完之后，在每个环节旁边标注：这个环节如果出问题，表现是什么？怎么才能发现？

以我实际经验，建议重点盯这几个技术指标：

• 端到端延迟：用户从发起到收到完整回复的总时长。注意这里要拆分P50、P95、P99，因为LLM响应受排队和生成长度影响很大，只看平均值完全没有参考意义。
• 首Token延迟（TTFT）：用户看到第一字出来的时间。这个直接决定AI应用的"体感快慢"，也是调优时最优先要降低的指标。
• Token输入输出拆分：输入Token和输出Token分别记录。有些Prompt膨胀问题，就是输入Token一直在涨，但没人注意到，直到成本报表出来才傻眼。
• 检索质量指标：RAG场景下，记录每次召回的TopK文档得分、重排序后得分、召回文档和问题的余弦相似度。这些分数异常时，往往意味着知识库出了问题。
• 命中率和拒绝率：AI客服场景下，记录Query是否触达到知识库答案（命中），以及是否触发"答不上来"的分支（拒绝）。拒绝率突然飙升，可能是知识库没更新，也可能是指令模板被改坏了。
• 成本度量：每次会话消耗多少Token、调用了多少次模型、单次会话成本估算。成本可观测是AI应用特有的需求，而且非常重要。

关键事件方面，我强烈建议至少把下面四类事件完整记录下来：模型调用异常（超时、限流、接口返回错误）、检索结果异常（召回为空、相关性分数极低）、内容安全违规（触发敏感词过滤）、业务规则冲突（比如推荐结果和库存不符）。

这四类事件里，内容安全违规最容易被人忽略，但它往往是导致重大事故的引信，你宁可多记一条，也不要漏掉。

3.2 第二步：用最小侵入的方式埋好观测点

梳理完指标和事件，接下来就是接入数据。这里我给一个非常实用的原则：不要一上来就做全量埋点，先用最小侵入方式跑通一条主链路。

现在主流方案有两种：一种是直接在代码里引入SDK，手动埋点；另一种是通过Agent采集器或网关层Sidecar自动抓取HTTP出口流量，把LLM调用的出入参自动记录下来。我个人的建议是：如果你们团队对代码改动比较敏感，或者AI部分是外包团队交付的，优先用网关/代理模式，在流量入口统一采集。

如果走代码埋点，下面这段伪代码展示的是最核心的埋点结构，你可以对照自己的语言改：

python复制# 以Python为例，封装一个大模型调用观测装饰器
import time
import json
from opentelemetry import trace

tracer = trace.get_tracer("ai.llm.call")

def observe_llm_call(model_name, prompt_messages, config=None):
    def decorator(func):
        def wrapper(*args, **kwargs):
            start = time.time()
            span = tracer.start_span(
                name="llm.completion",
                attributes={
                    "gen_ai.model": model_name,
                    "gen_ai.prompt": json.dumps(prompt_messages)[:2000],
                    "gen_ai.temperature": getattr(config, "temperature", None),
                    "gen_ai.top_p": getattr(config, "top_p", None),
                }
            )
            try:
                response = func(*args, **kwargs)
                span.set_attribute("gen_ai.usage.prompt_tokens", response.get("usage", {}).get("prompt_tokens", 0))
                span.set_attribute("gen_ai.usage.completion_tokens", response.get("usage", {}).get("completion_tokens", 0))
                span.set_attribute("gen_ai.completion", json.dumps(response.get("content", ""))[:2000])
                span.set_status(trace.StatusCode.OK)
                return response
            except Exception as e:
                span.set_attribute("gen_ai.error", str(e))
                span.set_status(trace.StatusCode.ERROR)
                raise
            finally:
                span.end()
        return wrapper
    return decorator

这段代码的作用是：把每一次大模型调用，包括模型名称、Prompt内容、生成结果、Token消耗、耗时和错误信息，全部记录到Trace里。有了这些数据，你才能回答"用户问了什么、系统答了什么、花了多少钱、慢在哪里"这几个灵魂问题。

RAG链路里的向量检索调用也可以类似埋点，核心要记录的是检索返回的TopK文档ID、得分、以及最终拼进上下文的内容长度。我之前就遇到过一次事故：检索环节返回了一个相似度很低但排序权重异常的文档，结果被拼进上下文之后，模型就顺着这个错误内容编了一篇"看起来合理"的回答。当时如果没有记录检索得分，这个问题根本没法定位。

3.3 第三步：把告警从"进程活着"升级到"业务语义正确"

最后一步是配置告警。传统告警只看CPU、内存、接口错误率，AI应用必须多两类维度的告警：

第一类是成本异常告警。 比如单日Token消耗突增50%以上，或者单次会话平均Token数超过设定阈值。这类告警非常容易配置，但价值极高，能在预算失控前给你一个缓冲期。我见过不止一个团队月底对账时才发现某个测试环境的大模型调用没关，白白烧了几万块。

第二类是效果劣化告警。 这个要复杂一些，不能简单地告警"延迟超过2000ms"，因为LLM生成本来就有波动，更合理的方式是设定基线并与历史数据对比。比如P95延迟比过去7天的同期值高出30%以上，或者RAG的召回答覆盖率（Recalled Docs Coverage）持续下降，就很可能是知识库更新引入了脏数据。

观测云这类平台的好处是，告警规则可以直接基于统一的观测数据体配置，不再需要一个指标一个指标地在不同工具里分别设置。它们的AIOps模块还能根据历史数据自动设定基线，比手工阈值智能不少。

告警配置完了，还有最后一个关键动作——建立告警关联分析的习惯。当某个"AI回答质量下降"的告警触发时，你要能一键跳转查看同一时间段的模型调用日志、检索得分、Prompt变更记录、以及底层基础设施指标。这个能力在排查"到底是模型升级导致效果变差，还是知识库更新导致检索质量下降"这类问题时会让你省下大量时间。

实操提示：落地这套体系时，最小可用范围建议只覆盖一条核心业务链路，比如"智能问答"这一个场景，跑通之后再复制到其他场景。别一上来就想把所有AI功能都圈进观测范围，否则光埋点审计就要折腾一个月。

4. 常见问题与排查技巧实录

最后这部分，我把过去在AI可观测实践中遇到过的典型问题整理一下，做成一个问题速查表。这些问题不一定容易遇到，但遇到了几乎个个能卡住团队几天。

这里面我重点说两个，因为它们比较反直觉。

第一个是"接口延迟变高但你查不出原因"的问题。 我遇到过一个案例，后端服务P99延迟从800ms涨到3000ms，传统APM曲线里各个中间件耗时都很正常，CPU和内存也没有明显波动。后来一查，发现是某次模型版本升级后，输出Token的默认上限被悄悄调高了，导致所有请求的生成阶段变长。如果我们的观测体系里没有把"输出Token数"和"生成阶段耗时"这两项数据记录在案，这个问题纯靠猜可能要猜一整天。

第二个是"回答质量下降但系统毫无报警"的问题。 这种问题最隐蔽，因为没有任何Error日志。我们当时的处理方式是给关键会话做一个"质量抽样"任务，每天自动从埋点数据里抽取200条问答记录，交由一套自动评估机制按打分规则给出质量分，低于阈值时触发预警。听起来有点重，但实际运行成本很低，因为不需要实时计算，每天跑一次离线任务就够了。

再补充几个避坑提醒：

• Prompt内容不要全量存储。 一方面涉及敏感信息，另一方面成本太高。我当时是默认截断前2000字，超过部分只记录长度和哈希值，排查需要详情时再手动取原始日志。
• Token参数一定要分输入和输出记录。 只记总Token数，你就无法判断上下文是不是在无限膨胀。
• 模型版本不要在代码里改。 建议把模型名称、温度等参数配置化，并在每次调用时作为标签记录下来，否则你很难追溯"这周回答风格变了"是哪次调整导致的。
• 不要迷信大模型API自带的可观测面板。 云厂商自带的调试台一般只覆盖单次调用的基本信息，和业务链路数据是割裂的，真正做关联分析还得靠统一可观测平台。

最后回到标题里的那场合作，我个人比较认同的方向是：可观测性不应该成为AI应用落地以后才补的课，而应该从一开始就伴随着链路设计一起做。观测云和百胜软件这类"平台方+行业ISV"的组合，正在把这件事从理论推向工程化。你在规划自己项目的AI可观测体系时，也可以按这个思路走一遍，先把关键链路画清楚、把核心指标埋点做起来、把告警和关联分析建立好。等真出了问题时你会发现，有数据可查和没数据可查，是两个完全不同的世界。