开源7B/14B模型反超同规模SOTA：数据清洗、分词器与对齐流水线是关键

简介：面向大模型开发者、人工智能研究者与进阶学习者的技术资料，以单份PDF收录通义千问Qwen1官方技术报告，重点解决开源大语言模型技术路线不清、论文要点难梳理的问题，适合论文研读、课程汇报与应用选型参考。压缩包共1个文件，仅含1个PDF，体积约1.53MB，轻量便携，便于本地检索、批注和二次整理。内容覆盖Qwen系列基础模型与Qwen-Chat，涉及预训练数据、分词方案、模型架构、上下文长度扩展、训练策略及实验结果，并展开监督微调、RLHF人类对齐和工具调用规划能力，同时介绍Code-Qwen、Code-Qwen-Chat、Math-Qwen-Chat等代码与数学专用模型。报告由Qwen Team, Alibaba Group撰写，正文按引言、预训练、对齐等章节组织，便于按主题定位关键方法与评测结论。已有1698人学习下载，可用于跟踪国产开源大模型的关键设计、整理读书笔记或辅助应用方案调研。

1. 开源 7B 与 14B 模型在 12 个基准上反超同规模 SOTA，靠的不是参数量

「参数量翻四倍，效果就该涨一截」——这个在大语言模型圈子里被反复引用的直觉，被一份公开的开源技术资料正面打破。这份 QWEN 技术报告给出的数字是：14B 参数的基座模型，在覆盖语言理解、知识、推理等 12 个基准的横向对比里，明显超过当时同规模的最好成绩，却依然排在更强的闭源旗舰之后。换句话说，在 7B～14B 这个「单机多卡跑得动」的尺寸上，决定性能强弱的已经不是参数量，而是三件更底层的事：预训练数据清洗得够不够干净、分词器把中文压缩得够不够狠、对齐流水线把基座潜力逼出了多少。下面沿着这三条线索往下拆，重点看每一环的设计动机和能复现的实现细节。

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

报告里有个容易被忽略的表述：语料规模到了 3 万亿 token 这个量级，唯一还值得盯的指标不是「有多少」，而是「里面有多少是重复的、低质的、有害的」。数据规模效应的前提是数据本身得是可学的信号，否则多喂一倍只是把噪声多过一遍。这一章拆数据流水线的四个关卡，以及为什么模糊去重必须上 MinHash + LSH 这套组合。

2.1 一条数据要过四道关：抽取、识别、去重、打分

按报告的描述，原始语料来源包括公开网页文档、百科、书籍、代码，多语言混合且以中英为主。从 HTML 到可训练 token，中间是一条四段式流水线。

第一道是抽取：从 HTML 里剥出正文文本，把导航栏、广告位、页脚这些模板内容剔掉。这一步做得糙，后面所有质量打分的分母都错了。

第二道是语言识别：用工具判定每条样本属于哪种语言，用于后续按语言配比和分词器验证。报告里那张压缩率对比图，就是按语言各随机抽一百万文档做的。

第三道是去重，分两级：归一化之后的精确匹配去重，以及用 MinHash + LSH 做的模糊去重。为什么要两级，下一节展开。

第四道是质量过滤，规则和模型并用。规则侧处理明显垃圾，比如过短、符号密度异常、重复字符占比过高；模型侧不是单一模型，而是多个打分器并行——语言模型打分（判断这段文本像不像自然语言）、文本质量评分模型（判断信息密度和可读性）、以及专门识别冒犯性或不当内容的分类模型。最后还有一步人工抽样复核，从不同来源各抽一批人看。这一步在很多团队里被省掉，但它是校准自动打分阈值唯一靠谱的手段。

提示：多模型打分的目的不是求平均分，而是让每个模型负责一个正交维度。如果几个打分器高度相关，那等于只做了一个维度，白烧算力。

2.2 MinHash 与 LSH：精确去重为什么挡不住模板化网页

精确去重能解决的是字节级重复，比如同一篇稿件被原样转载。但真实网页语料里的重复大多不是原样重复：同一份财报被不同站点套了不同的壳、同一段新闻被改写工具换了同义词、同一模板生成的商品页只改了商品名。这些样本的字节相似度可能只有 60%～80%，精确匹配一个都抓不到，但它们对模型来说是同一份信息重复喂了几十遍。

MinHash 的思路是把「集合相似度」变成「签名相等概率」。先把文档切成 shingle 集合（中文按字符切 k=5 比按空格切稳，因为中文没有天然词边界），然后构造一组哈希函数，每个函数取集合中所有 shingle 哈希值的最小值，得到一个签名向量。关键性质是：两个文档的签名在某个位置上相等的概率，正好等于它们的 Jaccard 相似度。签名长度取 128，就等于用 128 次伯努利试验去估这个相似度。

import hashlib, random def shingles(text, k=5): # 中文语料按 k 个字符切 shingle，避免依赖分词结果 return {text[i:i + k] for i in range(max(0, len(text) - k + 1))} def minhash_signature(shingle_set, num_perm=128, seed=42): rnd = random.Random(seed) m = (1 << 61) - 1 # 大素数，减少哈希碰撞 a = [rnd.randrange(1, m) for _ in range(num_perm)] b = [rnd.randrange(0, m) for _ in range(num_perm)] sig = [m] * num_perm for s in shingle_set: h = int.from_bytes(hashlib.blake2b(s.encode(), digest_size=8).digest(), "big") for i in range(num_perm): v = (a[i] * h + b[i]) % m # 每个位置一个独立哈希函数 if v < sig[i]: sig[i] = v # 只保留最小值，即 MinHash return sig def lsh_buckets(sig, bands=16): # 把 128 维签名切成 16 段，每段 8 维；任一段哈希相同即成为候选对 rows = len(sig) // bands for i in range(bands): yield i, hash(tuple(sig[i * rows:(i + 1) * rows]))

参数怎么选决定了召回曲线。签名长度 128 切 16 段每段 8 行时，两个文档进入同一候选桶的概率是 1 − (1 − s⁸)¹⁶。代入具体值：相似度 0.8 时召回约 95%，相似度 0.5 时只有约 6%。这条曲线很陡，等效于把判定阈值卡在 0.7 附近——高于 0.7 的基本跑不掉，低于 0.5 的基本不误杀。想要更宽松就减段加行，想要更严格就加段减行。

这里的工程要点是两阶段：LSH 只负责生成候选对（便宜，一次哈希），真正的 Jaccard 计算只在候选对上做（贵，但候选集小几个数量级）。全量两两比对是 O(n²)，十亿文档级别根本跑不完；LSH 把它压到了可接受范围。

2.3 上采样与人工抽检：高质量语料为什么要重复喂

报告里提到一个动作：对某些来源的数据做选择性上采样。这听起来像是「数据不够就复制几遍」，其实动机完全不同。

高质量语料天然稀缺。百科、专业书籍、优质代码在总量里占比很低，但单位 token 的信息密度远高于普通网页。如果按原始比例混，这些珍贵样本在 3 万亿 token 里被稀释到几乎不起作用。上采样就是在 token 预算固定的前提下，人为提高高质量源的采样权重，让模型多看几遍。

代价是过拟合风险。同一个高质量文档看三遍，模型可能开始记它的具体措辞而不是学它的表达方式。所以上采样的倍数要配合去重和验证集监控：训练 loss 在高质量子集上掉得异常快、而验证集不涨，就是采样过头了。

人工抽检在这条链路里承担两个职责：一是校准自动打分器的阈值（机器说 0.7 分算合格，人工抽 200 条看看到底合不合格），二是发现规则覆盖不到的坑——比如某种来源的文本全是表格转换残留，规则不认为它低质，但人一眼就能看出来。

注意：训练 loss 漂亮但评测差，十有八九是数据侧的问题，而且大概率是去重没做干净而非质量分不够。重复数据会让 loss 曲线看起来极健康，这是最典型的「黑匣子」误判。

3. 分词器与架构：一个汉字被切成几个 token，决定了多少推理账单

分词器在多数人眼里是个预处理细节，实际它直接决定三件事：同样的中文内容要占多少上下文窗口、推理时每 token 的算力账单、以及模型能学到多长的有效依赖。报告专门用一张图对比不同模型的编码压缩率，说明这不是随手一做的工作。

3.1 压缩率：用一个多语言编码器当刻度尺

压缩率的定义很朴素：同一份语料，用目标分词器编码得到的 token 数，与基准分词器编码得到的 token 数之比。比值越小，说明同样内容压得越狠（即以基准值 1 为单位）。

报告的做法是：随机抽取每种语言各一百万文档构成测试集，以一个支持上百种语言的多语言编码器为基准刻度量（基准值定为 1，不出现在图里），然后横向比较若干同规模公开模型的压缩率曲线。结论有两点值得记：一是中英和代码这三种高频语言上压缩率要足够高，二是其余语种也不能塌——如果为了优化中文词表把其他语言切得稀碎，多语言能力会直接废掉。

为什么这件事重要？上下文窗口是硬约束。同样一段 8000 字的中文技术文档，压缩率差 30%，就是一个装得下、一个必须截断的区别。推理成本同理，token 数就是计费单位，压缩率差 30% 等于推理账单差 30%。

3.2 词表大小的三角权衡：embedding 参数、softmax 成本、低频 token

词表做大能提高压缩率，但不是免费的。embedding 层参数量约等于词表大小 × 隐藏维度 × 2（输入嵌入和输出投影，不做权重共享时）。假设隐藏维度 4096、词表 15 万，光这一层就是 12 亿参数——在一个 7B 模型里占了近两成。这部分参数不参与任何「推理能力」，纯粹是查表开销。

第二笔成本在输出端。每次生成都要在词表维度上做 softmax，词表越大这一步越慢；做投机采样或蒸馏时，大词表还会放大对齐难度。

第三笔是低频 token 的训练不足。词表里塞了大量罕见字符和长尾子词，它们在 3 万亿 token 语料里出现次数可能只有几百次，embedding 基本没被训好，推理时遇到就是随机输出。

所以词表规模的确定过程通常是：先按目标语言的字符覆盖率定一个下界（覆盖 99.9% 以上的实际文本），再往上加高频多字词提升压缩率，然后用验证集确认低频 token 比例不超过某个阈值。中文场景里一个常见误区是直接用英文分词器，一个汉字被切成 2～3 个字节级 token，压缩率直接崩掉，后面所有成本估算全部失真。

from pathlib import Path from tokenizers import Tokenizer def compression_ratio(tokenizer_path: str, corpus_dir: str, lang: str = "zh") -> float: """返回 每字节对应的 token 数，越小说明压缩越狠。""" tok = Tokenizer.from_file(tokenizer_path) # 只加载词表和合并规则，不加载模型权重 total_tokens, total_bytes = 0, 0 for p in Path(corpus_dir).glob(f"{lang}/*.txt"): text = p.read_text(encoding="utf-8", errors="ignore") total_bytes += len(text.encode("utf-8")) # add_special_tokens=False 很关键，否则每条样本会多出 BOS/EOS 干扰统计 total_tokens += len(tok.encode(text, add_special_tokens=False).ids) return total_tokens / max(total_bytes, 1) # 同一份语料跑两个分词器，比值就是相对压缩率

这段脚本的用法是控制变量：语料目录固定、语言固定、只用文件读取不用流式，保证每次统计的分母完全一致。得到每字节 token 数之后，两个分词器的值相除，就得到报告里那种相对压缩率。跑之前记得确认语料没有经过任何清洗差异，否则测出来的是数据差异不是分词器差异。

3.3 架构里那几个不上新闻但必须对的选项

报告在模型架构一节给的是结论性描述，具体组件的选择属于这个规模模型的常见组合。下面这张表是我按这类模型的主流实现整理的，标注了每个组件解决什么问题、以及省掉它会付出什么代价。

GQA 这条最值得单独说，因为它直接影响能不能上线。KV cache 显存大致是 2 × 层数 × KV 头数 × 头维度 × 序列长度 × 批大小 × 每元素字节数。一个 32 层、8 个 KV 头 × 128 维的配置，序列 32768、批 1、fp16 存储，KV cache 约 4GB；如果换成 32 个 KV 头不共享，直接变 16GB。长上下文场景下这一项经常比模型权重本身还吃显存。

4. 上下文扩展与对齐：续写模型怎么变成会听指令的助手

基座模型本质上是个「给定前文猜下一个 token」的机器，它能续写、能补全，但你问它问题，它可能给你续出三个新问题。从基座到能用的助手，中间有两段改造：先把能吃下的上下文拉长，再用 SFT 和 RLHF 把输出分布掰到人类偏好的方向上。这两件事在报告里分属不同章节，但机制上高度耦合——上下文不够长，多轮对话和工具调用的历史根本塞不进去。

4.1 位置插值：上下文变长为什么不改模型结构

RoPE 的一个好处是位置信息以旋转方式作用在 query 和 key 上，模型结构不用为不同长度改设计。但「不用改结构」不等于「直接调大就行」。

直接把训练时的最大长度调大，模型会在超出训练分布的位置上遇到从未见过的旋转角频率，注意力分数分布崩掉，表现为长文后半段完全抓不住前文信息。这是外推失败的典型症状：困惑度在某个位置之后突然飙升。

常见的修法有两类。一类是位置插值：把位置索引整体除以一个缩放系数，让原本 4096 长度训练出的频率分布「拉伸」覆盖到更长范围。实现上只改位置索引，模型权重一个不动。

import torch def rope_after_interpolation(seq_len, dim=128, base=10000.0, scale=4.0): """scale = 目标长度 / 预训练长度；位置索引整体压缩，频率分布随之拉伸。""" pos = torch.arange(seq_len, dtype=torch.float32) / scale # 关键一行 inv_freq = 1.0 / (base ** (torch.arange(0, dim, 2).float() / dim)) freqs = torch.outer(pos, inv_freq) return torch.cos(freqs), torch.sin(freqs) # 直接替换原 RoPE 的 cos/sin 表

参数含义：scale是外推倍数，4 表示目标长度是预训练长度的 4 倍；dim必须和模型里注意力的头维度严格一致，否则 cos/sin 表的形状对不上；base要和预训练时一致，改了等于换了一套频率。这一行除法是全部改动，权重零修改，所以插值方案落地成本极低。

另一类是调整频率底数（NTK-aware 那一类思路），核心是低频维度少插值、高频维度多保留，缓解插值带来的分辨率损失。两条路的取舍在于：纯插值实现最简单但长距离分辨率有损，调频率保留更多细节但要重新扫超参。

真正的坑在于：只改配置不补训练。插值后的模型必须用长文本继续预训练一段，哪怕几百亿 token，让它在新频率分布上重新校准。跳过这步直接上线，短文本任务会先退化，长文本也没真正学会。

4.2 SFT：只对回答算 loss，是对话模型的第一道分水岭

监督微调的数据在报告里被描述为覆盖任务执行、聊天、工具使用、智能体、安全等多个方向。这个构成本身就说明了设计意图：SFT 不是教模型新知识，而是教它「什么场合用什么格式回答」。

实现上最容易被写错的一行是 loss mask。对话样本由 prompt 和 answer 拼成，如果整条序列都算 loss，模型会连「用户问了什么」一起学着生成，推理时容易把自己的提问也续出来。

IGNORE = -100 def build_labels(input_ids, prompt_len): """prompt 段不计 loss，只对 answer 段回传梯度。""" labels = list(input_ids) labels[:prompt_len] = [IGNORE] * prompt_len return labels

prompt_len的边界必须落在 prompt 最后一个 token 之后、answer 第一个 token 之前，差一个 token 就会把分隔符学成回答的开头。多轮对话里每一轮的 prompt 段都要 mask，只留最后一轮或每轮的回答，具体看训练目标——如果希望模型学会多轮连贯，通常保留所有助手轮次的 loss。

SFT 阶段的数据质量比数量重要得多。报告强调数据集是「精选」的，这在工程上的含义是：几万条格式规范、答案准确的样本，效果通常好过几十万条带噪声的抓取数据。噪声样本在 SFT 阶段是有毒的，因为模型在这个阶段学习率不低、epoch 不多，它会把每条样本的格式特征都当真理记下来。

4.3 奖励模型与 RLHF：把「人觉得好」压成一个标量

SFT 之后模型会回答问题了，但「会回答」和「回答得让人满意」是两回事。同一问题可以有多种正确回答，人类偏好其中更简洁、更有条理、更少废话的那个。这种偏好没法写成规则，只能用偏好数据训一个打分器。

奖励模型的训练目标基于 Bradley-Terry 模型：给定同一 prompt 下的两个回答，人类标注哪个更好，模型学习给「更好」的那个更高分。损失函数就是让两者的分差尽量大。

import torch, torch.nn.functional as F def rm_pairwise_loss(r_chosen, r_rejected): # r_* 是奖励模型对整段回答的标量打分，通常取最后一个 token 位置的输出 return -F.logsigmoid(r_chosen - r_rejected).mean()

用 logsigmoid 而不是 sigmoid 加 log，是因为前者数值稳定：分差很大时 sigmoid 会饱和到 0 或 1，取 log 直接变 -inf 或 0，梯度消失。logsigmoid 内部做了等价变形，大分差下梯度仍可用。

拿到奖励模型之后，RLHF 的目标是最大化期望奖励，同时用 KL 散度约束新策略不偏离 SFT 模型太远：目标 ≈ E[r(x, y)] − β · KL(π ‖ π_ref)。KL 项是整条链路的安全阀——没有它，策略会找到奖励模型的漏洞，输出一堆奖励模型打高分但人类看着莫名其妙的内容，这就是 reward hacking。

β 的调法有讲究。β 太小，模型放飞，输出变长、堆砌修饰词、遇事不决先夸一句；β 太大，模型不敢动，RLHF 等于白做。实践中监控两个指标最有效：平均回答长度（异常上涨是 reward hacking 的早期信号）和与参考模型的 KL 值（应该在一个窄区间内波动）。

4.4 自动评测和人工评测为什么会打架

报告同时给了自动评测和人工评测的结果，而且结论有温差：自动基准上基座模型对同规模对手有明确优势，人工评测上 RLHF 版模型有竞争力但仍落后于最强闭源模型。

这不是评测做错了，而是两种评测测的东西不同。自动评测多是选择题或精确匹配，考的是知识覆盖和推理正确性，对格式鲁棒但看不到表达质量；人工评测看的是偏好，回答啰嗦、结构混乱、答非所问都会扣分，而这些恰恰是自动指标完全无感的。

工程上的含义是：拿自动基准做模型迭代的快速反馈，拿人工评测做上线前的最终判断，两者不能互相替代。只看自动指标优化，很容易训出一个「考试型」模型——选择题很准，真对话时答得又长又绕。

5. 避坑与排查：复现这条流水线时最容易翻车的五处

这一章记录五个在复现类似流水线时高频出问题的地方，都按「现象 → 原因 → 解决」写。这些坑的共同点是：不报错、不崩，只是效果莫名地差，属于最消耗时间的血泪经验。

5.1 数据侧：去重和质量分这两个坑最贵

现象一：训练 loss 一路平滑下降，验证集 perplexity 也很漂亮，但下游基准几乎不动。

原因基本可以锁定在去重不彻底。模板化网页、改写稿、同一文档的多语言机器翻译版本，在 token 层面构成了大量近似重复。模型在这些样本上学到的是「记住」而不是「泛化」，loss 自然好看，但学到的分布极窄。更隐蔽的是，如果验证集也来自同一批语料、也带着同样的重复，验证 perplexity 会一起被骗过去。

解决分三步。先用 MinHash + LSH 在文档级做模糊去重，阈值卡在 Jaccard 0.7 附近（对应签名 128 维、16 段每段 8 行的配置）。再对长度超过一定阈值的文档做段落级去重，因为长文档内部的重复段落在文档级去重里被稀释掉了。最后，验证集必须来自独立时间切片或独立来源，不能和训练集共享任何去重前的父文档。

现象二：模型在通用对话上正常，但在某些垂直领域答得极其啰嗦且信息密度低。

这通常是质量打分器的阈值定错了方向。多模型打分时如果只追求「过滤掉低质」，阈值会一路往上调，结果是留下了一批「语法完美、信息量为零」的文本——它们语言模型打分很高（读起来通顺）、有害内容分很低（没风险），但质量评分模型未必认可。三个分数简单加权平均就会漏掉这类样本。

解决办法是把打分从「加权求和」改成「逐维卡阈值」：语言模型分低于某值直接丢（不像人话），有害分高于某值直接丢，质量分低于某值丢。三个维度独立把关，再对边界样本做人工抽检校准阈值。同时保留一小批被过滤的样本做对照集，用来验证过滤器没有系统性偏向某一类来源。

5.2 训练侧：分词器换了、上下文扩了，但预算没重算

现象三：换了一版中文优化过的分词器，模型效果没有预期提升，反而训练变慢、显存吃紧。

原因是 token 预算和 batch 配置没跟着重算。分词器换了之后，同样语料编码出的 token 数变了，如果仍按原来的「每步多少 token」配置跑，实际训练的数据量可能差了 20%～30%。压缩率提高意味着同样 token 数覆盖的原始文本更多，等效 epoch 数变化，学习率调度和总步数就全错位了。

解决方式很直接：换分词器后第一件事是重跑压缩率统计，用新分词器重新编码整个语料并记录精确 token 数，然后按新的 token 数重算总步数、warmup 步数和学习率调度。批大小也要复核，因为序列长度分布会随压缩率变化——中文样本变短了，但代码和长尾语种可能变长，padding 比例会漂移。

现象四：上下文扩展到 32K 之后，短任务指标下降，长文检索任务也没达标。

这是典型的「只改配置不补训练」。位置插值把频率分布拉伸了，但模型权重里对位置关系的先验还是按 4K 训出来的，短序列上位置分辨率被稀释，长序列上又没真正学会利用远端信息，两头不讨好。

正确顺序是：先做插值或频率调整，再用长文本继续预训练至少几百亿 token，让模型在新频率下重新校准，最后才做长上下文的能力评测。补训练的数据要包含足够比例的长文档，不能全是拼接出来的伪长文本，否则模型学到的是「跨越无关片段找关联」而不是真实的长程依赖。评测也要分档：4K 以内看是否退化，8K～32K 看是否真的能定位到中段信息（把关键信息放在文档中间位置测，不要只测开头和结尾）。

5.3 对齐侧：奖励模型过拟合是 RLHF 最常见的翻车点

现象五：RLHF 之后回答明显变长、变客气，开头总有一段铺垫，实际信息量没涨甚至下降。

原因在奖励模型的分布偏移。奖励模型是在 SFT 模型的输出上训的，它见过的好回答和坏回答都来自那个分布。RLHF 训练中策略模型开始生成奖励模型没见过的样本，这些样本落在训练分布之外，奖励模型的打分就不再有意义，模型于是找到了「高分但低质」的区域——通常表现为长度膨胀和套话堆砌。

解决要三道防线一起上。第一，KL 惩罚系数 β 不要调太小，并且在训练中监控与参考模型的 KL，超过阈值就停；第二，奖励模型训练数据要覆盖多样性，同一 prompt 至少三个以上不同来源的回答，避免偏好数据只来自单一生成器；第三，加长度惩罚或长度归一化，把奖励分数按回答长度做归一，让「长」本身不再自动等于「好」。

注意：RLHF 阶段的监控指标里，平均回答长度比奖励分数更值得盯。奖励分数稳步上涨是预期内的，长度跟着一起涨就是危险信号。

6. 工具调用与专家模型：把能力拆开卖，是取舍不是炫技

对齐之后还有一个问题：模型的短板是结构性的，靠堆数据补不回来。算术就是典型——自回归生成把数字当 token 逐个吐，多位数乘法的中间步骤全靠隐式计算，错一位就全错。报告的解法是把这类能力外包出去：让模型生成代码、调用解释器执行、再读回结果。同一思路延伸到工具调用，模型输出的不再是一段散文，而是一个结构化的调用请求，规划与执行彻底分离。这个设计的代价是链路变长、失败面变多（解析失败、参数幻觉、执行超时），收益是精确计算和多步任务从「概率上可能对」变成「确定性地对」。

专家模型是另一种拆法。代码方向是在基座之上继续用大量代码语料预训练，再做代码对话的监督微调，专门处理代码生成、调试和解释；数学方向同理，在数学题上做对齐后，小学应用题和竞赛级题目的表现都明显超过同规模公开模型，逼近更强的闭源通用模型。取舍很清楚：

我一般会这么判断：如果某个窄任务占总调用量的一半以上，且通用模型在该任务上的错误率不可接受，才值得单独训一个专家模型；否则优先把工具调用做扎实，用一个通用模型加外部执行器覆盖大部分长尾需求。多套权重并存带来的运维复杂度，往往比训练本身更消耗人。这份技术资料的价值不在于告诉你「我们也做了专家模型」，而在于它把基座、对齐、工具、专家这四条路的训练细节和评测口径都摊开了，你可以按自己的调用分布去对号入座。

从那以后我每次评估一个模型方案，都会先把调用日志按任务类型聚类，算出每一类的占比和通用模型的错误率，再决定要不要拆专家模型——不先做这一步就上手训，八成是在给自己造维护负担。希望帮到你。

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