上个月在一家制造业客户的AI项目评审会上对方CTO问了我一句话“你们的大模型上线后我怎么知道它今天比昨天好”我当时愣了一下然后意识到这不是一个技术员在问细节这是一个企业决策者在问一个他真正关心的问题——AI的可观测性。从那次之后我陆续接触了十几个准备落地大模型项目的中大型企业几乎所有客户都会在需求评审、POC、招标答疑这些环节里用各种方式问同一个问题。我把这些问法整理了一下发现它们五花八门但本质上都指向同一件事AI系统在生产环境里到底能不能被看见、被度量、被追溯、被控制。今天这篇文章就把这五种典型问法、背后的真实诉求以及一套可以落地的AI可观测性方案完整讲清楚。1. 五种典型的问法背后全是同一个诉求1.1 “模型答错了你们怎么处理”——问的是效果评估这是最普遍的一种问法。客户往往会举一个例子如果用户问了一个问题模型回答了错误的内容或者自己编造了一段不存在的业务流程企业怎么发现怎么处置客户问这句话的时候表面上在问“错误处理机制”实际是在问模型输出的质量有没有一个可量化的标准有没有持续观察的手段。传统软件系统里代码出错会报异常日志会留下堆栈工程师能直接定位。但大模型不一样它不会报异常它可能非常自信地说出一个错误答案系统本身毫无感知。于是“模型答错了”这件事需要一套评估机制来兜底——要么靠规则要么靠另一个模型打分要么靠用户反馈——但无论哪种前提都是先把模型输出记录和可视化否则连“答错”都没法定义。1.2 “生产环境出了问题你们怎么排查”——问的是链路追踪第二种问法来自运维和工程团队“如果系统响应变慢了或者某个功能突然不可用了你们怎么排查是模型的问题、还是网络的问题、还是我们业务代码的问题”这个问题我特别能理解因为大模型应用的生命周期里一个请求至少要经过业务服务、提示词组装、模型调用、输出解析、下游接口好几个环节。任何一个环节出了问题表现都可能是“AI反应变慢”或者“回答异常”。如果没有一套完整的调用链追踪排查起来就像在没有日志的旧系统里找bug全靠猜。客户问的是排查能力本质上要的是一条从“用户提问”到“模型回复”的全链路追踪能力也就是AI可观测性的核心之一。1.3 “每一笔AI调用花了多少钱你们能说清吗”——问的是成本可观测这个问法最近越来越多。客户会问用户每次对话消耗了多少Token成本是多少如果有人恶意刷接口成本暴涨要怎么预警不同的提示词版本之间哪个更省钱以前企业用IT系统成本是服务器和人力看得见摸得着。但用大模型API是按Token付费的一个用户对话可能消耗几百Token也可能消耗几万Token。企业客户已经发现如果不监控Token消耗成本就像水龙头漏水一样月底对账才知道花了多少。这个问法背后是对成本维度的可观测性诉求。1.4 “如果出了合规问题你们能追溯吗”——问的是审计能力第四种问法来自法务或合规部门“AI给出的回答如果包含不合规的内容或者涉及用户隐私你们有没有日志可以追溯能不能证明这个回答是什么时候、由哪个模型、根据什么上下文生成的”这种问法在大模型落地的企业里越来越常见。毕竟AI生成的内容如果出了问题企业是要承担责任的没有审计数据就等于没有证据。客户要的是全量记录、可回放、可导出、可脱敏的审计能力。这同样是可观测性的一部分——只是它更偏向日志和追踪的留存维度。1.5 “你们升级模型版本之后我怎么知道效果变好了”——问的是版本对比第五种问法来自那些已经跑了一段时间POC的客户“你们从GPT-4换到更便宜的模型或者改了提示词之后怎么证明效果没有恶化有哪些指标可以对比”问到这一层说明客户已经有工程思维了。他们想要的是一套可对比的评估体系同一个测试集在模型A和模型B上分别跑一遍得出来的准确率、命中率、合规率是多少。没有这套体系模型的每次升级都是一次赌博。客户真正需要的是一个包含离线评测、在线指标、版本对比的完整观测体系。1.6 剥开来看本质就是“AI可观测性”这五种问法从效果、排查、成本、审计、版本五个角度切入最后都汇聚到同一个答案AI可观测性。它指的是对AI系统在运行时产生的各种信号进行采集、分析、展示和告警的能力。在传统软件领域可观测性已经很成熟有Metrics指标、Logging日志、Tracing追踪三大支柱。但到了AI大模型时代这三样还不够因为系统的行为和输出质量成了新的不确定因素。企业客户的必问本质上是因为他们从“这模型能不能跑通”进入了“这模型能不能管好”的阶段。能不能管好前提就是能不能看见。2. 为什么可观测性成了AI项目绕不开的坎2.1 传统软件和AI系统在“出错方式”上完全不同我在给一家金融机构做咨询时对方技术负责人说了一句很到位的话“以前系统出错我知道是代码的哪一行出了问题现在模型出错我连它是怎么想的都不知道。”这就是传统系统和大模型系统最本质的区别。传统软件是确定性的输入相同输出必然相同出错有异常堆栈有明确的分支逻辑。大模型是概率性的同样的输入温度参数不为零时每次输出都可能不同出错没有堆栈没有逻辑断点只有一段文本。这种差异导致传统运维手段直接失灵。你不能给模型打断点也不能在模型内部埋点观察中间变量。你能做的只能是在模型的输入输出和外部行为上做观测。这意味着可观测性不再是“辅助功能”而是理解AI系统的唯一窗口。2.2 “不可复现”让AI排障变得异常困难可观测性之所以对企业客户如此重要还有一个非常实际的痛点AI系统的错误往往不可复现。传统系统里一个bug的复现路径是固定的只要找到触发条件就能反复验证。但大模型应用里同一个提示词可能这次回答正常下次就开始胡编乱造。我问过不少做AI应用的工程师他们最崩溃的场景就是测试环境里一切正常用户反馈出错你拿同样的输入去跑结果完全正常你根本无法判断问题是出在随机性上还是出在上下文被污染上。没有可观测性这种问题是永远解不掉的。只有把每一次请求的完整上下文、模型参数、检索结果、输出都记录下来才能回放现场才能判断“是模型的概率性波动还是某个环节确实出了问题”。这也是为什么我说可观测性对AI系统不是锦上添花而是必需品。2.3 业务影响放大信任成本比技术成本更昂贵除了技术层面的原因企业客户对可观测性的执念还有一个心理层面的逻辑——他们对AI系统的信任是脆弱的。一个企业花了几十万甚至几百万做AI项目结果上线后业务部门问“AI说的这个数据准不准”技术部门答不上来问“这个AI刚才是不是乱说了”也没有证据。只要发生一次这样的情况决策层对AI的信心就会大打折扣。可观测性在某种意义上是企业的“信任基础设施”。没有一个透明的运行数据面板企业根本不敢让AI做核心业务决策。我见过一些项目模型能力本身没问题就是因为没有观测手段老板不信任、业务不买单最后项目拖着上不了线。所以AI可观测性已经从一个技术选项变成了企业客户评估供应商时的必问题。2.4 成本失控的恐惧推动“钱”的观测还有一个绕不开的现实大模型应用的成本结构是全新的让企业客户非常不安。过去自建系统一次请求的边际成本几乎为零现在用大模型API每次调用都在烧Token。客户经常跟我说他们想象不到一个看起来简单的对话功能一天跑下来居然要花几千块。而且大模型的成本波动比传统系统大得多——提示词写长了成本立刻上升某个用户疯狂追问单次成本翻几倍。企业要控制成本就必须要一个能按用户、按功能、按时间段拆分成本的可观测系统。这个需求之强烈已经让“成本监控”从可观测性里的一个分支变成了很多客户采购时的硬指标。3. AI可观测性到底要观测什么一套可落地的指标体系3.1 从三大支柱到“四层观测”传统可观测性讲的是Metrics、Logging、Tracing对应的是“系统健康状态”。但对AI系统来说仅仅观测系统健康还不够你还要观测“模型行为”和“业务结果”。我一般把AI可观测性拆成四层基础设施与服务层模型API的响应延迟、错误率、Token吞吐量GPU或API服务的负载、配额超限情况。应用逻辑层业务服务是否正常、提示词是否被正确组装、检索系统是否返回了正确的上下文、工具调用是否成功。模型行为层输出质量、指令遵循度、幻觉率、拒绝率、回答一致性等模型层面的指标。业务结果层用户满意度、任务完成率、内容的业务转化价值、负面反馈率等真实业务指标。四层里前两层和传统可观测性很像后两层才是AI特有的也是企业客户真正关心的。很多团队在做AI可观测性时只做了前两层结果就是系统没宕机但模型在胡说八道面板上却全是绿的。这不算真正的AI可观测性。3.2 模型质量指标该怎么定义企业客户总是问“怎么判断模型效果好不好”所以我们得先有一组能被量化的质量指标。这里有一个很关键的点不能照搬学术界的准确率、F1这些指标因为大模型应用里很多任务没有标准答案或者是开放生成的。我自己的实践是把质量指标分成三类来建规则可判定指标比如输出是否为空、是否包含敏感词、是否超出长度限制、结构是否合法JSON可解析之类。这类指标可以直接通过代码判定成本低适合实时监控。模型打分指标比如回答的“相关性”“友好度”“安全性”可以调用一个小模型judge model来打分。这类指标质量更高但有一定成本和延迟适合在异步队列里跑或者按一定比例抽样。人工反馈指标用户点击“有帮助/没帮助”或者客服人工标注“正确/错误”。这类指标是企业AI落地时最有价值的数据源也是最容易被忽略的。在设置质量指标时我建议客户不要一开始就追求大而全。先选三到五个和业务强相关的指标跑通采集链路再逐步增加。如果一开始就定义二十个指标大概率是采集不全维护成本还高。3.3 成本与性能指标怎么采集成本和性能指标是企业客户问得最具体的一类因为它可以直接对应到账单。成本指标的采集相对简单。如果你用的是API模型每次调用都能拿到usage数据里面有prompt tokens、completion tokens、total tokens。有了Token数再乘上单价就能算单次成本。要注意的是不同模型的单价不一样有些还会按输入输出分开计价所以成本计算要按模型维度做配置。除了单次成本我还会建议客户做三张成本视图按功能维度客服、写作助手、知识问答各花了多少钱。按用户维度哪些用户消耗的Token异常高。按时间趋势按小时、按天看成本变化及时发现异常波动。性能指标方面重点看首Token延迟和完整响应延迟。大模型流式输出后用户等待的第一Token时间很影响体验。建议把延迟的P50、P95、P99分开统计因为平均值会掩盖极端情况。3.4 业务反馈闭环怎么设计最后这一层是企业客户从“看技术指标”升级到“看业务指标”的关键环节也是最难的一层。业务反馈闭环的核心是把每一次用户反馈和触发反馈的那次AI调用关联起来。具体做法是在请求链路上生成一个全局唯一的请求ID不管是前端的点赞点踩、后端的对话记录还是离线的人工标注都要带上这个请求ID。这样当你看到一个模型输出不达标时可以沿线追回去看上下文、看当时的检索结果、看模型参数找到问题根源。为了帮客户说清楚这件事我经常用一个比喻请求ID就像快递单号。你收到一个坏包裹模型输出质量差有单号才能查到它从哪里发货提示词、在哪一站中转检索上下文、是哪家物流送的模型版本。没有单号就只能认栽。业务反馈闭环本质上就是给每一次AI交互拴上快递单号。4. 技术落地给AI应用插上监控探针的实操方案4.1 基于OpenTelemetry的LLM调用链路怎么搭前面讲了很多理论这一节上实操。目前行业里最务实、最不容易被厂商锁定的做法是基于OpenTelemetry简称OTel来构建AI可观测性的底座。OTel的优势在于它已经把Metrics、Logs、Traces的接口标准统一了而且有庞大的生态。你不需要自己设计一套埋点协议直接用OTel的Span概念来记录一次AI调用。以Python为例接入一个LLM调用的链路追踪大致是这样的from opentelemetry import trace from opentelemetry.trace import Status, StatusCode tracer trace.get_tracer(llm-app) def call_llm(prompt, model, temperature): with tracer.start_as_current_span(llm.call) as span: # 记录请求关键信息 span.set_attribute(gen_ai.prompt, prompt) span.set_attribute(gen_ai.model, model) span.set_attribute(gen_ai.temperature, temperature) response model_client.chat.completions.create( modelmodel, temperaturetemperature, messages[{role: user, content: prompt}] ) # 记录响应与用量 span.set_attribute(gen_ai.completion, response.choices[0].message.content) span.set_attribute(gen_ai.usage.prompt_tokens, response.usage.prompt_tokens) span.set_attribute(gen_ai.usage.completion_tokens, response.usage.completion_tokens) span.set_attribute(gen_ai.usage.total_tokens, response.usage.total_tokens) span.end() return response这里每个span就是一个可追踪的步骤。在上面的例子里我记录了输入、模型参数、输出、Token用量这些字段已经足够支撑成本计算和问题复盘了。实际落地时我一般会在链路里再加几个span一个是“prompt.build”记录提示词模板版本和最终拼装结果一个是“retriever.query”记录检索出的上下文块一个是“external.api”记录调度工具调用。这样整条链路从头到尾都是完整的。4.2 关键埋点哪些数据值得采集很多团队做采集时容易走极端要么什么都记把成本搞得极高要么只记个日志标题关键信息全丢了。根据我的经验下面这些埋点是性价比最高的请求元数据请求ID、会话ID、用户ID注意脱敏、功能模块名称。提示词信息提示词模板ID、提示词版本号、模型名称、推理参数temperature、top_p。运行时数据请求耗时、首Token延迟、Token用量、重试次数、报错类型。上下文数据检索到的文档ID、文档块内容这一步要特别小心隐私能脱敏就脱敏。输出数据模型完整输出、是否被业务方的红线规则拦截、是否触发安全策略。反馈数据用户评价结果好/差、人工标注原因、后续修正动作。这里有个重要提醒不要为了可观测性把用户隐私和业务敏感数据全量落到日志里。我通常建议在业务日志中记录文档ID而不是文档全文在展示页面脱敏处理给真实输入输出做数据分权管理。4.3 评估与告警系统怎么建埋点做完数据已经在流动了接下来要解决的是“数据怎么用”的问题。评估方面我推荐两条腿走路离线评测和在线监控。离线评测是发布前做的准备一批Golden Set带着标准答案的测试集在模型或提示词变更时跑一遍回归对比变更前后的核心指标。在线监控则是发布后做的对生产流量做实时评分或抽样评分看看线上效果是否有波动。告警的触发规则我给客户定的初始策略基本是这样告警对象建议阈值告警频率响应P95延迟超过基线1.5倍5分钟内持续触发Token成本环比上涨50%1小时内持续触发错误率超过1%或5分钟内上升2倍立即触发负面反馈率超过5%或较昨日翻倍30分钟内持续触发阈值不要一开始设太严格否则告警群一天响几十次大家最后都把告警静音了。最好先静默观察一周摸出业务基线的正常范围再按基线的倍数来设定告警阈值。4.4 一个最小可用的AI可观测性架构如果你不想一上来就用商业产品想自己搭一套最小方案我可以给一个实际跑通的参考架构采集端在业务服务里用OpenTelemetry SDK埋点把Span数据通过OTLP协议发给Collector。汇聚端OpenTelemetry Collector承担数据接收、过滤、脱敏和转发。存储端指标数据用Prometheus或VictoriaMetrics链路和日志数据用ClickHouse或Elasticsearch。如果你的量不大单机ClickHouse就能扛住每天几十万条Span记录。展示端Grafana做指标面板Jaeger或Grafana Tempo做链路查询。评估端写一个独立的评估服务异步消费采集到的模型调用记录调用judge模型打分然后把分数写回存储端。这套架构的好处是完全标准化以后想换任何商业产品或者自研平台数据层面都不用推翻重来。我见过不少企业团队一开始图省事直接用商业APM结果自定义AI指标支持不全最后又迁到OTel方案这个弯路能不走就不走。5. 常见问题与排查技巧实录5.1 模型“答非所问”是提示词问题还是模型问题有一次客户报障说他们的智能客服经常回答牛头不对马嘴。我让团队把出问题的那几次请求回放调出来顺着Traces一看原因居然是检索系统返回了大量不相关的文档把模型输入塞爆了真正有用的信息反而被截断了。这个问题如果不做链路追踪光靠猜可能要在提示词上折腾几个星期。所以排查这类问题的标准动作是先看输入、再看检索、最后才怀疑模型。具体来说先回放Span里的prompt和上下文确认模型收到的信息是否完整再看temperature和top_p等参数是不是被某个上游设置得过于随机最后拿同样输入直接跑一遍模型排除概率性波动。大多数“答非所问”都藏在前两步里。5.2 幻觉频发但人工看不出来怎么办幻觉是AI应用里最让人头疼的问题因为人眼很难从一段流利的回答中判断哪里是编的。我的建议是不要试图用“事后去检查每一句话”来解决幻觉而是从采集端入手把模型回答所依据的上下文和回答绑定在一起。这样当用户反馈某句话有问题时你就能立刻看到这句话引用了哪份文档引用是否成立。如果没有找到任何引用来源就该判定为幻觉。实操上我一般会在业务层强制模型在回答中带引用标记同时在评估服务里做引用一致性校验。这套机制并不复杂但对客户来说极其有说服力因为它能用数据回答“AI为什么会这么说”。5.3 成本异常上涨怎么快速定位成本类问题在告警系统上线后其实很好定位。有一次客户反馈某天成本飙升我让他们先看按功能维度的成本图表发现80%的增量来自“文档分析”功能。再追踪该功能的请求量发现当天有大量高频率重复请求。最后追溯回到代码原来业务方写了个定时任务把几百个文档轮流让模型做摘要完全绕过了缓存导致Token消耗暴涨。这个案例里链路追踪的作用是把“账单变贵”和“具体哪个请求在烧钱”建起因果关联。所以成本排查的基本思路就是按功能拆、按用户拆、按请求拆一路往下钻一定会在某个维度看到异常点。5.4 客户要SLA和审计该怎么准备审计需求现在几乎已经变成AI项目的标配了。客户要的东西往往很具体他们希望留存所有的用户输入、模型输出、模型版本、提示词版本、推理参数、时间戳和调用人。准备这套东西重点不在存储而在规范和隐私。我的做法是对日志做分级留存原始内容只允许运维和合规岗位访问数据采集时做敏感字段动态脱敏导出审计报告时提供按会话粒度的数据包里面包含一次对话的完整轨迹。这套数据准备好之后客户再问合规问题你就可以直接展示系统能力而不是口头承诺。6. 最后的一点个人体会做了这么多AI可观测性项目我最大的感受是可观测性不是上线之后补的一个监控面板而是应该在AI应用设计阶段就同步规划的一种工程能力。它决定了企业能不能回答“模型今天比昨天好还是坏”这个问题决定了AI出了故障是半小时定位还是三周都排查不清楚也决定了业务部门敢不敢把核心流程交给AI。与其在项目后期硬加观测体系不如在第一个请求跑通之前就把埋点、链路、指标方案一并设计好。如果让我给一个最小起步建议我会说先不要管平台选型先把每一条线上请求的关键信息打点记录下来存起来能按请求ID回放出来。能做到这一步AI可观测性的一半价值就已经拿到了剩下的一半是在不断使用数据的迭代过程中慢慢长出来的。