AI 数据质量是领域问题，而非代码问题

AI 行业中有一种根深蒂固的信念，认为数据质量是一个工程挑战。构建更好的流水线、编写更多的验证规则、添加自动化质量检查、部署统计异常检测。如果数据不好，这种思维认为，是代码不够好。

这种信念是错误的。数据质量从根本上是一个领域知识问题。无论工程多么精妙，都无法弥补对数据含义的理解不足——哪些值是正确的，以及在你试图解决的特定问题中"质量"究竟意味着什么。

流水线的幻觉

假设一家公司正在构建一个按紧急程度分类客户支持工单的模型。他们的数据工程非常出色：

• 从5个工单来源自动采集
• 使用模糊匹配进行去重，相似度阈值为 0.92
• Schema 验证确保所有必填字段存在
• 统计检查标记文本长度和响应时间的异常值
• 自动化训练/测试集拆分并进行分层抽样

流水线很干净，代码很健壮。模型在 50,000 个工单上训练，在紧急程度分类上达到了 73% 的准确率。

问题不在流水线。问题在于"紧急「、」高优先级「和」正常「的标注标准是由一位从未在客户支持领域工作过的 ML 工程师定义的。在他的 schema 中，一个影响 3 个用户的生产故障工单是」高优先级「。而在支持团队的实际分诊框架中，它是」紧急"——因为这 3 个用户是企业计划用户，有 SLA 约定，超过 2 小时将触发经济处罚。

流水线完美地处理了数据。只是处理的数据标签是错误的。

代码无法解决的问题

有几类特定的数据质量问题是任何工程方案都无法解决的：

错误的标注标准。 如果你分类 schema 中"正例「和」反例"的定义与真实世界的决策边界不匹配，每个标签都可能是错误的——但没有验证规则能检测到这一点。标签内部一致、格式正确、统计分布合理。它们只是错了。

一个具体的例子：一个医学影像团队为肺炎检测标注胸部 X 光片。他们的标注指南说"如果肺野中存在阴影就标注为阳性"。放射科医生会告诉他们，肺野中 15-20% 的阴影不是肺炎——它们是肺不张、胸腔积液或伪影。标签通过了每一项质量检查。模型学会了检测阴影，而不是肺炎。

错误的去重决策。 去重算法可以识别两条记录是相似的。但它无法确定哪条是正确的。当一个客户在数据集中出现两次，地址略有不同时，算法可以标记重复。但它不知道一个地址是客户的家，另一个是办公室，而正确的地址取决于使用场景。

我们曾与一家金融服务团队合作，他们对交易记录使用了自动去重。算法合并了金额相同且时间戳相近的记录，将它们视为重复。实际上，8% 的"重复"是合法的独立交易——同一天向同一收款人进行的两笔 4,500 美元电汇，用于不同的发票。去重减少了数据集大小，但也通过删除真实数据降低了模型准确率。

对数据语义的误解。 一个标记为"completion_date"的字段在不同上下文中可能有不同含义：系统中标记任务完成的日期、工作实际完成的日期，或主管验证完成的日期。使用错误的解释会引入系统性误差，而没有验证规则能捕获这一点，因为数据类型和格式是正确的。

依赖上下文的质量标准。 在某些领域，"足够好「的数据质量取决于具体应用。客户名字拼错为」Jonh「而非」John"，对推荐系统来说是可以接受的，但对需要将姓名与制裁名单匹配的合规筛查模型来说是不可接受的。不考虑应用上下文的质量评分会产生误导性的置信度。

重要的领域知识

数据质量决策需要三种代码所不具备的领域知识：

语义知识。 理解数据值在上下文中的含义。ML 工程师看到一个值域为 0-10 的字段，将其视为连续数值特征。领域专家知道 1-3 是"正常「，4-6 是」升高「，7-10 是」危急"——而类别之间的阈值正是模型决策最关键的地方。

操作知识。 了解数据是如何收集的以及其局限性。领域专家知道制造日志中的周末条目不太可靠，因为初级操作员是在周一凭记忆填写的。ML 工程师则平等对待所有行。

后果知识。 了解模型出错时会发生什么。领域专家知道对某类交易的误分类有监管影响，而对另一类的误分类只是带来不便。这些知识应该影响你对数据集中不同部分的清洗、验证和平衡的激进程度。

真正的质量流程

有效的数据质量不是在代码流水线上撒一些领域知识。它是一个以领域驱动的流程，由代码支持执行。

第一步：领域专家定义质量标准。 在任何代码运行之前，领域专家指定每个标签的"正确"含义、存在哪些边缘情况以及如何处理模糊样本。这不是一个一小时的会议。这是一个迭代过程，通常需要 1-2 周的讨论、示例审查和标准细化。

第二步：领域专家标注种子数据集。 由领域专家标注的一小组样本（200-500 个）建立了基准真值。这个种子数据集作为质量基准，用于衡量所有后续标签和模型输出。

第三步：质量指标参照领域判断。 标注者间一致性、标签分布分析和边缘案例审查都参照领域专家的种子标签来衡量。如果自动化质量检查标记一批标签有问题，由领域专家——而非 ML 工程师——调查并确定问题是标注错误还是合理的分布偏移。

第四步：领域专家审查模型错误。 当模型误分类样本时，领域专家检查误分类，以确定错误源于训练数据不足、标签错误、标准模糊，还是模型本不应处理的真正边缘情况。

这个过程要求领域专家直接与数据和标注工具交互。如果领域专家只能通过会议和 Slack 消息参与，流程就会退化为代理标注——而这正是质量问题的根源。

犯错的代价

将数据质量视为工程问题的组织，在模型开发上的花费是将其视为领域问题的组织的 2-3 倍。原因如下：

更多的训练轮次。 当标签存在细微错误时，模型准确率会停滞在一个看似可以改进但抵抗一切工程干预的水平——更多数据、更好的架构、更长的训练。团队迭代数周甚至数月，才最终有人质疑标签。

延迟部署。 在领域错误数据上训练的模型，其失败方式与在噪声数据上训练的模型不同。噪声数据产生均匀的性能下降。领域错误数据在特定类别上产生高置信度的错误——模型对它错误的案例非常确定。这些高置信度的错误往往在用户验收测试期间才被发现，需要重新开始数据收集流程。

信任侵蚀。 当模型在领域特定案例上自信地误分类时，领域专家会对 AI 工具整体失去信心。重建信任的成本远高于一开始就做对。

Andrew Ng 的数据中心化 AI 研究表明，领域专家进行的系统性标签修正平均可将模型性能提升 5-15%——超过大多数架构变更。质量存在于数据中，而非模型中。

让领域专家掌握主导权

当领域专家能够直接检查、标注、验证和纠正训练数据时，数据质量就会提升。这需要对没有 ML 工程技能的人也友好的工具。

Ertas Data Suite 就是为此而构建的。它是一个原生桌面应用程序，领域专家可以直接处理数据——定义标签 schema、应用标签、审查质量指标和纠正错误——无需编写代码或操作技术基础设施。数据保留在他们的本地机器上。界面使用领域术语，而非 ML 术语。

ML 团队获得更好的数据。领域专家保持对质量的控制权。模型在反映真正领域知识的标签上训练，而不是工程师的最佳猜测。

数据质量是一个领域问题。工具应该让领域专家来解决它。