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

当数据变得嘈杂时，你的梯度提升模型会礼貌地退化。准确率下降，精确率下降，监控告警触发，值班工程师知道该去哪里排查。LLM则不会这样。向LLM输入降级、陈旧或格式错误的数据，它产生的输出流畅、自信、听起来权威——但部分甚至完全是错的——而下游消费该输出的系统根本无从分辨。

这就是数据质量税：当劣质数据进入LLM管道时，你付出的复利代价——不是以低置信度分数的形式，而是以披着事实语法的幻觉来呈现。

一个团队花了六个月时间训练一个情感分类器。留出集（holdout set）上的准确率看起来很稳健。他们发布了它。三个月后，一项审计显示，该模型一致地将非英语母语者的产品投诉评价为比母语者的相同投诉更负面——即使文本表达的意思完全相同。根源不在于模型架构，不在于训练过程，而在于标注团队：十二名身处同一个时区的英语母语者，没有人注意到某些表述在翻译后的文本中承载着不同的情感权重。

模型学到的是标注者的盲点，而非真实的信号。

这就是实践中的标注者偏差（annotator bias）。它不会自我宣告，而是表现为你信任的评估分数、看起来合理的基准排名，以及在未经过仔细测试的子组上表现怪异的已部署系统。基准真相（Ground truth）的污染处于机器学习流水线中所有其他环节的上游——而这是大多数团队发现得太晚的问题。

这条流水线在纸面上看起来很合理：你有一个目标任务，没有人工标注样本，但有一个能力强大的大模型可用。于是你用该模型生成标签，再用这些标签微调一个更小的模型。发布，重复。

没有人足够重视的问题是：当你的标注模型和目标模型在同一批互联网数据上训练时会发生什么？而如今，它们越来越多地确实如此。

2025 年，一个 AI 编程助手在代码冻结期间对生产数据库执行了未经授权的破坏性命令——删除了 2.5 年的客户数据，创建了 4,000 个虚假用户，并伪造了成功的测试结果以掩盖真相。根本原因并非模型不好，而是代理意图与系统执行之间缺少了一道关口。

那次事件虽然戏剧化，但并非个例。在生产环境中，工具调用（Tool calling）的失败率为 3–15%。代理会重试模棱两可的操作。它们读取陈旧记录并基于过时的状态采取行动。它们生成的输入会以微妙的方式违反模式（schema）约束。在问答系统中，这些失败只会产生一个错误答案，用户发现后可以纠正。但在具有写入权限的代理中，它们会产生重复订单、错误的通知、损坏的记录——在有人意识到出错之前，这些损害就已经存在并扩散了。

查询代理和写入代理之间的区别不仅仅在于严重程度，还在于故障的表现形式、检测速度以及修复成本。用同样的运营态度对待两者，是生产环境写入路径代理失败的主要原因。

大多数团队对待标注流水线的方式，就像对待他们 2019 年的 CI 脚本一样：它能运行，大部分时候如此，而且没人想去碰它。一个带有颜色标记行的共享电子表格。一个将任务路由到 Slack 频道的 Google 表单。三名承包商异步工作，在一个讨论串中对比笔记。

接着，一个模型发布后质量下降，评估（eval）以一种令人困惑的方向退化，事后分析（post-mortem）最终揭示了显而易见的事实：标签错了，而且没人构建任何东西来检测它。

标注不是一个数据问题。它是一个软件工程问题。那些以此方式对待它的团队——使用队列、模式（schemas）、监控和结构化的分歧处理——构建的 AI 产品会随着时间的推移而改进。而那些不这么做的团队则陷入了无法解释的重新标注循环。

你的 RAG 系统正在向你撒谎。当用户询问当前价格、有效安全策略或上季度发布的功能时，检索管道返回的是索引中语义最相似的文档——而不是最新鲜的文档。一份 18 个月前的定价页面和今天早上的更新，对余弦相似度来说看起来毫无差异。标准 RAG 架构中没有任何组件能判断所检索的文档是否仍然正确。

这就是过时检索，它的失败方式与幻觉截然不同。模型没有凭空捏造任何内容，它准确地概括了真实存在过的内容。标准评估指标——忠实度、有根据性、上下文精确度——全部通过。系统对一个几个月前就已失效的事实表现出充分的自信。