大模型训练全流程：预训练、SFT、RLHF与线上badcase修复

大模型训练全流程预训练、SFT、RLHF与线上badcase修复很多人把训练模型理解成把业务知识喂给模型。这个理解只对了一小半。预训练解决的是能力底座语言、知识、推理、代码、世界模型。后训练解决的是可用性听懂指令、按格式输出、知道什么时候拒答、偏向人类喜欢的回答。RAG解决的是动态知识和可追溯事实。线上 badcase 修复则是在这三者之间做取舍。真正难的不是知道 SFT、RLHF、RAG 这些名词而是判断一个问题该放到哪里修。一、先把训练链路说清楚大模型训练通常分成两段预训练和后训练。预训练让模型学会世界长什么样。它从大规模文本、代码、网页、书籍、论文、问答数据里学习下一个 token 的概率分布。这个阶段不要求模型成为一个好助手只要求它在海量语料上形成语言、知识、模式和推理的基础能力。后训练让模型学会应该怎么帮人。同样一个问题预训练模型可能补全文本、可能胡说、可能不按格式、也可能不知道自己应该遵守系统指令。SFT、RLHF、DPO、RFT 这些方法都是在把一个会续写的模型推向一个能对话、能执行、能拒绝、能遵守偏好的助手。阶段核心问题训练信号结果预训练让模型获得通用语言、知识、代码和推理能力大规模自监督语料下一个 token 预测基座模型SFT告诉模型什么是正确示范prompt 标准答案会按示例完成任务RLHF / DPO告诉模型两个答案里哪个更像人想要的偏好对、奖励模型、偏好优化更符合人类偏好RAG给模型注入当前、私有、可追溯知识检索到的外部文档回答更准确可引用来源评测回归判断改动有没有真的变好离线集、线上指标、人工评审训练能闭环关键判断预训练塑造能力边界后训练塑造行为倾向RAG补充上下文事实。不要用后训练硬塞大量动态知识也不要指望 RAG 改掉模型的稳定行为习惯。二、预训练到底在解决什么问题预训练的目标不是记住所有答案而是把语言和世界压缩进参数里。它学到的是一组可泛化的统计结构词语关系、事实关联、代码模式、推理链条、文体风格、常见任务形式。Llama 2 论文里提到基座模型使用公开来源数据预训练并通过数据清洗、数据配比、更多 token、更长上下文等方式提升模型能力。这里有一个容易被忽略的点预训练阶段的数据规模很大但数据配比和清洗同样重要。更多数据不是自动等于更好数据。预训练主要解决四类问题语言建模知道句子如何继续知道不同语言、文体、领域文本的结构。知识吸收在参数里形成常识、事实、概念关系和领域知识。能力涌现代码生成、数学推理、摘要、翻译、问答等能力很多来自大规模预训练的泛化。表示学习把文本映射到模型内部的高维表示为后续指令对齐打基础。但预训练不擅长解决三个问题不知道用户真正想要什么用户问帮我总结模型不知道应该短一点、分点、保留风险还是写成报告。不保证事实最新参数里的知识有时间边界也很难低成本更新。不保证输出可控JSON格式、固定字段、业务话术、安全拒答这些都不是预训练的主要目标。所以基座模型再强也要经过后训练。否则它像一个读过很多书的人但没有接受过岗位培训。三、SFT告诉模型好答案长什么样SFTSupervised Fine-Tuning监督微调是后训练的第一层。它用 prompt 理想回答训练模型让模型模仿高质量示范。OpenAI 文档对 SFT 的定义很直接提供正确回答示例引导模型行为常见场景包括分类、翻译、特定格式生成、修复指令遵从失败。这个定义很实用SFT 本质上就是示范学习。SFT 解决的不是主观偏好而是可明确写出标准答案的问题。适合 SFT 的问题原因样本形态固定格式输出有明确正确格式输入 → 标准 JSON / Markdown / 表格业务分类标签集合稳定用户问题 → 类别信息抽取答案可校验文本 → 字段标准话术企业口径明确场景 → 回复工具调用模式参数和步骤可标注用户目标 → tool call指令遵从失败正解可示范bad prompt → 正确回答SFT 的样本应该像生产请求而不是像考试题。{ system: 你是企业客服助手。回答必须使用JSON字段为answer、risk_level、next_action。, user: 用户问我已经退款了为什么钱还没到账, assistant: { answer: 退款已发起后到账时间通常取决于支付渠道。银行卡一般需要1-5个工作日余额支付通常更快。, risk_level: medium, next_action: 查询退款单状态并在无法确认时转人工 } }这条样本的关键不是退款知识而是同时示范了角色、格式、字段、语气和处理路径。3.1 SFT 样本怎么构造构造 SFT 样本要从线上任务倒推而不是从模型能力倒推。第一步定义任务边界。不要写让模型更懂客服而要写当用户询问退款到账时间时输出包含解释、风险等级和下一步动作的 JSON。第二步收集真实输入。线上问题、客服工单、搜索 query、用户追问、工具调用 trace优先级高于人工幻想题。人工构造可以补边界但不能替代真实分布。第三步写标准答案。标准答案要符合最终上线格式。训练时是什么格式推理时也应该是什么格式。OpenAI 的微调实践也强调训练样本格式要和推理时保持一致。第四步做困难样本。如果只训练干净问题模型会在真实线上变形。样本里要有口语、错别字、缺字段、混合意图、上下文省略、越界请求。第五步保留测试集。训练集只用于更新模型测试集只用于评估。测试集不能被训练过程反复污染否则上线前看到的提升大概率是幻觉。3.2 SFT 怎样才容易收敛SFT 不收敛常见原因不是模型太差而是样本在互相打架。标注不一致同一个意图有的样本输出JSON有的样本输出自然语言。任务混杂一批样本教客服问答另一批样本教写营销文案没有统一路由。负样本比例异常训练集中60%都在拒答线上真实拒答只有5%模型会变得过度保守。输入缺信息但答案补了信息用户没有提供订单号标准答案却说你的订单已退款模型会学会编造。指令没有重复出现小数据微调时训练样本里没有稳定出现系统约束模型只能从答案里猜规则。经验上先把数据质量做到 80 分再谈数据量。Llama 2 论文有一个很有参考价值的结论他们放弃了大量低质量第三方 SFT 数据转向几万条更高质量的标注效果反而更好。超参上可以按这几个方向排查现象可能原因调整方向训练集好测试集差过拟合减少 epoch、增加多样性、扩大测试集训练集也学不好学习不足或样本冲突增加 epoch / 学习率先清洗冲突样本输出变得死板epoch 太多或样本太单一减少 epoch增加等价表达格式仍然不稳格式示范不足增加格式边界样本加入自动校验幻觉变多答案里含输入没有的信息删除或改写这类样本OpenAI 微调实践里也给出类似方向模型没有按训练数据学到时可以增加 epoch输出多样性下降时减少 epoch不收敛时再考虑调大学习率。不要一上来就盲目加大训练轮数。四、RLHF / DPO解决哪个答案更好的问题SFT 适合教标准答案但很多线上问题没有唯一标准答案。比如用户让模型写一封拒绝合作的邮件。两个答案都正确一个更礼貌一个更简洁一个更符合公司调性。SFT 只能告诉模型这是一个好答案却很难告诉模型这个答案比另一个更好。这就是 RLHF 和 DPO 的位置。InstructGPT 的训练链路很经典先收集人工示范做 SFT再收集模型回答的排序数据训练奖励模型最后用强化学习优化模型。论文里提到小得多的 InstructGPT 在人工偏好上可以超过更大的 GPT-3这说明更会按人类意图回答不完全等同于参数更多。RLHF 解决的是偏好对齐用户问题 帮我写一段接口报错文案告诉用户系统繁忙。 回答A 系统繁忙请稍后再试。 回答B 当前访问人数较多服务响应变慢。你可以稍后重试未完成的操作不会重复扣费。 偏好标注 preferred: B rejected: A 原因 B解释了原因降低用户焦虑并补充了关键风险信息。这类偏好很难写成固定标准答案但很适合用 pairwise preference 学。DPO 可以理解成更直接的偏好优化。它不一定需要先训练一个独立奖励模型而是用 preferred / non-preferred 成对数据让模型更偏向被选择的回答。OpenAI 的 DPO 文档也建议先用 SFT 在理想回答上打底再用 DPO 细调偏好。4.1 格式异常能不能用 RLHF 修可以但要分情况。如果是模型完全不知道格式优先 SFT。比如你要求输出{ answer: ..., citations: [], risk_level: low|medium|high }模型经常少字段、字段名写错、类型不对。这是标准答案明确的问题应该先用 SFT 教格式再用解析器和重试兜底。如果是模型知道格式但在复杂场景下偶尔偏离可以用偏好优化。线上badcase 用户输入很长包含多轮历史、表格和特殊符号。 模型答案内容正确但JSON最后多了一句解释导致解析失败。 SFT样本 输入长上下文 特殊符号 格式要求 输出严格合法JSON DPO/RLHF样本 preferred_output: 严格合法JSON无额外解释 non_preferred_output: JSON后面追加以上是我的分析 偏好原则 在内容相同的前提下能被机器稳定解析的回答优先。这种场景下RLHF/DPO 不是在教模型JSON是什么而是在强化不要为了显得更有帮助而破坏机器协议。关键判断格式类问题先 SFT后偏好优化。SFT 教会结构RLHF/DPO 压住坏习惯。五、线上 badcase 应该怎么修线上 badcase 不能一股脑丢进训练集。先分类再决定修复手段。badcase 类型典型表现优先修复方式是否进训练格式异常JSON 解析失败、字段缺失SFT 解析校验 DPO是指令不遵从要短答却长篇解释SFT / DPO是事实过期政策、价格、库存不准RAG / 数据源修复通常不进私有知识缺失不知道公司流程RAG通常不进检索错误引错文档、漏召回RAG 检索链优化不优先训模型幻觉输入无依据却编结论SFT RAG 拒答样本视原因过度拒答安全词误触发DPO/RLHF 边界集是语气不合适太冷、太啰嗦、太像模板DPO/RLHF是工具调用错误选错工具、参数错SFT 工具评测是复杂推理失败多约束任务算错RFT / 任务拆解 / 工具化视成本5.1 一个 badcase 修复闭环线上发现 订单退款场景下模型偶尔输出自然语言导致前端JSON解析失败。 归因 不是知识缺失。 不是检索问题。 是格式遵从在长上下文下不稳定。 修复 1. 从日志中抽取真实输入脱敏。 2. 标注严格JSON标准答案加入SFT。 3. 构造DPO偏好对 - preferred合法JSON - rejected内容正确但多解释/少字段/字段类型错误 4. 增加离线评测 - JSON parse success rate - required fields coverage - answer correctness 5. 小流量上线观察解析失败率和用户满意度。这里最关键的是第 3 步。很多团队只做 SFT不做偏好对结果模型知道标准格式但在线上复杂输入里仍然会好心多说两句。这两句话在人类看来不严重对系统却是事故。5.2 什么时候不要训练不是所有问题都值得训练。事实经常变化价格、库存、政策、活动、接口状态。用RAG或工具查实时数据。问题来自检索召回模型没有看到正确文档训练模型只会让它更会猜。问题来自产品逻辑系统没有传订单状态模型无法凭空知道。问题来自输出后处理缺失JSON解析失败应该有schema校验、自动修复或重试。样本只有几个孤例先进入评测集观察不要立刻污染训练分布。训练是慢变量。RAG、工具、prompt、后处理是快变量。线上修复要先用快变量止血再决定要不要沉淀到训练。六、哪些放 SFT哪些用 RAG一个简单判断行为模式进 SFT动态事实进 RAG。SFT 改的是模型习惯怎么做。RAG 给的是模型现在应该参考什么。需求更适合 SFT更适合 RAG固定输出格式企业语气和话术可辅助工具调用策略退款政策原文每日价格、库存、排班私有文档问答不优先对边界问题的拒答习惯可辅助引用来源少样本稳定分类长尾知识覆盖RAG 的原始论文指出纯参数模型在访问和精确操纵知识上仍有限更新世界知识和提供依据也是难题。AWS 对 RAG 的解释更工程化RAG 让模型在生成前参考训练数据之外的权威知识库不必重新训练模型。这就是边界。如果你的问题是模型不知道公司报销制度不要微调。把制度文档放进知识库做好分块、召回、重排、权限和引用。如果你的问题是模型看到制度后仍然不按公司格式答那才考虑 SFT。6.1 SFT 和 RAG 可以一起用实际生产里最常见的组合是RAG 提供事实SFT 规定行为。用户问题 我这种情况能报销打车费吗 RAG提供 1. 公司差旅制度第3.2条 2. 用户所在部门的补充规则 3. 最近一次制度更新时间 SFT训练出的行为 1. 先给结论 2. 再引用依据 3. 不确定时列出缺失信息 4. 输出固定字段conclusion、basis、missing_info、next_actionRAG 负责答得有依据SFT 负责答得像产品需要的样子。七、样本怎么保证泛化而不是背题过拟合不是只发生在小模型上。大模型微调同样会背题尤其是样本少、格式单一、答案模板过强时。泛化要从样本设计开始。7.1 训练集要覆盖变化维度同一个任务至少覆盖这些维度输入变化短句、长句、多轮上下文口语、错别字、缩写、夹杂英文正常请求、边界请求、恶意请求信息完整、信息缺失、信息冲突输出变化同样格式下的不同表达不同风险等级可回答、需追问、需拒答有工具结果、无工具结果、工具失败场景变化高频主路径低频长尾历史badcase人工构造的边界压力样本不要把 1000 条几乎一样的样本当成 1000 条有效样本。它们只会让模型更自信地背同一种模式。7.2 训练集和测试集要按场景切分随机切分有时会高估效果。比如同一个用户问题改写了 10 个版本随机切分后训练集和测试集都出现相似表达测试分数会虚高。更好的切分方式切分方式适用场景目的按时间切分线上日志模拟未来请求按用户/会话切分多轮对话防止同一会话泄漏按意图切分分类/客服看新意图泛化按模板族切分格式输出防止背模板按难度分层工具调用/推理看边界能力7.3 用最小必要训练保护能力训练集不是越多越好训练轮数也不是越多越好。一个模型被微调得太狠会出现能力收缩回答变短、拒答变多、创造性下降、通用问题变差。Llama 2 的 RLHF 迭代里观察到过能力回退某个版本在押韵诗歌能力上变差。后来他们把之前迭代中的优秀样本重新混入缓解了这个问题。这对业务微调很有启发不要只拿最新 badcase 训练否则模型会被最近的问题牵着走。使用强基座不要指望微调用小模型补出不存在的推理能力。控制训练强度小学习率、少epoch、早停比猛训更稳。混入保能力样本保留通用问答、正常闲聊、核心业务主路径防止模型只记得badcase。做能力回归集除了业务指标还测通用能力、拒答率、格式成功率、工具调用成功率。偏好优化别太激进DPO/RLHF 的强度过大容易把模型推向单一风格。只训练需要改变的行为知识更新走RAG系统约束走prompt稳定行为再进训练。OpenAI 的 DPO 文档里有一个 beta 超参用来控制新模型多大程度保留原行为。这个思路可以抽象成一条工程原则微调不是重塑模型人格而是在尽量少破坏原能力的情况下修正稳定缺陷。八、训练数据的标准结构真正可用的数据集不只是 prompt 和 answer。它应该能支持训练、评测、归因和回滚。{ id: refund_format_0001, source: online_badcase / human_annotation / synthetic_edge, scenario: refund_status, task_type: structured_output, input_messages: [ {role: system, content: 输出必须是合法JSON字段为answer、risk_level、next_action。}, {role: user, content: 我的退款怎么还没到账} ], output: { answer: 退款到账时间取决于支付渠道。银行卡一般需要1-5个工作日。, risk_level: medium, next_action: 查询退款单状态无法确认时转人工。 }, metadata: { difficulty: medium, contains_pii: false, expected_schema: refund_answer_v2, eval_tags: [json_parse, required_fields, refund_policy] } }DPO / RLHF 偏好样本则要保留 rejected 版本。{ id: refund_preference_0007, input: 用户在长上下文后询问退款到账时间要求JSON输出。, preferred: { answer: 退款到账时间取决于支付渠道。银行卡一般需要1-5个工作日。, risk_level: medium, next_action: 查询退款单状态无法确认时转人工 }, rejected: { answer: 退款到账时间取决于支付渠道。银行卡一般需要1-5个工作日。, risk_level: medium }, rejected_suffix: 以上是我的分析。, preference_reason: preferred 是合法JSON字段完整rejected 缺少 next_action且追加了自然语言。, tags: [format_violation, missing_field, extra_text] }偏好样本最怕只写preferred 更好。要写清楚为什么更好否则标注员、训练者、评测者都会各自理解。九、一套可落地的训练修复流程把训练当成一个持续系统而不是一次性项目。9.1 从线上日志到训练集采集收集用户输入、模型输出、检索文档、工具调用、后处理错误、用户反馈。脱敏去掉手机号、身份证、订单号、地址、姓名等敏感信息。聚类按错误类型聚合格式、事实、拒答、工具、语气、推理。归因判断是模型行为问题、知识问题、检索问题、工具问题还是产品链路问题。标注SFT写标准答案DPO/RLHF写偏好对RAG问题修知识库。评测每类badcase进入离线回归集设置硬指标。小流量先灰度不要直接全量。回滚保留基座、数据版本、训练参数、评测结果能复现也能回退。9.2 评测指标要和 badcase 类型绑定问题类型核心指标不能只看格式异常parse success rate、schema pass rate人工感觉回答不错事实问答answer accuracy、citation precision语言流畅度拒答问题false refusal rate、unsafe answer rate拒答率越高越好工具调用tool selection accuracy、argument accuracy最终答案是否像对语气风格pairwise win rate、投诉率句子是否更长推理任务step accuracy、final accuracy、cost单条样例成功评测集也要分层主路径、长尾、历史 badcase、对抗样本。上线前如果只测历史 badcase很容易修好旧问题引入新问题。十、几个常见误区10.1 把知识都塞进 SFT公司政策、商品价格、活动规则、接口状态这些都可能变化。放进 SFT 会有两个问题更新慢难追溯。更好的方式是 RAG 或工具查询。10.2 用 SFT 修所有主观偏好更自然一点别那么啰嗦多解释风险不要像客服模板这些是偏好问题。可以用 SFT 打底但最终通常要靠偏好数据。10.3 只训练正例不训练边界模型在线上最容易出问题的地方往往不是主路径而是信息缺失、规则冲突、用户输入很乱的时候。没有边界样本模型只会在演示环境里稳定。10.4 用训练代替系统工程格式输出不能只靠训练。应该同时有 schema 约束、解析校验、失败重试、降级策略。训练能降低错误率但不能替代工程护栏。10.5 每次 badcase 都立刻训练单个 badcase 可能是偶然采样、上游数据缺失、提示词冲突也可能是检索失败。先归因再决定是否进入训练。否则训练集会越来越脏。十一、最后给一张决策表当线上出问题时可以按这张表快速判断。你看到的问题先问自己优先方案模型不知道某个事实这个事实会不会更新会更新就 RAG / 工具输出格式错标准格式是否明确明确就 SFT 校验内容正确但不够好是否存在主观偏好DPO / RLHF模型过度拒答是否安全边界标错偏好样本 边界评测引用了错误文档模型是否拿到了正确上下文优先修检索工具参数错参数规则能否标注SFT 工具调用样本复杂题推理错是否需要外部计算工具化 / RFT / 任务拆解新版本通用能力下降是否训练太集中减少训练强度混入保能力样本一句话总结SFT 负责示范正确做法RLHF/DPO 负责压住偏好问题RAG 负责提供当前事实评测负责证明没有把别的能力弄坏。训练不是把 badcase 堆进模型而是把错误变成可复用的行为规则、偏好约束和评测资产。做对了模型会越来越稳定做错了模型只是越来越像训练集。参考资料OpenAI, Training language models to follow instructions with human feedbackMeta AI, Llama 2: Open Foundation and Fine-Tuned Chat ModelsOpenAI Docs, Model optimizationOpenAI Docs, Supervised fine-tuningOpenAI Docs, Fine-tuning best practicesOpenAI Docs, Direct preference optimizationRafailov et al., Direct Preference Optimization: Your Language Model is Secretly a Reward ModelLewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP TasksAWS, What is RAG?