说实话接手企业大模型落地项目的团队十有八九都会问我同一个问题为什么通用大模型什么都懂一用到自己行业里面就不灵了答案不复杂通用大模型在训练时见过互联网上的海量文本但它没见过你们公司过去十年的设备故障记录、工艺文档、客服工单、行业专利和内部 SOP。它不知道你们行业里“过烧”“回潮”“流片”“圈层渗透率”这些词到底意味着什么。要解决这个问题最主流、最直接的手段就是 Continued Pre-Training持续预训练业内常简称 CPT也就是在通用大模型的基础上用行业数据继续做一次“预训练式”的学习。这篇内容我会把 CPT 从原理、数据准备、训练参数、评估方式到行业落地差异完整讲一遍。不讲虚的只讲能直接拿去用的东西。无论你是技术负责人、算法工程师还是刚接触大模型的业务方看这一篇基本能把“企业怎么把通用大模型训练成行业模型”这条路线图理清楚。1. 为什么通用大模型在行业里不好用CPT 要解决的本质问题要理解 CPT得先分清大模型训练的几条不同路线。大家平时听到的 Prompt Engineering、RAG、SFT监督微调、RLHF人类反馈强化学习解决的问题方向各不相同。CPT 常被混在微调里讲但它和微调根本不是一回事。1.1 从“读过万卷书”到“懂你们行”通用大模型像是一个名校毕业、读过海量书籍的年轻人。他的知识面确实广能聊历史、写代码、做翻译、谈物理。但如果你让他直接去处理你们工厂的设备点检记录他大概率会把“主轴温升异常”理解成“天气太热”把“跑冒滴漏”当成“加水太多”。因为他没见过这些词在你们行业里的真实语境。SFT 能教他“回答问题的格式”。你给他几千条问答对他学会了“用户问设备故障你应该先给故障代码再给处理建议”。但你问深一点比如“这个故障代码背后对应的历史维修记录有哪些共性原因”他就开始编了因为他脑子里没有这批数据。CPT 解决的就是这个问题。它让模型继续做“下一词预测”任务但这次喂给它的不再是互联网上的百科和新闻而是你们行业、你们公司的真实语料。通过大量重复暴露这些语料模型会把行业词汇、表达习惯、隐含关系逐步编码进自己的权重里。这个过程非常像新员工入职后的“沉浸式轮岗”——不是读一遍规章就完事而是在实际工作中反复接触、反复理解直到形成直觉。1.2 CPT 和 SFT、RAG 到底怎么分工很多团队会在方案选型的时候纠结我是做微调好还是上 RAG 好还是做 CPT 好这个问题其实问错了。它们不是替代关系而是不同层面的组合。RAG 是把知识放在外部数据库里问答时先检索再生成。优点是快、便宜、知识可以随时更新缺点是模型本身的“理解深度”没有变化。如果领域文本里的话术、逻辑链条、术语关系非常复杂仅靠检索片段去拼凑答案效果会比较生硬。SFT 是教模型“怎么说”。它改变的是输出格式、回答风格、任务范式。但 SFT 不会给模型脑子里塞进几千篇行业文档的深度知识。如果模型底层不认识这些概念SFT 只能让它在不认识的情况下依然硬着头皮给答案——这就是幻觉的重要来源。CPT 是教模型“懂什么”。它在权重层面沉淀领域知识。做完 CPT 的模型遇到行业问题时会表现得明显更“专业”能自然地使用行业术语能理解长文档里的逻辑关系甚至能隐隐约约学会一些模式识别。它没办法替代 RAG 的实时知识更新也没办法替代 SFT 的输出格式控制但它是地基是把一个“通用助手”变成“行业专家”的关键一步。1.3 什么情况下才需要 CPT不是所有企业场景都需要 CPT。我见过有些项目明明数据量只有几百条问答团队非要训练行业模型结果效果还不如直接调 Prompt。CPT 不是万能药它的使用场景比较明确你们有大规模、成体系的内部文档或日志数据规模至少在几千万 token 以上行业术语密集通用模型对专有名词的理解频繁出错业务场景强调对长文本的逻辑理解而不只是抽取式问答希望模型在特定领域内形成一定的“直觉”而不只是依赖外部检索。如果以上四条占了至少两条CPT 是值得认真考虑的路线。如果一条都不占那你大概率只需要做好 SFT 和 RAG 就足够了。2. 训练开始前的三件大事基座选择、数据工程和算力预算CPT 这个事听起来很酷做起来很坑。我参与过的项目里训练本身出大问题的其实不多绝大多数翻车都是翻在训练之前的准备阶段尤其是数据。这一节把三个核心准备工作逐一拆开讲。2.1 基座模型怎么选不是越强的模型越适合续训做 CPT 有一个前提你手里必须有一个可以合法修改权重的开源基座模型。闭源 API 模型没法做真正的 CPT最多只能做 Prompt 优化或者 RAG。所以第一步就是选基座。市面上的开源基座大致分两类一类是通用能力很强的“大而全”模型一类是某类语言或场景上更有针对性的模型。选基座的时候很多人会下意识挑“综合能力最强”的这其实是误区。CPT 是一项成本很高的操作如果基座本身对中文理解就偏弱你再怎么喂行业数据效果上限也不高反过来如果基座已经具备强大的通用推理能力但它的词表Vocabulary里根本不含你们行业的专有符号那续训时就会非常吃力。另外一个容易忽略的细节是词表与分词器的匹配度。制造业里常见的设备编码比如“PLC-03#工位-07#夹具”如果基座的分词器切分得很碎模型学习起来就会特别慢。处理办法有两个一是尽量选词表规模较大、对中文友好的基座二是在数据阶段对这类高频专有表达做一致性处理比如统一样式。不要指望模型能凭空学会乱糟糟的编码规则。2.2 数据工程CPT 里 90% 的工作量都在这里如果 CPT 训练的总工作量是 100%那数据准备至少要占 80-90%。这不是夸张。模型训练反而相对标准化真正决定效果的是你喂进去的语料质量。第一步是数据采集。行业数据的来源非常杂产品手册、维修记录、客服对话、质检报告、工艺参数表、专利文献、内部知识库甚至包括老员工手写的操作笔记。要尽量把这些数据统一汇总到一个标准存储里方便后续处理。第二步是清洗。这里有很多坑。最常见的问题是格式混乱比如 PDF 转出来带一堆换行符和乱码扫描件 OCR 出来错字连天。清洗不是简单去掉几个空格就行需要做的是去掉页眉页脚、页码、水印等无关信息纠正常见的 OCR 错误尤其是行业术语被识别错的情况把表格数据转成模型更易理解的文本描述而不是直接喂原始 CSV剔除明显低质量的内容比如全是乱码的文件、重复度极高的模板文档。第三步是去重。行业文档里重复率往往高得吓人。同一份操作流程可能在十几个版本的手册里出现稍微改了两句话就算一个新文档。如果不做去重模型会在这些重复内容上严重过拟合导致它记住的是重复的模板套话而不是真正的知识变体。第四步是构造混合数据。纯行业数据大量堆进去模型会快速“偏科”甚至在通用能力上大幅退步。经验做法是把通用数据和行业数据按比例混合常见比例在 7:3 到 9:1 之间具体取决于行业数据量。混合比例不是拍脑袋定的建议先做小规模实验观察模型在通用评测集上的退化程度来反推合理比例。2.3 算力预算一张表算清楚你要花多少钱CPT 的成本主要看三个变量模型参数量、训练数据量、训练步数。三者互相牵制。假设你要训练一个 70 亿参数的模型使用 1 亿条左右的行业数据约 10 亿 token用 8 张企业级加速卡在混合精度下大概需要跑几天到两周不等。如果是 130 亿参数以上模型数据量再翻倍那成本基本上是线性增长。更省钱的替代方案是参数高效微调比如 LoRA。很多团队会问用 LoRA 做 CPT 行不行答案是“能做但不是一回事”。LoRA 只在模型权重上挂一个低秩矩阵训练速度快、显存占用小但它对行业知识的“写入深度”有限。大型行业模型对知识的要求极高纯 LoRA 容易学个表面。折中方案是先用少量行业数据做短期的全量 CPT再用 LoRA 做后续的 SFT 和偏好对齐。这样既控制成本又能达到不错的效果。3. 实操环节CPT 训练的参数设计、过程监控与效果评估到这一节我们开始真正进入“实战”状态。很多人对 CPT 的理解是“把行业数据丢进去让模型继续 train 就完了”结果训出来的模型要么 Loss 降不下去要么效果还不如原版基座。这一节把训练过程中的关键参数和监控方法讲透。3.1 超参数怎么设学习率是重中之重CPT 和从零开始预训练不一样它是在一个已经收敛的模型基础上继续训练所以超参数的设计逻辑有本质区别。特别是学习率如果直接沿用预训练的学习率通常在 1e-4 这个量级模型会很快破坏原有权重表现就是训练集 Loss 降得很漂亮但通用能力崩得一塌糊涂。经验值一般是全量 CPT 的学习率设在原始预训练学习率的十分之一到二十分之一。以常见开源基座为例初始学习率取 1e-5 到 2e-5 比较稳妥。训练过程中使用余弦退火调度warmup 比例在 1% 到 3% 之间。批大小方面如果显存允许尽量把 batch size 拉大一些。批次太小会导致梯度噪声过大行业数据的学习不稳定。序列长度也要注意。行业文档往往很长如果模型的训练序列长度只有 2048那模型只能看到文档片段很难学到长距离的上下文依赖。建议在显存允许的前提下把序列长度提高到 4096 甚至 8192。但要注意序列变长之后训练时间会大幅上升要结合算力做取舍。3.2 防止灾难性遗忘通用能力回放与多阶段训练CPT 最经典的问题就是“灾难性遗忘”学一行、丢一行。原因很简单模型在行业数据上训练权重不断往行业知识方向偏移之前从通用语料里学到的知识就会被慢慢覆盖。应对策略有两个。第一个是通用数据回放。就是说训练数据里不能只有行业数据要混入一部分通用的、高质量的中文或英文语料。可以把它理解为“让模型定期复习通用知识避免完全偏科”。回放比例不要太低我通常建议至少保留 20% 到 30% 的通用数据。如果是行业数据特别多的场景通用数据比例可以适当下调但最好不要低于 10%。第二个是多阶段训练。不要一次性把所有行业数据都灌进去而是分成两到三个阶段先训核心的高质量数据再训边缘的长尾数据每个阶段之间留出评估时间。这样做的好处是如果第一个阶段效果不佳可以及时止损而不是等整个训练跑完了才发现模型已经“忘记”了自己是谁。我做过一个对比一次性灌入全部数据和分两阶段训练同样训练总量分阶段的模型在行业任务评测上能高 3-5 个百分点同时通用能力保持得更好。所以 CPT 这种项目宁可多花点管理成本也不要图省事一步到位。3.3 过程监控不能只看 Loss要看“领域困惑度”CPT 训练过程中大家都在看 Loss。但只盯 Loss 是不够的。行业语料里往往有大量重复模板和固定句式Loss 很容易被这些偏置拉低。更好的做法是额外维护一个小型的“评估集”这个评估集里包含两种数据一种是领域知识的持有集训练数据里绝不出现另一种是通用能力的抽样集。训练过程中每隔固定步数就在这个评估集上计算一次困惑度PerplexityPPL。领域评估集 PPL 下降说明模型确实在学习行业知识通用评估集 PPL 如果快速上升说明模型正在遗忘通用能力。两个指标交叉观察才能及时发现训练方向跑偏。另外不要迷信训练 Loss。我见过不少项目训练 Loss 降得很好但追问一些真实业务问题时模型回答依然没有可用的深度。根本原因是训练数据和真实业务问题之间的分布差异太大。所以有条件的话训练过程中就准备几十条真实的业务测试题每周人工过一遍模型回答比看任何指标都直观。4. 行业落地侧重点互联网行业和制造业的 CPT 项目到底哪里不同同一个 CPT 方法论放到不同行业做法和评价标准会差非常多。就拿互联网和制造业来说它们的“行业模型”看起来都是装在聊天框里的智能助手但背后的数据来源、部署方式、商业计划侧重点完全是两个世界的东西。4.1 互联网行业打法要快效果要直接互联网行业做 CPT 有一个天然优势数据密集且大多已经数字化。用户在平台上的点击、浏览、搜索、反馈、客服对话、评价内容都是现成的领域语料。所以互联网行业的 CPT 项目通常启动很快数据收集成本低训练周期也可以压缩得很短。互联网项目的商业计划侧重点通常在“效率”和“增长率”上。比如模型上线后客服人工介入率能不能降低 30%内容推荐场景里的点击率能不能提升 2 个百分点用户发帖的审核通过率能不能更智能地判断这些指标都是可以直接量化的。因此在做数据准备时互联网团队会更注重线上交互数据尤其是客服工单和用户反馈因为它们的业务价值直接可衡量。另一个显著特点是迭代速度。互联网行业模型不是训完一次就完了而是要按月甚至按周迭代。老用户会不断产生新的表达方式新业务会不断引入新的产品线所以 CPT 的数据流水线需要做得非常自动化。训练脚本、数据清洗流程、评测集管理都要能快速响应新数据接入。互联网团队通常会把模型部署在云上通过 API 对外提供服务弹性扩容能力是必须的。4.2 制造业稳定压倒一切私有化部署是刚需制造业的行业模型完全是另一套逻辑。制造业数字化转型的核心需求不是“让模型更会聊天”而是“让模型能理解和处理生产环节中产生的复杂知识”。这里的数据包括设备维修手册、故障代码表、工艺参数记录、质量检测报告、安全操作规范等。制造业项目的商业计划侧重点首先是“可靠性”和“投资回报率”。车间主管不会关心模型的回答有没有文采他们关心的是当设备报警时模型给出的处理建议是不是符合操作规范当工人上传一张零件缺陷图时模型能不能准确匹配到对应的历史案例。所以制造业对模型的准确率要求极高但对创新性要求不高。它不需要模型“创造”新的维修方案而是需要它把几十年的老师傅经验准确复现出来。部署方式上制造业几乎必然要求私有化甚至本地化部署。生产系统的数据非常敏感设备参数、工艺配方、客户订单这些数据流到外部云端是不可接受的。这就要求团队在模型选型阶段就考虑部署可行性模型不能太大推理延迟不能太高最好能运行在车间内部的服务器上。因此在训练阶段就要考虑模型压缩、量化等方案而不是一味追求效果。4.3 商业计划书之前的差异两类项目的核心价值表述完全不同我给几个做融资或内部立项的朋友看过不同行业的模型项目商业计划书差异非常明显。互联网行业的计划书会写数据飞轮效应、用户活跃度提升、运营成本降低、推荐转化率的增幅预估。通篇是growth逻辑核心假设是“模型用得越久数据积累越多效果越好”本质上是边际成本递减的网络效应。制造业的计划书里出现频率最高的词是降本、提质、增效、安全、合规。计划书里会明确算一笔账一套模型系统的建设成本是几百万元每年可以减少多少次非计划停机节省多少维修成本避免多少起安全事故。它更像是一个技术改造项目的投资评审核心诉求是可量化、可验证、可追溯。理解了这两种商业逻辑的差异你就知道为什么同一个 CPT 项目互联网团队的评估指标是“回答被采纳率”制造团队的是“对错率”和“是否可控”。不是谁高谁低而是行业的价值标准决定了你的模型必须为谁服务。5. 续训不是终点CPT 之后的对齐与“ppRM 模型”路线很多团队把 CPT 做完就急着上线结果发现模型确实“懂行业”了但它说话的方式、表达的逻辑、对安全边界的把握依然达不到可用标准。这很正常CPT 只是解决了“知识进脑子”的问题还差最后一步让模型学会用行业规范的方式把这些知识表达出来。这就是对齐Alignment要做的事。5.1 从续训到对齐为什么行业模型不能裸奔界面产品对外提供服务除了“会答”还得“答得对、答得稳、答得适当”。一个训练过的行业模型如果不对齐可能会出现几种情况它知道故障处理的知识但它可能用大段长文本把答案说得天花乱坠让工人抓不住重点它可能过于自信把一个推测性的方案说得像既定事实它还有可能被用户诱导说出不符合安全规范的建议。CPT 之后的对齐目标就是把这些“知识”装进“规范”的框子里。具体方式就是业内常说的 RLHF 或 DPO。而这就引出了最近社区讨论热度很高的一个概念技术群里常称的“ppRM 模型”。关于这个名字网上说法不太统一我个人倾向把它理解为 Post-training and Preference-alignment with Reward Model 的非正式缩写。说白了它不是某个新发明的模型架构而是一条训练路线在 CPT 完成之后继续用“奖励模型”来指导模型对人类偏好进行对齐。整个链路就是预训练Pre-training- 持续预训练Continued Pre-Training- 后训练Post-training- 奖励模型对齐Reward Model Alignment这套连招被不少人简化记成 ppRM 路线。5.2 奖励模型如何“教”行业模型守规矩奖励模型的核心思想很简单准备一批“问题-回答”对由领域专家人工标注哪个回答更好然后训练一个打分模型。这个打分模型学习到“什么是好的行业回答”之后再通过强化学习算法经典的有 PPO去优化对话模型让模型越来越倾向于生成那些能得到高分的内容。关键在于奖励模型的标准必须贴合行业场景。你不是在教它“通用语言通顺”而是要教它“是否遵守安全操作规范”“是否先给出结论再展开”“是否在不确定时明确承认不确定”。这些标注工作通常需要行业专家参与。我见过不少项目在这一步偷懒直接拿外部通用的奖励模型来对齐行业模型结果训出来的模型确实“态度好”但专业判断完全不对——因为外部模型根本不了解你们行业的对错标准。如果团队人力有限做不了大规模的人类反馈标注还有一个轻量替代方案规则奖励 可验证奖励。比如在制造业场景如果模型回答中包含“先断电再检修”这类固定安全步骤就给额外加分如果缺少其中的必要步骤就打回重训。这种基于规则判断的奖励模型成本低、可解释性强在垂直行业里的实用价值甚至比通用的人工反馈更高。5.3 更简单的对齐方式DPO 值得优先考虑不是所有团队都有资源跑完整的 PPO 强化学习流程。PPO 需要同时加载四个模型对话模型、价值模型、奖励模型、参考模型显存开销大训练不稳定调参难度很高。对于多数企业项目我更推荐优先尝试 DPODirect Preference Optimization。DPO 的思路很直接不需要单独训练一个奖励模型来做强化学习而是直接让模型在“好回答”和“坏回答”之间做对比学习。训练时需要的数据形式仍然是三元组问题、好的回答、差的回答但训练过程简单很多显存占用小训练也更稳定。很多实际项目里DPO 的效果不比 PPO 差多少但工程复杂度降低了一整个量级。从我个人的项目经验来看行业模型的完整训练链路应该是高质量的 CPT 打好知识底子再用 SFT 教会回答格式最后用 DPO 或规则奖励做偏好对齐。如果资源不够至少做掉前两步如果想把模型打磨成可商用的水平第三步绝对不能省。6. 常见问题与避坑技巧CPT 项目踩坑太常见了。这一节把我自己遇到过的、以及帮朋友排查过的典型问题整理成一个速查表每个问题都给到排查思路比泛泛而谈有用得多。问题现象可能原因排查思路训练 Loss 降不下去学习率过高或过低数据噪声太大先调整学习率再检查数据清洗质量看是否存在大量乱码Loss 降得很好但通用能力崩了通用数据回放比例不足提高通用数据比例或多阶段训练里加回放阶段模型输出总是套模板数据去重不彻底模板重复度太高做严格的 MinHash 去重把重复率降到 1% 以下常见问题上效果还不如通用模型测试集不合理或训练数据覆盖不足检查评测集是否有歧义句子补充更多真实业务场景数据行业术语回答错误分词器切分不合理或语料里术语格式混乱统一术语写法必要时扩展词表训练中途显存崩溃序列长度或 batch size 设置过高降低序列长度或开启梯度累积回答专业但过于冗长没有做对齐或对齐时未约束格式加入指令微调训练集里明确要求先给结论后展开模型在关键安全问题上胡说对齐阶段缺少安全规范的奖惩数据补充安全规则奖励数据或在奖励模型里加大违规惩罚权重6.1 容易被忽略的数据泄漏问题评估集和训练集如果来源相同测试成绩好看完全是自欺欺人。行业文档总会出现同一知识点的不同变体你以为去重过了其实只是文本形式不同语义上大量重叠。处理办法是评测之前用模型生成相似句做一次排重或者干脆把评测问题改成“人工新造的提问方式”而不是从文档里原样摘抄。6.2 模型不是越大越好要考虑推理成本训练完的大模型如果要真正落到业务里推理成本是无法回避的问题。制造业客户经常要求本地部署如果模型参数太大一台常规服务器根本跑不动。建议在项目一开始就设定一个“终端部署预算”倒推模型参数上限。常见做法是能力需求优先用 70 亿参数级别的模型承载不够再加检索增强或者把场景拆细尽量不要一上来就冲着 130 亿以上参数去。6.3 行业专家务必参与数据准备和评估这个坑我提过不止一次但还是要强调数据标注和评测环节行业专家不是可选项是必选项。很多项目组觉得让算法工程师去读几篇行业文档就能理解行业知识事实证明差距非常大。同一句“主轴异响”工程师可能觉得是噪音问题老师傅会知道这意味着轴承滚道很可能已经出现点蚀需要马上安排检修。这种隐藏在文字背后的行业经验只有从业者能准确标注和判断。一个靠谱的做法是在项目早期就邀请两到三位资深业务人员进入数据团队全程参与标注规范制定和评测集的回答打分。他们不用懂算法但在数据把关上的价值胜过十个算法工程师。我个人在实际操作中的体会是CPT 项目真的不是一次性工程。它更像是在给模型“办一个行业的长期居住证”今天办好了不代表明天永远有效。行业知识在变你们的业务流程在变客户的提问方式也在变。最理想的做法是把数据采集、清洗、训练、评估、上线、反馈收集这一整套流程做成一个可持续运转的流水线每隔一段时间就用新数据给模型做一次增量续训。凡是把 CPT 当成“训完就交付”的项目最后都会发现模型上线三个月后就开始跟不上业务节奏。把这个前言想清楚比任何训练技巧都重要。