企业官网建设流程全解析

1. 为什么2025年还需要一本“后训练手册”

如果你在过去一年里真正动手训过模型，大概率会有一种割裂感：预训练的门槛被开源社区拉得越来越低，几万块钱的算力就能跑出一个能说人话的基座，但真正决定这个模型能不能上线、能不能干活、能不能让业务方点头的，几乎全部落在“后训练”这一段。我见过太多团队，预训练阶段砸了大钱，结果卡在最后一步——模型输出格式不稳定、指令跟随时好时坏、稍微复杂一点的任务就开始胡编，最后项目延期甚至直接黄掉。

这就是我写这份《LLM Post-Training Handbook》的动机。它不是一篇论文综述，也不是某个框架的官方文档翻译，而是一份从一线踩坑里长出来的操作手册。核心关键词就几个：后训练、指令微调、偏好对齐、数据配比、评测闭环。它想解决的问题很具体——当你手里已经有一个还不错的基座模型，怎么用尽可能可控的成本，把它变成一个真正能交付的产品级模型。

适合谁看？三类人。第一类是做应用落地的工程师，你可能不训基座，但你必须懂后训练，否则你调不动模型；第二类是算法同学，你已经在跑SFT和偏好优化，但效果总是不稳定，想搞清楚每一步到底在发生什么；第三类是技术负责人，你需要判断一个后训练方案值不值得投人投卡。这篇手册会尽量把“为什么这么做”讲透，而不是只丢一堆超参让你抄。

需要先说明一点：后训练没有银弹。2025年的今天，工具链比两年前成熟太多，但成熟不等于简单。真正拉开差距的，是对数据、对目标函数、对评测这三件事的理解深度。下面我按实际项目推进的顺序，把整条链路拆开讲。

2. 后训练到底在训练什么：目标拆解与阶段划分

2.1 从“会说话”到“会办事”的三级跳

很多人把后训练等同于“跑一遍SFT”，这是最常见的认知偏差。我习惯把后训练拆成三个递进目标，每一级解决不同的问题，混在一起做往往两头不讨好。

第一级是格式与风格对齐。基座模型本质上是个“文本接龙机器”，它不知道什么叫“回答要分点”，也不知道“不要输出多余的解释”。这一级的核心是让模型学会人类期望的输出形态——该用JSON就用JSON，该简洁就简洁，该拒绝就拒绝。这一级用少量高质量数据就能见效，通常几千到几万条就够。

第二级是指令跟随与任务能力。模型要能理解复杂指令，比如“先总结这段文本，再翻译成英文，最后给出三个关键词”。这一级需要覆盖多样化的任务类型，数据量和多样性直接决定上限。很多团队卡在这里，因为他们的数据全是单一场景，模型在训练集上表现完美，换个任务就崩。

第三级是偏好与价值观对齐。模型不仅要“能做”，还要“做得让人满意”。同样一个回答，有的啰嗦有的精炼，有的安全有的越界，这一级就是通过偏好数据把模型往人类偏好的方向推。这一级最容易被低估，也最容易翻车，因为偏好是主观的，标注质量直接决定成败。

三级跳的顺序不能乱。我见过有人跳过第一级直接做偏好优化，结果模型学会了“讨好”但连基本格式都保不住，纯属浪费算力。

2.2 各阶段的算力与数据量级参考

为了让你有个直观预期，我把常见配置整理成表。注意这是经验区间，不是硬性标准，具体要看你基座的能力和任务复杂度。

这张表里最值得说的是最后一行。评测不是后训练结束后的验收，而是贯穿全程的“仪表盘”。我踩过最大的坑就是训完才评测，结果发现模型在某个关键任务上退化了，回头查数据发现是某批数据污染导致的，但已经浪费了一周算力。

2.3 一个容易被忽略的前提：基座选型决定后训练天花板

后训练再强，也救不了一个先天不足的基座。选基座时我会重点看三件事：基础指令跟随能力、上下文长度、以及tokenizer对目标语言的友好度。有些基座在英文上很强，但中文tokenizer效率极低，同样一段中文要消耗两倍token，后训练成本直接翻倍。

还有一个反直觉的经验：不要盲目追最新最大的基座。一个7B的基座如果预训练数据干净，后训练后的效果可能超过一个没调好的13B。我做过对比，在特定垂直任务上，精心后训练的小模型比通用大模型的表现更稳，推理成本还低一个数量级。选基座时先跑一轮零样本评测，看它在你的目标任务上的“原始手感”，手感太差的直接放弃。

3. 指令微调数据的构建：质量、配比与清洗

3.1 数据从哪来：三条主流路径的取舍

指令微调数据来源无非三条路：人工标注、模型合成、开源数据集复用。每条路都有坑，我逐个说。

人工标注质量最高，但成本也最高。我的经验是，人工数据不要追求量大，而要追求“种子”作用。通常我会让标注团队先产出500–1000条高质量种子数据，覆盖核心任务类型，然后用这些种子去引导模型合成更多数据。人工数据的价值在于“定义标准”，而不是“堆量”。

模型合成是2025年的主流做法，成本低、可扩展。但合成数据的最大风险是模式坍缩——模型合成出来的数据分布越来越窄，训出来的模型只会一种腔调。我的应对方法是多模型交叉合成：用A模型生成，用B模型改写，再用规则过滤，强制引入多样性。另外合成数据一定要做去重，我见过合成10万条结果去重后只剩2万条有效数据的案例。

开源数据集复用最省事，但最危险。很多公开数据集里混着低质、重复甚至有害内容，直接拿来训就是给自己埋雷。我的做法是：任何开源数据进训练集之前，必须过一遍质量分类器，把明显不合格的剔除，剩下的再人工抽检5%。

3.2 数据配比：不是越多越好，而是越均衡越好

数据配比是后训练里最玄学也最关键的环节。我总结了一个“三三制”原则供参考：三分之一通用指令、三分之一垂直任务、三分之一难例与边界case。

通用指令保证模型不丧失基础能力，垂直任务保证业务效果，难例和边界case保证模型在极端输入下不崩。很多团队只做中间那三分之一，结果模型在业务场景里表现不错，但用户随便问个无关问题就开始胡说。

配比还要动态调整。训练中期如果发现某类任务loss下降特别快，说明模型已经学会了，可以适当降低该类数据权重，把算力让给还没学会的任务。这个思路类似课程学习，但实现上不需要太复杂，按epoch调整采样权重即可。

3.3 数据清洗的五个必查项

清洗环节我列了一个检查清单，每次构建数据集都过一遍：

• 重复检测：不仅查完全重复，还要查语义重复。用embedding做相似度聚类，阈值设0.95以上，把近似重复的合并。
• 格式一致性：同一种任务的输出格式必须统一。我见过一个数据集里“总结”任务有的输出带标题有的不带，训出来的模型格式随机。
• 长度分布：检查输入输出长度分布，如果全是短样本，模型学不会长输出；如果全是长样本，推理时短问题也会啰嗦。
• 有害内容过滤：用分类器加关键词双重过滤，宁可错杀不可放过。
• 语言一致性：如果目标是中文模型，确保数据里中文占比足够，混入大量英文会让模型语言混乱。

提示：清洗不是一次性的，每次数据版本更新都要重新跑一遍。我习惯把清洗脚本固化下来，数据一更新就自动跑，避免人工遗漏。

4. 偏好优化：从RLHF到DPO的实战选择

4.1 为什么SFT之后还需要偏好优化

SFT教会模型“怎么做”，但没教会它“怎么做更好”。举个具体例子：用户问“推荐几本入门书”，SFT模型可能给出一个正确但冗长的回答，而偏好优化后的模型会知道用户想要的是简洁的列表而不是长篇大论。这种“度”的把握，SFT数据很难覆盖，因为SFT数据只告诉模型“正确答案是什么”，没告诉它“哪个答案更受欢迎”。

偏好优化的本质是给模型一个“排序信号”。你不需要告诉模型绝对正确答案，只需要告诉它A比B好，模型就能从大量相对比较中学会人类的偏好方向。这也是为什么偏好数据比SFT数据更容易获取——让人判断“哪个更好”比让人写出“标准答案”容易得多。

4.2 RLHF、DPO、KTO的适用场景对比

2025年主流的偏好优化方法就这几种，我按实际使用体验做个对比。

DPO是当前性价比最高的选择，它把偏好优化转化成一个类似分类的损失函数，不需要单独训奖励模型，训练稳定性也好很多。我实测下来，DPO在大多数任务上能达到PPO九成的效果，但调参难度和算力开销低一个档次。

KTO适合标注资源有限的场景，因为它只需要标注单条回答是“好”还是“坏”，不需要成对比较。如果你的标注团队只能做绝对评价做不了相对比较，KTO是更好的选择。

ORPO把SFT和偏好优化合并成一步，适合算力极度受限的情况，但效果上会有折损，我一般只在快速验证阶段用。

4.3 偏好数据的标注陷阱

偏好数据最大的坑是标注者偏差。如果所有标注者都是同一背景，模型就会偏向那一类人的偏好。我吃过一次亏：标注团队全是技术背景，结果模型对技术问题回答得很专业，但对普通用户的问题回答得过于技术化，业务方反馈“看不懂”。

解决办法是标注者多样化，并且定期做标注一致性检查。具体做法是让多个标注者对同一批样本独立标注，计算一致性系数，低于阈值的样本直接丢弃。另外要警惕“长度偏好”——标注者天然倾向于选更长的回答，但长不等于好。我会在标注指南里明确要求“不要因为长就选它”，并且定期抽查。

还有一个隐蔽的坑是位置偏差。如果偏好对总是A在前B在后，标注者可能形成惯性。解决办法是随机打乱A/B顺序，并且在数据处理时记录原始顺序，避免引入系统性偏差。

5. 评测闭环：怎么知道模型真的变好了

5.1 自动评测与人工评测的分工

评测这件事，我的原则是：自动评测做回归，人工评测做验收。自动评测跑得快、成本低，适合每次训练后快速看趋势，但它的分数和人类真实感受经常脱节。人工评测慢、贵，但它是唯一能反映真实体验的标准。

自动评测我通常用三类指标：任务准确率（有标准答案的任务）、格式合规率（输出是否符合预期格式）、以及困惑度（看模型对目标分布的拟合程度）。这三类指标组合起来，能快速发现明显的退化。

人工评测我会设计一个简单的评分卡，从准确性、完整性、简洁性、安全性四个维度打分，每个维度1–5分。关键是评分卡要固定，每次评测用同一套标准，否则分数没法横向对比。

5.2 构建你的“黄金测试集”

黄金测试集是后训练项目的命脉。我的做法是从真实业务场景里抽取200–500条代表性输入，覆盖高频场景、边界case、以及已知的难点。这个测试集一旦确定就冻结，不参与训练，每次评测都用它。

黄金测试集的关键是“代表性”。我见过有人用公开benchmark当测试集，结果模型在benchmark上分数很高，上线后一塌糊涂，因为benchmark和真实场景分布差太远。测试集必须来自你自己的业务，哪怕只有100条，也比一万条公开数据有用。

测试集还要定期更新。业务在变，用户问法在变，测试集半年不更新就会失效。我一般每季度补充一批新case，同时淘汰已经不再出现的旧case。

5.3 发现回归后的排查链路

模型训完发现某个任务退化了，怎么查？我总结了一条排查链路，按顺序走基本能定位问题。

第一步，确认退化是真实的还是评测噪声。用同一批数据多跑几次推理，看分数波动范围，如果波动超过退化幅度，那可能只是随机性。

第二步，定位退化集中在哪类输入。把测试集按任务类型分组，看是哪一组分数掉了。如果只有一类掉了，大概率是那类数据在训练集中被稀释了。

第三步，检查训练数据。看退化任务对应的数据在训练集中占比是否下降，或者是否有低质数据混入。我遇到过一次，某类任务退化是因为合成数据里混入了大量格式错误的样本。

第四步，检查训练超参。学习率过大、训练轮数过多都会导致灾难性遗忘。如果退化是全局性的，优先怀疑超参。

第五步，做消融实验。把可疑的数据批次去掉重训一个小模型，看退化是否消失。这一步最费时间，但最能定位根因。

6. 工程化落地：把后训练变成可重复的流水线

6.1 训练框架与工具链选型

2025年的后训练工具链已经比较成熟，我的选型原则是：训练用成熟框架，数据用自建流水线，评测用轻量工具。

训练框架上，我主要用两类：一类是通用微调框架，适合快速实验；另一类是分布式训练框架，适合大规模训练。选型时重点看三件事：是否支持你需要的并行策略、是否方便接入自定义数据、以及社区是否活跃。我踩过的坑是选了一个小众框架，结果遇到bug没人解答，卡了一周。

数据流水线我强烈建议自建。市面上的数据处理工具要么太通用要么太封闭，很难贴合你的业务。自建流水线不需要多复杂，用脚本加配置文件就能搞定，关键是每一步都可追溯、可复现。

评测工具用轻量的就行，核心是能批量跑推理、能自动算指标、能生成对比报告。我见过有人花大力气搭评测平台，结果模型都迭代三轮了平台还没搭好，本末倒置。

6.2 实验管理与版本控制

后训练实验多、变量多，没有好的实验管理就是一团乱麻。我的做法是三个“必须记录”：数据版本必须记录、超参必须记录、评测结果必须记录。

数据版本用哈希值标记，每次数据更新生成新版本号，训练时记录用的是哪个版本。这样出问题能快速回滚。超参用配置文件管理，不要硬编码在脚本里，方便对比不同配置。评测结果存成结构化格式，方便画趋势图。

我还习惯给每个实验起一个有意义的名字，比如“dpo-v3-lr5e6-data202506”，一眼能看出关键信息。别用“test1”“test2”这种名字，一周后你自己都记不住。

6.3 从实验到上线的最后一公里

实验效果好不等于能上线。上线前我会做三件事：推理性能测试、安全红队测试、以及灰度发布。

推理性能测试看的是延迟和吞吐，后训练后的模型可能因为输出变长导致延迟上升，这个必须提前测。安全红队测试是模拟恶意输入，看模型会不会输出有害内容，这一步不能省。灰度发布是先放小流量，观察真实用户反馈，没问题再全量。

最后一公里的坑往往不在模型本身，而在工程细节。比如模型输出格式变了导致下游解析失败，或者tokenizer版本不一致导致推理结果和训练不一致。这些细节必须在灰度阶段暴露出来，别等全量了才发现。

7. 几个我反复踩过的坑和应对心得

7.1 灾难性遗忘：模型变“专”了但变“傻”了

灾难性遗忘是后训练最常见的副作用。模型在垂直任务上越来越强，但通用能力肉眼可见地下降。我的应对方法是在训练数据里保留一定比例的通用数据，通常不低于20%。另外训练轮数不要太多，SFT一般2–3个epoch就够，多了必然遗忘。

还有一个技巧是分层学习率，底层参数用小学习率甚至冻结，顶层用正常学习率。这样底层学到的通用表示不会被破坏，顶层专注学新任务。这个技巧在算力有限时特别有用。

7.2 数据泄漏：测试集污染导致虚高

数据泄漏是隐形杀手。如果你的训练数据里混入了测试集的样本，评测分数会虚高，上线后原形毕露。我的做法是训练前用测试集做一次去重，任何和测试集相似度超过阈值的训练样本直接剔除。这个步骤花不了多少时间，但能避免大翻车。

7.3 过度对齐：模型变得“太乖”反而没用

偏好优化做过头，模型会变得过度保守，什么都不敢答，或者所有回答都一个腔调。我见过一个模型，问什么都是“这是一个很好的问题”，然后给一段四平八稳但毫无信息量的回答。这种模型业务方是不会满意的。

应对方法是在偏好数据里保留一定比例的“有观点”样本，让模型学会在合适的时候给出明确判断。另外偏好优化的强度要控制，DPO的beta参数不要设得太极端，我一般从0.1开始试。

7.4 评测指标和业务感受脱节

自动评测分数涨了，但业务方说“感觉没变好”，这种情况太常见了。根因是评测指标没对齐业务目标。解决办法是让业务方参与评测标准制定，至少让他们确认评分卡里的维度是他们在意的。我现在的做法是每个项目启动时就和业务方对齐评测维度，避免最后扯皮。

8. 写在最后：后训练是一门手艺

做了这么多轮后训练项目，我最大的体会是：这件事没有标准答案，它更像一门手艺而不是一门科学。同样的数据、同样的超参，不同的人做出来效果可能差很多，差别就在那些文档里不会写的细节——数据怎么洗、配比怎么调、评测怎么做、出问题怎么查。

这份手册里的每一条经验，几乎都是踩坑踩出来的。我不敢说它适用于所有场景，但如果你正在做后训练，或者准备开始做，希望它能帮你少走几个弯路。后训练最迷人的地方在于，它离业务最近，离用户最近，你做的每一个决策都能在最终效果里看到反馈。这种即时反馈带来的成长速度，是纯做预训练很难体会到的。

如果你只能记住一件事，那就记住这个：后训练的核心不是训练，而是数据和评测。把80%的精力花在数据构建和评测闭环上，剩下的20%花在训练本身，你的项目成功率会高很多。