评估集也有季节性：为什么质量在报税季的第一个周一会下降

在 1 月下旬的一个周一早上，仪表盘发出了第一次回归预警。支持助手的质量得分一夜之间下降了 3 分。周末没有发布 Prompt 变更。没有更换模型。评估套件——团队在 6 个月前构建的一个包含 800 行数据的精选黄金集 (gold set)——也没有任何变化。有人开了一个故障单 (incident)。

经过两天的二分定位 (bisecting) 之后，得到的答案平淡无奇且是结构性的。那是美国国税局 (IRS) 开启当年税务申报后的第一个工作周一。一半的入站查询已从“我的薪水到账了吗”变成了“我该如何申报来自支付 App 的 1099-K 表单”。在夏季采样的评估集对 1099-K 毫无头绪。模型并没有变差。是客户变了。评估标准是针对一个已经不存在的客户群进行校准的。

这种模式在每一个拥有季节性用户的产品中每季度都会重复出现——报税季的金融科技、季度末的销售工具、开学季的教育产品、退货季的电子商务、订票季的旅游产品、投保季的医疗保健。将“评估集视为固定资产”是一种舒适的抽象，但在一个无人更新的日程表上，这种做法是错误的。

评估集是非平稳分布的时间戳样本

经典的机器学习 (ML) 监控文献教导我们将漂移分为两种。数据漂移 (Data drift) 是指输入发生变化——模型在生产环境中看到的特征分布与其训练时的分布发生了偏离。概念漂移 (Concept drift) 是指输入与输出之间的关系发生了变化——同样的输入现在需要不同的答案。文献还明确指出，并非所有漂移都是对等的：周期性的季节性漂移是预期内且可预测的，而真正的概念漂移才是危险的那种 (Evidently AI)。

发布 LLM 功能的团队尚未内化的是：评估集本身也是一个不断变化的分布的冻结样本。从构建方式来看，黄金数据集 (golden dataset) 捕获的是你停止采样那天生产环境的样子。当你三个月后运行它时，你并不是在测量“模型是否仍然表现良好”，而是在测量“模型在处理人们 3 月份发送的那种任务时是否仍然表现良好”。如果 8 月的流量看起来不像 3 月的流量，那么这个答案与你的 PM 实际提出的问题（即 8 月的用户是否得到了满意的回答）就毫无关系了。

这个问题已经得到了衡量。LENS 框架明确地将 Prompt 分布视为随时间、用户群体和地区演变的东西，并表明自然的 Prompt 偏移会降低微调后的 LLM 性能，而这种性能下降在原始评估集中是无法体现的 (arXiv 2604.17650)。关于黄金数据集的文献也从实践者的角度得出了同样的结论：一个关键的缺点是维护开销和陈旧风险，建议的补救措施是为黄金数据行设置 90 天的有效期（除非重新验证），并频繁地从生产环境中提取新鲜场景进行小规模更新 (Confident AI, Maxim)。

最贴切的比喻来自信用风险建模，那里的团队几十年来一直在监控分布的稳定性。人口稳定性指数 (Population Stability Index, PSI) 报告了一个单一数值，用于衡量当前群体偏离参考群体的程度。PSI 低于 0.1 表示没有实质性变化；0.1 到 0.25 是值得注意的轻微偏移；超过 0.25 则是重大偏移，应该触发调查并可能采取行动 (Fiddler, NannyML)。诀窍是将这种本能应用到你的评估集上，而不仅仅是你的特征上。参考群体是你的评估集采样来源。当前群体是你的实时流量。当两者之间的 PSI 超过 0.25 时，评估集就不再是一个具有代表性的把关标准，你从中读到的分数报告的是一个已经发生迁移的客户群体。

季节性日历就是工程日历

这改变的第一项纪律是团队如何选择更新日期。大多数团队只有在有人有空时才会更新评估集，也就是说，几乎从不按计划进行。更新节奏最终与工程日历挂钩——迭代计划、季度 OKR 周期、发布之间的间歇期。这些都与用户输入分布实际发生变化的时间无关。

替代方案是根据产品的流量日历进行季节性的评估更新。对于金融科技产品，这意味着在报税季开启前更新评估集，在 4 月报税截止日期再次更新，在季度预缴税截止日期再次更新。对于销售工具，这意味着在每个季度末冲刺的两周前更新评估集。对于教育产品，这意味着在 8 月开学季之前更新。重点不在于具体的日期，而在于团队可以提前确定这些日期，因为它们映射的是客户的日历，而不是团队那一周碰巧在做的事情。

使之具体化的产出物是一个名为“流量日历”的一页文档。它列出了每年输入分布已知会发生变化的 4 到 6 个日期、受影响的产品或页面，以及提前每个日期 2 到 3 周的评估更新截止日期。该文档存放在值班 (on-call) 轮换的操作手册 (runbook) 旁边，因为更新截止日期是一项值班义务，而不是一个可选的目标。

流量分布仪表盘，而不仅仅是质量仪表盘

质量仪表盘通常只报告一个数字——黄金数据集（gold set）上的评测得分——并可能将其按两三个维度进行细分。这展示了质量状况，但它并没有告诉你输入分布是否发生了偏移。作为补充，流量分布仪表盘必须与质量仪表盘并存。

一个最起码有用的版本包含三个面板。

第一个面板是按月统计的输入组合，按意图（intent）或主题（topic）进行细分。如果你的支持助手有 15 个常见意图，该面板会显示上个月流量中每个意图所占的比例，以及评测集中覆盖每个意图的比例。你需要的视觉效果是两个重叠的条形图，它们看起来应该是相同的。当它们不再相似时，就是你的预警信号。

第二个面板是根据当前月的输入分布与评测集的输入分布计算得出的单一 PSI（群体稳定性指数）数值。这个数字每天变化缓慢，而这正是重点所在。当它超过 0.1 时，会显示在仪表盘上以引起关注。当它超过 0.25 时，就该呼叫相关人员了。

第三个面板是列出在生产环境中份额增长最快（相对于其在评测集中份额）的热门意图或主题。这是对“评测集具体在哪些方面覆盖不足”的回答，也是团队用来决定首先标注哪些新样本的依据。

拥有这三个面板的团队可以凭借证据来争论评测集更新的优先级。没有这些面板的团队只能依靠直觉，而直觉在判断输入分布方面往往是错误的，就像在判断延迟尾部形状（latency tail shapes）时一样——人类会系统性地忽略缓慢移动的结构性漂移。

影子评测：一种连续的距离衡量标准

流量仪表盘是必要的，但还不够充分，因为它只告诉你输入发生了变化，而没有告诉你模型是否跟上了这种变化。其补充手段是影子评测（shadow eval）——每周针对团队信任的任何评审方法，对真实生产流量的样本进行评分，并将其报告为与预留黄金数据集的连续距离衡量值。

其实现方式并不复杂。根据流量大小，对 1% 到 10% 的生产请求进行采样——在线评测的典型生产采样率就在这个范围内，具体数值根据流量和每个请求的评分成本进行调整（Statsig, LangChain）。运行与黄金数据集相同的评审模型（judge）或评分标准（rubric）。在同一个仪表盘上，将每周的数值与黄金数据集的得分并列报告。两个数字，一个趋势稳定，一个呈下降趋势，比一个解释取决于你在哪个周一读取的单一数字要响亮得多。

影子评测也是团队发现新失败模式的地方。如果 1099-K 查询在 1 月下旬进入生产环境，而助手无法处理，那么在黄金数据集得分察觉之前，影子评测就会暴露出这种模式，因为黄金数据集里根本没有 1099-K。影子评测成为了新黄金数据集行的暂存区：得分较低的生产样本经过人工审核、标注，并晋升到下一个更新周期（Klu, Arize）。

一点小小的校准建议。生产侧的统计漂移最好基于滚动基线进行监控——例如以 7 天为窗口对比前 7 天，或者环比——而不是针对静态训练快照，这可以防止因过时的季节性模式而产生的告警疲劳（Evidently）。评测集的对比则不同：你确实需要一个静态参考，因为问题核心在于当前世界与你校准门控时相比，究竟偏离了多少。两者都应该出现在仪表盘上，它们回答的是不同的问题。

一个“知晓”评测集时效性的发布门控

最后一部分是发布门控条款，这也是大部分工程判断力所在的地方。每个通过 CI 运行提示词（prompt）或模型 PR 的团队，都有某种版本的评测得分阈值，PR 必须跨过这个门槛。错误在于将阈值视为常量，而适当的阈值应该是评测集相对于当前流量的过时程度（staleness）的函数。

最简单的版本是一个这样的条款：如果评测集的上次更新时间超过 N 周，并且当前流量与评测集分布之间的 PSI 超过阈值，则不退化（non-regression）的门槛会收紧。由于团队正将产品发布到一个评测集未曾采样的世界中，因此测得的小幅退化更有可能是真实的退化，门控必须对此进行补偿。

举一个数字刻意取整的例子。默认策略：一个 PR 导致的全局评测得分退化不得超过 2%，任何细分维度的退化不得超过 5%。评测集过时策略（当评测集超过 8 周或 PSI 超过 0.25 时触发）：一个 PR 导致的全局评测得分退化不得超过 1%，且任何细分维度均不得退化。团队仍然可以通过过时评测集的门控进行发布，但难度更大，而这种更严格的门控本身就是一种强制函数——恢复宽松门控最廉价的方法就是更新评测集。

这个条款同时实现了两件有意义的事。它在团队最可能“盲飞”的时期强化了发布流程，并对团队未能保持评测集新鲜的行为征收“税收”，而这正是日历提醒原本应该防止的失效模式（ZenML, Inference.net）。

运作良好的状态是什么样的

内化了这一理念的团队不再将评估集视为一个已经构建完成的东西。他们将其视为一个持续构建的过程。流量日历存在于操作手册（runbook）中。流量分布仪表盘与质量仪表盘并列。影子评估每周报告一个数值，由值班工程师查阅。发布门禁中包含一条每个人都至少读过一次的“评估过期”条款。1 月份导致助手崩溃的 1099-K 查询，到 2 月份就已经进入了黄金集，而当下一个报税季开启时，门禁已经为此完成了校准。

尚未内化这一理念的团队通过了绿色门禁并发布 PR，在报税季的第一个周一看着仪表盘下跌了 3 个点，开启了一个故障响应，却在代码差异（diff）中一无所获，最后在复盘报告中写下“肯定是数据漂移”并关闭了故障，然后在明年重复同样的事情。评估集在仓库中保持不变，客户在不断变化，而门禁测量的指标与用户体验之间的差距随着又一个季度的到来而进一步扩大 (Braintrust, VentureBeat)。

架构上的认知虽然微小，却起着承重的作用。评估集不是基准测试。它是非平稳分布的一个带有时间戳的样本。如果一个团队在整个财年中运行一套不曾改变的黄金集，那么他们是在针对一个已经离开的客户来校准质量门禁。