先说点实在的，今年6月这份《LLM Post-Training Handbook》出的时候，我刚把一个基座模型从"知识渊博但答非所问"调教到"能老老实实按JSON输出"的阶段。回头看整个流程，最深的感触是：后训练（Post-Training）从来不是某一个算法的胜利，而是一整套工程细节的叠加。这篇东西我不会复述手册原文，而是把里面涉及的核心原理、我在实操中验证过的方法论、以及那些文档里不会写的坑，用大白话重新捋一遍。适合正在准备自己动手微调和对齐模型的算法工程师、负责模型落地评估的技术负责人，以及想搞清楚"模型是怎么从预训练变成真正好用"的进阶开发者。
1. 先把「后训练」这件事看明白：它在整个LLM流程中的位置
1.1 预训练给了模型"知识"，但没有给"教养"
预训练的任务极其纯粹：给定前文预测下一个token。模型在数万亿token上反复做这件事，学到的是语言中的统计规律、世界知识、推理链路的雏形。你可以把预训练后的基座模型理解成一个"知识渊博但完全不懂社交礼仪的天才"：你问它一个问题，它可能能答出很多相关的知识，但输出格式可能是"根据马尔可夫链推断，下一个最可能的字符是..."，完全不是人话；你让它按要求输出JSON，它可能给你一大段散文；你问它安全敏感问题，它可能毫不设防地给出答案。
这不是模型傻，而是它的训练目标和"人类使用模型"的目标根本不一致。预训练有唯一的正确答案（下一个token），而后训练要解决的是"如何让模型的行为符合用户意图"这个开放的、多目标的优化问题。所以后训练不是锦上添花，它是把"模型能力"转化为"产品价值"的必经桥梁。很多人拿到基座模型后第一反应是"这模型怎么这么难用"，其实不是模型差，而是它还没有经过"社会规训"，不知道怎么当助手。
1.2 2025年后训练的全貌：不止是SFT加RLHF
手册把后训练拆成三条主线，这个拆法非常关键，因为很多团队把这三件事混为一谈，最后模型就变成了四不像：
- 指令跟随（Instruct Alignment）：让模型学会"听指令"，包括理解任务意图、按要求格式输出、多轮对话的上下文管理等，主力手段是SFT。
- 偏好对齐（Preference Alignment）：让模型的回答风格、价值观、安全边界贴近人类偏好，主力手段包括RLHF（PPO）、DPO及其变体、GRPO等。
- 能力增强（Capability Enhancement）：包括工具调用、长上下文行为、多模态对齐、推理链路强化等，通常通过专门的数据构建和训练方式来激活或加强。
三条线的数据构建方法、训练目标、评估方式完全不同，混淆它们正是很多后训练项目失败的最主要原因。举个例子，你把偏好对齐的海量对比数据直接拿去做SFT阶段的训练，模型大概率会"精神分裂"；反过来，想靠SFT数据解决安全拒答问题，效果也非常有限。2025年的另一大趋势是合成数据占比持续攀升，以及"评估驱动训练"——不是训完了再想怎么评估，而是先设计好评估集，再倒推数据怎么造、训练怎么调。
1.3 这本手册的核心命题：用有限资源做高质量后训练
很多人以为后训练的瓶颈是算法，实际做下来你会发现，瓶颈永远是资源约束下的"投入产出比"。这份2025年6月版手册最核心的命题就是：当你拿到一个新的基座模型（无论开源权重还是API底座），如何在有限的GPU预算、有限的数据团队人力、有限的时间窗口内，把它调教成一个在目标场景中表现可靠的模型。
它给出一条主路线图，看起来平淡无奇，但每一步都有大量细节决定成败：
- 评估基线，明确差距在哪；
- 构建高质量数据（SFT数据和偏好数据）；
- 分阶段训练（SFT → 偏好对齐）；
- 多维度评估；
- 根据评估结果决定是否迭代。
下面我把这些步骤逐一展开，重点讲手册里的方法论和我自己实践后的补充。
2. 数据：后训练中最该花时间的地方
2.1 数据质量阈值比数据量更重要
我见过太多团队一上来就海量收集数据，觉得"多总比少好"。但后训练和预训练的数据逻辑截然不同：预训练可以容忍海量低质冗余数据，因为模型只是在学分布；后训练数据里的每一个样本，都是"手把手教模型应该输出什么"的示范，错误样本带来的伤害是直接且难以修复的。
为什么？因为预训练的目标是"预测下一个token"，模型可以从错误样本中忽略噪声信号；但SFT的目标是"模仿示范"，模型会把错误样本中的错误模式当作"正确行为"直接学到权重里。一个包含逻辑硬伤的"参考答案"，会让模型在遇到同类问题时产生系统性幻觉。
手册里给出的质量门槛看三个维度：
- 指令覆盖度：你的任务类型是否覆盖了目标场景的绝大多数需求
- 输出正确性：参考答案本身是否包含错误信息或逻辑硬伤
- 格式规范性：指令模板是否统一、解析是否可靠
我自己的补充：一个1000条的高质量SFT数据，效果往往好过10000条从网上爬来的"看起来像对话"的数据。质量判断不能靠肉眼，建议每条数据的"答案"都要通过基线模型的自动打分或人工抽检。我习惯的做法是：先随机抽50条让团队标注质量，如果这50条里质量问题超过5%，整批数据就要回炉重造。
2.2 合成数据的分寸：2025年绕不开的原料
到了2025年，后训练数据完全靠人工标注已经不现实，合成数据是默认操作。怎么合成、合成多少、如何防塌缩，是经验密集区。
合成数据的三种常见路径：
- 强模型蒸馏：自己收集一批高质量问题，让另一个能力更强的模型写答案；或者反过来，根据少量种子样本让模型生成类似风格的新样本。这种路径效率最高，但风险是"风格同质化"。
- 多轮对话扩写：把单轮问答扩写成多轮对话，用于训练对话模型。核心难点是对话的自然转折和上下文记忆的一致性。
- 偏好对合成：用同一问题让模型生成多个回答，再用强模型排序，得到偏好对齐训练需要的对比数据。
直接操作时最典型的坑是模型塌缩：如果合成数据过于依赖单一模型的风格和内容偏好，模型会丢失多样性，甚至把强模型的bad case当成"正确答案"学习。手册里的建议是把蒸馏数据控制在数据集总量的30%-50%，并且每轮迭代时加入20%左右的人写或人改数据，保证"血液"新鲜。我在实践中发现，如果用合成数据做DPO偏好对，一定要在偏好对里混入一些"两个回答都不完美"的样本——真实应用里大量问题本身没有完美答案，模型只有见过"不完美中的选择"，才不会在线上表现得太机械。
2.3 数据配比与去重：被低估的胜负手
数据配比影响任务均衡性。一个常见的失误是：把公开SFT数据集直接拿来训练，结果里面数学题占比奇高，或者翻译任务占比奇高，导致模型在目标场景上表现失衡。
配比的计算不复杂，关键是先定目标场景的任务分布。举个例子，假设你做一个客服助手，任务分解后可能是：意图分类15%、FAQ回答40%、多轮对话30%、内容生成15%，那么SFT数据就应该按这个比例分配。如果实际收集到的数据里FAQ只有20%，多轮对话却有50%，每轮训练前就要做欠采样或过采样，把比例拉回目标值。
配比数据的过程我建议用数据清单表格管理：每次记录任务类型、来源、占比、平均长度、质量评分。出问题时能快速回溯是哪个类别的数据出了问题。举个例子，如果模型对多轮对话的"指代消解"能力变差，你可以直接看多轮对话类数据的平均质量和占比，而不是把整个数据集重新翻一遍。
去重是另一个被严重低估的环节。大量语义重复的训练样本会让模型对高频样本过度学习，典型症状是：模型对某些表达方式的复现率极高，但缺乏泛化。工程上去重常用的方法：
- Embedding聚类：按向量余弦相似度分组，组内只保留代表性样本。我一般用通用的文本Embedding模型，相似度阈值设在0.85左右，超过就归为近似重复。
- MinHash：适合大规模精确去重，速度快，但只能处理"几乎一样"的样本，语义改写后的重复检测不到。
- 最笨但有效的方法：人工抽查"几乎一样但实体不同"的模板样本，这种数据在从公开数据集拼接时特别多。
3. 核心训练阶段一：指令微调（SFT）的精细化操作
3.1 SFT的关键超参数：火候全靠经验
SFT训练目标简单：还是next token prediction，但只在训练集的"答案部分"计算loss，指令部分的loss通常会mask掉。训练时模型根据"用户指令 + 标准答案"学习以最大似然拟合。目标简单，但火候控制全靠经验。
学习率：全参微调常用2e-5到1e-5，LoRA常用1e-4到3e-4。学习率偏大的直接后果是灾难性遗忘严重，模型原有的通用能力大幅下降；学习率偏小的后果是训练不充分，指令跟随能力提升不明显。判断标准就看两条：训练loss是否在合理下降，以及验证集上的指令跟随率是否同步上升。
Epoch数：1-3轮。SFT数据量小（往往是万级到十万级），训练epoch如果超过3轮，过拟合会非常严重。典型症状是：训练集上指标很高，但是新任务泛化能力下降，甚至开始幻觉泛滥。我见过一个案例，团队把SFT跑满5轮后模型把训练集里的实体名背得滚瓜烂熟，问什么都能扯到这个实体上。
Batch size和梯度累积：全参微调通常会追求比较大的"有效batch size"，LoRA因为参数量小，对batch size没那么敏感。一个经验公式：
有效batch size = batch size × 梯度累积步数 当有效batch size从16增大到64，学习率可以相应地从2e-5调到5e-5；增大有效batch size通常带来更稳定的训练曲线，但也不是越大越好——超过128以后收益递减，还可能引入隐性的收敛变慢。
另外，SFT阶段我强烈建议开启"对话模板一致性检查"：训练数据里的每一条，模板格式必须完全统一。最好用同一套tokenize函数把所有样本转成统一的"系统提示 + 多轮对话 + 最终答案"结构，不要在数据里手动留不同的分隔符。格式崩溃这个问题在训练时不明显，一旦上线部署，模型的输出解析器会直接挂掉。
3.2 全参微调 vs. LoRA：决策不是靠玄学
全参数微调和LoRA是两条路线，各有适用场景。全参微调的优势在于对模型能力的塑造能力最强，尤其是需要在模型里学习"新的行为模式"（比如学会工具调用协议、学会输出某种特定结构化格式）时，LoRA往往学不够深。缺点是真贵。
算一笔账：对一个7B模型做全参微调，用bf16精度，显存需求大约是：
- 模型权重：14GB
- 梯度：14GB
- 优化器状态（Adam）：28GB
- 激活值：视序列长度和batch size而定，通常8-16GB
- 总计：约64-72GB
也就是说，单张80GB的GPU勉强能跑，但没有任何冗余，实际建议至少4张80GB卡做分布式训练。
LoRA的优势则是低成本、低遗忘风险、快速迭代。一张24GB的消费级显卡就能跑7B模型的LoRA微调。但LoRA的分寸很难拿捏：
- rank取多大：常见8-64。对小数据小任务是8-16足够，对复杂行为学习建议32-64。rank太小表达力不足，rank太大训练变慢且未必更好。
- 加在哪些模块：一般加在attention的q、k、v、o；如果想加强FFN层的信息变换，也可以加在gate、up、down上。不同模块组合的效果差异很大，建议做一次小范围消融实验再定。
- 如果LoRA效果不稳定，先把"模块选择"和"rank"固定下来，只调学习率。
决策建议：数据量少于2万条、目标行为变化不大、需要频繁迭代的场景，优先LoRA；数据量超过5万条、希望真正改变模型行为模式的，直接上全参微调。不要把LoRA当万能药，它的下限低，但上限也被表达力限制住了。
3.3 SFT常见的翻车点：能防就防
SFT阶段最常见的翻车点，我列几个高频的：
- 格式崩溃：训练数据的对话模板不统一，比如有的样本用"Human:"开头，有的用"User:"开头，模型输出时就会混着来。在推理部署时就是灾难。
- 指令遗忘：模型在训练到后半段对高频指令响应很好，但遇到低频指令就退化。原因往往是低频指令的样本量太少，被高频数据稀释了。
- 幻觉加深：如果训练数据里存在错误答案或"明明没有的信息"但模型强行补充，SFT实际上在教模型"一本正经地胡说八道"。这个比幻觉本身更麻烦，因为它是被"正确答案"教出来的。
- 过拟合成性：模型背下了训练集里的标准答案，而不是学会解题思路。判断方法：把题目里的实体换成全新实体（人名、地名、数字），如果模型答错，就是背题了。
在这一段我就一个建议最实用：SFT数据里凡是答案超过300 token的长输出，务必人工抽样审视一遍，因为长输出中藏bad case的概率远高于短输出。
4. 核心训练阶段二：偏好对齐（RLHF及其替代方案）实操指南
4.1 从RLHF说起：PPO的四个"角色"
偏好对齐的目标是让模型的回答风格和价值观贴近人类偏好。经典实现是RLHF配合PPO训练，它涉及四个角色：
- Actor：被训练的模型，负责生成回答
- Reference：冻结的SFT模型，作为参照计算KL散度，防止Actor偏离太远
- Reward Model：给每个回答打分
- Critic：估计价值函数，帮助计算优势函数
每次训练迭代，Actor对prompt生成回答，Reward Model打分，Critic评估价值，最终用策略梯度更新Actor。这里有个工程上极其经典的问题：reward hacking——模型发现只要输出变长或者复述prompt里的关键词就能拿到高分，于是行为退化。应对手段是KL惩罚：在奖励里减去Actor与Reference的KL散度，惩罚偏离基线太远。
PPO训练还有几个只有踩过坑才知道的点：
- KL散度项权重如果过大，模型会被"拴"住，对齐效果微弱；权重过小，模型会跑飞。经验上先从一个中间值开始，观察训练过程中KL散度的趋势再调。
- Critic的价值初始化要基于SFT模型的预测，否则前几百步训练会剧烈波动。
- Reward Model要持续监控。如果Reward Model本身存在偏见（比如偏好长回答、偏好特定句式），整个模型都会被带偏。
所以，PPO最大的优点是对齐上限高，能优化任意可计算的奖励函数；最大的缺点是稳定性极差、工程成本高。2025年还能坚持用PPO的团队，通常是有成熟RL基础设施的大团队。
4.2 DPO：轻量级对齐的优雅解法
DPO是2023年提出的思路，2025年依然是很多场景的主力选择。它把RLHF的优化目标转化成了一个简单的偏好对比损失，不需要Reward Model，不需要在训练时反复采样，只需要静态的偏好对数据。
DPO的核心公式不好看，但思想很简单：如果用户更喜欢A回答而不是B回答，那训练时就提高A的概率、降低B的概率，同时用KL散度限制偏离SFT基线的程度。这个beta参数控制"对齐强度"：beta越大，模型越容易被偏好数据带动；beta越小，模型越保守，越靠近原SFT模型。实际操作中beta通常取0.1到0.5之间，先从小值开始，看评估结果再微调。
DPO最适合的场景：数据量中等（几千到几万偏好对）、不希望引入复杂RL训练流程、追求稳定可复现的对齐效果。最大的优点是训练时不需要采样，成本低，效果也比PPO更容易复现。
但DPO也有明确的边界：它无法优化需要"在线反馈"的目标，比如"代码能不能通过单测""搜索结果相关性如何"，这些必须要程序实时反馈的奖励信号，DPO没法处理。另外，偏好数据质量差时，DPO很容易学出"让模型说话更谄媚"的风格，而非真正提升能力。
实操中构造偏好对的重要心法：两个回答之间的差异应该足够大且清晰。如果A回答和B回答只有措辞上细微差别，模型学到的东西会很有限；最好在正确性、完整性、结构、风格等维度上有肉眼可见的优劣。一个合格的偏好对，正面回答应该"明显更好"而不是"略好"。
4.3 GRPO：2025年的"真香"选择
2025年，以大规模强化学习训练"深度思考型"模型是绝对热点。这套训练观的代表性算法是GRPO，它去掉Critic网络，通过组内相对优势来更新策略。简单解释：对同一问题让模型生成G个回答，根据奖励对这G个回答做内部比较，好回答的得分高于组内平均，差回答的得分低于组内平均，然后用这个相对优势做策略梯度更新。
GRPO带来的工程收益：少训练一个大型Critic网络，显存和训练复杂度大幅下降，而且它对奖励函数的要求是"可比较"而非"绝对准确"，这对很多评估场景更加友好。
选型建议：
- 目标是通用对话模型、以人类偏好为主，DPO最简单靠谱；
- 目标是推理型模型（数学、代码、逻辑任务），且有可编程的奖励函数（如答案正确性检查、单测通过率），GRPO几乎是必选；
- 场景需要在线交互反馈（比如工具调用结果反馈），GRPO也比离线DPO更能适应。
我自己做推理增强的体感：GRPO训练中最重要的是奖励函数设计，单有"正确性奖励"还不够。还要加"格式奖励"（比如必须输出思考过程和最终答案的标记）、"长度惩罚"（防止模型生成冗长但有效信息少的回答），不然模型会学会"讨巧"而不是"思考"。奖励函数里各项的权重，我通常是先跑一个1000步的小规模实验，看模型行为是否朝期望方向偏，再决定是否放大或收敛权重。
5. 训练后评估：没有评估就没有迭代
5.1 三层评估体系：别只盯着榜单分数
后训练最容易犯的评估错误是只看榜单分数。榜单分数高不一定代表产品体验好，原因在于公开benchmark存在数据污染、风格偏差等问题。更推荐的是一套三层评估体系：
- 第一层：固定基准集。用来横向对比模型能力基线，监控回归。比如数学、代码、知识问答等通用benchmark。
- 第二层：自定义场景评估集。从你的真实产品case中采样构建，分任务类型、难度、边界情况，用规则加模型打分，作为上线前的核心门槛。
- 第三层：人工盲测与线上A/B。真人给模型回答打分，和线上版本对比，决定是否发布。
没有第二层和第三层，只有第一层，几乎等于裸奔。榜单分数再高，也回答不了"这个模型在我们的客服场景里好不好用"这个问题。
5.2 评估指标的合理设计：把"好"拆成可打分的项
场景评估集的设计，核心是把"好"分解成可打分的小项。举一个客服助手场景的例子，每个回答可以打四个分：
- 正确性：答案事实是否正确（0/1）
- 完整性：是否覆盖用户问题的所有要点（0-2分）
- 格式合规：是否按要求格式输出（0/1）
- 安全合规：是否包含不当内容（0/1）
一个回答的"合格"可以定义为：正确性=1且格式合规=1且安全合规=1且完整性>=1。有了打分规则，才能把"这个模型变好了没有"变成可以监控的数字。
另一个常见的坑是"分数上升但产品体验变差"。我见过最典型的例子：模型在数学benchmark上疯狂涨分，但普通对话的语气变得僵硬、拒绝率上升。原因是训练时过度优化了数学数据，把"谨慎回答"的风格扩散到了所有任务上。对策：每次训练后，除了看目标任务的分数，还必须跑一遍"通用能力回归集"，里面至少包含50个跨领域的日常问题，避免偏科。
5.3 一次完整后训练的迭代Checklist
以一次SFT加DPO的典型迭代为例，完整流程应该是这样的：
- 样本基线取数：收集500个线上真实问题；
- 基线评估：对当前模型评估，记录各维度得分；
- 数据构建：按目标场景配比构建SFT数据（约1-3万条）和偏好对（约3000-5000对）；
- SFT训练：1-2 epoch，学习率2e-5到3e-5；
- SFT后评估：任务集从60分到80分，同时记录回归情况；
- DPO训练：beta取0.1-0.3，1 epoch；
- DPO后评估：任务集、回归集、安全集全部跑一遍；
- 人工盲测：20人每人50题，对比SFT版和DPO版；
- 上线前决策：达标即发，不达标回炉数据构造。
这个清单看起来繁琐，但每一步都省了后面更大的返工成本。我见过太多团队跳过第3步的人工抽检，结果模型训练完一周才发现数据里有系统性错误，白烧了几千美元的电费。
6. 资源调度与算力规划：把钱花在刀刃上
6.1 算力估算：从7B到70B
算力是很多团队后训练的硬约束。先给常规估算方法。
一个7B模型LoRA微调（rank=16，目标模块q/k/v/o），用单张24GB显卡：
- 模型权重约14GB（bf16），LoRA额外参数不到200MB；
- 激活内存取决于batch size和序列长度，通常小batch下2-4GB；
- 实际是能跑起来的，但batch size会很小（比如1-2），需要梯度累积。
一个7B模型全参微调，用4张80GB A100：
- 模型权重14GB，梯度14GB，优化器状态28GB，加上激活值，4卡并行勉强够用；
- 实际建议：数据量大、目标行为大改时才走全参。
70B模型的全参微调，没有几十张80GB显卡就别想了。现实中更常见的选择是：用多个LoRA或Q-LoRA在4-8张80GB卡上跑。
计算训练时间的快速公式：
- 每张A100大约每秒处理1000-2000个token（7B模型）；
- 训练总token数 = 样本总token数 × epoch数；
- 时间 = 总token数 ÷ 总吞吐。
举例：1万条平均长度500 token的数据，epoch=2，总token就是1千万。单卡吞吐按1500 token/s算，单卡时间约1.85小时，4卡并行约半小时左右。实际训练会因checkpoint保存、数据处理等增加开销，但量级在这里。
6.2 多节点训练与容错设计
超过10万条数据或超大模型，就需要分布式训练了。实操中几个必须注意的点：
- 检查点策略：每500-1000步保存一次，建议保留最近的3-5个checkpoint，不要只留最后一个。我就遇到过训练最后一步崩了，结果整个实验白跑的情况。
- 断点续训：保存好optimizer state、scheduler状态、random seed状态，只保存模型权重无法精确恢复训练状态。
- 梯度同步：使用ZeRO或FSDP时，小心通信瓶颈。减少通信的常见做法是用gradient checkpoint、混合精度训练（bf16/fp16）。
- 实验记录：用实验管理工具记录每个实验的loss、学习率、样本数、评估分数，这是后训练复现的基石。没有实验记录的后训练，等于在迷雾里走路。
6.3 那些"免费"的加速手段
- Flash Attention：大幅降低注意力训练显存、提升吞吐，在主流框架里基本是默认开启的选项。
- 梯度累积替代大batch：在显存不足时用小的batch size加大的梯度累积步数，用时间换显存。
- 混合精度：bf16是后训练中最常用的精度，稳定性和效果在大部分场景优于fp16。
- 数据预处理并行化：把tokenize和数据清洗做成pipeline，不要让它成为训练间隙的瓶颈。
- 模型并行策略：7B以下用数据并行就行，13B以上建议张量并行加数据并行混合。
7. 常见问题与排错实录
7.1 训练不收敛或loss爆炸
先按这个顺序排查，别瞎调参数：
- 确认学习率没打错。全参微调用1e-5仍然爆炸，把学习率降到5e-6试试。
- 检查数据是否有nan/inf，尤其是长输出样本可能引入非法字符。
- 检查混合精度设置。bf16在较新的GPU上稳定，在旧一些的架构上需要改为fp16并开启动态loss scaling。
- 检查loss是否在合理区间。SFT初始loss一般在2-3左右，如果初始就在10以上，大概率是模板拼接或tokenize错了，先修数据。
7.2 过拟合与灾难性遗忘
SFT和DPO训练都面临"老能力下降"的情况。止损策略：
- 在训练数据中混入10%-20%的通用语料（比如通用对话、逻辑问答），避免模型只记住新任务的一套模式。
- 用LoRA时可以调低rank并缩短epoch，减少对原模型的覆盖。
- 训练中保存多个checkpoint，选在"目标任务分数与通用能力分数交叉点"附近的checkpoint，而不是最后一个。
7.3 显存OOM
常规解法：
- 降低batch size，配合梯度累积；
- 开gradient checkpointing，大约省30%-50%显存；
- 序列过长时，限制或拆分长样本；
- 使用LoRA或Q-LoRA；
- 如果以上都解决不了，把训练序列长度缩短。SFT阶段的固定长度通常512-2048就够用，不必强行喂超长序列。
7.4 "对齐税"问题
对齐训练通常会带来一定程度的基础能力下降，行话叫"对齐税"。如果模型因为对齐而变笨，优先检查三点：
- 偏好数据是否过于严苛，模型被训得"过度谨慎不愿给答案"。如果你发现模型开始无理由拒绝回答一些正常问题，十有八九是这个原因。
- 把偏好数据中的"拒绝型样本"控制在合理比例（通常不超过10%-15%）。拒绝型样本是说那些教模型"不要回答"或"要谨慎回答"的样本，太多了模型就变得畏首畏尾。
- 考虑用能力保持损失：在DPO或GRPO的更新目标中加入对原始能力的正则项，限制对齐训练对模型参数的大幅扰动。
我自己在带团队做后训练的过程中，最大的一个体会是：数据、评估、对齐三者的时间分配比例应该是5:3:2，而不是把精力都砸在训练按钮上。数据是上限，评估是方向盘，训练只是执行。最后再分享一个小技巧：把每次训练的关键配置、数据清单和评估结果记录成一张实验卡，几轮迭代后回头看，这张卡能帮你省下大量重复踩坑的时间。如果你手上也有一份基座模型等着"打磨"，希望这份实操拆解能让你少走点弯路。
