实战：把通用大模型调教成行业专家)
最近不少做AI落地的朋友跑来问我同一个问题：手里的通用大模型明明能写诗、能聊天，但一用到自己这个行业里就“掉链子”——问它设备故障原因，它给你背一段百科全书；问它合同条款合规性，它绕来绕去就是不提关键风险点。问题出在哪？说白了，通用模型学的是全人类知识的“平均值”，而你要的是自己这片领域的“优等生”。想从“通用”走向“行业”，有一关绕不过去，就是今天要聊的这套东西：Continued Pre-Training（持续预训练，下文简称CPT）。
这个标题下的内容，适合谁？适合正在做企业大模型落地的算法工程师、技术负责人，也适合刚接触大模型、想搞清“微调和持续预训练到底啥区别”的学习者。我把做行业模型这件事从思路、数据、训练到部署，按实战流程拆开讲清楚。它解决的核心问题是：如何让模型在不大改底层能力的前提下，把你们行业的术语、规则、上下文逻辑真正“长进参数里”，而不是靠临时塞提示词去糊弄。
1. 为什么通用大模型到了行业里就变“外行”
1.1 通用模型在行业场景的三个尴尬现场
我先说三个常见场景，你感受一下。
第一个是面向政策条款的问答。你问通用模型“某地高新技术企业认定管理办法里，研发费用占比要求是多少”，模型能给你一个有模有样的回答，但条款编号是错的，比例是按其他省份的三年前版本背的。这就是典型的“知识过时+领域不精”。第二个是医疗场景，问“这组肺结节影像指标下，建议优先排查哪些方向”，通用模型会堆一堆通用健康建议，却不会基于专科诊疗指南给出分层处理逻辑。第三个是制造业设备运维，给模型一段设备运行日志，希望它定位故障根因，结果它把“主轴温度偏高”和“环境气温炎热”强行捆绑成因果关系，逻辑上通顺，但行业内看完全站不住脚。
这三个场景的共同点是什么？不是模型没有推理能力，是它压根没见过你们行业的“内部语言”。行业知识不只是几个名词，还包括行文逻辑、判断框架、默认前提、风险红线。这些东西散落在大量文档和真实业务数据里，通用大模型在预训练阶段没学过，后面你再怎么提示都不牢靠。
1.2 CPT 和微调（SFT）到底是不是一回事
很多人一开始接触的是 Supervised Fine-Tuning（SFT），也就是拿一批“问题-标准答案”对模型做监督训练。SFT 擅长的是让模型学会某种“回复格式”或“交互风格”，比如把模型调成客服语气、让模型总是先给结论再解释。但 SFT 有一个很要命的特点：它的数据量通常不大，少则几千条，多则几十万条，而且都是“问答对”。这种训练方式只会让模型在已有知识基础上调整“输出方式”，很难塞进去真正的新知识。
CPT 就不一样，它做的是在通用模型已经学会的语言能力基础上，继续用大规模纯文本语料做自监督学习。训练目标还是“预测下一个词”，但语料全是你们行业的文档、规范、真实报告。模型在这段时间里，会把行业词表、术语搭配、行文规则、知识关系一点点吸收进权重里。所以有个很形象的比方：SFT 是给一个刚毕业的大学生做岗前培训，教他话术和流程；CPT 是直接让他去业务部门轮岗半年，天天泡在真实项目里，熟悉行业逻辑。
这里我放一张对比表，方便你对照做技术方案时选型。
| 维度 | Continued Pre-Training | 监督微调（SFT） |
|---|---|---|
| 训练数据 | 大规模领域纯文本（文档、报告、语料库） | 小规模“问题-标准答案”对 |
| 学习目标 | 预测下一个词，吸收领域知识 | 学会指令跟随与输出格式 |
| 改变的内容 | 模型内部的世界知识和语义空间 | 模型的指令理解和回复策略 |
| 数据规模需求 | 通常是 GB 级以上，越多越好 | 千条到几十万条都有 |
| 典型耗时 | 数天到数周（取决算力和数据量） | 数小时到数天 |
| 单独使用的价值 | 能增强领域理解，但不能直接当问答助手 | 能变“听话”，但知识量没有实质增加 |
实际项目里，CPT 和 SFT 不是二选一，而是前后脚的关系。CPT 先把领域基础打牢，SFT 再教模型怎么把这些知识用问答方式吐出来。
1.3 什么阶段才需要上 CPT，先别急着跟风
CPT 听着很高级，但不是所有企业所有场景都需要。我见过不少团队，业务还没跑明白，先攒了一堆服务器要预训练，结果训完发现该回答错还是错，反而把通用能力搞退化了。
我的判断标准一般有三条，你对照一下。
第一，你的场景是否高度依赖领域内部知识？如果只是让人工智能帮忙写周报、做摘要、翻译，通用模型已经够了，不需要投入做 CPT。第二，你是否长期使用同一个固定场景的模型？如果是一次性活动，比如临时搭个客服机器人，用 RAG（检索增强生成）临时引用知识库成本更低。第三，你手上是否有足够高质量、成体系的领域语料？做 CPT 最怕的就是“数据凑数”，如果只有几十篇文档，训出来的模型基本白搭，甚至更差。
一句话：RAG 是“临时抱佛脚”，CPT 是“长期培养”。你要是想让模型真正成为这个行业的半个老师傅，且愿意在这个方向上持续投入，那 CPT 就是正确的路。
2. 项目整体设计：动手之前，先把这三件事想明白
2.1 圈定领域范围，别把“行业”想得太宽
“行业模型”这个词听起来很大，但落到实际项目里，你必须先把领域边界切出来。你做医疗，是做临床辅助决策还是医保控费？你做法律，是做合同审查还是裁判文书分析？不同子领域的术语体系、知识结构、判断标准相差非常大。模型在一个过宽的领域里做 CPT，往往每个方向都学个皮毛，单个任务上反而表现平平。
我的做法是先写一份“领域知识清单”，把业务方实际关心的知识点都列出来，再对照手头语料逐项打勾。比如做电力设备运维，清单可以分成四块：设备结构原理、历史缺陷记录、运维检修规程、故障案例库。每一块都对应一批文档，训练完以后评估也按照这张清单逐项测。这样既能控制数据范围，也能让老板和业务方清楚知道，模型到底学到了什么，哪些还没覆盖。
2.2 底座模型怎么选，不仅是看参数大小
选底座是 CPT 项目的第一个大决定，这里我给的策略是“三看”：看语言能力、看协议合规、看生态工具。
中文行业场景，我对 Qwen 系列和 DeepSeek 系列用得相对多，原因是这两个系列的中文语料占比本来就高，继续预训练时中英文混杂的问题会少一些。Llama 系列底子很强，但词表里中文 token 覆盖率偏弱，CPT 时你往往需要同时扩充词表，这会增加不少工程工作。另外一定要看模型的开源协议，很多模型只允许研究使用，商用需要额外申请，不要等产品上线了才发现授权链路有坑。
参数规模方面，我见过 7B 模型在单一行业场景做到可用，也见过 70B 模型训偏了没法收拾。没有绝对的“越大越好”，只有“匹配算力、匹配数据量、匹配场景复杂度”。如果你只有单卡 24G 显存，老老实实用 7B 或 13B；如果有整机多卡，再考虑更大的底座。这里的原则是：先把一个中小模型跑通端到端流程，再往上放大，成本可控得多。
2.3 评估体系要在训练前就搭好，别等训完了才想怎么测
这是我在项目里最深的体会之一，很多团队是模型训完了才开始手忙脚乱找测试题，结果测出来的指标说不清楚是数据问题还是训练问题。
我建议在启动 CPT 之前先建三套评估集。第一套是“领域知识填空题”，从行业文档里挖一些术语定义、参数范围、流程步骤，做成填空题或判断题，用来测模型“有没有把知识长进参数里”。第二套是“业务真实问答”，收集业务方日常问得最多的 200 个问题，由行业专家给标准答案，用来测模型在真实场景的可用度。第三套是“通用能力基线”，跑一些公开的常识推理、数学、代码题，用来监控模型有没有在 CPT 后被“训傻了”。
评估集不用一次性做得很大，核心是能重复使用。训练前先跑一遍基线，训练中每隔几个 checkpoint 跑一遍，训练后再跑一遍，你就非常清楚每一步对模型能力的影响。
3. 数据工程：CPT 成不成，七成看数据
3.1 语料来源与清洗规则
CPT 的数据来源可以很广，但质量门槛必须锁死。我常用的来源有这么几类：行业出版的标准规范（比如国标、行标）、企业内部的作业手册和流程文档、高校和研究院公开的领域教材与课件、经过脱敏的历史业务报告、以及有授权许可的行业资讯与论坛讨论。
这些原始语料进来以后，清洗是第一步，也是最枯燥但最不能省的一步。我一般会做这几道工序：去掉页眉页脚和重复段落，用 minhash 或向量相似度做全局去重；过滤掉乱码、图片裁剪后留下的半截文字；把明显的表格和列表结构化保留，因为行业文档里大量参数在表格里；最后一定要做敏感信息筛查，把身份证号、手机号、具体客户名称、内部项目代码这些信息提前抹掉，否则训练完的模型可能在回答中“复读”这些信息，那是妥妥的数据安全事故。
清洗完之后的数据要留一份“数据血缘表”，也就是每一批数据是从哪个文件夹、哪份文档来的。后面发现模型回答有问题，可以顺着数据血缘表去回溯是哪批语料引入了错误，这是纯靠玄学调参解决不了的。
3.2 领域数据与通用数据的配比
做过 CPT 的人都知道，只用纯领域数据是会把模型“训窄”的。模型疯狂学习行业文档，逐渐忘掉通用知识，最后变成只能聊行业的“偏科生”。所以我强烈建议在 CPT 数据里掺入一部分通用数据，充当模型老知识的“保鲜剂”。
我在项目里常用的配比是 4:1 到 5:1 之间，也就是每 4 份领域数据配 1 份通用数据。通用数据不一定要多高级，用公开的百科语料、新闻语料、网页语料都行，关键是让模型在训练过程中周期性回顾通用语言模式。如果你的领域数据本身比较少，比如只有 5GB，通用数据比例可以提高到 1:1，防止过拟合。
举个例子，假设你准备了 40GB 的医疗语料，你可以混入 10GB 的通用中文语料，然后总数据 50GB，做一个 epoch 或者最多两个 epoch。不要贪多，做多个 epoch 会显著加速过拟合，我在 7B 模型上试过，超过两个 epoch 后，领域能力提升已经基本停滞，通用能力却肉眼可见地往下掉。
3.3 合成数据：数据不够，怎么“无中生有”
行业语料往往严重不足，尤其是一些新兴领域，能拿到的有效文档可能就一两个 GB。这时候可以考虑用更强的模型来合成行业语料。
合成数据不是让大模型随便编，我总结了一套相对稳的流程：先把手头真实的领域文档做切片，抽取其中的关键概念和主题词；然后用一个能力更强的模型（比如更大的闭源模型或血缘更清晰的商业模型）基于这些主题写“科普式讲解文”，要求句式平实、知识准确；最后用规则和人工抽检把明显有幻觉风险的句子滤掉。合成的语料可以补充到训练集中，但比例我建议控制在 20% 以内，否则模型会学到生成模型那股“一本正经胡说八道”的味儿。
这里我得提醒一句：合成数据最大的风险是幻觉传染。母模型如果对某个细分知识点说了假话，学生模型会把假话当成真理牢牢记住，后面再改就难了。所以合成语料一定要留出足够的抽检比例，建议至少人工抽检 5%，哪怕只是快速扫一遍标题和开头，也能挡掉大部分明显错误。
4. 训练细节：参数怎么配、过程怎么盯
4.1 超参数配置参考
很多人微调时习惯沿用 SFT 的参数，结果做 CPT 直接“爆训”。这里我把一套我验证过、比较稳妥的 CPT 超参配置放在下面，供你参考。
| 超参数 | 推荐配置 | 说明 |
|---|---|---|
| 学习率 | 1e-5 到 2e-5 | CPT 学习率要低于 SFT，目的是小步慢走，别把原有能力冲垮 |
| Batch Size | 按显存能容纳的最大值设置 | 尽量大，让每个 step 的梯度更稳定 |
| 训练轮数（Epoch） | 1 到 2 | 多了必过拟合 |
| 最大序列长度 | 2048 或 4096 | 行业文档长文多，短序列学不到上下文关系 |
| Warmup 比例 | 3% 到 5% | 让学习率平稳上升，防止开局震荡 |
| 权重衰减 | 0.1 左右 | 帮助抑制过拟合 |
| 梯度裁剪 | 1.0 | 防止 loss 突然 spike 时梯度爆炸 |
学习率这块我要多说两句。CPT 是在已经训练好的底座上继续学习，学习率如果开得太高，模型会像失忆一样把原本的通用能力迅速破坏掉。我踩过最狠的一次是拿 5e-5 跑了一个 7B 模型，三个小时后困惑度确实在下降，但一跑通用测试集，分数直接掉了十几个点，那叫一个心疼。后来我把学习率压到 1.5e-5，同样数据量下训练时间翻倍，但通用能力几乎没受影响，领域效果反而更好。慢就是快，这句话在 CPT 里特别适用。
4.2 基于 HuggingFace 的 CPT 训练代码框架
现在开源工具有很多，最常用的路径还是基于 HuggingFace Transformers + Accelerate 或者 Deepspeed 来写训练脚本。如果你用的底座是 Qwen 或 Llama 系列，直接用官方代码稍作修改，把训练目标改成原生预训练目标即可。
我贴一段我用过的简化训练脚本（基于 transformers 的 Trainer）：
from transformers import ( AutoModelForCausalLM, AutoTokenizer, Trainer, TrainingArguments, DataCollatorForLanguageModeling ) from datasets import load_dataset # 加载底座模型和 tokenizer model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2.5-7B", torch_dtype="auto") tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B") tokenizer.pad_token = tokenizer.eos_token # 读取清洗后的领域+通用混合语料 dataset = load_dataset("text", data_files={"train": "data/train.txt", "validation": "data/val.txt"}) # 分桶并 tokenize，保持序列长度一致 def tokenize_function(examples): return tokenizer(examples["text"], truncation=True, max_length=4096) tokenized_dataset = dataset.map(tokenize_function, batched=True, remove_columns=["text"]) # 语言建模的 data collator，动态 mask data_collator = DataCollatorForLanguageModeling(tokenizer=tokenizer, mlm=False) training_args = TrainingArguments( output_dir="./cpt_output", per_device_train_batch_size=4, per_device_eval_batch_size=4, gradient_accumulation_steps=8, learning_rate=1.5e-5, warmup_ratio=0.03, num_train_epochs=1, logging_steps=50, save_steps=500, eval_strategy="steps", eval_steps=500, save_total_limit=3, fp16=True, deepspeed="ds_config.json", ) trainer = Trainer( model=model, args=training_args, train_dataset=tokenized_dataset["train"], eval_dataset=tokenized_dataset["validation"], data_collator=data_collator, ) trainer.train() resume_from_checkpoint=True这里几个关键点说一下。第一，DataCollatorForLanguageModeling 的 mlm=False 表示做的是自回归语言建模，也就是 CPT 和预训练一致；如果设成 True 那就变成 BERT 那种掩码语言模型了，不适用于 GPT 类底座。第二，deepspeed 配置我建议用 ZeRO-2，13B 以下模型基本上够用，能省不少显存。第三，训练时日志里除了关注 loss，还要看一眼梯度范数，如果突然冲高到 10 以上，说明该降学习率或检查数据了。
4.3 多卡并行与断点续训的工程要点
单卡跑 7B 的 CPT 不是不行，但数据量一大就要等好几天。企业项目里一般都会上多卡。我用得比较多的是 FSDP 和 DeepSpeed 两种方案，DeepSpeed 对新手更友好，配置起来直接套模板就行；FSDP 在异构卡多的环境里表现更稳。
断点续训一定要从一开始就打开，save_steps 设成固定步数，比如 500 步保存一次，save_total_limit 设成 3，防止磁盘被塞爆。续训的时候用 resume_from_checkpoint=True，Trainer 会自动从最近的 checkpoint 恢复。我吃过一次亏是训练第二天机器崩溃，重启后才发现之前没设 resume，浪费了一整天算力，打那以后我再也不敢省这一步。
还有一个容易坑到人的地方：多卡训练时的数据 shuffle 顺序。建议在预处理阶段固定随机种子，使得各卡的 batch 划分是确定的。否则你中途续训时，数据顺序变了，模型会看到一个跟之前不一样的“课程安排”，轻则增加额外 epoch 的震荡，重则影响最终效果。
5. 训练完成后：评估、对齐与部署
5.1 评估：别只盯着困惑度，业务盲测才是终审
CPT 训练过程中你会看到一个现象：train loss 在稳步下降，val loss 也在降，看起来一切正常。但 val loss 降不代表模型在真实业务里好用，它只能说明模型对这批数据的“预测能力”变好了。所以我强烈建议做完 CPT 以后，不要急着上业务，先在之前搭好的三套评估集上完整跑一遍。
领域知识填空题如果正确率明显提升、业务问答的专家评分过了及格线、通用能力基线没有大幅回退，那这一步 CPT 就算稳了。如果领域效果好了但通用能力掉太多，优先检查是不是学习率太高、通用数据掺少了或者训练轮数多了。如果困惑度降了但业务问答还是很差，那多半是训练数据和真实业务场景之间存在 gap，你训的内容覆盖不了真实问题，这时候要回到数据层面去补样本。
另外项目里我会专门安排一次“人工盲测”。把 CPT 前后的模型放在同一个 Web 页面里，让行业专家同时看两边的回答，但不知道哪个是旧模型哪个是新模型，按“知识准确性、逻辑条理、行业规范性”三个维度打分。盲测的作用是消除心理预期，有时候人是会倾向于觉得“花了钱的模型一定更好”的，盲测一上，真相立即水落石出。我经历过不止一次，专家评分出来，新旧模型差距微弱，这时候你就知道数据或训练配置还有问题，别急着开庆功会。
5.2 与 SFT 和偏好对齐的衔接顺序
CPT 训完的模型，本质上还只是一个“更懂行业知识但没有被教会对话格式”的模型。你直接拿它上线，它会像一台打字机一样给你续写段落，而不是回答问题。所以常规的企业落地链路是：CPT 完成后，再用一批准行业问答对做 SFT，把模型调成“问什么答什么”的形态；如果还需要控制回答的口吻、避免高风险内容，再进一步做偏好对齐训练（比如 DPO）。
顺序上我建议严格按 CPT→SFT→(可选 DPO) 推进。如果你把 SFT 放在 CPT 前面，模型在后续预训练阶段会把对话格式又冲淡掉，SFT 的成果就白做了。反过来，CPT 做完再 SFT，SFT 能很顺地继承已经内化的行业知识，训练量也不用太大。我在一个法律文本项目里试过，CPT 后只用了两万条问答做 SFT，效果就超过了之前十万条 SFT 的效果，这就是“先长知识、再学表达”的优势。
5.3 部署与推理优化：VLLM 上线，注意这几处细节
评估通过后的模型，我一般用 vLLM 做推理部署，吞吐量比原生 HF 推理高不少，尤其适合企业里多个业务同时调用的情况。
部署的时候有几个细节值得留意。首先是上下文长度，CPT 阶段如果用 4096 训练，部署时 max-model-len 可以先保留在 4096，贸然拉到 8192 或更长，很多基础模型是支持位置编码外推的，但如果训练阶段没专项训练，回答长文时可能会出现“讲到一半开始糊涂”的情况。我建议上线初期保守一些，稳定以后再逐步加长。
其次是 vLLM 的缓存命中率。企业场景里，用户的问题重复度很高，尤其是客服和运维场景。打开 vLLM 的 prefix caching，可以在处理高频问题前缀时大幅减少重复计算，显著降低首 token 延迟。实测在制造业问答场景里，开不开 prefix caching，高峰期平均显存占用能差 20% 上下，响应速度也有肉眼可见的提升。
显存不够的话可以配合 AWQ 或 GPTQ 做量化推理。一般 7B 模型量化到 4bit 后，在 24G 显存的卡上能很舒服地跑起来，效果损失在大部分业务场景里可以接受。但要注意：量化对模型回答的稳定性有一定影响，尤其是长文本生成时可能出现重复句子。上线前建议专门用一个长文用例集做一轮回归测试。
6. 常见问题与排查技巧
6.1 训练后通用能力明显下降
这是 CPT 项目里最经典的翻车现场。现象是：领域问答变好了，但模型忽然连“鸡兔同笼”这类小学数学都不会了，或者做简单代码补全时错误率暴增。原因通常是学习率太高、领域数据配比过重、训练轮数太多。
排查思路分三步。第一步，立刻把学习率降到 1e-5 以下，这是最直接的手段。第二步，检查领域数据和通用数据的配比，如果领域数据占比超过 85%，建议降到 80% 以下，把通用数据补上来。第三步，看训练日志，如果 loss 还在缓慢下降但通用测试集分数已开始跳水，说明该提前停掉了，不要恋战。我在项目里通常会设置一个“通用能力哨兵任务”，每几百步跑一次简单的通用能力测试，一旦分数跌破阈值就自动告警，这样不用等整轮训完才发现问题。
6.2 数据噪声放大了幻觉，模型开始一本正经编造术语
行业语料里通常带着各种非标准写法，比如同一台设备有三种叫法，同一个参数在不同部门文档里单位不一样。模型会把这种不一致当成“知识”学进去，回答时就会表现为同一个概念前后说法打架，甚至把 A 文档里的错误数字当成标准答案。
这类问题预防比事后修更重要。清洗数据阶段就要做两件事：一是术语归一化，把同义不同写的词统一成标准说法，比如“PLC 控制器”“可编程逻辑控制器”“Programmable Logic Controller”这类，训练前尽量统一成一种；二是数值单位校验，把明显不在合理范围的数据拦下来，比如一个写着“温度 9999℃”的断行数据，基本就是 OCR 识别错误，直接过滤。
如果模型已经训完并出现了混乱，可以试一次“专项纠正 CPT”：单独挑一批规范化的领域语料，用更低的学习率（比如 1e-5 以下）再做小步长训练，有概率把错误的模式压下去。但如果错误知识混得太多，可能就得回炉重做数据了，这也是为什么我一直强调数据清洗阶段多花一倍时间都是值得的。
6.3 困惑度降了，业务效果却变差
这个现象最迷惑人，因为从训练指标看你做的一切都是对的。我遇到过一例：领域语料困惑度从 12 降到 8，表现相当漂亮，但专家盲测时却发现模型经常在回答里引入一个训练数据里根本不存在的新概念，而且神情笃定。
排查之后发现是评估集和训练集出现了数据重叠。那批用于评估的业务问答，很多是从训练文档里直接改写来的，数据泄漏让指标虚高。解决方法是把评估集重新构建，彻底排除和训练数据高度相似的样本。另外也要检查是不是训练数据本身覆盖面太窄，模型在某几个知识点上“过于自信”，稍有相关性的问题都会强行往那个方向答。这时候要给模型补充更多元化的反例数据，让它知道哪些情况“不属于它管”。
6.4 超参数与硬件资源冲突
CPT 对显存的需求比 SFT 大不少，因为你要一次性把很长的一段文本喂进去，batch 又得尽量大。很多团队在启动前没算好显存，导致 batch size 被迫压到 1，训练稳定性很差。
我建议启动前用一个小样先做一轮“干跑”，把 batch size、梯度累积步数、序列长度、并行策略全部调好，再上全量数据。干跑时观察两点：一是显存占用是否在训练过程中缓慢上升，如果是，可能某个操作有内存泄漏；二是吞吐量是否合理，7B 模型在单张 A100 上，4096 序列长度时通常每秒能处理几十到上百个 token，如果慢到离谱，检查一下是不是 CPU 数据加载成了瓶颈。数据加载这块，别心疼内存，用 num_workers 多开几个进程预加载数据，实测能把 GPU 利用率从 60% 拉到 95% 以上。
最后按我的习惯，再分享一个实操技巧
一个项目启动前，我总会在正式训练之前做一次“最小化验证”，拿 1% 的领域数据和 1% 的通用数据，用真实参数跑几十步，确认 loss 在降、梯度范数正常、checkpoint 能正常保存、续训能恢复。这个流程看似浪费时间，实际上帮我挡掉过至少三次“配置错误导致白跑一整天”的灾祸。你说你配好了没问题，但等模型跑到第 800 步才发现数据路径配错，你已经浪费了几千元算力。先花 20 分钟做最小化验证，收益是最高的。
做 CPT 这件事，技术上没有想象中那么神秘，难点全在数据质量、配比耐心和对训练过程的感知上。希望这篇文章能帮你少走几步弯路，顺利把自家的大模型调教成真正的行业老师傅。
