最近和团队复盘一次大模型微调项目发现最花时间的不是模型训练而是数据准备。我们反复清洗了一批又一批语料真正能用的高质量数据却少得可怜。后来我意识到这不是一个团队的问题而是整个 AI 行业正在面对的共性困境互联网上的高质量文本数据可能真的不够用了。训练大模型就像喂养一只胃口越来越大的“数据怪兽”。模型参数从几亿涨到几千亿训练数据从几十 GB 涨到几十 TB可互联网上的有效文本并没有同步增长。更麻烦的是低质内容、重复内容、机器生成内容越来越多真正能提升模型能力的高质量语料反而更难找。这篇文章会从数据规模测算、数据供应链、合成数据与数据工程实践几个角度梳理“AI 吃光互联网”这件事的来龙去脉并给出 AI 工程师可以落地的数据预算、数据清洗、数据合成和模型部署思路。无论你是做大模型训练、RAG 应用还是本机部署大模型做实验这篇文章都值得收藏。1. 背景与核心概念AI 训练数据危机是怎么发生的1.1 为什么说“AI 在吃光互联网”先看一个最简单的对比。GPT-3 训练时使用了大约 3000 亿 token 的文本而到了 Llama 3 系列Meta 公开的训练数据已经达到 15 万亿 token 量级。短短几年之间单次预训练的数据消耗量增长了约 50 倍。这里的 token 可以简单理解为“模型读取文本的最小单位”。英文里一个 token 大约对应 0.7 到 1 个单词中文一个 token 大约对应 0.6 到 1 个汉字。15 万亿 token 是什么概念如果按一本 10 万字的书估算大约相当于几千万本书的文本量。问题在于互联网虽然每天都在产生海量内容但真正“适合训练大模型”的高质量文本远没有那么多。原始网页里充斥着导航栏、广告、重复转载、机器生成内容、无意义评论真正有价值的信息密度很低。随着大模型参数规模越来越大训练数据需求越来越高高质量数据的缺口就暴露出来了。1.2 数据枯竭对开发者的真实影响很多开发者以为“数据不够用”是大厂才需要考虑的问题其实不是。我在实际项目里感受到的影响主要有三个。第一训练和微调成本上升。数据不够、质量不够时团队只能花更多时间清洗、去重、标注或者购买第三方数据集这部分隐形成本往往比 GPU 费用还高。第二垂直领域数据更加稀缺。通用网页文本被反复使用后金融、医疗、法律、工业等专业领域的高质量数据仍然很难获取。做垂直大模型时往往要面对“领域数据根本凑不齐”的尴尬。第三评测结果越来越难反映真实能力。如果训练数据和公开评测数据存在大量重叠模型在 benchmark 上的分数会虚高一上线就“翻车”。这也是数据缺乏治理的典型表现。1.3 先分清几个容易混淆的概念在继续往下讲之前有必要把几个概念区分开。“训练数据”指的是模型学习时使用的文本、代码、图像等内容“合成数据”则是由模型或程序生成的、用于替代或补充真实数据的内容而“数据治理”是围绕数据采集、清洗、版本、权限、合规的一整套工程体系。另外“基础模型”和“行业模型”对数据的需求也不同。基础模型通常需要几百 GB 甚至几 TB 的通用语料而行业模型更多依赖高质量的垂直领域数据。搞清楚自己要做的是哪一类模型才能合理规划数据预算。2. 量化视角互联网数据到底够不够用2.1 主流大模型的训练数据量级先看一组公开信息里可以确认的数据。GPT-3 的训练数据约 3000 亿 tokenLlama 2 约 2 万亿 tokenLlama 3 达到 15 万亿 token 以上。可以看出模型训练对数据的需求是持续上升的。还有一个常被引用的经验法则叫 Chinchilla 法则它建议训练数据量大约为模型参数量的 20 倍左右。也就是说一个 70B 参数的模型按这个法则训练大约需要 1.4 万亿 token如果数据只有几百亿 token模型就很容易欠拟合学不到足够的知识。实际项目中很多团队会用更多数据来换取更好的效果。Llama 3 70B 用了 15 万亿 token远超 Chinchilla 法则的最低要求这从侧面说明“数据多多益善”仍然是当前大模型训练的普遍做法。2.2 估算互联网可用文本数据的规模那么互联网上到底有多少可用文本有研究机构估算互联网上高质量英文文本总量大约在 10 万亿到 100 万亿 token 之间取一个中间值也在数十万亿 token 量级。这个数字看起来不小但要注意三个约束。第一很多文本是重复的。同一个新闻稿会被多个网站转载同一段代码会出现在不同的博客里去重之后有效数据量会大幅缩水。第二很多文本质量偏低。机器翻译、拼凑内容、低质营销文章在网页中的占比越来越高过滤之后的语料远少于原始抓取量。第三受版权和合规限制并非所有互联网内容都可以合法采集和使用。去除不可用、不该用的数据之后真正能被大模型“吃掉”的高质量文本就更有限了。2.3 用 Python 做一个数据消耗测算脚本为了让大家对“数据预算”有更直观的感受我写了一个简单的 Python 脚本用来估算一个大模型需要多少训练数据以及互联网可采集文本大概能支撑多少个这样的模型。# data_budget.py 估算大模型训练数据需求并与互联网可采集文本量做粗略对比。 数值均为估算值重点在于帮助团队建立“数据预算”意识。 MODEL_SIZE 70 * 10**9 # 模型参数70B TOKENS_PER_PARAM 20 # Chinchilla 法则约 20 token/参数 TOKENS_PER_WORD 1.3 # 英文平均每个词约 1.3 个 token WORDS_PER_PAGE 800 # 平均每个网页有效正文约 800 词 HARVESTABLE_PAGES 2 * 10**9 # 假设可合法采集的网页约 20 亿个 def train_tokens_needed(model_size): 根据 Chinchilla 法则估算训练所需 token 数 return model_size * TOKENS_PER_PARAM def internet_token_supply(pages, words_per_page, tokens_per_word): 估算可采集网页的 token 总量 return pages * words_per_page * tokens_per_word needed train_tokens_needed(MODEL_SIZE) supply internet_token_supply(HARVESTABLE_PAGES, WORDS_PER_PAGE, TOKENS_PER_WORD) print(f70B 模型按约 20 token/参数估算需要训练数据{needed / 1e12:.2f} 万亿 token) print(f假设可采集 20 亿网页估计可提取文本{supply / 1e12:.2f} 万亿 token) print(f一个大模型消耗的可采集文本占比{needed / supply * 100:.2f}%)运行结果类似70B 模型按约 20 token/参数估算需要训练数据1.40 万亿 token 假设可采集 20 亿网页估计可提取文本2.08 万亿 token 一个大模型消耗的可采集文本占比67.31%这里并不是说“只能容纳一个大模型”而是想说明可采集文本看起来很多但单个大模型的数据消耗量已经非常可观。如果每个团队都从零训练一个大模型数据竞争的强度可想而知。2.4 为什么“毛估”也有价值有人会说这个估算太粗糙了网页数量、每页词数、token 换算都不准确。确实这只是一个“数量级估算”它的价值不在于精确预测而在于让团队建立“数据预算”意识。在实际项目中我们不会等到模型训练到一半才发现数据不够而是在立项阶段就估算要训练多大的模型、需要多少 token、目前手头有多少原始数据、清洗后还剩多少、按日爬取能补充多少。把这些问题想清楚后面才不会被数据问题拖垮。3. 从数据供应链看 AI 训练的依赖链3.1 数据采集不是越多越好数据供应链的第一步是采集。很多团队以为爬得越多越好结果发现大量低质数据反而拉低了训练效果。更严重的是如果采集时不注意合规还会带来版权和隐私风险。合规采集至少要做到几点遵守目标网站的 robots 协议控制请求频率避免影响对方服务只采集公开内容不碰需要登录或授权的信息涉及个人数据时必须脱敏和获得合法授权。这里的核心原则是“采集权利优先于采集数量”。实际项目中我更推荐把采集目标分成两类一类是基础通用语料比如百科类、书籍类、开源代码类另一类是垂直领域语料需要针对具体业务定向积累。两类数据的采集策略完全不同。3.2 清洗与去重决定数据质量的“生死线”采集回来的原始数据必须清洗。清洗包括去除 HTML 标签、过滤广告和导航信息、识别乱码、去除重复内容等。其中去重是最容易被忽视、也最影响训练效果的一步。如果数据集中存在大量重复文本模型会反复“背诵”这些重复片段导致泛化能力下降。更隐蔽的问题是重复数据会导致评测集被污染让离线指标虚高。下面用一个简化版 MinHash 示例演示文本相似度去重的基本思路。生产环境建议使用 datasketch、Spark 等成熟方案这里主要帮助理解原理。# minhash_dedup_demo.py import hashlib def shingles(text, k6): 将文本切成字符级 n-gram英文可按词切分 text text.replace( , ) return [text[i:i k] for i in range(len(text) - k 1)] def hash_shingle(value, seed): 带随机种子的哈希模拟不同的随机排列 raw f{seed}:{value}.encode(utf-8) return int(hashlib.md5(raw).hexdigest()[:8], 16) def minhash_signature(text, num_hashes10): 计算文本的 MinHash 签名 sig [] for seed in range(num_hashes): sig.append(min(hash_shingle(s, seed) for s in shingles(text))) return sig def signature_similarity(sig1, sig2): 根据签名估算 Jaccard 相似度 return sum(1 for a, b in zip(sig1, sig2) if a b) / len(sig1) if __name__ __main__: doc_a 人工智能正在改变互联网的内容生产方式 doc_b 人工智能正在改变互联网的内容生产模式 doc_c 今天天气很好适合出门散步 sig_a minhash_signature(doc_a) sig_b minhash_signature(doc_b) sig_c minhash_signature(doc_c) print(f相似文本签名相似度{signature_similarity(sig_a, sig_b):.2f}) print(f不相似文本签名相似度{signature_similarity(sig_a, sig_c):.2f})运行结果大致是相似文本签名相似度0.50 不相似文本签名相似度0.00相似文本的签名相似度明显更高说明 MinHash 可以在大规模文本集里快速找到近似重复的文档。生产环境中还可以用 LSH 做分桶在海量数据里进一步加速。3.3 质量过滤与版权过滤去重之外还需要做质量过滤。常见的做法包括用规则过滤过短文本、过滤无意义符号用分类模型判断文本质量用困惑度评估文本是否通顺。比较有名的例子是 Gopher 的过滤规则它会对文本长度、符号占比、脏词、重复程度等做综合打分低于阈值的文本直接丢弃。简单说质量过滤的目标是让语料更“干净”而不是更“多”。版权过滤同样重要。要避免让模型直接生成受版权保护的长片段采集时要确认数据来源的授权情况同时保留数据来源、时间等元信息方便事后审计。这也是数据治理的基本要求。3.4 数据质量评估没有指标就没法优化很多团队在数据清洗之后直接开始训练结果出了问题很难排查。更好的做法是在清洗完成后先对数据做一次质量评估至少包含几个维度文本长度分布是否合理重复率是否达标语言分布是否符合预期敏感信息是否已脱敏抽样内容是否存在明显错误。这些指标应该固化成脚本每次数据集更新后自动跑一遍。数据质量评估不是一次性工作而是数据供应链上的一个常态化节点。4. 应对方案合成数据与数据工程实践4.1 合成数据为什么成为焦点当真实高质量数据不足时合成数据成了很多团队的选择。合成数据是由程序或模型自动生成的训练样本可以补充真实数据覆盖不到的场景缓解标注成本高、领域数据稀缺的问题。常见的合成数据方案包括基于模板生成问答对利用大模型自举生成指令数据在图像领域做数据增强在表格数据里做分布采样等。不过合成数据并不是“万能药”。如果完全依赖合成数据训练模型模型可能会逐渐丢失真实分布的细节出现“模型坍塌”现象。所以更务实的做法是把合成数据作为真实数据的补充而不是替代。4.2 一个简单的合成数据生成示例下面用一个基于模板的 QA 数据生成示例演示合成数据 pipeline 的基本思路。实际项目中可以用大模型做更复杂的自举生成但质量控制逻辑是相通的。# synthetic_pipeline.py import hashlib import random class SyntheticDataPipeline: 合成数据生成与质量过滤 demo def __init__(self, min_length10, max_length300): self.min_length min_length self.max_length max_length self.seen_fingerprints set() def generate_samples(self, templates, num_samples100): samples [] while len(samples) num_samples: template random.choice(templates) sample template.format(idrandom.randint(1, 10000)) if self._is_valid(sample): samples.append({text: sample, source: synthetic}) return samples def _is_valid(self, text): if not (self.min_length len(text) self.max_length): return False fp hashlib.sha256(text.encode(utf-8)).hexdigest() if fp in self.seen_fingerprints: return False self.seen_fingerprints.add(fp) return True if __name__ __main__: templates [ 问题什么是 AI Agent\n答案AI Agent 是能够感知环境、做出决策并执行任务的智能体。, 问题如何本地部署大模型\n答案可以使用开源模型配合量化工具在本地 GPU 环境部署。, 问题什么是数据治理\n答案数据治理是对数据采集、存储、处理、使用进行规范和管理的体系。, ] pipeline SyntheticDataPipeline() samples pipeline.generate_samples(templates, num_samples20) print(f生成样本数{len(samples)}) for sample in samples[:3]: print(sample[text]) print(---)这个 pipeline 虽然简单但包含了两个关键思想一是生成样本要有质量控制二是要去重。真实项目里还会加入关键词过滤、敏感信息检测、困惑度评估等步骤。4.3 合成数据的质量评估与风险控制合成数据加入训练集之前一定要做质量评估。我建议至少做三件事。第一抽样人工审核。让业务人员或领域专家看一批生成样本判断内容是否合理、是否答非所问。第二做分布对比。对比合成数据和真实数据在长度、主题、句式上的分布差异差异过大时说明生成策略需要调整。第三设置混合比例。不要一上来就用 100% 合成数据而是从 10%、20% 开始逐步观察模型表现。这个比例需要根据具体任务反复实验。另外还要注意合成数据如果反复迭代模型可能逐渐偏离真实分布。保持“真实数据 合成数据”的混合策略是当前比较稳妥的做法。5. 对 AI 工程实践的具体影响5.1 小模型、垂直模型重新受到重视数据稀缺带来的直接影响是“大力出奇迹”的边际收益越来越低。以前训练一个任务直接把几十 TB 数据灌进去就行现在高质量数据不够很多团队开始转向小模型和垂直模型。小模型需要的训练数据少部署成本低更适合本机部署和边缘场景。比如在内部知识库问答、代码补全、日志分析等场景中一个经过高质量微调的 7B 或 13B 模型往往比盲目追求 70B 模型更实用。如果你做的是 AI 应用开发可以考虑用开源小模型 LoRA 微调的方式在少量高质量数据上也能获得不错的效果。这也符合“模型部署”环节对低延迟、低成本的要求。5.2 AI Agent 让数据回流成为新趋势另一个值得关注的方向是 AI Agent。Agent 在真实业务中会产生大量交互日志包括用户问题、工具调用、最终回复、用户反馈等。这些日志经过脱敏和清洗后可以变成新的训练数据形成“数据飞轮”。具体做法是Agent 上线后记录交互轨迹定期筛选高质量样本加入微调数据集。这样模型就能持续从真实使用中学习而不是只依赖静态的互联网语料。需要注意的是这类数据往往涉及用户隐私必须做严格的脱敏和授权处理同时要建立数据保留和删除机制。数据回流是好事情但前提是合规。5.3 数据版本管理与模型血缘当数据成为核心资产数据版本管理就显得非常重要。同一个模型上一版用的是 v2 数据集这一版用的是 v3 数据集如果效果变差需要能快速回查到是哪些数据发生了变化。推荐使用 DVC、LakeFS 等工具管理数据集版本并在训练任务中记录数据集的 commit、清洗脚本版本、tokenizer 版本等信息。这样每次训练实验都能完整复现排查问题也更快。5.4 从“堆数据”到“用数据”的思维转变过去很多团队做 AI第一反应是“先去爬更多数据”现在更合理的思路是“先想清楚要解决什么问题需要什么数据”。数据质量、数据配比、数据成本都应该在模型训练之前就规划好。这个转变看似简单实际落地需要数据工程师、算法工程师和业务人员紧密配合。数据不再是后台的“原材料”而是直接决定模型上限的核心资产。6. 常见问题与排查思路问题现象常见原因排查思路解决建议训练数据不够用数据预算没有提前规划用脚本统计原始数据、清洗后数据量扩大合规采集渠道或引入合成数据模型效果差重复内容多数据集中重复率过高抽样统计重复度跑 MinHash 去重建立去重 pipeline定期执行评测分数虚高线上翻车训练集与评测集数据重叠检查数据时间切分与去重按时间切分数据加入严格去重合成数据导致模型越训越差合成数据比例过高模型坍塌对比合成前后数据分布控制合成数据比例混合真实数据版权或隐私投诉采集和生成环节不合规检查数据来源和授权记录建立合规审核和脱敏机制清洗后数据量骤降过滤规则过于严格分析每条过滤规则的影响分阶段过滤保留可审计日志排查数据问题时建议按“采集 → 清洗 → 去重 → 质量评估 → 版本记录”的链路逐层检查不要直接怀疑模型结构。大多数情况下问题出在数据而不是模型。7. 最佳实践与工程建议结合前面的分析这里整理几条可以直接用在实际项目里的数据工程建议。第一数据预算先行。在项目立项时就用脚本估算训练数据需求设定目标数据量并制定采集和清洗计划。否则训练到一半才发现数据不够返工成本极高。第二高质量小数据优于低质量大数据。与其爬 100 TB 低质网页不如精心整理 10 TB 高质量语料再配合领域数据微调。数据清洗不是浪费时间而是变相节省 GPU 开销。第三把去重和质量过滤做成标准化 pipeline。去重、过滤、脱敏、抽样评估这些步骤要固化成可复用的工具链而不是每次手工处理。团队内部可以搭建一个简单的数据流水线自动产出清洗报告。第四合成数据只做补充不做替代。用合成数据解决数据不足问题没问题但要在 pipeline 里保留真实数据的比例并持续监控模型是否出现分布偏移。第五重视合规和隐私。采集数据要遵守网站协议处理个人数据要脱敏和授权所有数据操作都要有日志记录。安全边界一旦失守技术价值再高也会归零。第六建立数据血缘和版本管理。数据集版本化训练任务可复现出现问题时能快速定位。这个习惯在团队协作中尤为重要。第七关注数据分布漂移。互联网内容变化很快去年训练的数据可能已经和今年真实场景不匹配了。要建立定期更新的机制让模型持续适应新数据。8. 总结与学习路线这篇文章从“AI 吃光互联网”这个现象出发聊了数据规模估算、数据供应链、合成数据、AI Agent 数据回流和数据治理几个重点。对于 AI 工程师来说最需要建立的核心能力不是“会调参”而是“会管数据”。下一步可以沿着这样几条路线继续深入。如果你偏算法方向可以学习模型压缩、LoRA 微调、持续学习用更少的数据做出更好的模型如果你偏工程方向可以研究数据管道、数据版本管理和分布式数据处理把数据清洗做成自动化平台如果你偏产品方向可以关注垂直场景的数据回流机制让真实使用数据反哺模型。最后给一个实操建议找一个小型垂直任务手工整理 1 万条高质量数据用开源小模型做一次完整微调和部署记下数据清洗时间、训练时间、模型效果三个指标。做完这一步你对“数据到底有多重要”会有完全不一样的体感。如果这篇文章对你有帮助可以先收藏备用。后面我会继续分享数据清洗工具链和大模型本地部署的完整实战。