机器学习数据收集综述：从大数据与 AI 集成视角

关联论文：1811.03402
作者：spark
更新：2026-07-26

一句话结论

这篇综述第一次把"机器学习中的数据收集"放在数据管理（database / data management）视角下系统化，把它拆成数据获取（Data Acquisition）、数据标注（Data Labeling）、已有数据/模型的改进（Data/Model Improvement）三大阶段，给出了每个阶段的 research landscape、决策指南和未来挑战，是把 ML 与 data systems 真正打通的一份"地图式"survey。

它到底在解决什么真问题

2018 年前后，深度学习在视觉、NLP、语音等任务上全面铺开，但一个尴尬的事实浮出水面：模型的天花板几乎被数据卡死。这篇论文把"为什么数据突然变成瓶颈"归纳为两条：

新场景没有现成标签：医疗影像、工业质检、低资源语言、长尾推荐——传统 ImageNet/COCO 那一套帮不上忙，监督信号要么贵、要么根本没有。
深度学习自动学特征 = 要更多数据来换：特征工程省了，可标签和样本的消耗急剧上升。换句话说，"数据饥渴"是深度学习时代结构性的，不是工程细节。

更麻烦的是，过去 ML 圈和数据管理圈是各干各的：CS 的人写 active learning、semi-supervised，数据圈的人写 crowdsourcing operator、data integration。两边对同一件事用了不同词汇、对齐很差。Roh 等人这篇 survey 的核心贡献，就是强行把这两边缝合到同一个分类法里——从数据管理的眼睛看 ML 的数据问题。

核心方法：一张统一的分类法

论文的核心方法不是算法，而是一个双层 taxonomy + 决策指南。

顶层三分：Data Collection 的三个阶段

Data Collection
├── 1. Data Acquisition   (数据从哪儿来)
│     ├── 1.1 Data Augmentation    已有数据 → 更多数据
│     ├── 1.2 Data Generation      合成新数据（GAN/Simulation）
│     └── 1.3 Data Acquisition     从外部获取原始数据（爬取/采购/IoT）
│
├── 2. Data Labeling       (标签从哪儿来)
│     ├── 2.1 Crowdsourcing        众包（MTurk/Amazon Mechanical Turk）
│     ├── 2.2 Expert Labeling      领域专家标注
│     ├── 2.3 Automatic Labeling   用已有模型/规则打伪标签
│     └── 2.4 Weak Supervision     启发式/编程式标签（Snorkel 系）
│
└── 3. Data/Model Improvement  (已有数据/模型怎么变好)
      ├── 3.1 Feature Engineering（传统）
      ├── 3.2 Data Cleaning        去噪/纠错
      ├── 3.3 Active Learning      挑最有价值的样本问
      ├── 3.4 Semi-Supervised Learning
      └── 3.5 Transfer Learning / Pretraining

第二层：每个阶段的决策维度

每一节里，作者又按"输入 / 输出 / 适用场景 / 计算开销 / 何时不用"展开做对比，并且给出If-Then 决策表，例如：

数据少 + 任务敏感（医疗）→ 先看 transfer learning / pretrained backbone 是否能用，再考虑 expert labeling 而不是众包；
标签贵 + 任务可以模糊 → weak supervision + 自动标注流水线；
数据分布长尾 → active learning 优先挑边界样本，避免众包浪费在简单样本上。

这种写法对工程团队特别友好——你可以直接拿着这张表去选方案。

关键洞察：把数据管理当一等公民

论文最锋利的观点，是把数据库社区的若干概念正式"翻译"进 ML：

Provenance / Lineage：训练样本的来源、可追溯性、是否合规（GDPR 之后的命门）；
Data Quality / Cleaning：脏数据不再只是 ETL 阶段的事，训练前必须有 cleaning pipeline；
Query-based Data Acquisition：把"按需采数据"建模为查询（而非一次性 dump），这对 IoT/边缘场景至关重要；
Crowdsourcing Operators：把众包当成数据库算子来优化——Qurk/CrowdDB 这类系统被纳入版图。

关键内容与数据

论文本身是 20 页 survey（Roh, Heo, Whang 等，v1 2018-11-08，v2 2019-08-12），覆盖 100+ 篇参考文献。从 paper card 与第三方索引可见：

被引（OpenAlex）：152；tavily/Google Scholar 口径下被引约 1500+，两个口径差异极大，这是早期高被引 survey 的常见现象（数据库索引收录滞后）。
主分类：engineering；主题：database；形态：survey。
作者机构：Yuji Roh、Steven Whang 等，主要来自 Korea 的数据管理与 ML 跨学科团队（具体单位原文未明确列出在 abstract 中）。
核心贡献：把"数据获取 + 标注 + 改进"三条主线对齐到一个分类法，并显式讨论 Big Data × AI integration 这一更大的研究浪潮。

亮点

跨学科桥梁：第一次让 database 圈的人系统读到 ML 数据问题，让 ML 圈的人系统读到 database 圈的工具（如 Qurk、Snorkel、CrowdDB）。后续大量工作直接以它的分类法作为出发点。
决策导向而非纯文献罗列：每个分支都给了"If-Then"建议，工程可读性极强。
覆盖了 2018 之前的关键技术：data augmentation、GAN-based generation、active learning、weak supervision、crowdsourcing，基本上把后来被纳入"data-centric AI"的所有思想都预先梳理了一遍。
明确指出了 future directions：data acquisition cost、隐私下的数据获取、标注质量度量、自动标注的反馈循环等——这些方向在 2023 年 LLM 时代全部变成热门议题（self-instruct、RLAIF、合成数据治理）。

局限

时间点限制：2018 年成文，没有覆盖后来的 self-supervised pretraining（BERT/GPT-2 之后）、instruction tuning、RLHF、RAG 时代的数据策略；很多思想被后来者重新"发现"。
对结构化数据/数据库的覆盖较重，对 CV 数据的覆盖相对薄：今天回头看，CV 的数据增强（CutMix、MixUp）和最近 diffusion 合成数据治理，并没有被纳入这个分类法。
实验部分缺失：作为 survey 没有自跑 benchmark，方法对比的可信度依赖二手引用。
"Data Acquisition"小节对隐私/合规只是点到为止：GDPR 落地之后这一节需要大改，今天看是过时的。

对工程落地的启发

建一个数据 lineage 系统：哪怕是个 CSV + wiki，把每个训练样本的来源、采集时间、合规状态记下来。这一步在生产环境被严重低估。
数据流水线分三层：acquisition（采集/合成/扩增）→ labeling（众包/弱监督/自动）→ improvement（清洗/active/迁移）。每层独立评估 ROI。
标注预算的分配应该用决策表，而不是经验：脏数据 > 70% 时投入清洗；标签噪声 > 30% 时投入弱监督/自动标注；样本不足且分布长尾时投入 active learning。
不要把"数据收集"当作一次性工程：Roh 等人早在 2018 年就强调它是个连续闭环（model 跑出来 → 看失败 case → 回去补数据 → 再训）。今天 LLM 时代的 data flywheel、self-instruct、synthetic data 都在重复这条主线，只是工具换了。

与同方向工作的关系

上游/同期：Snorkel（weak supervision）、Qurk / CrowdDB（crowdsourcing operators）、active learning 经典综述（Settles 2010）。本文把这些串成一张图。
下游：
Data-centric AI（Andrew Ng 2021 起的系列演讲）几乎是这篇 survey 的"工业界 2.0 版"——同样的分类法，更工程化的口号。
LLM 时代的 self-instruct / constitutional AI / RLAIF，可以看成"automatic labeling"分支的极端形态——用一个超大模型给另一个超大模型造数据。
合成数据治理（synthetic data governance）、data provenance for LLMs：本文 3.1 data acquisition 的现代延伸。
区别于同方向：相比 A Survey on Transfer Learning（传统 ML 视角）和 Foundation Models survey（模型视角），本文是从数据视角切入的，更关心 pipeline 而不是模型架构。

适合谁读

数据平台工程师 / MLOps：直接拿它的分类法搭自己的 data collection 子系统。
ML 研究者：想知道"为什么我的模型再涨不动了"时，回头读它会意识到 70% 的瓶颈在数据，不在模型。
产品经理 / 数据负责人：理解数据成本结构（采集、标注、清洗各占多少）的入门地图。
隐私/合规负责人：了解 lineage / provenance 这条线索在 ML 语境下的位置。

不确定处

被引数：OpenAlex = 152，tavily/Google Scholar 口径约 1500+，差异巨大。文中采用 OpenAlex 152 为基准，标注 tavily 口径作参考。
作者具体机构（abstract 未列，原文 PDF 才完整）——原文未明确。
"Big Data -- AI Integration"作为一个更大研究浪潮的具体边界，原文未明确给出统一术语，部分读者会按 data-centric AI 或 MLOps 来对应。

工程落地与核查（Jay）

一、事实核查笔记

arXiv ID 1811.03402：已在 arXiv.org 验证，标题为 "A Survey on Data Collection for Machine Learning: a Big Data -- AI Integration Perspective"，Roh, Heo, Whang 等 ✅
v1 2018-11-08，v2 2019-08-12：arXiv 版本记录核实 ✅；SIGMOD Record 出版为 2019 年（建议查阅原文 DOI 确认）
OpenAlex 被引 152：2026 年 OpenAlex 数据核实为 152 次，合理；tavily/GS 口径 1500+ 属第三方统计差异，与 OpenAlex 收录策略不同（数据库论文索引滞后），两个数字不矛盾 ✅
「100+ 篇参考文献」：综述原文引 100+ 篇，时间窗截止 2018；2023 年后的 LLM 数据策略（RLAIF、合成数据）不在引用范围内，解读未超出原文边界 ✅
「Yuji Roh 等主要来自 Korea 的数据管理与 ML 跨学科团队」：原文 abstract 未列具体单位；SIGMOD Record 原文 PDF 注明作者来自 KAIST（Korea Advanced Institute of Science and Technology）等机构——解读中未明确标注，存疑但非错误
原survey无自跑实验：作为 survey 论文，方法对比依赖二手引用，无 benchmark 数据，解读中已诚实说明「实验部分缺失」✅

二、最小可跑流水线（Data Collection 三层实现）

以下展示一个最小化 Data Acquisition → Labeling → Improvement 流水线示例，验证本文分类法的工程可行性：

# === Layer 1: Data Acquisition ===
# 1a) 合成数据（GAN扩增，CIFAR-10 猫/狗二分类举例）
python generate_synthetic.py \
  --model BigGAN --class_idx 3,5 \
  --n_samples 5000 --out_dir ./data/synthetic

# 1b) 主动采集（IoT/爬取场景）
# 假设已有爬虫输出 images/ 和 metadata.jsonl
python deduplicate.py \
  --input images/ --metadata metadata.jsonl \
  --hash_type phash --threshold 0.9 \
  --out_clean images_clean/

# === Layer 2: Data Labeling（Weak Supervision + Active Learning）===
# 2a) 用 Snorkel 打编程式弱标签（文本分类举例）
python snorkel_labeling.py \
  --labeling_functions lfs/ \
  --train_data train_raw.csv \
  --out_labels train_labels.parquet

# 2b) Active Learning：挑不确定性最高的样本送标
python active_learning.py \
  --model classifier_model.pth \
  --unlabeled_pool test_unlabeled.parquet \
  --strategy uncertainty \
  --budget 500 \
  --out_query selected_for_labeling.csv

# === Layer 3: Data/Model Improvement ===
# 3a) 清洗（去噪 / 纠正标签错误）
python clean_labels.py \
  --labels train_labels.parquet \
  --method cross_entropy_filter --threshold 0.3 \
  --out clean_labels.parquet

# 3b) Active Learning 补标后重新训练
python retrain.py \
  --model classifier_model.pth \
  --data clean_labels.parquet \
  --out_model classifier_v2.pth

三、工程坑位清单

坑位	描述	解决方案
数据 lineage 缺失	生产环境中样本来源混乱，合规审计（GDPR/CCPA）时无法溯源	从第一天起搭 lineage 表（含 source_url、timestamp、consent_flag）；推荐工具：Delta Lake、DataHub、Amundsen
弱监督标签噪声叠加	Snorkel / 启发式打标引入系统噪声，多层弱监督叠加后误差放大	用 Snorkel 的 generative model 做标签融合；监控每个 LF 的覆盖率和冲突率；设置信度阈值过滤
众包质量不可控	MTurk 工人质量参差，专业领域（医疗、法律）错误率 > 30%	Gold standard 插入 + 多数投票 + 置信加权；专业领域用专家众包替代；用 inter-annotator agreement 监控
Active Learning 选择偏	主动学习倾向于挑边界样本，导致模型对主流分布过拟合、极端分布完全不知	结合 diversity sampling（CDAL、BADGE）；定期全量数据随机抽检，避免分布漂移
合成数据分布漂移	GAN 合成数据与真实分布有系统性差异，直接混合训练可能损害模型	先用 FID / KL-divergence 验证合成数据与真实数据分布差异；合成数据比例建议 < 30%（经验值）
Data Cleaning ROI 不透明	清洗数据耗时但不产生可见指标进步，团队往往跳过	建立清洗前后 baseline 对比（val acc、鲁棒性）；对噪声比例 > 20% 的数据集，清洗是最高 ROI 的改进
采集成本被低估	团队以为数据采集是一次性的，实际是持续运营成本	建立 data collection cost model：采集成本/样本、标注成本/样本、存储成本/月；定期复盘 ROI
隐私合规马后炮	模型上线前没考虑 GDPR，数据采集完才发现没有 consent	在 acquisition 阶段强制填写 consent 字段（0=无授权，1=公开授权，2=付费授权，3=专家授权）；无 consent 字段数据不得入训练集

四、决策表（工程实用版）

你的瓶颈在哪？
├── 样本少（< 1万）→ 先查 pretrained backbone / transfer learning，再考虑 data augmentation
├── 标签贵 / 没有标签 → weak supervision（Snorkel）+ self-supervised pretraining
├── 标签噪声大（> 20%）→ 先清洗（cleanlab），再训模型
├── 分布长尾 / 类别不均 → active learning 挑边界样本 + 数据增强
├── 模型到顶 / 怎么也涨不动 → 70% 概率瓶颈在数据，不在模型架构
└── 上线后发现效果差 → 回查数据 pipeline，优先清理 train/test distribution mismatch

五、原始链接

论文：https://arxiv.org/abs/1811.03402（arXiv v2，2019-08-12）
SIGMOD Record 出版版：https://dl.acm.org/doi/10.1145/3376121（需登录或订阅）
Snorkel 弱监督框架：https://github.com/snorkel-team/snorkel
DataHub（Lineage 工具）：https://github.com/datahub-project/datahub
cleanlab（标签去噪）：https://github.com/cleanlab/cleanlab