国内做行业大模型的朋友最近聊得最多的话题已经不是“要不要做”而是“怎么做才能让模型真的懂行”。拿通用底座直接上对话微调出来的东西经常是表面顺滑、一深入问就露馅——行业黑话半懂不懂、内部规则一问三不知。这里面的关键差距往往不在微调那一步而在更早的Continued Pre-Training继续预训练简称CPT。这篇实战指南就是把这条技术路线从头到尾拆开讲清楚企业到底怎么把通用大模型养成本行业的模型包括数据配方、训练参数、评估方法和我实际踩过的坑。先说清楚适用对象你可能是企业的算法负责人、独立开发团队的工程师或者刚被老板点名“一个月内搞出行业大模型”的技术骨干。只要你有基础GPU资源哪怕是几台4090或者几张A100想做法律、金融、医疗、制造等领域的私有化模型这篇文章就能直接当操作手册用。1. 为什么多数企业卡在“模型不够懂行”这一步1.1 通用模型的通病知识面广但深度不够通用大模型被训练出来的目标是“什么都懂一点”这决定了它在任何一个垂直领域都只能是浅尝辄止。比如你问一个通用大模型“应收账款保理合同里的追索权条款有哪些标准写法”它可能给你生成一份看起来合理、但细节完全不符合国内商业保理惯例的文本。这不是模型笨是它的预训练语料里保理合同相关的原文本身就很少而通用语料里的合同知识又被各种低质量网络文本冲淡了。很多团队的误区是既然模型回答得不够专业那就用几百条人工问答数据做一次SFT监督微调让模型“学会”回答。这个思路对简单指令有效但对需要深度知识的场景收效甚微。为什么因为SFT学到的是“回答形式”比如“你要先分析、再给出结论、最后给建议”但模型本身脑子里没有足够的领域知识储备你再怎么调它的回答风格它也变不出它没学过的东西。1.2 继续预训练和微调的边界一个改知识一个改行为我接触过的企业客户里至少有一半分不清CPT和SFT的区别。用一个不严谨但很好理解的类比预训练就像一个人从小到大读书学习积累知识SFT则是教他在考试时怎么答题、用什么格式写答案。如果你指望这个人考试考得好前提是他得读过足够的书。CPT干的正是“补读书”这件事——把大量的行业书籍、合同文本、政策文件、技术规范等按预训练的方式再喂给模型让模型真正把这些知识吸收进参数里。所以技术路线上标准的行业大模型训练流程是通用底座 CPT注入行业知识 SFT对齐问答格式 可选RLHF/DPO对齐人类偏好。CPT是整个链条里最基础也最容易出错的一环但市面上讨论得最少。大家一窝蜂都在讲“怎么微调”却很少有人讲清楚“微调之前你应该先做什么”。1.3 行业模型的技术路径选型三个层次要对号入座企业在启动CPT之前得先摸清自己属于下面哪种情况不同情况的方案差别非常大知识型行业模型如法律咨询、医疗问答、金融投研核心痛点是专业术语、领域规则、行业惯例CPT是最关键的一步数据量要求也最高。任务型行业模型如客服自动应答、信息抽取、文档解析核心痛点是输出格式和行为模式可以在通用模型基础上直接做高质量SFTCPT只是锦上添花。专有数据大模型如企业内部文档、专属代码库这是CPT最容易见效的场景因为你的专有数据是通用模型百分百没见过的新知识喂进去的效果立竿见影。看清楚自己属于哪个层次再决定CPT的投入量级。最怕的是团队不做判断盲目囤一堆领域数据就开始跑训练最后发现模型知识是涨了但通用能力崩了业务场景里用起来反而更差。2. 继续预训练的数据配方90%的成败在进训练前CPT这个事真正进入训练阶段其实技术含量并不高——用开源框架加载大模型喂数据跑起来就行。难点和成败关键全在数据上。我甚至跟朋友开玩笑说CPT是“数据工程占90%、训练工程占10%”的活。2.1 行业数据从哪来清洗流程和实操要点行业数据的来源非常杂合同文本、政策法规、科研论文、技术标准、专利文档、物流单据、病例报告、生产记录……每种格式要处理的方式都不一样。我以一个法律行业CPT项目为例梳理一份可以直接拿去用的数据清洗流水线原始文件解析。PDF文件用版面解析工具开源的有PyMuPDF、pdfplumber抽取正文遇到扫描件就得上OCR。这里有一个大坑扫描件的识别质量直接决定后续训练质量OCR错误率高的话等于喂给模型一堆带噪声的乱码。我建议按版面区域分别抽取标题、正文、页眉页脚分开存页眉页脚信息直接丢掉。编码清洗。去掉控制字符、全半角统一、修复乱码括号、处理特殊空白。中文数据经常出现“中文引号被转成英文引号”“全角逗号变半角”这类问题统一成规范标点很重要。语言过滤。按实际场景判断是否需要保留多语言。绝大多数行业模型只需要中文可能加一点英文术语其他语言删掉。用语言检测工具按段落打分分数低于阈值的段落直接丢。文档级别的维度去重。很多行业语料是同一个文件在网络上有不同版本比如同一份国家政策在不同网站上转载内容略有差异但从训练角度看就是重复数据。重复过多会导致模型对这部分内容过拟合对话时容易“背题”。用MinHash或SimHash算法做文档级去重阈值一般设在0.7-0.8之间也就是说两个文档相似度超过70%就只保留一个。隐私与合规筛查。这一步不能省。用正则匹配身份证号、手机号、银行卡号等PII信息是真实数据就脱敏或者整段删除。法律、医疗领域尤其严格别图省事直接把原始病历或合同灌进去出了合规问题整个项目就黄了。2.2 高质量过滤怎么判断一段行业文本“值得喂给模型”原始清洗只是去掉垃圾接下来更重要的是“选精华”。不是所有行业文本都适合做训练数据低质量文本不仅无益反而会拉低模型输出的质量。我常用的做法是先用分类器给文本质量打分分几个维度信息密度有没有具体的数据、案例、条款、流程步骤水话太多的不要。专业性是不是围绕行业核心知识的干货内容新闻报道和纯评论性的内容比例要控制。完整性段落是否完整有没有因为解析问题导致前后文断裂。结构特征带小标题、项目符号、枚举结构的文本通常质量更高更适合模型学习结构化知识。实操时可以请领域专家标注几百条数据然后训练一个lightGBM或简单微调一个小BERT模型做分类器对海量候选数据批量打分只保留分数Top 30%-50%的内容。这个步骤看着简单实际收益很大能把最终训练效果拉开一个档次。2.3 数据配比领域知识、通用语料、代码各占多少数据配比他直接决定你的模型训练出来是“懂行且正常”还是“偏科且犯傻”。常见误区是只灌领域数据结果模型的通用语言能力剧烈退化。原因很好理解CPT期间模型的所有参数都在更新如果只有法律数据模型对日常语言的理解和生成能力会逐渐被覆盖掉。行业数据里有大量长尾表达模型会把它们放大反而忘了通用表达。根据多个开源模型在领域适配时公开的经验我一般推荐这样的配比数据来源比例说明行业领域数据40%-60%核心知识来源质量优先通用中文语料20%-30%保持中文语言能力和常识降低灾难性遗忘英文技术/论文语料5%-15%行业里涉及英文术语和前沿文献时有用代码数据5%-10%提升逻辑推理能力对法律、金融的案例分析也有间接帮助通用问答对3%-5%保留模型的问答交互能力防止变成“哑巴”这个配比不是绝对的我发现一个经验曲线领域数据从30%提高到50%领域评测分数涨得最快超过60%之后通用能力掉的速率显著加快而领域分数涨幅趋缓。如果模型底座中文能力本来就不强通用语料的比例得再往上提。注意训练数据里一定不要混入SFT用的问答数据除非你在做的是SFT而不是CPT。CPT阶段喂结构化问答对模型会把“回答问题”也学成一种无意识的模式影响后续指令遵循。2.4 数据量级究竟要多少才有效果“老板让我拿5000条数据做个行业大模型”这类需求我见过不止一次。说实话5000条文本对于CPT来说远远不够。CPT本质是学习文本的分布数据量太小时模型什么都学不到。基于我在不同项目和公开技术报告里的观察一个粗略的经验数据量范围领域数据在1亿token以下CPT效果微弱几乎只相当于让模型“看了一眼”。3亿-5亿token是一个比较合理的起步区间在这个量级能明显感受到模型对术语和领域常识的掌握有提升。10亿token以上同时配比得当模型会在领域文本的流畅度和专业度上表现出接近“吃过这碗饭”的水准。当然token多少更准确地取决于你能使用的算力。一张A100 80G的卡大概能存下7B左右的模型每天能训练约5000万-1亿token3亿token大概要跑3-6天。不是大厂预算的企业至少得有几张卡并行才值得启动一个正经的CPT项目。3. 训练实操参数、Loss观察与检查点恢复数据准备好了终于可以开始训练。这个阶段相对“机械”但对工程细节的把握会直接影响项目能不能顺利跑完。我将自己的训练脚本和参数配置踩过的坑整理出来。3.1 超参数设定逻辑这些数字背后的原理CPT调参跟SFT有很大不同。SFT的学习率一般可以开到1e-5到2e-5因为模型只是学“输出格式”迭代次数还很少。CPT要让模型大规模吸收新知识但又不希望把已有知识冲得太乱学习率要保守得多。我习惯的起点配置是参数推荐值理由学习率1e-5到3e-5线性衰减太低学不进去太高遗忘严重批次大小128-512按动态batch大batch让梯度更稳定但显存压力大序列长度2048-4096行业文档经常需要长上下文短了学不到完整逻辑训练轮数1-2 epochs行业数据重复过多次会过拟合优化器AdamWβ10.9, β20.95大模型训练的标配权重衰减0.01-0.1防止参数过于发散Warmup占训练总量1%-3%稳定训练初期序列长度有一个容易被忽略的重要点很多开源底座虽然宣称支持4K或8K上下文但它们在预训练时实际上用的是更短的序列比如2K你用8K长度去继续预训练位置编码外推的风险会出现。最稳妥的办法是如果你的底座原生支持的长度是2KCPT阶段就使劲儿往3K-4K推但别一上来就8K。想延长有效上下文的话有专门的办法而不是硬拉。另外批次大小的设置需要跟学习率联动。超参数经验法则或者叫linear scaling rule是batch size翻倍学习率也翻倍。3.2 训练目标的取舍不要全都mask掉用全token学习继续预训练有两种常见目标一种是只对随机mask掉的token做预测MLM风格另一种是像GPT那样对所有token做自回归预测LM风格。LLM底座的CPT我建议直接沿用全token的自回归目标即每个token都参与loss计算。原因是LLM本身就是这样预训练的继续沿用可以更好地保持模型的语言特性。MLM主要适合BERT这样的编码器模型对生成式LLM收益不大。实操中一个细节如果你的行业文档里有大量结构化短文本比如条款列表、产品参数表可以适当提高这些短文档的采样权重因为大语言模型自回归loss在长文本上分摊后梯度贡献会被稀释。3.3 训练中看什么不要只看总loss要拆开看训练过程中我强烈建议你记录并实时监控以下几个指标而不是只盯着终端里打印的总loss总loss整体loss应该平稳下降如果下降太快或者跳变成负数大概率数据清洗有问题。按数据源拆分的loss分别计算行业数据、通用数据、代码数据各自的loss。实操中可以每隔固定步数抽出各个数据源的一个小batch单独跑前向记录loss。这能帮你判断训练是否均衡。梯度范数梯度范数突然异常增大可能是某个batch里包含了异常文本容易导致训练崩掉需要早点发现。验证集困惑度PPL选一份固定不变的行业验证集每500步算一次PPL。PPL下降说明模型在真正学进领域知识。我自己在训练7B模型时通常用Deepspeed ZeRO-2或ZeRO-3配合HuggingFace的Trainer即可。关键在配置里要设置gradient_checkpointingTrue来节省显存同时gradient_accumulation_steps来控制动态batch大小。下面是一份可以抄作业的Trainer训练配置PyTorch HuggingFacefrom transformers import ( AutoModelForCausalLM, AutoTokenizer, Trainer, TrainingArguments ) model AutoModelForCausalLM.from_pretrained(your-base-model) tokenizer AutoTokenizer.from_pretrained(your-base-model) training_args TrainingArguments( output_dir./cpt_checkpoints, per_device_train_batch_size1, gradient_accumulation_steps64, # 动态batch1*64*卡数 learning_rate2e-5, num_train_epochs1, warmup_ratio0.02, lr_scheduler_typelinear, logging_steps10, save_steps500, save_total_limit3, remove_unused_columnsFalse, fp16True, # A100可换bf16 gradient_checkpointingTrue, deepspeed./ds_config.json, )3.4 检查点中断恢复训练三天后崩溃是怎么救回来的大模型训练动不动跑几天中间断掉是常态不是意外。节点宕机、显存OOM、网络中断可能导致训练进程直接退出。如果你ArcFace不设置自动保存一天的进度就白费了。我踩过最痛的一次一个7B模型在8卡A100上跑了两天多结果因为一个数据样本太奇葩loss爆掉训练崩了。幸好我设置了save_steps500每500步存一个checkpoint最后只丢了不到十分钟的进度。恢复训练注意两个关键点随机状态恢复Trainer在恢复时用train_from_checkpoint参数指定checkpoint路径它会自动加载模型、优化器和调度器的状态。如果你用的是自定义训练循环记得把torch.random、DataLoader的generator状态一起保存和恢复。由于loss spike中断的情况先别急着恢复训练把崩溃附近的loss曲线调出来定位到是哪一类数据导致的问题然后在数据里把那个异常样本找出来清洗掉等数据确认没问题了再恢复训练。4. 评估量化“懂行业”和“没变傻”训练完成之后最怕的就是“感觉好了但拿不出证据”。在企业里做技术项目评估体系没搭好后面上线、汇报、迭代全都被动。我推荐三层评估法每一层解决一个问题。4.1 行业能力评测集怎么建把业务问题变成考题第一层是行业知识评估。很多团队喜欢直接用现有公开benchmark来测比如法律用JEC-QA、医疗用CMB这些数据集成熟、可比性好但跟你的实际业务场景未必匹配。我更建议重点构建一个“业务场景小评测集”从客户历史对话、工单记录、销售反馈里挑出50-200个真实业务问题。请业务方写出这些问题对应的标准答案要点不需要逐字逐句要点对即可。训练完成后用同一批问题让底座模型和CPT模型分别回答再对答题结果打分。打分有两个维度专业准确性答案里有没有明显的知识性错误和切题度有没有正面回答问题而非绕着说。业务方打分可能不精确但是比纯速度评测更有说服力。实操经验50个问题可能不够因为提问方式变化会导致评分波动至少准备100个问题并且固定“标准提问版本”。同时评测数据本身要做隔离千万不能混进训练数据——后面第五节会讲数据泄露的坑。4.2 通用能力回退检测用公开benchmark做“安全网”第二层是看通用能力有没有崩。因为CPT的过程把领域数据灌进去模型的通用语言能力、推理能力、常识理解力都可能被冲淡。用来检测通用能力的常用指标包括MMLU涵盖STEM、人文、社科等是衡量通用知识广度的基准C-Eval中文通用知识与推理GSM8K数学推理能力HumanEval代码生成能力如果代码对你重要BBH大模型推理benchmark实操中我会把焦点放在MMLU和C-Eval上两者各抽一个子集跑一次。如果CPT之后MMLU分数下降超过3个百分点就说明通用能力回退严重需要回炉调整数据配比。通用评估也要看“回退的方向”。有些下跌是可以接受的比如你对模型的主要目标是做行业问答那么它在GSM8K上从75跌到73其实无所谓但如果在MMLU的常识部分从80跌到70就要警惕了。判断哪些能力是底线由你的业务场景来定义。4.3 业务场景的最终验证让模型“真干活”看效果前两层评估都是静态打分最后一步要放到真实生产环境里做Shadow Test影子测试。把模型接进一个内部demo让真实的业务人员用它回答真实问题收集反馈。这一步的核心价值是暴露“评测集漏掉的问题”。我遇到过一个案例模型在行业知识评测里分数很高但真实使用中用户发现它“在回答法律条款时经常态度非常笃定地给出错误建议”。这个问题在演示阶段完全暴露不出来只有放到真实场景、让用户带着挑刺心态去试才能发现。应对手段就是加一个“模型认知边界”的训练信号让模型在自己不确定的时候学会说“需要进一步核实”这个可以在后续的SFT/RLHF阶段解决。影子测试注意留出2-4周的时间窗口因为不同季节、不同业务周期的真实输入差异可能很大别只跑一两天就下结论。5. 避坑清单CPT训练中我踩过的几个深坑CPT的项目周期长、环节多每个环节都有坑。下面是实战里最常见的几类问题我把排查思路和解决方案一并列出来。5.1 灾难性遗忘的破解数据配比 回放记忆灾难性遗忘在CPT里的表现是模型学完法律知识回答“今天天气怎么样”变差了或者写通用的工作邮件时语句变得生硬、动不动就冒出法条腔调。原因就是CPT阶段把模型参数全部更新了一遍旧知识被新知识覆盖。破解手段就是前面说的数据配比通用数据不能低于20%。如果你发现通用能力还是崩得厉害还有一个加强版方案加入“回放记忆”Rehearsal Memory数据也就是从通用预训练数据或者高质量通用数据里抽取一部分“代表性格言警句”训练时反复喂让模型保持对通用语言模式的记忆。另一个小技巧是弹性权重巩固EWC类算法——给模型参数的变化加正则化让与通用能力相关的参数尽量不动。但这个方案工程复杂度高需要修改训练循环多数场景下调整数据配比已经够用EWC慎用。5.2 领域数据过拟合loss崩了就查这里数据量不大但训练轮数偏多模型会过拟合到领域数据上表现为验证集PPL降到底部不再动但训练loss还在降回答时反复重复同样的模板结构创新能力大幅下降。缓解过拟合主要有三个手段减少训练轮数CPT通常1个epoch就够最多2个。加大Dropout很多大模型在预训练时关闭了Dropout你可以试着打开比如设成0.1有效但会影响收敛速度。数据增强对行业语料做回译、同义词替换、句式改写增加数据多样性。我见过一个真实案例一个团队拿10万篇医疗文献训练只跑了3个epoch模型回答问题时经常整段背原文经检测是因为同样的数据被重复看了太多遍。解决办法是保留1个epoch、把数据扩充到30万篇问题马上缓解。5.3 数据泄露评测分数虚高的元凶数据泄露在CPT项目里是个隐蔽但致命的坑。它最大的问题是让你对模型的真实能力产生虚假的自信——你以为模型学会了行业知识实际上它只是背下了答案。出现数据泄露的方式主要有训练数据里混进了评测集的数据。训练数据和评测数据来自同一个源头导致高度相似。在数据去重阶段只对训练集内部做了去重没有把评测集样本也纳入去重流程。我的做法是写一个基于向量相似度检索的检测脚本把评测集里每个样本embedding化然后在训练数据里用FAISS检索最相似的top-10条目如果相似度超过0.9就要小心。这个检查不能完全替代人工排查但能快速兜底。5.4 预算有限的替代方案LoRA/QLoRA继续预训练到底行不行很多中小团队没那么多算力做全量CPT会问能不能用LoRA做继续预训练。这个问题很有意思。LoRA本质是在旁路上学习增量能显著降低显存需求训练速度也更快。但从我实测的结果看LoRA对“小知识增量”效果好对“大规模知识注入”效果明显受限——它只会增加模型在新数据上的适配度真正要把几千亿token的行业语料融进底座LoRA能塞进去的有效信息量远不如全量CPT。但是有一个很好的折中方案先用LoRA/QLoRA做一轮小规模CPT验证数据配方和参数设定是否有效跑个几千步看看loss下降情况再决定是否上全量训练。这个“低成本验证全量训练”的组合对于预算有限的团队来说非常适合能节省大量试错成本。如果你的数据量确实不大低于1亿token也可以直接跳过CPT专注做高质量SFT 检索增强生成RAG方案。RAG能即时获取行业知识但知识整合深度不够CPT能真正把知识固化进参数但吃资源两者可以结合使用——最理想的组合是CPT融入核心概念RAG兜底实时资料。6. 从一个“能跑”的模型到真正可用的行业模型CPT做完模型只能说“底子到位了”离真正的“可用”还有距离。千万不要有“CPT跑完就万事大吉”的心态后面连着SFT、偏好对齐DPO/RLHF和持续迭代每一步都是在给这个底子做调制。最后分享一点个人经验。我在评估一个CPT项目是否成功时不看模型在评测集上刷了多少分而是看三个“会”业务人员愿不愿意用它、回答有没有低级错误、以及模型敢不敢承认自己不知道。前两个是能力问题最后一个是“校准”问题。很多模型在CPT之后知识增加了但“自知边界”的能力反而下降了回答问题时特别喜欢一本正经地编。解决这个问题的关键是在SFT阶段专门设计“说不知道”的训练样本让模型学会在不确定时坦诚表达而不是硬着头皮生成。继续预训练从来不是一个“做完就结束”的事。行业数据在变、业务场景在变模型需要定期增量更新。建议从一开始就搭建好数据的持续收集管道每一次业务使用中产生的优质问答、修正反馈都可以沉淀下来成为下一轮CPT的养料。模型不是一次性的项目而是要跟业务一起成长的系统。把这一轮做扎实后续的维护和迭代就有持续滚动的底子。