企业如何把通用大模型训练成行业模型：Continued Pre-Training实战指南
手里已经有一个在通用语料上训练好的底座大模型，想让它真正懂自己行业的术语、流程、文档和业务逻辑，怎么办？很多人第一反应是调Prompt或者做微调，但在行业专有知识极度稀缺的场景下，真正起决定性作用的往往是Continued Pre-Training（简称CPT，继续预训练）。它跟微调是两码事，目的不是让模型学会“听话”，而是把行业知识直接写进模型参数里。这篇指南写给准备做行业大模型的团队，从数据工程、训练策略、评估体系到算力规划，把整个CPT流程的操作要点和踩坑经验完整梳理一遍。
先说明一点：CPT不是万能的。如果业务场景只要求“模型能引用内部知识库内容”，优先做RAG（检索增强）可能更省算力、更快上线。但当模型出现三种情况时，CPT就是绕不开的路：一是领域专有名词高频出现，但模型总是输出错误释义；二是行业文档涉及大量内部流程、设备型号、法规条款，模型完全没有概念；三是通用模型产出的文本风格跟行业规范差别太大，靠提示词拉不回来。判断标准也很朴素——拿一批真实业务问题去考通用底座模型，如果错误率明显高于可接受线，且错误集中在“知识缺失”而不是“理解偏差”，CPT就该提上日程了。
1. 开工之前，先想清楚三件事
1.1 锚定场景：CPT解决的是什么问题
CPT的本质是让模型在原有语言能力基础上，额外“读”完一大批行业语料，从而调整参数分布，让领域知识和表达习惯内化到模型中。它和指令微调（SFT）、人类反馈对齐（RLHF/DPO）分工完全不同。我用一个生活化的类比解释：CPT是送模型去行业对口专业读书，SFT是教它按固定格式答考卷，RLHF是训练它的职场礼仪。专业没学过，后面两个环节再努力也白搭。
在实操前，团队必须回答一个问题：“我们要做的行业模型，到底强在哪一维？”不同行业答案完全不同。比如互联网行业，可能是让模型理解产品后台的运营术语、用户分层逻辑、内容推荐机制；制造业里则往往是让模型掌握设备参数表、工艺路线、故障代码、安全操作规程。这两个场景看起来都叫“行业知识”，但数据形态、训练目标、评估方式都不一样。先把场景锚定清楚，后面每一步才不会跑偏。
1.2 明确边界：不是所有数据都该喂给CPT
刚开始做CPT的团队最容易犯的错，是把所有内部文档一股脑喂进去，觉得“数据越多效果越好”。实际上CPT对数据质量的要求比SFT更苛刻，因为SFT有输入输出对做约束，错了顶多单条样本无效；CPT是让模型在开放文本上学分布，混入大量低质量内容就是灾难。
我建议在动手前先做一道减法：把数据分成“必须学”“可以学”“不要学”三类。必须学的是行业核心知识，比如标准规范、设备手册、专业论文、内部流程文档，这些是模型目前完全不会的内容；可以学的是带有行业风格但对答案准确性要求不高的语料，比如行业新闻、论坛讨论，主要用于风格迁移；不要学的是纯通用内容、涉密信息、含大量个人隐私的数据，这些要么没有CPT增量价值，要么有合规风险。建好这个分类，数据预算和清洗重点就清晰了。
1.3 先算一笔经济账：CPT的成本有多高
很多企业管理层听到“预训练”三个字就紧张，觉得是不是要烧几百万。实际上，CPT跟从头预训练完全不同。从头预训练要训练几万亿token，CPT通常只需要训练几十亿到几百亿token的增量数据，算力开销低两个数量级以上。
拿7B-13B参数规模的开源底座模型举例，做100B token的行业数据CPT，用8张A100/A800显卡跑一到两周是完全现实的。更大的70B模型会把成本放大5-10倍，但也不是遥不可及。我实际测过的配置后面详细说。这里想强调的是，CPT的技术门槛主要不在算力，而在数据工程和评估设计。钱能解决的问题都不是大问题，数据搞不干净才是真的进退两难。
2. 数据工程才是真正的护城河
2.1 语料来源：从内部系统到公开语料的整合
行业数据的最大优势在“独有”，最大痛点也在这里——数据大多散落在公司内部系统，格式乱七八糟，权限流程绕来绕去。我做CPT项目时，数据来源通常分三路并行推进。
第一路是公开行业语料，包括行业白皮书、国家标准、技术论文、专利摘要、头部企业的公开技术博客。这类数据胜在质量可控、版权风险低，缺点是不够“内部”——同行业竞争对手的公开数据别人也能拿到，做不出差异化。第二路是公司内部知识库，包括产品文档、技术支持工单、测试报告、售后记录、FAQ库。这类数据是真正的壁垒，但需要法务和业务部门配合做脱敏和权限授权，前置沟通时间往往比技术处理还长。第三路是半结构化数据，比如生产系统的参数日志、质量检测报告、ERP系统里的工艺流程描述。这类数据通常不在“文档管理系统”里，而在业务数据库或Excel表中，需要写脚本抽取并转换成自然语言文本。
2.2 清洗与去重：数据决定上限，清洗决定下限
CPT的数据清洗比很多人想的要重得多。我的经验是，清洗阶段至少要处理五类问题。
第一，乱码与格式噪声。PDF抽取经常带出页眉页脚、断行乱码；Excel表格转文本容易丢列对齐信息；扫描件OCR后可能产生大量错误字符。这些脏数据如果不清理，模型轻则学出口语化病句，重则产生幻觉式错误。
第二，近似重复。行业文档的一大特点是“互相引用”，同一段标准内容会出现在几十份文档里。如果不去重，模型会对高频片段过度记忆，导致生成时整段“背课文”，泛化能力变差。去重推荐用两层策略：先用MinHash做近似去重，把相似度超过0.8的段落聚类；再用Bloom Filter或精确哈希做完全去重，确保完全相同的句子只保留一份。
第三，低质量内容过滤。可以用一个小的困惑度模型打分，把困惑度异常高的句子剔除——这些通常是乱码、多语言混杂或无意义重复。也可以用规则过滤，比如标点符号占比过低、数字占比过高、URL过多等特征。
第四，语义完整性检查。行业文档经常存在“表头孤行”“章节截断”问题，一句话没头没尾，模型学到的就是碎片化表达。通过句长分布、段落起止词规则，可以筛掉大量残片。
第五，敏感信息脱敏。姓名、手机号、身份证号、内部服务器IP、未公开的商业数据，都需要在清洗阶段做检测和替换。这一步不只是合规问题，更关系到项目能不能过内部审计。
2.3 数据配比：通用语料和行业语料的比例怎么定
数据配比是CPT里最容易被忽视、却对效果影响极大的参数。核心矛盾是：行业语料占比太低，学不到深度知识；占比太高，模型会迅速遗忘通用能力，出现典型灾难性遗忘。
比较稳妥的做法是采用“通用保底+行业递增”的配比曲线。初期可以按“通用：行业=7：3”起步，随着训练步数增加，逐步过渡到“通用：行业=5：5”甚至“4：6”。但这里有个前提：投入的通用数据最好也是经过筛选的，不是随便拿网上爬来的通用语料凑数。我试过在CPT中混入高质量通用数据，比如数学逻辑、代码、通用百科，不单能防遗忘，有时还能顺便提升模型的推理能力。
实操上还要注意“数据重复率”。行业数据量少，一轮训练往往要重复多遍（epoch>1），这和从头预训练的“single epoch”习惯完全不同。重复太多次模型容易过拟合，出现“背题”现象；完全只训一遍，大参数模型又可能没吃透。我通常的做法是行业数据控制在2-3个epoch，通用数据只训1个epoch，必要时用课程学习思路先易后难排序。
3. 训练实施的关键决策点
3.1 训练目标：用Causal LM还是加辅助任务
CPT最标准的训练目标仍然是自回归语言建模，也就是Causal LM loss，让模型根据前文预测下一个token。这个目标简单直接，对所有文本都适用，而且和底座模型的预训练目标一致，兼容性最好。
在此基础上，可以按需加两类辅助目标。第一类是领域掩码语言建模，类似T5的Span Corruption思路，随机屏蔽一段连续token让模型还原，适合专有名词密集的文档，能强化模型对领域术语的理解。第二类是“知识型指令混合”，把一部分结构化的知识库内容转换成“问题-答案”格式，混在CPT数据里一起训练。这种做法虽然本质接近SFT，但在CPT阶段少量混入（5%-10%），能让模型在学到知识的同时就初步建立“按指令输出”的条件反射。
需要提醒的是，辅助目标增加会带来训练效率和稳定性下降。如果团队是第一次做CPT，我建议先用纯Causal LM跑通全流程，后续再迭代加辅助loss。
3.2 超参配置：别一上来就激进
训练超参方面，我的经验是要“稳”字当头。以下是一套经过验证的起始配置，适配7B-13B模型：
学习率建议设在1e-5到5e-5之间。对比从头预训练动辄1e-4到3e-4的学习率，CPT的学习率要低一个量级左右，因为底座模型已经收敛，过大的学习率会破坏已有参数，加速灾难性遗忘。Batch Size方面，7B模型可尝试128-256的序列级batch（配合梯度累积），显存不够时优先保证梯度更新步数稳定在几百到几千步量级。序列长度推荐4096或8192。行业文档往往包含长段落上下文，太短的序列会让模型学不到跨段知识，实际效果会明显打折扣。
训练步数的判断，不要只看一个指标。我的经验是盯两条曲线：训练集loss和独立验证集loss。行业验证集loss持续下降说明模型确实在吸收知识；通用验证集loss如果快速上升，说明遗忘速度过快，需要回调学习率或提高通用数据比例。另外还有一个容易被忽略的信号——gradient norm。如果梯度范数出现剧烈锯齿形波动，大概率是数据里混进了异常样本，优先查数据而不是调超参。
3.3 训练工程：框架、并行策略和断点管理
训练框架选择上，中小规模团队不用重复造轮子。7B-13B规模用DeepSpeed或者HuggingFace Accelerate足够，配合ZeRO Stage 2甚至Stage 3，单机8卡A100/A800就能跑起来。65B以上大规模才需要考虑Megatron-LM这类张量并行框架，但复杂度会显著上升，不是第一优先级。
混合精度建议使用bf16。和fp16相比，bf16的指数位更宽，在长序列训练中不容易溢出，loss稳定性更好。NVIDIA A800/H800及以上卡都原生支持bf16。检查点保存间隔要按“失败成本”来定，一般每保存一个检查点不超过2-4小时训练量，否则一旦训练中断，重头再来的代价非常高。我自己的习惯是同时保存最新checkpoint和最近3个历史checkpoint，防止某个checkpoint本身已损坏。
监控体系要在训练启动前就搭好。至少记录四个维度：tokens consumed（总处理token数）、throughput（吞吐，tokens/s/gpu）、loss、lr。高级一点再加gradient norm和验证集指标。很多团队训练到一半发现loss异常，回溯时却没有历史日志，只能盲猜原因，这非常被动。
4. 评估体系：别只看loss，拿真实业务问题“烤”模型
4.1 构建双轨评估：通用基准防遗忘，领域基准验能力
CPT项目的评估，最忌讳只看训练loss。loss降了只能说明模型拟合了训练数据分布，不代表真实业务场景好用。我的做法是搭双轨评估体系。
第一轨是通用能力基准，用于监控灾难性遗忘。常用包括MMLU（多任务语言理解）、C-Eval（中文基础评估）、GSM8K（数学推理）、BBH（复杂推理）。这些基准在训练前先跑一遍底座模型，得到基线分数；CPT训练中每隔一定步数（比如每500-1000步）复测一次，追踪分数波动。允许小幅下降（比如2-3个百分点），但大幅滑坡就需要干预。
第二轨是领域评估基准，这是团队必须自己动手搭的关键资产。建议整理100-300道真实业务题，按能力维度分层：术语解释题检验知识记忆，场景分析题检验知识应用，流程规范题检验对内部规则的理解，格式生成题检验输出是否符合行业标准。这套题跑完，模型能不能上线，心里就有底了。
4.2 灾难性遗忘：从原因到武器库
灾难性遗忘是CPT最常见的坑。症状很典型：行业知识答得头头是道，转头问它“1+1等于几”开始胡说八道，或者通用对话能力明显变僵硬。
背后的机理是：模型参数空间是有限的，学习新知识必然要调整旧知识相关的参数。调整幅度过大，旧知识就被覆盖；调整范围太集中，新知识又学不进去。应对手段我在实战中验证过几个有效组合。
第一个手段是把学习率调低，这是最便宜的缓解方式。5e-5和1e-5之间往往就能看到通用能力完全不同的表现。第二个手段是数据配比里加大通用数据混入比例，前面说的“通用：行业=7：3”起步就是这个目的。第三个手段是使用重放（Replay）策略，把通用能力评测集的答案文本做成数据混进训练语料，让模型反复“复习”通用知识。第四个手段是参数高效微调，比如用LoRA做CPT，只训练低秩适配器，对原始参数的破坏远小于全参微调。尤其数据量不大（低于20B token）时，LoRA-CPT的性价比往往高于全参CPT。
4.3 领域评估参考框架：用pprm思路做过程管理
这里介绍一个自建的评估参考框架，我习惯叫它pprm——Pre-trained and Post-refinement Refinement Model，直白说就是“预训练加后训练精炼”的评估管理思路。它不是一个需要去网上下载的现成工具，而是一套把模型训练过程拆成“前评估-过程评估-后评估”三个阶段的框架设计。
前评估阶段，在CPT之前用底座模型跑通一遍领域评估集，记录哪些知识点完全不会、哪些答错但接近正确，形成一份“知识缺口清单”。过程评估阶段，每隔N步做一次小样本评测，不追求全量跑完100题，而是抽20-30道代表性题目，关注“新知识是否开始答对”和“旧知识是否突然答错”。后评估阶段，在最终模型上跑全量评测，同时新增对抗性测试——比如故意把行业术语拼错、把业务问题场景换掉，观察模型是否机械记忆。
在pprm框架下，互联网行业和制造业的项目侧重点会有明显差异。互联网行业的知识更新速度快、开放域问题多，评估要更侧重新知识注入后的“泛化迁移”能力，也就是模型能不能把学到的新概念迁移到没见过的问法上；制造业的知识体系相对稳定、封闭域问题多，评估要更侧重“精确记忆”和“一致性”，要求模型对设备参数、安全规范这类知识做到高精度复现，宁可保守也不许自由发挥。两套侧重点会直接影响评估题的出题比例和验收标准，强烈建议在项目启动时就明确下来。
5. 算力估算与训练工程实战
5.1 从token数反推开销：一套可套用的计算公式
算力规划是每个CPT项目都要面对的第一道数学题。这里给出一套可以直接套用的估算逻辑。
先说吞吐基准。以7B模型在单张A100/A800（80G）上做全参训练为例，序列长度4096、batch size适中的配置下，单卡吞吐大约在3000-4000 tokens/s。13B模型大约是2000-3000 tokens/s。这个数字会因为框架、显存、数据长度分布波动，但作为前评估足够了。
总训练时长 = 总token数 ÷（单卡吞吐 × GPU数量）。举例：数据总量100B token，8卡A800，单卡吞吐3500 tokens/s，那么总时长 = 100 × 10^9 ÷（3500 × 8）秒 ≈ 357万秒 ≈ 41天。41天跑一次实验确实太久，所以工程上要分段验证——先用5-10B token的小批量数据把全流程跑通，验证数据和超参没问题，再扩大到全量数据。小批量和全量之间的吞吐差距不会特别大，但排错成本相差数十倍。
5.2 训练中段的异常排查之路
CPT训练跑起来之后，真正的考验才开始。我总结几个高频异常和排查方法。
第一个场景：loss下降缓慢甚至不动。先看学习率是不是过低，很多框架默认的1e-5对人类反馈微调合适，但对CPT可能偏小。再看数据的格式一致性，行业文档抽取后常带大量重复前缀或特殊标记，模型学到的可能是“复制模板”而不是“理解语义”。再看数据的tokenizer效率，如果一句话被切成大量无意义片段，学习效率也会很差。
第二个场景：loss中途突然spike。除了学习率过大导致的发散，最常见的原因是数据顺序问题。行业数据按来源文件组织时，文件头尾往往有大量页眉页脚和重复模板，模型会突然遇到一批“异常分布”数据。解决方法是训练前做全局shuffle，并确保shuffle的粒度在文档级而不是token级。
第三个场景：验证集行业指标一直不涨。这时候问题通常不在训练，而在构建的评估集本身。我踩过的坑是评估题和训练语料高度重叠——模型背答案也能拿高分。重新设计评估题，把题目改成“综合多段知识才能作答”的问法，才能真正反映能力提升。
5.3 算力不足时的替代方案：从全参到LoRA-CPT
很多企业团队拿不到8卡A100这样的资源，但又有CPT的需求。我的建议是优先考虑LoRA-CPT。
LoRA（Low-Rank Adaptation）思路是在冻结原模型参数的前提下，插入低秩矩阵去模拟参数更新。用于CPT时，行业知识会集中在低秩适配器里，推理时可以灵活组合或卸载。优点是显存占用低、训练速度快，7B模型用单张24G消费级显卡也能跑起来；缺点是对“大量新知识注入”的表达能力不如全参训练。实测经验是：当行业增量数据在10-20B token以内，LoRA-CPT的效果已经非常接近全参CPT，而成本只有后者的十分之一左右。我会建议资源有限的团队从LoRA-CPT起步，等到验证了数据有效性和评估方法之后，再决定是否进行全参训练。
6. 行业落地观察：互联网和制造业的侧重点对比
6.1 互联网行业：知识更迭快，模型要能“追新”
互联网行业的CPT项目，数据往往来自产品文档、运营知识库、用户行为分析报告、客服会话记录。这类数据的特征是更新快、表达随意、内部黑话多。比如一个内容推荐团队想让模型理解“完播率”“CTR预估”“用户分层策略”，这些概念变化极快，甚至不同业务线有不同叫法。
互联网行业CPT的核心痛点有两个：一是“旧知识过期”快，模型训完三个月可能就有一批政策、功能或术语过时，因此数据更新机制比一次性训练更关键；二是“产品形态差异大”，同一个集团下不同App的术语体系完全不同，单一行业模型很难通吃。实际落地时，建议在CPT数据上按照“业务线打标签”，训练时使用可调节的tag控制不同业务线的知识权重，后续上新业务线时只需要增量补充语料，不必整体重训。
6.2 制造业：精确优先，模型要能“较真”
制造业的CPT项目场景完全是另一种画风。核心数据包括设备说明书、工艺参数表、质量检测标准、安全操作规程、故障诊断记录。这类数据对“精确性”要求极高——一个工艺参数记错、一个安全细节遗漏，都可能造成生产事故。
制造业CPT的语料处理有几个制造业特色问题：参数表转文本时容易丢失数值和单位之间的关联，需要通过结构化模板保留；操作手册中“必须、禁止、宜”等规范性动词含义完全不同，语料切分时不能粗暴截断；不同厂家的同类设备术语不一致，需要建立同义术语表，否则模型会混淆概念。
从评估角度，制造业的验收标准也跟互联网行业不同。互联网行业可以接受模型给出“多种可能答案”，制造业则要求“唯一正确且依据充分”。因此制造业CPT项目里，评估集除了常规问答，更建议加入“参数召回准确率”“安全条款引用准确率”这类量化指标，达标线也要定得更高。
6.3 项目立项视角：两个行业的商业计划书侧重点差异
考虑到一个CPT项目通常需要申请预算，这里把互联网和制造行业立项汇报的侧重点差异也展开说。互联网行业的商业计划书，核心叙事通常是“产品迭代效率”和“用户规模收益”——强调行业模型能缩短新功能上线周期、提高用户留存、降低客服成本，估值逻辑上更偏“增长故事”。制造业的商业计划书，核心叙事则通常是“降本增效”和“风险控制”——强调模型能减少质检漏判、缩短老师傅培训周期、沉淀老师傅流失后的经验资产，决策层更关心投资回报周期和事故率下降这类可量化的指标。
这两种侧重点会影响整个CPT项目的验收口径。互联网团队如果拿着制造业那套“精确率99%”的目标去汇报，业务方会觉得产品太死板不好用；制造业团队如果照抄互联网的“回答多样性”指标，生产部门会直接拒收模型。最稳妥的做法是项目启动前就跟业务侧达成指标共识，把“模型答得如何”翻译成业务听得懂的“效率提升”“风险下降”“成本节省”。
写在最后：几个值得记住的实战判断
CPT项目走完一遍，我最深的体会是：数据工程的时间永远比训练长，评估设计的重要性永远比想象高，而超参调优其实是最不占时间的环节。很多团队第一次做CPT失败，不是因为算力不够，而是因为数据没洗干净就开跑、评估集没搭好就上线、一看到loss下降就以为万事大吉。
最后分享一个小技巧：任何CPT项目，都建议先拿“小模型+小数据”把流程打通。拿1.5B或3B模型配10B以内的数据，跑通数据清洗、训练、评估、部署全链路，再放大到7B/13B全量数据。小规模验证虽然不能完全等比例预测大模型效果，但能提前暴露90%以上的工程问题，这个时间花得绝对值。行业大模型的路上没有银弹，CPT只是其中最值得投入的一段路，希望这篇指南能让你少踩几个坑。
