近几年只要跟企业做AI落地的朋友应该都遇到过同一个场景拿着开源通用大模型比如Llama、Qwen、DeepSeek高高兴兴接上业务数据让模型回答行业问题时得到的输出经常是“正确的废话”。问它某个设备的巡检周期它能把变压器的常识背一遍却答不出你们厂里的运维规程。很多人第一反应是“那我微调一下”于是跑了一轮指令微调结果模型学会了问话的格式但该不会的照样不会。原因很直白指令微调只能让模型把已经知道的知识换一种表达方式它不能凭空学会你行业里那些压根不在预训练语料里的专业知识。要让通用模型成为真正“懂行”的行业模型需要让它在行业语料上再学一遍这个过程就是Continued Pre-Training也就是继续预训练。这篇文章就是一份实战指南讲清楚为什么需要它、什么场景适合用、具体怎么做以及我在企业项目里踩过的大小坑。1. 为什么通用大模型做不好行业任务1.1 通用模型的“知识盲区”通用大模型的预训练语料主要来自互联网公开内容、维基百科、开源代码、学术论文等。“通用”决定了它擅长的是广而浅的知识而不是某个行业的深而专的知识。比如预训练语料里可能收录了很多“云计算”的百科条目但不会把某家运营商内部的服务目录、故障等级定义、客户投诉处理流程写得清清楚楚。行业知识往往是封闭的、不在公开网络上的模型从根上就没见过自然回答不出来。而且行业知识本身有很强的上下文依赖。以医疗场景为例通用模型知道“高血压”的标准定义但只有在你提供了该院的临床路径、药品目录和诊断规范之后它才能给出真正可用的建议。但问题是这些内容无法靠prompt塞进去上下文窗口再大也装不完一整本诊疗规范。更麻烦的是很多行业知识是“结构化非结构化”混合的比如设备维修记录可能是工单系统里的几百个字段也可能是老师傅留下的一段潦草笔记通用模型没有见过这类数据就学不会这类推理。你可以把通用模型想象成一个刚毕业的通才员工他聪明、自知、沟通能力强但是一进到具体公司不懂你的业务流程、术语黑话和行业规矩。Continued Pre-Training做的就是“岗前培训”用真实行业资料把这些空缺补上。1.2 指令微调解决不了知识缺口我经常在企业项目里看到一种误区一提到让模型更专业就想到微调Fine-tuning然后默认微调就是SFTSupervised Fine-Tuning监督微调。SFT本质上是让模型学会“以给定指令要求的格式回答”它调整的是输出的风格、语气、结构而不是填充模型缺失的知识。举个我经历过的例子。某次我们给一家物流公司做客服大模型一开始只做了SFT拿几千条问答对去训练效果确实变好了模型的回答结构很规范会用“您好”“感谢您的咨询”开头。但只要客户问到比较偏门的运输保险条款模型依然乱编。为什么因为那些条款在预训练和SFT数据集里都不存在模型只会从相近知识里“猜”。后面我们补了一轮行业语料继续预训练把承运条款、理赔流程、部门操作手册喂进去再去SFT模型才真正能答出有依据的细节。这里有一个判断标准很实用如果模型应该知道答案但希望它按特定语气来回答用SFT。如果模型根本不知道答案问题出在没有知识那就要考虑继续预训练。很多SFT做了没效果不是微调方法有问题而是缺了知识注入这一步。1.3 继续预训练才是在给模型“专业进修”Continued Pre-Training持续预训练指的是在基座模型已经完成了通用预训练的基础上继续用特定领域或特定任务的语料进行自监督训练。它的本质和预训练相同都是让模型通过下一词预测任务学习数据的统计规律只不过这一次语料从“全网内容”换成了“行业内容”。这样学到的知识不是临时存在上下文里的而是被写进了模型的参数权重里长期有效。打个比方通用预训练相当于读了一个综合性大学的通识课程继续预训练相当于毕业后进入行业啃了一整年的公司内部资料、行业标准、案例库。这种“进修”带来的提升是结构性的尤其是在专业术语、行业规则、文本风格和数据分布上都会更接近真实业务。当然它也像人一样补课补得太过也会把原来的常识忘掉所以全程要控制“新知识”和“旧知识”的配比这部分我放在后面讲。2. 方案选型CPT、SFT、RAG到底选哪个2.1 三条路线的分工很多企业做行业大模型时都会问是继续预训练、指令微调还是搭RAG这三条路线解决的是不同问题不是互斥关系我通常直接用一张表给客户讲清楚。维度Continue Pre-TrainingSFTRAG核心作用注入领域知识对齐输出格式与交互方式提供动态、可检索的事实信息是否改变模型参数会且影响分布最深会但主要在输出端调整不改变参数训练成本最高需要大量语料和GPU中等需要人工标注数据低构建向量库即可适合场景行业术语密集、知识型问答客服、助手等需要特定话术知识库频繁更新、需要引用来源局限语料不足时容易遗忘无法解决知识缺失强推理和多跳问答容易断裂用一句话总结CPT负责“让模型懂专业”SFT负责“让模型会沟通”RAG负责“给模型递资料”。一个完整的行业模型落地经常是三者搭配使用。比如我做过的一个政务咨询项目先用政府公开数据和政策文件做了CPT让模型理解政策术语和办理流程再构造了上千条咨询话术做SFT统一回答口径最后接了一个政策检索接口确保最新文件能实时引用。只做任何一环都会露馅。2.2 什么情况必须上CPT判断要不要上成本不低的继续预训练我有几个经验信号。第一模型在业务场景中频繁出现“答非所问式自信”。你问A它答B看起来有道理但细节全是编的。这说明模型缺乏相应概念而不是表达问题。第二行业里有大量独特的专有词汇、缩写、命名规则。比如金融行业里的“非标”“委外”“预期信用损失模型”法律里的“抗辩”“反诉”“既判力”。模型只靠通用语料很难建立起这些术语之间的逻辑关系必须在行业语料里反复出现。第三你已经尝试了SFT和RAG但效果依然不够。SFT做完了模型说话已经很礼貌了但内容还是空RAG把资料检索出来了模型却不会顺着资料做综合推理。这时候就该回归语料做CPT。第四你要做的场景是知识密集型、判断型的比如医疗辅助诊断、工业质检报告生成、法律文书审查而不是简单的检索问答。这一类任务需要模型自己“沉淀”行业逻辑只靠提示词或外部数据库是撑不起来的。2.3 继续预训练与微调的衔接顺序正确顺序通常是先CPT再SFT最后按需接RAG或工具调用。这个顺序有讲究。如果先SFT再CPT模型可能在继续预训练阶段把好不容易学到的指令表达方式覆盖掉还得重新做SFT。如果先CPT模型先学会行业知识再用少量高质量对话数据去“格式化”输出训练效率更高最终的交互体验也更稳定。实际项目中数据量有限的话也可以把CPT和SFT分开训练各自调参。不要试图在同一个数据集里混着训练因为两者的目标和loss计算方式不一样。我在早期尝试过把领域语料和对话语料混在一起做“一步到位的训练”结果模型既没做好词法预测也在对话评测上翻了车。后来老实拆成两步反而简单可控。3. 数据工程行业语料的收集与清洗3.1 高质量行业语料从哪来很多企业以为做继续预训练必须要有“海量”数据其实真正的门槛不是数量而是质量。我用过最小有效规模的CPT项目只有不到2亿token照样把一个小型开源模型在一个垂直领域的术语理解提升了很大一截。关键在于数据是不是足够“像真实业务”。常见的语料来源有几类。第一企业内部知识库包括操作手册、维修日志、产品说明书、客服工单和标准作业流程。第二行业公开资料比如行业标准、白皮书、监管文件、学术论文、专业图书。第三脱敏后的真实业务文本比如合同、报告、病例记录、司法文书。第四专家问答沉淀比如企业内网的QA、论坛问答、专家访谈记录。这里特别提醒使用公开数据和用户数据前一定要做好合规审查尤其是客户的业务数据含有隐私或个人身份信息的内容必须先脱敏否则后续麻烦非常大。数据合规是继续预训练项目里第一优先级技术再好也不能越过红线。3.2 清洗与去重的关键步骤行业语料比通用语料脏得多PDF表格、扫描件OCR乱码、网页广告、系统导出的半结构化文本都很常见。我一般会按下面几层来做。第一层是格式清理。把HTML标签、Markdown标记、页眉页脚、水印、超链接、特殊符号去除。PDF如果是从排版工具导出的优先用文档对象解析比直接OCR效果好得多。第二层是内容过滤。用关键词和正则把明显的广告、联系方式、无效页面过滤掉。还要过滤掉过短的段落比如少于50个字的片段对预训练帮助很小还容易引入噪声。第三层是去除重复。行业数据里同一份合同模板被保存了上千份同一份行业标准被复制了几十次如果不做去重模型会反复背诵这部分浪费训练成本还容易过拟合。我常用MinHash做文档级去重再用n-gram做句子级去重简单高效。第四层是质量打分。可以训练一个轻量分类模型判断文本是否属于目标行业、是否具有知识密度也可以直接用规则加正则先过滤再人工抽检。我们之前在每个项目里会抽5%的清洗后数据让行业专家快速判断是否“像回事”如果专家觉得语义不清就继续调清洗逻辑。3.3 数据量级与配比的经验值继续预训练到底要多少数据回答这个问题要先想清楚模型规模和行业复杂度。如果是一个7B左右的模型目标只是让它在某几个专业场景上更懂术语5到10GB纯文本大约25到50亿token已经能看到明显效果。如果是几十B甚至上百B的模型或者行业跨度很大比如同时要覆盖生产、研发、供应链多个方向数据量要按数十亿甚至百亿token来规划。行业语料和通用语料的比例建议控制在20%到50%之间。纯用行业语料训练模型会在行业任务上变强但在通用常识、代码、逻辑推理上的退步会非常明显。我记得有次把行业语料比例放到70%训练后行业评测涨了12%通用基准却掉了15%用户很容易感知到“变笨了”。后来把行业语料降到40%再混入通用数据行业评测只掉1个点通用能力基本稳住这个配比就比较健康。4. 训练方案设计与参数配置4.1 全量微调还是参数高效微调继续预训练最直接的做法是加载基座模型在整个行业语料上对所有参数继续梯度更新也就是全量继续预训练。效果通常最好但显存和算力要求最高。7B模型的AdamW优化状态量非常大单卡基本跑不动要靠多卡并行加DeepSpeed ZeRO或FSDP还得配合梯度检查点。参数高效微调比如LoRA、QLoRA在继续预训练中同样能用而且很常用。LoRA通过在注意力权重上加低秩矩阵只训练少量参数显存占用小调参快。但对继续预训练来说LoRA有一个天生弱点低秩矩阵的容量有限对大规模、多样性的行业知识注入不够充分。如果语料只有几千万token用LoRA完全可行如果语料到了数十亿tokenLoRA想“硬记”下大量知识会很吃力。我个人的建议是中小型模型比如7B或13B且预算有限先用QLoRA做一轮“知识试读”验证数据方向对不对效果符合预期再上全量。如果是正式生产且语料充足全量继续预训练仍是首选。还有一种折中方案冻结大部分层只解冻最后若干层的注意力参数效果接近全量但成本低不少。4.2 学习率、批次大小与训练步数继续预训练最常犯的错是把学习率设得太高。预训练阶段通常会用到5e-4这种量级但继续预训练是在预训练好的模型上做“精修”学习率必须大幅降低。对全量继续预训练常见范围是1e-5到5e-5对LoRA或QLoRA可以放宽到1e-4到5e-4。这里没有绝对最优需要小规模实验。批次大小也有讲究。理论上总batch size是“序列长度乘以batch数”一般为了保证梯度稳定7B模型一次更新尽量攒到256到1024条序列每条序列长度可以是2048或4096。显存不够就用梯度累积比如真实batch size设为8累积16步等效batch size就是128。训练步数不用太多行业语料不是越多越好通常0.5到2个epochs就够跑太多会把模型推到只熟悉行业语料的局部区域造成严重遗忘。我建议训练过程中持续保存checkpoint不要只保留最终版本。我在一个项目里遇到过第2个epoch的模型在行业评测上比第4个epoch还要好最后选了中间checkpoint上线说明继续预训练不是“跑得越久越好”每一步都要用评估说话。4.3 防止灾难性遗忘的混合训练技巧灾难性遗忘是继续预训练最大的坑。模型在行业语料上训练几天后行业知识倒是提升了但可能连基本常识都开始胡说。根本原因是新数据分布持续覆盖旧知识梯度更新在旧任务方向上的偏移过大。最有效的办法还是混合旧知识。在每个训练step里把行业语料和通用语料按比例混在一起比如行业比通用等于6比4或者模型刚训练完继续预训练后再用一小部分通用预训练数据做“回放”。我在具体操作中通常把通用语料作为一个额外的数据流用sampler按比例采样行业数据不够时就增加通用数据的占比。这样模型在“补新课”的同时也没有放下“旧课”。另外可以调低学习率、缩短训练步数必要的时候对关键通用任务做评测。如果发现通用能力下降明显可以考虑冻结底层embedding和部分浅层只更新深层参数。底层往往保存了语言和常识的基本表示动得越少遗忘越轻。5. 真实训练流程从环境到监控5.1 训练环境搭建这一节我按在生产环境里实际使用的方案来讲。继续预训练首选Linux服务器比如Ubuntu 20.04或22.04至少4张A100 80G或者8张4090也可以跑小规模实验。软件栈方面Python 3.10、PyTorch 2.x、Transformers、Accelerate、DeepSpeed如果要用LoRA就加PEFT或者直接装Unsloth做快速验证。显存不足可以先开梯度检查点gradient checkpointing再用DeepSpeed ZeRO Stage 2或FSDP。7B模型单张80G可以勉强装下但优化器状态很容易爆所以我还是推荐用多卡加ZeRO或者直接用QLoRA把优化器开销降下来。先把流程跑通再追求规模这一点很重要。5.2 用TransformersDeepSpeed跑起来下面给一个可以直接抄的简化训练脚本思路。我们用的是HuggingFace生态代码量不大。先把数据组织成文本文件每一行一条文档按自己的行业语料做tokenizer并切成块。from transformers import AutoTokenizer, AutoModelForCausalLM, Trainer, TrainingArguments from datasets import load_dataset model_name Qwen/Qwen2.5-7B tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained(model_name, trust_remote_codeTrue) dataset load_dataset(text, data_files{train: industry_corpus.txt}) def tokenize(examples): return tokenizer(examples[text], truncationTrue, max_length2048) tokenized dataset.map(tokenize, batchedTrue, remove_columns[text])然后是训练参数。我一般会关闭对话模板直接把文本拼起来做自回归预测tokenizer在遇到长文本时按block切分。接着定义TrainingArgumentstraining_args TrainingArguments( output_dir./cpt_checkpoints, per_device_train_batch_size4, gradient_accumulation_steps16, learning_rate3e-5, num_train_epochs1, logging_steps50, save_steps500, fp16True, gradient_checkpointingTrue, warmup_steps200, max_grad_norm1.0, report_tonone, )训练时用Trainer即可跑之前建议先拿一个mini batch做一次sanity check确保数据能吃进去、前向反向不报错。大规模训练再叠加DeepSpeed的配置文件和accelerate launch启动。5.3 训练过程中的监控指标训练不是按一下运行就等结果要盯几个关键信号。第一是loss。继续预训练的初始loss通常在1.5到2.5之间具体看基座模型和数据难度。如果训练上百步后loss纹丝不动先怀疑数据切块错误大量内容是空的或重复。第二是grad norm如果经常飙到几十上百说明某个batch里混进了异常样本可以做梯度裁剪也要检查数据清洗是否漏了“中文乱码”“超长数字串”之类。训练中点推荐用WandB或TensorBoard记录loss、学习率、显存占用和吞吐量。一个直观的经验是7B模型在A100 80G上使用全量继续预训练加ZeRO吞吐能到每GPU每秒几千token如果掉到几百多半是数据预处理卡住了或者dataloader的num_workers太低。监控起来能帮你快速定位是算力瓶颈还是数据瓶颈。我还习惯在看loss的同时每500步跑一个小下游评测集。loss降了不代表业务指标一定涨有些阶段loss降得很漂亮但评测集里关键词都开始胡扯了。及时跑评测能避免浪费几天的训练时间。6. 评估与验收怎么证明行业模型变强了6.1 困惑度不是唯一标准很多人用困惑度PerplexityPPL来评估继续预训练效果因为它计算简单不需要人工标注。PPL确实能反映模型对领域语料拟合程度我们训练中也会看但千万不要把它当成金标准。我们遇到过PPL下降非常漂亮、明显低于基座模型但业务专家一测模型回答的行业问题还是很一般。原因在于PPL衡量的是“模型对文本的惊讶程度”而业务效果更看重“模型能否在正确答案上给出正确判断”。高维行业文本里模型可以把常见句式学得很顺却抓不住关键实体和逻辑关系。所以PPL只能作为粗筛不能作为验收依据。6.2 搭建行业评测集真正能说明问题的是围绕业务场景搭建的评测集。评测集不需要很大但要有代表性。如果做法律场景可以收集三类问题一是名词解释类检验术语定义是否准确二是法条检索类给定案情判断相关法条三是案例分析类给出事实让模型输出结论。每一类准备50到100题作为固定评测集。制作评测集时可以请业务专家出题并写参考答案最好附带“采分点”。比如问“设备出现振动值超标如何处理”专家答案里有“停机”“检测轴承”“记录振动频谱”三个关键词模型回答能命中多少个就按比例给分。这种有条件得分的方式比单纯让模型打分更稳定。我还习惯把通用能力评测也纳入验收流程。如果只测行业能力容易漏掉“变笨”风险。我常用MMLU、C-Eval等通用基准里的部分子集做回归测试至少确保行业模型在常识、数学、逻辑上没有明显退化。6.3 让一线专家参与盲评自动评测能看出“数量上的进步”但“质量上的飞跃”必须靠人。建议把基座模型、SFT模型、CPT加SFT模型和完整版模型放到同一个页面让业务专家在不告知模型版本的情况下对结果盲评。评分维度可以从准确性、完整性、是否符合行业习惯三个角度打1到5分。这里有个细节专家盲评的题目不要和训练数据来自同一批文档否则容易产生数据泄漏分数虚高。我吃过这个亏有一版模型在内部测试上几乎满分一到真实验收就露馅后来发现测试题和训练语料是同一份操作手册里出来的属于典型的“背题”而非“学会”。所以评测集最好由另一批专家新出或者至少在时间、来源上刻意隔开。7. 常见问题与排查技巧实录7.1 Loss不降反升继续预训练最常见的“翻车现场”是loss完全不动或者往上涨。先不要急着调学习率先做几个基础排查数据文件是不是空的或乱码tokenizer是否正常序列长度设得过大导致绝大多数样本都是padding模型权重是不是被错误加载成了随机初始化我建议第一步做sanity check拿一段正常行业文本只跑一个batch看看输入和label是否对得上。如果单条文本的loss就能正常下降说明数据管线没问题问题出在整体配置。之后再调学习率和batch size。一开始学习率太高确实会出现loss先降后涨的现象降到合理区间就好了。7.2 模型“变笨”了行业能力上去了通用能力掉得很厉害这是灾难性遗忘的表现。最直接的解决方案是混合更多通用语料比如把行业语料占比降到30%左右或者补充通用数据回放。另外一个有效手段是降低学习率我试过把3e-5降到1e-5通用评估掉点立刻减小行业评测只微降一点点这个平衡点值得多试。如果混通用语料已经没法救了可以考虑从更早的checkpoint重新训练只跑0.5个epoch。不要觉得浪费继续预训练很多时候最合适的停止点就是训练总量的一半左右这个在多个项目里都验证过。7.3 训练中途OOM和崩溃显存OOM是最常见的技术问题。解决办法从易到难依次是调小per_device_train_batch_size、开启gradient checkpointing、用DeepSpeed ZeRO Stage 2或3、开启CPU offload。如果模型本身就撑不下就换用LoRA或QLoRA做参数高效训练。有时不是显存不够而是显存碎片化。可以调整PyTorch的显存分配策略或者在启动训练前预留显存。训练崩溃如果在某个固定step发生多半是数据里有特殊字符导致tokenizer崩了可以定位到具体样本删掉。我们在处理一批来自旧系统的报告时遇到过很多次类似问题后来在清洗阶段加了异常字符过滤基本没再复发。7.4 数据泄漏导致评估虚高这个问题隐蔽而危险。行业语料和测试集同源会导致模型评估分数远超真实水平。排查方式是检查测试集中是否存在训练语料里几乎原文复现的句子。如果是必须把测试集重新构建。更稳妥的办法是把训练数据按时间线切分比如用去年的数据训练用今年上半年的数据做测试模拟真实业务数据分布的未来迁移。还有一类泄漏是“公开数据集泄漏”。如果你的训练语料是从公开数据集里爬来的而这些公开数据集已经被基座模型在预训练阶段见过那么再做继续预训练也可能导致指标虚高。这种情况很难完全避免只能在报告结果时注明数据边界。最后再分享一个小技巧。很多团队做继续预训练一上来就挑最大规模的模型、拉最贵的GPU结果成本花了效果却没起来。我个人的经验是先拿最小的基座模型、最小的数据子集比如0.1%的数据跑通全流程确认数据清洗、训练配置、评估链路都可靠再逐步扩大到完整规模。这个做法看起来慢实际上最快。行业模型的路子没有想象中那么神秘核心还是“数据训练评估”的闭环尤其是数据占了整个项目七成以上的工作量。希望这份实战指南能让你少踩几个坑把通用大模型真正调教成自己行业里的“老师傅”。