StreamSparkAI

概览/核心摘要 (Executive Summary)

本次演讲由Hugging Face的机器学习工程师Loubna Ben Allal主讲，深入探讨了从零开始训练大型语言模型（LLM）的复杂过程，并以StarCoder模型作为代码LLM的案例进行分析。核心观点认为，高质量的数据是训练优秀LLM的基石，其重要性甚至超过模型架构和训练技巧。演讲首先回顾了开源LLM的快速发展，指出其与闭源模型差距正不断缩小。接着，详细阐述了获取优质训练数据的三大关键问题：数据量（规模法则的演进，从Kaplan到Chinchilla，再到考虑推理成本的“超越Chinchilla”）、数据来源（网络数据如Common Crawl和FineWeb，代码数据如The Stack V1/V2，以及日益重要的合成数据如Cosmopedia）和数据筛选（语言过滤、低质移除、去重、PII清除、去污染等）。StarCoder的开发实践突出了精细数据治理的重要性，包括多阶段过滤、PII清除工具StarPII的开发以及为提升代码生成质量而设计的特殊数据格式。演讲强调了开放和负责任的LLM开发，包括数据透明、提供退出机制、PII移除和发布复现工具。最后，讨论了代码LLM的评估挑战，如基准污染问题及LifeCoderBench等应对方案，并提及了微调代码LLM构建个人代码助手的可能性。

引言与开源进展

• 演讲核心问题：训练一个优秀的LLM需要什么？
• 开源LLM的进步：
  • 过去认为开源社区追赶GPT-4等强大闭源模型需很长时间。
  • 现状：社区已掌握大部分关键技术，开源模型（如Llama 3 70B）性能已接近GPT-4。
  • Llama 3 70B Instruct模型权重开放，可量化并在消费级桌面运行，推动社区创新。
  • 更多公司（如DeepMind的Gemma，Mistral的模型）开始拥抱开源。
  • LMSys Arena排行榜显示，从2023年到2024年5月，闭源与开源模型性能差距缩小。
• 开源发布的局限性：
  • 常缺失数据处理和模型训练的关键细节。
  • 原因：
    1. 避免法律审查：若数据处理不当（如侵犯版权），公开细节可能面临法律风险。
    2. 维持竞争优势：公司不愿透露所有训练细节。

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

训练一个好的LLM主要依赖三个方面：

1. 模型 (Model)：
   • Transformer架构已成默认选择。
   • 其他有趣架构：Mamba（状态空间模型）、混合专家模型 (MoE)。
   • 本次演讲不侧重模型架构，因其已被广泛探讨。
2. GPU (GPUs)：
   • 演讲者表示对此无可奉告，笑称“也许该问Jensen (黄仁勋)”。
3. 数据 (Data)：
   • 被认为是LLM的支柱 (backbone)。
   • 在给定预算下，数据是区分模型优劣的关键。
   • 值得投入时间探索和理解如何获取高质量样本。

优质训练数据的获取与处理

获取优质训练数据需回答三个问题：需要多少数据？从哪里获取数据？如何清洗数据？

数据量：规模法则的演进与应用 (Data Quantity: Evolution and Application of Scaling Laws)

规模法则 (Scaling Laws) 研究如何在数据量和模型大小之间分配计算预算。

• 早期Kaplan法则 (OpenAI)：
  • 结论：若计算资源增加10倍，参数量应增加5.5倍，训练token数仅增加1.8倍。
  • 影响：催生了如GPT-3 (175B参数，300B tokens) 这样参数巨大但训练不足 (undertrained) 的模型。OPT、Bloom也遵循此模式。
• Chinchilla法则 (DeepMind)：
  • 修正了Kaplan法则，指出Kaplan因使用固定余弦调度器 (cosine scheduler) 导致对某些模型评估不足。
  • 新结论：应同等扩展数据量和模型大小。
  • Chinchilla模型 (65B参数) 用1.6万亿 (trillion) tokens训练，性能优于更大的GPT-3和Gopher (200B+参数)。
• 超越Chinchilla：推理成本的考量：
  • 现象：Llama 1 (7B参数) 使用了与Chinchilla (65B) 相近的1.6万亿tokens进行训练，远超其Chinchilla最优点。Llama 3更是用了15万亿tokens。
  • 原因：“计算最优并非总是（整体）最优” (Compute optimal is not always optimal)。训练成本是一次性的，但推理成本是持续的。
  • 用户倾向于训练更小的模型更长时间，以节省推理成本。这被称为支付“计算开销” (compute overhead) 以换取推理效益。
  • Hugging Face的工具显示，一个7B模型在1万亿tokens上训练，相比Chinchilla最优点，训练开销增加约13%，但推理成本可节省近50%。
• 数据受限与数据重复：
  • 论文《Scaling Data Constraint Language Models》指出，若高质量数据有限，可将数据重复最多4次，仍能获得与使用不重复数据相似的性能。
  • 这对已耗尽公开可用数据的领域（如代码）尤其重要。The Stack V2几乎包含了所有公开可用的代码。
• 数据质量与规模法则：
  • DeepSeek LLM的论文发现，规模法则的行为高度依赖于数据质量。
  • 更高质量的数据集可能意味着应将更多计算资源分配给模型大小，而非数据大小。

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

• 网络数据 (Web Data)：
  • Common Crawl：主要的原始数据来源，是公开的网页抓取存档。需要大规模、重度过滤（最新dump超400TB，总计近95个dumps）。
  • 已过滤数据集：Hugging Face最近发布的FineWeb，包含15万亿tokens，在公开数据集中表现最佳。
• 代码数据 (Code Data)：
  • The Stack (BigCode项目)：最大的开源代码数据集。
    • V1版本：6TB许可宽松的代码。构建流程：克隆GitHub所有公开仓库 (1.3亿+仓库, 100TB数据) -> 文件扩展名过滤 (剩90TB) -> 基于许可证过滤 (仅保留Apache 2, MIT等) -> 去重 (剩约3TB)。提供Opt-out工具，允许开发者将其代码从数据集中移除。最终约2000亿tokens。
    • V2版本：更大、更优。数据源自Software Heritage（代码归档库）。过滤后约1万亿tokens。增加了GitHub Issues, Pull Requests等高质量资源。
• 其他策划来源 (Curated Sources)：
  • Wikipedia, Books, arXiv, Stack Exchange。质量高但规模小。
• 合成数据 (Synthetic Data)：
  • 近年变得非常重要，未来可能更重要。
  • Microsoft的Phi系列模型 ("Textbooks are all you need") 引发关注，使用GPT-3.5/4生成合成教科书作为预训练语料。
  • Claude 3 和 Llama 3 均在预训练中使用了合成数据。Llama 3用其提升编码、推理和长上下文能力。
  • Cosmopedia (Hugging Face)：最大的合成文本数据集 (250亿tokens)，使用开源模型Mixtral 8x7B生成。方法：80%数据来自网络样本启发，结合Stanford课程、WikiHow等策划内容生成多样化教科书。

数据筛选：方法与实践 (Data Filtering: Methods and Practices)

高质量数据集对模型能力至关重要。

• 通用过滤流程 (以Ye论文为例)：
  1. 语言过滤。
  2. 低质量样本移除：如重复行过多、基于规则修正、困惑度过滤 (perplexity filtering)。
  3. 去重 (Deduplication)：
     • 精确去重 (Exact deduplication) 和 近似去重 (Near deduplication, 如MinHash)。
     • 至关重要，可防止模型记忆和过拟合。
  4. 语义/主题过滤 (Semantic/topic filtering)。
  5. FineWeb的优异表现归功于其精细的过滤和去重。
• 寻找有效过滤器：
  • 手动检查数据：总是一个好主意。
  • 消融实验 (Ablation studies)：
    • 在应用特定过滤器后的数据子集上训练小模型，对比有无此过滤器的效果。
    • Loubna团队经验：
      • 按“少评论”过滤代码，性能提升微乎其微。
      • 按“仓库星标少于5”过滤，移除了70%数据，导致模型性能最差。
    • 建议：选择高信号基准测试，使用不同随机种子多次训练以减少噪音。FineWeb作者进行了200多次消融实验。

StarCoder案例研究：代码大语言模型的训练

StarCoder是专为代码设计的LLM系列。

StarCoder数据筛选流程 (The Stack数据集)

• StarCoder (V1数据基础)：从6TB原始代码筛选至800GB用于训练。
• StarCoder 2 (V2数据基础)：从32TB (600种编程语言) 筛选至6.3TB。

• 筛选步骤：

  1. 语言选择：保留流行和维护中的语言。StarCoder 2包含600+语言。
  2. 额外数据源：GitHub Issues, Commits, Jupyter Notebooks (V1 & V2), Cargo Notebooks, Pull Requests (V2)。
  3. 数据质量检查：
     • 移除低质量和自动生成内容。
     • 指标示例：平均行长。不同语言阈值不同，需人工检查（BigCode社区每种扩展名检查100个样本）。
  4. 近似去重：
     • 性能提升最显著的步骤，且语言无关。
     • 示例：Python代码去重后，pass@1从13%提升到17%。
  5. 个人可识别信息 (PII) 移除：
     • 背景：GitHub代码中仍存在密钥、密码等敏感信息。
     • 方法：与标注公司合作标注PII数据 -> 训练StarPII (NER模型)检测PII -> 在整个StarCoder训练数据上运行StarPII (耗费800个A100 GPU小时)。
  6. 数据去污染 (Data Decontamination)：
     • 移除训练数据中的基准测试集和测试用例，避免评估结果虚高。
  7. 数据格式化：
     • 代码与文本不同，可进行特殊格式化辅助推理。
     • StarCoder：在代码文件前添加特殊tokens，如[repository_name], [file_name], [stars]。
     • StarCoder 2实现仓库感知 (repository-aware)：将同一仓库中的文件用特殊token（如[file_separator]）连接，使模型能理解文件间的关联。

• 相关工具：

  • 通用LLM：datatrove (过滤), nanotron (训练), lighteval (评估)。
  • 代码LLM：BigCode GitHub仓库提供The Stack和StarCoder模型相关代码。

代码大语言模型的特点与生态

• 起源：GitHub Copilot (基于OpenAI Codex模型) 的成功，证明了可以将代码视为文本进行处理，通过预测下一个token来生成代码。
• 现状：Hugging Face Hub上有超过1700个代码模型。部分模型在HumanEval上达到近80%的准确率。
• 主要模型和项目：
  • BigCode: The Stack数据集, StarCoder 1 & 2, StarChat2。
  • Meta: Code Llama系列 (7B到70B)。
  • DeepSeek: DeepSeek Coder系列。
  • 其他: IBM Granite, CodeQwen, CodeGen, StableCode。
• BigCode协作特点：
  • 完全数据透明，公开数据和代码。
  • 开放合作，超过1000名研究者参与。
  • The Stack被广泛用于训练其他代码模型 (CodeGen, StableCode)。StarCoder模型成为社区微调的基础。

负责任的开放与模型发布

一个开放且负责任的LLM发布应包含：

• 开放访问的数据集：提供数据检查工具和用户退出机制 (opt-out tools)。
• PII移除。
• 可复现性：公开处理流程和工具。
• 评估工具。
• 技术报告：详细记录整个流程。
• StarCoder系列进展：SantaCoder (消融实验模型) -> StarCoder (15B, 2023年发布) -> StarCoder 2 (2024年发布, 更多语言, 更高评估分数)。
• StarCoder被Stanford基础模型透明度指数评为最透明模型。

代码大语言模型的评估

• StarCoder性能：
  • StarCoder 15B发布时是SOTA代码模型。
  • StarCoder 2 15B在同级别模型中表现SOTA，甚至接近或优于更大模型（如匹配Code Llama 34B，在某些基准上接近DeepSeek Coder 33B）。
• 多基准评估的重要性：避免单一基准可能存在的污染问题，全面了解模型行为。
• StarCoder配套工具：VS Code插件，包含成员资格测试 (membership test)，尝试检测生成代码是否在训练数据中出现过，以支持代码溯源。
• 常用代码评估基准：
  • HumanEval: 模型自动完成函数，通过单元测试评估，计算pass@1。
  • MultiPL-E: HumanEval的多语言版本 (18种语言)。
• 评估挑战：污染与过拟合：
  • 尤其对指令微调模型，其训练数据可能与HumanEval等基准测试相似，导致污染。
  • LifeCoderBench：
    • 定期从CodeContests, LeetCode等平台抓取新题目。
    • 仅在模型发布日期之后出现的新问题上评估模型，确保无污染。
    • 发现一些模型在历史数据和新数据上表现不一致。
• 其他排行榜：比较开源与闭源模型（如GPT-4）的排行榜也值得关注。

代码大语言模型的微调应用

• 构建个人Copilot：
  • Sarab和Sayak的博客文章介绍了如何微调代码模型（如StarCoder, Code Llama）用于特定代码库（如Hugging Face内部库），并用Ollama部署为本地代码助手。
  • 流程：准备数据 (过滤、去重) -> 微调模型。
  • 可使用PEFT (Parameter-Efficient Fine-Tuning)库（如LoRA），在少量可训练参数下高效微调，7B模型甚至可在Google Colab上训练。

问答环节精选

• AI生成合成数据的后果：
  1. 强化偏见：生成模型自身的偏见可能被放大。
  2. 评估污染：合成数据可能与评估基准相似。Phi模型曾因此受到质疑。
• 合成数据与自然语言分布：
  • Cosmopedia最初表现不如网络数据，加入部分网络数据后有所改善。
  • 网络数据中的某些噪音和特定模式对模型覆盖自然语言分布可能必要。
  • 理想的训练集可能是合成数据与自然数据的混合。Phi-3技术报告也强调了过滤后的网络数据的重要性。
• RLHF与无监督预训练数据的重要性：
  • 无监督预训练用于获取基础模型。
  • 要使模型成为聊天助手，需进行有监督微调。目前指令微调 (instruction tuning)（使用指令-答案对训练）效果很好，不一定需要RLHF。DPO、RPO是RLHF的有效替代方法。
• 多模态数据是否减少对纯文本数据的需求：
  • 演讲者表示不确定，但指出当前多模态模型（如Idefics）仍包含大量文本数据。
• 文本LLM与代码LLM训练的主要差异 (除数据外)：
  • 架构相似 (StarCoder类似Llama/Mistral)。
  • 代码LLM可能更需长上下文能力（以容纳相关文件）。
  • 快速推理很重要 (GQA, MQA)。
  • 总体相似，但代码LLM可能更优先考虑小型化、快速模型以便IDE集成。
• 小计算预算 (单GPU) 微调建议：
  • 使用量化模型 (如Llama.cpp) 和PEFT技术 (如LoRA)。
  • 优先保证数据质量而非数量，选择精心策划的数据集。
• 最优训练数据量是否依赖领域和任务：
  • Chinchilla法则在英语和代码上结论相似。
  • 其他领域（如医疗）可能不同。DeepSeek论文显示规模法则对数据质量敏感。此领域研究尚不充分。
• 文本与代码的Tokenization差异：
  • 代码Tokenization需注意数字的切分。
  • StarCoder使用标准BPE，在其代码混合数据上训练Tokenizer，并进行健全性检查。
  • 总体与文本Tokenization接近。多数LLM的Tokenizer已包含大量代码。代码本身也含Markdown和自然语言。
• 微调与预训练的原则差异：
  • 数据准备不同。微调可能针对特定语言，过滤更严格。
  • 微调所需数据量远少于预训练。LIMA论文显示1000条指令即可取得良好微调效果。
  • 数据策划 (curation) 在微调中更为关键。
• 发布大型数据集的注意事项：
  • 技术层面：提供过滤工具和文档 (如The Stack)。
  • 治理层面：尊重许可证和版权，提供退出机制，确保PII已移除。
  • 可访问性：通过Hugging Face Hub等平台发布。
  • 敏感信息：对包含敏感信息的数据集（如用于PII检测的数据集）设置访问门槛。

核心观点总结

训练优秀的LLM是一个系统工程，其中数据是核心驱动力。从理解数据需求（规模法则）、拓展数据来源（网络、代码、合成数据）到精细化数据处理（过滤、去重、去污染、PII移除），每一步都至关重要。StarCoder等代码LLM的成功实践，进一步印证了通过精心数据治理和负责任的开放共享，可以构建出强大的专用模型。同时，对模型进行全面、无污染的评估以及探索高效的微调方法，是推动LLM技术发展和应用的关键环节。