在本地部署过几个开源基座模型之后很多程序员的感受其实高度一致模型确实能跑起来但回答总不如官方Demo里那么“听话”。你问它东它给你续写西你要它按JSON格式输出它偏要自由发挥加一段解释。这个差距十有八九出在监督微调SFT这一环上。SFT全称是Supervised Fine-Tuning简单说就是拿一批人工标注好的“指令-回答”数据对预训练基座模型做有监督的再训练让模型学会人类期望的交互方式。这篇内容我会把SFT的原理、数据构造、超参数、训练配置、实操流程和踩坑记录一次性讲透。它不是泛泛的科普而是对着能做事的实践总结写下来之前已经在多台机器上反复验证过建议直接存下来备查。1. 先搞清楚SFT在整条链路里的位置1.1 基座模型只会“续写”不会“干活”很多人第一次玩开源基座模型时都会有这个困惑模型明明很大常识也很丰富为什么跟它对话就特别别扭这是因为基座模型在预训练阶段的唯一目标函数是“下一个词预测”。它学到的本质是词与词之间的统计关联你输入一段文本它就按照统计规律往后接最可能的词而不是“理解你的问题然后给出答案”。拿生活化的例子来说基座模型像一个博览群书但没参加过考试的学生。你问他一道题他凭记忆和语感展开长篇大论却不知道答案应该是一句话、一段代码还是一个JSON对象。他不知道考试有固定格式、有标准答案、有答题边界。这些“约定俗成”的东西预训练阶段没有专门教过只能靠SFT来补课。这种能力差距在实际部署中非常致命。比如你打算做一个代码助手希望模型根据需求生成Python脚本基座模型可能会输出一大段自然语言解释再夹几行伪代码甚至把问题换个说法又重复一遍。而经过SFT的模型才知道用户问代码时应该先给代码块再给简要说明。所以SFT解决的是“形式对齐”和“指令跟随”问题不是知识注入问题。1.2 SFT、预训练和RLHF的分工关系大模型从零到可用的链路一般可以拆成三个阶段预训练、SFT、偏好对齐常见手段是RLHF/DPO。这三者分工完全不同。预训练负责往里灌知识让模型具备语言能力、事实记忆和推理基础这一步成本最高通常需要几千亿token和成百上千张显卡。SFT负责教模型“怎么把知识组织成用户想要的样子”用几千到几万条高质量的指令数据就能完成任务。偏好对齐则更进一步它解决的是“模型知道答案是什么但不一定知道哪个答案更符合人类品味”的问题。SFT给的是标准答案就像教科书上的参考答案偏好对齐给的是一堆答案排序就像阅卷老师告诉你“这个回答比那个更流畅、更有用”。SFT是基础没有好的SFT模型偏好对齐做起来会非常吃力因为模型连基本的指令格式都没学好。我见过不少团队为了省事跳过SFT直接尝试用偏好优化方法调基座模型结果模型学会了说漂亮话但依然不会严格按要求办事。原因很简单排序学习只能调整回答风格的倾向无法补上“格式不对齐就是听不懂人话”这个根本短板。SFT是让模型“听得懂人话”的最低成本方案。1.3 为什么SFT数据不多却能改变模型行为一个值得思考的问题预训练看了几千亿token为什么SFT只用几万条数据就能明显改变模型行为这里的关键在于SFT改变的不是知识量而是“概率分布的输出模式”。模型在预训练阶段其实已经见过大量问答类文本它具备回答问题的潜力只是不知道怎么判断“当前这是在问我问题我应该认真回答而不是继续编故事”。SFT相当于给模型做了行为示范看到指令停止发散按格式输出。因为预训练已经给了它足够的语言能力和知识储备SFT只需要“拨动开关”把回答模式从续写切换到指令跟随。这也是为什么SFT数据不需要海量但必须高质量、格式统一、覆盖充分。理解了这一点就不会盲目堆数据量了。2. SFT数据工程成败的关键不在模型而在数据2.1 数据长什么样三种主流格式必须掌握SFT数据的组织方式目前大体上有三种主流格式。第一种是“instruction/input/output”三段式适合任务型微调一条样本就是一个独立问题可以附带输入内容。第二种是messages对话格式按角色区分user和assistant消息适合训练多轮对话能力。第三种是ShareGPT风格用conversations数组保存完整对话历史很多开源训练框架默认用这种格式。我在实际项目中习惯把数据统一转成对话格式因为即便单轮任务也可以看成一轮对话。统一格式的好处是方便后续增加多轮样本模型在推理时也容易保持上下文连贯。这里有个新手经常踩的坑不同格式混在一起喂给模型模型会学到混乱的交互预期。今天学的是“首轮直接答”明天学的是“设身处地寒暄两句”最后表现就是时灵时不灵。举个例子一条标准的对话格式样本大概长这样{ conversations: [ {role: system, content: 你是一个专业的Python开发助手。}, {role: user, content: 写一个函数输入一个整数列表返回所有偶数的平方。要求用列表推导式。}, {role: assistant, content: python\ndef square_evens(nums):\n return [x*x for x in nums if x % 2 0]\n\n\n这个实现用列表推导式一次完成过滤和映射两个操作时间复杂度为O(n)。} ] }这个格式里system字段很重要它定义了模型的人设和行为约束。很多项目为了省事不写system模型也能跑但泛化性和稳定性会差很多。我通常会让每条样本都带system并且准备一个默认的system兜底避免推理时传空值导致模板错乱。2.2 数据从哪来开源数据集、日志清洗与模型构造SFT数据来源大致有三条路。第一条是直接用社区已有的开源SFT数据集适合快速验证流程。但这类数据集往往质量参差不齐可能有回答错误、格式混乱、重复过高等问题直接拿来训练模型很容易学到脏模式。第二条是从自己业务里捞真实数据这是最推荐的方式。比如你做客服机器人就把历史工单里优质的“用户问题-客服回答”对挑出来清洗。真实业务数据与目标场景高度匹配微调效果通常是最好的。第三条是用强模型构造数据思路是用能力更强的模型批量生成问答对再人工或者自动筛选。这种方式能快速扩充数据规模但有个隐患强模型自己可能也会犯错错误会原样传给学生模型。我见过有团队用这种方式一天造了几万条数据训完模型回答流畅但事实错误率很高最后排查才发现数据源头就错了。所以用强模型造数据抽样审核环节必须跟上。还有一个值得注意的点数据构造时要考虑分布。如果你做的助手要覆盖技术问答、闲聊、拒答三类场景数据比例就要和实际使用场景接近。我见过有项目把闲聊数据堆到80%结果模型变得很油滑正事不爱干了。数据分布偏了就改不回来重训成本非常昂贵。2.3 清洗与质量控制这些细节决定微调上限数据清洗是SFT里最枯燥但最重要的一环。我一般按下面的顺序处理先做全局去重重复样本会让模型对特定句式过拟合训练时看起来loss很低实际泛化很差。然后做长度过滤过短的样本没有学习价值过长的样本会拖慢训练还要处理超过max length的截断问题。接着做格式标准化统一标点符号、统一换行、统一代码块的标记语言让模型学到干净的模式。更关键的是内容校验。如果数据里有明显的错误答案模型会当作正确答案来学。这块我建议人力抽检加规则过滤双管齐下。比如代码类数据可以尝试直接执行样本来验证正确性知识类数据可以用关键词匹配或交叉验证来做粗筛。用脚本删掉明显答非所问的样本比多训几百条数据有用得多。另外提醒一下编码问题中文数据最容易在清洗时踩这个坑。统一转成UTF-8去掉不可见字符和乱七八糟的空格检查有没有打断JSON解析的转义符。这些小事在几百条数据时看不出问题数据量到几万条时任何一个脏字符都可能让训练中断或者模型输出乱码。2.4 用多少数据最合适不是多多益善SFT数据量没有一个固定标准但可以给一个经验区间场景单一的任务型微调几千条高质量样本就够通用助手的对话能力微调一到三万条比较合适再往上增加数据收益会明显递减。原因前面说过SFT主要是行为对齐模型不需要通过SFT学海量新知识它只需要足够多的示范来理解你的指令格式和输出偏好。我实操下来的体会是数据质量每提升一档对最终效果的影响远大于数据量翻倍。同样一万条数据粗洗和精洗之后的模型效果完全不是一个级别。宁可只有五千条高质量数据也别硬凑两万条垃圾数据。额外的数据有时反而会引入噪声让模型在部分场景下的表现倒退。还有一个容易被忽略的事情验证集的划分。SFT不是用完全部数据就万事大吉要留出一部分样本做验证。我在每次训练前都固定切出5%-10%的数据做验证集训练过程中持续观察验证集loss。如果训练集loss在降验证集loss在涨那就说明过拟合了及时停掉可以省下大量时间。3. 训练配置与超参数把SFT跑稳的核心3.1 全参微调还是LoRA看条件选方案SFT的实现方式主要分成全参微调和参数高效微调两大类LoRA是后者的典型代表。全参微调是让基座模型的全部参数都参与更新效果上限最高但显存和算力要求也最狠。以7B模型为例全参微调用AdamW优化器动辄需要60GB以上的显存单张消费级显卡基本做不了。LoRA则是冻结原始权重只训练注入的低秩矩阵显存占用大幅下降7B模型的LoRA训练在24GB显存下就能跑起来。从效果角度说如果数据量足够大、任务足够复杂全参微调确实能学到更多细微变化。但对于大多数业务场景LoRA的效果已经非常接近全参微调而且资源消耗少一个量级。我个人的选择标准是24GB以下显存无脑用LoRA能上全参微调的资源优先把多余算力投给数据清洗和评估而不是一味追求全参更新。LoRA还有一个额外优势就是多个adapter可以共用一个基座模型不同任务切换非常方便。不过LoRA有个小坑如果基座模型本身难以通过低秩更新达到理想效果比如领域知识严重不足LoRA的表现就会比全参微调差一截。这种情况你得先评估是“不会听指令”还是“不懂这个领域”前者LoRA能解决后者可能需要考虑增量预训练或者换更强的基座。3.2 关键超参数选择与背后的逻辑SFT常用的超参数并不复杂但每个参数的取值范围和背后逻辑一定要清楚。学习率是第一个要小心设置的参数。全参微调一般用1e-5到2e-5LoRA则可以用到1e-4到2e-4。因为LoRA只更新很少的参数学习率可以步子大一点。如果学习率设得太高模型会快速忘掉预训练学到的知识表现出来就是loss降低很快但输出开始胡言乱语。训练轮数同样需要克制。高质量SFT数据集2到4个epoch是比较稳的范围。数据量很大时甚至1个epoch就够了。这里有个常见的认知误区多训几轮不一定是好事。模型反复看过同一批样本后会对训练集的表达方式过度拟合导致泛化能力下降。我在训练时会同时盯着训练loss和验证loss一旦验证loss开始回升就立即停止通常能比固定epoch训练得到更好的结果。批大小和梯度累积对SFT也很关键。因为显存限制单卡一般只能放很小batch但batch太小会导致梯度噪声大、训练不稳定。解决办法是设置一个较小的per_device_batch_size然后用梯度累积凑到等效batch size。比如per_device_batch_size1gradient_accumulation_steps16等效batch size就是16。我习惯把等效batch size控制在32到64之间既稳定又不会太慢。权重衰减一般设为0.01warmup ratio设0.03左右这些是经验值大多数场景直接照用不会出错。学习率调度器推荐cosine它在训练末期能把学习率平滑降到很低有助于收敛到更好的局部最优。3.3 LoRA的rank、alpha和target_modules怎么定LoRA的rank是低秩矩阵的维度直接影响可训练参数量和表达能力。常见的实践值是8、16、32。rank太小模型学不到足够复杂的映射rank太大训练参数变多但收益不一定成比例提升。我通常先用16跑一个小实验观察效果后再决定要不要加大。alpha是缩放系数一般设置为rank的两倍比如rank16时alpha32。这个比例在大多数情况下表现良好。target_modules的选择是个容易被忽视的细节。在Transformer结构里LoRA可以注入到自注意力层的q/k/v/o投影矩阵也可以注入到前馈网络的gate/up/down投影。我测试下来同时注入注意力模块和前馈模块效果比只注入注意力要好尤其在做中文指令跟随任务时。原因是前馈网络承担了大量知识记忆的功能通过低秩更新微调这部分能让模型更快适应训练数据里出现的表达习惯。还有两个细节值得提。第一bias参数通常设成not update保持和基座模型一致减少训练参数总量。第二lora_dropout建议设置0.05到0.1防止过拟合但如果验证集表现正常dropout设小一点也能提升收敛速度这个可以微调。3.4 显存与训练稳定性配置跑SFT之前先想清楚两个问题用不用梯度检查点用不用混合精度。梯度检查点是个显存换速度的手段开启后显存占用可以降低大约30%-40%代价是训练速度变慢。对7B模型加LoRA的场景我建议开启它因为显存往往比时间更紧张。混合精度方面英伟达较新的卡建议直接用bf16它的动态范围和稳定性都优于fp16不容易出现loss溢出为NaN的问题。老显卡只支持fp16时记得加上loss scale策略并持续监控训练日志。序列长度max seq length是另一个需要仔细权衡的配置。它决定模型能看到多长的上下文。设得太短长对话会被截断模型学不到完整的依赖关系设得太长显存占用随长度线性增长训练速度也会下降。我建议先统计一下训练数据中最长的样本长度然后设定为覆盖80%-90%样本的长度值剩下的长样本做截断处理这样性价比最高。还有两个工程层面的配置容易出问题。一个是保存间隔建议同时按“步数”和“时间”两个维度设置长时间训练时至少每小时能看到一个可用的checkpoint避免意外中断后白白浪费时间。另一个是日志打印频率打开日志打印每10步打一次loss监控文本生成。因为有时候loss很漂亮实际生成的文本已经完全崩坏只看数字发现不了问题。4. 完整实操从原始问答到微调上线4.1 环境准备与最低硬件要求实操第一步是准备环境。我的建议是先建一个独立的Python环境避免依赖冲突。核心依赖就是深度学习框架、模型加载库、数据集库和LoRA库这几样就能跑通整个流程。GPU方面如果你想微调7B量级的开源基座模型24GB显存是甜点位用LoRA加梯度检查点可以比较舒服地跑起来。如果显存只有16GB可以通过4bit量化加载基座模型仍然能完成LoRA训练只是量化后训练精度略有损失。这里有个建议第一次跑通全流程时不要直接上大模型。先用几亿参数量级的小模型跑通数据加载、训练、保存、推理的闭环再换成目标模型。小模型调试成本低跑完一个epoch只需几分钟任何代码问题都能快速暴露。我每次接到新任务都先用小模型验证数据和代码确认无误后再换大模型训练这套流程帮我省下了大量调试时间。基座模型选择的核心原则是中英文、代码、数学能力匹配你的目标场景且尽量选择指令跟随能力已经不错的版本。如果底子太差SFT要补的课太多效果必然受限。4.2 数据格式转换脚本不管原始数据是Excel、JSON还是数据库导出的CSV第一步都要统一转成训练框架能读入的格式。下面这个脚本可以把简单的“问题-答案”列表转成对话格式的JSONL文件import json # 原始数据假设每条是 {question: ..., answer: ...} raw_data [ { question: 什么是列表推导式, answer: 列表推导式是Python中一种简洁地创建列表的语法格式为 [表达式 for 元素 in 可迭代对象 if 条件]。 }, # 更多样本... ] SYSTEM_PROMPT 你是一个专业的中文技术助手请用简洁准确的语言回答用户的问题。 def convert_to_sharegpt(item): return { conversations: [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: item[question]}, {role: assistant, content: item[answer]}, ] } with open(sft_train.jsonl, w, encodingutf-8) as f: for item in raw_data: f.write(json.dumps(convert_to_sharegpt(item), ensure_asciiFalse) \n) print(f转换完成共 {len(raw_data)} 条样本)转换脚本的核心逻辑就是把每条样本包成system、user、assistant三段。有人问system每次都要写吗我的建议是默认都写哪怕内容一样。这样模型在训练中会稳定学习到“先读人设再看问题”的行为模式。另外写入文件时一定加ensure_asciiFalse否则中文会被转成\uXXXX的Unicode转义序列可读性极差后续检查数据非常痛苦。4.3 训练脚本与关键配置数据准备好之后训练脚本的核心部分如下。这个脚本以加载基座模型为基础套上LoRA配置然后通过训练参数控制训练过程from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments, Trainer from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from datasets import load_dataset # 1. 加载基座模型和tokenizer # base_model_path 换成你手中的基座模型路径 model AutoModelForCausalLM.from_pretrained( base_model_path, torch_dtypebf16, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(base_model_path) # 2. 设置pad token。如果tokenizer没有pad token用eos代替 if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token model.config.pad_token_id tokenizer.eos_token_id # 3. 配置LoRA lora_config LoraConfig( r16, lora_alpha32, target_modules[ q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj, ], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config) model.print_trainable_parameters() # 打印可训练参数量 # 4. 定义训练参数 training_args TrainingArguments( output_dir./sft_checkpoints, per_device_train_batch_size1, gradient_accumulation_steps16, learning_rate1e-4, num_train_epochs3, logging_steps10, save_steps200, save_total_limit3, bf16True, gradient_checkpointingTrue, optimadamw_torch, lr_scheduler_typecosine, warmup_ratio0.03, weight_decay0.01, report_tonone, ) # 5. 加载数据集并按模板格式处理 dataset load_dataset(json, data_filessft_train.jsonl, splittrain) def format_chat(example): # 把conversations拼成模型需要的模板文本 # 这里用简单的拼接方式实际项目中建议使用tokenizer.apply_chat_template messages example[conversations] text for msg in messages: role msg[role] content msg[content] if role system: text f系统{content}\n elif role user: text f用户{content}\n else: text f助手{content}\n text 助手 return {text: text} tokenized_dataset dataset.map( lambda x: tokenizer( format_chat(x)[text], truncationTrue, max_length2048, paddingFalse, ), remove_columnsdataset.column_names, ) # 6. 创建Trainer并开始训练 trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_dataset, tokenizertokenizer, ) trainer.train()这套配置有几个数值值得解释一下。per_device_train_batch_size1配gradient_accumulation_steps16的组合是为了在24GB显存下跑7B模型的同时保持batch size不至过小。学习率1e-4是LoRA的常见起点如果你发现训练早期loss出现明显波动可以降到5e-5继续试。max_length设2048是因为大多数SFT样本并不需要那么长的上下文这个长度在显存和表达能力之间比较均衡。另外训练时打印可训练参数量是一个好习惯。一个7B模型的LoRA训练可训练参数通常只在几千万到一亿左右占比不到2%。看到这个数字你就明白为什么LoRA这么快了。4.4 推理验证与adapter合并训练完成后LoRA的权重是单独保存的并不会直接写回基座模型。推理之前需要先加载adapter验证效果。加载方式有两种一种是直接生成适合快速验证另一种是把adapter合并回基座模型生成一个新模型适合部署上线。from peft import PeftModel # 加载基座模型 base_model AutoModelForCausalLM.from_pretrained( base_model_path, torch_dtypebf16, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(base_model_path) if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token # 加载训练好的LoRA adapter model PeftModel.from_pretrained(base_model, ./sft_checkpoints/checkpoint-600) model.eval() # 合并adapter到基座模型部署时推荐 merged_model model.merge_and_unload() merged_model.save_pretrained(merged_model) tokenizer.save_pretrained(merged_model)合并这一步值得多说两点。第一合并后的模型体积和基座模型一样大但推理时不再需要额外的adapter管理可以直接用常规方式加载和部署。如果你用的是vLLM这类推理框架合并后的模型兼容性更好。第二合并操作会修改全部权重所以合并前一定要把原始基座模型备份好。有一次我误操作直接覆盖了原始权重只能重新下载模型那个下载时间足够写一篇新博客了。验证模型效果时我建议同时准备三组测试用例第一组是训练数据里没见过的类似题目看模型泛化能力第二组是训练数据里出现过的原题看模型记住了没有第三组是稍微挑战指令格式的用例比如要求它用表格输出、用特定语气回答看它是不是真的理解了指令跟随。5. 常见问题与排查技巧实录5.1 Loss降了模型反而变傻了这个现象出现过太多次了。训练日志上loss一路下降看起来非常健康结果拿出去一测模型回答质量反而比微调前更差。遇到这种情况第一个怀疑对象就是数据质量。SFT模型会把训练数据中的错误、噪声和格式混乱原样学进去。如果loss降得很快说明模型记性好把脏数据也记住了。第二个怀疑对象是数据分布。比如训练数据里80%都是“知识问答”20%是“代码生成”模型自然会偏向知识问答的输出风格代码能力反而不升反降。检查一下训练数据的类别占比把比例往目标场景调整往往是这一类问题最简单的解决办法。第三个原因可能是验证集划分不合适。如果你留出的验证集和训练集高度相似验证loss会一直很乐观等到真正上线面对新数据时才暴露问题。我建议验证集尽量和线上场景保持一致而不是随机抽样。5.2 灾难性遗忘怎么控制灾难性遗忘是SFT最头疼的问题之一表现是微调后模型对目标场景表现很好但通用能力明显倒退比如数学变差、常识错误增多。根本原因在于SFT训练数据分布和预训练数据分布差距太大模型在拟合训练数据的过程中把原有的知识表达式覆盖掉了。控制遗忘的方法有几个第一个是降低学习率。学习率越高权重改动幅度越大遗忘越严重。我遇到过把学习率从1e-4降到5e-5之后目标任务效果只差一点点但通用能力明显变好。第二个方法是混合通用数据。在目标SFT数据里掺入10%-20%的通用指令数据或者预训练语料让模型在原分布附近“巩固记忆”。第三个方法是做多任务混合训练。把多个场景的数据混在一起训而不是只训一个单独任务模型对指令的理解会更稳健。如果你已经训练完了发现模型通用能力受损还有一个补救手段用低学习率在通用数据上做几轮“恢复训练”通常能让通用能力回来一部分但要谨慎控制轮数恢复过头了目标任务的收益又会丢掉。5.3 输出成了复读机或者出现乱码生成阶段出现复读机很多人第一反应是调采样参数比如降低temperature、调整repetition penalty但从SFT侧来看根因常常在训练阶段。学习率过高是常见元凶模型在训练集上过拟合生成的token序列容易掉进重复循环。把学习率降下来重新训练复读现象经常自动消失。数据里的重复样本也值得排查。如果某条样本在数据集中重复了几十次模型对它的记忆特别深输出时就容易反复横跳。用去重脚本把完全重复和近似重复的样本清理掉能有效缓解这个问题。至于乱码问题优先检查tokenizer的pad token设置。很多基座模型的tokenizer没有pad token训练时如果不指定系统会拿eos token来凑可能导致注意力掩码错乱。另一个检查点是数据文本本身确认没有混入非法字符或者编码不一致的文本。5.4 显存OOM的排查路线训练中途报CUDA out of memory是最常见的工程问题但解决办法并不复杂按顺序处理就好。先减per_device_batch_size从4减到2再减到1。如果batch1还是OOM说明单条样本太大检查max_length是不是设得过高适当截断长样本。接着开启gradient_checkpointing这个能省不少显存。还不行就考虑换LoRA或者上量化。从全参微调切到LoRA显存占用能下降一半以上LoRA再加4bit量化加载7B模型的训练甚至可以压到16GB显存以内。有一点要提醒batch变小后训练稳定性会变差记得同步调大gradient_accumulation_steps把等效batch size维持住。用大batch换稳定用累积换等效是解决显存问题的通用思路。5.5 微调效果怎么评估才靠谱很多团队评估SFT效果只看训练loss这是远远不够的。loss只能说明模型有没有拟合训练数据不能说明模型能不能解决真实问题。我自己的评估体系分三层第一层是规则指标如果任务是分类或者抽取计算准确率、F1这些客观指标第二层是生成质量指标比如代码任务的passk、文本摘要的ROUGE分但这些只能做参考不能完全替代人工第三层是人工评测准备几十条覆盖各场景的测试用例逐个看模型输出按有用性、正确性、格式规范度打分。人工评测虽然费时但它最能暴露问题。我通常会让不直接参与训练的人来做评测这样能避免“自己训的模型怎么看都好”的主观偏差。打分表也不要搞得太复杂三到五个维度足够了重点看有没有出现答非所问、格式混乱、事实错误这三类致命问题。模型上线前至少做两轮评估第一轮发现问题并重训第二轮确认修复效果这样形成闭环才算真正跑完一次SFT。最后说一个我个人的习惯每次SFT训练跑完之后把所有配置、数据统计结果和评测记录整理成一个简单的文档留档。别小看这一步模型效果不好时想回溯原因这份记录能帮你快速定位是数据问题、参数问题还是训练代码问题。我做过的项目里好几轮模型效果倒退都是靠文档记录快速查出了原因。如果你正准备开始自己的SFT实验建议也养成这个习惯。
