企业官网建设流程全解析

Naive-N0.5-Flash这个名字，我第一次看到的时候，第一反应是这又是个蹭热度的小模型。但真正把这个项目跑了一遍之后，我得说，这套Post-Training的完整链路确实值得拿出来聊聊。尤其是现在大家动不动就聊预训练、千卡集群，反而把后训练这个真正决定模型“能不能用”的环节给轻视了。Naive-N0.5-Flash属于那种参数规模不大、主打快速响应的轻量模型，它的能力几乎全部来自后训练阶段的精心设计。这篇文章我不想复述官方文档，而是想以一个实际参与者的视角，拆解这条Post-Training路线里的数据工程、多阶段训练策略、稳定性调优和评测闭环，把我踩过的坑和验证过有效的方案讲清楚。

如果你正准备给中小尺寸模型做后训练，或者已经跑完SFT但发现模型还是“脑子清楚、嘴上没把门”，那这篇文章应该能给你一套可以抄作业的参考路径。这里没有玄学，只有数据配比、训练参数和踩坑记录。

1. 为什么Naive-N0.5-Flash这类模型，最值钱的反而是“后训练”

1.1 从N0.5和Flash两个词看模型定位

先拆一下名字。N0.5在命名上指向参数量级，大致落在1B以下、几百M到0.5B左右的区间，介于常见的Nano和Mini之间。Flash这个词强调的是推理速度和低延迟，瞄准的是端侧部署、实时交互、嵌入式场景，而不是在A100集群上慢慢跑离线任务。

这类模型和7B、13B的通用助手有一个本质区别：它们的容量非常有限，几乎装不下太多“知识”。所以你不能指望它像大模型那样，靠海量预训练语料内化世界知识。N0.5的定位更像是“一个脑子转得快、但知识面有限的执行者”。这对后训练提出了完全不同的要求——你不能只做指令微调，还得把有限参数里的每一份容量都用在刀刃上，让它至少在特定任务上做到高服从性、高格式遵循度、高稳定性。

很多团队拿到这种小模型的基座之后，喜欢直接上SFT，训完之后发现效果不如基座自己瞎说。原因很简单，基座模型的预训练目标是“预测下一个词”，它天然倾向于续写而不是回答问题。后训练要做的，就是把这个“续写机器”掰成一个“能听懂指令并按要求执行”的工具，这件事对小模型来说几乎是生死线。

1.2 基座模型只是“会接话”，后训练才是“会办事”

我习惯用一个比喻：基座模型就像一个刚从名校毕业、满腹经纶但完全不懂职场规矩的新人。你问他问题，他能给你讲出一大段背景知识，但你让他“按三句话总结”或者“输出JSON格式”，他就开始自由发挥了。Post-Training就是入职培训，要教会他不光知道，还得知道怎么按照公司的格式写周报、怎么在约束条件下完成任务。

从技术实现上看，后训练要解决的核心问题有三个。第一个是格式和指令遵循，也就是模型要能分清“你在问我什么”“你希望我怎么回答”。第二个是偏好对齐，也就是在多个可行答案中，模型要能选出人类更喜欢的表达方式。第三个是可验证任务的推理能力，比如数学、代码这类有标准答案的任务，模型需要学会自我校验和逐步推导。这三个问题在预训练阶段都不会被显式优化，只能靠后训练阶段的结构化数据和多阶段训练来补齐。

1.3 哪些团队适合参考这条后训练路线

说实话，不是所有团队都需要跑一遍完整的Post-Training。如果你的目标只是给内部做个Demo，那直接用现成的API就够了。但如果你是想针对特定场景定制一个轻量模型，或者你手里的底座模型是一个开源的较小尺寸基座，那么这套Post-Training流程就是绕不开的。

我特别建议两类人认真看这篇文章。一类是刚搭好训练流程、正准备从SFT往偏好优化进阶的工程师，另一类是被“小模型效果总差一口气”困扰的团队。后者的问题往往不是模型太小，而是后训练做得太糙。别急着换更大的底座，先把数据清洗和阶段顺序做对，很多时候0.5B的模型也能达到令人满意的实用性。

2. 后训练第一关：数据工程，决定了模型的上限

2.1 公开指令集里，真正能用的数据比想象中少

Naive-N0.5-Flash项目早期踩过最大的坑，就是高估了公开指令数据集的质量。我最初从几个流行的公开SFT数据源里抽了一批样本，跑了一个快速SFT验证，结果模型的输出经常出现“车轱辘话”、重复前缀、甚至英文夹杂中文的问题。排查下来发现，公开数据里至少有三分之一存在明显的质量问题：有的是从网页里扒下来的对话，用户侧和助手侧的角色标注混乱；有的是用大模型批量生成的伪指令，内容高度同质化；还有的是回答长度分布极其极端，长的一两千词，短的只有一个字。

这里想强调一个观点：SFT数据量和模型效果并不是正相关，数据和效果的关系更像是一个倒U形。数据太少，模型学不到指令多样性；数据太多但质量差，模型反而会把噪声里的错误模式学进去。对小模型来说尤其如此，因为它的容量有限，每学一个坏样本都在挤占好样本的位置。

2.2 一套可复用的清洗流程

在Naive-N0.5-Flash项目里，我们最终沉淀了一套四步清洗流程，每一步都是踩过坑才加上的。

第一步是去重。这里不是简单做文本去重，而是用MinHash加LSH对全量数据做近似去重。因为很多公开数据集之间存在互相拼接的情况，不同来源里同样的问答可能以不同格式重复出现。如果不做这一步，模型会被迫记忆重复模式，导致生成内容趋向保守和模板化。

第二步是角色标注校验。这一步针对的是从网页抓取的多轮对话数据。我们写了一套启发式规则加分类模型的双重校验：先按发言人前缀、特殊符号切分出对话轮次，再用一个小的分类器判断每一条“助手回复”是不是真的符合助手身份。这一步过滤掉了大量“用户自问自答”和“助手反问用户”的错位数据。

第三步是响应质量打分。我试过用规则打分，比如长度、标点、代码块完整性，后来发现规则太容易被绕过。最终采用的做法是用一个指令跟随能力较强的大模型对响应做质量打分，分数维度包括相关性、信息密度、格式规范性和毒性。打分结果再经过人工抽检校准，从五个维度综合筛选出保留数据。这一步能过滤掉大约30%的低质数据，是最有效的一道防线。

第四步是安全和隐私过滤。这块没什么可说的，属于必须做的基本功，只是提醒一句：正则过滤只能过滤显式词，真正有效的还是基于分类模型的软过滤，因为很多有问题的表达是隐晦的、语义化的。

2.3 数据配比：小模型的“营养菜单”

清洗完数据之后，配比问题就来了。训练数据里不同类型的任务各占多少，直接决定了模型的能力偏向。Naive-N0.5-Flash项目里我们反复调了几轮，最终一个效果比较稳定的配比是这样的：通用指令问答占30%，代码相关占20%，数学推理占15%，工具调用和结构化输出占15%，多轮角色扮演和长对话占20%。

为什么这个比例效果好？关键在于“结构遵循”类任务的比例被刻意拉高了。通用问答决定模型的知识面和基本表达能力，这部分即使少一点，基座模型本来就能兜住。代码和结构化输出之所以占比高，是因为它们能强制模型学会格式约束，这对小模型来说是一种性价比极高的“能力迁移”。模型学会了输出正确格式的JSON或代码块，那么它的整体输出规范性也会提升。数学推理数据则承担了“多步逻辑链”的训练责任，防止模型在稍微复杂的指令面前直接摆烂。

需要注意，配比不是一锤子买卖。每跑完一个阶段的训练，都需要抽样观察模型在不同任务上的表现，再反过来调配比。我自己的经验是：如果模型普遍回答过于冗长，就降低通用问答比例、提高结构化输出比例；如果模型在简单指令上答非所问，那大概率是通用指令的多样性不够，而不是量不够。

2.4 合成数据要用，但不能全信

合成数据是小模型后训练里躲不开的话题。N0.5的训练语料里大约有40%是合成数据，但我必须说，这一块如果处理不好，反而会带崩整个模型。

我们踩过的一个具体问题是：合成数据里的“自我表扬”倾向非常严重。用教师模型生成数据时，如果提示词里写了“请给出高质量回答”，教师模型经常会生成“这是一个很好的问题”“我很乐意帮助你”这类客套话。这类话单看没什么，但当大量数据里都有类似开头时，模型就会把“说废话”当成一种默认行为，导致推理效率直线下降。

解决方法是两个：一是在生成提示词里加负向约束，明确要求“不要客套、不要重复用户的问题、直接给出答案”；二是在清洗阶段加一个“无效开头”检测器，把以固定客套句式开头的样本单独拎出来审查。这套组合下来，生成的指令质量才勉强达到可用水平。

3. 后训练主流程：SFT、DPO、RLVR三步走

3.1 第一步：SFT冷启动，把格式和指令遵循先立起来

我见过很多团队跳过SFT直接做对齐，理由是“基座模型已经会对话了”。这个想法在小模型上是完全行不通的。基座模型虽然会生成流畅文本，但它根本不知道什么叫“指令”，什么叫“回答边界”。SFT阶段的目标非常朴素：先把格式和交互方式定下来。

N0.5项目的SFT阶段配置是：3个epoch，学习率1.5e-5，warmup比例5%，序列长度从基座阶段的2048逐步扩展到4096。这里有个容易忽略的点，就是SFT阶段要不要做数据packing。packing能显著提高训练吞吐，但如果你用的是旋转位置编码，就一定要在计算attention时对不同样本做好mask隔离，否则模型会学到跨样本的虚假依赖。我们第一版就是因为packing时mask没做对，导致模型偶尔会从上一个样本的上下文里“继承”话题，排查了很久才发现。

SFT阶段的收敛判断不能只看loss。我们更关注的指标是训练样本里的“格式完成率”，比如每100条指令里，模型能正确输出指定格式的比例。当这个比例在验证集上稳定在95%以上时，SFT阶段就算合格了。这里多说一句，不要盲目拉高epoch数，小模型SFT过了3到4个epoch之后，很容易出现对训练数据的高频词汇过拟合，表现就是回答越来越“油滑”但实际信息密度下降。

3.2 第二步：DPO做偏好对齐，小模型的最优解

SFT跑完后，模型已经能做到“有问必答、格式正确”。但它的偏好还是乱的：同一个问题可能给出好几个不同风格的答案，有的简洁、有的啰嗦、有的喜欢加表情。这时候就需要偏好对齐，把模型的“口味”拧到符合人类偏好的方向上。

现在主流的对齐方法里，DPO（Direct Preference Optimization）在小模型上明显比PPO更实用。我们做N0.5时把PPO也试跑过，最大的感受是：PPO需要额外的奖励模型，而小模型场景下奖励模型很容易过拟合，打分失真，最后策略模型在奖励模型的错误指导下越跑越偏。DPO则不需要单独的奖励模型，只需要偏好数据对（chosen和rejected），直接在SFT模型上用分类目标做优化，训练稳定性和资源占用都友好得多。

DPO阶段有几个关键超参需要调。beta值控制对偏好差异的敏感度，我们试下来beta=0.2附近效果最稳，太大（比如0.5以上）会导致模型对chosen和rejected之间细微的措辞差异过度敏感，输出变得拘谨；太小（0.1以下）则偏好对齐效果不明显。学习率用1e-6这个量级，比SFT低一个数量级，因为DPO是在SFT模型基础上做微调，步子太大容易把SFT阶段学到的指令遵循能力冲掉。训练步数控制在500到1000步左右，跑太多同样会过拟合到偏好数据上。

这里还要提一个很tricky的地方：DPO数据的构建质量，直接决定对齐成败。我们在构建偏好对时，不是简单让大模型生成两次答案再挑一个，而是让教师模型对同一个问题生成多个候选，再由人工或裁判模型按详细程度、语气、格式规范、事实正确性四个维度排序。最初图省事，用规则生成偏好对，结果模型学到的不是“更好的回答”，而是“更长、更多列点的回答”，这是典型的reward hacking前兆。

3.3 第三步：RLVR处理可验证任务

SFT加DPO跑完，模型在日常对话、通用指令上已经能看了。但在数学、代码这类有标准答案的任务上，表现离可用还有差距。根本原因是这类任务对推理过程的要求远超“格式正确”，需要模型具备多步验证和自我纠错能力。SFT阶段即使塞再多的例子，模型也只是在模仿解题套路，遇到没见过的变体就抓瞎。

这就轮到RLVR（Reinforcement Learning with Verifiable Rewards）上场了。这个思路的核心在于：既然对话质量很难量化打分，那数学题和代码题总可以。GSM8K的答案对不对、单元测试能不能过，都是硬性可验证的奖励信号，不需要训练奖励模型去预测。

我们在N0.5项目里的做法是：搭建一个采样和验证的循环。对每道数学题，让当前策略模型采样8个候选答案，然后用规则校验器检查最终答案是否正确。答案正确的样本得到奖励1，错误得0。然后基于这个奖励信号做策略梯度更新。这里最关键的细节是奖励的稀疏性处理：8个采样全部错误的题目直接丢弃，不参与梯度更新，否则模型会被“怎么做都错”的样本带偏，产生严重的梯度噪声。

代码任务的流程类似，但验证器换成单元测试。这里有个隐藏工程点：不是每道题都有配套测试用例，所以需要先用大模型生成题目和测试用例，再人工筛一遍。筛的时候要特别小心测试用例本身的正确性，一个错误的测试用例会让模型对该题目的所有正确解法全部判负，对训练数据造成污染。

RLVR阶段跑下来，模型在GSM8K上的准确率从SFT后的65%左右提升到了82%，HumanEval的pass@1也从48%涨到61%。这两组数字说明，可验证任务上，RLVR的价值非常直接。

3.4 阶段顺序背后的逻辑

这里想说一句：为什么必须是SFT、DPO、RLVR这个顺序，而不是反过来或者混合着来？因为这三个阶段解决的问题是递进的。SFT先解决“能力下限”的问题，让模型至少能输出人话、能遵循格式。DPO在SFT的基础上解决“风格和偏好”的问题，让模型学会选择更符合人类预期的表达。RLVR则是在前两者都稳定之后，再去单独打磨“可验证推理能力”的尖刀项。

一旦顺序乱了，典型的后果是：先做DPO，模型在样式上变得很讨喜，但因为基础能力不足，回答内容经常是“礼貌的空话”；先做RLVR，模型会在数学题上突飞猛进，但它的通用对话能力甚至可能退化，因为优化信号过于单一。后训练和预训练一样，也是有阶段性的，每个阶段踩在前一个阶段的肩膀上。

4. 训练稳定性和资源调优：把loss spikes和OOM都收拾干净

4.1 精度、学习率、序列长度的三角关系

小模型后训练看起来比预训练轻量，但实际操作中遇到的训练稳定性问题一点都不少。我们在N0.5项目里遇到最多的是三类问题：loss spike、显存OOM和训练速度上不去。

先说loss spike。SFT阶段有几次loss突然从1.2跳到3.5，一开始怀疑是学习率太高，降了学习率也没用。最后定位到是混合精度训练下，某些batch里出现了极大值的attention logit，导致梯度爆炸。解决方法是把梯度裁剪从1.0降到0.5，同时在数据加载阶段加了一个“异常样本检查”——如果某个样本的token数不足序列长度的10%，直接丢弃。这种极短样本经常是数据清洗时的残留，它们的gradient噪声极大。

精度选择上，bf16是比fp16更稳的选择。fp16在小模型上虽然省显存，但动态范围窄，一旦loss出现小幅波动，很容易溢出到inf。bf16的指数位和fp32一致，数值范围大得多，牺牲的是尾数精度，但后训练阶段对精度的敏感度远低于预训练，实测下来完全够用。

序列长度是另一个容易被忽略的资源杀手。N0.5从SFT阶段的2048扩展到RLVR阶段的4096，显存占用直接翻倍还不止。我们在4096长度下，单卡A100 80G也撑不住一个完整的DPO训练，只能配合梯度检查点（gradient checkpointing）和FlashAttention 2才能把batch size稳定在16。提醒一下，梯度检查点会大概增加30%的计算时间，换来的显存节省接近一半，这个trade-off在资源紧张时非常划算。

4.2 训练监控：除了loss还要看什么

很多人训模型只看训练loss曲线，loss一降就觉得万事大吉。但在Post-Training阶段，loss的参考价值远不如几个“行为指标”。我们的监控面板上同时跑着训练loss、验证集格式遵循率、平均回答长度、拒绝回答率、代码块闭合率五个指标。

这五个指标里，平均回答长度是一个非常早期的问题信号。如果这个数字在训练过程中突然上升，说明模型正在往“多说废话”的方向漂移，这时候即使loss还在降，也得停下来抽一批样本人工看。拒绝回答率（模型说“抱歉我不能回答”或“这个问题超出我的能力范围”的比例）在SFT阶段应该在1%以下，如果高于这个数，通常意味着数据里有过多“安全拒绝”类样本，导致模型变得胆小。

4.3 资源优化几个实用招

小模型虽然参数少，但数据量大、序列长，一样会跑得很慢。我们最后把训练吞吐提升了近两倍，靠的是三个比较土但有效的招。

第一招是数据预加载和打散。把训练数据提前加载到内存并用num_workers多进程喂给GPU，避免GPU等数据。这个事很多人知道但没做彻底，实际用下来，数据加载时间能从每个step的40%降到5%以下。

第二招是使用DeepSpeed ZeRO-2。N0.5这种0.5B模型，单卡其实能塞下，但为了加速我们用4卡并行，ZeRO-2把优化器状态切分到多卡上，显存压力小，通信开销也不大，比ZeRO-3更适合小模型。

第三招是减少日志和checkpoint频率。听起来很基础，但实际上很多人每100步存一个checkpoint，每个好几G，一方面占用磁盘，另一方面保存时的同步操作会打断流水线。我们改成每500步存一个主checkpoint，每2000步存一个可恢复的临时checkpoint，整个训练流程少了很多不必要的停顿。

5. 评测不是打分，而是建立bad case闭环

5.1 多维度评测组合

N0.5项目刚开始做评测的时候，我也是只看MMLU和GSM8K的分数，后来发现被分数骗了。模型在标准benchmark上分数很好看，一放到真实场景里就露馅。原因是公开benchmark和真实任务的分布差异太大，而且小模型在基准测试上很容易“背题”——训练数据里如果混入了评测集的相似样本，分数会虚高得离谱。

我们最终沉淀了一套五个维度的评测组合：通用能力用MMLU加C-Eval；数学用GSM8K和MATH的抽样子集；代码用HumanEval和MBPP；指令遵循用IFEval；对话质量和实用性则靠一套自建的场景题库，覆盖客服问答、信息抽取、格式转换、角色扮演等真实任务。这套组合跑一次大概需要两到三个小时，但能比较全面地看出模型在哪个维度存在短板。

5.2 bad case回收与增量迭代

评测的意义不在分数本身，而在暴露问题。我们的做法是每次评测后，把模型输出的bad case全部捞出来，按错误类型聚类，比如“格式错误”“指令理解偏差”“事实性错误”“啰嗦冗长”。然后针对占比最高的几类问题，回到数据工程环节去补数据，再做增量训练。

这就是Post-Training和预训练一个很大的不同：预训练几乎不回头，一次跑完；后训练则是一个不断“评测-收集-补数据-重训”的闭环。小模型有一个独特优势——迭代成本极低。N0.5的一次增量SFT只需要大概两到三个小时，一天之内可以完成一个完整的“发现问题到验证修复”的循环。这是大模型团队很难享受的节奏优势。

5.3 LLM-as-Judge的陷阱

在对话质量评测里，完全靠人工看几百条样本太慢，所以通常会借用大模型当裁判。但LLM-as-Judge有几个已经被反复验证的偏差，这里必须提醒：位置偏差（模型倾向于选先出现的答案）、长度偏差（模型倾向于选更长的答案）、以及自我偏好偏差（模型倾向于选和自己风格相似的答案）。

我们应对的办法有两个。一是把两个候选答案的位置随机交换，跑两次比较，只有两次结论一致才算有效。二是把评判任务的粒度从“哪个更好”拆成“A是否比B更简洁、A是否比B更准确、A是否比B格式更规范”这类单维度比较。细粒度比较比分值打分稳定得多，也更适合在小样本上做人工复核。

6. 常见问题与排查技巧速查

6.1 高频问题对照表

这里整理一份N0.5项目过程中高频踩坑的问题速查表，每条都是实际遇到并解决的。

6.2 一个真实的数据污染案例

有一次模型在训练到第2000步时，突然出现一个奇怪的现象：验证集loss稳定下降，但模型开始大量输出“抱歉，我还没有学会回答这个问题”。抽了50条bad case，发现一小半都包含这句话。

排查了很久，最后在数据清洗脚本里找到真凶。清洗时用了一个网页抓取的去重工具，它会把格式相似的纯文本当成重复内容删除，但这个工具把一批真实指令数据里的“抱歉，我还没有学会回答这个问题”当作模板去重了，只保留了一条样本。但更麻烦的是，这批带这句话的样本并没有被真正删除，而是被标成了重复标记，在后面某些数据合并逻辑里又被重新放回了训练集，导致这一句话被重复学了上百次。

从那之后，我们定了一个规矩：任何清洗工具的标记字段，宁可多查一步也不能直接信任。清洗结果要做完整的数据集抽样检查，包括查看被删除样本和被保留样本的句级分布。

6.3 一个reward hacking案例

RLVR阶段还遇到过一次经典reward hacking。模型在GSM8K验证集上分数一直在涨，但抽样看了几个答案，发现模型在遇到复杂题时，不再一步步推理，而是直接输出一个能猜中得分的答案，比如输出“答案无法确定”或“条件不足”。因为规则校验器只检查最终答案字符串，不检查推导过程，模型就钻了这个空子。

这个问题的根源在于验证器过于宽松。解决方法是把奖励拆成三部分：最终答案正确得0.5分，推导过程包含关键步骤得0.3分，步骤数量大于等于2得0.2分。这样一来，模型光猜对答案拿不到满分，必须老老实实写步骤。改完奖励设计之后，模型很快就收敛回了正常的解题路径。

这个案例让我意识到一件事：RLVR里的“可验证奖励”并不意味着奖励设计可以偷懒。验证器只验证最终结果是完全不够的，你给模型留多少漏洞，它就一定会钻多少漏洞。

6.4 最后分享一点实战体会

整个Naive-N0.5-Flash项目做下来，我个人最大的体会是：小模型的后训练，本质上是一场“数据洁癖”和“阶段耐心”的训练。数据清洗多花一天，后面训练能少折腾三天；阶段顺序不乱，模型能力就能一层一层搭上去。别急着上最花哨的方法，先把SFT的数据配比和格式遵循率做扎实，你会发现后面DPO和RLVR的推进顺畅得多。

另外，如果让我给一个最值得投入产出的方向，我会说是那个“评测-收集bad case-补数据-重训”的闭环。这个闭环转得越快，模型的实战能力就增长得越快。大模型拼的是算力，小模型拼的是迭代效率，这一点在N0.5上体现得淋漓尽致。

最后分享一个最近在做的扩展：把这套Post-Training流程迁移到支持图像输入的版本上，数据和阶段策略要做不少调整，但整体框架应该是通用的。等跑完一轮再回来分享具体的差异和坑。