回归集越滚越大为什么评测分数更好看线上却更容易翻车很多团队在搭建LLM回归体系时都会把线上失败样本自动回流进评测集。这个动作表面很合理用户哪里出错就把哪里补进基线。⚠️ 但跑上一两周后经常会出现一种反常识现象离线通过率从81%涨到89%线上投诉却没有下降甚至在新版本切换后更集中。问题不在“失败样本没有回流”而在回流之后评测基线开始失去稳定定义。图 1评测基线最危险的不是样本太少而是样本边界越来越模糊真正的污染通常来自三类样本被混装。 一类是稳定复现的系统性失败一类是某次事故期间才出现的临时脏数据另一类则是已经被策略修掉、只对旧版本有效的历史问题。若这三类样本都直接进入同一回归集评测就会把“修复历史问题”与“守住当前能力”混成一个指标。到了版本迭代时团队看到的是分数波动却看不到究竟是模型退化还是基线自身在漂移。图 2失败样本不断回流时评测体系必须区分长期缺陷、临时事故和历史遗留策略离线通过率线上误报率基线漂移率主要问题失败样本直接并入回归集89.1%7.8%18.4%历史问题和临时样本混入基线回流后先做去重和标签校验86.7%5.2%9.1%版本绑定仍不清晰Failure Harvest Freeze 窗口84.9%3.4%2.7%维护成本更高但结论稳定️ 更稳的做法不是让回归集一直长而是先把新失败样本关进隔离带更稳的工程实践是把回流样本拆成quarantine、candidate和frozen benchmark三层。 新失败先进入隔离池只记录错误类型、提示词版本、工具链版本和裁决规则只有当同类失败在多个批次重复出现且人工抽检确认标签稳定后才允许进入候选集。✅ 真正对版本发布负责的基线只能来自固定周期冻结的benchmark snapshot而不能直接消费当天的新投诉。defpromote_failure_case(case,current_release,freeze_window):ifcase.label_confidence0.9:returnstay_in_quarantineifcase.prompt_version!current_release.prompt_version:returnbind_to_legacy_sliceifcase.first_seen_atfreeze_window.start:returncandidate_onlyifcase.repeat_count3andcase.slice_owner_confirmed:returnpromote_to_next_snapshotreturnobserve_more这套分层机制的价值在于它把“发现问题”和“定义基线”分开了。 某电商问答链路的一轮回放里团队把自动回流改成月度冻结后false_regression_alarm从12.6%降到3.1%同时slice_owner处理争议样本的时间缩短了近一半。 评测分数看起来没以前那么漂亮却第一次能稳定回答一个关键问题这次掉分到底是模型真退化还是测试尺子被人悄悄换了。图 3隔离池、候选池和冻结基线分层之后回归集才不会被当天告警牵着走 接下来 3 到 6 个月评测系统的竞争点会从“样本更多”转向“基线治理更硬”接下来3到6个月评测体系的分水岭不会只是benchmark大小而是谁先把版本治理做细。 团队至少要长期盯住benchmark_churn_rate、slice_survival_days、legacy_case_ratio和false_regression_alarm四个指标。若这些治理指标缺位评测平台即使挂上再强的LLM-as-a-Judge也只能把噪声打磨得更精致却无法给发布决策提供稳定依据。笔者认为回归集自动扩容最容易让人上瘾的地方是它看起来总在“更贴近真实用户”。 但没有Benchmark Freezing的 Failure Harvest本质上是在用流动样本给流动模型打分最终只会把评测系统变成运维告警的另一种写法。 你们当前更头疼的是回流样本标签不稳还是历史版本样本一直污染新基线欢迎交流也欢迎点赞、收藏和关注。图 4真正值得投入的不是无限扩容样本而是让每次评测都对应清晰的基线版本