开源大模型技术报告解读：小参数模型的数据管线与对齐工程

简介围绕通义千问Qwen系列的首份技术报告面向大语言模型研究者、算法工程师及关注开源大模型的开发者帮助快速建立对Qwen模型体系、预训练流程与人类对齐方法的整体认识。内容涵盖基础预训练模型Qwen与对话模型Qwen-Chat涉及数据构建、分词、模型架构、上下文长度扩展、训练策略及实验结果并介绍代码专用模型Code-Qwen、数学专用模型Math-Qwen-Chat的设计与评测表现。压缩包内含1个PDF文件大小约1.53MB便于检索、打印和离线阅读适合作为论文精读或技术调研的入口材料。已有1698人学习说明其在开源大模型学习群体中具有一定参考价值。读者可从中了解模型家族全貌、关键训练与对齐方法、下游任务表现及专业化模型路线为复现实验、选型评估和后续研究提供依据。1. 开源大模型技术报告小参数量为什么能压过大模型大模型开源到今天真正稀缺的从来不是权重文件而是一份把训练过程摊开写清楚的技术资料。它要回答一个反直觉的问题为什么一个参数更少的模型能在多数下游任务上达到甚至超过比自己大一圈的竞品。答案不在某个神奇的算子。数据管线的清洗强度、分词器的压缩效率、对齐阶段的数据配比这三件事叠加起来才是差距的真正来源。搞懂这三点中任意两点你对大模型训练过程的判断力就会完全不同。2. 预训练数据管线3 万亿 token 是怎么被洗干净的2.1 四条数据支线网页、百科、书、代码这份技术资料里写得很直白预训练语料由公开网页文档、百科、书籍、代码等构成语种上以中英为主同时覆盖多语言。看起来像一句客套话实际上这句话决定了后面所有工程的形态——不同来源的脏法完全不同清洗手段也就不可能只有一种。网页数据的原始形态是 HTML第一步不是训练而是抽正文。抽完正文之后要做语种识别因为一份多语言语料如果没有可靠的语种标签后面按语种上采样、按语种评估压缩率都无从谈起。书籍和百科相对干净但重复度高、模板化严重容易让模型把“目录结构”当成语言能力学进去。代码则是另一种脏语法合法但语义垃圾的片段大量存在比如自动生成的、被截断的、注释与实现不符的。真正体现工程水平的是后面的三级过滤。第一级是精确去重先做归一化统一空白、统一大小写形态、去掉不可见字符再按哈希做完全匹配去重。第二级是模糊去重用 MinHash 加 LSH 把近似重复的段落找出来。第三级是质量打分用多个模型并行给内容打分语言模型算困惑度判断像不像人话文本质量模型打分再有一个模型专门识别冒犯性或不适宜内容。提示这三级过滤的顺序不能随意调换。先做精确去重能显著减小模糊去重的输入规模先做质量过滤反而会把大量低质但可修复的样本直接扔掉浪费后续上采样的空间。最后一环是上采样。报告提到对某些来源做选择性上采样目的是保证高质量内容在 3 万亿 token 的总盘子里占到足够比例。这件事听起来简单实际上是配比的艺术——代码上采样过头模型的自然语言流畅度会明显掉百科上采样过头模型回答问题会变得像在念词条。2.2 去重为什么必须上 MinHash 和 LSH精确去重解决不了最恶心的一类重复同一篇文章被转载时改了几个标点、换了标题、插了一段广告。这类样本在网页语料里占比极高如果不去模型会在这些内容上反复训练效果等价于给它们加了权重。MinHash 的思路是把一个文档压成一个固定长度的签名对文档里的 shingle 集合做多次哈希每一维取最小值。两个文档的签名在某一维上相等的概率等于两个文档 shingle 集合的 Jaccard 相似度。签名足够长时比较签名就等价于近似比较集合相似度单次比较的成本从“遍历全文”降到“比较几十个整数”。LSH 则是把签名分桶把签名切成若干段只要有一段完全相同就落进同一个桶桶内再两两精算。这样避免了对全量文档做 O(n²) 的两两比较——这是去重能不能在万亿级 token 上跑完的关键。# 模糊去重的骨架签名 - 分桶 - 桶内精算 import hashlib def minhash_signature(text, num_perm128, shingle5): tokens text.split() grams { .join(tokens[i:i shingle]) for i in range(len(tokens) - shingle 1)} sig [] for seed in range(num_perm): # 每个 seed 对应一个独立哈希函数 h min(int(hashlib.md5(f{seed}:{g}.encode()).hexdigest()[:8], 16) for g in grams) sig.append(h) return sig def lsh_buckets(sig, bands16): # 128 维签名切成 16 段每段 8 维段内完全一致即视为候选对 per len(sig) // bands return [hash(tuple(sig[i * per:(i 1) * per])) for i in range(bands)]这段代码是示意实现不是生产版本真实系统会用更快的哈希比如 xxhash、会在归一化后的文本上先切句再切 shingleshingle 粒度一般按字符而不是按词因为中文分词本身就会引入噪声。参数num_perm决定签名长度越大越准也越慢bands决定召回与误召回的平衡段数越多越容易把不相似的文档放进同一个桶。有一处容易搞反分桶只负责“召回候选”桶内必须再做一次精算相似度超过阈值才删。跳过精算直接按桶删会把大量只在某一个片段上雷同的正常文档误删——血泪经验是这一步阈值宁可保守删少了顶多浪费算力删多了模型能力直接塌一块。2.3 分词器压缩率一个被低估的成本项报告里有一张容易被跳过的图不同模型在同等语料上的编码压缩率对比。做法是每种语言随机抽一百万文档规模的语料以某个支持上百种语言的多语言分词器作为基准值 1看各模型切出的 token 数相对基准的比值。这个指标之所以重要是因为它同时影响三件事。第一是成本同样的语料压缩率差 20%训练算力就差 20%。第二是等效上下文模型的上下文窗口是按 token 算的压缩率高意味着同样窗口能装下更多实际内容。第三是推理延迟用户输入同样一段中文切出的 token 少prefill 就快。# 压缩率token 数相对基准的比值越小越省 def compression_ratio(corpus, tokenizer, base_tokenizer): n_tok sum(len(tokenizer.encode(t)) for t in corpus) # 待测分词器 n_base sum(len(base_tokenizer.encode(t)) for t in corpus) # 基准分词器 return n_tok / n_base报告强调的一点是在保证中英和代码高效解码的同时其他语种的压缩率也做得不错。这句话背后的取舍很实际——多语言词表是有容量上限的给低资源语种多分一些词表槽位英文的压缩率就会掉。能在不牺牲中英的前提下把其他语种也压下去说明词表构建阶段的语料配比是认真调过的而不是拿英文语料训完词表再硬塞中文。注意压缩率不能只看平均值。中文、英文、代码三类分别统计任何一类明显劣化都会在对应任务上体现为“上下文不够用”的假象实际上只是 token 被切碎了。2.4 架构与长上下文RoPE 底数那点事这份资料对架构的着墨不多只给了结构位置没给公式细节。按这一代开源模型收敛出的共识基础结构基本是 Pre-Norm 加 RMSNorm、SwiGLU 前馈、旋转位置编码注意力部分对 QKV 加偏置。这套组合不是拍脑袋定的RMSNorm 比 LayerNorm 少一次减均值和一次加偏置在几十层堆叠下省下的访存是可观的SwiGLU 用门控把前馈的参数量换算成表达力同等参数量下比 ReLU 系更划算旋转位置编码把位置信息编码进复数旋转天然具备相对位置的性质外推时改造成本最低。长上下文扩展那一节的方法论值得单独说。位置编码的外推不是把窗口数字改大就行直接在超出训练长度的位置上推理注意力分数会进入模型从未见过的分布区间输出会迅速崩坏。常见的实现思路是调整旋转位置编码的底数把不同维度的旋转频率整体拉伸让长距离位置也落在训练时见过的频率范围内更激进的动态方案会在推理时按实际序列长度动态计算缩放系数短序列不受影响长序列才启用。这件事的坑在于底数调大之后短序列的位置分辨率会下降模型对近距离语序的敏感度变差。所以扩展长上下文之后必须做少量继续训练让模型重新适应新的位置分布光改配置直接推理掉点是必然的。3. 对齐的两级火箭SFT 与人类反馈强化学习各自在修什么3.1 监督微调数据配比比数据量重要预训练完的模型会答题但不会“好好答题”。你问它一个问题它可能续写出一段类似知乎问答的文本也可能直接开始编造引用。监督微调要解决的就是这个把“文本续写器”改造成“指令跟随器”。报告里对微调数据的描述是围绕任务执行、对话、工具使用、智能体、安全等方向构建。这个列举顺序其实有信息量——任务执行排在对话前面说明数据里相当比例是多步任务而不是闲聊安全单独列一项说明它被当成独立的数据类别来构造而不是在对话数据里顺手带一点。SFT 阶段最容易翻车的地方不是数据量是配比和掩码。掩码这件事必须做对损失只能回传在回答部分指令部分要全部忽略。原因很直接指令是用户给的输入模型不需要学会“生成用户的提问”把这部分算进损失等于让模型花容量去拟合输入分布还会让模型倾向于自己接话。# SFT只对回答段回传梯度指令段全部置为 ignore_index def build_labels(input_ids, prompt_len, ignore_index-100): labels input_ids.clone() labels[:, :prompt_len] ignore_index # 系统提示 用户指令不参与损失 return labelsprompt_len必须按实际拼接后的 token 位置算不能按字符数估。多轮对话里更麻烦每一轮的用户输入都要 mask每一轮的模型回答都要保留中间的分隔符按训练框架的约定处理。见过有人图省事只 mask 第一轮训出来的模型在多轮场景里会抢话第二轮的输出经常是重复上一轮的答案。配比方面一个常见做法是把数据按能力维度打标签然后按目标比例采样而不是简单混在一起随机打乱。代码、数学、工具调用这几类数据如果按自然分布混入占比会被通用对话淹没模型在专用任务上的表现上不去。但反过来专用数据上采样过头通用对话的流畅度会肉眼可见地退化回答开始变得像模板。3.2 奖励模型把人类偏好压成一个标量SFT 之后模型会答了但答得好不好没人管。奖励模型的作用是给“好”定义一个可计算的代理给定同一个问题的两个回答让它判断哪个更符合人类偏好。训练数据是成对比较标注者只需要说 A 比 B 好不需要打绝对分。这一点是设计上的关键——绝对分在不同标注者之间没有可比性相对判断的一致性高得多。损失函数用排序损失只约束分数差不约束分数绝对值。# 奖励模型同一 prompt 下chosen 的分数要高于 rejected import torch.nn.functional as F def rm_loss(score_chosen, score_rejected, margin0.0): # margin 留一点间隔避免两个分数贴太近导致排序不稳 return -F.logsigmoid(score_chosen - score_rejected - margin).mean()奖励模型的质量上限由标注一致性决定而标注一致性又由标注规范决定。规范越抽象“选更有帮助的”标注者之间的分歧越大奖励模型学到的就是一个噪声标签规范越具体“事实错误优先扣分其次看完整性最后看语气”一致性越高但覆盖面会变窄遇到规范没覆盖的场景就打不准。这是对齐阶段最真实的取舍没有两全的方案。还有一类隐蔽问题奖励模型会学到长度偏好。标注者天然倾向选更长、更详细的回答奖励模型把这个偏好学进去之后强化学习阶段的策略会迅速学会“把话说长”输出开始注水。常见对策是在标注时控制长度差、或者训练时对长度做归一化报告没展开写但这是这个环节绕不过去的坑。3.3 强化学习阶段策略到底在优化什么到了人类反馈强化学习这一步优化目标变了不再拟合某个标准答案而是最大化奖励模型给出的分数同时不能离 SFT 模型太远。后者就是 KL 惩罚项的作用——如果只最大化奖励策略会找到奖励模型的漏洞输出一堆奖励模型打高分但人类看着难受的文本这个现象在圈子里被叫做奖励劫持。阶段优化目标数据形态主要风险监督微调最大化标准答案的似然指令-回答对配比失衡、掩码错误奖励建模最大化偏好对的排序正确性成对比较标注不一致、长度偏好强化学习奖励分数减 KL 惩罚在线采样奖励劫持、训练不稳三个阶段的失败模式完全不同所以不能用一个阶段的指标去判断另一个阶段的好坏。SFT 阶段的损失降得很低不代表对话质量好奖励模型的排序准确率很高不代表策略学得对。这一点在实际操作里最容易被忽略只看单一指标训练跑完才发现输出风格崩了。报告里提到一个务实的做法除了强化学习也用拒绝采样这类更稳的方式构造高质量对话数据。拒绝采样的逻辑是让模型对同一问题生成多个回答用奖励模型挑最好的那个作为训练样本再微调一轮。它没有策略梯度那么激进训练稳定性好很多代价是采样算力花得多。两条路并行是这个阶段比较常见的工程选择。3.4 自动评测与人工评测的分工报告的评测部分把自动评测和人工评测分开写这个结构本身说明了态度自动基准能测出能力但测不出体验。自动评测用的是标准化数据集覆盖语言理解、知识、推理、代码、数学等方向好处是可复现、可比对。问题在于训练数据里可能包含这些基准的同源内容分数会虚高。所以真正有参考价值的对比是在同代模型之间看相对差距而不是看绝对值。人工评测用的是开放式难题让标注者对两个模型的回答做盲评。报告坦承即便经过强化学习与最强的闭源模型相比仍有差距。这种表述比“全面超越”可信得多——人工评测的结论通常是分场景的某些任务上已经接近某些任务上差距明显比如需要长链条推理的复杂问题。4. 工具调用与代码解释器模型怎么从“会说”变成“会算”4.1 工具调用不是提示词技巧是格式契约报告里提到对齐后的模型具备工具使用和规划能力在代码解释器这类复杂任务上表现不错。这句话容易被误读成“模型很聪明”实际上的机制要朴素得多模型学会了按约定格式输出结构化调用运行时负责执行并把结果拼回上下文。关键在于“约定格式”这四个字。模型必须在合适的时候输出一个可被解析的调用结构包含工具名和参数解析器负责校验、执行、把结果序列化后回灌。整条链路上任何一环不严谨模型就会开始胡说——比如输出一个不存在的工具名或者参数类型对不上。所以格式设计要满足三个条件可被严格校验缺字段直接判失败不做猜测、错误可回灌异常要转成文本让模型看到、幂等可重试同一个调用重放不会产生副作用。第三条经常被忽略等到工具里带了写操作重试一次就多写一条脏数据。注意工具描述文本本身就是训练数据的一部分。描述写得含糊模型就选不准工具参数说明缺少边界比如“最大 100 条”没写模型就会传入越界值然后把失败归因于工具坏了。4.2 代码解释器把算术和精确性外包出去代码解释器的价值不在于模型会不会写代码而在于把“算”这件事从概率生成变成了确定性执行。大模型做多位数乘法、日期推算、字符串精确处理本质上是在拟合训练分布位数一多就必然出错。让它生成一段代码交给解释器跑错误率立刻从“随位数增长”变成“代码写对就正确”。这个设计还带来一个副作用中间结果可以留在执行环境里不必全部塞回上下文。处理一份几万行的数据时模型只需要写几行聚合逻辑结果打印出来几十行上下文压力比让它“读完整份数据再回答”小一个数量级。代价是引入了一个新的失败面。执行环境有权限边界有超时有内存上限模型写的代码可能死循环可能读一个不存在的文件可能依赖没装的库。这些都必须在运行时捕获转成人类可读的错误信息回灌给模型让它自己改。回灌的文本质量很关键——直接把堆栈甩回去模型经常改错方向把错误类型和关键行号提炼出来修正成功率会高很多。4.3 规划与失败恢复Agent 循环的退出条件带工具的智能体本质上是一个循环模型输出意图运行时执行结果回灌模型继续。这个循环最容易失控的地方不是模型能力是退出条件。# 智能体循环的最小骨架 MAX_TURNS 8 for turn in range(MAX_TURNS): msg model.chat(history) # 模型输出自然语言 结构化调用 call parse_tool_call(msg) # 解析失败按普通回复处理不抛异常 if call is None: break # 没有调用 模型认为可以收尾 try: result registry[call.name](**call.args) except Exception as e: result f工具执行失败: {type(e).__name__}: {e} # 异常转文本回灌 history.append(tool_result(call.id, truncate(result)))MAX_TURNS是硬护栏防止模型在两个工具之间来回踢皮球。truncate是必要的工具输出可能几万字符全塞回去会直接吃光上下文模型反而看不到关键信息。解析失败时不抛异常而是当普通回复处理是因为模型有可能在收尾时输出一段自然语言总结这时强行要求结构化输出会把正常路径也打断。规划能力的真正体现是模型能不能把任务拆成有依赖关系的子步骤。报告里提到它在复杂任务上的表现可以和一些更大的模型掰手腕一个合理解释是工具把“记忆”和“计算”这两件事卸载出去了模型只需要负责拆解和调度参数量上的劣势被流程补上了一部分。这也解释了为什么工具调用能力对中小尺寸模型的意义比对超大模型更大。5. 复现与评测避坑五个让你白跑一周训练的现象5.1 数据与分词阶段的三处翻车第一处训练损失正常下降但模型输出开始复读。现象是同一句话反复出现或者问答开头几句一模一样。原因通常是去重没做透近似重复的模板文本在语料里占了太高比例模型学到了“复读”这个最省力的解。解决办法是把模糊去重的阈值收紧同时统计各来源的重复率对重复率异常高的来源直接降权而不是全量保留。第二处中文压缩率看着没问题但长文档任务总是截断。原因是只看总体压缩率没有分语种、分内容类型统计。数字、代码、繁体混排的文本在词表里往往被切得很碎而那类文档恰好最长。解决办法是按语言和内容类型分桶统计对碎片化严重的类别补词表或做预处理归一化。第三处上采样之后通用能力退化。现象是专用任务分数上去了日常对话变得生硬。原因很直接上采样改变了数据分布模型把容量分配给了少数来源。解决办法是给通用数据设一个下限比例上采样只在上限之内做每次调整配比都重跑一组通用评测而不是只看目标任务的分数。5.2 训练与评测阶段的两处翻车第四处监督微调后模型在开放问题上答得挺好一进多轮对话就抢话。原因是损失掩码只处理了第一轮的指令部分后续轮次的用户输入参与了训练模型学会了“接着用户的话往下写”。解决办法是按轮次边界精确构造掩码把每一轮的用户输入和分隔符全部置为忽略并且用一条极短的样本做断言测试确保掩码位置和 token 边界对齐。第五处长上下文扩展开启后短问题答得更差了。现象是简单问答开始丢失细节长文档问答反而提升。原因是位置编码的底数调大之后近距离位置的分辨率下降而短问题全靠近距离的语序信息。解决办法是扩展后必须做少量继续训练让模型适应新分布同时在配置里保留长度判断短序列走原始参数。这一条是最容易翻车的因为评测集里如果长样本占多数短问题的退化会被平均值掩盖等上线才发现。6. 设计取舍为什么“专用小模型加对齐”比“一个巨无霸”更划算这份资料里最有价值的判断不是某个基准分数而是模型谱系的组织方式一个基础预训练模型往上分出对齐后的对话模型再往侧边分出代码专用和数学专用两条支线各自都有预训练增强和微调版本。这个结构承认了一个现实通用能力和专用能力在容量分配上是竞争关系。同一个模型代码数据喂多了通用对话的语感会掉数学数据喂多了输出会变得过度步骤化。与其在一个模型里反复拉扯配比不如在基础模型之上分叉每条支线用更集中的数据做继续训练。代价是要维护多套模型和对应的评测集收益是每一套都能在自己的场景里把分数顶到接近闭源模型的水平。另一处取舍在规模上。开源发布的是中等参数规模的版本而不是最大那个。这个选择的逻辑不难推中等规模能在单机多卡上跑推理能被个人开发者真正用起来更大的模型分数更高但推广成本高一个数量级社区拿不动开源的意义就打了折扣。技术资料里反复强调这些模型在同等规模下表现突出本质上是在说单位算力的效率而不是绝对能力。还有一处更隐蔽对齐阶段选择同时走强化学习和拒绝采样两条路。纯强化学习上限高但训练不稳纯拒绝采样稳但收益有限两条并行意味着工程复杂度上升换来的是训练过程的可控性。这个取舍在文档里没有展开但从“同时报告 SFT 结果和强化学习后结果”的写法能看出来他们对自己的训练稳定性也没有十足的把握多留一条退路是理性的。验证这套设计是否成立我的建议是做两件小事。一是拿同一个问题分别问基础模型和对齐后的模型看差异出在“答不出”还是“答得不好”这能区分能力问题和风格问题。二是把代码任务和通用对话任务混在一个评测脚本里跑观察两者分数是否此消彼长如果明显互斥说明你手上的配比还没调稳。从那以后我每次看到“小模型打赢大模型”的结论都强制走一遍这条检查链先看压缩率是不是同一基准再看去重和上采样配比最后看评测集与训练数据是否同源。这三步走完多数“奇迹”都会回归成一个可解释的工程结果。希望帮到你。本文还有配套的精品资源点击获取