推理：可观测性与在线评测

模型上线后，真正难的不是“服务有没有活着”，而是能不能持续回答四个问题：线上发生了什么、质量有没有变好、成本和稳定性是否可控、异常能不能回放并进入下一轮修复。可观测性回答“系统现在如何运行”，在线评测回答“这次变化是否值得保留”。两者应被设计成同一套闭环，而不是两个互不相干的 dashboard。

这页建议和 推理服务系统、成本建模与 SLO 设计、RAG、Agent 与长上下文系统 一起读。前者解释推理链路和容量约束，本页关注上线后如何持续判断系统是否真的变好。

初学者先抓住

可观测性回答“发生了什么”，在线评测回答“这次变化值不值得保留”。没有可回放的日志和分桶指标，线上质量变化很容易被平均值掩盖。

有趣例子：开店看账本

只看今天营业额不够，还要看客流、退单、出餐时间、差评原因和高峰拥堵。模型上线也是这样：QPS 正常不代表质量正常，错误率低不代表高价值任务没退化。

一、为什么离线 benchmark 不够

离线测试集固定、干净、可复现，真实流量却会不断变化。用户问题分布、上下文长度、附件类型、工具可用性、检索索引、业务目标和安全边界都会随时间漂移。一个模型在离线集上更高分，不等价于线上效用更高。

可以把线上质量写成：

$Q_{\text{online}} = \mathbb{E}_{x \sim p_t(x)}[u(f_\theta(x), c(x), r(x))],$

其中 $p_t(x)$ 是随时间变化的真实请求分布，$u(\cdot)$ 是业务效用，$c(x)$ 是成本和时延，$r(x)$ 是风险约束。线上评测要看的不是单一模型分数，而是质量、成本、时延、稳定性和风险的联合结果。

常见误判主要来自三类：只看全局均值，导致长上下文或高价值桶退化被普通 FAQ 流量掩盖；只看系统健康，误以为 GPU、QPS、错误率正常就代表模型行为正常；一次改太多变量，让模型、prompt、检索索引、缓存和路由变化混在一起，线上实验结论几乎不可解释。

因此，线上评测的最低要求是：所有核心指标都能按任务类型、输入长度、模型路径、租户、语言、工具调用状态和版本变更切开看。

二、先定义 SLI 树，再建设 Trace Schema

可观测性不是面板数量，而是因果定位能力。真正有用的观测系统应能在异常出现后快速回答：哪个用户群、任务桶或模型路径受影响，异常从哪个版本或 feature flag 开始，问题发生在检索、prompt、prefill、decode、工具、后处理还是业务侧，以及下一步应该回滚、限流、扩容、切 fallback，还是进入训练和数据修复。

SLI 树

建议先把指标组织成 SLI 树，而不是先堆 dashboard：

层级	关键问题	典型指标
用户体验	用户是否顺利完成任务	任务完成率 proxy、会话完成率、人工接管率、投诉率
质量行为	模型输出是否可靠	judge 分数、拒答率、格式正确率、工具成功率、引用命中率
系统性能	服务是否稳定	TTFT、TPOT、P95/P99、队列时延、错误率、空响应率
资源饱和	容量瓶颈在哪里	GPU 利用率、KV cache 占用、batch size、prefill/decode 队列
成本效率	质量收益是否值得	单请求成本、单 token 成本、升级到大模型比例、外部 API 成本

传统服务的 golden signals 是 latency、traffic、errors、saturation；模型系统必须额外加入 quality，否则“系统没挂但答案变差”的问题会被长期漏掉。

Trace Schema

Trace schema 应在系统上线前设计，而不是出事故后补字段。一条请求级 trace 至少覆盖几类信息：

类别	关键字段
请求身份	request_id、session_id、租户、产品线、任务类型
输入画像	输入/输出长度桶、语言、模态、附件信息
模型路径	模型版本、量化版本、runtime、route path、fallback path
上下文资产	prompt 模板、检索索引、reranker 版本
性能资源	cache 命中、prefill/decode 耗时、队列时间、KV 占用
工具链路	工具调用链、工具参数、工具耗时、工具错误
质量风险	judge、policy、安全分类器、业务反馈、人工接管或投诉信号

高基数字段不要全部打进实时指标系统。更稳妥的做法是：少数核心分桶用于实时聚合，高基数原始细节放入 trace、日志和 replay 存储。实时面板服务定位，原始样本服务复现。

请求级和 Session 级都要看

单请求指标适合定位链路问题，session 级指标更接近真实体验。Agent、RAG、多轮问答尤其需要 session 级观测，因为一次工具失败或一次错误引用可能影响后续多轮。

建议保留会话完成率、平均追问次数、同题重试率、多轮工具闭环成功率、会话级人工接管率，以及会话内模型路径变化和 fallback 次数。这些指标比单次响应更能反映真实体验。

三、在线评测：持续监控、实验验证与回放

在线评测至少包含四种机制：持续监控、灰度实验、shadow/replay、人审校准。它们目的不同，不能互相替代。

持续监控

持续监控关注“系统有没有退化”。它要求指标稳定、口径清晰、分桶长期保留，适合发现慢性漂移和局部异常。例如输出长度突然变长、拒答率上升、工具调用次数增加、某个长上下文桶 P99 变差。

持续监控需要合成探针流量作为参照系。探针请求应覆盖关键业务模板、高风险安全样本、长上下文样本、典型工具链路和缓存敏感样本。真实流量变了而探针没变，可能是业务漂移；真实流量和探针同时变差，更可能是系统退化。

A/B、Canary 与 Interleaving

A/B 测试用于判断新版本是否因果性更好。若指标为 $Y$，处理变量为 $T \in \{0,1\}$，核心关注：

$\Delta = \mathbb{E}[Y \mid T=1] - \mathbb{E}[Y \mid T=0].$

模型系统做 A/B 时要额外避免用户跨会话污染、检索索引同时变化、prompt cache 共享干扰、工具版本不一致和路由策略叠加。Canary 更适合早期防事故：先在小比例高观测流量上看错误率、空响应率、P95/P99、安全异常和高价值用户反馈，再决定是否放量。

Interleaving 更适合检索、排序和候选答案对比场景。它流量效率高，但不适合所有生成任务。

Shadow Evaluation 与 Replay

Shadow evaluation 让新版本在后台同步跑，但用户仍看到主路径输出。它适合验证高风险模型、runtime、路由策略或工具链变化。缺点是无法直接观测真实用户后续交互，并且工具副作用需要隔离。

Replay 是线上闭环的核心。一个可用 replay 系统至少要固定请求内容、上下文、附件和当时的系统输入；同时记录模型、prompt、检索索引和工具版本；还要保留路由决策、cache 状态、采样参数、安全策略、工具返回或 mock，以及当时的 trace、错误和业务反馈。

只保存用户问题是不够的。没有版本、检索结果和工具返回，所谓回放很容易变成“看起来相似但环境已经不同”的伪复现。

Proxy 指标与人审校准

线上很多场景拿不到 gold label，因此会依赖 proxy：用户是否继续追问、是否复制答案、是否点击引用、是否转人工、工具是否完成、judge 分数是否提升。Proxy 的问题是容易被表面风格欺骗：更长回答可能提高复制率，更保守回答可能降低事故率，用户不追问也可能只是放弃。

工程上建议用双层方案：海量请求用 proxy 做粗筛和异常发现，高价值、低置信、分歧大、投诉触发和新版本相关样本做人审精查；再定期画出 proxy 与人工质量的一致性曲线，并按任务桶、语言桶、租户桶分别校准，而不是只看全局相关性。

四、分桶归因：质量、成本和稳定性必须一起看

模型系统最怕“质量略升，但成本、时延或风险显著恶化”。一次线上实验应同时汇报质量 proxy 和人审结果、TTFT/TPOT/P95/P99、单请求与单 token 成本、工具/API 成本、cache 命中率、升级到大模型比例、fallback 比例、安全拦截与人工接管，以及高价值桶、长上下文桶、多模态桶和工具桶的局部变化。

分桶优先级

推荐长期保留这些分桶：

分桶	解决的问题
长度桶	区分短问答、长上下文、超长上下文的成本和质量退化
任务桶	区分 FAQ、代码、文档问答、数据分析、工具执行
路径桶	区分模型版本、runtime、路由、fallback、量化路径
租户/业务线	避免高价值客户退化被全局均值掩盖
语言/地域	发现多语言和跨地域部署偏差
风险桶	单独看安全、医疗、法律、金融等高风险请求

分桶不是为了画更多图，而是为了决定下一步动作。比如长上下文桶变慢可能要看 KV cache、prefill 队列和上下文压缩；工具桶失败率升高要看 tool schema、参数生成和外部依赖；某个租户质量下降可能要看该租户文档 OCR、索引版本和权限过滤。

行为漂移

很多退化不会先表现成错误率上升，而是表现为行为漂移：回答越来越长导致成本上升，拒答率上升导致任务完成率下降，模板化话术变多导致用户满意度下降，工具调用次数增加但成功率不变，引用格式正确但证据利用变差，或者路由器把更多请求送到贵模型而质量只小幅提升。

因此，每次模型、prompt、judge、路由或缓存策略变化，都应在面板上保留“最近一次变更”栏，并能直接关联到指标变化。

五、RAG、Agent 与多模型系统的特殊观测

RAG、Agent 和多模型路由系统的错误经常不在最终回答本身，而在中间链路。

RAG

RAG 退化通常需要拆成四段看：文档解析和 OCR 是否正确，检索召回是否覆盖答案证据，reranker 是否把证据排到前面，以及生成模型是否忠实使用证据。

只看最终答案会把检索失败、证据拼接过长、引用错误和模型幻觉混成一个“回答不好”。建议 trace 中保留 query rewrite、召回片段、rerank 分数、最终注入 prompt 的证据和引用命中情况。

Agent

Agent 系统要额外看过程指标：计划步数是否异常增长，工具调用是否空转或重复，工具参数错误率，观察结果是否被正确吸收，是否进入死循环，以及多轮恢复是否成功。

Agent 的质量不是单轮回答质量，而是“是否用可接受成本完成任务”。因此要把工具成本、工具失败、恢复策略和 session 完成率放在一起评估。

多模型与多路径服务

多模型系统必须做路径级归因。至少要能回答哪类请求走了哪条模型路径，哪条路径成本最高，哪条路径失败率、人工接管率或安全异常更高，同类请求换路径是否更好，以及最近打开的 feature flag 是否改变了路径分布。

很多线上优化不需要重写模型，只要把一类请求从错误路径移走，就能获得比内核优化更大的收益。

六、告警、发布治理与 Oncall

告警的目标不是“红了就提醒”，而是让 oncall 能快速决定下一步动作。一个实用面板应从总览下钻到任务桶，再下钻到路径和 trace 样本，最后能跳到 replay、回滚或流量切换入口。

分桶异常优先于绝对阈值

纯绝对阈值告警容易漏掉局部退化。更稳妥的告警方式是：全局 SLI 触发重大事故告警，高价值桶和高风险桶触发局部告警，新版本首周使用更敏感的强化观测阈值，冷启动和稳态分开看，业务漂移和系统退化分开判断。

冷启动需要单独监控。新模型刚上线、新池子刚扩容、cache 刚清空、runtime 刚编译时，延迟和命中率与稳态差异很大。把冷启动混进稳态指标，会同时污染容量评估和质量判断。

发布联动

成熟发布流程应和在线评测自动联动：灰度开始前跑探针和 replay 回归，灰度中按关键桶自动判断是否继续放量，超过回滚阈值时自动冻结或切回 fallback，灰度结束后自动生成质量、时延、成本和异常分桶报告，失败实验进入负向档案，记录假设、失败指标、受影响桶和后续是否可重试。

这不是形式化流程，而是为了避免组织反复为同一类错误付费。

Ownership

观测平台也需要 owner 和版本。指标定义、trace schema、judge 口径、bucket 边界、采样策略、脱敏策略和告警规则的变化都应可追踪。否则团队可能在不知不觉中改变统计口径，导致前后版本不可比。

一种实用分工是：平台团队负责 runtime、queue、cache、trace、replay 和资源指标；模型团队负责模型行为、judge、prompt、路由策略和质量回归；产品团队负责业务成功率、价值分层和上线门槛；安全/合规团队负责风险指标、脱敏、审计和数据保留策略。

七、回流闭环与落地清单

可观测性和在线评测最终要服务回流。一个闭环应从线上监控发现异常或机会开始，经过分桶定位、replay / shadow 对照、judge 和规则初筛、人审复核，再把错误 taxonomy 映射到训练、prompt、检索、工具、路由或安全策略修复；修复后的样本要进入回归集，并成为下一轮发布门槛。

错误 taxonomy 必须能指导动作。例如 retrieval_miss 应回到文档处理和检索召回，tool_arg_error 应回到工具 schema 和工具调用数据，factual_hallucination 可能回到证据拼接和后训练，over_refusal 应回到安全边界和偏好数据。

隐私与长期维护

Trace 和 replay 往往包含完整上下文，必须把隐私治理放进主流程：用户标识和敏感字段要脱敏，原始样本要分级存储，高权限访问需要审计，replay 数据要设保留期；对高价值事故还应保留指标快照、trace 样本、feature flags、回滚时间线和修复验证链接。

长期维护建议固定做三件事：季度口径审计、月度高价值样本复查、重要版本后归档质量/时延/成本对照报告。模型、prompt、judge、路由、缓存和业务流量都会变，观测体系如果不跟着治理，很快就会变成“用旧口径看新系统”。

极简验收表

一套线上观测体系至少应让团队快速回答：能否看到问题，能否定位受影响用户、任务桶和路径，能否回放并验证，能否决定回滚、限流、扩容、切 fallback 或继续放量，能否把样本回流到下一轮训练、评测或系统修复，以及能否保持指标口径稳定、关键桶长期可追、发布变更可回看。

如果这些问题还答不快，说明系统只是有 dashboard，还没有形成可运营的线上评测能力。