迁移避坑 日志采样评估偏差问题解析

一个高频翻车的诊断场景：离线评估提升了5个点，上线两周核心指标却出现下滑。层层排查后，模型本身没有缺陷，是评估所用的日志采样数据存在系统性偏差。这种“静默问题”比接口报错更隐蔽——它不会触发任何告警，却会持续蚕食业务指标。

评估偏差的成因
标准做法是：从线上日志抽取一批请求，由人工标注标准答案，新旧模型各自跑一遍并对比得分。这个流程依赖一个前提——日志数据能真实反映线上流量分布。但在GPT-5.5迁移场景下，这个前提极易失效。

日志数据天然带有“幸存者偏差”。线上日志仅记录“当时模型实际处理过的请求”。旧模型因能力不足，直接拒绝回答或给出模糊回应，用户很可能放弃，后续追问根本不会发生。这些“从未出现”的追问自然不在日志中。用这份日志评估GPT-5.5——它的生成能力更强、回答更具体——用户会发起更多后续交互，形成新的对话模式。评估集无法覆盖这些新场景，结论必然存在盲区。

时间窗口同样是常被忽略的因素。日志采样集中在某一时段，而该时段恰好是某类特定用户的高活跃期，样本分布就会偏移。例如工作日上午的日志几乎全是企业用户的办公场景问题，个人用户的娱乐场景完全缺失。

GPT-5.5独有的“输出膨胀偏差”
GPT-5.5的输出比前代更详尽，这引入了一种特殊的评估偏差：离线阶段无法准确预估Token消耗。

离线评估时通常只跑几百条典型用例，这些样本的输出长度可能仅比旧模型多出20%–30%。但上线后真实流量的输出长度膨胀幅度可能超过50%——因为用户开始提出更复杂的问题，进行更深入的追问。若按离线评估的Token消耗做预算，实际账单会大幅超出预期。

更隐蔽的是输出长度膨胀对下游链路的连锁效应。离线评估只测了“模型输出质量”，并未测试“下游截断风险”。上线后真实流量中，长输出被截断的概率明显上升，截断导致格式异常，格式异常触发重试，重试进一步推高成本。这个连锁反应在离线评估阶段完全不可见。

如何破解：三招修正采样偏差

第一招，做足分层采样。按业务场景、时间段、用户类型进行分层抽样，每个核心场景至少抽取100条，边界case占比不低于30%。并且要定期更新，避免用半年前的旧数据评估新模型。

def stratified_sampling(logs, scenarios, samples_per_scenario=100):
    eval_set = []
    for scenario in scenarios:
        scenario_logs = [log for log in logs if log['scenario'] == scenario]
        normal_cases = random.sample(scenario_logs, int(samples_per_scenario * 0.7))
        edge_cases = random.sample(
            [log for log in scenario_logs if log.get('is_edge_case')],
            int(samples_per_scenario * 0.3)
        )
        eval_set.extend(normal_cases + edge_cases)
    return eval_set

第二招，补全“缺失的对话”。从真实日志中抽取一部分数据后，再用模型模拟后续追问，构建完整的多轮对话链。让评估集不仅覆盖“用户第一句话”，还要覆盖“模型回答后用户接着提问”的场景。这对GPT-5.5尤其关键——其详尽的输出会激发用户进行更深入的追问，而这些追问在旧模型的日志中根本不存在。

第三招，为GPT-5.5新增输出长度评估维度。在传统准确率、格式遵循率之外，将输出长度分布和Token消耗纳入评估指标。离线评估时直接用灰度流量实测Token消耗的膨胀比例，而不是凭旧模型的经验估算。同时评估下游链路的截断风险——输出长度超过下游缓冲区上限的概率是多少。

评估集也需要“随模型进化”
评估集不是一次性工作。GPT-5.5的行为特性与上一代不同，旧评估集可能无法检出新模型的关键变化。建议每次模型升级后，将线上新发现的bad case加入评估集，让评估集与模型一起迭代。同时，定期从近期线上日志重新抽样，保持评估集分布与真实流量一致。

模型迁移时，别只盯着评测分数。花时间检查采样数据是否覆盖了足够场景，是否存在分布偏差。GPT-5.5的详尽输出使得“输出长度膨胀”成为一个必须单独评估的维度。采样做扎实了，评估结论才可信，上线才能放心。