简介面向大模型研发者的训练与测试语料包聚焦自然语言处理场景下的指令微调、预训练与对齐评测需求。资源采用Alpaca与ShareGPT两种主流格式组织共14个JSON文件压缩包仅65.32MB便于下载、携带和复用适合本地测试及小规模实验。文件覆盖中英文指令数据、预训练语料片段以及奖励模型训练集包含Alpaca中文指令、GPT-4生成对齐数据与对比评测数据等代表性内容可用于监督微调、RLHF及模型效果测试。语料既有新闻、社交媒体、百科全书等通用型互联网文本也包含法律、财务、医学等垂直领域内容兼顾通用知识与专业应用预训练语料库规模通常最大大量无标注语料可帮助模型从海量文本中习得广泛知识与语言规律再经指令微调和对齐训练提升理解与生成能力。整体格式清晰无论是快速验证模型效果还是构建领域问答集都能从中提取所需语料。目前已有1515人学习下载适合需要配置大模型训练语料、搭建评测集或开展数据清洗的算法工程师与研究者。 去年下半年我接到一个挺扎手的任务给一个即将上线的大模型产品搭一套完整的测试训练语料数据体系。一开始我以为这事不难无非是找几份公开数据集、做点清洗、切成训练集和测试集后来真正动手才发现LLM 的语料工程远不是“攒数据”这么简单。同样是“语料数据”训练语料、测试语料、评测基准三者的定位完全不同混用一次轻则模型评测分数虚高重则上线后面对真实用户时暴露出大量幻觉和拒答问题。这篇文章我打算从头梳理一遍大模型测试训练语料数据的整体思路、构建细节和实战流程重点聊哪些坑值得提前避开。内容面向想系统搭建语料体系的算法工程师、数据负责人也照顾刚入门、想搞清楚“测试集和训练集到底怎么切”的初学者。看完之后你应该能自己动手搭出一套可复用、可迭代的语料数据管线。1. 语料数据的整体版图训练、测试、评测各司其职1.1 训练语料和测试语料别混着用很多第一次做大模型项目的团队最容易犯的错误就是把“语料”当成一个筐什么东西都往里装。其实按用途区分语料数据至少要分成三条线训练语料、测试语料、评测基准。训练语料喂给模型决定了模型“学会了什么”。预训练阶段用的是海量网页、书籍、代码、论文目标是让模型具备语言能力和世界知识微调阶段用的是指令数据、对话数据、领域数据目标是让模型学会遵循指令、匹配特定业务场景。测试语料则完全是另一回事它不参与任何参数更新只用来检验模型“学得怎么样”。一条测试样本如果混进了训练集后面所有指标都等于开卷考试分数再好看也没有参考意义。评测基准可以理解为公开的标准化测试语料比如 MMLU、GSM8K、BBH 这类榜单数据集。它们的好处是能横向对比不同模型的能力坏处是跟具体业务场景往往对不上。真实的业务测试语料必须从自己的产品需求出发去构建这也是这篇文章想重点讲的部分。提示训练集、验证集、测试集三者的划分比例没有绝对标准但一个可以落地的经验值是基座模型预训练阶段不需要单独留验证集微调和评测阶段才需要严格控制切分。验证集用来调参测试集只用来做最终评估测试集一旦用过一次就要考虑它是否已经被模型“记住”。1.2 为什么公开 benchmark 不能直接当业务测试集我见过不少团队直接用 MMLU 和 C-Eval 的分数来验收自己的业务模型天然是跑偏的。公开 benchmark 测的是通用能力而业务场景往往有很强的领域属性。比如你做的是农业领域的大模型要监测土壤墒情、气象数据、给出灌溉施肥建议那你的测试语料里就需要大量带传感器数据格式的样本土壤湿度、温度、降雨量、作物生长期、施肥建议之间的映射关系对不对而不是问模型“法国首都是哪里”。另外还有一个很现实的问题公开 benchmark 的数据很可能已经出现在模型的预训练语料里了。预训练阶段抓取互联网数据时MMLU 这类知名数据集经常被“顺带”抓进去导致模型在榜单上分数虚高。放到业务场景就是你今天测出来 85 分上线后真实用户一问实际效果可能只有 60 分。所以在实际项目中我会把测试语料分成两层一层是公开 benchmark只用来做横向参考另一层是自建的业务测试语料从产品真实问题里抽样本、由领域专家标注、结果脚本自动化评估。第二层才是验收模型能不能上线的核心依据。1.3 不同落地场景的语料需求差异语料数据的形态跟场景强相关我简单按场景拆一下通用聊天助手需要覆盖闲聊、知识问答、观点表达、拒绝回答等能力域语料形态以多轮对话为主。RAG 知识库问答像 AnythingLLM 这类工具接上本地知识库后测试语料需要围绕文档内容制作问题要能对应到具体段落同时要准备一些“文档里没有答案”的负样本看模型会不会乱编。代码生成与调试需要成对的“需求描述-代码实现”样本还要有“出错代码-修复结果”样本测试重点是语法正确性和逻辑一致性。多模态理解视频、图片、语音类场景需要对应的视频片段、图像、音频文件。比如网上流传的 RTMP 测试地址、测试视频下载链接这类素材可以拿来调试流媒体链路但直接当作多模态模型的测试语料并不合适因为内容本身没有经过标注无法评判模型输出是否准确。垂直行业应用像农业监测大模型语料往往是结构化数据和时间序列数据的混合体测试时既要看文本生成质量也要看数值推理是否正确。在动手之前先把场景确认清楚后面所有的数据采集、清洗、标注、评估工作才有方向。这个前置步骤我建议至少花一周时间做调研别着急写代码。2. 测试语料构建的核心细节与关键参数2.1 第一步永远是拆能力域而不是堆数据拿到一个模型评估任务后我通常先做能力域拆解把“模型好不好”拆成一张可以逐项打分的表。比如一个客服场景的 LLM我会拆成下面这些维度意图识别准确率用户说“我要退货”模型能否识别为售后意图。知识回答准确率答案内容是否与知识库一致。拒答能力用户问个人隐私、违法违规内容时模型能否礼貌拒绝。多轮上下文保持连续对话 5 轮后是否还记得早期信息。格式遵循能力要求输出 JSON 时是否严格按 JSON 输出。每个能力域至少准备 100 条测试样本整体测试集从 1000 条起步比较合理。数量太少模型在某类问题上表现差也没法判断是偶发还是系统性问题数量太多人工标注和评测成本会变得很难承受。先把能力域定下来再基于能力域去设计问题模板、组织答案、配比数据量比漫无目的地收集语料高效得多。这里特别提醒一点能力域不要拍脑袋定最好拉上产品、算法、运营三方一起过一遍。产品知道用户会怎么问算法知道模型当前哪里弱运营手里有大量真实用户反馈这三类信息整合起来能力域拆解才靠谱。2.2 清洗、去重、去污染这三大关怎么过不管是训练语料还是测试语料原始数据都不能直接用。网上爬来的文本里有大量广告、导航、乱码、重复段落还有隐私信息这些脏数据如果进入语料库轻则影响模型输出质量重则引发合规问题。清洗流程我通常按顺序做先用正则和解析库抽取出正文去除 HTML 标签、脚本、样式再用规则过滤掉过短文本、过长的无空格文本、乱码率过高的文本接着做敏感信息检测手机号、身份证号、银行卡号等个人隐私信息必须脱敏或直接删除。最后做格式统一统一换行符、全角半角、标点符号这一步能让后续的标注和评测少踩很多坑。去重是整个流程里最关键的一步。文本去重常用 MinHash 或 SimHash原理是把文本转换成一组特征签名再计算两段文本的相似度。一个常见的参数基线是n-gram 取 5相似度阈值设在 0.85 以上就算重复。代码类数据可以适当把阈值调到 0.8因为代码里有很多固定的样板代码阈值太严会把大量正常样本误杀。训练语料必须去重测试语料同样要跟训练语料做交叉去重否则测试结果会被污染。这块没有现成的一体化工具我会用 Python 写一个多进程 batch 脚本跑在服务器上对百万级文本做去重耗时通常在几小时内。2.3 数据配比和采样策略直接影响最终分数语料数据的配比问题是测试训练语料里最容易被低估的一环。训练时配比不对模型会在高频类别上表现好、低频类别上表现差测试时配比不对评估结果会失真让你误判模型能力。配比方案要从业务真实分布出发。比如电商客服场景里售前咨询约占 60%售后问题占 30%闲聊和投诉各占 5%。那测试语料的配比就应该跟这个分布大致一致否则模型售后能力不行但因为你测试集里只有 5% 的售后样本整体准确率依然好看问题被掩盖了。负样本的配比需要单独关注。所谓负样本就是那些模型应当拒绝回答、或不能给出肯定答案的输入。真实场景中用户一定会问超出范围的问题如果测试集里全是“有标准答案”的正样本模型的拒答能力就完全测不出来。我一般会在测试集里混入 10% 到 20% 的负样本并单独统计拒答准确率。采样策略上我推荐做分层抽样而不是简单随机抽样。先把数据按能力域、难度等级简单、中等、困难分层再从每一层内随机抽取样本。这样做的好处是即使某个层级样本量少也能在测试集中保留一定比例最终结果能反映出模型在困难样本上的真实水平。3. 从零搭一套 LLM 评测语料的实操流程3.1 用开源路线做一套 QA 评测集我以搭建一个问答能力评测语料为例完整走一遍实操流程。前提是机器上已经装好 Python 3.9 以上环境数据源先准备两部分一个公开的指令数据集比如 alpaca-cleaned加上你们自己的历史工单或客服对话记录。第一步把原始数据加载进来做字段规整。手工整理过的数据格式千奇百怪有 JSON、CSV、TXT我先统一转成标准 JSONL。每行包含三个核心字段instruction问题、input可选上下文、output参考答案。第二步按能力域给数据打标签。写一个轻量脚本基于关键词和规则先把明显是“代码问题”“数学问题”“常识问题”的样本区分开再人工抽检修正。这一步不需要太复杂的模型规则脚本即可完成粗分类真正的精度靠后续人工复核保证。第三步做去重和负样本注入。用 SimHash 去掉重复问题再人工写一批“无法回答”的负样本比如询问个人隐私、要求预测彩票号码、问模型训练数据之外的事件等。最终生成一个约 1200 条的评测集文件。下面是一段简化版的生成脚本思路可以直接复用import json import hashlib from collections import defaultdict def simhash(text, hash_bits64, ngram5): # 简化版 simhash用于文本近似去重 tokens [text[i:ingram] for i in range(len(text) - ngram 1)] v [0] * hash_bits for token in tokens: h int(hashlib.md5(token.encode()).hexdigest(), 16) for i in range(hash_bits): bit (h i) 1 v[i] 1 if bit else -1 fingerprint 0 for i in range(hash_bits): if v[i] 0: fingerprint | (1 i) return fingerprint def hamming_distance(a, b): return bin(a ^ b).count(1) def dedup(items, threshold8): result [] seen [] for item in items: fp simhash(item[instruction]) if all(hamming_distance(fp, s) threshold for s in seen): result.append(item) seen.append(fp) return result # 读取原始 jsonl raw_data [json.loads(line) for line in open(raw_data.jsonl, encodingutf-8)] # 去重 deduped dedup(raw_data) # 保持能力域分布输出 target 目录 with open(eval_set.jsonl, w, encodingutf-8) as f: for item in deduped: f.write(json.dumps(item, ensure_asciiFalse) \n)3.2 跑评测与 badcase 回流语料集构建好之后接下来就是跑评测。把测试集逐条封装成请求发给待测模型统一收集输出。注意要固定生成参数temperature建议设为 0.2 或更低max_tokens按场景设置否则模型生成的随机波动会干扰评测结论导致同一模型这次测 80 分、下次测 85 分。跑完一轮之后最重要的不是看总分而是分析错误样本。我习惯把误判样本称为 badcase每轮评测后把它们单独导出一份按能力域归类。如果某个能力域的错误率明显高于其他域说明这是模型当前的短板就需要针对性补充训练数据或调整提示词。这里有个容易忽略的点badcase 并不是只能用于模型迭代它们本身就是高质量的语料来源。把评估错误的样本、修正后的标准答案加回去经过人工复核后可以作为微调阶段的训练语料。这一套机制业内常叫主动学习闭环我在实际项目里发现两三轮循环之后模型在关键场景上的表现提升非常明显。回到测试语料本身我还会把测试集拆成两部分一部分是黄金测试集保持固定不变用于多版本模型的横向对比另一部分是扩展测试集每两周根据线上 badcase 和新增需求补充进去防止模型过拟合到固定的测试题。这个做法能让你长期跟踪模型效果的真实变化而不是只在某个时间点看到一张漂亮的报表。3.3 微调场景下的语料制作补充如果目标是做微调比如用 LoRA 做领域适配语料格式会比纯评测语料更严格。微调数据通常要求“指令-输入-输出”三段式结构或者“用户-助手”多轮结构。实践中经常遇到字段错位的问题有人把输入和指令写反有人把多轮对话压成单轮这些都会导致微调后的模型行为异常而且错误很难定位。我整理过一个比较稳妥的制作流程。先从真实业务数据里筛出高频问题场景人工撰写指令模板同一个问题写法要做多样化改写比如把“写一封邮件”改写成“帮我把这段话润色成邮件格式”。答案由领域专家编写尽量控制在 200 字以内避免模型学到冗长但无信息量的表达。最后做一遍格式校验扫描所有样本的字段完整性、字符数范围、空值比例校验通过再进入训练管线。对 LoRA 这类参数高效微调来说数据量不需要特别大。我的经验是一个垂直领域场景经过清洗和改写的高质量样本 3000 到 5000 条已经能让模型有明显的行为改善。超过这个量级之后收益会递减与其堆数量不如花时间提升样本质量和标注一致性。4. 常见问题与排查技巧实录4.1 问题速查表我把实际项目中高频遇到的问题整理成了一张速查表方便你按图索骥排查问题可能原因处理建议训练集和测试集重叠未做跨集去重同一批数据被重复使用用 SimHash/Embedding 相似度做全量交叉去重测试集过难模型分数普遍偏低负样本占比过高或困难样本过多回归业务真实分布按比例控制简单/中等/困难样本测试集过简单分数普遍虚高样本缺少对抗性模型“背答案”即可通过引入改写后的困难变体增加生成类、推理类题型同一测试集反复使用后分数失真模型已经在迭代中隐性记忆了测试分布维护黄金集扩展集双层结构扩展集定期更新模型幻觉严重但测试分数不低答案评判只看关键词匹配没有做语义一致性判断使用 LLM-as-judge 或人工抽检从语义层评估答案标注人员之间答案风格差异大缺少标注规范评审环节缺失编写标注手册新增样本经过双人交叉评审微调后模型行为反而变差训练语料存在字段错位或答案噪声检查字段映射抽检 50 条样本人工评估这张表我建议直接贴到团队文档里遇到问题先对一遍能省下很多排查时间。4.2 我踩过的几个坑先说数据污染的坑。有一阵子我们为了提升模型的行业问答能力从网上爬了一大批问答对直接混入指令微调数据。结果模型微调后反而开始输出一些带有明显网络论坛风格的口语化内容排查了很久才发现爬虫数据里混着大量灌水帖和不文明的表达。从那以后我定了一条铁律任何外部爬来的数据进入语料库之前必须先过一轮关键词过滤和人工抽检比例不低于 5%哪怕这会拖慢数据构建速度。再说多模态语料的坑。有次评测视频理解模型团队图省事用了 RTMP 测试地址和公开的测试视频文件结果模型在“视频里有什么物体”这类问题上的回答完全不可控。原因很简单这些视频本来就是用来调试播放链路的画面内容没有被标注模型输出自然谈不上对错。后来我们把视频语料全部换成有配套 caption 和问答标注的样本才真正开始有可复现的评测结论。还有一次自动化格式校验的坑。当时用 pytest 写了一套语料质量校验用例其中一个用例检查 JSONL 文件的字段是否完整结果漏掉了“数组字段为空”的情况导致一批空负样本混进测试集而不自知。后来在 pytest 用例里补了一个空数组的专项校验这个问题才算堵住。测试语料自己的质量也需要自动化测试来守护用 pytest 这类框架做数据校验是很好的做法但边界条件一定要覆盖全。4.3 数据合规与安全自查清单语料数据涉及的安全问题不只是隐私脱敏还包括内容合规、版权风险和数据投毒等几个维度。数据投毒指的是通过构造恶意样本混入训练数据让模型输出特定错误行为这是一个真实的工程风险需要在语料入库时做好来源审计和内容抽样检查。我目前团队执行的自查清单大概是这样的所有标注数据必须去除可识别个人身份的信息手机号、地址、姓名全部打码。文本内容经过色情、暴力、违法信息等敏感词过滤人工抽检比例不低于 3%。来自第三方开源数据集的先确认许可证类型避免商用风险。对外部数据源做可信度分级高风险的来源必须在隔离环境里抽样评估后再决定是否使用。评测集不能直接从网上的未知来源整包下载后无脑使用先人工审一遍再入库。这几点看起来琐碎但任何一个环节缺失后续上线时都可能变成事故。合规和安全问题没有先来后到必须从第一批语料进库就开始执行而不是等数据量大了再回头补。最后分享一点我的个人体会语料数据这项工作表面上是在处理文本、打标签、跑脚本本质上是在做“模型的验收标准”和“模型的成长饲料”。一套好的测试训练语料体系不只是模型上线前的检查工具更是持续迭代的发动机。如果你正在做类似的事情从第一版语料开始就搭建好黄金测试集和扩展测试集的骨架并且把 badcase 回流机制跑通后续每一步都会轻松很多。我在实际推进中养成的一个习惯是每次项目例会前先看一遍评测集上的 badcase 分布而不是只看总分和排名数字。因为数字只能告诉你模型行不行badcase 才能告诉你模型哪里不行、该往哪个方向补数据。把注意力从分数转移到错题上语料数据的价值才能真正体现出来。本文还有配套的精品资源点击获取 
长河君 · 2026/9/8 8:53:55 · 阅读 1.2k 大模型语料数据构建全指南：测试集、训练集与评测基准的实战方法论
简介面向大模型研发者的训练与测试语料包聚焦自然语言处理场景下的指令微调、预训练与对齐评测需求。资源采用Alpaca与ShareGPT两种主流格式组织共14个JSON文件压缩包仅65.32MB便于下载、携带和复用适合本地测试及小规模实验。文件覆盖中英文指令数据、预训练语料片段以及奖励模型训练集包含Alpaca中文指令、GPT-4生成对齐数据与对比评测数据等代表性内容可用于监督微调、RLHF及模型效果测试。语料既有新闻、社交媒体、百科全书等通用型互联网文本也包含法律、财务、医学等垂直领域内容兼顾通用知识与专业应用预训练语料库规模通常最大大量无标注语料可帮助模型从海量文本中习得广泛知识与语言规律再经指令微调和对齐训练提升理解与生成能力。整体格式清晰无论是快速验证模型效果还是构建领域问答集都能从中提取所需语料。目前已有1515人学习下载适合需要配置大模型训练语料、搭建评测集或开展数据清洗的算法工程师与研究者。 去年下半年我接到一个挺扎手的任务给一个即将上线的大模型产品搭一套完整的测试训练语料数据体系。一开始我以为这事不难无非是找几份公开数据集、做点清洗、切成训练集和测试集后来真正动手才发现LLM 的语料工程远不是“攒数据”这么简单。同样是“语料数据”训练语料、测试语料、评测基准三者的定位完全不同混用一次轻则模型评测分数虚高重则上线后面对真实用户时暴露出大量幻觉和拒答问题。这篇文章我打算从头梳理一遍大模型测试训练语料数据的整体思路、构建细节和实战流程重点聊哪些坑值得提前避开。内容面向想系统搭建语料体系的算法工程师、数据负责人也照顾刚入门、想搞清楚“测试集和训练集到底怎么切”的初学者。看完之后你应该能自己动手搭出一套可复用、可迭代的语料数据管线。1. 语料数据的整体版图训练、测试、评测各司其职1.1 训练语料和测试语料别混着用很多第一次做大模型项目的团队最容易犯的错误就是把“语料”当成一个筐什么东西都往里装。其实按用途区分语料数据至少要分成三条线训练语料、测试语料、评测基准。训练语料喂给模型决定了模型“学会了什么”。预训练阶段用的是海量网页、书籍、代码、论文目标是让模型具备语言能力和世界知识微调阶段用的是指令数据、对话数据、领域数据目标是让模型学会遵循指令、匹配特定业务场景。测试语料则完全是另一回事它不参与任何参数更新只用来检验模型“学得怎么样”。一条测试样本如果混进了训练集后面所有指标都等于开卷考试分数再好看也没有参考意义。评测基准可以理解为公开的标准化测试语料比如 MMLU、GSM8K、BBH 这类榜单数据集。它们的好处是能横向对比不同模型的能力坏处是跟具体业务场景往往对不上。真实的业务测试语料必须从自己的产品需求出发去构建这也是这篇文章想重点讲的部分。提示训练集、验证集、测试集三者的划分比例没有绝对标准但一个可以落地的经验值是基座模型预训练阶段不需要单独留验证集微调和评测阶段才需要严格控制切分。验证集用来调参测试集只用来做最终评估测试集一旦用过一次就要考虑它是否已经被模型“记住”。1.2 为什么公开 benchmark 不能直接当业务测试集我见过不少团队直接用 MMLU 和 C-Eval 的分数来验收自己的业务模型天然是跑偏的。公开 benchmark 测的是通用能力而业务场景往往有很强的领域属性。比如你做的是农业领域的大模型要监测土壤墒情、气象数据、给出灌溉施肥建议那你的测试语料里就需要大量带传感器数据格式的样本土壤湿度、温度、降雨量、作物生长期、施肥建议之间的映射关系对不对而不是问模型“法国首都是哪里”。另外还有一个很现实的问题公开 benchmark 的数据很可能已经出现在模型的预训练语料里了。预训练阶段抓取互联网数据时MMLU 这类知名数据集经常被“顺带”抓进去导致模型在榜单上分数虚高。放到业务场景就是你今天测出来 85 分上线后真实用户一问实际效果可能只有 60 分。所以在实际项目中我会把测试语料分成两层一层是公开 benchmark只用来做横向参考另一层是自建的业务测试语料从产品真实问题里抽样本、由领域专家标注、结果脚本自动化评估。第二层才是验收模型能不能上线的核心依据。1.3 不同落地场景的语料需求差异语料数据的形态跟场景强相关我简单按场景拆一下通用聊天助手需要覆盖闲聊、知识问答、观点表达、拒绝回答等能力域语料形态以多轮对话为主。RAG 知识库问答像 AnythingLLM 这类工具接上本地知识库后测试语料需要围绕文档内容制作问题要能对应到具体段落同时要准备一些“文档里没有答案”的负样本看模型会不会乱编。代码生成与调试需要成对的“需求描述-代码实现”样本还要有“出错代码-修复结果”样本测试重点是语法正确性和逻辑一致性。多模态理解视频、图片、语音类场景需要对应的视频片段、图像、音频文件。比如网上流传的 RTMP 测试地址、测试视频下载链接这类素材可以拿来调试流媒体链路但直接当作多模态模型的测试语料并不合适因为内容本身没有经过标注无法评判模型输出是否准确。垂直行业应用像农业监测大模型语料往往是结构化数据和时间序列数据的混合体测试时既要看文本生成质量也要看数值推理是否正确。在动手之前先把场景确认清楚后面所有的数据采集、清洗、标注、评估工作才有方向。这个前置步骤我建议至少花一周时间做调研别着急写代码。2. 测试语料构建的核心细节与关键参数2.1 第一步永远是拆能力域而不是堆数据拿到一个模型评估任务后我通常先做能力域拆解把“模型好不好”拆成一张可以逐项打分的表。比如一个客服场景的 LLM我会拆成下面这些维度意图识别准确率用户说“我要退货”模型能否识别为售后意图。知识回答准确率答案内容是否与知识库一致。拒答能力用户问个人隐私、违法违规内容时模型能否礼貌拒绝。多轮上下文保持连续对话 5 轮后是否还记得早期信息。格式遵循能力要求输出 JSON 时是否严格按 JSON 输出。每个能力域至少准备 100 条测试样本整体测试集从 1000 条起步比较合理。数量太少模型在某类问题上表现差也没法判断是偶发还是系统性问题数量太多人工标注和评测成本会变得很难承受。先把能力域定下来再基于能力域去设计问题模板、组织答案、配比数据量比漫无目的地收集语料高效得多。这里特别提醒一点能力域不要拍脑袋定最好拉上产品、算法、运营三方一起过一遍。产品知道用户会怎么问算法知道模型当前哪里弱运营手里有大量真实用户反馈这三类信息整合起来能力域拆解才靠谱。2.2 清洗、去重、去污染这三大关怎么过不管是训练语料还是测试语料原始数据都不能直接用。网上爬来的文本里有大量广告、导航、乱码、重复段落还有隐私信息这些脏数据如果进入语料库轻则影响模型输出质量重则引发合规问题。清洗流程我通常按顺序做先用正则和解析库抽取出正文去除 HTML 标签、脚本、样式再用规则过滤掉过短文本、过长的无空格文本、乱码率过高的文本接着做敏感信息检测手机号、身份证号、银行卡号等个人隐私信息必须脱敏或直接删除。最后做格式统一统一换行符、全角半角、标点符号这一步能让后续的标注和评测少踩很多坑。去重是整个流程里最关键的一步。文本去重常用 MinHash 或 SimHash原理是把文本转换成一组特征签名再计算两段文本的相似度。一个常见的参数基线是n-gram 取 5相似度阈值设在 0.85 以上就算重复。代码类数据可以适当把阈值调到 0.8因为代码里有很多固定的样板代码阈值太严会把大量正常样本误杀。训练语料必须去重测试语料同样要跟训练语料做交叉去重否则测试结果会被污染。这块没有现成的一体化工具我会用 Python 写一个多进程 batch 脚本跑在服务器上对百万级文本做去重耗时通常在几小时内。2.3 数据配比和采样策略直接影响最终分数语料数据的配比问题是测试训练语料里最容易被低估的一环。训练时配比不对模型会在高频类别上表现好、低频类别上表现差测试时配比不对评估结果会失真让你误判模型能力。配比方案要从业务真实分布出发。比如电商客服场景里售前咨询约占 60%售后问题占 30%闲聊和投诉各占 5%。那测试语料的配比就应该跟这个分布大致一致否则模型售后能力不行但因为你测试集里只有 5% 的售后样本整体准确率依然好看问题被掩盖了。负样本的配比需要单独关注。所谓负样本就是那些模型应当拒绝回答、或不能给出肯定答案的输入。真实场景中用户一定会问超出范围的问题如果测试集里全是“有标准答案”的正样本模型的拒答能力就完全测不出来。我一般会在测试集里混入 10% 到 20% 的负样本并单独统计拒答准确率。采样策略上我推荐做分层抽样而不是简单随机抽样。先把数据按能力域、难度等级简单、中等、困难分层再从每一层内随机抽取样本。这样做的好处是即使某个层级样本量少也能在测试集中保留一定比例最终结果能反映出模型在困难样本上的真实水平。3. 从零搭一套 LLM 评测语料的实操流程3.1 用开源路线做一套 QA 评测集我以搭建一个问答能力评测语料为例完整走一遍实操流程。前提是机器上已经装好 Python 3.9 以上环境数据源先准备两部分一个公开的指令数据集比如 alpaca-cleaned加上你们自己的历史工单或客服对话记录。第一步把原始数据加载进来做字段规整。手工整理过的数据格式千奇百怪有 JSON、CSV、TXT我先统一转成标准 JSONL。每行包含三个核心字段instruction问题、input可选上下文、output参考答案。第二步按能力域给数据打标签。写一个轻量脚本基于关键词和规则先把明显是“代码问题”“数学问题”“常识问题”的样本区分开再人工抽检修正。这一步不需要太复杂的模型规则脚本即可完成粗分类真正的精度靠后续人工复核保证。第三步做去重和负样本注入。用 SimHash 去掉重复问题再人工写一批“无法回答”的负样本比如询问个人隐私、要求预测彩票号码、问模型训练数据之外的事件等。最终生成一个约 1200 条的评测集文件。下面是一段简化版的生成脚本思路可以直接复用import json import hashlib from collections import defaultdict def simhash(text, hash_bits64, ngram5): # 简化版 simhash用于文本近似去重 tokens [text[i:ingram] for i in range(len(text) - ngram 1)] v [0] * hash_bits for token in tokens: h int(hashlib.md5(token.encode()).hexdigest(), 16) for i in range(hash_bits): bit (h i) 1 v[i] 1 if bit else -1 fingerprint 0 for i in range(hash_bits): if v[i] 0: fingerprint | (1 i) return fingerprint def hamming_distance(a, b): return bin(a ^ b).count(1) def dedup(items, threshold8): result [] seen [] for item in items: fp simhash(item[instruction]) if all(hamming_distance(fp, s) threshold for s in seen): result.append(item) seen.append(fp) return result # 读取原始 jsonl raw_data [json.loads(line) for line in open(raw_data.jsonl, encodingutf-8)] # 去重 deduped dedup(raw_data) # 保持能力域分布输出 target 目录 with open(eval_set.jsonl, w, encodingutf-8) as f: for item in deduped: f.write(json.dumps(item, ensure_asciiFalse) \n)3.2 跑评测与 badcase 回流语料集构建好之后接下来就是跑评测。把测试集逐条封装成请求发给待测模型统一收集输出。注意要固定生成参数temperature建议设为 0.2 或更低max_tokens按场景设置否则模型生成的随机波动会干扰评测结论导致同一模型这次测 80 分、下次测 85 分。跑完一轮之后最重要的不是看总分而是分析错误样本。我习惯把误判样本称为 badcase每轮评测后把它们单独导出一份按能力域归类。如果某个能力域的错误率明显高于其他域说明这是模型当前的短板就需要针对性补充训练数据或调整提示词。这里有个容易忽略的点badcase 并不是只能用于模型迭代它们本身就是高质量的语料来源。把评估错误的样本、修正后的标准答案加回去经过人工复核后可以作为微调阶段的训练语料。这一套机制业内常叫主动学习闭环我在实际项目里发现两三轮循环之后模型在关键场景上的表现提升非常明显。回到测试语料本身我还会把测试集拆成两部分一部分是黄金测试集保持固定不变用于多版本模型的横向对比另一部分是扩展测试集每两周根据线上 badcase 和新增需求补充进去防止模型过拟合到固定的测试题。这个做法能让你长期跟踪模型效果的真实变化而不是只在某个时间点看到一张漂亮的报表。3.3 微调场景下的语料制作补充如果目标是做微调比如用 LoRA 做领域适配语料格式会比纯评测语料更严格。微调数据通常要求“指令-输入-输出”三段式结构或者“用户-助手”多轮结构。实践中经常遇到字段错位的问题有人把输入和指令写反有人把多轮对话压成单轮这些都会导致微调后的模型行为异常而且错误很难定位。我整理过一个比较稳妥的制作流程。先从真实业务数据里筛出高频问题场景人工撰写指令模板同一个问题写法要做多样化改写比如把“写一封邮件”改写成“帮我把这段话润色成邮件格式”。答案由领域专家编写尽量控制在 200 字以内避免模型学到冗长但无信息量的表达。最后做一遍格式校验扫描所有样本的字段完整性、字符数范围、空值比例校验通过再进入训练管线。对 LoRA 这类参数高效微调来说数据量不需要特别大。我的经验是一个垂直领域场景经过清洗和改写的高质量样本 3000 到 5000 条已经能让模型有明显的行为改善。超过这个量级之后收益会递减与其堆数量不如花时间提升样本质量和标注一致性。4. 常见问题与排查技巧实录4.1 问题速查表我把实际项目中高频遇到的问题整理成了一张速查表方便你按图索骥排查问题可能原因处理建议训练集和测试集重叠未做跨集去重同一批数据被重复使用用 SimHash/Embedding 相似度做全量交叉去重测试集过难模型分数普遍偏低负样本占比过高或困难样本过多回归业务真实分布按比例控制简单/中等/困难样本测试集过简单分数普遍虚高样本缺少对抗性模型“背答案”即可通过引入改写后的困难变体增加生成类、推理类题型同一测试集反复使用后分数失真模型已经在迭代中隐性记忆了测试分布维护黄金集扩展集双层结构扩展集定期更新模型幻觉严重但测试分数不低答案评判只看关键词匹配没有做语义一致性判断使用 LLM-as-judge 或人工抽检从语义层评估答案标注人员之间答案风格差异大缺少标注规范评审环节缺失编写标注手册新增样本经过双人交叉评审微调后模型行为反而变差训练语料存在字段错位或答案噪声检查字段映射抽检 50 条样本人工评估这张表我建议直接贴到团队文档里遇到问题先对一遍能省下很多排查时间。4.2 我踩过的几个坑先说数据污染的坑。有一阵子我们为了提升模型的行业问答能力从网上爬了一大批问答对直接混入指令微调数据。结果模型微调后反而开始输出一些带有明显网络论坛风格的口语化内容排查了很久才发现爬虫数据里混着大量灌水帖和不文明的表达。从那以后我定了一条铁律任何外部爬来的数据进入语料库之前必须先过一轮关键词过滤和人工抽检比例不低于 5%哪怕这会拖慢数据构建速度。再说多模态语料的坑。有次评测视频理解模型团队图省事用了 RTMP 测试地址和公开的测试视频文件结果模型在“视频里有什么物体”这类问题上的回答完全不可控。原因很简单这些视频本来就是用来调试播放链路的画面内容没有被标注模型输出自然谈不上对错。后来我们把视频语料全部换成有配套 caption 和问答标注的样本才真正开始有可复现的评测结论。还有一次自动化格式校验的坑。当时用 pytest 写了一套语料质量校验用例其中一个用例检查 JSONL 文件的字段是否完整结果漏掉了“数组字段为空”的情况导致一批空负样本混进测试集而不自知。后来在 pytest 用例里补了一个空数组的专项校验这个问题才算堵住。测试语料自己的质量也需要自动化测试来守护用 pytest 这类框架做数据校验是很好的做法但边界条件一定要覆盖全。4.3 数据合规与安全自查清单语料数据涉及的安全问题不只是隐私脱敏还包括内容合规、版权风险和数据投毒等几个维度。数据投毒指的是通过构造恶意样本混入训练数据让模型输出特定错误行为这是一个真实的工程风险需要在语料入库时做好来源审计和内容抽样检查。我目前团队执行的自查清单大概是这样的所有标注数据必须去除可识别个人身份的信息手机号、地址、姓名全部打码。文本内容经过色情、暴力、违法信息等敏感词过滤人工抽检比例不低于 3%。来自第三方开源数据集的先确认许可证类型避免商用风险。对外部数据源做可信度分级高风险的来源必须在隔离环境里抽样评估后再决定是否使用。评测集不能直接从网上的未知来源整包下载后无脑使用先人工审一遍再入库。这几点看起来琐碎但任何一个环节缺失后续上线时都可能变成事故。合规和安全问题没有先来后到必须从第一批语料进库就开始执行而不是等数据量大了再回头补。最后分享一点我的个人体会语料数据这项工作表面上是在处理文本、打标签、跑脚本本质上是在做“模型的验收标准”和“模型的成长饲料”。一套好的测试训练语料体系不只是模型上线前的检查工具更是持续迭代的发动机。如果你正在做类似的事情从第一版语料开始就搭建好黄金测试集和扩展测试集的骨架并且把 badcase 回流机制跑通后续每一步都会轻松很多。我在实际推进中养成的一个习惯是每次项目例会前先看一遍评测集上的 badcase 分布而不是只看总分和排名数字。因为数字只能告诉你模型行不行badcase 才能告诉你模型哪里不行、该往哪个方向补数据。把注意力从分数转移到错题上语料数据的价值才能真正体现出来。本文还有配套的精品资源点击获取