通义千问技术资料拆解：预训练数据、对齐流程与垂直分支

简介：面向大语言模型学习者与开发者的开源技术资料包，聚焦通义千问Qwen系列首版技术报告，适合希望系统了解LLM预训练、对齐与评测细节的中高级读者。包内仅含1个PDF文件，压缩包约1.53MB，内容为Qwen Technical Report英文原文，便于按章节查阅模型系列的整体设计与实验结论。已有1696人学习下载，具备一定参考热度。文档围绕Qwen与Qwen-Chat展开，覆盖预训练数据、分词、模型架构、上下文长度扩展、训练流程与实验结果，并进一步讨论监督微调、RLHF对齐、智能体工具使用与规划能力；同时涉及Code-Qwen、Code-Qwen-Chat和Math-Qwen-Chat等专用模型的表现。读者可据此梳理千问系列从基座模型到对话模型的技术脉络，理解开源模型在编程、数学与复杂任务中的能力边界，为后续复现、选型或二次开发提供一手参考。

1. 通意千问的技术资料：为什么模型卡上的参数从来不是重点

很多人拿到一份大模型技术资料，第一反应是翻到评测表格，看某个尺寸的模型在多少个榜单上赢了多少分。这个习惯在通意千问这类开源资料上会直接踩空——真正决定它能不能被你用起来的，不是那几个百分数，而是资料里反复出现的三条工程主线：3 万亿 token 的预训练数据管线、分阶段的人类对齐流程、以及代码与数学两个垂直分支的继续预训练策略。这三件事决定了模型的知识密度、指令服从度、以及在特定任务上的下限。换句话说，参数表告诉你「它考了多少分」，数据与对齐流程告诉你「它为什么会考这个分、换个场景还灵不灵」。搞懂后者，你才知道该在什么位置接入它、什么位置必须自己补一层。这份资料的阅读价值，正在于它把训练流水线摊开给你看，而不是只交一份成绩单。

2. 预训练数据管线：3 万亿 token 是怎么被筛出来的

2.1 从 HTML 到可用语料：一条四段式清洗链

大模型的知识底座来自预训练语料，而语料工程的难点从来不是「抓多少」，而是「留下哪些」。通意千问的资料里给出了一条相当标准的四段式链路，我一般把它拆成下面这样理解：

这条链里最容易被低估的是去重。重复语料在训练中的危害不是「浪费算力」这么简单，它会让模型对某些句式产生异常高的概率偏好，表现为输出重复、复读、以及在长文本生成中反复回到同一个短语。精确去重只能干掉完全一致的副本，而网页转载、模板改写造成的近似重复必须靠模糊去重。MinHash 加 LSH 是这类场景的常规组合：先把文档切分成若干片段集合，用多组哈希函数得到最小哈希签名，签名相似度超过阈值的文档对就被判定为近似重复。阈值定低了漏杀，定高了误杀，这一刀切在哪里，直接决定语料的多样性。

打分环节用的是多个模型并联的思路：语言模型打分判断文本是否「像人写的连贯内容」，质量模型给出可读性与信息密度评分，另有专门的分类模型识别不当内容。规则过滤负责兜住那些模型打不准的硬性条件，比如字符重复率、符号占比、段落长度异常。最后一步人工抽样复核不能省——它是唯一能发现「所有自动指标都说好、但人一看就是垃圾」的手段。

2.2 多语言与上采样：为什么中英混合的比例要人为干预

语料的多语言构成直接塑造模型的语言能力分布。资料里明确提到数据集以中英文为主，同时覆盖多种其他语言。这里有个反直觉的点：自然网页语料里英文占比天然偏高，如果完全按原始分布训练，中文能力会被稀释。常见的处理思路是对特定来源做上采样，也就是人为提高某些高质量语料在训练批次中的出现频率，让模型在有限的 token 预算内多「看」几眼中文与代码。

上采样的代价是可能加剧过拟合，所以它通常和去重、质量打分绑定使用：只有通过质量筛选的那部分语料才享有上采样资格。下面这段伪代码表达的是采样权重的构造逻辑，不是原文代码，但结构上贴近这类管线的通用做法：

# 语料采样权重构造示意 SOURCE_WEIGHTS = { "web_zh": 1.6, # 中文网页，上采样以平衡语言分布 "web_en": 1.0, # 英文网页，基准权重 "code": 1.8, # 代码语料，提升结构化推理能力 "books": 1.2, # 长文本，改善长程连贯性 "encyclopedia": 1.1 # 百科，事实密度高 } def build_sampler(datasets, weights): # 只对通过质量打分的样本计算权重 qualified = {name: ds.filter(min_quality=0.6) for name, ds in datasets.items()} total = sum(weights[n] * len(ds) for n, ds in qualified.items()) # 返回按权重归一化后的采样概率 return {n: weights[n] * len(ds) / total for n, ds in qualified.items()}

min_quality这个参数是整条管线的命门，调高会显著缩小可用语料规模，调低则放进噪声。实际工程里它很少是一个全局常数，通常按来源分别设定，网页类偏低、书籍与百科类偏高。做这类调参时，值得同步记录每个来源在最终训练集中的实际 token 占比，否则很容易出现「以为上采样了中文、实际占比没变」的情况。

2.3 压缩率：一个被忽略的分词器质量指标

资料里有一张对比不同模型编码压缩率的图，用多语言基线的压缩率为 1 做归一化。这个指标衡量的是「同样的文本，你的分词器需要多少个 token 来表示」。压缩率越高，同样的上下文窗口能装下的实际内容越多，推理成本也越低。

这件事的底层机制在于词表设计。词表大、覆盖的常见子词多，压缩率就高，但嵌入矩阵和输出层参数会变大；词表小则相反。对中文尤其敏感——中文没有空格分隔，分词粒度选择直接决定一个汉字或常见词是占一个 token 还是被切成两三个。压缩率差 20%，意味着同样的窗口长度下有效信息量差 20%，在长文档场景里这是实打实的差距。看技术资料时，如果只关注模型结构而跳过分词器，就很容易在部署阶段被上下文长度不够用的问题打脸。

3. 对齐流水线：SFT 与 RLHF 各自在修什么

3.1 监督微调：把「续写机器」改造成「应答机器」

预训练模型的本质是下一个 token 预测，它会忠实地续写你的输入，而不是回答你的问题。监督微调做的就是这件事：用大量「指令—回答」配对，把模型的输出分布从「续写网页」扳向「回应用户」。资料里提到微调数据覆盖任务执行、对话、工具使用、智能体、安全等多个方向，这个覆盖面本身就是设计决策——如果微调数据只覆盖闲聊，模型在结构化任务上会明显退化。

对话数据的组织方式比数据量更影响最终手感。多轮对话必须保留角色标记与轮次边界，让模型学会区分「谁在说」和「说到哪了」。常见的实现思路是用特殊 token 包裹每一轮的角色与内容，训练时只对回答部分计算损失，指令部分不参与梯度。下面这段是数据格式的示意，帮助理解损失掩码在哪一层生效：

# 单条训练样本的构造示意 def build_example(system, turns, tokenizer): ids, labels = [], [] # 系统提示参与上下文，但不计算损失 sys_ids = tokenizer.encode(f"<|system|>{system}") ids += sys_ids labels += [-100] * len(sys_ids) # -100 在交叉熵中被忽略 for role, text in turns: head = tokenizer.encode(f"<|{role}|>") body = tokenizer.encode(text) ids += head + body if role == "assistant": # 只有模型自己说的话才计入损失 labels += [-100] * len(head) + body else: labels += [-100] * (len(head) + len(body)) return {"input_ids": ids, "labels": labels}

-100是 PyTorch 交叉熵的默认忽略索引，这个约定把「哪些 token 该学」变成了数据构造问题而非损失函数问题。实践中最常见的翻车是把用户输入也算进损失，模型会学成「自问自答」，表现为回答里突然冒出用户口吻的句子。这就是血泪经验：格式没错、loss 也在降，但生成质量就是不对，回头查数据构造才发现掩码漏了一行。

3.2 奖励模型与 RLHF：把「人觉得好」变成可优化的标量

监督微调只能教模型「照着示范答」，教不了「两个都不错的答案里哪个更好」。奖励模型补的就是这一环：拿同一提示下的多个回答让人工排序，训练一个打分器去拟合这个偏好顺序。排序数据天然适合用成对比较的损失来训练，因为人给出「A 优于 B」比给出「A 打 7.3 分」要可靠得多。

有了奖励模型，强化学习阶段就可以让策略模型生成回答、由奖励模型打分、再用这个分数去更新策略。这里有个结构性风险：策略模型会主动寻找奖励模型的漏洞，生成一堆在打分器眼里很高分、在人眼里很怪异的输出。常见的抑制手段是在目标里加一项对原始模型的 KL 惩罚，约束新策略不要偏离太远。用伪代码表达目标的形式大致是：

# RLHF 目标函数结构示意 def rlhf_objective(reward_model, policy, ref_policy, prompt, beta=0.1): response = policy.generate(prompt) r = reward_model.score(prompt, response) # 偏好打分 kl = policy.logprob(response) - ref_policy.logprob(response) # beta 控制允许偏离参考模型的程度 return r - beta * kl

beta是这条流水线上最需要调的参数。调大，模型保守，回答安全但平淡；调小，模型敢说，但容易跑偏甚至编造。资料里提到经 RLHF 的对话模型在人工评测中表现有竞争力，这类结论背后其实是beta和奖励模型质量共同决定的，不是算法本身有多新。

3.3 工具调用与代码解释器：对齐不止于说话好听

资料里专门用一节讲工具使用、代码解释器与智能体，这一点值得单独拎出来。让模型调用外部工具，本质是把「生成文本」扩展成「生成结构化动作」。模型需要输出符合约定格式的调用意图，外部执行器解析后运行，再把结果回填进上下文。这条链路对格式的容错度极低——少一个括号、字段名拼错，整次调用就失败。

代码解释器更进一步：模型写的代码要在真实环境里跑，跑出来的结果再作为观测回灌。这要求模型具备「根据报错修正代码」的闭环能力。资料里提到这类能力在复杂任务上表现不俗，机制上它依赖的是多轮交互中的错误反馈利用，而不是单次生成的准确性。如果你的场景需要这类能力，重点要验证的是模型在拿到异常信息后能否收敛，而不是第一次就写对。

4. 垂直分支：代码与数学模型为什么要单独继续预训练

4.1 CODE-QWEN：代码语料的分布与自然语言差在哪

通用语料里代码占比有限，而代码的统计特性和自然语言差异极大：缩进有语义、括号必须配对、标识符的命名遵循作用域规则。通用模型能写代码，但对长距离的结构约束容易失守，典型表现是函数开了头忘了闭合、变量声明了没用上。

CODE-QWEN 的做法是在通用底座上继续用大规模代码语料预训练，再做代码相关的指令微调。这个顺序有讲究：继续预训练改变的是模型的底层分布，让它对代码的语法结构形成更强的先验；指令微调改的是输出形式，让它按「解释、生成、调试」等不同意图组织回答。反过来做，先微调再预训练，微调学到的格式会被后续预训练冲掉。资料里提到这类模型在代码理解与生成的基准上有明显提升，机制上正是这两步叠加的结果。

4.2 MATH-QWEN：数学推理的瓶颈在链式展开而非知识

数学任务的失败模式和代码不同。模型往往知道相关公式，却在多步推导中丢条件、串变量。这类问题的根源是长链推理中的错误累积：每一步都有小概率出错，步数一多，整体正确率指数下滑。

针对这个特性，数学分支的训练重点落在推理过程的组织上——让模型把中间步骤显式写出来，而不是直接跳到答案。显式的中间步骤有两个好处：一是把一次高难度预测拆成多次低难度预测，降低单步出错概率；二是让错误可定位，便于用结果正确性做筛选和再训练。资料里提到数学专用对话模型在同尺寸开源模型中大幅领先并接近更大体量的通用模型，这个结论的说服力来自「专用数据 + 显式推理」的组合，而不是单纯的参数堆叠。

5. 避坑与排查：接入这类模型时最容易翻车的五件事

5.1 现象：同样的提示词，换个批次结果风格突变

原因通常不在模型，而在采样参数或对话模板。对话模型对角色标记极其敏感，少一个起始标记，模型会退化成续写模式；温度与 top-p 改动 0.1，输出风格就会有可感知的漂移。解决方式是固定一套模板与采样配置并写进版本管理，任何对比实验只在单一变量上变动，别一次改三个参数然后对着结果猜。

5.2 现象：长文档输入被截断，模型答非所问

先确认分词器的实际压缩率，再确认上下文窗口的有效长度。很多所谓「窗口够长」的模型，在中英混合长文本上的实际容量会明显缩水。解决方式是先统计目标文档的 token 数分布，据此设定分块策略；需要跨块推理时，用摘要回填而不是简单拼接，避免中间段落被稀释掉。

5.3 现象：模型调用工具时参数格式频繁出错

这是格式约束没被充分训练的表现。缓解手段有三层：在提示里给出完整的调用样例而不只是字段说明；对输出做结构校验并在失败时把错误信息回灌让模型重试；在容错层做参数归一化，比如把字符串数字转成数值。三层叠加能把失败率压下来，但别指望降到零，重试机制必须常备。

5.4 现象：RLHF 后的模型回答变得极其保守

这是 KL 惩罚过强或奖励模型偏好偏窄的典型症状。表现是遇到稍敏感或稍复杂的问题就绕开，给出大段免责式表述。排查时先看奖励模型的训练数据是否过度集中于「安全但空洞」的样本，再考虑下调偏离惩罚。要提醒的是，放松约束会同时放大编造风险，这两个方向的调整必须一起评估。

5.5 现象：代码模型生成的函数体语法正确但逻辑跑不通

语法正确来自预训练对结构的拟合，逻辑不通来自缺少执行反馈。解决思路是把单元测试或解释器接进流程，让模型对失败用例做定向修正。单靠提示词要求「仔细检查」几乎无效，可验证的执行结果才是唯一可靠的信号。

6. 从这份资料里该带走什么：规模、数据与对齐的三角权衡

读完这类技术资料，最容易形成的错觉是「参数越大越好」。真实的工程取舍是一张三角关系：参数规模决定容量上限，数据质量决定这个上限能被兑现多少，对齐流程决定兑现出来的能力是否按你期望的形式呈现。三者中任何一角塌陷，另外两角的投入都会打折。3 万亿 token 的语料规模如果不配去重与打分，训练出的模型会在长文本上反复绕圈；对齐流程如果只做监督微调不做偏好优化，模型答得规范但不好用；垂直分支如果不做继续预训练直接微调，代码和数学能力就上不去。资料里把这几条线分开陈述，恰恰是在暗示它们彼此不可替代。

验证一份资料是否值得深挖，我一般会做三件事。第一，看它有没有交代数据管线的具体环节，只写「使用了高质量语料」的基本可以放下。第二，看评测是否区分了基座与对话模型，把两者混在一起报分的结论要打折扣。第三，看垂直分支的训练顺序是否讲清楚，顺序错了，复现必然失败。这三条判断标准不依赖任何具体榜单，换个模型系列照样适用。

还有一个常被忽略的维度是分词器与压缩率。它不在模型结构图里，也不在评测表格里，却同时影响上下文容量、推理成本和多语言表现。评估一个模型能不能扛住你的长文档场景，先算一遍目标语料在它的分词器下的 token 数，比看任何窗口长度宣称都可靠。

至于该不该动手跑一遍，我的建议是先明确你要解决的是哪类问题。需要通用对话与工具编排，就从对话模型入手；需要代码生成与调试，直接看代码分支；需要多步推导，数学分支的显式推理组织方式比通用模型更值得参考。这份资料的价值不在于给出一组可以照抄的超参，而在于把「数据怎么筛、对齐怎么做、垂直能力怎么长出来」这条因果链完整摊开——顺着这条链读，你能判断出哪些能力是模型自带的、哪些必须自己补，这比记住任何一个分数都管用。

从那以后我每次评估一份模型技术资料，都强制自己先看数据管线和对齐流程这两节，再回头看评测表，因为顺序反了很容易被数字带着走。希望帮到你。

本文还有配套的精品资源，点击获取