20 篇博文 含有标签「data-quality」

最危险的 eval set 是那些依然能通过测试的。变红的 regression suite 会引起关注：有人会打开失败的案例进行争论、修复 Bug 或更新预期。绿色的 suite 则会赢得信任。而这种信任恰恰是失效的 eval set 不配拥有的，因为得分保持绿色并非因为你的系统足够好，而是因为测试已经不再反映用户的真实行为。

这是 AI 评估中一种隐蔽的失败模式。你构建了一个 golden dataset —— 几百个精心标记的案例，代表了产品的工作任务。它能在一整个季度里发挥作用。每次部署都会运行它，每个分数都是绿色，每个人都睡得很香。与此同时，产品发布了三个新功能，企业级流量从查询量的 10% 攀升至 45%，用户开始以 18 个月前团队中没人写过的方式来表达请求。eval set 对此一无所知。它继续根据一个已经不存在的分布对模型进行评分。

一个检索增强生成（RAG）管道可能会连续数周出现性能退化，而没有任何指标能察觉到。相关性评分看起来正常，检索延迟没有变化。触及受损主题的评估切片（eval slice）向错误方向移动了 0.25 个点，而你的每周审查将其归因于噪声。直到有人阅读了模型为某个客户工单实际接收到的上下文窗口，发现同一个段落出现了三次——一次是标题格式，一次是小写格式，一次是去除了标点的格式——你才意识到，一个月以来，你的前五名（top-five）在暗地里其实只是前二名。

这类故障的特点是：系统完全在按照指令行事。检索器正在返回与查询最相似的向量。这些向量中的每一个都确实与正确的主题相关。索引根本不知道其中三个向量来自同一个段落（只是以三种方式索引了三次），因为原本应该捕获这种情况的入库阶段去重环节正在静默跳过它。

预发布环境界面（staging UI）里的点踩（thumbs-down）按钮原本只有一个作用：告诉值班工程师哪个回复看起来很糟，以便他们去排查。六个月后，模型团队的某个人把“所有带有修正建议的生产反馈”拉取到一个 Parquet 文件中，并针对它运行了一个微调（SFT）任务。评估集在三个指标上有所提升，却在五个指标上悄悄退步。没人能解释原因，直到有人翻看标签并发现修正列中有一行写着：“这没问题，但我讨厌它的措辞方式。”模型习得了这种观点。然后，它又习得了另外四万个观点。

这种失效模式源于调试界面和标注界面是同一个界面。工程师点击“点踩”可能是因为某个环节坏了，或者看起来很奇怪，或者他们正准备提交一个工单，或者排版让他们不爽，甚至只是为了测试按钮是否好用。从那次点击中流出的信号混合了“这个输出是错误的”、“这个输出是对的但很难看”、“我不喜欢这个”以及“我当时很无聊”。作为单一标签，它什么也证明不了。以此进行训练，它教会模型的是所有这些情绪的并集。

某家保险公司用一整年的客服对话记录微调了一个支持模型。上线不到一周,合规审查员就发现了怪事:这个机器人一直把 "deductible"(免赔额)写成 "deductable"。不是偶尔出错——而是每八条出现该词的消息里,大约都会有一条这样写。模型并没有自己发明这个拼写错误。它继承了这个错误。一小撮一线客服两年来一直这么打字,而语料库忠实地反映了他们打的内容,不是字典里的内容。

这就是在运营数据上做监督式微调最令人不安的地方:模型并不是在学习你的领域,它是在学习你的语料库。这两者有重叠,但并不等同,而那道缝隙正是每一个本可预防的行为缺陷藏身的地方。训练数据里的频率并不是正确性的信号,它只是一个信号——告诉你你的团队恰好做某件事做得够多,多到模型愿意模仿。

错别字是最容易识别的情形。难的是那些没人愿意写成规则的部分,因为大家都默认模型会学到工作的"专业"版本,而不是工作被实际执行的样子。

你需要更多的训练数据，于是你生成了它们。模型编写了几千个例子来填补数据集中的空白——边缘案例、代表性不足的意图，以及你真实日志从未涵盖的长尾数据。你抽检了一个样本。每个例子看起来都不错：语法正确、符合主题、标签准确。你将这一批数据加入到微调集中，然后继续工作。

三轮迭代之后，你的模型在那些你特意生成数据来覆盖的案例上表现反而变差了。并不是灾难性的变差——只是悄无声息地、均匀地变得平庸。以前偶尔能奏效的稀有意图现在完全失效了。用户实际输入的措辞被误读。而你的质量检查中没有任何一项发现异常，因为你生成的每一个独立案例确实都很正常。

失败不在于任何单个案例，而在于分布。合成数据在没有现实锚点的情况下被生成和反复生成，会向均值收缩——而长尾部分，即你求助于合成数据的根本原因，是首先消失的部分。

你的团队启用模式约束解码（schema-constrained decoding）的那一天感觉像是一个里程碑。解析错误停止了。JSONDecodeError 警报消失了。从文本中抓取字段的脆弱正则表达式也被删除了。有人在站会上说“模型现在返回有效的 JSON 了”，结构化输出的任务单随之关闭。

那句话正是麻烦的开始。“模型现在返回有效的 JSON 了”是正确性工作的开始，而不是结束。JSON 模式和约束解码保证了响应的形状（shape）——即 quantity 是一个整数，status 是三个枚举值之一，对象包含你要求的键。它们完全无法保证 quantity 是否是正确的数字，status 是否反映了真实发生的情况，或者 sku 字段是否指向了目录中存在的商品。

你的 RAG 系统很可能正在把自己的输出编入索引。只是你还不知道而已。

一切往往从一件看似无害的事开始：有人把一份季度总结文档添加到了知识库。而这份总结，正是由查询该知识库的同一个 LLM 生成的。六个月后，开发者又加入了 AI 生成的版本说明，随后是自动生成的支持 FAQ，再然后是合成的入职指南。这些文档没有任何一份被标注为 AI 生成。对于检索系统而言，它们与人工撰写的一手资料看起来别无二致。于是，当你的模型检索上下文来回答问题时，其中相当一部分上下文是之前某次模型运行所输出的压缩版、甚至可能已经失真的结果——而你的准确率指标依然绿灯常亮。

这就是溯源债务：在检索语料库中，AI 生成的内容在没有来源标记的情况下不断累积，形成一个反馈循环——每一代模型的输出，都成为下一代模型的原始素材。

你的推荐模型在三个月前上线了。点击率增长了 18%。观看时长在不断攀升。仪表盘上一片飘绿。领导层很满意。

而你的模型正在悄悄地破坏它将用于训练下一个版本的数据。

这就是训练数据自中毒（training data self-poisoning）：一种反馈循环，其中已部署的 AI 功能会改变用户行为，其方式破坏了模型最初训练时学习的交互数据。最糟糕的是，你的标准参与度指标会告诉你一切正常 —— 直到它们失效的那一刻。

大多数团队在反馈采集端的检测体系都非常完善。点击“踩”的操作会被记录，星级评分会流入仪表板，人工标注任务会将每一组偏好对写入表格。数据摄入过程干净、带有时间戳且可查询。

在采集到反馈与下一次模型更新之间所发生的一切，对大多数团队来说都是一个黑盒。

数据被过滤。某些标注的权重被调高。稀有类别被上采样。近重复项被删除。提示词模板的更改导致上个月的标签与本月的不一致，但合并依然在进行。当信号到达奖励模型或微调任务时，它已经通过了 6 个转换步骤，没有审计追踪，没有版本锚定，也无法将退化的模型权重溯源到流水线中特定的损坏点。

这就是反馈溯源鸿沟（Feedback Provenance Gap）：团队知道反馈从何处进入系统，但不知道它在塑造模型行为之前变成了什么。

我认识的一个团队花了六个月的时间去追踪一个并不存在的回归 (regression)。每一次发布都通过了评估 (eval)。每一次发布都上线了。但每个季度，AI 服务群组的 NPS 都会下降一个点。最终，一名实习生在对黄金数据集 (gold dataset) 进行例行审计时发现，一名早已离职的合同标注员标注了 11% 的数据项，而这些项在团队一直试图修复的一个特定故障模式上，系统性地表现得更加宽松。评估结果显示模型正在变好。但模型并没有变好。评估结果被一个人的校准漂移悄悄地倾斜了，而没有人监督标注员，因为没有人认为标注员是一个威胁面。

这就是评估集毒丸 (eval-set poison pill)。大多数团队将他们的评估集视为一个值得信赖的产物：标签是由人类评分的，数据来自生产环境，而回归仪表盘是组织在发布时一致同意参考的唯一指标。但标注流水线是一个人类供应链，而人类供应链是可以被操纵的。如果不对评估集的输入应用供应链卫生管理，就将其视为真值 (ground truth)，那么你就是在信任一个你无法辩护其来源 (provenance) 的数字。

你的评估套件通过了。质量仪表板显示为绿色。一周后，用户正在悄悄流失，没人能解释原因。评估集并没有通过犯错来撒谎——它的谎言在于它是一面镜子。你用来评分的标签，可以追溯到正是由你试图评估的那个模型家族生成或过滤的。通过这项评估并不是质量的证明。它证明了你的模型与其过去的输出是一致的。

这是成熟 LLM 流水线中一种隐蔽的失败模式：通过生产泄漏导致的评估集污染。这不同于著名的基准测试污染（即在 GSM8K 上训练的模型又在 GSM8K 上进行评分）——那个故事已经被讲烂了。更微妙的一种发生在下游。你的黄金标签来自用户反馈、来自先看到模型草稿的人类标注员、来自 RLHF 奖励追踪、来自 LLM-as-judge（模型即评委）的偏好数据。这些流水线中的每一个都将当前模型习语的指纹带回到了你的“基准真值”中。几个季度下来，测试集悄悄地记住了你模型的偏好，评估变成了一个自我表扬的循环。

每位产品负责人都听过这个论调：更多用户产生更多数据，更好的数据训练更好的模型，更好的模型吸引更多用户。数据飞轮是复利护城河，这正是AI巨头们能够赢得市场的原因。

这个论调并没有错。但实施几乎总是出了问题。在实践中，大多数数据飞轮都有多个泄漏点——反馈循环看似在运转，实际上却在放大偏差、强化陈旧模式，或者优化一个与真实目标背道而驰的代理指标。构建这些系统的工程师很少知道自己遇到的是哪种泄漏，因为所有泄漏从外部看起来都一样：参与度上升，模型在可测量的指标上持续改进，而系统却在难以归因的方式下变得越来越没用。

这就是数据飞轮陷阱。理解其失败模式，是构建真正有效飞轮的前提。