AI模型表现不佳的原因：如何检查数据集、标注和数据质量

1. 当模型出错时，首先要找出问题出在哪里

当 ML 模型不再达到预期质量时，第一反应往往是检查模型本身：更改架构、调整不同的超参数、增加训练轮数，或尝试更复杂的骨干网络。然而，在重建模型之前，值得先回答一个更简单的问题：它究竟在哪里失败，这些失败有什么共同点？

平均指标只能说明部分情况。模型可能在大多数数据上表现非常好，却在对业务至关重要的一小部分场景中系统性地失败。它可能正确识别大多数产品，却混淆两个视觉上相似的类别。或者它可能在原始测试集上表现良好，却在包装重新设计后性能下降。

诊断不要从“我们如何改进模型？”开始，而要从“模型无法正确处理哪些数据？”开始。

只有在此之后，团队才应决定是需要更改模型本身，还是需要改进训练数据。

整体质量高并不意味着任务已解决

一个很好的例子来自 US-DATA 的一个杂货零售项目。客户已经有一个分析视频并识别产品的 ML 模型。总体而言，系统表现出色——根据项目的内部质量指标约为 96%。但剩余的错误并非随机分布。

模型主要在产品类别视觉上相似的地方失败。其中一个案例是奶酪与黄油。

关键细节是错误不在多边形上。对象轮廓足够准确。错误是语义上的：为图像分配了错误的类别。

这暴露了基础标注 QA 的一个重要局限。团队可以完美验证 Bounding Box 坐标、掩码和多边形，但如果类别标签分配不一致，仍然会提供糟糕的训练数据。

寻找错误模式，而非孤立错误

在这个项目中，模型质量在生产环境中受到监控。产品识别结果与实际结账销售进行对比。这创建了一个额外的控制回路：如果销售点系统显示某商品已售出，AI 就应该记录相应的事件。

当销售统计与 AI 输出开始出现分歧时，客户团队识别出可疑的视频片段并手动审查样本。团队得到的不是“模型以 96% 运行”这样模糊的陈述，而是更有可操作性的信息：哪个产品、在什么条件下、与哪个相邻类别最容易被模型混淆。

随后，有问题的样本被发送给 US-DATA 进行额外标注。这个过程是迭代的：业务数据与 AI 输出之间的差异触发手动审查；确认的困难案例被返回数据集；模型被重新训练并再次评估。

有针对性的重新标注取得了什么成果

团队没有简单地添加更多随机的产品图像，而是专注于模型已经表现出弱点的类别和情境。

经过多次迭代，项目的内部质量指标从约 96% 提升到 99.5% 以上。

原始数据集并非总体上太小。剩余的改进空间集中在模型觉得困难的样本类型上。这就是为什么总数据量和数据对特定模型错误的信息价值必须被视为不同的东西。

如果模型在一个狭窄场景中失败，额外的一万张简单图像可能几乎不会带来改变。几百个精心挑选的困难样本可能更有价值。这种方法通常被称为有针对性的标注。

生产环境不断产生新的困难案例

一个强大的初始数据集最终变得不够用还有另一个原因：现实世界在变化。在同一个零售项目中，US-DATA 处理了大约十个产品类别，而包装设计会定期更新。在某些月份，有 3 到 25 次设计变更。

对一个人来说，重新设计的黄油包装仍然是黄油。对计算机视觉来说，视觉表现可能发生显著变化：颜色、标志位置、字体、产品图像、对比度、装饰元素，甚至包装形状。

因此，ML 系统在首次成功部署后并不会停止演进。生产环境必须继续将新的错误反馈到数据生命周期中。

第一步审计：对错误进行分段

当模型质量不理想时，一个聚合指标是不够的。错误应该被分解成组。

• 哪些类别之间相互混淆？
• 是否存在质量急剧下降的条件——低光照、眩光、另一台摄像头、不寻常的视角、新包装或部分遮挡？
• 模型是否在所有产品上表现相同，还是某个类别明显比其他类别差？
• 失败是否主要在部署后出现？
• 自数据集创建以来，环境本身是否发生了变化？

目标是从“模型不够好”转变为更具体的陈述，例如：“模型在这些条件下混淆类别 A 和 B，而这些样本在训练数据集中代表性不足。”

何时应该调查模型架构

数据并不能解释所有 ML 问题。原因可能是架构、预处理、损失函数、超参数、计算限制，甚至 ML 问题本身的表述。

因此，一个实用的顺序是：定位错误、检查数据和标签、评估困难场景的覆盖范围、验证训练/验证/测试划分，然后才决定是否必须更改模型方法。这可以防止团队花费数周重新设计模型，来弥补实际上存在于少数缺失或错误标注的数据切片中的缺口。

2. 一千张图像还算不上数据集：设计数据覆盖范围

估算未来数据集最常见的方法之一是计算图像数量：“我们需要 10,000 张照片”、“每个类别至少 1,000 个样本”，或“让我们再添加几千帧，模型就会改进”。然而，仅凭图像数量，几乎无法说明这些图像覆盖了多少现实世界。

一个数据集可能包含 10,000 张几乎相同的图像，都是同一产品在相同光照和相同视角下拍摄的。形式上，它很大。但一旦光照改变、对象旋转，或出现不寻常的缺陷，模型就会遇到训练数据中实际上不存在的情况。

因此，数据集设计不仅取决于数量，还取决于对模型在运行中将面临的变异性的覆盖。

数据质量在标注之前就开始了

在一个 US-DATA 项目中，任务是准备训练和验证数据，用于评估产品成熟度和视觉异常的计算机视觉模型。在这种情况下，团队不能简单地接收一个图像档案并开始标注。数据集必须被设计和采集。

US-DATA 的工作人员在现场参与仓库工作：他们帮助组织拍摄区域、准备产品、控制视角和光照条件，并在标注开始前验证图像质量。

这个案例说明了一个重要原则：在某些 ML 项目中，数据工作从标注界面之外就开始了。如果模型必须区分成熟度、表面损伤或缺陷，那么采集过程中的错误可能与标注错误一样有害。

为什么不直接从开源渠道收集图像？

该项目使用了客户的实际产品范围。在目标不是“苹果”这样的通用类别，而是特定 SKU 的状态的任务中，这一点很重要。

在单个 SKU 内，样本可能在色调、大小、形状、表面纹理、特征元素、成熟度和损伤类型上有所不同。品种之间的差异可能更大。

正确的问题不是“我们有多少张苹果图像？”而是“这些图像中代表了哪些苹果变体、在哪些条件下？”

最少 1,000 张图像只是起点

对于每个 SKU，项目要求至少 1,000 张图像。规格说明远不止于此：

• 对象应大致居中于图像中。
• 它应占据画面的 60–90%。
• 背景应统一。
• 对象应从不同视角展示。
• 对象应清晰对焦。
• 图像分辨率应至少为 2 MP。
• 数据集应包含该 SKU 特有的缺陷和状态。

目标不是一千这个数字本身。目标是确保这一千张包含足够的多样性，使模型能够学习稳健的视觉模式。

一个对象必须以多种方式展示给模型

有缺陷的物品受到特别严格的覆盖要求。缺陷必须从多个方向拍摄，包括大约垂直、30° 和 60° 视角，总共至少五个视角。

原因很直接：同一缺陷的可见外观会随相机位置发生显著变化。一个正面看很明显的表面缺陷，从另一个角度看时可能部分消失、融入纹理、落入阴影、改变表观形状，或看起来像正常特征。

光照是数据的一部分，而不仅仅是拍摄条件

项目明确规定了多种照明方案：

• 低照度——大约最高 500 lux，此时阴影细节、对比度和色彩保真度可能下降。
• 正常照度——大约 500 lux 及以上，此时对象和表面细节保持可读。
• 过曝——大约 10,000 lux 及以上，此时局部或强烈高光可能破坏纹理和颜色信息。

目标不是故意制造糟糕的照片。目标是在部署之前，让模型接触到它在生产中可能真实遇到的条件。

甚至光的颜色也很重要

外部光温也受到控制：

对于成熟度评估，这一点尤其重要，因为产品颜色可能是类别信号之一。同一个苹果在冷光和暖光下是物理上相同的对象，但模型接收到略有不同的视觉特征分布。

“覆盖一个 SKU”真正意味着什么

覆盖意味着控制相机、大小和形状、颜色、成熟度、缺陷、视角、光照和光温的组合。能够影响模型性能的因素越多，确保这些变体存在于训练数据中就越重要。

类别平衡也必须被设计

为什么高整体指标可能掩盖严重问题

考虑一个简化的数据集，有 950 个正常产品和只有 50 个有缺陷的产品。一个几乎总是预测“正常”的模型仍然可以产生令人印象深刻的整体分数，却在缺陷检测这一业务关键任务上失败。因此，数据集质量不能仅通过文件数量或单一聚合指标来评估。

至少，团队应该检查类别计数、类内多样性、稀有场景，以及对运营至关重要的少数案例是否得到了足够好的代表。

另一个常见错误是按最容易获得的任何比例来收集数据。可获得性和训练价值不是一回事。

在这个项目中，图像最初被分为两个主要类别：60%“用于订单履行”和 40%“用于核销”。在适用成熟度评估的地方，“用于订单履行”类别进一步分为不太成熟、中等成熟和较成熟阶段，比例大致相等。

这很重要，因为一个由正常产品主导的数据集仍然可以产生令人印象深刻的整体指标，却在业务真正关心的稀有缺陷检测任务上失败。

训练、验证和测试必须真正独立

该项目使用了 80/10/10 的划分。但仅凭比例并不能保证有效的评估。如果同一个苹果的十张几乎相同的图像被随机分配到训练集和测试集中，测试可能衡量的是对已见过对象的识别，而不是对新对象的泛化。

因此，划分需要考虑图像来源和相关性，而不仅仅是随机划分文件名。

元数据将图像文件夹变成可管理的数据集

对于每张图像，项目要求元数据字段：

• filename
• object_type
• ripeness_stage
• defect_type
• angle
• lighting_condition
• split
• light_temperature

这些字段使得提出有用的问题成为可能：测试集中是否代表了低光照？某些缺陷是否只从一个角度可见？冷光是否几乎完全集中在训练集中？哪种缺陷类型导致最多的模型错误？没有元数据，这些问题需要手动检查数千个文件。

近距和远距相机服务于不同目的

该项目使用了两种采集场景。一个至少 2 MP 的近距 RGB 相机提供详细的产品图像，物品占据画面的 60–90%，并具有良好的近焦性能。第二个更远的 RGB-D 相机安装在距离对象约 50 厘米处。

远距相机有不同的作用：采集与生产设置实际观察到的更相似的数据。一个强大的数据集不仅应包含方便的训练图像，还应包含类似于未来生产流的图像。

对象多样性比同一对象的许多帧更有价值

标注团队在流程中的切入点

标注员和 QA 的早期参与有助于在采集数万张图像之前暴露语义问题：正常表面变化在哪里结束、缺陷从哪里开始，成熟度阶段如何划分，一个物品上的多个缺陷应如何处理，以及部分可见的损伤该怎么办。

对于复杂的 CV 项目，数据采集、标注、QA 和 ML 需求作为迭代循环比作为孤立的连续阶段效果更好。

需求明确说明，不需要对同一个物理单元拍摄非常大量的图像。通常更有用的是增加 SKU 内实例之间的变异——不同的大小、颜色、形状、表面纹理和缺陷——以便模型学习类别，而不是记住几个对象。

特征元素也必须同时出现在正常和有缺陷的样本中。对于苹果来说，果梗很容易成为意外的捷径，如果它被系统性地只与一个类别关联。

主要结论

一个好的数据集不能由单一数字来定义。一千、一万或十万张图像并不能保证稳健的性能。重要的是实际代表了哪些对象、状态、缺陷、视角、光照条件、相机和稀有案例。

3. 如果两名标注员对同一对象的看法不同，问题可能出在指南上

标注中最令人不安的情况之一是两个人收到同一张图像却分配不同的标签。直接反应往往是其中一人一定错了。实际上，原因可能更深。

如果对象确实是边界性的，指令不完整，类别重叠，或者缺陷定义过于抽象，那么两名标注员可能都在合乎逻辑地行事——只是根据不同的解释。在这种情况下，问题不是个人质量；而是形式化不足。

好的指南必须回答的不仅仅是“标注什么”

• 对象从哪里开始、到哪里结束？
• 缺陷边界在哪里？
• 什么算作正常？
• 部分可见的元素应如何处理？
• 混合案例应如何解释？
• 如果一个对象符合多个类别怎么办？
• 哪些案例应该上报？

视觉任务越复杂，“标注披萨缺陷”这样的通用指令就越没用。项目必须定义什么是缺陷、它看起来像什么、它的边界在哪里，以及它如何与相似但可接受的产品状态区分开来。

真实案例：披萨标注

在一个 US-DATA 项目中，需要标注来自一家披萨连锁店的超过 100,000 张图像。使用了不同的标注类型。对于饼边、背衬和切口等元素需要掩码或多边形，而缺陷则用 Bounding Box 标注。

问题几乎立即出现。一项要求将缺陷描述为“奶酪未完全融化的区域”。然而，在源图像中，该条件的确切边界并不总是明显，因此团队要求提供更多示例。

饼边也出现了类似问题：一些图像显示面团扭曲，而同一边缘也可能烤过头。那是形状缺陷、烘焙缺陷，还是两者兼有？这类案例不能通过告诉标注员简单地“更仔细一些”来解决。它们需要新的、更明确的规则。

边界案例是任务的一部分，而不是例外

披萨项目推进过程中发生了什么变化

项目规则通过生产标注中的真实问题得到完善。诸如是否标注配料、如何处理异物，以及如何标记可见切口等决定，被转化为明确的指南更新，而不是留在聊天消息或个人记忆中。

如果指南只包含一个明确的正例和一个明确的负例，标注员就必须为中间状态发明缺失的规则。在规模上，这些个人解释会变成系统性的标签噪声。

随着披萨项目的推进，指令得到了完善。例如，团队明确记录了用作配料的奶酪不应被标注为单独对象；画面中的异物应被框出但不分类；可见切口应使用掩码或多边形标记。

这些看起来可能是小细节，但在数万张图像的规模上，它们决定了 ground truth 的一致性和标注决策的可重复性。

标注员不应该需要猜测

一个强大的指南将标注员的角色从解释类别含义转变为应用先前商定的规则。当数十或数百名标注员处理同一数据集时，这一点变得至关重要。

团队不应使用“奶酪融化得不好”这样模糊的陈述，而应努力制定更具可操作性的规则：哪些可见模式算数、受影响区域是什么，以及该条件与正常状态有何不同。数学上的精确并不总是可能，但减少解释空间可以提高一致性。

视觉示例通常比长篇文字更有用

对于视觉标注，一个好的指南通常应至少包含四种类型的示例：明显的正例、明显的负例、边界案例，以及必须上报的案例。

披萨项目表明，个别缺陷缺少示例是澄清请求的直接来源。

披萨项目中的人在回路

目标不是将整个生产流发送给人工。而是将人的注意力保留在人工决策能为模型创造新信息的案例上。

仅仅增加标注员数量并不能解决模糊的指南。如果规则本身不清楚，十名、一百名或一千名标注员只会扩大矛盾标签的规模。必须与劳动力一起扩展的是指南、QA、反馈、上报、版本控制，以及更新指令的流程。

规格需要修订的三个迹象

最昂贵的场景是发现歧义太晚

如果在 500 张图像的试点中发现重叠类别，规则可以低成本地纠正。在 100,000 张图像之后发现同样的歧义，可能需要定位受影响的记录、重新标注、重复 QA、重建数据集，甚至可能重新训练。因此，试点标注和早期团队校准是成本控制工具，而不是形式。

1. 同样的问题反复出现。如果独立的标注员问同样的事情，指南可能不完整。
2. QA 反复纠正同一类型的错误。规则可能不清楚或示例不足。
3. 每次讨论都产生新的例外。这通常意味着分类法或任务表述仍不成熟。

暂停扩展几个小时或几天来完善规则，通常比之后返工数万个标注更便宜。

主要结论

当两名标注员分配不同的标签时，不要自动假设其中一人表现不佳。首先验证规则是否明确、是否存在视觉示例、是否覆盖了边缘案例、类别是否重叠，以及是否有清晰的上报路径。高质量的标注始于整个团队对同一情况采用同一规则。

4. 标注质量控制：除了“对/错”之外还要检查什么

标注审查通常被简化为二元决策：对象标注正确或错误。对于 ML 项目来说，这还不够。一个数据集可能看起来视觉上整洁，却仍然是糟糕的训练材料，因为质量取决于完整性、一致性、平衡性、规则遵循情况和对困难案例的覆盖。

因此，QA 应被设计为生产标注中的持续过程，而不仅仅是对已完成数据集的最终检查。

QA 的九个层次

1. 技术有效性

检查标注在结构上对任务是否有效：Bounding Box 保持在图像内、多边形闭合、掩码未损坏、避免重复对象、坐标有效、类别 ID 存在、文件与图像匹配，以及导出符合所需格式。其中许多检查可以自动化。

2. 完整性

遗漏的稀有对象尤其危险

在数千个常见对象中漏掉一个对象，与漏掉数据集中唯一的稀有缺陷并不等同。QA 工作应根据类别关键性进行调整：对稳定的常见类别进行标准抽样，对稀有缺陷加强审查，对新类别进行双重审查，对有争议的边缘案例进行专家审查。

一个标注可能正确但不完整。如果一张图像包含五个对象，而只有四个被标注，未标注的第五个对象就会成为矛盾的训练信号。QA 不仅要问已标注的是否正确，还要问所有应该标注的是否都已找到。

3. 类别正确性

奶酪与黄油的例子说明了几何 QA 和语义 QA 之间的区别：一个对象可以被正确勾勒轮廓，而类别标签却是错误的。

4. 指南遵循

如果规则在项目中途改变怎么办？

当指南改变时，团队需要知道哪些数据是在每个版本下产生的，以及哪些标注可能受到影响。一个狭窄的边缘案例变更可能只需要重新检查一个子集；核心类别规则的变更可能需要更广泛的审查。这就是为什么标注 QA 和数据集版本管理紧密相连。

一个标签可能总体上合理，却违反了项目特定规则。一个项目可能要求部分可见的对象只有在超过 50% 可见时才标注；另一个项目可能标注任何可见部分。当数据集的不同部分遵循不同规则时，错误就开始了。

5. 标注员间一致性

定期将同一样本交给多名标注员有助于识别规则不稳定的地方。集中的分歧可能表明类别不清楚、示例薄弱、边界模糊、培训不足，或任务本身具有主观性。

6. 几何一致性

对于分割和多边形任务，标注员必须一致地应用边界规则：轮廓跟随的紧密程度、是否包含小突起、如何处理阴影、透明部分和遮挡。

7. 类别平衡

数据集级别的 QA 必须检查类别分布和稀有类别。一个完美标注的数据集如果某个关键类别只有少量样本，仍然可能不够充分。

8. 切片覆盖

整体质量可能掩盖薄弱片段。白天与夜晚、相机 A 与相机 B、旧包装与新包装，或一个地区与另一个地区，可能表现出非常不同的性能。元数据是实现这种切片级 QA 的关键。

9. 黄金集

大型项目受益于一个小型参考数据集，其中包含预先商定的标签、困难案例和专家决策。黄金集可用于培训新标注员、监控当前团队、校准 QA，以及在指南变更后验证行为。

QA 应在项目期间运行，而不是在项目之后

最昂贵的错误之一是标注完整数量后才开始验证。更安全的流程从试点批次开始——例如约 500 张图像——更新规则，扩展到几千张，然后才进一步扩展。目的是在系统性错误变成数万个错误标注之前发现它们。

多级 QA 工作流

1. 标注员——执行标注。
2. 自动验证——检查格式、坐标、类别 ID、缺失文件，以及空标注。
3. 审查员——对高风险类别验证样本或完整数量。
4. 高级 QA——解决困难和有争议的案例。
5. 领域专家——决定语义上困难的问题。
6. 数据集级验证——检查整个数据集的结构和覆盖范围。

并非数据集的每个部分都需要相同深度的审查

QA 必须创建反馈回路

如果审查员默默修复标注，同样的错误会再次出现。成熟的 QA 流程会识别原因，必要时更新规则，向团队提供反馈，并重新检查受影响的片段。“标注员犯了错误”远不如“指南没有定义如何处理遮挡超过 50% 的对象”有用。

基于风险的 QA 根据数据的重要性和不确定性分配审查工作。简单图像可以抽样；新标注员可能获得更高的 QA 率；新类别或稀有缺陷可能获得几乎完整的审查；边缘案例可能需要专家。

QA 还必须创建反馈。如果审查员只修复标注而从不沟通原因，同样的错误会再次出现。成熟的流程会对原因进行分类，必要时更新规则，通知团队，并重新检查受影响的片段。

将数据集交给 ML 之前的检查清单

最重要的 QA 问题

不要只问“我们检查了百分之多少的标注？”要问“还有哪些错误可能漏过，它们对模型会有多危险？”

对于生产 ML，简单对象上 99% 的正确