离线高分不等于线上好用

模型评测最容易掉进的坑，是把离线基准分数当成能力证明。团队花几周把 MMLU、GSM8K、代码通过率刷高几个点，上线后用户投诉却更多了。原因不神秘：离线基准是固定题库、固定 prompt、固定判分，而线上是一条真实分布长尾、上下文动态、意图模糊的请求流。两者的输入分布、评价标准、成本约束几乎处处不同。要避免自欺，评测体系必须同时覆盖离线基准与线上回归，并且明确它们各自回答什么问题、不能回答什么问题。

一个常见的失败模式是“选择性评测”：只汇报涨了的指标，忽略没涨甚至跌了的场景。另一个是“污染”：基准题早已进入预训练语料，模型记住答案并不等于会推理。第三个是“判分错位”：离线用字符串精确匹配或单一裁判模型，线上用户只关心任务是否完成。评测体系的设计目标不是给模型打分排名，而是回答“这次变更会不会让真实用户变差”。

输入侧。离线评测的输入是清洗过的、长度可控的、语言统一的样本；线上输入则是带错别字、口语化、多轮引用、超长上下文、夹杂表格和代码的混合体。差别最大的是分布尾部：一次线上故障往往来自千分之几的长尾输入。因此输入侧评测要做三件事：一是对真实流量做聚类，抽取高频簇与长尾簇；二是构造对抗样本，覆盖空输入、超长输入、注入指令、多语言混排、结构化数据截断；三是记录输入 token 分布和上下文长度的分位数，用于判断模型是否在靠近窗口边界时退化。

推理/执行侧。离线推理通常是单轮、贪心解码、温度固定；线上则是多轮、带工具调用、有采样、有时间预算。这里的关键变量包括：解码参数（温度、top-p）对稳定性的影响，工具调用的成功率与重试策略，以及失败降级路径是否可用。评测时不能只看最终答案，还要看中间轨迹：是否触发了不该触发的工具、是否在检索为空时硬答、是否在超时前主动收敛。执行侧还应记录 P50/P95 延迟与单次请求成本，因为一个分数更高但慢三倍、贵五倍的模型，在多数业务里并不划算。

输出/评测侧。这是最容易自欺的一环。精确匹配只适合有唯一答案的任务；开放式生成需要人工 rubric 或裁判模型，而裁判模型本身有偏置和不稳定。建议采用分层判分：先用规则校验可结构化字段（格式、字段完整性、引用是否存在），再用裁判模型做语义与事实性判断，最后用抽样人工复核校准裁判。同时要把“拒答”“幻觉”“越权调用”作为独立维度，而不是混在总分里。线上回归则要建立 A/B 或影子模式：同一批真实请求同时打给旧模型和新模型，对比完成率、返工率、人工介入率、投诉率，而不是只看自动指标。