
上周有个朋友来问了一个很实在的问题他们公司想把通用大模型用到质检报告自动归档上提示词写了好几版RAG也接上了但模型产出的内容总透着一股“通用味”专业术语张冠李戴质检结论写不到点子上。他问我是不是该做SFT监督微调了。我听完只回了一句你先别急着微调有没有考虑过让模型先把行业的“语言习惯”学会他愣了一下。这就是很多企业落地大模型时的典型盲区——大家知道RAG、知道SFT却很少意识到在SFT之前还有一道更底层的工序叫Continued Pre-Training继续预训练以下简称CPT。CPT这几年在开源社区里已经是很多行业模型的标配工序但真正把它当成一项工程来做、而非一句口号的企业团队确实不多。这篇文章我会从数据、参数、评估、资源几个维度把CPT从“听说过”讲到“能落地”给你一套可以直接拿着用的实战路径。1. 为什么通用大模型在行业场景失灵问题定位与三点归因1.1 一个质检报告的失败案例提示词和RAG解决不了什么先回到那位朋友的质检报告场景。他传了一批样例给我看任务是让模型从一段质检描述里抽取缺陷类型、损伤等级、处理建议并生成归档摘要。通用模型确实能读懂中文也能按模板输出但问题出在关键判断上。比如“表面存在轻微压伤”这种描述通用模型理解成“表面有划痕”因为“压伤”在通用语料里更多出现在人体或情绪场景再比如“氧化色”这个词模型分不清它是缺陷描述还是正常工艺特征。这类问题的本质是什么呢是通用预训练语料中特定行业的语义密度太低。模型不是不聪明而是它根本没有“读够”这个行业的语料。你给一个完全没学过物理的人出电磁学题他认真听你讲一百遍题型套路也照样容易翻车——因为脑子里缺少物理知识的结构性沉淀。RAG能解决的是“检索相关片段并带进上下文”的问题但模型要把检索到的信息整合成自己的判断逻辑还需要本身对这些术语和业务知识有足够强的先验理解。这也是为什么很多人做了RAG之后效果提升有限检索到的内容模型“接不住”或者上下文里信息一多注意力被冲散。所以如果你的业务场景里存在大量行业术语、判断规则、上下文隐含知识而仅仅靠提示词、外挂知识库都无法稳定提升效果时就该认真考虑CPT这条路了。1.2 CPT和SFT、RAG的分工一个被搞混的先后顺序先把三件事摆在一起区分清楚这是很多企业团队方向性混乱的根源。技术手段解决什么问题核心动作数据形式CPT继续预训练知识注入、行业语言适应让模型在行业语料上继续学习大规模无标注行业文本SFT监督微调指令遵循、输出格式对齐教会模型按用户期望的格式作答高质量指令-回答对RAG检索增强即时知识补充、减少幻觉把外部资料检索进上下文知识库文档 查询从流程上看CPT在先SFT在后。CPT相当于让模型“读一年行业入门课”SFT相当于“手把手教它做真题、对答案”。如果跳过CPT直接做SFT模型面对新的行业术语时本质是在不认识的基础上硬背答案泛化能力会很差。如果跳过SFT直接做CPT模型虽然掌握了行业知识但未必会用对话的格式把知识呈现出来需要后续指令微调来对齐。需要说明的是RAG和CPT不是替代关系而是配合关系。CPT把行业知识内化到模型参数里让模型对术语、上下文更敏感RAG负责把频繁变化、非结构化、数量巨大的业务内容实时捞进来。两者搭配做才能既保持模型“懂行”又不至于每三四个月就把几亿文档重新训练一遍。2. 语料工程决定CPT效果的第一道关卡2.1 行业语料从哪里来别只盯着“高质量文档”做CPT语料质量比模型参数更决定成败。我见过不少项目一开始把精力全放在选基座模型上结果数据工程只花了一周训练效果出来惨不忍睹。数据这部分建议至少占掉项目三分之二的精力。行业语料的来源很多人第一反应是“标准文档”“技术手册”“专家写的教材”这些确实是高价值来源但如果只靠这一类数据量很容易不够。拿制造业举例一次CPT想有可感知的效果行业相关语料通常要准备数十亿到上百亿token的规模。哪怕是小规模验证也要保证行业语料在5亿token以上否则模型基本学不到稳定的领域分布。这要求我们打开思路把眼光放到企业内部实际生产环境中客户工单、客服对话记录这里面有大量口语化的行业表达比如“这台设备异响换了轴承还是响”这类语料贴近真实场景模型学完对业务交互特别有帮助。质检报告、维修日志、巡检记录格式半结构化术语密集是训练行业判断能力的富矿。产品说明书、操作手册、安装调试指南这类语料逻辑性强能帮模型建立对设备和流程的结构化理解。行业期刊、论文、专利、标准规范质量高但门槛也高适合后期做“精读”阶段用。行业垂直社区的公开内容包括论坛、专栏、公众号文章覆盖大量一线经验性知识。需要注意的是企业内部数据往往伴随着数据权限和隐私脱敏问题尤其是工单和客服对话里面可能有客户身份信息、内部系统账号等敏感内容。我的经验是语料进训练管线之前必须走一遍脱敏和合规评审不要想当然地认为只用来训练就没问题。这一点宁可保守也不要冒进。2.2 清洗流水线格式清理、去重、领域筛选三步走拿到原始语料后清洗流程我建议分三层来做每一层都有明确目标和验收标准。第一层是格式清洗。很多企业语料是PDF、扫描件、HTML页面直接提取出来会有大量噪声。PDF要按页解析并恢复段落结构扫描件需要过OCRHTML要去掉标签、导航和广告代码。这层做完的标准是文本连贯可读没有乱码段落边界基本符合原文档结构。第二层是内容去重与模板过滤。企业语料里有大量重复内容比如同一份说明书在不同目录下存了多个版本、回访记录里有大量套路化开头。重复数据不去掉模型会在这些句子上严重过拟合表现就是生成的文本像“复读机”一段话反复说。去重可以用MinHash或SimHash按句子和段落级别做粗粒度去重后再按文档级别做一次双保险。至于模板过滤可以人工扫一批数据把明显的套话模板、空白表格、无效占位符清理掉。第三层是领域相关性筛选。这层容易被忽视但特别关键。企业语料里经常混入大量与目标行业无关的内容比如设备厂商的官网里既有技术文档也有公司新闻、招聘公告、员工活动报道。训练模型时这些噪声会稀释行业知识的密度。实操上可以用一个基础分类器或干脆用大模型做蒸馏打分过滤掉明显不相关的文档只保留行业核心内容。2.3 要不要扩展tokenizer词表一个容易被忽略的决策这个点很多人会漏掉。通用大模型的tokenizer在处理行业术语时往往把一个完整词切碎成多个token。比如把“压伤处理工艺”切成“压伤/处理/工艺”这种粒度虽然不至于出错但增加了模型需要学习的组合模式。如果行业术语本身很密集tokenizer切碎之后序列长度变长训练效率下降模型对术语的整体感知也会弱一些。我的建议是如果你们的行业语料里新词比例明显偏高可以做一次tokenizer词表扩展。具体做法是在原tokenizer基础上用行业语料训练一个补充词表把高频出现的领域复合词、专业缩写、产品型号等作为新词加入。新增词会对应新的embedding初始化时可以用原词表相近词的embedding做平均或者直接随机初始化然后在CPT阶段让模型自己学。不过要提醒一句词表扩展属于锦上添花不是雪中送炭。如果你们的语料里新词比例不高强行扩词表反而会让训练变复杂甚至影响模型对原有词汇的表示稳定性。判断标准很简单抽样1000条行业语料统计里面分词后被切碎的完整术语占比超过15%就值得做低于5%可以直接跳过。2.4 数据配比与epoch控制防止模型“偏科”和“健忘”CPT最大的风险之一是模型在猛补行业知识的同时把通用能力给丢了。这种“偏科”在NLP领域有个正式名字叫灾难性遗忘。而控制它的核心抓手就是数据配比和训练轮数。我个人的经验行业语料与通用语料的比例控制在1:1到1:3之间比较稳妥。行业语料占比太高比如超过50%模型会很快偏向行业分布通用能力明显下降但通用语料占比太高行业知识注入又不够训练了跟没训练差不多。如果你使用的是中文开源基座模型通用语料可以选用开源社区的原训练语料子集、大规模网页语料或者把之前里面比较通用的部分抽出来用。要注意的是通用语料只需当“配菜”不用完全复刻原始预训练数据的规模保持总量与行业语料按比例混合即可。epoch的设置也要克制。行业语料重复训练2到3个epoch是常见区间超过3个epoch边际收益就开始下降而且会加剧对重复数据的记忆。通用语料则尽量只过1个epoch不要反复嚼。如果数据量差距大可以通过采样调整让每个batch里通用和行业数据比例稳定。我习惯在采样器里设定好比例而不是把两堆数据简单拼接后洗牌这样不容易出现某几个batch行业数据过密集的情况。3. 把参数和训练流程写清楚CPT的配置、分布式与稳定性问题3.1 核心超参学习率、batch size、sequence length怎么定不少团队第一次跑CPT时直接把SFT那套超参搬过来用结果一训就崩。CPT和SFT的超参设定逻辑完全不同SFT是让模型在已懂的知识上调整输出格式学习率可以稍微大胆一点CPT要在已收敛的模型上注入新知识步子一大就容易破坏原有表征。我给一份可以直接参考的起始配置以7B到14B参数量级的开源模型为例参数建议值说明学习率1e-5到2e-5甚至可以降到5e-6比SFT的学习率低一个量级SFT常见2e-5到5e-5目的是“小步快跑”Batch Size尽量大128到512个样本梯度更稳定行业知识注入更平滑Epoch行业数据2到3通用数据1防止过拟合和灾难性遗忘Sequence Length原模型最大长度的一半或以上比如模型支持4096建议至少用2048训练覆盖行业文档常见的段落结构优化器AdamW权重衰减0.1行业标配学习率调度Warmup后用Cosine衰减Warmup比例建议1%到3%让前期损失更稳很多人在学习率上栽过跟头。我见过有人用5e-5跑CPT训到一半loss不降反升整个模型输出开始出现重复乱码最后只能回滚重新来。CPT学习率宁可低也不高低只会让你多花点时间跑完高可能直接废掉一个模型代价完全不对等。顺便说一句如果用的是DeepSpeed这样的框架attention dropout、hidden dropout这些参数基本保持原模型设置即可不要随手去改。Batch size的问题也需要多解释一句很多人担心显存不够于是把batch size调到很小比如8结果训练曲线抖动得特别厉害。行业语料里本身就存在大量长尾分布小batch会让模型对每个batch里的噪声更敏感。如果显存受限我建议先用梯度累积把实际batch size拆成micro batch累积几十步再更新一次参数。这样既保证稳定性又不至于因为显存问题牺牲效果。3.2 训练流程混合训练和两阶段有各自适用场景CPT的训练流程设计我见过两种主流做法分别适合不同情况。第一种是混合训练。把行业语料和通用语料按比例混在一个数据池里随机采样一次训练完成。这种做法简单直接适合行业语料规模不大比如10亿token以内、团队时间紧张的场景。好处是不用设计复杂的调度策略坏处是如果你想在后期针对特定高质量数据做强化控制力不够精细。第二种是两阶段训练。第一阶段用行业语料和通用语料混合训练目标是让模型初步建立行业概念第二阶段用高质量、高相关的行业语料比如专家精选的维修案例、诊断规则、标准文档做一次“精读”学习率降到第一阶段的30%到50%训练步数也大幅缩短。这种做法模拟了人“先泛读、再精读”的学习节奏行业能力会更扎实但需要多一个阶段的数据工程和调试成本。我自己实际操作时如果目标是做一个能长期迭代的行业底座模型基本都会选择两阶段第一阶段的行业语料可能来自宽口径清洗结果第二阶段的语料则必须是领域专家评审过的。这两阶段用的数据尽管数量上有差距但每一阶段的目的都很清楚第一阶段扩充覆盖面第二阶段提升判断精度。另外提醒一点如果你的行业文档普遍比较长超过模型默认的context长度比如动不动就是几千字的产品手册、维修流程图配文字说明那建议先做长度外推比如用NTK-aware scaling或YaRN等上下文扩展方法把模型的context window拉长后再做CPT。否则长文档被截断模型学到的是破碎信息行业知识很难形成整体结构。3.3 DeepSpeed/FSDP配置示例单机多卡能跑就不用上大集群CPT的训练和SFT有个区别SFT的数据通常只有几万到几十万条单卡甚至都能跑CPT动不动就是几十亿token必须做分布式训练。但对多数企业团队来说第一步不需要上大规模集群单机多卡比如8卡A100/H100足够支撑7B到14B量级的CPT训练了。以7B模型为例我一般推荐直接用DeepSpeed ZeRO-3或PyTorch FSDP配合bf16混合精度。下面是一份简化的DeepSpeed配置你可以基于它改compute_environment: LOCAL_MACHINE distributed_type: DEEPSPEED deepspeed_config: gradient_accumulation_steps: 8 gradient_clipping: 1.0 offload_optimizer_device: none offload_param_device: none zero_force_opt_optimization: false zero_stage: 3 mixed_precision: bf16: enabled: trueZeRO-3会把优化器状态、梯度、参数都切分到各卡上显存占用比ZeRO-2低很多。如果显存依旧紧张再考虑offload优化器状态到CPU。注意开启offload之后训练速度会明显下降计算密集型的CPT阶段尽量少用。关于bf16和fp16我的建议很明确能用bf16就别用fp16。bf16的指数位和fp32一样动态范围大在CPT这种长训练任务里不容易出现溢出问题。很多显存的loss尖峰、NaN问题其实根源就是fp16的精度不够。3.4 常见训练事故loss尖峰与崩溃怎么排查CPT训练时间动辄几天最怕中途崩掉。我把最常见的几种事故和排查路径列一下Loss突然变成NaN先查学习率是不是太高再看数据里有没有异常值比如某个文档全是特殊字符最后检查混合精度设置。一个小技巧在数据加载时过滤掉所有纯符号或超长无意义文本能避免一大半这类问题。Loss出现周期性尖峰通常是某些batch的数据质量差或者序列长度分布不均匀。解决方法是把数据按长度分桶每个batch尽量保持长度相近并在采样时做一次质量过滤。训练过程中loss下降但生成效果反而变差大概率是过拟合了减少行业语料的epoch数或者提高通用语料比例重新训一版对比。重启后loss不下降很多框架的learning rate warmup在重启后会重新计算如果是从中间checkpoint接着跑建议保留原来的warmup步数设置或者干脆把warmup设小一点。遇到训练崩溃不要慌关键是提前规划好训练日志和checkpoint策略。我习惯每500步记录一次loss和PPL每四分之一训练量保存一次checkpoint这样即使出问题还能回到最近的稳定点不会白白浪费几个GPU天的算力。4. 怎样知道行业模型真的变强了双轨评估与灾难性遗忘4.1 通用基线和行业基线怎么做CPT跑完第一件事不是急着部署而是评估。我发现很多团队喜欢打开一个对话窗口人工试几条觉得“看起来不错”就上线了。这种做法在SFT阶段还能蒙混过关在CPT阶段是绝对不够的——因为你需要的不是“某几个问题回答得不错”而是“整个行业的分布特征被模型建模住了”。我的做法是搭一套双轨评估体系在CPT前、中、后都跑同一套评测用数据对比说服自己通用能力基线方面可以选用公开的评测集比如C-Eval、MMLU、CMMLU、GSM8K等。这些数据集覆盖了常识、数学、逻辑推理、多学科知识能在一定程度上反映模型通用能力有没有退化。跑分不需要追求刷榜重点看CPT前后分数的变化。行业能力基线方面这个评测集需要自己建并且要有针对性。我的建议是从行业语料里抽取典型场景构造3类题术语理解题给出一个行业术语让模型解释含义或归类验证语义对齐业务判断题给出具体场景描述让模型判断处理方式或结论验证知识应用上下文推理题给一段长文档让模型定位关键信息并输出结构化结果验证长文本处理能力。题量不需要特别大500到1000道左右就够用但质量和覆盖面必须经过行业专家确认。评测可以用生成式打分的模式让一个能力更强的通用模型按评分标准打分同时抽30%找人工复核两边分数误差控制在可接受范围这套评测就算建立起来了。4.2 PPL的陷阱困惑度降了不等于效果好了很多技术同学习惯用PPL困惑度来判断模型有没有学好。这里要泼一盆冷水PPL降低只能说明模型对这些数据的拟合度提高了不能说明模型真的把行业知识内化了。行业语料的分布往往相对单一、句式重复度高模型哪怕只是学会模仿表面句式PPL都能大幅下降。我见过一个项目PPL降了15%以上但行业基线的判断题正确率比CPT前还低——模型学会了输出“行业腔”但没学会行业判断逻辑。所以PPL可以作为训练过程的监控信号比如判断loss是否正常下降、有没有过拟合但最终决策一定要看行业基线和通用基线的分数变化。两套基线都稳了才算真正训练到位。4.3 灾难性遗忘的排查与修复过程我在一次制造业设备的CPT项目中就中过招。第一版实验把行业数据比例直接干到了60%epoch设了4训练曲线非常漂亮——行业测试集PPL降幅明显。结果跑到通用评测集上一看C-Eval分数从原来的63掉到了55常识问答里的很多基础问题开始出现明显错误。这就是典型的灾难性遗忘。当时的排查过程大致是这样的先怀疑是数据配比问题把行业数据比例从60%降到33%再怀疑是epoch过多把行业语料的epoch从4降到2同时把通用语料的比例提上来确保每个batch里至少有一半以上是通用内容。改完之后重跑了一版通用能力回到61行业基线还保持住了此前的90%以上效果。我自己做完这轮对比的体会是出现遗忘不可怕它只是模型在告诉你“行业知识挤占了通用知识的空间”解决办法不是停止CPT而是调整配比和训练节奏。另外一个比较有效的补救手段是退火训练在训练的最后几百步把数据源全部切换成高质量通用数据并且把学习率降到非常低比如1e-6相当于对通用能力做一次“轻量唤醒”。这个做法在很多开源社区模型里被大量验证过能把通用能力拉回来一部分同时不破坏行业知识。还有一种更进阶的做法是用模型合并把原始通用模型和CPT后的模型按权重插值融合。不过这个方法的可解释性稍弱建议在配比和退火手段都调到位之后再把它当作补充方案尝试。5. 算力账本、框架选型与小规模验证的节奏5.1 算一笔7B模型跑10亿token的账CPT到底要烧多少显卡这是每个老板都会问的问题。我可以给一个可以手动估算的粗粒度公式。训练的总计算量大约等于6 × 模型参数量 × 总token数这个系数来自前向反向传播的计算量粗略估算。以一个70亿参数模型为例训练10亿token总计算量大约是6 × 7×10^9 × 10^9 4.2×10^19 FLOPs。再看算力供给。一张A100 80G在bf16下的理论算力大约是312 TFLOPS实际训练中MFU模型算力利用率做到40%已经很不错了也就是单卡实际有效算力大约120到140 TFLOPS。8卡A100满打满算有效算力约1.0到1.1×10^15 FLOPs/s。除一下10亿token的训练时间大约是10到12小时算上通信损耗、日志停顿按15到20小时准备比较稳妥。这个估算对实际项目很有用。如果你们的目标行业语料有50亿token8卡A100大概要跑3到4天如果是100亿token一周左右。很多团队一听“CPT”以为要租一个月的超级集群其实做一个7B量级的行业底座训练周期并不夸张。如果你需要更大规模比如千亿参数模型跑千亿token那就完全是另一个量级的工程了建议优先考虑租用更大规模集群同时准备好断点续训方案。5.2 框架选型从轻量框架到分布式训练框架CPT框架怎么选取决于团队规模、模型规模和工程能力。我给一张基于经验的选型表框架适合团队优点主要成本LLaMA-Factory中小团队、第一次尝试上手快支持LoRA/全参训练很多开源模型适配完善超大模型多机扩展偏弱Hugging Face Transformers DeepSpeed有一定算法工程经验灵活生态完整ZeRO-3稳定性好需要自己写训练脚本和数据处理PyTorch FSDP已经用PyTorch的团队原生支持和Transformer代码兼容好调试分布式问题有学习成本NVIDIA NeMo / Megatron-LM千亿级模型或规模化平台分布式能力极强支持张量并行、流水线并行工程复杂度高不适合快速验证如果你的目标是7B到14B量级的行业模型LLaMA-Factory加DeepSpeed后端是我比较推荐的起步组合。它把数据处理、训练循环、评测脚本做了很好的封装团队可以把主要精力放在语料和参数调优上。如果后续要扩展到70B甚至更大参数再迁移到NeMo或Megatron架构把训练管线重写成更规范的分布式任务。5.3 先跑5亿token再做全量验证节奏建议CPT不是一锤子买卖我特别不建议第一次就跑全量数据。更稳妥的节奏是先做一个小规模可行性验证再铺开全量训练。具体操作上我会先抽出5亿到10亿token的行业语料子集加上通用语料整个数据池控制在15到20亿token用目标配置跑一轮。这一轮的作用不是直接产出最终模型而是检验三件事数据清洗流程能不能跑通训练loss曲线稳不稳定双轨评测体系能不能拉开差距。如果这轮跑完行业基线明显提升通用基线没崩再启动全量训练心里就有底了。小规模验证还意味着可以多跑几个对比实验比如行业数据配比1:1和1:2哪个好学习率1e-5和2e-5哪个更稳这些对比用全量数据跑很贵用子集跑就便宜得多能帮你把最终方案收敛得更好。磨刀不误砍柴工这个阶段花一周时间能省下后面全量训练返工的两三周。6. 从CPT到上线流水线衔接与运营更新6.1 基座模型选型性能、可控与商用边界的平衡CPT是在已有基座模型上继续训练所以基座模型的选型直接决定行业模型的天花板。我一般会看三件事模型对中文的支持能力、社区的生态成熟度、以及开源协议允许的使用范围。建议选择有开放权重且商业使用边界较明确的基座模型避免训练到一半才发现不能用到业务里。在能力维度上最好选一个本身就比较均衡、推理能力过关的模型。CPT能够注入行业知识但很难大幅提升模型的基础推理能力——如果你选了一个基础推理就偏弱的底座指望靠行业语料把逻辑能力补起来那基本是缘木求鱼。所以宁可先花时间评测几个候选底座在通用任务上的表现再做决定。6.2 不要最后才想SFTCPT和下游微调的衔接要提前规划前面讲过CPT之后通常还要接SFT甚至可能还要做DPO之类的对齐训练。这里有个很容易踩的坑如果CPT阶段完全不管后续指令微调的数据形式等CPT练完才发现模型对“指令格式”非常陌生甚至输出风格产生了偏移那SFT阶段又要额外花大量力气去修复。解决方案是把整条流水线当成一个整体来规划。CPT阶段的语料里可以混入一定比例的“对话形态”文本比如把新技术文档改造成“问题回答”的排版方式让模型在学习行业知识的同时不丢失对话感。但这部分通常控制在5%到10%以内不影响整体知识注入的纯粹性。更重要的是CPT训练完成后不要直接拿原始通用SFT数据来微调而是要把行业问答数据加进去让SFT阶段同时完成“输出格式学习”和“行业指令遵循”两件事。6.3 部署维度的几点提醒量化、推理速度与持续更新行业模型练完之后部署阶段有几个容易被忽视的细节。第一量化会带来效果损耗。CPT后模型的参数分布通常和原始模型有一些偏移直接转成INT4量化可能会让行业知识表达受损。我的建议是先转INT8或BF16做线上验证如果效果达标再尝试更低精度的量化切忌为了省显存而让模型“带伤上线”。第二建议为行业模型保留一条独立的评测流水线。行业数据是持续变化的今天工厂进了新设备明天质检标准出了新版本模型使用的行业知识必然有过时的一天。我会在每个迭代周期设置增量CPT任务拿新增行业语料和老语料按比例重新混合接着上一次的checkpoint继续训练。这样模型知识跟得上业务变化而不是训练完就变成一潭死水。第三一个容易踩的坑模型上线后业务指标没有提升不一定是模型的问题也可能是评测体系和业务目标没对齐。CPT这个技术从一开始就要绑定业务指标来评估不能只盯模型分数。如果模型在行业基线上涨了但业务流程里的实际自动化率没变那大概率是下游应用设计的问题而不是继续训练的问题。我在实际项目中逐渐形成一个习惯每次CPT训练都会同步保留一套“行业语料快照”、一份评测报告、一组可复现的训练配置。这样半年后业务方来问“当时这个模型是用什么数据训的”我能立刻给出完整答案。把CPT当作一项可重复的工程流程而不是一次性的实验脚本行业模型才能真正成为企业AI落地里那个可靠的底座。