StreamSparkAI

概览/核心摘要 (Executive Summary)

本次演讲由Hugging Face的机器学习工程师Loubna Ben Allal主讲，深入探讨了从零开始训练大规模语言模型（LLM）的复杂过程，特别是以代码LLM StarCoder为例。核心观点强调，高质量、精心策划的数据是训练优秀LLM的基石，其重要性甚至超过模型架构和训练技巧。演讲回顾了缩放法则（Scaling Laws）的演变，从早期Kaplan法则（侧重模型参数量）到Chinchilla法则（模型与数据同等重要），再到当前考虑到推理成本而倾向于用更多数据训练更小模型的趋势（如Llama 3在15万亿token上训练）。

获取优质数据涉及三大问题：需要多少数据、从何处获取数据以及如何筛选数据。数据来源包括网络数据（如Common Crawl，FineWeb数据集表现优异）、代码数据（如BigCode项目的The Stack V1和V2，后者包含近1万亿token的代码）以及日益重要的合成数据（如Phi系列模型和Cosmopedia数据集）。数据筛选是关键步骤，包括语言过滤、低质量样本移除、去重（对StarCoder性能提升显著）、个人身份信息（PII）移除（通过StarPII模型）和基准测试数据去污染。演讲强调了通过小型“消融模型”（ablation models）实验来验证筛选策略有效性的重要性。

StarCoder项目作为案例，展示了其在数据治理（如提供opt-out工具、移除PII）和透明度方面的努力，其模型（如StarCoder 2 15B）在代码生成任务上表现优异。最后，演讲讨论了代码LLM的评估挑战，如基准污染问题，并提及LifeCodeBench等动态评估方法。问答环节进一步探讨了合成数据的使用、RLHF的重要性、多模态数据的影响以及微调策略等。

引言：训练优质大语言模型的探索

演讲者Loubna Ben Allal首先提出核心问题：“训练一个好的LLM需要什么？” (What does it take to train a good llm?) 并指出，尽管过去认为强大的闭源模型（如GPT-4）拥有难以企及的“秘密武器”，但开源社区已取得巨大进展，逐渐揭示了构建强大LLM的关键要素。

开源大语言模型的进展与挑战

• 开源模型的崛起：
  • 如今，像Llama 3 70B Instruct这样的开源模型在性能上已接近GPT-4，并且由于模型权重开放，解锁了更多应用场景，甚至可以在消费级桌面设备上运行。
  • 越来越多的公司（如DeepMind的Gemma，Mistral AI的模型）开始拥抱开源。
  • LMSys Arena的评估显示，从2023年到2024年5月，闭源模型与开源模型之间的性能差距正在缩小。
• 开源面临的挑战：
  • 许多模型发布时缺少关于数据处理和模型训练的关键细节。
  • 原因主要有二：
    1. 避免法律审查：若数据使用不当（如侵犯版权），公开训练数据可能面临法律风险。
    2. 保持竞争优势：部分公司希望保留其训练方法的核心细节。
  • 尽管如此，通过分析众多已发布的模型，仍可以拼凑出训练优质LLM的要素。

训练优质大语言模型的关键要素

训练一个好的LLM主要依赖以下几个方面：

1. 模型架构 (Model)：
   • Transformer已成为默认选择。
   • 其他有趣的架构包括Mamba（状态空间模型）和混合专家模型（MoE）。
   • 演讲者表示，模型架构已得到充分探讨，本讲座将更侧重其他方面。
2. GPU资源 (GPUs)：
   • 演讲者对此未做过多阐述。
3. 数据 (Data)：
   • 被认为是LLM的“支柱” (backbone of lms)。
   • 在给定预算下，数据是区分模型优劣的关键因素，值得投入时间探索和理解如何获取高质量样本。

优质训练数据的获取策略

获取优质训练数据主要围绕三个问题展开：

数据量：缩放法则的演进与应用 (Data Volume: Evolution and Application of Scaling Laws)

缩放法则研究如何在计算预算、数据大小和模型大小之间进行最优分配。

• 早期缩放法则 (Kaplan et al., OpenAI)：
  • 发现若计算资源增加10倍，模型参数量应增加5.5倍，而训练token数仅增加1.8倍。
  • 结论：优先增大模型规模，而非数据量。
  • 这导致了像GPT-3（1750亿参数，仅用3000亿token训练）这样相对“欠训练” (undertrained) 的模型。OPT和Bloom也遵循此模式。
• Chinchilla缩放法则 (Hoffmann et al., DeepMind)：
  • 重新审视了缩放法则，发现Kaplan等人的结论部分源于其实验中对不同数据规模使用了固定的余弦学习率调度器，导致对某些模型的性能低估。
  • 新结论：应同等扩展数据量和模型大小。
  • Chinchilla模型（650亿参数）在1.6万亿token上训练，性能优于更大的Gopher（超2000亿参数）和GPT-3。
• 后Chinchilla时代与推理成本考量：
  • Llama 1（70亿参数）在与Chinchilla（600亿参数）相近的数据量（约1.6万亿token）上训练，远超其Chinchilla最优点。
  • 原因：“计算最优并非总是（全局）最优” (compute optimal is not always optimal)，因为训练成本是一次性的，而推理成本是持续的。
  • 更小的模型训练更长时间，虽然训练成本增加（“计算开销” compute overhead），但在推理时能节省大量成本。Llama 3甚至在15万亿token上训练。
  • Harden's Law相关博客文章探讨了这种计算开销。Hugging Face提供了一个工具，可以根据模型大小和数据集估算与Chinchilla最优点相比的开销和推理节省。例如，一个7B模型在1万亿token上训练，可能有13%的训练开销，但带来近50%的推理成本节省。
• 数据受限下的策略：
  • 论文《Scaling Data-Constrained Language Models》指出，如果高质量数据有限，可以将数据重复最多4次，仍能获得与使用不重复数据相似的性能。这对于已接近穷尽可用公共数据的领域（如代码）尤为重要。
• 数据质量对缩放法则的影响：
  • DeepSeek LLM的研究发现，缩放行为高度依赖于数据质量。他们为自己的数据集建立了新的缩放法则。
  • 结论：当拥有更高质量的数据集时，可能应将更多计算资源分配给模型大小，而非数据大小。

数据来源：网络、代码与合成数据 (Data Sources: Web, Code, and Synthetic Data)

• 大规模数据来源：
  1. 网络数据 (Web Data)：
     • 通常从Common Crawl（公共网络爬取数据仓库）开始，需要大规模、重度的过滤。最新dump有超400TB，总计近95个dumps。
     • 可使用已过滤的数据集，如Hugging Face最近发布的FineWeb，包含5万亿token，在公开数据集中表现最佳（对比C4, RefinedWeb, SlimPajama, The Pile）。
  2. 代码数据 (Code Data)：
     • The Stack v1：包含6TB许可宽松的代码。从GitHub克隆超1.3亿仓库（100TB数据），经文件扩展名过滤、许可证过滤（仅保留Apache 2, MIT等）、去重后得到约3TB数据（约2000亿token）。提供Opt-out工具。
     • The Stack v2：更大、更优。数据源自Software Heritage（代码存档），过滤后得到近1万亿token。增加了GitHub Issues, StackOverflow[不确定，原文为matphone code datsets，疑为StackOverflow或类似平台], Pull Requests等高质量资源。比V1大4-5倍。
• 其他高质量但规模较小的数据源：
  • Wikipedia, Books, ArXiv, Stack Exchange。
• 合成数据 (Synthetic Data)：
  • 近年来变得非常重要，预计未来会更重要。
  • Microsoft的Phi系列模型（如论文《Textbooks Are All You Need》）使用GPT-3.5和GPT-4生成合成教科书作为预训练语料库，表现优于在网络数据集上训练的模型。
  • 许多流行LLM（如Claude 3, Llama 3）已将合成数据纳入预训练。Llama 3使用模型构建分类器筛选样本，并生成合成内容以提升编码、推理和长上下文能力。
  • Hugging Face发布的Cosmopedia：最大的合成文本数据集之一，含约250亿token，使用开源模型Mixtral 8x7B生成。生成策略：80%数据来自网络样本，启发模型生成相关教科书，并通过提供更多上下文限制生成范围；另有来自Stanford课程、WikiHow等策划源的数据。

数据筛选与清洗：提升数据质量的关键 (Data Filtering and Cleaning: Key to Improving Data Quality)

“高质量数据集可能会为标准架构展现出非常高级的能力。” (High quality dataset might exhibit very advanced capabilities for a standard architecture) - 引用自Yi论文。

• 通用过滤流程示例 (Yi论文)：
  1. 语言过滤。
  2. 低质量样本移除（如重复行过多、基于规则修正、困惑度过滤）。
  3. 去重 (Deduplication)：非常重要，避免模型记忆和性能下降。包括精确去重和近似去重（如MinHash）。
  4. 进一步过滤（如语义过滤、主题过滤）。
• FineWeb的成功也归功于其精细的过滤和去重。
• 如何找到好的过滤器：
  1. 手动检查数据：了解数据实际情况。
  2. 消融实验 (Ablation Studies)：
     • 对应用了特定过滤器的子集训练小型模型，比较有无此过滤器的效果。
     • 经验表明，小型模型上的数据消融实验结果多数能推广到大型模型。
     • 选择高信号基准测试（如Hellaswag, MMLU）以便早期判断效果。
     • 使用不同随机种子多次训练以减少噪声，获得更稳健的结论。
     • FineWeb作者运行了超过200个消融实验（1B模型，30B token训练）。
  3. 案例：StarCoder团队曾尝试基于代码注释多少和仓库星标数进行过滤。
     • 移除几乎无注释文件的过滤器，性能提升微乎其微。
     • 移除星标数少于5的仓库文件（移除了70%数据），导致模型性能在所有消融实验中最差。

StarCoder案例研究：代码大模型的幕后 (StarCoder Use Case: Behind the Scenes of Code LLMs)

The Stack数据集的筛选流程 (Filtering Process for The Stack Dataset)

• StarCoder (V1)：从The Stack V1的6TB源码中筛选出800GB用于训练。
• StarCoder 2：从The Stack V2的3.2TB（600种编程语言）数据开始，最终筛选并扩充（加入GitHub Issues, Commits, Jupyter Notebooks, Cargo Notebooks, Pull Requests）到6.3TB代码。
• 代码筛选步骤：
  1. 语言选择：保留流行语言，排除不再维护的语言。StarCoder 2包含超600种语言。
  2. 数据质量检查：移除低质量文件和自动生成内容。例如，平均行长过高可能表明文件有问题。针对不同语言使用不同阈值（BigCode社区成员帮助审查样本并确定阈值）。
  3. 近似去重 (Near-Deduplication)：对性能提升最显著的过滤步骤，且语言无关。StarCoder的Python子集在应用近似去重后，Pass@1从13%提升到17%。
  4. 个人可识别信息 (PII) 移除：
     • 由于代码中可能包含姓名、邮箱、密钥、密码等敏感信息。
     • 方法：与标注公司合作标注PII样本 -> 训练一个NER模型（StarPII）来检测PII -> 在整个StarCoder训练数据上运行StarPII（耗费约800 A100 GPU小时）。
  5. 数据去污染 (Data Decontamination)：确保从训练数据中移除评估用的基准测试集和测试集，避免评估结果虚高。
• 数据格式化：
  • 在代码文件前添加特殊token，如仓库名、文件名、星标数。这有助于模型在IDE（如VS Code）中根据文件名后缀推断语言。
  • 尝试通过控制星标数token影响生成代码质量，但未发现显著差异。

StarCoder 2的改进：仓库感知能力 (StarCoder 2 Improvements: Repository Awareness)

• StarCoder V1训练时打乱了文件，模型不知道文件间的仓库归属关系。
• StarCoder 2：将同一仓库中的文件在训练时保持相邻，通过特殊token（如FILE_SEPARATOR）分隔。这使得模型能感知文件间的上下文关系，可能学习到仓库内文件的关联。

相关工具与资源 (Relevant Tools and Resources)

• 通用LLM训练：Hugging Face的Nanotron，一个用于训练具有3D并行性（张量并行、流水线并行、数据并行）的LLM的框架。还包含用于评估的LightEval。
• 代码LLM训练：BigCode项目在GitHub上开源了用于The Stack数据集处理和StarCoder模型训练的代码。

代码大语言模型概览 (Overview of Code LLMs)

发展历程与现状 (Development History and Current Status)

• GitHub Copilot（基于OpenAI的Codex模型）的发布是一个里程碑，证明了可以将代码视为文本，通过大型Transformer模型和大量代码数据进行训练，效果远超传统方法（如使用AST）。
• 如今，Hugging Face Hub上有超过1700个代码训练模型（纯代码模型或包含代码数据训练的通用模型）。
• 代码评估基准HumanEval上，一些强模型得分接近80%。

BigCode项目的贡献与原则 (Contributions and Principles of the BigCode Project)

• 主要贡献者：
  • BigCode：发布了The Stack数据集（已成为代码训练的默认数据集）、StarCoder 1和StarCoder 2系列模型、Starchat 2（与Hugging Face H4团队合作的指令微调模型）。
  • Meta：Code Llama系列模型（7B到70B）。
  • DeepSeek：DeepSeek Coder系列模型。
  • 其他：IBM的Granite模型，CodeTrans[不确定，原文为code quen，疑为CodeTrans或CodeGen], CodeGen, StableCode。
• BigCode的协作原则：
  • 完全数据透明：公开训练细节和数据。
  • 可复现性：提供处理代码和模型权重。
  • 开放协作：吸引了上千名研究者参与。
  • 负责任的发布：
    • 开放数据集访问（包括数据检查工具）。
    • 提供Opt-out工具。
    • 移除PII。
    • 发布评估工具和详细技术报告。

StarCoder系列模型的演进与评估 (Evolution and Evaluation of StarCoder Model Series)

• 演进：SantaCoder (消融实验用) -> StarCoder (去年发布, 15B) -> StarCoder 2 (今年发布, 多语言, 评估分数更高)。
• 透明度：StarCoder被斯坦福基础模型透明度指数评为最透明的模型。
• 性能：
  • StarCoder 15B发布时是SOTA代码模型。
  • StarCoder 2 15B在同级别模型中也是SOTA，甚至接近或优于更大的模型（如匹配Code Llama 34B，在某些基准上接近DeepSeek Coder 33B）。
  • 强调在多个基准上进行评估的重要性，以全面了解模型行为并降低单一基准污染的风险。
• 配套工具：
  • VS Code集成，包含成员资格测试 (membership test)，尝试检测生成的代码是否在训练数据中并高亮提示，作为代码溯源努力的一部分。

个人代码助手的构建 (Building Personal Code Assistants)

• 可以基于StarCoder, Code Llama等模型在个人代码库上进行微调。
• 流程：数据准备与过滤 -> 去重 -> 使用PEFT（参数高效微调，如LoRA）进行训练（7B模型可在Google Colab上完成）-> 部署（如使用Ollama）。

代码大语言模型的评估挑战 (Evaluation Challenges for Code LLMs)

• 常用基准：
  • HumanEval: 模型补全函数，通过单元测试评估，计算Pass@1。
  • MultiPL-E: HumanEval的多语言版本（支持18种语言如Java, JavaScript, C++）。
• 问题：
  • 污染 (Contamination) 和 过拟合 (Overfitting)，尤其对于指令微调模型。指令数据可能与HumanEval的练习形式非常相似。
• 解决方案探索：
  • LifeCodeBench Leaderboard: 定期从CodeContests, LeetCode等平台抓取新问题，并仅在模型发布日期之后出现的问题上评估模型，以确保无污染。
  • 发现一些模型在全量数据和“无污染”数据上的表现不一致。
  • 这类动态基准也有助于比较开源模型与闭源模型（如GPT-4）的真实差距。

问答环节精选 (Selected Q&A)

1. AI生成合成数据的后果及与自然语言分布的差异？
   • 后果：可能强化模型偏见；可能生成与评估基准相似的内容导致污染（如对Phi模型的质疑）。
   • 与自然分布差异：纯合成数据训练的模型可能不如混合了真实网络数据的模型。Cosmopedia实验发现加入部分网络数据能提升性能。目前看，高质量过滤后的网络数据与合成数据的混合可能是最佳方案。Phi 3的技术报告也强调了过滤网络数据并将其包含在预训练中的重要性。
2. RLHF的偏好数据比无监督预训练数据更重要吗？
   • 无监督预训练用于获得基础模型。要将其用作聊天助手，需要额外步骤，如RLHF或更常见的监督式指令微调（SFT）。目前也有非强化学习的方法如DPO, RPO表现良好。因此，若目标是聊天助手，则在无监督预训练模型之上进行某种形式的监督式训练是必要的。
3. 多模态数据（图像、视频）能否减少对纯文本数据的需求？
   • 演讲者表示不确定，但观察到即使是多模态模型（如Hugging Face的Idefics），文本部分仍占显著比例。
4. 训练文本LLM与代码LLM的主要区别（除数据外）？
   • 训练架构相似（StarCoder使用类似Llama/Mistral的架构）。
   • 代码LLM可能更优先考虑长上下文能力（以便在IDE中处理多个相关文件）和快速推理（使用GQA等技术）。但这些技术也用于通用LLM。总体而言非常相似，但代码LLM可能更倾向于能快速部署的小模型。
5. 计算预算极小（如单GPU）时的优先事项（假设微调）？
   • 使用量化模型（如Llama.cpp）和PEFT技术（如LoRA）进行微调，7B模型单GPU可实现。
   • 关键是找到一个精心策划的小型高质量数据集，因为质量比数量更重要。
6. 最优训练数据量是否也取决于领域和任务？
   • 是的。Chinchilla缩放法则比较了英语和代码，发现结论仍适用。但对于其他领域（如医疗），情况可能不同。DeepSeek的论文表明缩放法则高度依赖数据（即使在同一领域，不同质量的数据集也会导致缩放法则变化）。对于未被现有缩放法则研究覆盖的领域，需注意这一点。
7. 通用文本与代码生成的tokenizer有何有趣差异？
   • 训练tokenizer时，会确保数字被正确切分。StarCoder的tokenizer在其代码混合数据上训练。
   • 总体与文本tokenizer训练相似。目前多数LLM的tokenizer都在大量代码数据上训练过，因此也包含大量代码token。反之，代码数据中也包含大量Markdown等自然语言文本，所以代码tokenizer也能很好地表示英文token。
8. 微调的原则与预训练有何不同或额外建议？
   • 数据准备阶段差异较大。微调通常针对特定语言或任务，数据量需求远小于预训练。
   • 数据策划对于微调更为关键。例如，StarCoder预训练时因移除过多数据而失败的“星标过滤”策略，在数据量需求更小的指令微调中可能适用（类比DALL-E[不确定，原文为dilemma paper，疑为某篇关于少量高质量指令数据微调的论文，如Alpaca的1000条指令]论文中仅用少量高质量指令就取得良好效果）。
9. 发布非常大的数据集时有哪些注意事项（尤其是细微或不为人知的方面）？
   • 技术层面：提供过滤工具和文档（如The Stack的做法）。
   • 治理层面：确保许可证和版权得到尊重；提供Opt-out工具；在Hugging Face Hub等平台发布以便访问。
   • 敏感数据：对于包含敏感信息的数据集（如StarCoder的PII检测数据集），可以考虑设置门控访问机制。

核心观点总结 (Summary of Core Viewpoints)

演讲强调，训练强大的大规模语言模型，尤其是针对代码等特定领域的模型，其核心在于数据。这包括理解需要多少数据（缩放法则的演进，并考虑推理成本）、从何处获取数据（网络、代码、合成数据），以及最关键的——如何通过细致的筛选、去重和净化流程来确保数据的高质量。StarCoder项目作为成功案例，展示了透明、负责任的数据处理和模型开发流程。开源社区在LLM领域正快速追赶，而数据策略的优劣是决定模型性能的关键差异化因素。