EuroLLM-1.7B与Instruct差异：指令微调、对话模板与选型

做模型选型的时候经常被新手问到同一个问题同一个模型名字后面挂个-Instruct下载下来体积差不多、参数量一模一样为什么一个能规规矩矩回答问题另一个却像没睡醒一样自顾自往下续写这次就拿EuroLLM-1.7B和EuroLLM-1.7B-Instruct这一对来做拆解。前者是多语言方向的紧凑型基座模型主打在有限参数量下覆盖多种语言的自回归预训练后者是它在指令数据上做过监督微调之后的对话版本。两者参数量、层数、词表完全一致差的只是最后一公里的指令调优Instruction Tuning。这篇文章想讲清楚三件事这两个模型在权重和行为上到底差在哪里、指令调优那套流程的内部机制是什么、以及在实际部署和二次开发中怎么把这份差异用对地方。不管你是刚接触模型微调的新手还是已经在做小模型落地的从业者下面这些内容都能直接抄去用。1. 两个模型到底差在哪从权重到行为的差异拆解1.1 参数一样、体积一样为什么表现像两个物种先把最容易被误解的一点讲透Instruct 版本不是换了个更大的模型也不是重新预训练了一轮。EuroLLM-1.7B 和 EuroLLM-1.7B-Instruct 的config.json里hidden_size、num_hidden_layers、num_attention_heads、vocab_size、max_position_embeddings这些关键字段是完全一致的参数量都在 1.7B 这个量级权重文件大小差异基本只在数值精度上。所以你在显存占用、推理速度、量化难度上看到的差别微乎其微——fp16 下光权重就是 3.4GB 上下跑在消费级显卡上毫无压力。真正的差别藏在权重的数值分布里。基座模型的训练目标是纯粹的下一 token 预测它的训练语料是海量文档、网页、书籍、多语言平行语料学习目标是给定前文最可能的下一个词是什么。这个目标让它成了一个极强的语言建模器但它从来没有被明确告知当有人问你问题的时候你应该给一个答案。它见到的所有文本都是自然流动的问题后面跟着的通常是另一段论述而不是一个收敛的回答。Instruct 版本在这个基础上又跑了一轮监督微调训练数据变成了成对的(指令, 回答)模型被迫学习一种新的条件分布给定指令输出回答并且在回答结束时输出终止符。这里有个很直观的类比。基座模型像一个读遍了图书馆但没上过班的实习生知识量大、联想能力强但你让他写个周报他可能给你续写出一篇关于周报这种文体历史演变的散文。Instruct 版本像是这个实习生参加了几万次模拟面试和模拟汇报被反复纠正问什么答什么、答完就停于是形成了行为习惯。知识底座没变变的是行为的对齐程度。所以你会观察到一个很有意思的现象在纯语言建模的困惑度指标上基座模型往往还略优于 Instruct 版本——因为 SFT 会把分布往指令-回答这个窄分布上拽自然会牺牲一部分通用建模能力。这就是所谓的灾难性遗忘在小模型上尤其明显的原因。而在指令遵循、格式稳定性、多轮对话这些维度上Instruct 版本是碾压式的。1.2 指令微调真正改掉的三样东西很多人把指令微调理解成喂点问答数据训一下这个理解太粗。从工程角度看这一轮训练其实动了三样东西缺一不可。第一是损失计算的掩码loss mask。指令数据的形式是提示 回答拼接成一条序列但反向传播时只对回答部分计算交叉熵提示部分置为 -100 不参与梯度。为什么因为提示是用户给的模型不需要学习如何生成提示它需要学的是给定提示后如何生成回答。如果不做 mask模型会把大量梯度花在复述用户问题上小模型容量有限这部分浪费极其致命。这个细节在早期很多自研 SFT 脚本里被忽略训出来的模型喜欢在回答前把问题复述一遍就是 mask 没做对。第二是对话模板chat template与特殊 token。指令数据不是裸文本它有结构化标记谁在说话、说到哪里结束、下一位是谁。EuroLLM 的 tokenizer 里内置了一套角色标记 tokenInstruct 版本在训练时反复见过这些标记因此在推理时必须用完全相同的模板拼接输入否则模型看到的分布和训练分布不一致效果会断崖式下跌。这一点后面会专门展开是踩坑率最高的一环。第三是终止行为。预训练语料里的文本是连续流动的模型没有说完了这个概念所以在基座模型上做生成它经常洋洋洒洒停不下来直到撞上max_new_tokens上限才被硬截断。SFT 阶段每条样本末尾都有结束标记模型学会了回答完毕就输出终止符这是 Instruct 版本体验上最直观的改善之一。1.3 什么场景该用哪个一张判断表选型这件事没有绝对答案但有几个明确的判断依据。我整理成表实际项目里对着看就行。使用场景推荐版本原因开放域对话、客服问答、助手类应用Instruct开箱即用格式稳定会说我不知道文本续写、风格模仿、数据合成基座分布更自然不会强行收敛成问答腔作为二次 SFT 的起点Instruct已有指令遵循能力收敛快、数据需求少领域自适应预训练DAPT基座需要完整语言建模能力避免指令行为被覆盖分类、抽取、打分等判别任务基座 线性头只借用编码能力不需要生成行为多语言翻译草稿视情况基座在平行语料上学得扎实Instruct 更听格式指令有一条经验值得单独说如果你的下游任务需要的是续写千万别用 Instruct。我见过有人想用 SFT 模型做风格化文案生成结果模型总想在结尾加一句总结或者问一句还需要我做什么吗这就是指令行为在干扰。反过来如果你要做的是任务型应用用基座去拼 few-shot 提示你会发现格式稳定性差得离谱十次里能有三四次输出跑偏工程上根本没法用。2. 指令调优的核心原理与数据配方2.1 SFT 的损失函数细节为什么 mask 这么重要把 SFT 的损失写清楚很多现象就自然解释得通了。设一条样本拼接后的 token 序列为 $x_1, ..., x_T$其中提示部分长度为 $P$回答部分为 $P1$ 到 $T$那么损失是$$\mathcal{L} -\frac{1}{T-P}\sum_{tP1}^{T}\log p_\theta(x_t \mid x_{t})$$分母是回答长度而不是总长度这一点在实现时容易被写错——如果用总长度做分母长提示短回答的样本梯度会被稀释模型学不到东西。我在检查别人的训练曲线时第一件事就是看 loss 的量级如果一开始 loss 就低得离谱比如 0.5 以下大概率是 mask 写反了把回答部分给屏蔽了。另一个细节是标签偏移label shift。因果语言模型的输入和标签是同一序列错一位所以 mask 的边界要跟着错位。提示最后一个 token 的标签应该是回答的第一个 token它是参与 loss 的。这种差一位的 off-by-one 错误极其隐蔽训练能跑起来、loss 也在降只是效果差一截很难通过日志发现。实操中还有一个取舍是否对多轮对话的每一轮都计损失。常见做法是只对助手回复计损失用户轮次全部 mask 掉。但有些团队会保留一小部分用户轮次预测认为这有助于模型理解对话节奏。我的看法是1.7B 这种规模的模型容量紧张老老实实只训回复部分别把参数预算浪费在学用户说话上。2.2 数据配比小模型的 SFT 不是越多越好这一点跟大模型的经验完全不同。7B、13B 以上的模型做 SFT数据量往往能吃到几十万甚至上百万条还在涨点但 1.7B 这个量级高质量数据几万到十几万条基本就到顶了再往上加收益迅速衰减甚至开始损伤基座能力。EuroLLM 这个系列本身是多语言定位所以它的 Instruct 版本在数据配比上必须解决一个额外的难题语言之间的能力平衡。如果指令数据里某几种语言占了绝大多数小模型很容易出现某种语言回答流畅、另一种语言开始胡言乱语的现象。这在 1.7B 上比在 9B 上严重得多因为容量小、语言间的表征挤在一起互相干扰更明显。我实践下来觉得比较稳的配比思路是这样的主体语言指令数据占比 40% 到 50%保证主要使用场景的质量其余语言按使用频率分档高频语言 10% 到 15%低频语言保底 3% 到 5%保底的作用是防止完全失效混入 5% 到 10% 的预训练原始文本replay data这一步是防遗忘的关键很多团队省掉了结果训完发现模型连基本的语言流畅度都下降了任务类型上保持多样性问答、摘要、改写、抽取、翻译、拒答各占一定比例单一任务占比不超过 25%。数据质量的判断标准我一般看三条回答是否是模型自己能产生的别用超大模型的输出直接灌风格差距太大会学歪、长度分布是否合理全是一样的长度说明是模板批量生成的、是否存在明显的幻觉小模型学幻觉学得特别快。这三条里最容易被忽视的是第一条用大模型蒸馏数据给 1.7B 训练效果经常不如用同等规模模型生成或者人工整理的数据因为表达能力差距摆在那里小模型模仿大模型的措辞会导致输出显得撑不起来。2.3 训练超参怎么定给出可复现的起点超参这块我不喜欢讲玄学直接给一组在 1.7B 量级上比较稳的起点然后说明每个参数为什么这么定。参数推荐值选择依据学习率1e-5 ~ 2e-5全量/ 1e-4 ~ 2e-4LoRA全量微调学习率要比预训练小一到两个数量级防止破坏已有表征LoRA 只训低秩增量可以用大一些训练轮数2 ~ 3 epoch超过 3 轮小模型几乎必然过拟合表现为输出套话化批大小有效批 32 ~ 64 条样本太小梯度噪声大太大在有限数据上收敛过快学习率调度cosine 3% warmupwarmup 太少前期容易崩太多浪费训练步权重衰减0.01 ~ 0.1抑制过拟合小模型上取偏大值更稳梯度裁剪1.0指令数据长度差异大裁剪能防偶发爆炸精度bf16比 fp16 数值范围大不容易溢出省心关于 epoch 数量我想多说一句。2 到 3 轮这个数字看起来保守但如果你观察过 loss 曲线就会明白第 1 轮结束 loss 快速下降第 2 轮缓慢下降第 3 轮之后基本平了而验证集上的指令遵循表现往往在第 2 轮末就到顶。继续训下去模型会开始死记训练集的措辞你问它任何问题它都会用同一套句式回答这就是典型的模板腔过拟合。判断是否过拟合有个很土但有效的办法准备 20 条完全没在训练集里出现过的开放式问题训练前后各跑一遍人工看回答的多样性。如果训练后所有回答都以这是一个很好的问题或者类似的句式开头立刻停往回退一个 checkpoint。2.4 对话模板最容易被低估的一环模板这件事值得单独拎出来讲因为它是实际使用中出错率最高的地方而错误表现又特别有迷惑性——模型不是完全不回答而是答得似是而非让你以为是模型能力问题。指令微调时训练样本会被拼成类似这样的结构角色标记 用户内容 角色标记 助手内容 结束标记。模型在这个格式上训练了几万次形成了强条件依赖。推理时如果你直接把裸问题丢进去模型看到的输入分布和训练时完全不同它可能仍然会给出答案因为问题本身有强引导性但质量、稳定性、多轮一致性都会明显下降。正确做法是从 tokenizer 配置里读模板不要手写。主流推理框架支持直接从tokenizer_config.json里的chat_template字段渲染这样能保证和训练时完全一致。手写模板的问题在于空格、换行、特殊 token 的边界位置肉眼几乎看不出差别但 tokenize 之后序列就不一样了。我见过最典型的一个 bug 是模板末尾少了一个换行导致模型生成的第一 token 是空格然后整段回答的格式就乱了。还有一个隐蔽的坑部分推理框架在应用模板时会自动添加 BOS而模板本身已经包含了 BOS结果序列开头有两个 BOS。这个错误不会报异常只是效果变差。排查方法是把最终喂给模型的 input_ids 打印出来和训练时的样本对比前几个 token一眼就能看出来。3. 实操两个模型的加载、推理与对比测试3.1 环境准备与显存预算先把环境和资源算清楚。1.7B 模型对硬件非常友好但有几点要提前规划。显存方面fp16 权重约 3.4GB加上推理框架开销和 KV cache单条 4k 上下文推理大概占 5GB 到 6GB。KV cache 的量级可以估算每 token 每层的 KV 占用约为2 × num_kv_heads × head_dim × 2 bytes按 24 层、8 个 KV 头、head_dim 128 估算每 token 约 96KB4k 上下文单条序列就是 400MB 左右。批量推理时这个数字线性增长8 条并发就要 3GB 以上所以批量场景要留足余量。如果要做 LoRA 微调显存需求会上一个台阶。用 8bit 优化器加梯度检查点1.7B 的 LoRA 训练在 16GB 显存的卡上可以跑起来batch size 大概能到 4 到 8取决于序列长度。全量微调则需要 40GB 以上因为 AdamW 要为每个参数维护两个动量加上梯度和权重每参数约 16 字节1.7B 就是 27GB 起步。依赖这块没什么特殊的主流推理和微调框架都支持这个架构pip install torch transformers accelerate peft datasets加载模型时注意两个模型要分开实例化不要试图共用。虽然结构一样但权重不同混着用会出现极难排查的问题。import torch from transformers import AutoModelForCausalLM, AutoTokenizer base_id eurollm-1.7b # 基座 instruct_id eurollm-1.7b-instruct # 指令版 tok AutoTokenizer.from_pretrained(instruct_id) model AutoModelForCausalLM.from_pretrained( instruct_id, torch_dtypetorch.bfloat16, device_mapauto, )3.2 基座模型的正确打开方式续写而非问答用基座模型最常见的错误就是直接提问然后期待答案。它的行为逻辑是续写你给什么它就顺着往下写。prompt 请解释一下什么是梯度裁剪。 inputs tok(prompt, return_tensorspt).to(model.device) out model.generate(**inputs, max_new_tokens200, do_sampleFalse) print(tok.decode(out[0], skip_special_tokensTrue))实测下来这种裸提示的输出大概率是模型顺着请解释一下什么是梯度裁剪这句话往下写可能会写出请解释一下什么是学习率。请解释一下什么是动量。这类重复句也可能写出一段看似相关但结构松散的内容然后一直不停直到 max_new_tokens 用完。这不是模型不会而是它不知道该停了。要让基座模型干活得把它放回它熟悉的语境里也就是用少样本示例构造续写上下文few_shot 问什么是学习率 答学习率控制每次参数更新的步长太大容易震荡太小收敛慢。 问什么是梯度裁剪 答这种写法能显著提升输出质量因为模型看到了问-答的模式会顺着续写答案。但即使这样格式稳定性仍然有限输出长度不可控偶尔会自己编出第三个问题。这就是为什么工程上不推荐用基座做任务型应用——它的行为太自由了。另外一个实用技巧是用停止字符串收敛输出。既然基座不会自己停那就在提示里埋一个它大概率会跟随的分隔符然后在生成时把这个分隔符设为停止条件。这属于工程上的将就方案能用但不如直接用 Instruct 版本省事。3.3 Instruct 模型的对话推理模板对齐是关键Instruct 版本的正确用法是走对话模板渲染把消息列表交给 tokenizer 处理让它按训练时的格式拼接。messages [ {role: user, content: 请用三句话解释什么是梯度裁剪。} ] prompt tok.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue, # 关键补上助手起始标记 ) inputs tok(prompt, return_tensorspt).to(model.device) out model.generate( **inputs, max_new_tokens256, do_sampleTrue, temperature0.7, top_p0.9, repetition_penalty1.05, eos_token_idtok.eos_token_id, ) print(tok.decode(out[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue))这段代码里有几个点必须说清楚每一个都对应一类实际故障。add_generation_promptTrue的作用是在拼接完用户消息之后补上助手角色标记告诉模型该你说了。如果漏掉这个参数模型看到的序列结尾是用户消息的结束标记它可能会自己编一个用户提问接下去或者干脆不输出。这是使用率最高但最容易忘的参数。eos_token_id要显式指定。有些模型的生成配置里会包含多个终止 token如果只传单个 id模型在输出另一个终止符时不会被识别为结束结果就是回答完了还在继续。稳妥的做法是检查generation_config.json里配置的终止 token 列表一并传进去。解码参数方面做事实性问答时temperature建议压在 0.2 到 0.4让输出更确定做创意生成可以放到 0.8 到 1.0。repetition_penalty不要超过 1.1超过之后模型会为了避开重复而刻意换词反而导致表达别扭甚至语义错误。这个参数我一般设在 1.03 到 1.08 之间小模型上偏保守一点更安全。还有一个批量推理的细节decoder-only 模型必须用left padding。因为生成时新 token 是往序列末尾追加的如果 padding 在左边所有序列的最后一个有效位置对齐的是填充位而不是真实内容输出会全乱。设置方式是tok.padding_side left并且要确保pad_token有定义——有些模型默认没有 pad token会用 eos 顶上这时要注意 batch 内的 loss 计算不受影响推理时无所谓训练时要注意 mask 掉。3.4 对比测试怎么设计别用几个 case 下结论想真正看清两个版本的差距得有结构化的测试方案而不是随便问几句凭感觉。我通常用四个维度维度一指令遵循率。准备 50 条带明确格式要求的指令比如用三个要点回答只输出 JSON回答不超过 30 字统计满足格式的比例。基座模型在这个指标上通常只有个位数到二十几Instruct 版本能到 70% 以上差距非常直观。维度二终止行为。统计输出是否在语义完整处自然结束而不是被 max_new_tokens 截断。基座模型的自然终止率往往很低Instruct 版本大部分能正常收尾。维度三语言一致性。给一个某语言的指令看回答是不是同一种语言。1.7B 多语言模型上这个指标波动较大尤其是低频语言Instruct 版本因为训练数据里有语言约束的样本表现会更稳定。维度四知识准确性。用一批有确定答案的事实性问题人工核对。这个维度上两个版本差距最小因为知识来自预训练SFT 阶段几乎不注入新知识——这也解释了为什么指令调优不能解决幻觉问题它只是让模型更会用已有的知识。实测中我记录的一组典型对比如下同一批 50 条中文指令温度 0.3单次采样指标基座模型Instruct 版本格式遵循率约 14%约 76%自然终止率约 8%约 88%平均输出长度token远超上限120 左右语言一致性约 70%约 92%事实性正确率相近相近注意最后一行这个结论很重要指令调优提升的是行为不是知识。如果你的场景核心痛点是模型不知道某个领域的事实那做 SFT 是解错题了应该去做检索增强或者领域继续预训练。4. 常见问题与踩坑排查实录4.1 输出停不下来或者提前截断停不下来是最常见的问题原因分两类。用基座模型时这是预期行为因为它没学过终止符只能靠max_new_tokens硬截或者靠停止字符串兜底。用 Instruct 版本还停不下来就要查三处终止 token 是否传全了、模板是否正确应用模板错了模型就不知道自己在什么角色里自然不会输出该角色的结束标记、max_new_tokens是否小于模型想说的长度。提前截断则是另一种情况——模型刚说到一半就停了。这通常是因为某个 token 被误当成了终止符。检查方法是把生成配置里的终止 token 列表打印出来看是否包含了一些高频普通 token。这种情况在用自定义 tokenizer 或者手动改过生成配置之后容易出现。还有一种少见的病态表现模型输出一整段然后重复开头进入循环。这多半是repetition_penalty设得太低配合高温度导致的把温度降下来、惩罚稍微提一点就能缓解。4.2 答非所问九成是模板问题Instruct 模型答非所问先别怀疑模型能力按这个顺序排查第一步打印实际喂进去的 input_ids 对应的文本看模板拼出来的东西长什么样。正常的应该是清晰的角色划分如果看到两个 BOS、缺少角色标记、或者用户内容和助手标记之间没有换行就是模板问题。第二步确认模板来源。手动拼接的模板几乎一定会有细微偏差正确做法是用 tokenizer 内置的模板渲染。第三步确认 system 消息是否被支持。有些模型在 SFT 阶段没有训练过 system 角色你给它加一条 system 消息它会把这个角色标记当成未知内容行为变得不可预测。判断方法是查模型卡里的说明或者做个小实验加 system 和不加 system 各跑一遍如果加了之后效果明显变差说明不支持。第四步检查多轮对话的历史拼接顺序和角色交替是否符合训练格式。有些模板要求角色严格交替如果连续两条 user 消息模板渲染可能会出错。4.3 量化之后效果崩了1.7B 这种小模型对量化特别敏感这是容量决定的。7B 模型做 4bit 量化损失通常在可接受范围内1.7B 做 4bit往往会看到明显的表达退化和格式遵循率下降严重的时候连完整句子都说不利索。我的建议是优先用 bf16 或 fp16 部署1.7B 的显存需求本来就不高量化的收益有限。如果确实显存吃紧优先考虑 8bit 而不是 4bit。如果非要 4bit那至少要做一次完整的对比评测把格式遵循率和人工抽样质量都过一遍别只看困惑度——困惑度对量化不敏感但行为退化可能已经很严重了。另外提醒一句量化对基座模型和 Instruct 模型的影响不一样。Instruct 版本因为行为更依赖精细的权重分布尤其是终止判断和格式控制量化后退化往往更明显。4.4 常见问题速查表现象最可能原因排查动作基座模型输出跑题、重复提示未提供任务语境加少样本示例或改用 InstructInstruct 输出像续写未应用对话模板用apply_chat_template渲染回答完不停止终止 token 未配全检查生成配置的终止 token 列表批量推理结果全乱用了 right padding改为 left padding输出开头多空格或格式乱模板末尾多了/少了换行打印 input_ids 文本核对模型开始复述问题SFT 时未做 loss mask检查训练脚本的标签掩码多语言能力失衡指令数据语言配比失衡提升低频语言占比混入 replay 数据输出全是同一套句式训练轮数过多过拟合回退 checkpoint减少 epoch量化后格式全崩4bit 量化对小模型损伤大改用 8bit 或 bf16加了 system 消息反而变差模型未训练 system 角色去掉 system合并进 user 内容5. 微调与二次开发实战建议5.1 从哪个版本起步两条路线的取舍做领域微调时第一个决策就是拿基座还是拿 Instruct 做起点。这两条路线我都跑过结论是取决于你的数据量和领域与通用分布的差距。如果你有几千到几万条高质量的领域指令数据直接拿 Instruct 做 LoRA 微调是最省事的路线。它已经有指令遵循能力你的数据只需要教会它领域知识和输出风格收敛很快通常 1 到 2 个 epoch 就够。缺点是容易把原有的通用能力覆盖掉尤其是数据领域比较窄的时候训完模型可能只会答你这一类的题其他问题一律往这个方向靠。如果领域和通用分布差得很远比如某种专业符号体系、特定格式的结构化文本或者你有大量无标注领域文本那更合理的路线是先拿基座做领域继续预训练DAPT再在得到的模型上做指令微调。这条路成本高得多但能力沉淀更扎实不会出现只会答题不懂行的情况。有个折中方案我经常用拿基座做少量领域继续预训练然后和 Instruct 版本的权重做线性插值再小规模 SFT 一次。这个做法在一些场景下能同时拿到领域适配和指令能力代价是要多调一个插值系数。这条路径不一定适合所有项目但如果直接 SFT 的效果撞墙了可以试试。5.2 LoRA 参数怎么设给出计算过程和取值LoRA 的核心是用两个低秩矩阵近似权重更新参数量为r × (d_in d_out)其中 r 是秩。在 1.7B 模型上如果只对注意力层的 q、k、v、o 四个投影做 LoRAr 取 16可训练参数大概在几百万量级占全模型的 0.2% 到 0.5%单卡 16GB 完全够用。如果要把 MLP 层也加进去gate、up、down 三个投影可训练参数会翻两三倍效果通常更好一些但显存和训练时间也上去了。我的经验是任务简单风格、格式只动注意力层就够任务复杂领域知识注入加上 MLP 层收益明显。具体配置我一般这么写from peft import LoraConfig, get_peft_model lora_cfg LoraConfig( r16, lora_alpha32, # 通常是 r 的 2 倍 lora_dropout0.05, biasnone, task_typeCAUSAL_LM, target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], ) model get_peft_model(model, lora_cfg) model.print_trainable_parameters()lora_alpha和r的比例关系影响更新幅度alpha 取 r 的 2 倍是常见起点。如果训练 loss 降不下去先把 alpha 调大试试如果过拟合快把 r 降下来或者把 dropout 提到 0.1。训练时的 batch 组织要注意按 token 数而非样本数来控制。指令数据的长度差异可能达到十倍以上如果按样本数固定 batch长样本那一步的显存会突然爆掉。稳妥做法是用长度分组length grouping或者动态 padding 到 batch 内最长同时设一个 token 上限截断。5.3 评测别骗自己几个实操原则微调做完最容易犯的错误是拿训练集里挑出来的样本做测试看完觉得效果不错就上线。这种自欺欺人的评测方式在小模型项目里特别普遍因为小模型的效果波动大你总能挑出好的样例。几条我认为必须坚持的原则。第一测试集必须和训练集在来源上分开最好是不同时间、不同渠道收集的数据同源数据里藏着大量相似表达会让评测结果虚高。第二评测要跑全量而不是抽样至少几百条因为小模型的输出方差大抽十条看不出真实水平。第三要有基线对比和微调前的模型在同一批数据上跑否则你无法判断提升来自微调还是数据本身简单。第四格式类指标要自动化质量类指标要人工别指望用另一个模型来打分就完事1.7B 这个量级的输出问题往往是细微的表达退化自动打分器识别不出来。还有一点值得强调关注退化而不只是提升。微调之后专门挑一批通用问题去问看模型是不是把原来的能力弄丢了。我见过太多案例领域任务指标涨了十个百分点通用问答能力掉了一半这种模型上线后用户体验反而更差。防退化的手段前面提过——混入 replay 数据、控制 epoch 数、用较小的学习率。最后分享一个我实际调试时常用的小技巧把两个模型的输出并排放在一起看不要看单条看一批。单条输出很容易被某句话的说服力带偏但并排看二十条行为模式的差异会非常明显——基座的回答往往发散、长短不一、偶尔跑题Instruct 的回答结构规整、长度接近、偶尔过于套路。看清这个差异你就知道自己该往哪个方向调了如果觉得 Instruct 太套路说明训练数据多样性不够如果觉得基座太散说明你需要的正是那一轮指令对齐。