简介：一份来自阿里巴巴 Qwen 团队的技术报告原文，以 PDF 文献形式呈现，面向希望深入了解大语言模型训练细节的开发者、算法工程师与高校研究者。文档系统记录了千问系列首个版本的整体设计：从预训练语料构建与分词方案，到模型架构、上下文长度扩展策略与训练流程，并给出多类下游任务的实验结果，可帮助读者建立对国产开源大模型技术路线的完整认知。压缩包内仅含 1 个 PDF 文件，体积约 1.53MB，篇幅紧凑便于通读与检索，也方便按章节摘取图表和指标用于课程汇报或技术分享。报告后半部分重点讨论对齐环节，包括监督微调与基于人类反馈的强化学习，并介绍 Qwen-Chat 在工具调用、代码解释器使用等智能体场景中的规划能力；同时覆盖面向编程的 Code-Qwen、Code-Qwen-Chat 与面向数学推理的 Math-Qwen-Chat 等专用模型的表现对比。目前已有 1698 人学习，适合作为理解千问系列模型演进与实践选型的参考材料。

1. Qwen 技术报告公开：大模型厂商第一次把训练方法论完整摊开

大语言模型这个圈子最缺的从来不是榜单，而是可对照的工程细节。Qwen 这份开源的技术资料把预训练、对齐、代码与数学专项模型、多模态支线的完整路径一次写清，基础模型训练用了最多 3 万亿 token，开源的是 7B 和 14B 两档的基座与 Chat 对齐版本。过去要拼凑这套配方，只能靠零散博客和逆向猜测；现在有一份五十多页的原始文档摆在那里。对做人工智能应用的团队来说，它更像一份说明书，而不是通稿：数据怎么洗、模型怎么扩上下文、奖励模型怎么训、专项模型怎么切，都单独成节。值得关注的点不在参数表，而在这些"本可以不写"的细节。

2. 3 万亿 token 背后：预训练数据管道才是真门槛

预训练这一章是整份报告里信息密度最高的部分。3 万亿 token 被反复引用，但门槛从来不在这个数字上——同样规模的数据，清洗方式和领域配比不同，训出来的模型能差出一个量级。报告把数据来源拆成公开网页文档、百科、书籍、代码几类，明确多语言、中英占大头。这个描述朴素到容易被跳过，但对真要复现的人来说，后面每一句都是关键。

2.1 四道工序：HTML 原文先过一遍筛子

原文对预处理的描述可以归成四段：从 HTML 里抽正文、用语种识别工具判定语言、做两级去重、用规则加模型过滤低质内容，随后人工抽样复核，并对部分来源做上采样。顺序不是随便排的。去重放在过滤之前，能先压掉大量重复页，减少后续打分模型的计算量；过滤放在去重之后，则能让质量判断不被重复内容污染。很多团队在这两步上翻过车——先过滤后去重，结果同一篇稿子被十个站点转载，每条都过了质量关，最后语料里塞满同义重复。

质量打分用的是组合拳：语言模型打分、文本质量打分模型、以及识别不当内容的模型，三路并行，再叠一层规则。规则负责确定性判断（长度、符号比例、乱码比例），模型负责语义层面的判断（是否通顺、是否成段、是否像正文）。两层都要，只有规则会漏掉"语法正确但是垃圾"的内容，只有模型会把某些专业领域的长句误杀。

上采样这一步最容易被忽略，但直接决定模型的领域手感。代码、数学、百科这类在原始网页里占比低但价值高的内容，会被刻意提高采样权重。从行业角度看，这就是为什么后来的模型在代码和推理上进步明显——不是架构变了，是配比变了。

提示：如果只做一次全量去重，建议对短文本单独设阈值。短句的 MinHash 签名区分度低，容易把不同内容判成重复。

2.2 MinHash 加 LSH：模糊去重的成本账

精确去重只能解决"完全一样"的情况。归一化之后（去空白、统一大小写、去标点噪声）做哈希比对，成本低，但拿转载改写、模板拼接、段落乱序没辙。报告里用的是 MinHash 加 LSH 的模糊去重组合，这也是目前大规模语料处理里性价比最高的方案：MinHash 把一篇文档压成一个固定长度的签名，LSH 把签名分桶，只在同桶内比对，避免 O(n²) 两两计算。

下面这段是按报告描述的思路做的示意复现，重点看参数，不要照搬阈值：

from datasketch import MinHash, MinHashLSH # 5-gram 切分：中文按字切更稳，英文和代码建议先按 token 切再拼 def shingles(text, k=5): text = "".join(text.split()).lower() return {text[i:i + k] for i in range(max(0, len(text) - k + 1))} def build_minhash(text, num_perm=128): m = MinHash(num_perm=num_perm) for s in shingles(text): m.update(s.encode("utf-8")) return m # threshold 是 Jaccard 相似度阈值，0.8 表示八成重合即判重 lsh = MinHashLSH(threshold=0.8, num_perm=128) kept = [] for doc_id, text in corpus: # corpus 为 (id, 正文) 的可迭代对象 if len(text) < 200: # 短文本另走精确去重，避免误杀 kept.append(doc_id) continue m = build_minhash(text) if lsh.query(m): # 命中已有桶，判定近重复，丢弃 continue lsh.insert(doc_id, m) kept.append(doc_id)

三个参数决定这套流程的性格。k=5是切分粒度，中文语料上 5 个字能覆盖一个短语，太短会让正常表述也撞车，太长会让改写版本逃过检测。num_perm=128是签名长度，直接换准确率和内存，128 在亿级文档上已经够用，翻到 256 收益递减明显。threshold=0.8是最需要按语料调的，新闻类可以压到 0.7，技术文档建议提到 0.85 以上，否则会把同一份 API 说明的不同版本当成重复删掉。

代码语料要特殊处理。不能去空白、不能统一大小写，缩进在 Python 里是语法的一部分；还得先把注释剥离再算签名，否则同一段逻辑换个注释就被判成不同文档。这套流程跑完，"后悔药"就没得吃了——被误删的样本不会出现在任何日志里，只能靠人工抽样那一步兜住。

注意：去重结果一定要留可回溯的落盘记录（文档 id、命中的桶 id、相似度）。训练效果不对时，第一件事就是回头查语料是不是被删过头。

2.3 分词压缩率：中文场景里最容易被忽略的成本项

报告里放了一张编码压缩率对比图，以支持百种语言的某多语分词器为基准值 1，横向比较几个同期开源模型在中、英、代码及多门语言上的压缩表现。Qwen 的结论是在保证中英和代码高效解码的同时，对其他语种也维持了较高压缩率。

这个指标听起来枯燥，落到账单上很直接。压缩率低，意味着同一段中文会被切成更多 token：上下文窗口被更早占满，训练时每个样本承载的有效信息更少，推理时按 token 计费的场景成本更高，显存里 KV 缓存的压力也更大。一个中文占比高的应用，分词器效率差 20%，等效于上下文从 8K 缩到 6.4K，还得额外付两成的推理钱。

这也是为什么多语言模型的分词器设计比想象中难。英文和代码的 token 边界相对清晰，中文没有空格，日文混假名，东南亚语种还有大量组合字符。要在一套词表里同时兼顾，只能靠语料配比去调。从业者评估一个开源模型时，第一件事应该是拿自己业务里的真实文本跑一遍分词，看平均 token 数——这个数字比任何榜单都更能预测你的推理成本。

2.4 架构与上下文：不做花活的路线选择

主干沿用 decoder-only 的 Transformer，位置编码用旋转位置编码，前馈层用门控结构，归一化用 RMSNorm，注意力层里加了偏置项以便更好地做长度外推。这套组合在同期开源模型里属于共识路线，没有引入混合专家之类的复杂结构——参数量就 7B 和 14B 两档，用密集架构把训练稳定性放在第一位，是当时更务实的选择。

上下文扩展单列了一节。预训练阶段的标准窗口并不长，要支撑长文档、多轮工具调用这类场景，得靠位置编码的插值方案加少量长文本继续训练，把有效窗口推上去。行业里通行的做法是对旋转位置编码做频率调整，让模型在没见过的更长位置上仍能保持相对位置关系，再接一段长样本微调收口。这里最容易踩的坑是只改推理端参数、不做继续训练，短文本上看着没事，一上长文档，注意力就开始发散。

提示：判断一个模型的长上下文是"真支持"还是"能塞进去"，别看宣传口径。拿一份需要跨章节引用的长文档做问答，答案落在中段和尾段时是否还准确，一试便知。

3. 对齐三段式：SFT 打底、奖励模型定标、RLHF 收口

基座模型会续写，但不会对话。从"能接话"到"答得让人愿意用"，中间隔着一整套对齐流程。报告把这段拆成监督微调、奖励模型、强化学习三个环节，每个环节的数据构成和训练目标都单独交代，这在对齐章节里算是写得比较实的。

3.1 SFT 数据：任务面覆盖比数据量更关键

监督微调用的是一份经过筛选的对话数据，覆盖任务执行、闲聊、工具使用、Agent 场景、安全边界五类。注意这个分类方式——它不是按领域分的（法律、医疗、金融），而是按"模型要会做什么动作"分的。任务执行要求模型理解指令并输出结构化结果；工具使用要求模型在合适的时候停下来调用外部接口；Agent 场景要求多步规划；安全边界要求模型在越界请求上稳住。

按动作分而不是按领域分，是因为泛化路径不同。按领域分，模型学到的是知识；按动作分，模型学到的是行为模式，后者才更容易迁移到没见过的领域。这也是为什么后来的模型都在强调"指令遵循"而不是"领域覆盖"——领域是无限的，动作是有限的。

数据质量的判断标准在报告里没有展开，但从行业惯例看，SFT 阶段最怕两类样本：一类是"看起来很长很专业但答非所问"的，一类是"答案对但格式混乱"的。前者让模型学会堆字，后者让模型学会忽略格式约束。清洗这两类样本的工作量，往往比收集新样本更大。

3.2 奖励模型：把"人觉得好"变成一个可优化的标量

强化学习阶段的核心是奖励模型。做法是让人对同一问题的多个回答做偏好排序，用这些排序数据训练一个打分模型，再用它给强化学习提供信号。这套流程的关键不在算法，在偏好数据的质量和覆盖面——排序标准模糊，训出来的奖励模型就是个黑匣子，你永远不知道它在奖励什么。

强化学习本身用的是策略优化，让模型在奖励模型给出的分数上做梯度上升，同时用一个约束项防止它偏离 SFT 模型太远。这个约束项是必需的，没有它，模型很快会学会"讨好打分器"而不是"回答问题"，也就是常说的奖励劫持。表现是回答变得很长、很客气、结构很工整，但信息密度极低。

报告里对 RLHF 版本的评价是"有竞争力"，人类评测中表现不错，但明确写了仍落后于当时最强的闭源模型。这个表述很克制，也值得从业者记住：RLHF 是把模型从"能用"推到"好用"的工序，不是把 7B 推成 70B 的魔法。

注意：如果你在自己的业务上做偏好对齐，排序标注一定要给标注员明确的反例标准。只告诉"哪个更好"，不给"什么样的答案不可接受"，训出来的奖励模型会系统性偏好长答案。

3.3 双轨评测：榜单分数和人类偏好的分歧

评测部分走了两条线。自动评测这边，报告在一组覆盖语言理解、知识、推理等方向的数据集上，把 14B 基座和当时同尺寸的最好开源模型、以及两个闭源模型放在一起比。结论是明显超过同尺寸开源对手，但仍落后于闭源的第一梯队。这个结论和后面的对话模型评测是一致的，没有夸大。

人类评测那边用的是开放式难题，让评估者对回答质量做判断。结果是 RLHF 版本明显好于纯 SFT 版本，说明强化学习这一步确实在起作用，而不只是流程上的装饰。

两条线放在一起看，能看出一个常被忽略的事实：自动榜单和人类偏好的排序并不总是一致。基座模型在知识类选择题上能刷得很高，但同一批模型在开放式对话里可能答得生硬、抓不住重点。反过来，经过对齐的模型在榜单上未必涨分，用户却明显更愿意用。做模型选型时，如果你的场景是结构化抽取、分类这类有标准答案的任务，看基座分数就够；如果是对话、写作、客服这类开放式场景，人类偏好数据比榜单更有参考价值。

3.4 工具调用与代码解释器：Agent 能力的早期形态

报告单独用一节讲工具使用、代码解释器和 Agent。这一节的信号意义大于技术细节：它说明工具调用能力是通过训练得到的，不是靠提示词临时拼出来的。模型要学会判断什么时候该调工具、调哪个、拿到返回结果后怎么接着推理，这套行为模式得在对齐数据里出现过，模型才学得会。

代码解释器是这套能力最典型的检验场。它要求模型把自然语言问题转成代码、执行、读结果、再修正，一旦中间某步出错，整个链条就断了。报告里提到，在这类复杂任务上，对话模型的表现可以和一些参数更大的模型相比——这句话的潜台词是，工具使用能力不完全由参数规模决定，训练数据里有没有这类轨迹，影响更大。

对做应用的团队来说，这意味着评估一个模型能不能做 Agent，不能只看它会不会写函数，要看它在多步任务里会不会自我纠正、会不会在工具返回异常时降级处理。这两点，靠提示词补不上。

4. 常见的五个误读：别把技术报告当发布通稿读

技术报告的价值在细节，但细节最容易被读成结论。翻完一遍之后，脑子里留下的往往是一句被简化过的判断，而这句话恰恰是最容易用错的。下面这几条，是从业者在看这类文档时最常出现的偏差。

4.1 误读一：参数越大越强，7B 没戏

误判点：看到 7B、14B 的规模，直接归类为"玩具模型"，认为只能做 demo。

为什么：榜单被大模型占据，视觉上形成"只有最大那个能打"的印象。但报告的评测口径是按同尺寸横向对比，7B 对标的是其他 7B，14B 对标的是其他 14B，结论也明确写在这个范围内——超过同尺寸对手，落后于更大的闭源模型。

怎么看：先确定你的任务难度和延迟预算。分类、抽取、改写、结构化输出这类任务，7B 对齐版本足够；需要多步推理、长文档理解、复杂代码生成的，才需要考虑更大规模或者专门的推理模型。规模是成本项，不是荣誉项。

4.2 误读二：RLHF 只是锦上添花

误判点：把强化学习当成"最后调一下语气"的收尾工序，觉得跳过也不影响主体能力。

为什么：SFT 之后模型已经能对话，看起来只差"礼貌程度"。实际上 RLHF 改的是输出分布的偏好方向——同样的知识，回答的组织方式、详略取舍、遇到不确定时的表述，都在这一步被重新塑形。

怎么看：报告里人类评测的对比很直接，RLHF 版本明显优于纯 SFT 版本。如果你的场景对输出风格敏感（客服、写作辅助、对外问答），对齐投入不能省；如果是纯内部的结构化任务，SFT 版本的性价比可能更高。

4.3 误读三：代码和数学专项模型就是挂个适配层

误判点：认为 Code-Qwen 是在通用模型上加个 LoRA、喂点代码数据就完事。

为什么：报告写得很清楚，代码专项模型是在基座之上继续做代码领域的预训练，再做对话微调。继续预训练这一步改的是模型的底层分布，和微调改行为完全不是一个量级的事。数学模型同理，训练路径单独成章。

怎么看：评估任何"专项模型"时，先问它是在哪一步介入的——继续预训练、SFT、还是推理时的提示模板。介入点越靠前，领域能力的上限越高，迁移成本也越高。只做后两步的，通常只能解决格式问题，解决不了能力问题。

4.4 误读四：开源就意味着能直接顶替线上服务

误判点：拿到权重就以为可以平替现有接口，忽略工程侧的落差。

为什么：开源释放的是模型参数，不是推理基础设施。吞吐、并发、量化精度损失、长上下文下的显存占用、异常输入的鲁棒性，这些都得自己验证。报告给的是能力上限，不是线上表现。

怎么看：拿真实业务流量做一轮影子测试，重点看三件事——高并发下的首 token 延迟、量化后效果回退幅度、边界输入（空串、超长、混合语言）会不会崩。这三项过了，再谈替换。

4.5 误读五：报告里的分数可以跨口径横比

误判点：把不同报告里的同一数据集分数直接排排坐，得出"谁更强"。

为什么：同一个数据集，提示模板、few-shot 数量、答案抽取规则、是否允许思维链，都能让分数浮动几个点到十几个点。报告内部的对比是自洽的，跨报告就不自洽了。

怎么看：只信同一份报告内部的横向对比，跨模型比较一律自己重跑。跑的时候固定提示模板和后处理脚本，把变量压到只剩模型本身。这套流程做一次，以后每来一个新模型都能复用。

5. 专项模型怎么切：Code-Qwen 与 Math-Qwen 的领域化路径

通用模型什么都会一点，但每一样都不够深。领域化是绕不开的一步，区别只在于在哪一层下手。报告给了两条完整路径，正好可以对照着看。

5.1 Code-Qwen：继续预训练比微调更决定性

代码模型的路线是：在基座之上用大规模代码语料继续预训练，再做面向代码对话的微调，产出 7B 和 14B 两档，以及对应的对话版本。评测放在 HumanEval、MBPP、HumanEvalPack 这几个基准上，结论是明显好于同尺寸开源模型，略逊于闭源模型。

继续预训练这一步为什么关键？通用语料里的代码占比低，模型见过语法但没见过足够多的真实工程代码——多文件依赖、异常处理、框架惯用法、版本迁移写法，这些在通用预训练里是稀缺样本。继续预训练相当于把模型的概率分布往代码域拽一把，之后再用少量高质量对话数据教它"怎么和人讨论代码"。

这两步的分工不能混。只做微调，模型会模仿代码对话的语气，但写出来的东西经不起运行；只做继续预训练，模型补全能力强，但不会按指令改 bug、不会解释报错。工程上常见的做法是先看你在哪一步有数据——有海量未标注代码就做继续预训练，只有人工标注的问答对就老老实实做 SFT。

5.2 Math-Qwen-Chat：专项模型为什么只做 Chat 版

数学专项只发布了对话版本，7B 和 14B 两档，在 GSM8K 和 MATH 这类基准上大幅超过同尺寸开源模型，接近当时的中档闭源水平。注意它没有单独发基座版本，这个选择本身有信息量。

数学能力的体现方式和对齐强绑定。基座模型能续写解题过程，但不会主动按"先分析、再列式、最后给答案"的结构输出，也不会在题目有歧义时先澄清。这些行为得靠对话数据塑造。换句话说，数学模型的竞争力不只在算得对，还在解得清楚——而"解得清楚"是 SFT 的产物。

从应用角度看，这类模型适合的是需要展示推理过程的教育、审阅、辅助场景；如果只是要一个最终数字，通用模型加代码解释器往往更划算，因为它能把计算交给外部执行，避免模型在算术上栽跟头。

5.3 Qwen-VL 那条支线：多模态的位置

模型谱系图里还有一条独立的支线——视觉语言模型及其对话版本，同样基于这套基座，支持中英文的文本识别和视觉定位，能做多图对话和连续叙事。这条线在报告里只做了引用，细节在另一份文档中。

把它放进谱系图这个动作值得注意：它说明基座是被当作一个平台在用，语言、代码、数学、视觉都是挂在这个平台上的分支。对使用者的启示是，如果你的业务同时涉及文本和图像，优先选同一家族里的多模态分支，能省掉跨模型拼接带来的对齐成本——同一套分词、同一套对话格式、同一套工具调用协议，集成的坑会少很多。

5.4 领域化的通用配方

把两条路径抽出来，能得到一个可复用的四步：

1. 判断领域数据规模。有百万级以上的未标注领域文本，才值得做继续预训练；只有万级以下的标注样本，直接进 SFT。
2. 构造领域评测集。不要用公开榜单当唯一标准，自己标 200 到 500 条真实业务样本，固定评分规则。
3. 继续预训练阶段控制学习率。这一步最容易把通用能力洗掉，用较小的学习率、混入一定比例的通用语料做回放，是常见的止损手段。
4. 对话微调阶段严控数据格式。领域模型的失败大多不是不会，而是输出格式不稳定，结构化模板要在这一阶段锁死。

提示：继续预训练之后一定要重跑通用能力评测。领域分数涨了、通用分数掉了，是典型的灾难性遗忘，靠混入通用语料回放能缓解，但救不回全部。

6. 接下来怎么看：从追参数转向追可复现的工程细节

这份报告真正的价值，是把"怎么做"和"做了什么"分开了。参数、榜单、模型谱系，这些是结果；数据管道、去重策略、分词压缩率、奖励模型的数据构成、领域模型的介入点，这些是过程。结果只能让你知道谁在前面，过程才能让你判断自己能不能追上。

从行业角度看，接下来一年值得盯的三个观察点：

第一，数据配比会不会被更细地公开。现在公开的是"用了哪些来源"，没公开的是"各占多少"。这个比例才是复现的核心，也是各家的护城河。

第二，评测口径会不会标准化。跨报告横比的问题短期解决不了，但如果更多团队开始公布提示模板和后处理脚本，横向对比的可信度会提升。

第三，专项模型的边界会不会继续细分。代码、数学之后，还有一堆垂直领域等着被同样的配方切一遍——谁能把"继续预训练加对话微调"这套流程的边际成本压下来，谁就能更快铺开。

给三类团队一个粗略的起手式参考：

我自己的习惯是，每拿到一份新的模型技术报告，先把数据管道和对齐流程两节单独拎出来读一遍，其余章节快速过。血泪经验来自早年一次线上事故：模型效果突然下滑，查了两天才发现是上游语料更新时把去重阈值调松了，同义重复样本灌进去，模型学会了复读。从那以后我每次做数据版本变更，都强制走一遍小流量对照，宁可慢两天，也不要把这种玄学问题留到线上。这份报告里那些看起来枯燥的清洗步骤和阈值选择，恰恰是这类问题的解药。

完整的模型谱系、预训练数据流程、对齐与评测细节、代码与数学专项的训练路径，都在这份技术资料里，需要的从业者可以自行取用对照。

希望帮到你。

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