搞大模型等于洗数据？LLM数据工程深度解析

最近一年在钻研大模型的过程中，观察到一种很有意思的风气：很多人觉得搞大模型嘛，核心就是喂数据，质量差点也无所谓。这其实是个挺深的误解。回看计算机视觉时代，ImageNet那300万张图片，每一张都靠人工标注，准确率要求97%以上——多少智能，就得付出多少人工。李飞飞正是靠着这份苦功夫，才让学术界看到了数据的真正价值。

数据在大型语言模型训练中的分量，怎么强调都不过分。无论是预训练还是后续的监督微调，有效的数据管理都是提升模型性能、提高训练效率的关键。2023年的实践很能说明问题：就算模型本身再强大，如果没有领域知识的协同配合，想上生产环境几乎是天方夜谭。这篇文章会结合相关论文和实际研发中的设计、开发、测试、知识QA case，尝试把通用的数据处理方法理清楚，同时聚焦研发场景中的具体任务——比如基础模型能不能完成任务、需要什么样的数据、数据从哪里来、该用增量训练还是SFT或知识库、如何构造训练数据集和检索知识库、推理时能不能用这些数据，以及怎么管理它们。

在知识密集型领域用通用大模型，主流的打法不外乎三种：

1. 领域自适应预训练（DAPT），也就是继续预训练或增量预训练。这一步通常需要引入领域专用的tokenizer。参考论文《Don’t Stop Pretraining: Adapt Language Models to Domains and Tasks》。

2. 监督微调（SFT），用通用和领域特定的指令来做模型对齐。

3. 检索增强生成（RAG），搭配一个经过领域自适应训练的检索模型。

研发大模型数据工程

可以把狭义的研发大模型数据工程理解为：根据具体的研发场景和任务，采集相关数据，生成模型预训练语料或微调数据集。事实上，增量预训练、SFT、RAG、Prompt这些环节都会用到数据，怎么处理和应用这些数据，就构成了广义的研发大模型数据工程。这些数据本质上就是研发资产——可能是作业用的原始数据，也可能是工程规范的积累。

参考《A Survey of Knowledge-Enhanced Pre-trained》和《A Comprehensive Survey on Instruction Following》，研发数据工程的核心诉求是：能处理所有类型的研发资产（文本、图像、知识图谱、数据库等），形成预训练语料或指令微调数据集，并针对不同的资产格式（文本、知识图谱、规则等）或研发场景任务（编码、单元测试、代码检视等），设计出详细的训练数据和分层知识库。

预训练阶段

预训练为大模型的能力打下了地基。在海量语料上做预训练，模型才能获得基本的语言理解和生成能力。预训练数据通常分为通用文本和专用文本两大类。

通用文本包括：

1. 网页，比如CommonCrawl，数据量巨大，能让模型学到多样化的语言知识，增强泛化能力。

2. 对话文本，比如公共对话语料，能增强模型的对话能力，改善问答任务的表现。

3. 书籍，比如Books3，提供更正式的语言素材，有助于建模长距离依赖关系和连贯文本生成能力。

专用文本则包括：

1. 多语言文本：整合多语言语料，提升跨语言的生成和理解能力。

2. 科学文本：比如论文、教材，能让模型在科学和推理任务中表现更好。

3. 代码：显著提升代码编写能力，甚至被认为是复杂推理能力（如思维链）的来源之一。

收集到大量文本后，预处理环节至关重要——尤其是要去除噪声、冗余、无关甚至有害的内容。这些脏数据会严重影响模型的能力。典型的预处理流程包括：

1. 质量过滤：通过设定规则，删除低质量数据。

2. 去重：重复数据会降低语言模型的多样性，需要在文档、段落、句子等不同层级上做去重。

3. 隐私去除：用户生成内容里可能包含敏感信息，需要从语料库中彻底删除。

4. 分词：将文本分解为词或子词，让机器更好地理解和分析。

《A Survey of Large Language Models》总结了准备预训练数据的一般流程：

1. 数据收集：整合多样化来源。如果模型要专注某种特定技能，相应来源的数据比例就要提高。

2. 数据清洗：去重、去低质量内容、去毒、去隐私数据，然后统一格式，训练分词器。

3. 数据调度：确定数据混合比例和训练顺序。实际操作中，可以先拿几个候选方案在小模型上试试，再选效果最好的。

持续预训练阶段：清洗领域语料

如果预训练语料和下游任务语料之间的数据分布或领域差异较大，就需要做持续预训练（也叫领域增强预训练或增量预训练）。这个差距本质上还是数据问题——token、word、n-gram的分布不同，以及它们出现的上下文不同。举个例子，假如你要从法律文档里做命名实体识别，却用着普通的bert-base-chinese，那最好先拿大量法律语料继续预训练，得到一个适配法律领域的模型。

领域预训练涉及数据设计（挖掘领域和领域任务数据）、训练方法设计（挖掘领域词汇）以及数据增强等。论文《Don't Stop Pretraining》表明，做领域自适应预训练（DAPT）能带来性能提升。如果后续再加上任务自适应预训练（TAPT），效果还能进一步优化。

多个研究都指出了分词的重要性。适配预训练分词器的主要目标是提高领域数据的token效率，同时保持通用数据集上的性能和减少重新训练的工作量。ChipNeMo提出的四步法值得借鉴：

• 第一步：用领域数据从头训练一个分词器。

• 第二步：从新分词器的词表中，找出那些在通用分词器里没有、且在通用数据集中很少出现的token。

• 第三步：用这些新token扩展通用分词器。

• 第四步：用通用分词器初始化新token的嵌入。

Lawyer LLaMA的案例显示，它的领域预训练语料包括从中国法院网站收集的判决书、法律文章、司法解释、法院新闻及各种法律普及文章。为了缓解常识遗忘，还会从悟道Corpus、CLUE Corpus和C4中抽取部分通用文本。

ChipNeMo则用了NVIDIA内部数据，涵盖设计、验证、基础设施和内部文档等与芯片设计相关的各种文本。

有些文献还提到，在预训练阶段直接使用微调数据或领域任务特定数据集，可以用更少的数据获得不错的效果——这实际上就是TAPT的思路。

持续预训练的数据工程和预训练阶段类似。目前研发方面选了Pangu 38B和Code LIaMa 34B作为基础预训练模型，后续会依据评估结果决定：

1. 补充研发通用知识的增量训练（待定）。

2. 对系统模型和检索模型，增加研发资产的增量训练。

微调阶段：构建指令格式

预训练之后，大模型具备了解决各种任务的通用能力。越来越多的研究表明，这些能力可以进一步适配到特定任务上。适配方法主要有两种：指令微调和对齐微调。前者是为了增强或解锁模型的能力，后者则是让模型行为更符合人类价值观或偏好。指令微调的关键一步，就是收集或构建指令格式的实例，然后用这些实例以有监督的方式微调模型。

一个指令格式的实例通常包括：任务描述（即指令）、一对输入和输出，以及可选的少量示例。目前已有大量开源的指令数据集，比如NLP任务类的P3、FLAN，对话类的OpenAssistant，以及合成类的Self-Instruct。具体的数据集结构可以参考Hugging Face。

指令格式的基本结构：

任务描述：XXX

示例（可选）：XXX

输入：XXX，输出：XXX

指令实例的质量直接影响模型性能。需要重点关注指令规模和格式设计。通常，给现有数据集的输入-输出对加上任务描述和可选示例就够了——任务描述是让模型理解任务的核心。适量的示例能带来实质性改进，还能降低模型对指令工程的敏感度。至于添加“避免事项”“原因”“建议”这类信息，收益其实很有限。如果想激发模型的逐步推理能力，建议在微调时同时包含有思维链和无思维链的样本。

Lawyer LLaMA提到了两种SFT策略：

1. 针对国家司法考试，把多选题转为问答风格，用了三种方法：JE-Q2EA（问题转解释+答案）、JE-QA2E（问题+答案转解释），以及JE-EXPERT（专家整理）。

2. 针对法律咨询，先从开源数据集中抽取婚姻相关的种子问题，再用ChatGPT扮演律师生成回答。为了避免模型引用过时或虚假的法律条文，还引入了一个法律文章检索组件，把检索到的前三篇文章附加到输入提示中。

ChipNeMo的SFT做法是：

1. 使用一个通用的聊天SFT指令数据集（可供商业用途），主要由OASST、FLAN、P3等公开数据集构成，加上一小部分专有数据，涵盖头脑风暴、开放式问答、重写、总结等主题。共包含128,000个训练样本，且不涉及芯片设计的下游用例。

2. 另外，针对三个下游用例（工程助手聊天机器人、EDA工具脚本生成、Bug总结与分析），由领域专家精心制作了一个领域特定的指令数据集，以单次问答形式呈现。这个数据集的样本量相对较小。

RAG：事实知识处理

总的来说，通用大模型缺乏领域专业知识，而且不实时。实验表明，即使让模型反复学习领域文章，它在生成回应时也未必能正确使用这些知识——可能会引用无关文章，或者混淆术语。为了让模型输出更可靠，通常的做法是把模型和检索模块结合起来。

Lawyer LLaMA的做法是：收集用户的法律咨询问题，请法律专业人员为每个问题标记最多3篇必要的法律文章。然后基于RoBERTa训练了一个法律文章检索模型，在保留集上能达到0.543的Macro Recall@1和0.807的Macro Recall@3。

ChipNeMo则指出，幻觉问题对工程助手聊天机器人的准确性影响尤其大，建议用RAG来缓解。研究发现，使用领域特定的语言模型做RAG，能显著提升答案质量；用适量领域特定数据微调检索模型，也能大幅提高检索准确度。它们的领域自适应RAG实现中，检索模型用的是微调后的E5。

当前在研发领域，RAG技术已经广泛应用：

1. 参与SFT数据集构建（SFTV3格式已经明确RAG参与）。

2. 参与推理时的Prompt构建，比如相似代码、API等场景（PromptCenter已对接RAG）。

此外，研发知识文档、大量向量化的研发资产，以及对语言模型进行QA微调，都是常见的做法。

推理阶段：数据参与Prompt工程

预训练或适配调整之后，使用大模型的主要方式就是为各种任务设计合适的提示策略——也就是提示工程。一个好的提示，能有效激发出模型完成特定任务的能力。设计提示时，有几个原则值得注意：清晰明确地表达任务目标、把复杂任务分解成易懂的子任务、提供少量示例、使用模型友好的格式。提示工程需要考虑的关键要素包括：任务描述、输入数据、上下文信息、提示风格以及示例。

1. 任务描述：应该用自然语言清楚地描述目标。对于输入或输出格式特殊的任务，还需要详细说明，可以用关键词突出特殊设置。

2. 输入数据：大多数情况下用自然语言描述即可。但对于知识图谱、表格、数据库等结构化数据，需要想办法让模型能读得懂，比如通过API。

3. 上下文信息：除了任务描述和输入数据，某些任务还需要背景信息。比如开放领域问答中，检索到的文档就是很好的支持证据。上下文描述能引导模型完成复杂任务，帮助它理解目标、输出格式以及输入输出之间的映射关系。

4. 提示风格：不同模型适合不同的风格。提示应该表达为一个清晰的问题或详细的指令。有些情况下，加上前缀或后缀能更好地引导模型——比如用“让我们逐步思考”来激发推理，或用“你是这个领域的专家”来提升特定任务的表现。

5. 示例：模型可以从上下文学习中受益，提示里包含少量高质量的输入-输出示例，能帮助模型学会语义映射，而无需调整参数。

目前研发领域通过SFT在代码生成的一些场景中，测试集命中率能超过50%，但实际开放给用户使用时只有20%左右。关键问题在于高质量的提示工程——比如如何传递代码逻辑关系、API调用等信息。研发资产数据如何参与提示构建，如何体现任务意图和上下文，这已经是当前最核心的挑战。

AI BOM：SBOM的扩展

把软件物料清单（SBOM）的概念扩展到“AIBOM”，通过记录AI训练数据的来源、模型架构、监控程序和其他AI特定元数据，可以提升透明度和风险评估能力。

Prompt、RAG、SFT的协同策略

需要明确的是，提示工程（含上下文学习）、微调和检索增强生成并不是互斥的，完全可以组合使用，取长补短。微调能让通用语言模型更好地适应特定任务；RAG则通过检索机制把模型和外部知识源连接起来，把生成能力与搜索整合能力结合到一起。两者互补，能产生强大的协同效应，显著提升模型性能和可靠性。

RAG在访问动态外部数据源和提供响应透明度方面表现出色，但微调为模型增加了一层关键的适应性和精细改进。没有微调，模型可能会反复犯同样的错误；而微调通过领域特定数据和纠错数据，能让模型学会纠正这些错误。此外，微调还能帮助模型学习所需的生成语气。

结合业界建议和2023年的实践经验，坚持“作业数据-语料-数据集SFT/知识库RAG-应用”的解耦原则，根据任务场景特点综合运用这些方法。当前研发场景下的SFT/RAG建议策略如下：

来源：互联网