★ FEATURED ARTICLE 简介面向大模型研究与开发者的通义千问QWEN开源技术资料聚焦QWEN系列首版技术报告适合希望系统了解国产开源大模型训练路线、对齐方法与能力边界的读者。资料为1个PDF文件压缩包约1.53MB便于本地检索与批注阅读。报告中系统梳理预训练数据构建、分词策略、模型架构、上下文长度扩展与训练流程并给出多类下游任务的实验结果对齐部分覆盖监督微调与基于人类反馈的强化学习同时讨论聊天模型在工具调用、规划及代码解释器等复杂任务中的表现。文中还介绍代码专用模型与数学专用模型的设计与评测可与通用模型对照理解垂直领域优化思路内容含摘要、目录与分节论述方便按主题跳读。已有1698人学习适合研究者、算法工程师和高校学生用作技术选型、论文复现与方案设计的参考底稿。1. 一份技术报告开源之后真正的信息不在参数表里大模型圈子里的技术资料价值常常不在结论而在过程。一份完整的技术报告公开之后多数人第一反应是翻参数量和榜单分数翻完觉得“就这”然后关掉页面。真正值钱的内容压在后面几十页语料怎么去重、奖励模型怎么标、工具调用怎么接、分词压缩率怎么测。这些平时只存在于团队内部文档里的工程细节这一次被完整地摊在了纸面上。这份资料值得从业者读是因为它把一个完整模型家族的施工过程写成了可复现的流程三万亿 token 级别的预训练语料、SFT 加 RLHF 的两段式对齐、通用对话之外延伸出的代码与数学专项分支、多模态能力如何从同一套基座生长出来以及工具调用和代码解释器这类 Agent 能力的验证方式。对做应用的人来说它回答的不是“谁排第一”而是“这条路哪一段最容易翻车”。2. 模型家族拆开看一套基座为什么长出五条产品线把这份报告从头翻到尾最直观的感受是它的组织方式不像一篇论文更像一份产品架构说明。预训练一章、对齐一章、代码一章、数学一章附录里再挂上多模态分支。五个方向共用同一套基座权重各自接不同的后训练管线。这种“一基座多分支”的结构本身就是当前大模型工程化的主流做法也是理解这份资料的第一把钥匙。2.1 基座、对话、代码、数学、多模态的分工边界基座模型承担的是把世界知识、语言能力和基础推理压缩进参数里这件事。报告给出的语料规模是三万亿 token来源覆盖公开网页文档、百科、书籍和代码语种以中英为主并兼顾多语言。这个组合的用意很直接网页保证广度与时效百科和书籍保证事实密度与长文本连贯代码保证结构化推理的语感。三者缺一模型在后面对齐阶段的天花板就会明显偏低。对话模型是在基座上叠加 SFT 与 RLHF 的产物。报告里明确写了对话模型的训练数据覆盖任务执行、闲聊、工具使用、Agent、安全几个方向并且强调的是经过筛选构建的数据集而不是把公开对话语料直接灌进去。这个细节经常被忽略但它决定了对齐阶段到底是在“教模型怎么说话”还是在“教模型怎么说人话还不跑偏”。代码模型和数学模型走的是另一条路先在基座上继续做代码或数学语料的预训练再做对应方向的 SFT。这条路径的必要性在于通用对齐会把模型往“会聊天、会妥协”的方向拉而代码和数学要的是不给面子、只给答案。两个目标在数据分布上是打架的硬用一套 SFT 数据兼顾结果通常是两头都不够好。多模态分支则是在同一套基座权重上延伸支持中英双语的文本识别和视觉定位还能做多图对话与连续叙事。这条线的意义不只是多了一个模态而是证明了基座的语言能力可以迁移到视觉语言联合空间里这对后续做垂直场景的图文理解是重要的信号。分支底座来源后训练方式输入输出形态典型用途基座模型三万亿 token 语料预训练无文本续写二次训练、领域继续预训练对话模型基座SFT RLHF多轮对话助手、客服、任务执行代码模型基座 代码语料继续预训练代码方向 SFT代码生成、补全、解释编辑器插件、代码评审数学模型基座数学方向 SFT推理链输出题库解析、教学辅助多模态模型基座 视觉编码图文对齐图文混合输入票据识别、图文问答这张表看起来只是罗列但它对应的判断是选模型的时候先问自己要哪条分支而不是先问哪个基座分数高。做客服问答的去卷代码模型做代码补全的去卷对话榜单都是典型的错配。2.2 7B 与 14B 的取舍参数规模、压缩率与部署成本这次开源的是 7B 和 14B 两档参数。这个选择不是随手定的而是卡在“能在开发者或应用侧跑起来”这条线上。7B 属于单卡就能加载的量级适合做私有化部署、端侧推理和快速验证14B 是双卡或者单张高显存工作站卡的量级在效果和成本之间取了一个折中。再往上走效果提升的边际收益开始变小而推理成本是线性甚至超线性上升的。比参数量更值得琢磨的是分词压缩率这一节。报告用了一组对比以支持上百种语言的多语言分词器作为基准 1把同期几个同量级的开源模型放进去一起比测的是同样一段文本编码后需要的 token 数量。压缩率高意味着同样的上下文窗口能塞进更多内容也意味着同样的推理预算能处理更长的文档。这个指标平时讨论得少但落到实际部署里非常致命——中文文档的 token 效率差出两成长文档场景的推理成本就差出两成上下文窗口的有效长度也跟着打折。提示评估一个中文场景的基座时压缩率要和上下文长度一起看。窗口写着很长、分词效率很低实际能用的有效长度会被大量浪费在无意义的切分上。想自己验证这件事并不复杂抽一份中英混排加代码的语料用不同分词器跑一遍 token 计数就能得出结论。# 分词压缩率对比骨架同一份语料不同分词器算 token 数比值 import statistics from pathlib import Path from transformers import AutoTokenizer BASE_NAME multi-lang-baseline # 基准分词器比值定为 1 CANDIDATES [model-a-7b, model-b-7b, model-c-14b] def load(path: str, limit: int 100000) - list[str]: 按行读语料截断到 limit 条过滤空行避免空串拉低平均值 lines Path(path).read_text(encodingutf-8).splitlines() return [x for x in lines[:limit] if x.strip()] def token_count(texts: list[str], tok) - int: 逐条编码后累加长度不开启 truncation保证长文本也完整计数 return sum(len(tok.encode(t)) for t in texts) texts load(./corpus/zh_en_code_mix.txt) base_tok AutoTokenizer.from_pretrained(BASE_NAME) base_n token_count(texts, base_tok) for name in CANDIDATES: tok AutoTokenizer.from_pretrained(name) n token_count(texts, tok) print(f{name}\tbase{base_n}\tcand{n}\tratio{n / base_n:.4f})这段脚本的关键在语料构造不在代码本身。语料要分层抽样中文网页、英文网页、代码、数学题各取一份。混在一起算总分会被代码的符号密度带偏因为代码天然切分得碎会把整体比值拉高。limit参数也别设太小一万条以下波动非常大结论不可靠。真要下判断至少按语种分三组分别统计再看比值分布的中位数而不是平均值避免少数极长文档把结果拽偏。2.3 数据侧的三个动作去重、打分、上采样预训练这一章里最有信息量的部分其实是对数据处理的描述可以拆成三个动作来看。去重分成两层。第一层是归一化之后的精确去重处理完全重复的网页转载和模板文本第二层是模糊去重用 MinHash 加 LSH 这类近似算法找出高相似度的文档簇只保留其中质量最高的一份。这两层的作用不只是省算力更关键的是避免模型在少量重复内容上过拟合导致输出风格变得单一。打分环节用的是多个模型叠加语言模型打分、文本质量打分模型、带有冒犯性或不当内容识别能力的模型三者交叉过滤再叠加规则类的清洗手段。这套组合拳的逻辑是任何单一指标都会被数据刷穿只有多指标交叉才能把噪声压下去。报告还提到一个重要动作就是人工抽样复审从不同来源随机抽文本做质量检查——这一步在很多团队的流程里是被砍掉的砍掉之后模型会以一种很难定位的方式变笨。上采样则是选择性动作对某些来源的数据做加权上调保证高质量内容的实际占比。这个动作看起来只是调权重实际上决定了模型的能力分布。报告里没有给出每个来源的具体配比但从它强调的“多样性”和“高质量”两个目标可以推断配比是经过多轮实验调出来的。这三个动作放到一起看会得到一个有点反直觉的结论预训练阶段的工程重心其实不在模型结构而在数据流水线。结构决定能力上限数据决定能不能摸到那个上限。3. 对齐流水线SFT 与 RLHF 各自改掉了什么预训练解决的是“模型知道什么”对齐解决的是“模型怎么用知道的东西回答你”。这份资料把对齐拆成监督微调、基于人类反馈的强化学习、自动与人工评测、工具使用与 Agent 四块顺序上很讲究。前三块是常规动作第四块暴露了当前对齐工作的真实重心——模型能不能调工具、能不能写代码跑起来、能不能分步骤规划这些已经和“话说得漂不漂亮”并列甚至更靠前。3.1 奖励模型整条链上最贵也最容易被跳过的一环强化学习这一段被拆成了奖励模型和强化学习本身两部分。奖励模型是拿人类偏好数据训出来的打分器它决定了强化学习阶段模型会往哪个方向漂。这一步在很多团队的实践里是被跳过的理由通常是标注成本高、周期长于是直接拿开源奖励模型顶上或者干脆只做 SFT。问题是SFT 只能教模型“什么样的回答像答案”教不了“两个都像答案的回答哪个更好”。而后一件事恰恰是产品体验的分水岭。血泪经验是奖励模型训歪了强化学习阶段只会把歪掉的偏好放大模型会学会更长、更谄媚、更像模板的回答因为标注者在这种回答上更容易打高分。这类问题在上线之后极难回滚等于自己给自己埋了个没有后悔药的坑。报告里的一句话值得反复读对齐后的对话模型在人工评测中有竞争力但仍然落后于头部闭源模型。这句话的潜台词是奖励模型能够把模型对齐到“人类更喜欢”但对齐不到“人类认为正确”。偏好和正确之间隔着一条沟这条沟目前靠工具调用、代码执行和检索来填。阶段训练信号来源主要改变成本重心典型失败表现监督微调人工构造的指令-回答对学会指令格式与回答结构数据构造与质检回答像模板、遇难题硬编奖励模型人类偏好对比标注学会给回答打分排序标注规模与一致性偏好长回答、偏好谄媚表达强化学习奖励模型给出的分数放大高偏好回答的分布采样与训练稳定性奖励刷分、输出风格趋同工具与 Agent可执行的工具与反馈学会先规划再作答工具设计与容错参数乱填、忽略返回结果这张表可以用来做一件事当模型表现不对的时候先判断问题出在哪一层而不是一律去加数据。回答格式乱是 SFT 的问题回答方向偏是奖励模型的问题回答正确但过程不可信是工具链路没接好。3.2 工具调用与代码解释器Agent 能力不是接个接口报告专门辟出一节写工具使用、代码解释器和 Agent附录里还有一节单独做代码解释器的分析。这个安排本身说明团队把 Agent 能力当成独立的观测维度而不是对话能力的附庸。工具调用的难点从来不在接口层。真正的三座山是什么时候该调、参数怎么填、返回结果怎么消化。第一件事考的是模型的判断力什么时候该老老实实回答、什么时候该去查第二件事考的是结构化输出能力字段名、类型、嵌套层级不能错第三件事最容易被低估工具返回的东西可能是错的、空的、超长的模型得有本事判断这个结果能不能用而不是照单全收地编下去。代码解释器的意义在于它给了模型一个外部黑匣子。模型自己在脑子里算错了没人知道把计算写成代码交给解释器跑错了会抛异常。这个反馈回路让模型的多步推理第一次有了可验证的中间环节。报告在附录里专门分析代码解释器的表现说明他们很清楚这件事的价值不在“能写代码”而在“能把推理过程外部化、可检验化”。{ tool_call: { name: run_python, arguments: { code: import statistics\ndata [12, 15, 9, 22, 18]\nprint(statistics.mean(data), statistics.pstdev(data)), timeout_seconds: 10 } }, policy: { max_rounds: 3, on_error: return_to_model, on_timeout: abort } }这段结构值得注意的地方有三个。timeout_seconds是必须显式给的解释器卡死在死循环里是最常见的翻车方式没有超时限制一次调用就能把整条请求链路挂住。max_rounds限制的是模型自我纠错的轮次不设上限的话模型会在报错和重试之间反复横跳成本失控。on_error决定错误怎么回流是原样把异常栈丢回给模型还是包装成自然语言描述这两种处理对最终回答质量的影响差别很大。实际接工具的时候还有一条经验返回结果要在长度上做截断和摘要别把几千行的标准输出直接塞回上下文。上下文被工具输出吃满之后模型会开始遗忘最初的任务目标表现出来就是答非所问。3.3 评测口径自动评测与人工评测各自能证明什么报告把自动评测和人工评测分开写这个安排本身就是一种诚实。自动评测跑的是标准基准证明的是模型在已知题型上的得分能力人工评测让标注者面对开放问题做盲评证明的是模型在真实场景下的可用性。两者之间经常出现背离而背离的方向很有信息量。自动评测分数高、人工评测表现一般通常意味着模型在题型分布上过拟合了换个问法就不会。反过来自动评测分数一般、人工评测评价不错往往说明模型的可读性和配合度更好标注者更愿意给它机会。产品上线看的是后一种模型迭代看的是前一种两个都不能丢。值得注意的还有一个细节报告在附录里给了自动评测的具体配置和人工评测的评分维度。这部分内容在大多数技术报告里是不公开的公开之后读者才有可能判断它的结论是不是在自己关心的场景下成立。评测口径不透明是所有“榜单第一”类宣传最大的问题所在。4. 五个常见误读参数、榜单、开源与专项模型的认知偏差这份资料传开之后围绕它的讨论里有一批反复出现的判断其中相当一部分经不起推敲。把这些误读单独拎出来讲比正面复述报告内容更有用因为误读往往就藏在自己团队的选型会议里。4.1 关于参数、榜单与“超越”的三种误读误读一参数量越大能力越强。为什么这么想过去几年的经验确实是大模型赢规模定律被反复验证。怎么看规模定律描述的是训练阶段的损失曲线不是产品阶段的体验曲线。7B 和 14B 之间的差距在特定任务上可能远小于 14B 和更大模型之间的成本差距。选型时应该先固定任务再在同一任务上比不同规模而不是反过来。更实际的做法是先拿最小的那一档跑通全链路跑不通再加参数因为参数加上去容易成本降下来难。误读二榜单分数可以直接换算成产品体验。为什么这么想分数是唯一可比的数字讨论起来省事。怎么看榜单测的是标准化题型产品面对的是用户随口说的一句话。同样一道题换个问法、加一段背景、要求特定输出格式分数会掉得比想象中快。合理的用法是把榜单当成筛子而不是尺子先筛掉明显不行的再用自己业务的真实样本做小规模人工评测。误读三开源就意味着可以随便用、直接用。为什么这么想代码和权重都拿到了感觉没有门槛。怎么看拿到权重和能跑起来是两件事。推理框架适配、显存占用、批处理吞吐、量化之后的效果衰减每一项都要单独验证。量化尤其是个玄学重灾区同一套权重在不同量化方案下代码能力和数学能力的衰减幅度可以差出好几个百分点必须在自己的评测集上重跑一遍再上线。4.2 关于开源与落地的两种误读误读四专项模型等于通用模型加一段提示词。为什么这么想提示词工程被宣传得太万能看起来什么都能调。怎么看专项模型的价值来自继续预训练阶段对数据分布的改写不是来自输出格式的约束。拿通用模型加一句“你是代码专家”改的是风格改不了候选代码的分布。判断方法很简单让通用模型和专项模型各写十个函数看能不能一次通过基本用例——这个差距靠提示词是补不上的。误读五上下文长度扩展只是改一个配置。为什么这么想文档里写着支持多长就以为填个参数就完事。怎么看上下文扩展通常要配合位置编码的调整和一段专门的训练否则模型在长文本中段的信息召回会明显掉。报告里把它单列成一小节说明这是一个需要训练介入的动作不是推理期开关。实际用的时候长文档场景一定要做“中间段落能不能被问到”的抽测只看开头结尾会得出过于乐观的结论。这五条误读的共同点都是把“能跑”当成“能用”把“指标”当成“体验”。这份资料的价值之一恰恰在于它把中间那些不体面的工程细节写出来了看完之后很难再对任何单点指标抱有不切实际的期待。5. 专项模型为什么单独训代码与数学的两条窄路通用模型什么都能聊一点专项模型只做一件事但要做透。这份资料在通用家族之外单独拿出了两章讲代码模型和数学模型篇幅不小结构也很完整预训练、监督微调、评测各一节。这种写法的潜台词是专项能力不是通用能力的自然延伸得单独下功夫。5.1 代码模型的三段式继续预训练、方向微调、基准检验代码这条线的做法是先在基座上用大量代码语料做继续预训练再做面向代码对话的监督微调然后在几个不同的代码基准上验证。报告提到的基准覆盖了函数级生成、多语言代码改写、入门级编程题三类场景评测维度是 Passk 这类“跑通了才算数”的指标而不是文本相似度。这个评测口径的选择很关键。代码任务有一个其他任务没有的优势对错可以被自动验证。写出来的函数跑测试用例通过就是通过不通过就是不通过。这意味着代码能力的评估噪声天然比文本任务低也意味着代码模型的效果提升是能被稳定测出来的不太依赖人工主观判断。继续预训练这一步的必要性也在这里体现得最明显。通用语料里代码的占比很低即使有也多是片段和注释。要让模型学会完整的函数结构、错误处理惯例、常见库的用法必须把代码语料的比例大幅提上去。而这一步一旦做了模型的自然语言风格会受到影响——这是代价需要靠后续的方向微调把对话能力拉回来一部分。报告开源的代码分支覆盖 7B 和 14B 两档同时提供基座版和对话版。这个组合对应用侧很友好基座版适合做继续训练和补全类任务对话版适合做代码问答和解释。选错版本是常见踩坑拿对话版去做纯补全输出里会带上多余的说明文字还得再加一层清洗。5.2 数学模型的路线与天花板数学这条线走的是另一套逻辑。报告里数学模型只有对话版本没有单独的基座版本说明这个分支的目标从一开始就锁定在“解题对话”上而不是“生成更多数学文本”。评测用的是两个层次小学水平的应用题和竞赛级的题目。这两个层次的差距很大前者的难点在读懂题意和列式后者的难点在推理链的构造。报告给出的判断是数学模型在同等规模上明显优于同量级开源模型接近头部闭源模型的水平但仍有差距。这个表述很克制实际含义是常规题型已经能打难题上的推理深度还不够。天花板在哪里在推理链的自我校验。数学题做错的时候多数情况不是不会算而是中间某一步推错了之后没有回头检查。强化学习能改善这个问题的程度有限因为奖励信号来自最终答案的对错中间步骤的质量很难被单独打分。这也是为什么后来的做法普遍往“让模型把计算交给外部工具”这个方向走——把不可验证的推理链拆成若干个可验证的小步骤。对应用团队来说这个判断的实际意义是数学模型适合做题库解析、教学辅助、步骤讲解这类任务不适合直接拿来做需要高可靠性的计算。涉及金额、剂量、工程参数的场景必须接一个真正的计算组件模型只负责把自然语言翻译成计算表达式。5.3 垂类团队的可行路径从专项模型到领域数据看完这两条线能得到一个对中小团队更有用的推论专项能力的技术路径是可以复制到垂类场景的关键在于数据分布的重塑而不是模型结构的改造。具体做法分三步。第一步把领域语料按“是否包含完整任务”来筛只留下有输入有输出的样本去掉纯描述性的文本。第二步用通用基座做一轮继续预训练比例不用太高但要保证领域词汇和表达习惯能被模型吸收。第三步用几百到几千条高质量的任务样本做方向微调样本质量远比数量重要。这里有个反直觉的经验垂类微调最容易失败的原因不是数据太少而是数据太杂。把客服问答、合同条款、产品手册混在一起训模型会学到一种“什么都懂一点但什么都不精”的中间状态表现反而不如不微调。正确做法是先做任务聚类一个模型只服务一类任务宁可多训几个小模型也不要训一个全能模型。6. 从这份资料往后看三个判断和一份落地检查清单6.1 三个会持续生效的判断第一个判断模型家族的拆分方式会成为行业默认。基座、对话、代码、数学、多模态这套结构不是某一家团队的偏好而是能力分工的必然结果。原因很朴素——后训练数据的目标函数互相冲突想在一个权重里同时优化只能取平均取平均就意味着每个方向都不到最优。往后看垂类模型的数量会继续增加而通用模型会逐渐退到“基座供应商”的位置。第二个判断对齐的竞争重心会从偏好转向可验证。奖励模型能把模型调得讨人喜欢但调不到可靠。真正能拉开差距的是工具调用、代码执行、检索这类能提供外部反馈的环节。这份资料用整整一节加一个附录来写代码解释器方向已经很明确了。第三个判断压缩率和推理成本会成为选型的一级指标。中文场景尤其如此分词效率的差异会被长文档和长对话无限放大。过去大家比的是谁的窗口长接下来比的会是谁的有效窗口长。判断观察依据对从业者的影响下一步动作家族拆分成为默认基座与多条专项分支并列组织选型从“选一个模型”变成“选一条管线”按任务拆分模型避免单模型通吃对齐重心转向可验证工具调用与代码解释器单列成节提示词工程的收益下降工具设计收益上升优先把可执行环节接进流程成本指标前移分词压缩率被单独对比中文长文本场景的成本差异被放大上线前先测压缩率与有效窗口6.2 一份上线前的落地检查清单看完全部内容我把对自己最有用的部分压缩成了一段可执行的自检脚本。它不是性能测试而是把几个最容易在最后关头翻车的点固化成流程。# 上线前自检清单把定性判断落成可执行的检查项 CHECKS [ (分词压缩率, 用业务真实语料跑一遍 token 计数比值高于基准 1.15 要重新评估成本), (有效窗口, 构造 8k 以上文档把关键信息放在中段提问验证召回是否稳定), (量化衰减, 同一评测集上比原始权重与量化权重的通过率差值超过 3 个点就换方案), (工具超时, 给所有外部调用设置 timeout并用死循环用例验证熔断是否生效), (输出格式, 用 200 条真实样本统计结构化输出的解析失败率超过 2% 要加约束解码), ] def run(check_list): for name, rule in check_list: # 这里只打印规则实际执行时替换为对应的测试函数 print(f[待执行] {name}: {rule}) run(CHECKS)这五项里最容易漏的是第二项和第三项。有效窗口不测上线后才发现长文档问答答非所问量化衰减不测本地跑得好好的部署到低显存档位上能力直接掉一截。这两件事的共同点是在开发环境里都不会暴露只在真实流量下才现形。我自己的习惯是每次要换基座或者换量化方案都强制把这个清单走一遍哪怕时间再紧也不跳。有一次赶进度跳过了量化那一项上线第二天收到一堆“答非所问”的反馈回头排查了两天才定位到是量化之后数值精度的问题——从那以后我每次换权重都强制走一遍完整清单宁可多花半天。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
