实战指南：从数据工程到行业模型落地)
很多做企业AI落地的朋友找到我，开口第一句话往往是："我们调了通用大模型，也做了提示词优化，但回答行业问题还是不够专业，是不是该自己训练一个行业模型？"这个问题背后，就是通用大模型和行业模型之间的鸿沟。通用大模型确实强，但它掌握的是全人类范围的常识，到了某个垂直行业，术语体系、文档风格、知识密度全都变了，光靠提示词很难把底座模型的认知拉到行业深度。Train from scratch成本高到离谱，纯靠SFT又只是表面学会格式，深层行业知识根本没进去。真正性价比最高的路径，就是我今天要讲的Continued Pre-Training，中文叫持续预训练，简称CPT。
这篇文章我会从数据工程、训练配置、评估回归、连带踩坑，把整个CPT实战链路拆开讲一遍。适合企业AI团队的技术负责人、算法工程师，也适合正在做技术选型的产品经理看个大概。里面所有数值和策略都是我在真实项目里跑过的，不一定适合每一家公司，但肯定比网上那些泛泛的概念介绍要实在得多。
1. 项目概述：搞懂Continued Pre-Training在企业里的真实定位
1.1 为什么说"从零预训练"不是企业该走的路
先直接回答一个最常被问的问题：为什么不能从零开始训练一个行业大模型？技术上不是不行，但经济账完全算不过来。一个7B规模的模型，从零预训练通常需要2到3万亿token的数据，算力消耗在数千块A100级别显卡上跑几个月，电费加硬件折旧就是几千万起步。到了70B甚至更大规模，成本直接上亿。绝大多数企业根本没有这个预算，也没有这个数据量。退一步说，就算你砸钱砸数据勉强训出来了，效果大概率还不如一个开源的通用底座模型，因为你造数据的质量和广度和那些顶级团队的万亿级语料没法比。
所以更聪明的做法是站在巨人的肩膀上。通用大模型已经具备语言学能力、推理能力、世界常识，它只是对某个行业的专有知识覆盖不足。Continued Pre-Training要做的，就是用大量行业语料对底座模型做二次训练，让模型把行业术语、文档结构、专业逻辑内化到参数里。你可以把它想象成：招了一个名校通识教育毕业的高材生，他很聪明、基础很好，但不懂你这家公司的业务，你把他送去行业研究院进修三个月，回来他就能直接干活了。
这三个月进修，就是CPT。它不需要重新学习语言，只需要补充行业知识，所以token量级通常在几十亿到几百亿之间，和万亿级预训练相差两个数量级。这也是为什么CPT是目前企业自训行业模型的主流入场方式。
1.2 CPT能解决什么、不能解决什么
把CPT的边界搞清楚，能避免后期大量返工。它擅长解决的问题，我列几类：
- 行业术语和专有名词。制造业里的"高炉煤气""冷轧卷板"，金融里的"授信额度""债券回售"，医疗里的"适应症""给药途径"，通用模型经常理解得模棱两可，CPT之后会稳定很多。
- 行业文档的写作风格和表达习惯。让模型读一批环评报告、法律判决书、基金公告，它能学会这类文本的段落结构、句式特征。
- 企业内部的私有知识。公司历史项目文档、产品缺陷记录、FAQ库、客服对话，这些都是公开语料里不存在的内容，CPT是最合理的注入方式之一。
- 减少幻觉的底层认知。模型对某个领域完全没概念时，会一本正经地编造。CPT让它在知识边界内作答，编造概率会大幅下降。
但CPT不是万能的。首先，它不能替代RAG做实时知识检索。企业内部的那套动态数据库、每天变动的价格、库存、政策，根本不应当写进参数里，CPT训练完之后数据就固化了，今天注入的知识明天不可能自动更新。其次，CPT不负责指令跟随。让模型"按JSON格式输出""先分析再总结"这类能力，是SFT阶段的工作。最后，CPT也不能凭空创造模型没见过的新知识，如果企业业务文档本身就稀缺，那CPT的效果会非常有限。
所以我经常和团队强调一句话：CPT解决的是"这个模型懂不懂行业"，SFT解决的是"模型会不会按你的要求说话"，RAG解决的是"模型能不能拿到最新最准的信息"。三者是一条流水线，不是互斥方案。
2. 数据工程：CPT的成败七成在数据，三成才在训练
2.1 数据来源：企业知识资产的盘点与收集
我见过不少团队，训练还没开始，第一步就被数据卡住了。企业里数据散落在各个部门、各种格式里，文档有Word、PDF、扫描件、PPT，甚至还有大量Excel里的结构化字段。你指望一个训练脚本直接吃进去，根本不现实。所以在动训练之前，先做一次认真到近乎较真的数据盘点。
内部数据源通常包括这几类：技术文档、产品说明书、操作手册、历年项目报告、行业分析报告、客服对话记录、工单系统里的问题描述和解决过程、研发代码仓库里的注释文档、企业内部的知识库和Wiki。外部的公开数据源包括行业白皮书、监管公告、专利文本、学术论文、标准规范、行业协会的公开报告。做金融的，要把每年几千份基金公告、招股说明书纳入；做法律的，裁判文书、法律法规库是重中之重；做制造业的，设备说明书和故障案例库比泛泛的行业新闻更有价值。
这块有个特别重要的提醒：数据授权和合规。内部文档要注意是否包含客户隐私、员工个人信息、商业机密；外部爬取的数据要确认版权和平台条款。CPT做完之后模型是可能记住具体片段并原样输出的，如果语料里混入了未经脱敏的个人信息，那在推理阶段就等于数据泄露。我在实际项目里要求所有进入训练流水线的数据，必须先过一轮PII检测，手机号、身份证号、邮箱、住址这类高敏信息直接做掩码或丢弃。
盘完数据之后，还要记录每个文档的来源、格式、时间、部门。这一步听着行政化，但训练出了问题要回溯数据时，它就是救命的索引。
2.2 清洗去重：决定训练下限的脏活累活
很多人以为训练效果靠模型结构，靠调参，其实CPT这个阶段，数据quality对结果的影响比模型还大。通用预训练数据规模足够大，偶尔脏一点问题不大；但行业语料本身就只有几十万篇，如果遍地是OCR乱码、广告水印、重复段落，模型很容易把噪声也学进去。
清洗流程我按顺序拆一下：
第一，格式解析。PDF要重点处理。很多扫描件需要OCR，OCR输出的错别字、乱码、表格错位，都需要用规则和模型来修正。Word文档里的页眉、页脚、目录、水印要去掉。HTML下载的内容要剥离标签，只保留正文文本。Excel表格要考虑是转成自然语言句子，还是保持线性化的键值对。这里的核心原则是：喂给模型的是"可读的自然语言"，而不是机器导出的原始结构。
第二，去重。行业语料虽然总量不大，但内部重复率高得吓人。同一份公告可能在三个网站出现，同一个技术方案文档被复制粘贴了几十次。先去精确重复，MD5或SHA1哈希判重，这能干掉一半以上重复。再去模糊重复，用MinHash加LSH做近重复检测，相似度阈值我一般设在0.85左右。还有一个容易被忽视的重复类型：跨文档重复。比如A文档是B文档的章节截断，或者多份报告共用同一段政策原文，这些都要去。重复数据不去干净，模型过拟合的风险会成倍增加。
第三，质量过滤。不是所有文本都值得让模型学。规则层面，可以过滤掉过短文本、非中文主体文本、乱码比例过高的文本。模型层面，我习惯用一个小型语言模型给每个文档算困惑度，那些困惑度异常高或异常低的都要查一下。异常高通常是语种混杂、乱码；异常低往往是重复文本或模板化内容。另外，广告、营销号、水军内容也要设规则词表过滤。
清洗这块没有太多技术性捷径，基本都是脏活累活，但请务必重视。一个经验是：如果你发现清洗完的数据量只剩原来的60%，这是非常正常的情况，不要心疼。用剩下的60%干净数据，效果远好过用100%的脏数据。
2.3 数据配比与词表扩展：两个容易被忽略的关键点
数据准备好之后，下一个问题是：训练语料里只放行业数据吗？答案是否定的。我强烈建议在CPT阶段保留相当比例的通用语料，目的就一个，防止灾难性遗忘。模型本来已经具备了很强的通用能力，如果连续几天只喂法律文书或医疗病历，它对常识对话、代码、数学的能力会明显下滑。一个比较稳的配比是行业语料占60%到80%，通用语料占20%到40%。通用语料从哪里来？可以直接复用开源的中文预训练语料，也可以从公开的百科、新闻、书籍里采样一部分。
行业数据总量该有多少？这个问题不能一概而论，但可以给个参考区间。如果一个7B模型，CPT阶段行业语料做到10亿到20亿token，通常就能看到明显的领域能力提升。如果预算充足，做到50亿到100亿token也很常见。再往上，边际收益会递减，除非底座模型本身训练不足。注意，token不等于篇数，一篇文章大约几百到上千token，所以20亿token对应的大概是几十万篇文档。
词表扩展是另一个很容易踩的坑。底座模型的分词器，比如Qwen、Baichuan、Llama的tokenizer，是在通用语料上训练出来的，它对行业专有名词的切分很可能不友好。举个例子，在Llama的中文词表里，一个较长的行业术语可能被切成七八个token，这就意味着模型要把一个完整概念拆成碎片来理解，效果自然打折。解决方法是：用行业语料跑一个BPE统计，找出那些高频但当前词表切分过细的片段，拼成增量词表，然后把embedding矩阵和LM head对应位置随机初始化或做均值初始化，再整体投入训练。这个操作会让模型对行业词汇的"感知颗粒度"更合适，生成的术语准确率会有很直接的提升。当然，词表扩展也有代价，就是embedding维度变大，显存占用增加几十到几百MB，这个开销在可接受范围内。
3. 训练实施：从调度、超参到分布式训练的完整流程
3.1 技术选型：全量微调、LoRA、冻结层怎么选
训练方案取舍，本质是预算和效果之间的权衡。我先把三种方案说清楚。
全量微调，也就是对底座模型的全部参数做更新，理论上限最高，行业知识融入最彻底，但显存和算力开销也最大。一个7B模型用全量微调，如果用上ZeRO-3和激活重计算，单卡80G显存大概需要8到16张卡才能跑起来；70B模型则需要几十甚至上百张卡。这个成本大多数企业未必扛得住，但效果确实是最稳的。
LoRA这类参数高效微调方法，只训练新增的低秩适配矩阵，参数量只占原模型的0.1%到1%。显存需求大大降低，7B模型4到8张消费级显卡就能跑。但它的劣势是：可学习的参数量有限，对大规模行业知识注入的"深度"不如全量微调。我的经验是，LoRA适合数据量不大、预算有限的场景，能实现五六成功力的CPT效果；但如果目标是让模型在专业任务上达到非常高的水平，全量微调始终是绕不开的选项。
还有一个折中方案：冻结浅层和深层部分层，只训练中间几层，或者只训练embedding和最后的几层。这种做法在CPT里也有应用，但实践下来，效果波动较大，不是特别推荐作为首选。训练框架方面，如果做全量微调，DeepSpeed的ZeRO-3是标配；如果做LoRA，HuggingFace TRL加PEFT的组合就很顺手；追求极致训练效率的团队，可以考虑Megatron-LM，但那套东西工程复杂度高很多，适合专门做底座训练的团队。
3.2 超参数设计与训练策略
说到超参数，网上很多教程上来就是一套"默认值"，但CPT和SFT、预训练的超参数差别挺大。我按自己跑过的项目给一套经过验证的初始配置，然后讲一下每个参数背后的考量。
学习率是CPT里最需要谨慎的一个参数。通用的预训练学习率通常在1e-4到3e-4，但CPT是在已有模型基础上继续训练，学习率太大会把原有参数冲坏，导致通用能力断崖式下降。我的习惯是初始学习率控制在2e-5到5e-5之间，如果用LoRA，学习率可以适当提高到1e-4到2e-4，因为新增参数不涉及原始权重的稳定性。学习率调度用cosine decay，warmup比例在3%到5%。如果数据量不大，比如只有几亿token，可以不用完整cosine降到底，在最低点截断也没问题。
训练轮数，也就是epoch，这个特别重要。CPT不建议多轮反复训练。行业语料本身重复率就高，连续两三轮之后，模型可能会开始背数据，生成时反复出现同样的句子。1到1.5个epoch是比较安全的范围，也就是说，训练数据每一条最多让模型看到一到两遍。
batch size方面，我建议关注全局batch size，也就是单个batch乘以梯度累积步数，保持在512到1024个样本之间。这个规模既能让梯度估计稳定，又不会因为太大而损失泛化。序列长度上，常规场景用4096就够；如果行业文档以长文本为主，比如年报、专利、判决书，可以尝试8192甚至16384。长序列训练要注意，位置编码如果是RoPE类的，长度外推问题不大，但如果用的Alibi，长序列效果需要做针对性验证。
损失函数不用特别设计，还是标准的交叉熵。但训练过程中要盯两个指标：一是loss曲线的下降趋势，二是行业评测集上的困惑度变化。如果loss降得很快但行业评测集上效果没提升，那通常意味着数据里学到的只是表面模式，而不是真正可迁移的知识。
下面给一份我实际用过的DeepSpeed配置片段，方便你有个直观印象。
# deepspeed_config.json { "train_batch_size": 512, "gradient_accumulation_steps": 16, "train_micro_batch_size_per_gpu": 4, "optimizer": { "type": "AdamW", "params": { "lr": 3e-5, "betas": [0.9, 0.95], "weight_decay": 0.1 } }, "scheduler": { "type": "WarmupCosineLR", "params": { "warmup_min_lr": 1e-6, "warmup_max_lr": 3e-5, "warmup_num_steps": 500, "total_num_steps": 8000 } }, "fp16": { "enabled": false }, "bf16": { "enabled": true }, "zero_optimization": { "stage": 3, "offload_optimizer": { "device": "none" } }, "activation_checkpointing": { "partition_activations": true } }这里面有个细节值得说明：我推荐用bf16而不是fp16。因为在CPT这种长训练流程里，fp16容易出现梯度下溢和精度丢失，bf16的指数位更宽，训练更稳定。如果你的硬件不支持bf16，比如一些旧卡，那再退回到fp16，同时开启loss scaling。
3.3 算力估算与分布式配置
算力估算这件事，网上公式很多，我用一个比较直观的方式来讲。训练总计算量大致等于6乘以模型参数量再乘以训练token数。比如一个7B模型，跑20亿token，总计算量大约是6乘以7e9乘以2e9，约8.4e19 FLOPs。再看硬件算力，一张A100在bf16矩阵计算下大概能到312 TFLOPS，考虑到实际利用率通常只有40%到50%，真实有效算力按130 TFLOPS算。那么一张A100跑完全程需要的时间大概就是8.4e19除以130e12，约6.5e5秒，折合180小时左右。如果按2天跑完的节奏，8张卡绰绰有余；如果按1天跑完，16张卡也够了。70B模型跑50亿token，一张卡就不行了，至少需要64张A100级别。
这组数字告诉你一个道理：CPT对算力的门槛远低于从零预训练，但也绝不是一张消费级显卡能搞定的事。我给大家一个决策参考：如果你的训练数据在5亿token以内，模型是7B，LoRA方案可行；如果数据超过20亿token，还是老老实实上全量微调加多卡分布式，否则信息量消化不完。
分布式配置这里面工程细节很多，我不展开讲每一层，只说三个最容易忽略的点。第一，数据加载是很多CPT项目的瓶颈。行业文档清洗后可能需要做成统一的tokenized格式，比如预编码成二进制内存映射文件，这样训练时不用每步都做tokenize，吞吐量能提升好几倍。第二，混合并行策略。模型不大时，数据并行加ZeRO-3就够了；模型大到30B以上，建议加张量并行，否则单卡内存压力会爆。第三，断点续训。CPT训练周期长，机器故障是常态。每500到1000步存一次checkpoint，而且要确认checkpoint里保存了优化器状态、学习率调度器状态和随机数种子状态，否则续训时损失会跳变。
最后，训练过程中的监控面板也要搭好。除了loss，还要盯梯度范数，如果出现梯度爆炸，往往需要把梯度裁剪设到1.0，这是我最常用的急救手段。梯度范数长期异常偏大，就得检查数据里是否有异常长文本或高重复序列。
4. 评估与回归：凭什么说这个模型"行业化"了
4.1 行业评测集的搭建
训练跑完了，模型行业化没有？这个问题如果只说"我们自己测了一下，感觉变专业了"，那在内部立项和外部汇报时都站不住脚。必须有一套可量化、可复现的行业评测集。
搭评测集最理想的方式，是从训练语料中留出一部分不参与训练的文档，然后基于这些文档构造任务。比如你是做法律行业的，可以从判决书里构造出"根据以下案情，判断被告是否构成违约"这类问题；做医疗，可以从病例和用药指南里构造"针对XX症状，最适合的用药建议是什么"。问题的形式可以是选择题、判断题，也可以是开放问答，但开放问答需要人工打分，尽量把大部分评测项转成有标准答案的客观题，这样自动化跑分才高效。
除了从留出文档构造，还可以请行业专家写一批典型业务问题。这个问题规模和模型能力匹配：一个细分领域，100到300道题是一个比较基础的评测集；要想做严谨的版本，500道以上会更有说服力。评测集定下来之后，还要划分成"dev集"和"test集"，dev集用来训练过程中随时监测，test集只在最终评估时用一次，避免你根据test集反复改模型造成过拟合。
这里有一个细节：用大模型辅助生成评测题是可以的，但一定要专家审核。通用大模型生成的选项里经常有知识瑕疵，如果这些瑕疵进入评测集，那模型答对答错都不能反映真实能力，整个评测就失效了。
4.2 通用能力回归与灾难性遗忘的度量
行业能力要涨，通用能力不能跌得太狠。这是CPT项目里最难平衡的事。我在实际项目里有个铁律：训练前后，模型的通用基准测试成绩必须做对比。中文场景，跑C-Eval、CMMLU、GAOKAO-Bench这类；英文和代码，配上MMLU、GSM8K、HumanEval。不用全跑，挑三四个和你们产品最相关的。通常的标准是：通用能力综合得分下降不超过2个百分点，可以接受；超过5个百分点，就要停下来分析原因了。
出现明显回落时，先检查是不是学习率太大或训练轮数太多。还有一个更隐蔽的原因：数据配比中通用语料比例太低。我后来习惯把通用语料维持在20%以上，并且在训练后半段逐步提高通用语料的比例，相当于做了一遍"回放"，把模型对通用能力的记忆再巩固一下。如果回放效果还不理想，可以试试EWC这类正则手段，让模型参数更新时尽量远离原始模型位置。这个方法在部分项目里有效，但不是银弹。
另外我还特别建议关注一个指标：行业语料困惑度。训练完成后的模型，在留出的行业测试文档上困惑度应该比底座模型有明显下降，比如下降10%以上，这能证明模型确实在"消化"行业语言模式。当然困惑度下降不等于下游任务效果好，所以要结合行业评测集一起看，两个指标一个都不能少。
4.3 训练到部署的验收清单
把评估项整理成一张验收清单，是我在每个项目收尾时都会做的事。这里我直接把清单分享出来，你们可以直接抄。
- 行业语义理解：在行业评测集上的准确率，对比底座模型提升是否明显，比如提升10个百分点以上。
- 专有名词生成：抽检100个行业术语，让模型输出解释，看准确率是否超过95%。
- 通用能力回归：C-Eval和MMLU这类基准，对比底座模型下降是否小于2个百分点。
- 生成质量抽检：人工阅读50条生成结果，打钩确定是否存在重复、逻辑断裂、幻觉。
- 指令跟随能力：跑一批SFT阶段的标准指令，确认模型没有在CPT后变"笨"。
- 遗忘测试：随机挑一批训练语料里的关键数据，让模型输出相关内容，确认不是机械背诵。
这六项都过完，再谈上线。很多项目失败不是败在训练效果，而是败在验收标准模糊，最后产品和算法互相甩锅。标准前置，验收模板化，是避免这个局面的唯一办法。
5. 踩坑实录与实操心得
5.1 我遇到的最典型的四个坑
这一节全是真实项目里趟出来的坑，每一条都值得你收藏。
第一个坑是数据重复导致的过拟合。有一回训练一个金融行业模型，loss下降异常快，训练到一万步的时候，生成结果里反复出现同一段公司的标准免责声明。查下来发现，语料里一份50页的招股书被不同数据源重复收录了三百多次。清洗阶段虽然做了精确去重，但那份文档在不同来源里文字略有差异，MinHash的阈值又设得比较松，结果漏掉了。那次之后我把模糊去重阈值从0.85调到了0.9，并额外加了一道基于embedding的语义去重，过拟合问题大幅缓解。
第二个坑是学习率设置过高，直接把模型通用能力冲崩溃了。第一次做CPT时，我按预训练的节奏设了1e-4，结果训练到一半，模型写代码的能力几乎归零，连"写一个Python循环"这种题都答不对。后来降到3e-5，重新跑，情况立刻好转。所以这里再次强调：CPT的学习率，宁低勿高，这是血泪教训。
第三个坑是词表垃圾化。有个制造行业的项目，语料里全是设备型号和工业专有名词，最初没做词表扩展，训练之后发现模型生成术语时经常出现拼接错误，把一个完整的型号拆成几截。后来统计tokenizer的切分情况，把那几千个高频行业词加入词表，重新初始化对应的embedding，再训练一轮，生成准确率明显恢复。词表扩展这件事，越早做越好，训练完再做代价就大了。
第四个坑是评估指标骗人。某个项目只看了行业文档困惑度，指标漂亮得很，下降超过20%，但实际问答测试一塌糊涂。原因很简单：模型只是学会了模仿行业文档的句式，并没有建立起足够的事实关联。所以从那天起，我坚持困惑度只能作为参考，行业评测集的准确率和人工抽检才是最终裁判。
5.2 给后来者的实操建议
CPT这件事，做完一个完整项目之后你会明白，它不是一次性的训练任务，更像是一个持续迭代的数据产品。以下几点是我现在带团队时必讲的原则。
先小规模验证，再全量跑。起步阶段拿原始数据的10%跑一次CPT，用最小的算力成本验证数据质量和训练配置是否合理。跑一小步，观察loss曲线和评测集变化，确认没问题再放到全量数据上。不要上来就全量跑，失败了连排查的切入点头绪都没有。
训练过程中定期做通用回归。不要等全部训练完了再评估。每几千步，就把C-Eval这类基准抽20到50道题快速跑一遍。这个动作成本很低，但能帮你尽早发现灾难性遗忘的苗头，及时止损。
保留每一个阶段性checkpoint。不要只留最后一版。训练到中间某一步的模型，很可能比最后一步更适合你的产品需求，尤其是当最后一步通用能力开始下滑时。回滚到几百步之前的checkpoint重来，比重新训练省时间太多。
把CPT和RAG、SFT串成一条流水线。单纯做一个CPT模型上线使用，效果通常不会让你惊艳。更好的组合是：CPT解决行业知识底子，SFT教会模型按格式输出，RAG在推理阶段拉取最新知识，三者协同。这也是目前行业里企业自训大模型最经典的一套组合拳。
最后再分享一个我自己坚持的做法。每次训练完成，把训练数据、清洗脚本、训练参数、评估结果、模型checkpoint的版本号完整归档，形成一份可复现的训练档案。之后再迭代版本时，这份档案就是最好的起点。很多团队半年后在原模型上重新训练，发现效果还不如老版本，就是因为当初的细节没记录，所有坑都白踩了。
我个人在实际操作中的体会是，CPT没有太多神秘感，它的核心就两个字：数据和耐心。数据质量决定了模型能力的上限，训练策略只是尽量去逼近这个上限。把这个关系想明白，项目就成功了一大半。如果你正准备启动自己的行业模型训练，希望这篇实战指南能帮你少走几段弯路。
