★ FEATURED ARTICLE 1. 大模型数据格式的底层逻辑与设计哲学1.1 为什么数据格式是大模型训练的“隐形地基”很多人第一次接触大模型训练注意力全在模型结构、参数量、注意力机制上觉得数据格式不过是“把文本喂进去”这么简单。我刚开始也这么想直到有一次帮一个团队排查训练损失不收敛的问题折腾了三天最后发现是数据格式里多了一个看不见的特殊字符导致tokenizer把整段文本切得乱七八糟。从那以后我就明白数据格式不是配角它是整个训练流程的隐形地基。大模型数据格式要解决的核心问题其实就三个怎么把非结构化的原始内容变成模型能吃的数字序列、怎么让模型在训练时高效读取、怎么保证多轮对话或长文档的上下文不丢失。这三个问题对应了三个层面——编码层、存储层、组织层。编码层决定token怎么切、特殊标记怎么加存储层决定数据用什么文件格式落盘、怎么分片组织层决定样本怎么拼接、padding怎么处理、attention mask怎么生成。我见过太多项目在模型结构上反复调优却忽略了数据格式的规范性结果就是训练不稳定、评估指标忽高忽低。举个生活化的类比数据格式就像做菜前的备菜食材切得大小不一、该腌的没腌、该焯水的没焯后面火候掌握得再好菜的味道也不会对。大模型训练同理格式不对再好的超参搜索也是白费。1.2 从原始文本到训练样本的完整链路拆解一条原始数据要变成模型能用的训练样本中间要经过好几个环节每个环节都有格式上的讲究。我把它拆成五步原始采集可能是网页正文、PDF解析文本、对话日志、代码文件。这个阶段最大的坑是编码不统一有的UTF-8有的GBK混在一起后面必出乱码。清洗过滤去掉HTML标签、多余空白、乱码字符、重复段落。这一步的格式输出建议统一成纯文本每行一个段落方便后续处理。分词编码用tokenizer把文本转成token id序列。这里要注意特殊token的插入位置比如BOS、EOS、PAD、SEP不同模型的要求不一样。样本组装把多条短文本拼成固定长度或者把长文本截断。拼接时要加分隔符截断时要保留完整语义单元。格式落盘最终存成JSONL、Parquet、TFRecord、Arrow等格式供训练框架读取。这五步里分词编码和样本组装是格式问题的高发区。我实测下来至少七成的训练异常都能追溯到这两步。比如拼接时忘了加EOS模型就学不会“什么时候该停”截断时把一句话从中间切开模型就会学到残缺的语法模式。1.3 常见数据格式的选型对比与适用场景市面上主流的大模型数据格式就那么几种但选错了会直接影响训练效率和可维护性。我整理了一个对比表都是实际项目中踩过坑之后总结的格式可读性读取速度压缩率适用场景主要坑点JSONL高中低小规模调试、人工检查大文件读取慢内存占用高Parquet低高高大规模训练、列式读取schema变更麻烦嵌套结构复杂TFRecord低高中TensorFlow生态调试困难需要专门工具查看Arrow中极高中内存计算、快速迭代落盘体积大跨版本兼容性一般HDF5低中高科学计算、多维数组并发读写支持差选型的核心原则是调试阶段用JSONL正式训练用Parquet或Arrow超大规模用TFRecord或WebDataset分片。我一般会保留一份JSONL作为“人类可读版本”方便排查问题训练时再转成高效格式。这样既保证了可调试性又不牺牲训练速度。还有一个容易被忽略的点格式的元数据设计。比如每条样本的来源、长度、语言、质量分这些信息如果能在格式里带上后续做数据筛选和课程学习会方便很多。Parquet的列式存储在这方面优势明显可以只读取需要的列不用把整条样本加载进内存。2. 核心格式规范与实操细节解析2.1 预训练数据格式从原始语料到token序列预训练数据的格式目标很明确让模型看到尽可能多的高质量连续文本。但“连续”两个字说起来简单做起来全是细节。首先是文档边界处理。原始语料是一篇篇文章训练时要把它们拼成固定长度的序列。拼接方式有两种一种是简单拼接文档之间加一个EOS token另一种是加文档ID和位置编码让模型知道哪些token属于同一篇文档。我实测下来简单拼接在大多数场景下够用但如果文档很短、主题差异很大加文档边界信息会明显提升效果。其次是序列长度选择。这个不是拍脑袋定的要考虑三个因素模型的最大位置编码、显存容量、数据本身的长度分布。我一般会先统计语料的长度的分位数比如P50、P90、P99然后选一个能覆盖大部分数据又不超过显存的长度。举个例子如果P90是1024P99是4096那选2048或4096都合理选512就会截掉太多信息。然后是padding策略。预训练阶段一般用“拼接截断”不做padding因为每条样本都是满的。但如果是多任务混合训练不同任务长度差异大就需要padding。padding token的选择要注意有些模型的pad token和eos token是同一个这时候要确保attention mask正确屏蔽pad位置否则模型会把padding当成真实内容学习。注意预训练数据里如果混入了大量重复文本模型会反复记忆同样的内容导致泛化能力下降。我一般会用MinHash或SimHash做去重相似度阈值设在0.8到0.9之间具体看数据质量。还有一个实操细节特殊token的添加顺序。以常见的自回归模型为例一条样本的格式通常是[BOS] token_ids [EOS]。但有些框架会自动加BOS有些不会如果两边都加就会变成[BOS][BOS]...模型训练时看到两个BOS会困惑。我的做法是统一在数据格式里不加BOS由训练框架的collator统一处理这样责任清晰不容易出错。2.2 指令微调数据格式让模型学会“听懂人话”指令微调的数据格式比预训练复杂得多因为它要表达“指令-输入-输出”的三元结构。最常见的格式是Alpaca风格{ instruction: 把下面的句子翻译成英文, input: 今天天气很好, output: The weather is nice today. }这种格式简单直观但有个问题当input为空时很多模板会留下一个空的输入段导致模型看到奇怪的格式。我一般会在数据预处理时判断如果input为空就只保留instruction和output模板里也不渲染input部分。另一种主流格式是ShareGPT风格用对话列表表示多轮交互{ conversations: [ {from: human, value: 你好请介绍一下自己}, {from: gpt, value: 我是一个语言模型...}, {from: human, value: 你能做什么}, {from: gpt, value: 我可以帮你...} ] }这种格式的好处是天然支持多轮对话而且角色标记清晰。但要注意不同模型的对话模板不一样有的用|user|和|assistant|有的用[INST]和[/INST]。数据格式里最好只存原始对话内容模板渲染交给训练框架这样换模型时不用重新处理数据。我在实际项目里踩过最大的坑是loss mask的设置。指令微调时我们通常只计算output部分的loss不计算instruction和input部分的loss。如果数据格式里没有明确标记哪些token需要计算loss训练框架可能会把整条样本都算进去导致模型学会“复述指令”而不是“回答问题”。我的做法是在数据里加一个loss_mask字段或者用固定的模板分隔符让框架能自动识别。提示指令微调数据的质量比数量重要得多。我见过用几千条高质量数据微调出来的模型效果远超用几十万条低质量数据训练的。格式规范只是基础内容质量才是上限。2.3 多轮对话与长上下文的数据组织方式多轮对话的数据组织有两个核心问题轮次截断和上下文拼接。轮次截断是指当对话轮次太多、总长度超过模型最大长度时怎么截。常见策略有三种从最早轮次开始截、从中间截保留最近几轮、按重要性截。我一般用“保留最近N轮系统提示”的策略因为最近的对话通常和当前回复最相关。但要注意如果系统提示很长也要算进长度预算里。上下文拼接是指把多轮对话拼成一个序列时怎么标记每轮的边界。最直接的方式是用特殊token分隔比如|turn_start|和|turn_end|。但有些模型没有预训练过这些token突然加进去会让模型困惑。更稳妥的方式是用模型原本就见过的分隔符比如换行加角色名。长上下文的数据格式又是另一回事。当序列长度达到8K、32K甚至128K时位置编码的处理方式会直接影响效果。有些模型用RoPE有些用ALiBi数据格式本身不需要变但要注意训练时的位置ID生成方式。我遇到过一个问题数据拼接时没有重置位置ID导致第二篇文档的位置从第一篇的末尾继续数模型看到的位置信息就乱了。正确的做法是每篇文档重新从0开始计位置或者用文档边界标记告诉模型“这里重新开始”。还有一个实操技巧长上下文数据最好按长度分桶。把长度相近的样本放在一个batch里可以减少padding浪费提升训练效率。我一般会按512、1024、2048、4096、8192分几个桶每个桶内再随机打乱。这样显存利用率能提升30%以上。2.4 数据格式的版本管理与兼容性设计数据格式不是定下来就不变的。随着项目推进你可能需要加字段、改结构、换编码方式。如果没有版本管理旧代码读新数据就会报错新代码读旧数据也会出问题。我的做法是在数据目录里放一个schema文件用JSON描述当前数据的字段、类型、版本号。每次格式变更就升一个版本号并在schema里记录变更内容。训练代码读取数据前先检查schema版本不匹配就给出明确提示而不是默默出错。{ version: 1.2.0, fields: { instruction: {type: string, required: true}, input: {type: string, required: false}, output: {type: string, required: true}, source: {type: string, required: false}, quality_score: {type: float, required: false} }, changelog: [ {version: 1.1.0, change: 新增source字段}, {version: 1.2.0, change: quality_score改为可选} ] }这样做的好处是数据生产者和消费者之间有明确的契约。数据团队知道要产出什么格式训练团队知道能读到什么字段出了问题也能快速定位是哪个版本的变化导致的。注意不要轻易删除字段哪怕你觉得没用了。我见过一个项目把source字段删了结果后来要做数据溯源时发现根本查不到每条数据来自哪里只能重新跑一遍数据处理流程浪费了大量时间。字段可以标记为deprecated但保留着总没错。3. 实操过程与核心环节实现3.1 从零构建一套指令微调数据格式的完整流程假设你手头有一批原始对话日志想把它变成能用于指令微调的标准格式。我按实际操作的顺序把每一步都拆开讲。第一步原始数据摸底。先抽样看100条数据了解它的结构。是单轮问答还是多轮对话有没有角色标记文本里有没有HTML标签或特殊字符这一步的目的是确定清洗规则和格式转换的映射关系。我一般会写个简单的脚本统计每条数据的长度分布、字符集分布、角色标记的出现频率。第二步定义目标格式。根据你的训练框架和模型类型确定最终要什么格式。如果是LLaMA Factory它支持Alpaca和ShareGPT两种如果是自己写的训练脚本那就按自己的需求定。我建议用ShareGPT风格存多轮对话用Alpaca风格存单轮指令两者可以共存于同一个数据集用type字段区分。第三步编写转换脚本。这一步的核心是字段映射和模板渲染。比如原始数据里角色叫speaker值是user和bot目标格式里要变成human和gpt那就写个映射字典。模板渲染要注意转义特别是当文本里本身包含{或}时用f-string会报错我一般用str.replace或Template类来做。# 一个简单的转换示例 def convert_to_sharegpt(raw_item): conversations [] for turn in raw_item[dialogue]: role human if turn[speaker] user else gpt conversations.append({ from: role, value: turn[text].strip() }) return {conversations: conversations}第四步质量过滤。转换完之后不能直接用要过几道筛子太短的对话去掉比如总长度少于10个token、包含敏感词的去掉、重复的去掉、格式异常的去掉。我一般会设几个阈值单轮长度下限、总轮次下限、字符重复率上限。这些阈值不是拍脑袋定的而是根据数据分布的分位数来选。第五步格式校验。写一个校验脚本检查每条数据是否符合schema定义必填字段有没有、类型对不对、对话轮次是不是human和gpt交替、有没有空的value。校验不通过的数据单独存一个文件人工抽查原因。这一步能拦住大部分低级错误。第六步落盘与分片。最终数据存成JSONL或Parquet按一定大小分片比如每片100MB或10万条。分片的好处是读取时可以并行而且单个文件不会太大导致内存溢出。我一般还会生成一个索引文件记录每片的路径、条数、长度分布方便后续采样。3.2 数据格式转换中的参数计算与选择依据在格式转换过程中有几个参数需要根据实际情况计算不能随便填。最大序列长度这个参数直接影响显存占用和训练效率。计算方法是对所有样本的长度做统计看P95或P99是多少。如果P99是2048那最大长度设2048能覆盖99%的样本剩下的1%截断。但截断也有讲究如果截断后output部分完全没了这条样本就废了应该直接丢弃而不是截断。我一般会保证截断后至少保留output的前N个tokenN取32或64。padding长度如果是按batch动态padding那每个batch的padding长度就是该batch内最长样本的长度。如果是固定长度padding那就要选一个覆盖大多数样本的长度。固定长度的好处是计算图稳定坏处是短样本浪费严重。我实测下来动态padding能节省20%到40%的显存但需要框架支持。分片大小分片太大读取慢分片太小文件数量多、管理麻烦。我的经验值是每片100MB到500MB之间具体看单条样本的平均大小。如果单条样本平均10KB那每片1万到5万条比较合适。另外分片时最好保证同一来源的数据尽量在同一片里这样读取时局部性更好。重复率阈值去重时用的相似度阈值我一般设在0.85到0.95之间。太低会误删正常数据太高去重不干净。具体值要看数据特点如果是新闻类文本0.9比较合适如果是代码0.95更稳妥因为代码的相似度天然就高。提示所有参数都不要硬编码在脚本里用配置文件管理。这样换数据集时只改配置不用改代码。我习惯用YAML或JSON存配置每个数据集一个配置文件版本化管理。3.3 大规模数据格式的并行处理与性能优化当数据量到了TB级别单机处理就扛不住了必须上并行。我一般用两种方案多进程和分布式框架。多进程适合单机多核的场景。Python的multiprocessing配合tqdm可以很方便地做并行转换。关键是要把数据分块每个进程处理一块最后合并结果。注意进程间不要共享状态每个进程独立读写自己的输出文件避免锁竞争。from multiprocessing import Pool def process_chunk(chunk_id): # 读取chunk_id对应的数据块 # 转换格式 # 写入输出文件 return chunk_id with Pool(processes8) as pool: results pool.map(process_chunk, range(100))分布式框架适合数据量特别大或者需要跨机处理的场景。我用的比较多的是Ray和Dask。Ray的map操作可以自动分发到多个节点而且支持流式处理不用把全部数据加载进内存。Dask的DataFrame接口和Pandas很像学习成本低适合做结构化数据的转换。性能优化方面有几个点特别值得注意IO是瓶颈读JSONL比读Parquet慢很多如果原始数据是JSONL建议先转成Parquet再做后续处理。我实测过同样数据量Parquet的读取速度是JSONL的5到10倍。避免频繁的小文件读写每处理一条就写一次文件磁盘IO会爆炸。正确的做法是攒一批再写比如每1000条写一次。压缩算法选择Parquet默认用Snappy压缩速度快但压缩率一般。如果存储空间紧张可以用Zstd压缩率更高但CPU占用也高。我一般用Snappy因为训练时读取速度更重要。内存管理处理大文件时不要一次性读进内存用生成器逐行读。Python的ijson库可以流式解析JSON比json.load省内存得多。3.4 格式验证与自动化测试的落地方法数据格式出了问题最好在训练之前就发现而不是训练到一半loss爆炸了才去查。我一般会建一套自动化测试每次数据更新都跑一遍。Schema校验用pydantic或jsonschema定义数据模型每条数据都过一遍校验。必填字段缺失、类型不对、值超出范围都能自动抓出来。from pydantic import BaseModel, validator class Conversation(BaseModel): from_: str value: str validator(from_) def check_role(cls, v): if v not in (human, gpt, system): raise ValueError(f非法角色: {v}) return v class Sample(BaseModel): conversations: list[Conversation] validator(conversations) def check_alternating(cls, v): # 检查角色是否交替出现 for i in range(1, len(v)): if v[i].from_ v[i-1].from_: raise ValueError(角色未交替) return v统计校验除了单条校验还要做整体统计。比如平均长度、长度分布、角色比例、重复率。如果某个指标和上次相比变化超过阈值就报警。我遇到过数据源更新后新数据的平均长度突然翻倍导致训练时显存溢出如果有统计校验就能提前发现。端到端测试拿一小批数据跑一遍完整的训练流程看能不能正常前向传播、loss是不是在合理范围。这个测试不用跑很多步几十步就够了目的是验证格式和训练框架的兼容性。回归测试每次修改数据格式或处理脚本都要用固定的测试集跑一遍确保输出和预期一致。我一般会保留一个“黄金数据集”包含各种边界情况空input、超长output、多轮对话、特殊字符、中英文混合。任何改动都不能让这些样本的处理结果发生非预期变化。注意自动化测试不是万能的它只能检查你想到的问题。我建议每周抽半天时间人工看一批数据特别是新加入的数据源。机器检查格式人检查内容两者缺一不可。4. 常见问题与排查技巧实录4.1 训练loss异常时如何从数据格式角度排查loss不收敛或者突然飙升很多人第一反应是调学习率、换优化器但我的经验是先查数据格式。下面是我常用的排查顺序第一步看loss曲线形态。如果loss从一开始就很高且不下降大概率是数据格式和模型不匹配比如token id超出了词表范围。如果loss正常下降然后突然飙升可能是某批数据有问题比如混入了空样本或超长样本。第二步检查token id范围。把数据里的token id取出来看最大值和最小值。如果最大值超过了词表大小说明tokenizer和模型不匹配。我遇到过用A模型的tokenizer处理数据却用B模型训练的情况词表对不上loss直接爆炸。第三步检查特殊token。看数据里有没有不该出现的特殊token比如PAD出现在中间、EOS出现在开头。这些异常会让模型学到错误的模式。我一般会统计每个特殊token的出现位置分布如果PAD大量出现在非末尾位置就有问题。第四步检查attention mask。如果用了paddingattention mask必须正确设置。我见过一个bug是mask全为1导致模型把padding也当成真实token训练出来的模型对padding位置特别敏感。第五步检查label对齐。自回归模型的label通常是input向右移一位。如果数据格式里已经包含了label要确保和input对齐。我一般会在训练脚本里打印前几条样本的input和label人工核对。下面是一个快速排查的对照表现象可能原因排查方法loss不下降token id越界、词表不匹配检查token id最大值loss突然飙升混入异常样本、空样本按batch检查loss定位异常batchloss震荡大数据长度差异大、padding过多统计长度分布检查padding比例模型输出重复数据里重复文本多、EOS缺失检查重复率确认EOS位置模型不停止EOS被mask、EOS token错误检查loss mask和EOS id4.2 数据格式不兼容导致的典型报错与解决不同训练框架对数据格式的要求不一样换框架时经常遇到兼容性问题。我整理了几个最常见的报错和解决方法。报错一KeyError: instruction。这通常是因为数据是ShareGPT格式但框架期望Alpaca格式。解决方法是写一个适配层在数据加载时做格式转换而不是改数据本身。这样同一份数据可以适配多个框架。报错二ValueError: Expected input batch_size to match target batch_size。这是label和input的batch size不一致常见于padding处理不当。检查collator里的padding逻辑确保input_ids、attention_mask、labels的shape一致。报错三RuntimeError: CUDA out of memory。不一定是模型太大也可能是数据里混入了超长样本。我遇到过一条样本长度是10万token直接把显存打满。解决方法是在数据加载时加长度过滤超过阈值的直接丢弃或截断。报错四TypeError: Object of type int64 is not JSON serializable。这是numpy类型和Python原生类型混用导致的。在保存JSONL之前把numpy类型转成Python原生类型用int()、float()、str()包一下。报错五UnicodeDecodeError。编码问题原始数据里混了非UTF-8字符。解决方法是用errorsignore或errorsreplace打开文件或者先做编码检测和转换。提示遇到报错不要急着改数据先看框架的文档和源码理解它期望什么格式。很多时候是配置问题不是数据问题。我一般会在框架的issue区搜一下报错信息大概率有人遇到过同样的问题。4.3 数据格式的常见坑点与避坑清单干了这么多项目踩过的坑实在太多了我挑几个最有代表性的列出来希望能帮你省点时间。坑一换行符不统一。Windows是\r\nLinux是\nMac是\r。混在一起会导致tokenizer把\r当成独立字符增加序列长度还引入噪声。处理时统一替换成\n。坑二BOM头。有些UTF-8文件开头有\ufeff这个字符不可见但会占一个token。用utf-8-sig编码打开可以自动去掉。坑三全角半角混用。中文文本里经常混着全角逗号和半角逗号tokenizer可能把它们当成不同token。如果对一致性要求高可以做全角转半角处理。坑四特殊字符转义。JSONL里如果文本包含双引号或反斜杠必须转义否则解析会失败。用json.dumps自动处理不要手动拼字符串。坑五空样本。清洗后可能产生空字符串或只有空白的样本这些样本会让loss变成NaN。过滤掉长度小于阈值的样本。坑六标签泄漏。指令微调时如果input里包含了output的内容模型会直接抄input评估指标虚高但实际能力很差。检查input和output的重叠度重叠太高的样本要处理。坑七数据顺序偏差。如果数据按来源排序训练时又不打乱模型会先学好一个领域再学另一个导致灾难性遗忘。训练前一定要全局打乱。坑八分片边界截断。分片时如果按行数分可能把一条多轮对话切到两个片里。要按完整样本分片不能按行分。4.4 数据质量监控与持续迭代的实操经验数据格式不是一次性的工作而是持续迭代的过程。我一般会建一个数据质量看板监控几个核心指标格式合规率通过schema校验的样本比例目标100%。长度分布P50、P90、P99长度和上次相比的变化。角色比例human和gpt的轮次比例是否接近1:1。重复率去重后剩余样本的比例。特殊token比例PAD、EOS等特殊token的占比是否在合理范围。这些指标每天自动跑一次异常时发通知。我遇到过数据源更新后格式合规率从100%掉到60%及时发现了问题避免了污染整个训练集。除了自动监控我还会定期做人工抽检。每次抽100条逐条看内容质量、格式正确性、有没有敏感信息。这个工作很枯燥但非常必要。机器只能检查格式内容质量还得靠人判断。最后分享一个经验数据格式的文档要跟着代码一起更新。我见过太多项目代码改了但文档没改新人接手时按旧文档处理数据结果格式对不上。我的做法是把格式说明写在代码仓库的README里每次改格式必须同时改README代码review时一起检查。5. 不同训练阶段的数据格式策略5.1 预训练、微调、对齐阶段的数据格式差异大模型训练分几个阶段每个阶段的数据格式目标不一样不能一套格式用到底。预训练阶段的目标是让模型学习语言的基本规律数据格式追求简单、连续、大规模。通常就是纯文本拼接加BOS和EOS不做复杂的指令模板。这个阶段的数据格式最“粗糙”但数据量最大格式的一致性比精细度更重要。指令微调阶段的目标是让模型学会遵循指令数据格式要清晰表达指令和响应的边界。Alpaca或ShareGPT格式都行关键是要让模型能区分哪些是输入、哪些是该生成的输出。这个阶段的数据量小很多但格式要求更精细每条样本都要人工或自动检查质量。对齐阶段比如RLHF或DPO的目标是让模型的输出符合人类偏好数据格式要包含偏好信息。比如DPO需要chosen和rejected两个响应格式上就是一对多的结构。这个阶段的数据格式最复杂而且不同对齐算法的格式要求还不一样。我一般会为每个阶段维护独立的数据格式定义不要试图用一套格式覆盖所有阶段。预训练数据转成微调格式时要重新处理不能直接复用。5.2 多模态数据格式的特殊考量多模态大模型的数据格式比纯文本复杂一个量级因为要同时处理文本和图像、音频、视频等模态。图像数据的格式核心是路径引用和特征对齐。通常不会把图像直接塞进JSONL而是存图像路径或URL训练时再加载。格式里要包含图像路径、图像描述文本、以及图像和文本在序列中的位置关系。比如LLaVA格式用image占位符标记图像位置训练时再把占位符替换成图像特征。音频数据类似存音频路径和采样率文本里用特殊token标记音频片段的位置。要注意音频长度和文本长度的对齐太长的音频要截断或分段。视频数据最复杂因为有时序信息。格式里要包含帧路径、时间戳、对应的文本描述。我见过的做法是把视频抽成关键帧每帧当一张图像处理帧之间用时间戳标记顺序。多模态数据格式最大的坑是模态对齐。文本里说“图中的猫”图像里必须真的有猫而且位置要对。如果对齐错了模型会学到错误的跨模态关联。我一般会做交叉校验用图像描述模型生成描述和原始文本对比相似度太低就人工检查。5.3 数据格式的自动化流水线设计当数据源多、更新频繁时手动处理不现实必须建自动化流水线。我设计的流水线一般分四层采集层从各个数据源拉取原始数据统一存到原始数据区。这一层不做任何处理只做归档和版本标记。清洗层做格式统一、去重、过滤、脱敏。输出是干净的纯文本或结构化数据。这一层的输出格式要稳定下游依赖这个格式。转换层把清洗后的数据转成训练需要的格式。这一层可以根据不同的训练阶段输出不同的格式比如预训练格式、微调格式、对齐格式。验证层对转换后的数据做schema校验、统计校验、端到端测试。通过验证的数据才能进入训练数据区。每一层之间用文件系统或对象存储解耦上层不关心下层的实现细节。这样任何一层出问题都可以单独重跑不用从头再来。流水线的调度我一般用Airflow或Prefect每天定时跑也可以手动触发。关键是要有幂等性同样的输入跑多次输出应该一样。这要求处理逻辑是确定性的不能依赖随机数或当前时间。注意流水线一定要有回滚机制。如果新一批数据有问题要能快速切回上一批。我一般会保留最近三个版本的数据出问题随时回滚。6. 工具链与生态适配6.1 主流训练框架的数据格式要求对比不同训练框架对数据格式的偏好不一样选框架时要把数据格式的适配成本算进去。框架推荐格式是否支持流式自定义模板学习曲线LLaMA FactoryAlpaca/ShareGPT支持支持低AxolotlYAML配置JSONL支持支持中DeepSpeedJSONL/Arrow支持需改代码高Megatron-LM二进制索引支持需改代码很高HuggingFace Trainer任意Dataset支持支持低我的建议是小规模实验用LLaMA Factory或HuggingFace Trainer大规模训练用Megatron-LM或DeepSpeed。但不管用哪个数据格式最好保持一份“标准版”用适配层转成框架需要的格式。这样换框架时不用重新处理数据。适配层的实现方式很简单写一个Dataset类读取标准格式在__getitem__里转成框架需要的格式。这样数据只存一份框架随便换。6.2 数据格式转换的常用工具与脚本我日常用的数据格式转换工具就那么几个但每个都很实用。jq命令行处理JSON的神器。查看、过滤、转换JSONL特别方便。比如jq -c .conversations[] data.jsonl可以展开对话列表。虽然学习曲线有点陡但学会了效率极高。Pandas/Polars处理结构化数据。Polars比Pandas快很多特别是大文件读取和groupby操作。我一般用Polars做数据统计和过滤用Pandas做小规模调试。Datasets库HuggingFace的Datasets库支持多种格式的读写而且自带缓存和流式处理。load_dataset可以读JSONL、Parquet、CSVmap可以做并行转换。我一般用它做格式转换的中间层。自定义脚本有些特殊需求工具搞不定就得自己写。我一般用Python写核心逻辑就三个读、转、写。读用生成器转用纯函数写用批量写。保持简单不要过度设计。# 一个通用的格式转换脚本框架 def convert(input_path, output_path, convert_fn, batch_size1000): batch [] with open(input_path, r, encodingutf-8) as fin: for line in fin: item json.loads(line) converted convert_fn(item) if converted is not None: batch.append(converted) if len(batch) batch_size: write_batch(output_path, batch) batch [] if batch: write_batch(output_path, batch)这个框架的好处是内存友好不管多大的文件都能处理。convert_fn是纯函数方便测试和复用。6.3 格式转换中的性能瓶颈与优化手段格式转换看起来简单但数据量大了之后性能问题很突出。我遇到过转换1TB数据跑了三天的情况后来优化到半天主要做了这几件事用Parquet替代JSONLJSONL的解析是逐行的CPU占用高。Parquet是列式存储读取时可以只读需要的列而且压缩率高IO量小。我实测下来同样数据量Parquet的读取速度是JSONL的5到10倍。批量处理替代逐条处理逐条读写文件系统调用开销大。改成批量读写比如每1000条写一次性能提升明显。多进程替代单线程Python的GIL限制了多线程的CPU利用率用多进程可以绕过。multiprocessing.Pool配合分块处理能线性提升速度。避免不必要的序列化如果中间步骤不需要落盘就在内存里传递。比如清洗和转换可以合并成一个步骤不用先写清洗结果再读进来转换。用C扩展或Rust加速如果某个转换逻辑特别耗时可以考虑用Cython或Rust重写。比如正则替换Python的re模块已经很快了但如果数据量特别大用Rust的regex库会更快。提示优化之前先profile找到真正的瓶颈。我一般用cProfile或py-spy看时间花在哪里。很多时候瓶颈不在你以为的地方比如可能是磁盘IO而不是CPU。7. 从数据格式看大模型训练的效率与质量平衡7.1 格式选择对训练效率的实际影响数据格式对训练效率的影响比大多数人想象的要大。我做过一组对比实验同样的模型、同样的数据量只改数据格式训练速度差了将近一倍。JSONL vs ParquetJSONL需要逐行解析CPU占用高而且不能并行读取。Parquet可以按列读取支持谓词下推读取速度快很多。在数据加载成为瓶颈的场景下Parquet能提升30%到50%的训练吞吐。固定长度 vs 动态长度固定长度padding会浪费大量计算在padding token上。如果数据长度分布很广比如从10到4096都有固定长度4096的话平均可能有50%以上的计算是浪费的。动态长度能把这部分省下来。预取 vs 实时读取训练时数据加载和GPU计算是串行的如果数据加载慢GPU就会空闲。用预取prefetch可以让数据加载和计算重叠GPU利用率能提升20%以上。PyTorch的DataLoader自带prefetch设置num_workers和prefetch_factor就行。内存映射 vs 全量加载如果数据能全部放进内存那最快。放不下的话用内存映射memory map比全量加载快因为操作系统会按需加载页面。Arrow格式天然支持内存映射读取大文件时优势明显。7.2 数据格式对模型最终效果的影响机制数据格式不仅影响训练速度还影响模型最终效果。这个影响是间接的但很显著。格式一致性影响模型稳定性如果训练数据里格式不统一比如有的样本有BOS有的没有模型会学到不一致的模式导致输出不稳定。我做过对比格式统一的数据训练出来的模型在生成时的重复率和截断率都明显更低。特殊token的使用影响模型行为EOS的位置和数量直接影响模型什么时候停止生成。如果训练数据里EOS缺失或位置不对模型就学不会正常停止。PAD的处理影响模型对padding位置的注意力如果attention mask不对模型会浪费容量在padding上。样本拼接方式影响长距离依赖预训练时文档怎么拼接影响模型学到的长距离依赖模式。如果拼接时没有文档边界标记模型会把不同文档的内容当成连续的学到错误的关联。加上边界标记后模型能更好地区分文档内和文档间的关系。数据顺序影响学习轨迹训练数据的顺序会影响模型的收敛路径。如果数据按难度排序从易到难模型收敛更稳定。如果随机打乱模型需要更多步才能收敛。我一般会用课程学习的思路先易后难地组织数据。7.3 面向未来的数据格式演进趋势数据格式也在不断演进几个趋势值得关注。流式格式的普及WebDataset格式把数据存成tar分片支持流式读取不用把全部数据加载进内存。这对超大规模训练特别友好而且和云存储的兼容性好。多模态统一格式随着多模态模型的发展文本、图像、音频的格式正在走向统一。比如用一套schema描述所有模态用modality字段区分。这样数据处理流水线可以复用不用为每个模态单独写一套。动态格式与自适应未来的数据格式可能会根据训练阶段动态调整。比如训练初期用简单格式快速迭代训练后期用精细格式提升质量。格式不再是静态的而是训练策略的一部分。格式与硬件的协同设计数据格式的设计会更多考虑硬件特性。比如针对GPU的显存层次设计更适合缓存的数据布局针对NVMe SSD的高吞吐设计更大块的数据分片。这些趋势现在还在早期但方向是明确的数据格式会越来越“智能”越来越贴近训练的实际需求而不是简单的存储约定。作为从业者保持对格式演进的关注能让你在项目选型时更有前瞻性。我个人在实际操作中的体会是数据格式这件事投入产出比极高。花一天时间把格式规范好后面能省下一周甚至一个月的调试时间。反过来格式上偷的懒后面都会以各种奇怪的方式还回来。所以我的建议是在项目早期就把数据格式当成一等公民来对待定义清楚、文档写全、测试覆盖后面会轻松很多。
阅读完成 · 觉得有帮助？
