AI服务监控要看什么：Token、延迟、错误、成本和满意度

[admin]

写作日期：2026-05-22

AI 服务上线后，最危险的状态不是报错，而是“看起来能用”。页面能返回答案，接口有 200，用户偶尔夸一句好用，团队就以为系统稳定了。过一段时间才发现，Token 成本悄悄翻倍，首字延迟越来越慢，某个模型供应商的错误被重试掩盖，用户满意度下降但没人收到告警，客服只知道“最近 AI 有点不准”，工程团队却只看到 CPU 和内存都正常。

传统在线服务监控看请求量、延迟、错误率、资源占用，AI 服务当然也要看这些，但远远不够。大模型应用多了一层生成过程：输入多少 Token，输出多少 Token，检索了哪些资料，调用了几次工具，是否发生截断，是否走了降级模型，答案是否被用户采纳，模型是否胡说，成本是否超过业务价值。这些信号如果没有被记录，系统就像黑箱。黑箱可以演示，不能长期运营。

AI 服务监控要从“机器是否活着”升级到“用户是否得到可靠结果”。Token、延迟、错误、成本和满意度是最基础的五类指标。Token 告诉我们模型工作量和上下文使用情况；延迟告诉我们用户等待体验和链路瓶颈；错误告诉我们系统在哪些环节失败；成本告诉我们每次价值交付花了多少钱；满意度告诉我们用户是否认为结果有用。这五类指标要放在同一张运营图里看，不能各看各的。

社区里经常有人说“先上线，后面再加 observability”。这个想法在 AI 应用里特别容易吃亏。因为 AI 的质量问题不一定表现为异常日志。模型答非所问、引用错资料、把上下文吃满、重试三次才成功、用昂贵模型处理简单请求、用户复制答案后又手动修改，这些都可能被普通监控忽略。等到成本账单和用户投诉出现，问题已经积累很久。

一、别只看 200 状态码

AI 服务的一个常见误区，是把 HTTP 200 当成成功。接口返回 200，只说明网关和应用层完成了响应，不说明答案正确、完整、合规、便宜、及时、可用。一个 RAG 问答接口可能顺利返回 200，但检索到的文档是过期版本；一个客服机器人可能返回完整文本，但没有解决用户问题；一个代码助手可能生成一大段代码，但无法运行；一个教育导师可能给出答案，但没有帮助学生理解。

传统 SRE 里的黄金信号包括延迟、流量、错误和饱和度。这套思路仍然重要：请求是否变慢，流量是否异常，错误是否增加，资源是否接近极限。但 AI 服务要在黄金信号旁边加上模型信号和业务信号。模型信号包括 Token、上下文长度、模型名、温度、工具调用次数、检索命中文档、输出截断、拒答、重试、供应商返回码。业务信号包括用户是否继续追问、是否点赞、是否复制、是否采纳、是否转人工、是否完成任务。

只看服务器指标，会错过模型层问题。比如某天延迟升高，不一定是 CPU 忙，可能是上下文从 4k 涨到 24k；错误率不高，不代表质量稳定，可能是失败被兜底文案掩盖；成本升高，不一定是流量增加，可能是提示词里塞了过多历史消息；满意度下降，不一定是模型变差，可能是知识库过期或某个工具 API 返回空结果。

AI 服务监控应该按一次完整任务来观察，而不只是按单个接口请求。用户输入问题，系统检索资料，调用模型，模型决定调用工具，工具返回结果，模型生成最终答案，安全策略过滤，前端流式展示，用户点赞或继续追问。这个链路每一步都有耗时、输入、输出、错误和质量信号。没有 trace，团队只能凭感觉猜。

二、Token 是第一类经营指标

Token 不是模型 API 的内部小字，而是 AI 服务的基本计量单位。输入 Token 代表系统给模型看的上下文，输出 Token 代表模型生成的内容，缓存 Token、推理 Token、工具结果 Token、检索片段 Token 都可能影响成本和延迟。一个 AI 应用如果不记录 Token，就等于 SaaS 不记录调用量，电商不记录订单金额。

Token 监控至少要分输入和输出。输入 Token 过高，常见原因是历史对话没有压缩、系统提示词膨胀、检索片段太多、文档切片过长、工具返回原始大 JSON、把用户看不到的调试信息塞给模型。输出 Token 过高，常见原因是没有限制答案长度、模型重复解释、提示词鼓励长篇输出、没有按场景设置格式、失败重试多次生成。输入和输出问题的治理手段不同，混在一起看没有意义。

还要按模型、租户、功能、用户角色和任务类型切分 Token。同样是 100 万 Token，用在付费客户的复杂报告上可能合理，用在游客的一句话闲聊上就很浪费；用在高价值合同审阅上可能合理，用在按钮文案改写上就不一定。总 Token 上升不一定是坏事，关键要看它是否带来业务价值。

上下文利用率也值得看。一个请求如果发送了 60k Token，但模型真正引用的资料只有 2 段，说明检索和上下文拼装可能过度。RAG 系统尤其容易犯这个错误：为了“保险”，把太多文档片段塞进 prompt，结果成本和延迟上升，模型还更容易被无关信息干扰。监控应记录检索候选数量、最终注入数量、引用命中数量和答案引用覆盖率。

Token 还关系到截断和遗忘。上下文超过模型窗口，系统可能截掉早期对话、工具结果或关键约束。用户看到的是回答突然不一致，工程日志里可能没有异常。每次调用都应记录上下文窗口、实际输入 Token、剩余可用 Token、输出上限、是否发生截断。对长对话、长文档和 Agent 任务，这些指标尤其重要。

一个实用看板可以包含：每日总 Token、每千次请求 Token、单次请求 P50/P95 输入 Token、P50/P95 输出 Token、按功能 Token 占比、按模型 Token 占比、超长上下文请求数、截断次数、无引用高 Token 请求、工具结果 Token 占比。看到这些指标，团队才能知道成本和质量问题从哪里来。

三、延迟要拆成首字、总时长和各阶段耗时

AI 服务延迟不能只看后端接口耗时。用户真实感受通常由两件事决定：多久看到第一个有意义输出，以及多久拿到完整结果。流式输出让用户可以更早看到内容，但如果首字延迟很高，用户仍然会觉得卡；如果总时长过长，用户会在长答案中失去耐心。

首字延迟通常包括排队、鉴权、上下文构建、检索、模型首 token 生成、安全检查和网络传输。总时长还包括完整生成、工具调用、多轮推理、后处理和前端渲染。一个看板只显示平均响应时间，很难定位问题。必须拆阶段：入口网关耗时、业务服务耗时、数据库查询耗时、向量检索耗时、重排耗时、模型排队耗时、模型生成耗时、工具调用耗时、安全审核耗时、流式传输耗时。

P50、P95、P99 比平均值更重要。AI 服务延迟分布经常长尾明显。多数请求可能 3 秒完成，少数请求因为长上下文、供应商排队、工具超时、重试或复杂 Agent 循环拖到 60 秒。平均值会掩盖这些体验事故。用户不会因为平均很快而原谅自己那次等了半分钟。

延迟还要按任务类型看。短问答、长文总结、代码生成、图像理解、知识库检索、Agent 多步任务，不应放进同一个延迟目标。短问答首字 1 秒和 5 秒差别很大；长报告生成 30 秒可能可接受；后台批处理可以更慢但要可追踪。服务等级目标要按场景设置。

流式输出也需要监控质量。流式不是把内容一点点吐出来就够。要看首字时间、token 输出速率、流中断次数、客户端取消率、用户在第几秒离开、流式内容是否被安全策略后置拦截。若安全审核放在最终输出后，前面已经流给用户的内容可能无法撤回；若所有内容都等审核后再发，首字延迟会变高。不同场景要做取舍。

延迟优化不能只靠换更快模型。很多慢请求来自上下文过大、检索慢、工具 API 超时、串行调用过多、没有缓存、重试策略粗糙。先拆链路，再做优化。否则团队可能花钱上更强模型，却继续把 30 段无关资料塞进去。

四、错误不是一个错误率能概括

AI 服务错误要分层看。第一层是基础设施错误：服务不可用、连接超时、DNS、TLS、网关 502、容器重启、磁盘满、队列堆积。第二层是供应商错误：模型 API 超时、限流、配额不足、内容过滤、上下文超限、模型不存在、认证失败。第三层是应用错误：检索为空、工具调用失败、JSON 解析失败、函数参数不合法、状态机走错、流式连接中断。第四层是质量错误：答非所问、幻觉、引用错误、格式不合规、拒答不当、泄露不该展示的信息。

不同错误的处理策略不同。供应商限流可以切换模型或排队；上下文超限要压缩输入；工具超时要降级展示；检索为空要提示补充资料；JSON 解析失败可以要求模型修复结构；质量错误通常需要评估、反馈和数据改进。把这些都统计成一个 1% 错误率，只会让问题变模糊。

错误监控要记录错误发生在哪个阶段。一次请求可能模型成功了，但后处理解析失败；也可能检索失败后系统直接让模型泛答；也可能模型拒答，但业务把拒答当作成功返回。trace 里应有明确 span：retrieval、rerank、prompt_build、model_call、tool_call、guardrail、postprocess、stream、feedback。每个 span 有状态、耗时、输入规模、输出摘要和错误类型。

错误还要区分可见和不可见。可见错误是用户看到失败提示、空白页、连接中断。不可见错误是系统自动重试或降级后返回了答案。不可见错误也必须统计，因为它会增加成本、延迟和质量风险。比如同一个请求第一次调用主模型超时，第二次调用便宜模型成功，用户看到答案，但服务质量已经变化；如果不记录，团队会误以为主模型稳定。

重试策略本身也要监控。AI API 错误经常带有瞬时性，重试有必要，但盲目重试会放大流量和成本。应记录重试次数、重试原因、重试模型、重试后是否成功、重试增加的延迟和 Token。对幂等任务可以重试，对会触发外部动作的工具调用必须谨慎，避免重复下单、重复发信、重复提交表单。

质量错误最难监控，也最需要运营化。可以通过用户反馈、人工抽检、自动评测、引用校验、格式校验、事实检查、对话后续行为来发现。比如用户连续三次追问“不是这个意思”，可能说明理解失败；用户点击“转人工”，可能说明任务未完成；答案引用了不存在的文档段落，是明确质量错误；客服人工修改 AI 建议后发送，也说明原答案不够好。

五、成本要算到任务和客户

AI 成本不能只看供应商账单。账单告诉你总共花了多少钱，但不会告诉你哪类任务亏、哪个客户异常、哪个功能浪费、哪次版本发布导致成本上升。生产级 AI 服务要把成本分摊到请求、会话、用户、租户、功能、模型和业务结果。

成本至少包括模型输入输出 Token、嵌入、重排、向量数据库、缓存、工具 API、图片或音频模型、日志存储、人工审核、失败重试和基础设施。很多团队只算模型生成费用，忽略 embedding、reranker、长日志、评测任务和失败重跑。AI 应用规模上来后，这些都会变成真实支出。

单次请求成本很有用，但不够。更重要的是每完成一次任务的成本。用户问一次问题没有解决，连续追问五次，表面上是五个请求，业务上是一次失败任务；用户一次生成报告花了很多 Token，但直接交付成功，可能是高价值任务。成本指标要和任务完成率、满意度、转化、留存结合。

成本看板要能发现异常。某租户 Token 突然暴涨，可能是业务增长，也可能是脚本滥用、循环调用、提示词错误、恶意请求或知识库文档异常。某功能单位成本上升，可能是模型切换、上下文增加、重试变多或输出过长。某模型成本占比上升，可能是路由策略失效。没有成本告警，团队只能等月末账单。

成本治理有几种常见手段。第一，模型路由：简单问题用低成本模型，复杂任务用强模型，必要时升级。第二，上下文压缩：控制历史消息、检索片段和工具返回。第三，缓存：对重复问题、固定资料摘要、常用检索结果和系统提示做缓存。第四，输出约束：按场景限制长度和格式。第五，预算控制：按租户、功能和用户设置软硬额度。第六，离线批处理：把不需要实时的评测和总结移到低峰或便宜路径。

成本不能只追求最低。过度降成本会牺牲质量和体验。便宜模型答错导致用户转人工，真实成本可能更高；强行缩短输出导致用户反复追问，总 Token 反而增加。成本优化要看单位价值，而不是单次调用价格。

六、满意度是结果指标，不是装饰按钮

满意度经常被做成答案下方的点赞和点踩，然后没人看。真正有用的满意度监控，要把用户反馈和具体请求、任务、模型、知识库版本、提示词版本、错误类型、后续行为关联起来。否则点踩只是情绪垃圾桶，不能指导改进。

显式反馈包括点赞、点踩、评分、标签、评论、投诉、转人工原因。显式反馈的好处是明确，坏处是样本少且偏向极端用户。隐式反馈包括是否复制答案、是否点击引用、是否继续追问、是否改写输入、是否重新生成、是否放弃会话、是否完成表单、是否转人工、人工是否采纳 AI 建议。这些信号更丰富，但解释要谨慎。

满意度要按任务看。客服机器人里，用户点踩可能是答案错，也可能是政策本身让用户不满意；教育应用里，学生不喜欢严格反馈，不代表反馈无效；代码助手里，用户复制代码后又大量修改，可能说明有用但不完整。满意度不能脱离场景直接比较。

一个可执行的满意度指标体系可以包含：答案点赞率、点踩率、带原因点踩率、首次解决率、转人工率、重复提问率、用户追问深度、答案复制率、引用点击率、任务完成率、人工采纳率、人工修改比例、投诉率。不同业务选择不同核心指标。社区问答可能重视采纳和引用点击，客服重视首次解决和转人工，内部知识库重视搜索后是否继续求助，写作工具重视编辑修改比例。

满意度要进入闭环。点踩原因如果是“没有回答问题”，要回到意图识别和检索；如果是“信息过期”，要回到知识库更新；如果是“回答太长”，要回到输出策略；如果是“语气不合适”，要回到风格约束；如果是“无法执行”，要回到工具能力。每类反馈都应有负责人和处理路径。

不要让满意度污染用户体验。每次回答都弹长问卷，会降低使用意愿。更好的做法是轻量收集，必要时抽样追问。点踩后给几个清晰原因选项：没有回答问题、信息不准确、缺少来源、太复杂、太短、不能执行、语气不合适。用户愿意补充时，再开放文本说明。

七、RAG 服务要看检索指标

很多 AI 服务问题表面上是模型问题，根因是检索。RAG 系统里，模型只能根据拿到的上下文回答；检索召回错了、资料过期、切片断裂、重排失效，模型再强也会胡乱补。监控 RAG，不能只看最终答案。

检索指标至少包括检索请求量、检索延迟、候选文档数、最终注入片段数、相似度分布、重排前后变化、空结果率、低置信结果率、引用覆盖率、引用点击率、答案中未引用声明比例、过期文档命中率、无权限文档过滤次数。对企业知识库，还要按部门、资料类型和更新时间切分。

空结果不一定是坏事。用户问了知识库没有的内容，系统应诚实说明缺资料，而不是让模型编。真正危险的是“低质量结果被当成高质量上下文”。相似度很低的片段被塞给模型，答案看起来有引用但不支撑结论，这比直接说没有资料更糟。

知识库更新也要监控。新增文档是否成功切片，embedding 是否完成，索引是否刷新，旧文档是否下线，权限是否同步，重复文档是否增加，热门问题是否命中最新版本。很多 RAG 事故来自资料更新流程，而不是模型本身。

引用质量要单独看。答案给了链接，不代表引用正确。系统可以抽检答案句子是否被引用片段支持，引用片段是否来自允许资料，引用是否过期，用户是否点击后继续追问。引用是信任机制，不能当装饰。

八、Agent 服务要看步骤和工具

Agent 型 AI 服务比普通问答更需要监控。因为它不是一次模型调用，而是计划、调用工具、观察结果、再决定下一步。用户只看到最终结果，系统内部可能已经走了十几步。没有步骤级 trace，问题很难复盘。

Agent 监控要记录每一步的目标、工具、参数、结果、耗时、Token、错误和决策原因。工具调用尤其要细：调用了哪个外部系统，传了哪些关键参数，是否写入数据，是否有副作用，是否重试，是否被人工确认。对高风险工具，例如发邮件、建订单、改权限、转账、删除数据，必须记录确认链路。

步骤数是重要指标。步骤过少，可能说明 Agent 没有认真完成任务；步骤过多，可能说明它迷路、循环、工具不可用或目标不清。可以设置最大步骤、循环检测、重复工具调用告警和阶段超时。用户一句简单需求如果触发 20 次模型调用，需要查原因。

工具成功率也要看。一个 Agent 经常失败，不一定是模型推理差，可能是工具 schema 不清、错误提示不可读、权限不足、外部 API 不稳定、返回数据太大。工具错误要反馈给提示词、工具设计和业务系统，而不是全怪模型。

Agent 还要看任务完成率。最终输出了文本，不代表任务完成。用户要求“帮我生成报价单并保存”，系统必须确认文件是否生成、字段是否完整、是否保存到正确位置。对 Agent 来说，最终答案应绑定可验证产物或状态变化。

九、监控数据怎么落地

落地 AI 监控，第一步是定义统一事件模型。一次用户请求应该有 request_id，一次多轮任务应该有 session_id 或 task_id，所有模型调用、检索、工具、评估和反馈都挂在同一条链路上。没有统一 ID，日志散落在前端、后端、网关、模型代理、向量库和供应商控制台里，排查会非常痛苦。

第二步是做 tracing。OpenTelemetry 的生成式 AI 语义约定已经把模型系统、请求模型、响应模型、token 用量、工具调用等字段纳入观测思路。团队可以用 OpenTelemetry 打基础，也可以使用 Langfuse、Phoenix、LangSmith 等 LLM observability 工具。工具不是重点，重点是把请求链路打通。

第三步是定义日志粒度。不要把完整敏感输入输出无脑写进日志，也不要只写“调用成功”。比较稳的做法是保存必要元数据、脱敏文本摘要、哈希、文档 ID、模型配置、Token、耗时、错误类型、评估结果和用户反馈。对需要排查质量的样本，可以按权限进入受控审计池。

第四步是建立指标和告警。指标用于长期看趋势，告警用于及时发现事故。告警不要太多，否则没人理。起步可以设置：错误率异常、P95 首字延迟异常、P95 总时长异常、单位请求 Token 异常、日成本异常、供应商限流异常、检索空结果率异常、点踩率异常、转人工率异常。每个告警要有处理负责人和排查手册。

第五步是做样本回放。AI 问题经常需要复现上下文。系统应能在权限允许下回放一次请求：用户输入、检索结果、prompt 版本、模型参数、工具结果、输出、评估、反馈。没有回放，团队只能靠截图和猜测修复问题。

第六步是把监控接入发布流程。提示词改动、模型升级、知识库重建、路由策略调整，都应观察关键指标变化。发布前用评测集回归，发布后看线上指标，异常时能回滚。AI 应用的变更不只是代码，prompt、资料、模型和路由都是生产变更。

十、不要把监控界面做成工程垃圾场

AI 服务监控给工程师看，也给产品、运营、客服、内容、教师或业务负责人看。不同角色需要不同界面。工程师需要 trace、错误堆栈、模型参数、耗时分解；产品需要任务完成率、满意度、成本趋势；运营需要高频问题、低满意会话、知识缺口；客服主管需要转人工原因、AI 建议采纳率；管理者需要价值和风险。

一个好的监控界面应从问题出发，而不是从字段出发。比如“为什么今天成本涨了？”界面应能拆到流量、Token、模型、重试、功能、租户。“为什么用户说回答不准？”界面应能拆到点踩样本、知识库版本、检索结果、引用覆盖和人工审核。“为什么变慢？”界面应能拆到首字、检索、模型排队、工具调用和重试。

界面文案要面向使用者。不要把内部字段直接甩给业务用户。业务看板可以写“高成本会话”“未解决问题”“知识库缺口”“需要复核的回答”，工程详情里再展示 input_tokens、ttft_ms、provider_error_code。同一份数据可以有不同表达层。

还要避免信息重复。一个请求详情页不需要在十个位置显示模型名和用户 ID。更好的结构是顶部显示任务结果，中间显示链路时间线，右侧显示成本和 Token，下方显示反馈和评估。监控界面本身也要有产品标准，否则团队很快不愿使用。

十一、安全、隐私和合规指标

AI 服务监控不能只服务性能和成本，也要服务安全、隐私和合规。模型应用会处理用户输入、企业资料、学生记录、客服工单、合同文本、代码片段和个人信息。若监控系统把这些内容完整保存、随意展示、长期留存，本身就会变成高风险数据仓库。很多团队以为“为了排查问题多记一点没关系”，这在生产环境里很危险。

安全指标可以分三类。第一类是输入风险：敏感信息出现次数、疑似密钥提交、身份证或手机号提交、提示注入命中、越权访问请求、恶意批量调用。第二类是输出风险：不当内容拦截、隐私泄露拦截、危险建议拦截、版权风险、拒答比例、误拒比例。第三类是工具风险：高权限工具调用次数、人工确认次数、被拒绝的外部动作、跨域数据发送、异常下载和上传。

隐私指标要看数据生命周期。日志保存了什么，保存多久，谁访问过，是否脱敏，是否能按用户或租户删除，是否进入训练集，是否被导出给第三方。监控平台应记录审计日志：谁查看了原始对话，为什么查看，查看了哪些样本，是否导出。没有审计，排查权限很容易变成随意浏览用户数据。

合规还包括地区和行业差异。教育、医疗、金融、政务、企业内部知识库，对数据保留、访问控制和解释责任要求不同。一个面向公开社区的 AI 问答，可以保存匿名问题做质量改进；一个面向学校的学习诊断，就要更谨慎处理学生数据；一个面向企业合同审阅的系统，可能需要严格控制模型供应商和日志留存。监控字段也要按场景配置。

安全监控不要只看拦截数量。拦截过多可能说明用户场景不清，也可能说明规则过严；拦截过少可能是系统安全，也可能是检测失效。更有价值的是抽样复核：被拦截的内容是否确实有风险，未拦截的低满意或投诉样本是否含风险，用户是否因为误拒而绕路表达。AI 安全质量和普通质量一样，需要持续标注和校准。

提示注入也应作为可观测事件。RAG 文档、网页内容、用户上传文件、工具返回结果中都可能包含“忽略之前指令”“泄露系统提示”“调用某工具”等恶意文本。系统不应只在模型提示词里写一句防护，而要记录来源、命中规则、是否隔离、是否影响最终输出。长期看这些数据，可以反向发现被污染的资料源。

十二、容量、限流和供应商稳定性

AI 服务还要看容量。传统服务容量主要受 CPU、内存、数据库连接、队列长度影响，AI 服务还受模型供应商配额、每分钟请求数、每分钟 Token 数、并发流式连接、上下文长度、GPU 队列和工具 API 限制影响。容量不足时，表现不一定是服务挂掉，可能是排队变长、流式断开、限流增多或降级频繁。

供应商稳定性要单独监控。多个模型供应商的错误码、限流规则、超时行为、内容过滤策略和计费方式不同。一个供应商偶发慢，可能拖慢整个 Agent；一个供应商改变模型版本，可能影响输出风格；一个供应商配额耗尽，可能触发大量降级。监控应按 provider、region、model、endpoint 统计成功率、P95 延迟、限流次数、超时次数、内容过滤次数和成本。

模型网关在这里很重要。所有模型调用如果散落在各业务服务里，团队很难统一记录和治理。通过模型网关集中处理认证、路由、限流、重试、缓存、日志、成本和降级，可以让监控数据更完整。网关不是为了增加架构复杂度，而是为了让 AI 调用成为可运营资源。

限流策略要区分用户公平和系统保护。免费用户、付费用户、内部员工、批处理任务、实时对话，不能使用同一限流阈值。高价值实时请求应优先保障，后台评测可以排队，异常脚本应快速限制。限流指标要记录被限制对象、原因、等待时间和用户可见结果。否则业务只会听到“系统偶尔慢”，不知道是配额策略还是容量问题。

容量规划也要看高峰和长尾。大促、开学季、财报发布、产品上线、新闻事件、批量导入知识库，都可能让 AI 调用突然升高。Token 容量比请求容量更难预测，因为一次请求可能从几百 Token 变成几万 Token。团队应设置容量预警：每分钟 Token 接近供应商上限、流式连接接近上限、队列等待超过阈值、降级比例升高、缓存命中下降。

自部署模型还要看 GPU 指标，但不能只看 GPU 利用率。要看请求队列、批处理大小、KV cache 使用、显存碎片、上下文长度分布、prefill 耗时、decode 速率、模型加载时间、OOM 次数、请求取消率。GPU 利用率高不一定坏，关键是用户侧延迟和吞吐是否达标。GPU 利用率低也不一定好，可能是调度低效或负载不均。

十三、评测指标和线上监控怎样配合

离线评测和线上监控经常被分开做。评测团队关心模型在测试集上的分数，运维团队关心服务是否稳定，产品团队关心用户是否满意。AI 服务真正需要的是把三者串起来。离线评测告诉我们变更前的预期风险，线上监控告诉我们真实用户环境里的表现，人工复盘告诉我们哪些指标解释错了。

每次提示词、模型、检索策略、工具 schema、知识库版本变化，都应先跑固定评测集。评测集要覆盖常见问题、边界问题、高价值问题、已知事故样本和低满意样本。指标可以包括准确性、引用支持、格式遵循、拒答正确性、工具参数正确性、输出长度和安全性。评测通过不代表一定能上线，但评测失败通常不应强行上线。

上线后要看相同维度的线上指标。比如离线评测显示新提示词能减少幻觉，上线后应观察引用错误、点踩原因、用户追问和人工修改比例是否改善。离线评测显示输出更短，上线后要看满意度是否下降、追问是否增加。线上指标能验证离线指标是否真的代表用户价值。

线上样本又要回流评测集。每周从点踩、投诉、转人工、高成本、长延迟、错误引用、工具失败样本中挑选代表性案例，清洗后加入回归集。这样评测集会越来越贴近真实业务，而不是停留在上线前编出来的题。AI 服务的质量体系应像产品一样持续演化。

评测指标也要版本化。一个样本的标准答案可能随知识库更新变化，某些政策、价格、接口能力也会变。评测集要记录资料版本和判断依据。否则系统可能因为回答了最新事实而被旧标准判错，或因为旧资料未更新而被误判通过。

十四、指标之间要一起看

单个指标很容易误导。Token 下降可能是好事，也可能是上下文被截断导致质量下降。延迟下降可能是优化成功，也可能是系统跳过了检索。错误率下降可能是兜底文案吞掉了错误。满意度上升可能是用户只在简单问题上使用。成本下降可能是强模型调用减少，也可能是高价值任务流失。

所以指标要组合看。Token 上升但满意度和任务完成率也上升，可能是合理投资；Token 上升但满意度下降，说明浪费。延迟上升但错误率不变，要查上下文和供应商排队；延迟上升且用户取消率上升，说明体验事故。成本下降但转人工率上升，说明便宜策略把问题转嫁给人工。

AI 服务最有用的分析经常是分群。新用户和老用户不同，免费用户和付费用户不同，简单问答和复杂任务不同，中文和英文不同，移动端和桌面端不同。总体指标正常，不代表关键客户正常。监控要支持按租户、功能、模型、地区、渠道、版本、知识库、实验组切分。

还要看变化点。某天模型从 A 切到 B，提示词版本从 12 到 13，知识库重建，前端改了输入框默认提示，都会影响指标。指标曲线最好标注发布事件。否则团队看到波动，只能从记忆里找原因。

十五、一个小团队的起步方案

小团队不需要第一天就搭大而全平台，但必须从第一天记录关键字段。最小可用监控可以这样做：每次用户请求生成一个 request_id；记录用户或租户标识、功能、模型、输入 Token、输出 Token、首字延迟、总时长、错误类型、重试次数、成本估算、检索文档 ID、工具调用列表、用户反馈。先存数据库或日志系统，再逐步接入专门工具。

第一张看板只做十个指标：请求量、成功率、P95 首字延迟、P95 总时长、平均输入 Token、平均输出 Token、每日成本、单请求成本、点踩率、转人工率。第二张看板再做成本拆分和错误分类。第三张看板做 RAG 和 Agent 详情。不要一开始铺满几十个图，没人维护。

同时准备一个低满意样本池。每天或每周抽取点踩、转人工、多次追问、高成本、长延迟、检索空结果的会话，人工看一批。AI 服务质量提升很依赖样本复盘。纯看数字，不看具体对话，很容易错判。

发布流程也要轻量纳入。每次改模型、prompt、知识库、路由策略前，用固定评测集跑一遍；上线后看 24 小时关键指标；若点踩率、延迟、成本或错误率超阈值，回滚或灰度收缩。哪怕团队很小，也要把这些动作制度化。

安全和隐私从起步就要考虑。日志里不要直接保存完整身份证号、手机号、密钥、病历、学生隐私等敏感内容。需要排查时使用受控权限，给敏感样本设置保留期限。监控不是另一个数据泄露入口。

十六、成熟团队的进阶方向

成熟团队可以把 AI 监控做成质量运营系统。第一，建立离线评测集和线上真实样本联动。线上低满意样本进入标注池，形成新的回归用例；发布前评测集通过，发布后看真实用户表现。第二，做自动质量评估，对事实性、引用支持、格式、语气、安全、任务完成度进行多维评分。

第三，做模型路由实验。不同模型、不同提示词、不同检索策略在真实流量中灰度比较，看质量、延迟和成本综合表现。不要只凭 benchmark 决定生产路由。第四，做成本归因和预算管理，让产品经理知道每个功能的毛利压力，让客户成功知道哪些租户异常使用。

第五，做知识缺口运营。把检索空结果、低相似度、用户追问、点踩原因聚合成知识库待补清单。很多 AI 服务质量不是靠改模型提升，而是靠补资料、改文档、清理过期内容。第六，做人工协作闭环。客服、教师、编辑、审核员对 AI 输出的修改，都是宝贵训练和评估信号。

第七，做事故复盘。AI 事故不一定是服务挂掉，也可能是错误建议、错误引用、成本失控、内容越界、工具误操作。复盘要记录触发条件、影响范围、监控是否发现、告警是否及时、用户是否受影响、如何防止复发。AI 服务需要自己的事故分类。

第八，做体验分层。不同用户和任务设不同 SLO。企业高价值客户的关键流程可以用更强模型和更严格评估；低风险临时问答可以走低成本路径；后台批处理可以慢但稳定；实时对话要优先首字延迟。成熟系统不是一条路跑到底，而是按价值和风险路由。

十七、常见误区

误区一，只看 API 成功率。模型返回成功但答案不可用，是 AI 服务最常见问题。必须把质量、反馈和任务完成纳入监控。

误区二，不记录 Token。没有 Token，就无法解释成本、延迟、截断、上下文膨胀和模型路由问题。Token 是基础经营指标。

误区三，只有总成本，没有归因。月账单上涨时，团队不知道是哪位客户、哪个功能、哪个模型、哪个版本造成，只能靠猜。

误区四，过度依赖用户点赞。显式反馈样本少，且容易偏。要结合追问、复制、转人工、任务完成、人工采纳等隐式信号。

误区五，把所有文本写进日志。这样排查方便，但会制造隐私风险。应分层保存、脱敏、设权限和保留期限。

误区六，告警太多。几十个告警同时响，最终等于没有告警。起步只保留真正需要人处理的异常。

误区七，监控不跟发布关联。模型、prompt、知识库和路由变化都可能造成质量波动。没有版本标记，曲线很难解释。

误区八，用平均值掩盖长尾。AI 服务长尾体验很明显，P95、P99 和高成本样本比平均值更能暴露问题。

十八、检查清单

• 每次用户任务是否有统一 request_id、session_id 或 task_id。
• 是否记录输入 Token、输出 Token、上下文窗口、截断和模型名。
• 是否拆分首字延迟、总时长、检索、重排、模型、工具和后处理耗时。
• 是否按供应商错误、应用错误、质量错误和用户可见错误分类。
• 是否记录重试次数、降级路径、重试增加的成本和延迟。
• 是否能把成本归因到功能、模型、租户、用户和任务。
• 是否收集点赞、点踩、转人工、复制、追问、人工采纳等反馈信号。
• RAG 是否记录检索空结果、低置信结果、引用覆盖和过期资料命中。
• Agent 是否记录步骤数、工具调用、参数、结果和人工确认。
• 日志是否做了敏感信息脱敏、访问控制和保留期限管理。
• 看板是否区分工程视角、产品视角和运营视角。
• 告警是否覆盖错误率、P95 延迟、Token 异常、成本异常和满意度异常。
• 发布模型、提示词、知识库和路由时，是否有评测、灰度和回滚机制。

参考资料

• Google SRE Book, Monitoring Distributed Systems: https://sre.google/sre-book/monitoring-distributed-systems/
• Google SRE Book, Service Level Objectives: https://sre.google/sre-book/service-level-objectives/
• OpenTelemetry Semantic Conventions for Generative AI: https://opentelemetry.io/docs/specs/semconv/gen-ai/
• OpenTelemetry Semantic Conventions for Metrics: https://opentelemetry.io/docs/specs/semconv/general/metrics/
• Langfuse documentation, Tracing: https://langfuse.com/docs/tracing
• Langfuse documentation, Scores and user feedback: https://langfuse.com/docs/scores/overview
• Arize Phoenix documentation, LLM Traces: https://arize.com/docs/phoenix/tracing/llm-traces
• LangSmith documentation, Observability: https://docs.smith.langchain.com/observability
• OpenAI API Error codes: https://platform.openai.com/docs/guides/error-codes
• OpenAI API Text generation and token usage concepts: https://platform.openai.com/docs/guides/text
• Anthropic API Errors: https://docs.anthropic.com/en/api/errors
• Anthropic Token counting: https://docs.anthropic.com/en/docs/build-with-claude/token-counting