现有藏书全是离线评测，这篇补上另一半世界：没有 ground truth 时线上能算什么（无参考指标体系）、漂移检测如何避免把噪声当报警、线上失败如何回流成离线用例、A/B 与灰度怎么配合。offline 是考试，online 是体检。
先修：a24（统计严谨性）。Agent 已上线或即将上线的团队必读——「等用户投诉才知道出事」就是缺这一课。MVP 只要三样：护栏检测、用户反馈、成本监控。
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
真实请求没有 ground truth。线上只能算无参考指标（faithfulness、护栏、成本、用户反馈、LLM 裁判分），需要标准答案的判定只能放 offline。
不一定——线上指标带噪声。要看「显著且持续的劣化」：基线窗口 vs 近期窗口对比、分群拆开看、关联发布变更，而不是盯单日抖动。
online 发现未知失败 → 捞出失败 trace 固化成 offline 新用例（过三道筛子）→ 修复 → 回归门禁防复发 → 重新上线。online 抓新失败，offline 防老失败。
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
前两讲，评测在实验室里能跑起来、也看得见每一步了。但实验室的题再全，也不等于真实世界。这一讲，我们走出实验室——线上评测（online eval）：用生产流量做实时质量监控。
offline 是"上线前的考试"，online 是"上线后的体检"。前者防止你把已知的错误带上线，后者抓住你没想到的错误——两者缺一不可，还要连成一个闭环。
两个理由，offline 再好也堵不住：
一是长尾。你的评测集，装的是你想得到的场景。可真实用户永远会做出你没想到的事——奇怪的输入、罕见的组合、恶意的试探。offline 覆盖的是"已知的未知"，而真实世界里有大量"未知的未知"。
二是世界会变。模型悄悄更新了版本、上游某个 API 改了返回、用户的问法随季节漂移……你那批固定的 offline 题，反映不了"最近线上到底怎么样"。offline 是一张定格的照片，而线上是流动的河。
所以你需要 online：持续地、对真实流量、实时地量质量。它不是 offline 的替代，是 offline 够不到的那半个世界。
| offline 评测 | online 评测 | |
|---|---|---|
| 时机 | 上线前 | 上线后，实时 |
| 对象 | 固定的评测集 | 真实生产流量 |
| 有没有 ground truth | 有（标准答案/oracle） | 通常没有 |
| 擅长 | 回归门禁、可控对比、快速迭代 | 抓长尾、抓漂移、真实真值 |
| 速度 | 快（随时重跑） | 慢（要等真实流量累积） |
最关键的一栏是"有没有 ground truth"。offline 你给每个 task 配了标准答案（oracle），所以能算"对不对"。而 online 面对的是真实请求——你没有它的标准答案。这一条，直接决定了线上能算哪些指标、不能算哪些。
这是线上评测最需要想清楚的约束。指标分两类：
能在线上算的（reference-free，不需要标准答案）：
算不了的（reference-based，需要 ground truth，只能留给 offline）：精确匹配、和标准答案比对的正确性——真实请求没有标准答案，这些做不了。
所以线上评测 ≈ 用一批无参考指标 + 用户信号，持续给真实流量打分。想清楚"哪些指标离了标准答案还能算"，是设计线上评测的第一步。
没有标准答案，怎么估"成没成"？靠代理信号（proxy）拼出来：用户没重试、没转人工（大概率解决了）、会话正常结束、没投诉（正向）、人工介入被触发（说明 Agent 自己没搞定，负向）、下游行为（退款后没再来问同一件事）。这些代理都不完美，但组合起来能给你一个"线上成功率"的近似。要更准，就定期抽一小批线上请求做人工标注——既拿到一批带 ground truth 的真实样本，又能校准你那些无参考指标准不准。线上不是完全没有真值，而是真值很贵，所以用代理 + 抽样人工来逼近它。
线上打分怎么跑？三种放法，按成本和实时性选：
一句话：护栏内联实时拦，质量指标异步采样算。
线上评测最核心的动作，不是给单条请求打分，而是盯住关键指标随时间的曲线，抓漂移。
你会盯几条线：faithfulness（幻觉率）、护栏违规率、用户点踩率、平均成本与延迟、以及各种成功代理指标。正常时它们平稳；一旦某条突然跳变或缓慢劣化，就是在报警——质量漂移了。常见触发漂移的事件：模型换了版本、prompt 改了、上游依赖变了、流量结构变了。
这里有个坑必须连回统计严谨性：线上指标本身也带噪声，别把正常波动当成漂移。今天点踩率比昨天高 2%，可能只是当天流量的随机波动。所以漂移检测也要有统计意识——看的是"显著的、持续的劣化"，而不是"某一天的抖动"。否则你会天天被假警报吵醒，最后干脆不看告警了。
具体怎么判断漂移，几个实用做法：
线上评测最大的价值，不止于"发现问题"，而在于它能喂养 offline，把整个评测体系变成一个飞轮：线上真实流量 → 实时打分、抓到异常/失败的 trace → 捞出失败 trace 固化成 offline 评测集的新用例 → 修复 Agent → offline 回归门禁守住"这个错不再犯" → 重新上线 → 继续线上（飞轮再转）。
online 负责发现"未知的新失败"，offline 负责防止"已知的老失败复发"。
"production traces become datasets（生产轨迹变成数据集）"——线上抓到的每一个真实失败，都是给你 offline 评测集的一份免费的、命中要害的礼物。这也是为什么线上线下要用同一套 trace 标准：格式一致，这个回流才顺滑。
不过回流也别照单全收——线上失败成百上千，直接全塞进 offline 会让评测集迅速臃肿，三道筛子同样适用：去重（同类失败只留代表）、看严重性 × 频率（优先收高风险高频的）、能不能写出稳定判定（写不出的先别收）。线上是个源源不断的"失败素材库"，你的任务是从中挑出最值得固化的那些。
线上还有一件 offline 做不了的事——A/B 测试：把真实流量分给两个（或多个）版本，比较它们的线上指标。它回答的是 offline 回答不了的那个终极问题："在真实用户身上，新版真的更好吗？" offline 能告诉你"新版在我的测试集上分更高"，但只有 A/B 能告诉你"新版让真实用户的满意度/成功率/成本真的改善了"。
用 A/B 有三个要点：
再提两个 A/B 常见的陷阱。新鲜感效应（novelty effect）：新版刚上，用户因为好奇而互动增加，指标看着变好，过几天就回落——所以 A/B 要观察得够久。指标打架：新版可能"成功率"升了、却把"成本"或"护栏违规"也带高了——所以 A/B 别只盯一个主指标，要同时守住护栏类的"底线指标"，一个都不能破。
别想着一上来就全套。线上评测的 MVP，通常先接这三样：
这三样投入小、价值大。等它们跑顺了，再加异步的 faithfulness 幻觉监控、LLM 裁判质量分、A/B 框架。先把最便宜、最兜底的护栏和用户信号接上，别等憋出一套完美的线上系统才上线。
退款 Agent 上了线，你的线上评测大概盯这几条：退款失败率 / 用户投诉率（成功代理 + 用户信号）；护栏违规率：有没有出现"没核身份就退""对不可退订单退款"；忠实度：给用户的答复有没有和真实退款状态不符（谎报）；单均成本与延迟。
某天你发现"护栏违规率"这条线悄悄爬高了——先确认这是显著漂移不是波动，然后调出那批违规的 trace 看根因，发现是上游改了订单状态字段导致"核身份"那步失效。你把这些失败 trace 固化成 offline 新用例、修复、跑回归门禁确认修好且没弄坏别的，再灰度上线。闭环，就是这么一圈圈转起来的。
值得回味的是：这次事故里，线上评测扮演了"哨兵"（第一时间发现违规率异动），tracing 扮演了"侦探"（下钻到字段改名这个根因），offline 评测扮演了"疫苗"（把这个失败固化成用例，从此免疫）。三者各司其职、缺一不可。