上个月陪一个制造业客户做项目评审对方技术负责人上来就问了一句通用大模型我们试了三个月回答设备故障诊断的问题还是像搜索引擎我们要的是老师傅脑子里的那套判断逻辑模型给不了。这个问题我太熟悉了过去一年里我见过太多企业买了几张 A100、拉了一个微调团队以为用几千条问答对做一遍 SFT 就能得到一个行业模型。结果模型确实会背几个标准答案了但只要问题换个说法、换个场景立刻就露馅。原因很简单你已经跳过了行业知识注入这一步而这一步叫 Continued Pre-Training。这篇文章我不打算讲花哨的框架也不做论文复读只把我自己团队从零开始把一个通用底座模型训练成行业模型的全过程、踩过的坑、以及那些容易在项目规划阶段被忽略的决策点讲透。无论你是在互联网公司做推荐、风控还是在制造业做设备诊断、工艺优化只要你想让通用大模型真正变成企业能用的行业模型这篇实战指南都应该能帮你少走几个月弯路。1. 为什么通用模型到行业模型绕不开 Continued Pre-Training1.1 通用模型在行业场景的三个尴尬瞬间通用底座模型的强项是知识面广、表达流畅、常识丰富但行业的真正竞争力往往藏在窄而深的知识里。拿制造业来说一台注塑机的工艺参数调整涉及材料流变特性、模具温度场分布、保压曲线设计这些内容在互联网公开语料里占比极低通用模型即便读过几篇论文也无法形成老师傅那种听声音就知道哪段保压时间长了的隐性判断。互联网行业其实也一样。你做电商搜索商品标题里的行业黑话、属性词之间的共现关系、用户从浏览到成交的转化链路这些业务知识并不会以规整的文本形式出现在 Common Crawl 里。模型可以陪你聊天但它不懂你的业务更不懂你业务里的那些潜规则。第二个尴尬是知道但不精确。我问过某个通用模型一个具体的行业问题某型号变频器在 50Hz 运行下IGBT 模块的结温估算公式里热阻系数一般取多少模型能给我一个看起来很专业的答案但数值范围宽到等于没说。这不是模型笨而是它训练数据里关于这个具体型号的工程手册太少缺乏精确记忆。第三个尴尬是稳定性差。通用模型今天这么回答明天换个 prompt 又是另一个说法。在企业生产环境里这种不确定性是不可接受的。你要的不是一个聪明的聊天对象而是一个稳定的、可被验证的行业助手。这三个尴尬总结起来就是行业知识密度不够、精确性不足、稳定性缺失。而 Continued Pre-Training 解决的恰恰是第一个和第二个问题它能从底层权重里注入行业知识而不是像 RAG 那样只做外部检索。1.2 RAG 能救一部分但救不了知识密度很多团队一上来就说要做 RAG把文档切块、向量化、检索增强感觉这样就不用动模型权重了。这个思路在市场落地初期没问题尤其是知识库问答场景RAG 的性价比很高。但 RAG 有三个天花板。第一检索质量上限受限于文档质量和切片策略。行业文档里大量知识是隐含在图表、公式和上下文中的切成向量块之后语义完整性经常被破坏。第二多轮推理能力弱。当问题涉及多个知识点的组合推理时检索回来的片段之间可能互相矛盾模型缺乏足够的领域知识去判断谁对谁错。第三延迟和成本。每次请求都要做向量检索加上大模型生成链路长了线上延迟和成本都上去了。RAG 适合做外挂知识库但如果你希望模型本身成为那个懂行的专家必须让知识进入权重。这就是 Continued Pre-Training 的定位它不是替代 RAG而是让底座模型先具备领域知识再配合 RAG 做实时信息补充。1.3 Continued Pre-Training 到底在训练什么简单说这一步就是用大量领域相关的纯文本数据在原有模型权重的基础上继续做自回归训练。它和从零预训练的区别是不需要从头学语法和常识只需要调整概率分布让模型更认为某个行业的知识是高频的。从数学上看目标函数仍然是下一个 token 的交叉熵损失[ L -\frac{1}{T}\sum_{t1}^{T}\log P(x_t | x_{t}; \theta) ]但和 SFT 不同我们喂给模型的不是问答对而是大段大段的行业语料工艺手册、检修记录、技术标准、专利摘要、高质量的研报、专家撰写的工作日志。模型通过海量重复出现的行业术语和知识模式把这些信息压缩到权重里。这个过程中模型的世界知识得到扩展而不是仅仅学会某种回答格式。这也是为什么我经常强调SFT 解决的是让模型学会怎么回答CPT 解决的是让模型知道这个行业是怎么回事。顺序不能反先注入知识再对齐格式。2. 项目启动前行业语料才是真正的护城河2.1 行业语料的来源清单与质量筛选标准很多团队找我咨询时开口就问训练参数怎么配、用多少张卡好像这些才是核心。但根据我的经验一个 Continued Pre-Training 项目是否成功80% 取决于语料而不是算力。先列一下我常用的行业语料来源企业内部文档设备维护记录、工艺卡、异常工单、质检报告、维修日志这些是外面拿不到的独家语料。行业标准与规范国标、行标、企标这些文本规范性强、信息密度高特别适合训练。专业书籍与教材注意版权尽量用已授权的电子资源。高水平论文与专利中文核心期刊、行业顶级会议论文、专利说明书专利文本的写法非常结构化模型能从里面学到大量技术方案。专家撰写的工作总结与技术博客这部分质量参差不齐需要严格筛选。社区问答数据比如技术论坛里高赞问答可以清洗成段落文本但要去掉口语化噪声。质量筛选标准方面我团队内部有一套打分逻辑核心看四个维度信息密度、权威性、时效性和格式质量。信息密度低的一律不要比如一篇介绍公司大事记的新闻稿全是人名和空话喂给模型只会增加噪声。另外要注意去隐私、合规。制造业的设备数据里可能包含客户信息互联网业务数据里可能包含用户隐私进入训练语料前必须做一轮脱敏和权限审查。2.2 清洗、去重、配比三个决定成败的动作数据清洗这一步最忌讳的就是直接拿爬虫抓下来的原始文本去训练。HTML 标签、乱码、重复段落、表格错位这些噪声会明显拉低训练效果。我见过一个团队清洗不彻底结果模型学到大量网页导航词生成的文本里动不动冒出点击下载相关推荐。我的标准清洗流程是统一编码和换行 → 提取正文 → 去除页眉页脚和导航 → 识别并修复表格/列表 → 繁简体转换 → 术语归一化 → 一轮人工抽检。去重是很多人忽略的环节。通用爬虫语料里同一个文档可能以十几种 URL 形式存在直接做 minhash 或 SimHash 去重是常规操作。但要注意行业语料往往是高价值、少样本过度去重会丢掉一些必要的重复。设备维修记录里大量故障现象描述很类似这些相似但不相同的文本恰恰是模型学习规律的关键不能因为 SimHash 相似度高就一刀切删掉。配比问题最重要。你千万不要把语料库做成 100% 的纯行业数据那样模型很快就会灾难性遗忘原本的通用能力。我的经验配比是通用语料或原模型训练数据子集占 60% 到 70%行业语料占 30% 到 40%。如果行业语料实在有限可以采用课程学习策略前 20% 的训练步数用通用语料稳定住模型基础能力后面逐步提高行业语料比例。2.3 需要准备多少数据才够一个可计算的估算方法准备多少数据才够这个问题几乎每次评审都会被问。两个企业客户一个互联网公司拿得出几十亿 token 的用户行为序列日志但不是文本一个制造业客户攒了三年才几千份有效文档。两者的答案完全不同。有一个实用的估算方法先确定你的总训练 token 预算再反推需要多少行业语料。公式不复杂[ 总训练token数 训练步数 \times 全局batch大小 \times 序列长度 ]举个例子你计划训练 3000 步全局 batch 是 32 条样本每条样本序列长度是 4096 token那么总 token 数大约是 (3000 \times 32 \times 4096 \approx 3.93) 亿。如果行业语料配比是 30%那你就需要大约 1.2 亿 token 的行业数据。这里有个容易算错的地方1.2 亿 token 不等于 1.2 亿个汉字。一个汉字大约对应 1.5 到 2 个 token这意味着纯中文语料需要大约 6000 万到 8000 万汉字。一个传统制造业企业要攒出这个量级的优质文档通常需要联合多间工厂的数据。如果你手上只有几百万字我建议谨慎启动数据量不足时优先考虑用 RAG 过渡而不是硬上 CPT。3. Continued Pre-Training 训练配置从 checkpoint 选择到超参调整3.1 基座模型选择和 checkpoint 恢复的正确姿势训练开始前选哪个基座模型决定了后续一大半事情的难度。我比较务实的建议是优先选开源生态成熟、中文能力强的底座比如 Qwen、InternLM 这些。不要一上来就选需要特殊授权或者权重文件都拿不全的模型因为 Continued Pre-Training 需要直接在原始权重上做优化器状态初始化封闭模型没法做。还有一个常被忽略的点尽量使用最终的、经过完整对齐的 checkpoint还是使用基座模型很多开源模型会发布多个版本有 base 版、chat 版、instruct 版。对于 Continued Pre-Training我强烈建议从 base 版本开始。因为 chat 版已经经过 RLHF 等对齐过程分布被拉向讨喜的方向你再喂行业语料两个分布会打架模型容易产生灾难性遗忘。Base 版本更原始可塑性更强。如果你只有 chat 版权重也不是绝对不能训练但需要把学习率调低一个量级并且在训练时混入更多的通用语料来做稳定。3.2 学习率、batch size、训练步数的推荐区间Continued Pre-Training 和 SFT 的超参配置逻辑完全不同。SFT 通常会用 (1e-5) 到 (2e-5) 的学习率而且训练步数很少几百步就够。CPT 则更接近预训练的微型版本学习率过高会破坏原有模型结构过低则学不进新知识。我团队在 7B 到 14B 模型上验证过的推荐区间如下参数推荐取值范围说明学习率(1e-5) 到 (3e-5)峰值设置在前 3% 步数AdamW 优化器14B 以上建议不超过 (1.5e-5)全局 batch size32 到 128序列长度 4096 时这批样本量足够稳定训练步数模型参数量的 1% 到 5% 总量对应 token7B 模型约 2000-5000 步数据少时可加大重复轮次warmup 步数总步数的 3% 到 5%防止初始阶段损失震荡序列长度2048 到 8192行业文档往往包含长上下文依赖推荐 4096我实际用的 7B 模型训练脚本大致长这样deepspeed --num_gpus8 train_cpt.py \ --model_name_or_path /models/Qwen2.5-7B-Base \ --train_data_path /data/industry_corpus \ --output_dir /models/industry-cpt-7b \ --per_device_train_batch_size 2 \ --gradient_accumulation_steps 16 \ --learning_rate 2e-5 \ --max_steps 3000 \ --warmup_steps 100 \ --lr_scheduler_type cosine \ --bf16 True \ --gradient_checkpointing True \ --logging_steps 10 \ --save_steps 500 \ --dataloader_num_workers 8需要注意梯度累积和 batch size 的换算。上面函数里per_device_train_batch_size2、8 卡、gradient_accumulation_steps16那么全局 batch size 是 (2 \times 8 \times 16 256)这个数值在 4096 序列长度下并不小。实际跑的时候观察 GPU 显存不要 OOM。3.3 灾难性遗忘的监控与缓解灾难性遗忘是 CPT 里我最头疼的问题没有之一。模型学到新行业知识的同时把原本的通用能力丢了典型表现是训练后模型不会写诗了、代码能力退化、甚至数学计算变差。监控灾难性遗忘最好的办法不是看训练集损失而是建一个通用能力测试集。我会在训练前后分别让模型跑几组固定的评测任务常识问答、代码生成、数学运算、通用对话流畅度。如果这些分数下降超过一定阈值就说明配比或学习率有问题。缓解手段我整理成三级方案第一级是配比调整。通用语料比例提到 60% 以上这是最廉价也最有效的手段。第二级是学习率衰减。如果检测到遗忘严重把峰值学习率降低一半或者使用 layer-wise learning rate decay让靠近输出层的层学得更少。第三级是回放。每训练 N 步就混入一些原本训练集的通用样本让模型持续复习旧知识。还有一种更轻的做法LoRA 微调。很多人不知道 LoRA 也可以用于 continued pre-training而不仅是 SFT。在 7B 模型上用 rank 64 到 128 的 LoRA 注入行业知识训练速度快很多而且几乎不会产生灾难性遗忘。缺点是知识注入的容量有限适合数据量在几千万 token 以内的场景。4. 互联网和制造业项目商业计划书侧重点为什么完全不一样4.1 互联网行业数据规模驱动、快速迭代、以线上效果说话在互联网公司做行业大模型项目商业计划书的逻辑通常是流量-转化-收入的闭环。数据是现成的用户行为日志、商品库、内容库都在那模型训练的语料获取成本低而且数据量往往非常大。这种情况下项目侧重点在于如何把产品问题转化为模型问题。比如电商搜索场景你需要先说清楚现有搜索的点击率、转化率瓶颈在哪里引入行业 CPT 模型之后相关性提升多少个点能带来多少 GMV 增量这些指标必须量化到能让业务负责人听懂的程度。互联网项目的另一个特点是迭代周期短。一个模型从训练到上线正常节奏是三到六周。商业计划书里必须包含明确的实验设计对照组怎么建、流量切分比例、评估指标怎么算、什么时候能拿到显著性结论。互联网业务方对模型上线这件事容忍度很低你需要在计划书里提前规划好灰度方案和回滚机制。数据合规也是互联网项目的重点。用户行为语料涉及个人隐私如果直接用原始数据训练模型法务这一关就过不了。商业计划书里需要单列一节讲数据脱敏方案、合规审查流程和数据生命周期管理。4.2 制造业知识壁垒驱动、数据稀疏、以专家验证说话制造业项目的商业计划书完全是另一套逻辑。核心不是快速迭代而是稳定可靠、可解释、可复用。制造业的数据量通常不大。一家工厂一年可能只有几千条有效的设备维修记录但每条记录的含金量极高背后是老师傅几十年积累的判断逻辑。这种情况下模型的目标不是记住所有文本而是从稀疏数据里提炼出可复用的判断规则。侧重点首先在知识工程。制造业项目在启动前必须做大量人工知识梳理故障现象怎么描述、原因类别怎么归纳、维修动作的标准术语是什么。这些工作不是算法工程师能独立完成的必须联合工艺专家、设备工程师一起做知识抽取和标注。商业计划书里要体现这个跨部门协作机制否则最后一定做成模型学了个寂寞。其次是验证方式。互联网可以用点击率做线上评估制造业没有这个条件。你的模型回答是否准确必须依赖领域专家评审。所以在计划书里要设计一套专家评估流程准备多少条测试问题、找几位专家打分、打分的维度是什么准确性、完整性、可解释性、安全性。这些都是制造业项目特有的内容。我在帮一家设备厂商做诊断模型时评估标准完全是老师傅点头才算对。模型生成一段推理过程老师傅发现它对工况条件的理解漏了一个关键前提那就直接判定为失败。这种评估方式很残酷但也很真实你的商业计划书必须提前确认这个现实。4.3 算力成本与 ROI 周期在两类项目中的差异两类项目的商业计划书在成本结构上差异极大很多从互联网跳去制造业的算法负责人在这里容易栽跟头。互联网项目算力成本相对可控因为数据准备流程高度自动化而且模型可以服务海量用户单位请求成本摊薄后很低。ROI 周期短通常两到三个月就能看到业务指标变化。商业计划书里可以大胆写投产比。制造业项目则完全不同。算力投入只是小头真正的大头是数据治理和专家时间。把老师傅从车间拉出来做一天知识梳理成本远高于一张 H800 跑一天的租金。ROI 周期也长得多少则半年多则一年以上。如果商业计划书里还照搬互联网那套三个月见效的预期项目进行到一半就会被砍。我见过最离谱的一份制造业商业计划书预算里 70% 是 GPU 采购只有 5% 留给了数据整理和专家咨询。结果模型训得很欢但语料质量极差最后产出的模型只能说一些正确的废话。正确做法是制造业项目预算里至少留出 30% 到 40% 给数据工程和专家协作。5. 别忘了 PPRM继续预训练之后的对齐与评测闭环5.1 PPRM 是什么Post-Pretraining Reward Model 的实践拆解训练完 Continued Pre-Training模型肚子里有了行业知识但这不意味着它能直接回答用户问题。你还需要对模型进行行为对齐让它知道面对具体问题时应该用什么格式、什么语气、什么边界去回答。我在实际项目中习惯把这一步简称为 PPRMPost-Pretraining Reward Model。PPRM 不是一个严格的学术名词而是我对这样一套流程的工程化总结先做少量高质量 SFT 把回答格式固定下来再构建一个领域偏好的奖励模型最后用 RLHF 或 DPO 做策略优化。很多团队只做了 SFT 就收工这在互联网场景下可行但在制造业等高专业壁垒场景下模型很容易一本正经地胡说八道因为没有奖励模型在背后约束生成质量。举个例子在设备故障诊断场景里模型可能生成一段十分流畅但包含严重事实错误的回答说是某型号 PLC 的通信模块故障但真正的故障原因是电源模块电压不稳。SFT 阶段如果只是简单模仿标准答案模型不会理解什么情况下答案是不可接受的。奖励模型就是用来学习这种好坏的边界。实现奖励模型的流程不复杂基于 CPT 后的模型用几百条人工精心编写的指令做 SFT生成领域回答的基准格式。让多个领域专家对模型回答打分标注维度包括信息准确性、逻辑完整性、安全性和格式规范。用标注数据训练一个 reward model这个模型可以复用语言模型的底座把最后一层改成回归输出一个标量分数。用 PPO 或 DPO 对主模型进行对齐训练让主模型学会输出更接近专家偏好的内容。PPRM 的价值在制造业场景里特别明显。因为制造业专家资源极其稀缺让模型直接生成 10 个答案再让专家挑比让专家手写 10 个标准答案要高效得多。奖励模型本质上是在复制专家的判断力把稀缺的专家时间沉淀到模型权重里。5.2 领域评测集怎么建才能不被感觉还行骗了评测是整个 CPT 流程里最容易被轻视的一环。训练过程中的 loss 下降只是必要条件不代表模型就真的变好了。我自己吃过不少亏所以现在对评测体系建设格外重视。领域评测集一定要单独从训练语料里隔离出来。我见过有团队直接用训练集里抽几条做评测结果模型 loss 低得漂亮一上线就被业务方骂因为模型根本没有泛化能力只是背了训练集里的标准答案。我的评测集建设思路是第一难度分层。先准备一批入门级问题考察模型是否掌握了基本术语再准备一批推理级问题考察模型是否能综合多个知识点进行判断最后准备一批对抗级问题专门注入干扰信息看模型是否会被带偏。第二评估维度分四类准确性、完整性、稳定性、安全性。准确性和完整性可以由专家打分稳定性的测试方法是同一问题改写 10 种不同说法看模型输出是否一致安全性则要重点测试模型会不会在缺乏工况数据时强行下结论。第三评测集数量不需要多但必须精。制造业场景一两百条高质量问题就足够发现模型的真实水平。互联网场景可以自动化程度高一些用线上反馈数据回流构造评测集。我建议每训练几百步就做一次中间评测不要等全部训练完再测。这样一旦发现问题可以及时回调数据配比或学习率避免浪费大量算力。6. 我在实际项目中踩过的坑和给你省时间的建议6.1 坑把所有行业数据一股脑灌进去结果基础能力崩了我第一次带 CPT 项目时收集了接近 20GB 的行业语料加上了所有能抓到的通用开源中文语料配比没细算直接开训。训到一半发现模型的中文写作能力明显变差连简单的诗词对句都不会了。后来复盘发现行业语料里大量设备运维记录存在非常强的句式模板模型学到了高频模式却把通用文本的多样性丢失了。解决这个问题的唯一办法是严格控制配比并且在训练全程持续监控通用评测指标。配比不是一句大概 7:3就完事了。不同行业语料之间的内部配比也会影响效果。比如制造业语料里维修记录和工艺手册的信息密度不一样如果维修记录占比过高模型会过度偏向故障诊断的表达方式。6.2 坑用 SFT 的惯性思维配置 CPT 的超参数很多从 ChatGLM 时代就开始做微调的工程师习惯了一上来就开learning_rate5e-5甚至1e-4。这个数值在 SFT 阶段可能没问题但用在 CPT 上损失函数会剧烈震荡模型权重被大幅改写很快就出现生成乱码的现象。我后来总结了一个经验法则如果你在 CPT 中设置的学习率大于模型训练时学习率的 10 倍基本就会出事。大模型的预训练阶段学习率通常在3e-4量级但那是从零开始在已有权重上继续训练学习率要缩小一到两个数量级。现在我们的标准配置是1e-5到2e-5而且一定要用 cosine 衰减到接近 0避免训练后期权重还在大幅度波动。6.3 坑只看困惑度忽略生成质量的飘忽不定训练日志里 PPL 在持续下降但测试生成的答案质量越来越飘两个问题明明很像一个回答非常精准一个回答完全跑偏。这就是典型的只看 PPL 的坑。PPL 衡量的是模型对语料的拟合程度和生成质量并不是简单的线性关系。行业语料里频繁出现的专业词汇和固定句式模型拟合得越好PPL 就越低但生成时模型可能把某个低频但关键的条件给忽略了。因此我现在的做法是 PPL 只作为参考指标真正意义上的训练停止条件由领域评测集上的得分决定。哪怕 PPL 还在下降如果评测集分数连续几个保存点没有提升就直接停止训练避免过拟合。6.4 省时间建议几件我后悔没早点做的事如果要给还没启动 CPT 项目的团队三句话我会说这三句。第一先把一个小的验证跑通再上全量数据。别一上来就 3000 步、几十万训练数据。我通常先拿 100 万 token、100 步训练出一个 mini 模型看看行业知识有没有注入进去同时验证数据清洗流程有没有问题。全流程跑通后再放大数据量和步数成功率会高很多。第二提前写好回滚和模型评测流程。CPT 训练失败不可怕可怕的是你没法快速定位是哪一步出了问题。建议把数据版本、模型版本、评测结果全部做记录形成可追溯的流水线。任何一次训练结束后你都能立刻回答这个模型和上一个模型比到底好在哪、差在哪。第三不要把算法工程师当全能选手。CPT 是一项需要数据工程师、领域专家和算法工程师紧密协作的工作。制造业尤其如此没有老师傅参与数据清洗做得再漂亮也是纸上谈兵。项目启动前就建立一个多角色协同机制比多买两张显卡管用得多。我现在每次接到新的行业 CPT 项目第一件事永远是跟业务方确认三件事语料有没有、评测标准有没有、专家时间有没有。这三样东西比任何训练框架都重要。技术层面的东西会越来越标准化开源社区已经帮你解决了大半但数据和知识工程的积累才是每个企业真正需要花时间去打磨的护城河。搞定了这些Continued Pre-Training 才会真的成为一个让模型脱胎换骨的利器而不是又一个烧钱的算法实验。