那个通过后门污染了你评估集的点赞按钮
“点赞”按钮是你所能埋点的最廉价信号。它也是最危险的信号之一,因为没有任何迹象表明它正在重塑你的评估集本应代表的分布。这个按钮作为正向信号被收集——策展流水线将其解读为高质量——而六个月后,评估集就被一群不包含最可能流失的客户的用户所选择的案例占据了。
这种失败很少表现为回归。它表现为一种偏离:每周评估趋势向好,企业级用户的 NPS 下滑,而团队只有在一个流失的账户指出了其团队一直遇到错误回答的具体问题类型时,才会诊断出这种差距。评估集中根本没有这种类型的案例。你正在优化的信号是真实的。它只是测量了错误的分布。
这篇文章探讨了作为样本选择机制的隐式反馈,它泄漏到评估集中的机制,以及为了防止为你买单的群体被那些点击按钮的群体悄然取代,评估集治理政策应该是什么样的。
泄漏的隐蔽机制
泄漏很少发生在单一环节。它是通过一个在每个节点看起来都很合理的流水线发生的。
首先是示能性(Affordance)。“点赞”按钮是二元的、低摩擦的,并且不成比例地由进行随意交互的用户发出——这些用户没有被卡住,没有截止日期压力,也没有在困难任务上运行模型。在生产环境的聊天机器人中,只有不到 5% 的响应会收到任何用户反馈,而这 5% 并不是均匀的随机样本。它倾向于简短的交互、友好的语气,以及那些将按钮视为礼貌方式而非测量工具的用户。
现在加上策展流水线。数据团队将评分最高的响应采样为训练信号(这是合理的),并将其作为新评估案例的候选池(这在孤立看时也是合理的)。策展准则筛选清晰度、主题覆盖面、语言和毒性。它不会筛选选择偏置,因为选择偏置不是单个案例的属性。它是案例如何被准入候选池的属性。当一行数据到达评估环节时,本可以让你重建其来源的监管链已被压缩为“来自反馈池的候选,评审员已批准”。
最后是评估团队。评估团队接受源自“点赞”的案例,假设“用户喜欢这个答案”是正确性的可用代理指标。它是点击瞬间满意度的代理指标,而这是一个不同的量。用户可能会喜欢一个他们无法验证的、自信且错误的答案。用户也可能对一个加载时间过长的正确答案吝啬点赞。这个按钮测量的是预期与呈现的交汇点——而不是问题与基准真值的交汇点。
六个月后,评估集被提示词占据,这些提示词的群体倾向于随意的查询,带有简短、友好的答案,在参与度上得分很高,但在决定你最困难的客户是否续约的技术准确性上得分很低。流水线中的每一步都完成了它的设计任务。然而,系统仍然产生了评估漂移。
为什么“用户给了我们这个信号”不等于“这个信号代表了我们的用户”
当评估图表和 NPS 图表出现分歧时,产品评审会上经常会出现一句话:“但是用户给了我们这个信号”。在这一刻,负责模型的团队和负责客户关系的团队发现,他们对“用户”一词的定义完全不同。
评估集的用户是“谁点击了按钮”的样本加权平均值。NPS 小组的用户是“谁回复了调查”的调查加权平均值,带有显式的群体细分。流失分析的用户是“谁取消了订阅”的群体加权平均值,相对于流量而言,取消最多的群体被过度代表。这三个分布并不相同。它们甚至相去甚远。而评估集的分布是三者中扭曲得最隐蔽的,因为采样机制(一个按钮)不像调查或流失名单那样能产生一个框架。
这是披着产品分析外衣的幸存者偏差。决策是基于那些生存时间足够长、能够参与互动的用户的数据做出的;而那些没有参与互动的用户数据根本不在池中。你会让你的评估集过拟合到一个从结构上就排除了对业务最重要的群体的群体。领导层认为“用户给了我们这个信号”的观点,与“这个信号代表了我们的用户”并不是一回事,混淆这两点的团队正在发布看起来像产品胜利的评估改进,而这些改进针对的是一个日益偏向于最不可能离开的群体的集合。
在运行中捕捉到这一点的最难之处在于,局 部优化是真实的。模型在评估集中的提示词上确实变得更好了。评估集确实积累了不止一个评审员认为高质量的案例。流水线正在运行。但在每个人脚下,流水线采样的群体已经发生了漂移。
弥合差距的模式
纠正措施并非抛弃隐式反馈。隐式反馈是你拥有的规模最大且成本最低的信号来源,而因为隐式反馈存在偏见就拒绝使用它,是那些有预算构建人工标注评估集的产品才能享有的奢侈。纠正的方法是将偏见视为一种可衡量的属性,并围绕它进行治理。
将人群覆盖率(Cohort coverage)作为验收标准。 定义你的产品需要服务的不同人群——企业管理员、超级用户、首周用户、运行对抗性提示词(adversarial prompts)的用户、收入风险最高的界面上的用户——并要求每个评估集(eval set)都将这些人群的覆盖率作为核心统计指标进行发布。新案例的采纳取决于它们是否提高了代表性不足人群的覆盖率,而不仅仅取决于评审员是否给出了高分。一个通过反馈池获取并增加了所需人群覆盖率的案例是可接纳的;而一个通过反馈池获取但恶化了人群平衡的案例,即使它是一个完美的提示词,也应被拒绝。评估集是你想要衡量的世界的样本,验收关口是强制要求样本看起来像真实世界的地方。
严格区分训练信号与评估集录入。 点赞(Thumbs-up)是输入到奖励模型(reward modeling)进行微调的极佳信号。但如果不经转化就直接将其纳入评估集是危险的,因为评估集是你用来检查训练信号是否真的让模型变得更好的工具。 如果循环的两端都采样自同一个有偏见的群体,你就构建了一个自我确认偏好的封闭系统。解决方法是对每一条评估数据建立“监管链”(chain of custody),标明采纳它的真人评审员、来源池以及允许你按来源切分评估数据的标签。一旦评估数据可以按“来自反馈池的数据”与“来自人群覆盖目标的数据”进行切分,关于评估集是否仍能代表客户的讨论就从辞令式的争论转向了可验证的检查。
从流失访谈和高严重度支持工单中抽样对抗性人群。 你的产品面临的最难案例并非来自那些点击点赞的用户。它们来自开启了 P0 工单的用户和流失的账号。养成习惯,将这些交互中的提示词转换为带有群体标签的评估数据,并在每次模型变更时将其作为独立的切片(slice)运行。这个切片能够及早发现偏差,因为它采样了那些反馈从未触及反馈按钮的人群。
为每一条评估数据添加反馈来源标签。 来源溯源(Source provenance)是你可以附加到评估数据中最具杠杆效应的元数据。它能让你询问:在上个季度采纳的数据中,有多少来自反馈池,有多少来自评审员精心策划的添加,有多少来自流失客户?你可以监控这种分布并在发生漂移时发出告警。你可以按来源分解评估得分,并发现趋势是在反馈来源切片上移动(令人怀疑——可能对活跃用户过度拟合),还是在对抗性切片上移动(这才是你真正关心的切片)。
评估集是一个持续治理的产物,而非一次性的语料库。 评估集不是一次建成后就锁定的。它是一个生命体,会随着产品的流量、模型的行为以及业务赖以生存的人群而漂移。持续的评估治理意味着要负责每季度的人群覆盖率审查、每季度的来源构成重新校准,以及每季度淘汰不再代 表实时流量的数据行。如果没有这种纪律,评估集就会变成去年客户的博物馆,而模型的“改进”则是针对一群已经流失的人群进行衡量的。
仪表盘本应显示、但可能并未显示的内容
在这一切成为政策之前,一个有效的诊断方法是询问:你的团队用来讨论评估质量的仪表盘,是否回答了人群漂移(cohort drift)被迫要求回答的问题?
每周评估仪表盘是否在发布总体指标的同时也发布了人群细分数据,还是领导层审查时只能看到总体指标?如果只显示总体指标,人群漂移就会在指标之下悄然发生,其持续时间至少等同于评估指标变动与 NPS 变动之间的滞后期,对于企业级产品来说,这通常长达整整一个季度。
评估集的数据清单是否报告了每一行数据的来源池以及采纳日期?如果没有,你将无法重建评估集是如何漂移的,只能描述其当前状态。
模型变更评审流程是否要求在总体得分之外,还要提供对抗性切片的得分?如果没有,一个让总体得分上升两点但让对抗性切片保持平稳的变更,与一个让两者同时提升的变更在视觉上是无法区分的。然而,这两个变更产生的产品后果却截然不同。
负责评估集的团队是否与负责流失访谈的团队有任何接触?在许多组织中,这两个团队没有共同的产出物、没有共同的评审周期,也没有共同的指标。流失访谈产生的是非评估格式的定性产出。评估团队产生的是与客户离开的定性原因毫无关 联的定量产出。弥合这一差距是产品组织所能采取的最具杠杆效应的行动之一,因为它是最难的案例流入评估集的桥梁。
架构实现
点赞按钮是一种测量设备,其统计特性从未被明确规定,却被连接到一个依赖于这些特性(而实际上这些特性并不符合预期)的评估系统中。每个隐式反馈渠道在某种程度上都具有这种特性,而解决方案并非移除这些渠道,而是要承认收集反馈的行为本身就是一种具有自身偏见特征(bias profile)的抽样机制,并且评估集(eval set)是受这些偏见影响最深的人工制品,因为它最接近闭环。
一个从业者级别的启示:评估集是一个样本,而每个样本都有一个抽样框(frame)。基于隐式反馈的评估抽样框是“在模型响应后点击按钮的用户”,这是一个由参与度(engagement)而非代表性定义的抽样框。基于流失率的评估抽样框是“流失的用户”,这更接近业务关注的群体,但却向相反的方向倾斜。均衡评估的抽样框是你刻意构建的,它具有明确的客群(cohort)目标、来源混合规范,以及将抽样框视为受管人工制品的审查节奏。
如果一个团队在发布下一轮评估改进时没有掌控抽样框,那么他们发布的只是在波动的数据,而那些最重要的客户却在悄然流失。掌控抽样框的团队可以更有信心地论证模型变更,并将这种信心转化为产品成果,因为用于测试变更的评估集是一个测量设备,其偏见已被归类、监控并得到了明确补偿。这就是“认可点击客群的评估”与“代表付费客群的评估”之间的区别。
- https://arxiv.org/pdf/2505.14946
- https://aclanthology.org/2025.emnlp-main.133/
- https://arxiv.org/abs/2504.14716
- https://siliconangle.com/2026/05/17/eval-engineering-missing-piece-agentic-ai-governance/
- https://logiciel.io/blog/llm-eval-harness-internal-build-2026
- https://blog.logrocket.com/product-management/survivorship-bias-guide/
- https://dev.to/ben/the-developer-feedback-you-are-actually-getting-is-survivorship-bias-4b54
- https://www.tonic.ai/blog/prevent-training-data-leakage-ai
- https://www.statsig.com/perspectives/preventingdataleakage
