你的 Gold 评估集已经发生偏移,而它的通过率正是你无法察觉的原因
黄金评估集的通过率为 94%。模型在本季度已经升级了两次,提示词修改了 11 次,工具库增加了 4 个,仪表盘依然是一片绿色。然而,一名销售工程师转发了一份对话记录,显示智能体(Agent)自信地将客户引导至一个两个月前就已停用的工作流;与此同时,支持团队负责人悄悄开启了一个讨论组,询问为什么在评估流水线显示没有回归的情况下,满意度评分已经连续下滑了六周。黄金集并没有撒谎。它只是在用上个季度的产品标准来衡量这个季度的流量,而除此之外没人要求它做别的事。
这是评估系统最难察觉的一种失效模式,因为本该检测质量回归的工具本身就是误报的源头。通过率是针对集合中的项目计算的;集合中的项目是根据某个时间点的使用快照精心筛选的;用户的使用方式已经演进,但通过率依然保持“干净”。团队信任绿色的仪表盘,发布了另一个模型升级,几个月后才发现生产环境的分布与评估集所衡量的东西已经南辕北辙,而这种状态持续的时间超出了所有 人的想象。
解决方法并不是提高黄金集的更新频率。更新频率是一个错误的调节旋钮;正确的旋钮是拥有第二个针对不同时间窗口校准的工具,以便在用户发现问题之前,通过两者之间的分歧来暴露漂移。这第二个工具就是影子评估(Shadow Eval)—— 一个从当前生产流量中持续重建的并行评估集,它与黄金集并行运行,其明确的任务就是与黄金集唱反调。
黄金集是校准,而非事实真相
请像仪器工程团队对待参考标准那样对待黄金评估集。它是针对已知时间点的已知输入分布进行校准的,由决定了哪些细分领域重要的人员,使用体现了当时“好”的标准来编写评分标准(Rubrics)。这些决定本身都没有错,但它们都过时了。
关于黄金数据集的行业指南将其描述为“受信任的输入和理想的输出……由人工标注……作为基准”。这种语言精确地说明了该集合能保证什么,而对其不能保证什么保持沉默。该集合保证了其中项目随时间推移的一致性。但它不保证其中的项目仍然代表系统在生产环境中处理的工作负载。概念漂移(Concept drift)、行为演进、微调输出风格的提示词修改、改变拒绝行为的模型升级——所有这些都会在不改变黄金项目的情况下改变实时分布。在一个移动的分布上运行静态数据集,从结构上讲,这种度量标准注定会失效。
这种失效在黄金集内部是不可见的。如果你只看绿色的通过率,陈旧感的唯一信号就是当客户投诉传达到某位碰巧也在查看评估仪表盘的工程师那里。到那时,回归已经复合成倍增长了数周。
为什么“每季度更新黄金集”解决不了问题
当团队意识到黄金集变得陈旧时,标准的反应是设定一个更新周期——每季度、每月或每次发布。这有一点帮助,但由于两个原因,它无法解决底层问题。
第一个原因是,负责更新黄金集的团队往往就是构建它的同一批人,他们查看的是已经看过的追踪记录(Traces),带着对哪些细分领域有趣的相同偏见。更新往往只是在现有项目附近添加类似项目。该集合在已覆盖的区域内变得更庞大、更自信。而盲点依然是盲点,因为策划者不知道那是盲点——这就是“盲点”的定义。
第二个原因更具结构性。黄金集承担着两个相互冲突的任务:回归检测(这次模型发布在已知的输入上表现是否与前一个一致?)和分布覆盖(我们衡量的输入是否仍然看起来像生产环境?)。回归检测要求集合在不同发布版本之间保持稳定,以便通过率的变化具有意义。分布覆盖则要求集合随生产环境的演进而演进,以便通过率能持续代表真实情况。更新黄金集强迫单一产物同时处理这两个任务,结果两个都做不好。上个季度作为稳定基准的项目被退役或重新标注,破坏了回归数值的可比性。而没有被退役的项目则与实时分布越漂越远。团队在两种失效模式(过度稳定和过度变化)之间轮转,却从未在任何一个问题上获得清晰的信号。
出路在于停止要 求一个集合同时完成两项工作。让黄金集专注于回归检测。构建第二个专注于分布覆盖的集合。让它们并行运行。它们之间的分歧,正是你一直缺失的信号。
影子评估集究竟是什么
影子评估集 (shadow eval set) 是从最近的生产流量中通过分层采样构建而成的,其更新节奏是持续或近乎持续的——每个周期都会加入新条目,而超过周期窗口的老条目则会被淘汰。它由相同的评估器(LLM 作为裁判、人工审核、确定性检查,或者你在黄金集上使用的任何方式)按照相同的评分标准 (rubrics) 进行评分。它与黄金集 (gold set) 并行运行,针对每一次模型和提示词 (prompt) 的更改进行测试。它明确不是一个准入标准 (gate);通过影子评估集并不意味着授权发布,因为这些条目没有像黄金集条目那样经过仔细审核。影子评估集未通过,或者更重要的一点——与黄金集的结果出现了值得关注的分歧,这便是一个信号,表明某些东西已经发生了变化。
构建过程中有几个细节至关重要。
进行分层采样,不要进行均匀采样。 从生产流量中进行均匀采样会过度代表最常见的用例,而忽略了可能存在实际故障的长尾切片 (tail slices)。近期评估文献中的标准做法是按群组、查询类型、用户细分或嵌入聚类 (embedding cluster) 进行采样,并确保每个切片都有比例代表性或保底代表性。撰写过相关文章的追踪观测 (trace observability) 供应商——LangSmith、Maxim、Confident——都得出了相同的建议:按对产品至关重要的维度进行分层,确保 没有任何关键类别低于每切片的最低限额,并每季度审计一次切片分类体系。
使用与黄金集相同的评分框架。 同时运行两者的目的是为了获得可比的数字。如果影子评估集由不同的裁判、按照不同的评分标准、在不同的时间表上进行评分,那么比较就毫无意义。应该由相同的裁判,针对相同的维度,对从不同分布中提取的条目进行评分。这才是让分歧具有信息价值的原因。
- https://hamel.dev/blog/posts/evals-faq/
- https://hamel.dev/blog/posts/evals/
- https://microsoft.github.io/code-with-engineering-playbook/automated-testing/shadow-testing/
- https://scc-comets.com/continuous-evaluation-in-production-shadow-testing-large-language-models
- https://venturebeat.com/infrastructure/monitoring-llm-behavior-drift-retries-and-refusal-patterns
- https://orq.ai/blog/model-vs-data-drift
- https://www.atla-ai.com/post/why-your-evals-keep-breaking
- https://www.langchain.com/articles/llm-monitoring-observability
- https://wandb.ai/onlineinference/genai-research/reports/LLM-evaluation-Metrics-frameworks-and-best-practices--VmlldzoxMTMxNjQ4NA
- https://nexla.com/ai-infrastructure/data-drift/
- https://arize.com/resource/golden-dataset/
- https://www.confident-ai.com/blog/the-ultimate-llm-evaluation-playbook
- https://agility-at-scale.com/ai/generative/continuous-evaluation-and-drift-monitoring/
- https://arxiv.org/html/2411.13768v3
- https://www.getmaxim.ai/articles/building-a-golden-dataset-for-ai-evaluation-a-step-by-step-guide/
