企业官网建设流程全解析

通用大模型在通用任务上已经够强了，可真落到具体行业里，企业往往还是会觉得“差点意思”。比如法律领域的条款理解、医疗场景的术语推理、制造业的设备故障诊断，通用模型要么答得泛泛，要么干脆胡说。这时候很多团队第一时间想到的是微调（Fine-Tuning），但忽略了一个更前置、更关键的手段：Continued Pre-Training（持续预训练，简称CPT）。这篇文章我会结合自己跑过的训练任务，把企业怎么把通用大模型“喂”成行业模型这件事讲透，涵盖数据准备、训练策略、资源评估和避坑经验，适合正在做模型落地的算法工程师、技术负责人，以及被老板要求“让大模型更懂我们行业”的一线同学。

先说结论：CPT的本质，是在通用模型的基础上，继续用大规模领域语料做预训练，让模型在参数层面“真正掌握”行业知识。它跟微调最大的区别在于，微调是教模型“怎么回答”，CPT是教模型“知道什么”。如果你手里有大量行业文档、技术手册、历史报告，而这些知识在通用模型里覆盖率很低，那CPT大概率是比微调更值得投入的方向。

这篇文章我不会只讲概念，会把整套流程拆开揉碎：数据怎么清洗、训练怎么配参、资源要多少、loss怎么看、遗忘怎么防，每一步都给出可以直接拿去用的方案和经验。好，直接进正题。

1. 先搞清楚：Continued Pre-Training到底解决什么问题

1.1 为什么通用大模型在行业场景里“不够用”

很多人对“大模型很聪明”有误解，觉得啥都懂。但模型的能力上限，取决于预训练阶段“见过的数据”。通用模型的数据分布里，互联网公开内容占大头，而某个特定行业的深度知识、专有术语、内部逻辑，在公开语料里的占比非常低。举个例子：你问GPT或开源模型“变压器油中溶解气体分析的判断依据”，它能背出三比值法，但你要是问“结合我们厂近三年的DGA趋势和负载情况，给出检修优先级建议”，它大概率就露馅了。

这不是模型不行，而是它缺少“你们厂”乃至“你们行业”的知识。Continued Pre-Training的价值就在这里：用海量的行业语料继续训练基座模型，把这些知识写进模型参数里。训练完成后，模型在行业任务上的“先验理解”会明显增强，后续无论是做检索增强（RAG）、做微调（SFT），还是直接做few-shot推理，效果都会上一个大台阶。

1.2 CPT、SFT、LoRA三者到底是什么关系

这个必须讲清楚，因为太多人把它们混为一谈。

• CPT（Continued Pre-Training）：拿原始语料（不需要问答对、不需要标签）继续预训练。目标是让模型学“知识”，改变的是模型内部的知识密度和语义理解能力。训练方式跟预训练一样，是自回归的next token prediction。
• SFT（Supervised Fine-Tuning）：拿指令-回答对训练，目标是让模型学会“按指令回答问题”的行为模式、格式、语气。改变的是模型的“行为”，而不是“知识”。
• LoRA（Low-Rank Adaptation）：一种参数高效的微调方法，通过低秩矩阵注入的方式只训练一小部分参数，可以用在SFT上，也可以用在CPT上。

它们的正确打开方式通常是：先做CPT，再做SFT。CPT把模型变成“行业专家”，SFT把模型变成“听话的行业专家”。如果你跳过CPT直接SFT，模型虽然能按你的格式回答，但回答的内容深度依然受限于通用知识，行业术语和深层逻辑还是跟不上。如果只做CPT不做SFT，模型知识库变强了，但对话能力没有被专门调优，交互体验会一般。

1.3 什么情况下该做CPT，什么情况下不该做

CPT不是万能的，它有自己的适用范围。我建议你用下面几个条件自测一下：

• 是否有足够多的行业语料？通常建议至少5-10GB以上清洗后的纯文本，少于这个量，CPT收益会非常有限，不如直接走RAG。
• 行业知识的“私有化”程度高不高？如果行业知识在公开互联网已经大量存在，CPT的边际收益会很低；反之，如果是企业内部积累、公开资料很少覆盖的，CPT就很值得。
• 任务的深度够不够？如果只是简单的“根据文档回答问题”，RAG方案可能更快更省；如果是需要“内化知识后进行推理、分析、生成”，CPT才能体现价值。

我见过不少团队一上来就CPT，训完发现效果不明显，后来一查语料才2GB，还混着一大堆低质量爬虫数据，这种投入产出比确实难看。CPT更适合那种“语料量大、知识体系完整、需要模型深度理解行业”的场景。

2. 数据工程：CPT的成败一大半在数据上

2.1 行业语料从哪儿来：别只盯着“爬”

说到行业语料，第一反应可能是去爬公开的行业网站、论坛、政策文件。这个思路没错，但要是只靠爬虫，数据和别人家的模型训练数据高度重合，CPT做起来容易“白干”。

更靠谱的语料来源要分四类：

1. 企业自有文档：内部技术手册、运维日志（需脱敏）、产品说明书、设计方案、测试报告、历史故障记录、客服对话记录等。这一部分价值最高，因为外部真的拿不到。
2. 行业公开资料：标准规范、行业白皮书、专利摘要、专业论文、监管政策、行业百科。这些公开但分散，需要花精力系统性收集。
3. 高质量社区内容：垂直社区的问答、专业博客、行业论坛的精华帖。这类数据口语化程度高，对提升模型的“实战感”很有帮助。
4. 合成数据：用通用大模型，基于已有的行业知识生成解释性文本、模拟问答、案例分析。注意合成数据主要用于补充，不能作为主力，否则容易引入幻觉。

我自己的习惯是“内部为主、公开为辅、合成为补”。内部数据决定了模型的“护城河”，公开数据负责夯实领域基础，合成数据用来填补覆盖盲区。

2.2 数据清洗：哪些该留哪些该扔

行业语料清洗，跟通用预训练的清洗逻辑不完全一样。通用预训练追求“大而全”，行业CPT更讲究“精而准”。我通常会走这么一条清洗流水线：

• 格式统一：PDF、Word、HTML这些格式先全部转成纯文本。转出来经常伴随乱码、多余的换行、页眉页脚，这类噪声在行业文档里特别常见，我用正则表达式做一轮粗暴清洗，把重复空行、特殊控制字符、无意义符号直接干掉。
• 噪声过滤：用规则过滤掉无正文的页面、纯广告文案、大量乱码的内容；再用启发式规则，比如筛掉包含“点击查看”、“更多优惠”这类非行业内容的文本块。
• 质量打分：给文本质量打分是一个很实用的技巧。我会根据句子长度分布、标点符号比例、重复度、是否有完整段落结构等维度评分，低于阈值的直接淘汰。行业文档里经常有扫描件OCR出来的文字，质量极差，这种数据喂进去只会教坏模型。
• 语言过滤：除非你想做多语种，否则建议只保留目标语言占绝对主体的文档。行业文档有时中英混杂，保留“中文为主、英文术语保留”的文本，这种反而对模型友好。
• 敏感信息处理：企业在用自己的数据时，一定要做PII（个人隐私信息）检测和脱敏。客户姓名、电话号码、身份证号等都要用规则加模型双重识别，能去掉就去掉，不能去掉就打码。这条不能省，否则后期出问题很麻烦。

2.3 数据配比与采样策略：不是堆量就完事

行业CPT的数据配比，是很多团队容易栽跟头的地方。“既然要做行业模型，那就全用行业数据呗”——千万别这么干。如果全部喂行业数据，模型在通用任务上的能力会快速退化，这种现象叫“灾难性遗忘”，后面我会详细讲。

我的经验是，行业CPT的数据配比要有一个“通用数据锚点”。比例上，行业数据占60%-80%，通用数据占20%-40%。通用数据可以复用RedPajama、SlimPajama这类开源通用语料的抽样，或者用你基座模型原始训练数据中可获取的公开部分。这样模型既能持续吸收行业知识，又不会把通用语言能力丢掉太多。

另外要注意的是行业内部各细分子领域的配比。比如做法律大模型，民法、刑法、商法、程序法、行政法规之间的语料也不均匀。我在实操中会先用规则或关键词统计对语料做粗略分类，再根据模型在下游任务上的薄弱点调整配比。这不是一步到位的，往往第一版训练完，跑完评测，发现某个子领域效果差，就需要回去加密该子领域的数据。

2.4 去重：被忽视的关键环节

预训练数据去重，理论上行业CPT也一样要做。行业语料内部重复度高得惊人，尤其是政策文件的不同转载版本、同一技术文档的多个备份。如果不做去重，模型会在某些句子上严重过拟合，训练到后期loss下不去，生成的文本还可能出现“复读机”现象。

实操中我会做两级去重：

• 精确去重：对整篇文档做哈希，内容一模一样直接去重。
• 模糊去重：使用MinHash（局部敏感哈希）对文档做近似去重，主要对付“改几个字就重新发布一遍”的情况。行业文档里这种尤其多，比如不同年份的政策文件，正文只改了年份和少数地方，这种就要靠模糊去重来识别。

我之前处理过一批央企的规章制度文档，精确去重后发现去掉了将近30%的冗余内容，这个比例在企业数据里一点都不夸张。

3. 技术选型与训练策略：全量CPT还是高效参数CPT

3.1 全量CPT：效果最好，门槛也最高

全量CPT，就是让模型所有参数都参与训练。好处很明显：模型学习新知识的“容量”最大，知识融入得最彻底。坏处也直接：显存要求极高，训练时长很长，对工程能力要求高。

以参数量为例，如果基座模型是7B，全量CPT在单机8卡A100(80GB)的条件下，序列长度设为2048、全局batch size设为1024，大概只能同时容纳很小的梯度更新步数，训练效率会受限于通信开销。如果模型是13B甚至70B，没有多机多卡集群，基本不用考虑全量，老老实实走高效参数方案。

全量CPT的工程要点包括：使用DeepSpeed ZeRO-2或ZeRO-3进行显存优化，开启activation checkpointing（激活重计算）节省显存，混合精度训练（bf16基本是标配）。训练框架我建议用Megatron-LM或基于DeepSpeed的脚本，这两者对大规模预训练的支持更成熟。

3.2 LoRA/QLoRA做CPT：性价比之选

很多人以为LoRA只能做SFT，其实LoRA完全可以做CPT。把LoRA模块加到模型的attention层（一般q、v、k、o都加，或至少q、v），然后用行业语料做next token prediction训练。效果比起全量CPT会打折扣，但开销省了不止一个数量级。

我做过一组对比实验：同样用10GB行业语料、训练3个epoch，7B模型全量CPT在8卡A100上要跑40多个小时，而QLoRA（4-bit量化+LoRA）在单卡A100上用了不到10小时。下游评测指标上，全量CPT平均分比QLoRA高大约6%-10%，但如果算投入产出比，QLoRA对中小团队来说绝对是“真香”选项。

LoRA做CPT的几个实操参数（7B模型，仅供参考）：

• rank（秩）建议64-128，比SFT时设得高一些。CPT要学的新知识模式更多，rank太小容易学不进去。
• alpha设为rank的2倍，比如rank=64，alpha=128。
• 学习率1e-4到2e-4，比全量CPT高一个量级。
• target_modules设成q_proj、k_proj、v_proj、o_proj，全加上效果更稳定。

3.3 怎么选：资源与目标之间的权衡

决策路径其实很简单。我通常按这个逻辑判断：

• 想做到“极致行业化”，比如要发布一个行业大模型产品，有GPU集群，训完还想继续SFT，那就全量CPT。
• 想在现有系统里快速提升模型行业能力，资源只有几块消费级或单卡专业级GPU，预算有限，那就LoRA/QLoRA。
• 数据量本身只有1-3GB这种小体量，别纠结CPT了，用LoRA快速迭代打样，验证赛道方向更重要。

还有一条折中路线：先做LoRA CPT验证数据质量，如果评测指标明显提升、说明数据有效，再决定要不要升级到全量CPT正式训练。这个“先小后大”的节奏我一直在用，能省很多不必要的试错成本。

3.4 关键超参数设置：不抄作业，理解逻辑

CPT的超参数跟预训练相似，但又有自己的特点。下面是我用过比较稳的设置（以7B模型、序列长度2048为例）：

这里特别说一下epoch。通用预训练对大语料只过0.5-1轮，行业CPT因为语料相对小，一般过1-3轮。但要注意：如果语料低于10GB，过2轮以上很容易过拟合，模型会开始“背数据”而不是“学规律”。判断方法很简单，训练过程中监控验证集loss，如果验证集loss先降后升，那就是过拟合的典型信号，赶紧停。

3.5 基座模型怎么选：不是越大越好

基座模型对CPT的效果影响很大。我选基座时会看几个维度：

• 开放程度：模型是否允许商用、权重是否可下载。Qwen系列、DeepSeek系列、Llama系列这几种开源模型各有特色，国内做企业项目优先考虑Qwen和DeepSeek，中文能力底子好。
• 原始训练数据的覆盖度：如果基座模型本身在目标行业的数据覆盖度就一般，CPT的负担会更重。这个可以通过先用模型做一批行业问题测试，看看基座本身的“底子”。
• 模型尺寸与部署约束：如果最终要部署在普通GPU服务器上，7B-14B是相对合适的档位。70B再强，部署成本和推理延迟很多企业都扛不住。

我个人的建议是，垂直行业项目优先试Qwen2.5系列（7B/14B），中文效果好，对CPT的兼容性也友好。即便最后因为某些原因不选它做基座，也建议先用它做一轮小规模CPT验证数据质量，因为它的训练行为比较稳定，不太容易出现“越训越差”的诡异问题。

4. 训练环境与工程实践：别让环境拖后腿

4.1 GPU资源需求：怎么算才靠谱

很多人问“CPT需要多大的GPU资源”，我给一个参考计算方法。

关键变量是：模型参数量（N）、序列长度（L）、全局batch size（B）、训练步数（S）。训练的总计算量约等于 6 * N * B * S（FLOPs），注意这是理论值，实际还要考虑激活重计算带来的额外开销。

如果拿A100(80GB)估算能跑多大的模型：全量CPT的7B模型，开activation checkpointing之后，单卡大概能塞下序列长2048的batch size为2-4的样本。要凑到全局batch size 1024，就需要256-512张卡同时并行。大型机构没问题，中小团队直接劝退。所以我才反复推荐LoRA/QLoRA方案，7B模型QLogic上用单卡A100就能做训练，实在没有A100，用4090 24GB也不是不能跑QLoRA，只是batch size要压得更低。

4.2 框架选择：熟悉和效率之间的平衡

• HuggingFace Transformers + PEFT：最简单，适合快速验证和中小规模训练。LoRA/QLoRA基本是标配路线，代码量小，改起来方便，适合团队快速上手。
• DeepSpeed：在做全量CPT时非常顺手，ZeRO-2/3对显存的优化立竿见影，offload到CPU甚至NVMe能进一步压显存。
• Megatron-LM：追求极致训练效率和多卡扩展时用，但代码复杂度高，一般团队不需要上手就选它。
• LLaMA-Factory：如果主要是用LoRA走CPT，这个框架可以大幅提高效率，很多训练trick都内置了，对新手尤其友好。
• PaddleNLP：如果团队用的是百度系技术栈，或者有飞桨算力平台，可以考虑，中文NLP支持做得不错。

我的建议很务实：先跑通小数据、小模型验证方案，再决定上不上大规模集群。框架的选型不要盲目追新，团队哪个熟用哪个，训练脚本稳定可控比花里胡哨重要。

4.3 训练过程中的监控：该盯哪些指标

训练启动之后不是撒手不管，我一般盯着几类信息：

• 训练loss：重点关注下降趋势是否平缓。CPT的loss下降通常不像预训练前期那么快，因为模型已经有基础了。如果loss完全不动，优先检查数据问题和学习率；如果loss震荡剧烈，考虑改小学习率。
• 验证集loss：一定要留出一部分行业数据做验证集（我习惯留5%左右），每个epoch或固定步数跑一次验证，用来监控过拟合。验证集loss拐头上升，就是过拟合信号。
• 梯度范数：梯度范数异常增大说明训练不稳定，要调低学习率或检查数据里是否有异常样本。
• 通用能力评估：每隔一段时间把模型拿出来，跑一批通用能力评测（比如GSM8K数学、MMLU综合、C-Eval中文），一旦发现通用能力明显下跌，就得考虑调低学习率或者增大通用数据比例。

我有一个习惯：训练期间把checkpoint隔固定步数保存（比如每500步），全部train完之后，挑不同步数的checkpoint做行业任务评测，看一看“训练到哪一步效果到顶”。有时候训练3/4的时候效果最好，全训完反而过了，这时候拿中间checkpoint部署反而是最优解。

5. 评估与迭代：怎么知道训练有没有效果

5.1 评估维度：行业知识和通用能力两手抓

CPT的效果评估，不能只看loss。loss下降说明模型拟合了训练数据，但不代表在下游任务上真的更“好用”。我一般从四个维度做评估：

• 行业知识问答：构造一批行业专业问题，让模型直接回答，人工或大模型打分判断正确性。这是最直观的维度。问题要包括“知识性问答”（某标准、某条款是什么）和“分析推理题”（给定场景，让模型推理判断）。
• 行业术语理解：测试模型对专业术语的定义、关联、辨析能力。比如给一个术语，让模型生成解释；或者给两个相近术语，让模型说清楚区别。
• 通用能力回退测试：跑MMLU、C-Eval、GSM8K这类的通用基准，对比CPT前后分数。通用分数下跌在10%以内是可接受的，超过这个幅度就要调整训练策略。
• 生成质量抽查：人工翻阅模型生成的行业文本，看是否有逻辑混乱、事实错误、重复生成。这个只能靠人工，但很必要。

5.2 评测集怎么建：没有评测集，训练就是盲人摸象

我在项目启动的第一周，就会让团队把评测集先建起来，而不是等训练完了再想怎么测。评测集的建设原则：

• 来源独立：评测题目的语料不能混入训练数据，否则评测就是自欺欺人。
• 覆盖全面：每个行业子领域都要有题，数量按业务重要程度分配。
• 难度分层：有简单的事实题，也有复杂的综合推理题。

评测集规模不用大，200-500题就能在训练中期发现趋势性问题。关键是稳定，每次评测用同一套题，跑出来的分数才有对比意义。

5.3 防遗忘：通用能力掉了怎么办

灾难性遗忘是CPT最头疼的问题之一。我踩过深坑，后来总结出几个有效的防线：

• 数据配比里加通用数据锚点（前面提过），这是第一道也是最有效的防线。
• 降低学习率，学习率太高对原模型参数破坏更大。
• 考虑用混合训练：每个batch里行业数据和通用数据按比例混合，而不要前一段行业后一段通用。
• 用LoRA降低破坏面：LoRA因为只训练低秩矩阵，对原参数的影响天然比全量小，所以遗忘问题也轻很多。

如果你做了全量CPT，发现通用能力掉得很厉害，还有一个缓解办法：用通用数据做“恢复训练”的混合策略，在训练后期加大通用数据比例，让模型回到通用能力基线附近。

6. 常见问题与排查实录

这个板块我把自己压箱底的踩坑经验拿出来，基本是实战中最高频的问题。

6.1 Loss一直不降怎么办

先别慌，从几个方向排查：

• 学习率是否过低：如果学习率低于1e-6，基本等于没训练，先把学习率提到1e-5以上看看趋势。
• 数据是否有问题：检查数据有没有大量重复、乱码、或和目标语言不一致的内容。我遇到过一批语料编码出了问题，训练loss直接“躺平”。
• 序列长度和batch size：序列长度过长、batch size过小会导致梯度噪声大，训练不稳定。
• 检查基座模型加载方式：用LoRA时，确认不是把基座模型也设成了可训练，导致LoRA权重没有生效。

6.2 训练时显存溢出OOM

显存溢出在CPT里太常见了。几个立竿见影的办法：

• 开启gradient checkpointing（activation checkpointing），显存能省30%-50%。
• 用gradient accumulation凑大batch。
• 用QLoRA的4-bit量化加载基座。
• 长度改短一点，比如从4096改到2048。
• 换优化器：AdamW的显存占用有多个副本参数，用bitsandbytes的8-bit Adam能省一笔显存。

6.3 训练完模型“变傻了”，通用能力崩了

典型灾难性遗忘。先看数据配比里通用数据占比够不够；再看学习率是不是设高了；最后看训练轮数是不是过多了。解决手段按顺序试：先降学习率，再调大通用数据比例，最后考虑换LoRA方案从头训。

6.4 行业评测成绩没提升，甚至下降了

这个情况往往不是训练本身的问题，而是评测集与训练数据脱节。比如你做的是法律CPT，但评测题大量是“法官执法程序常识题”，这类知识基座模型本来就会，行业语料里反而不太讲这些，测不出来是正常的。建议先把评测集拿出来，逐题看模型答错的原因：是真不知道，还是知道了但表达不对，还是评测题本身有歧义。针对性调整数据或评测集再测。

6.5 训练过程中模型生成“胡说八道”的行业内容

这个情况要区分是训练不足还是过拟合。训练不足，模型还没掌握行业术语的精确用法，输出会比较空；过拟合，模型背下了训练数据中的具体段落，但不会举一反三，遇到没见过的问法也会强行套。两者处理方式正好相反：前者加数据、加步数；后者降epoch、降学习率、加强数据多样性。

6.6 数据泄漏问题：评测集别混进训练集

这个错误我见过不止一次。有人把行业资料下载下来，一部分做训练，一部分做评测，但两个集合之间有大量重复文档，评测分数虚高得离谱。防止方法：训练集和评测集做一次MinHash去重，确保评测集合里没有与训练集近似重复的文档。

7. 落地辅助：RAG和CPT怎么配合，效果才能拉满

最后聊一个很多团队都纠结的问题：我已经做了RAG（检索增强生成），还需要CPT吗？这两个不是二选一，配合好了是1+1大于2。

RAG的核心机制是“外部检索+生成”，模型本身没有内化知识，每次回答都要去库里检索相关内容再组织语言。它的优点是实时性好、可解释性强、知识可更新。缺点是：如果检索出来的信息本身不完整、不准确，模型的回答质量会直接受影响；而且对需要深度推理的复杂问题，RAG给到的碎片化上下文不一定够用。

CPT的核心机制是把知识内化到参数里，模型的推理和生成过程更“原生”。比如面对一个需要综合多个条款、多个前置条件才能作答的行业问题，CPT后的模型可以直接推理，而RAG方案需要先拼凑出一大段检索片段交给模型。CPT的缺点是知识一旦训进去再更新就要重新训练，灵活性差。

我个人的落地经验是：先做CPT把模型的基础行业能力拉起来，再在这套模型上做RAG，让RAG负责“实时、动态的私域知识”，CPT负责“稳定、深层的行业理解”。两者配合，一个管广度，一个管深度，效果比单独用任何一项都稳。尤其是做企业知识库问答的场景，CPT打底之后，RAG检索到的内容即使有些噪声，模型的抗干扰能力也好很多，答出来的内容更像“懂行的人”说的话。

另外补充一点，别在SFT阶段一次性把CPT、SFT和RLHF全都堆上去。每做完一步，都做一个中间评测，确认这一步的效果是正向的再进下一步。训练迭代这事儿，每一步的增量都要看得见，不然出了问题根本没法定位是哪个环节搞坏的。

我现在做一个行业模型项目，标准流程基本固定成：数据清洗和去重、评测集构建、小规模LoRA CPT验证、全量或大规模LoRA CPT正式训练、通用能力回归测试、SFT对齐、上线前评测。这个链路走下来，项目成功率比早期“直接微调一把梭”高太多。

最后分享一个体会：CPT最大的门槛从来不在于“训练技术”，而在于“数据治理”。你在数据上偷的每一分懒，训练完的效果都会加倍还给你的评测报告。把数据基础打牢，把验证集建好，后面无论你换什么基座、调什么参数，都有据可依，不会慌张。