企业官网建设流程全解析

前两天有个做工业设备的兄弟来找我聊，说他们拿开源的基座模型做行业问答，SFT（监督微调）跑了两轮，业务专家测完反馈就一句话："它看着像个客服，不像个老师傅。" 这其实是很多企业做行业大模型时的共同困惑。你以为是模型不会回答问题，但根子上是它压根没"读过"你们行业的语料，不知道设备故障码对应的场景逻辑，不知道合同条款里的行业惯例，更不知道你们内部文档里那些约定俗成的缩写。这时候该做的不是继续堆SFT数据，而是回到上游，做一次Continued Pre-Training（简称CPT，持续预训练）。

这篇东西我不打算写成论文复读，就按我在实际项目里走过的完整链路来拆：CPT和预训练、SFT之间到底什么关系；训练方案里几个能决定成败的超参和设计逻辑；行业语料怎么从一坨原始文档变成能喂给模型的Token；算力怎么估算、工具链怎么选；以及最容易被忽视的评估闭环。适合正在做企业级大模型落地的算法工程师、AI技术负责人，以及那些已经拿到基座模型但不确定下一步是继续微调还是重新训练的技术决策者。

1. 先弄清CPT在改模型的哪层能力：预训练、继续预训练与指令微调的分界

很多团队的误区，是把所有"让模型更懂行业"的动作都叫微调，然后一把梭去做SFT。但基座模型的能力结构是个三层金字塔：第一层是语言能力和世界知识，靠大规模预训练（Pre-training）获得；第二层是行业知识和专业语感，靠Continue Pre-Training注入；第三层是服从指令、格式化输出，靠SFT和RLHF/DPO打磨。你跳过第二层直接上第三层，模型当然学会了对齐格式，但肚子里没货，属于典型的"话术很礼貌，业务全不懂"。

1.1 预训练三阶段与CPT在其中的生态位

传统的预训练流程大致分三阶段：通用语料预训练（几万亿Token，学语言和通用知识）、领域持续预训练（几百亿到几千亿Token，学行业知识）、对齐阶段（SFT+偏好优化，学交互方式）。Stage 1和Stage 2加起来就是"前训练"（Pre-training），CPT本质上就是把Stage 2单独拎出来做，让模型在既有通用能力的基础上，继续学习某一块垂直领域的数据分布。

这里有一个非常关键的点：CPT不是从零学语言，而是"换口味"和"补知识"。模型权重在通用阶段已经收敛到一种比较稳定的状态，你拿行业语料去继续训，本质上是在调整它内部表示中与行业相关的那些子空间，同时尽量不破坏已经学到的通用能力。所以CPT的优化目标不是"追求训练集loss最低"，而是"在保持通用能力的前提下，把行业数据分布嵌入模型"。

1.2 训练目标与数据形态的差异：CLM还是MLM？

CPT在当前主流的Decoder-only架构下，训练目标和预训练一致，仍然是最经典的自回归语言建模（Causal Language Modeling, CLM），即给定前文预测下一个Token。而很多团队做SFT时用的是Chat模板，会把输入输出包成"Human:...Assistant:..."的对话结构，然后掩盖掉Assistant部分去计算Loss。这两种训练目标要严格区分开：CPT阶段不要用Chat模板。你喂给它的就是连续的、没有对话包装的行业文本，让它以纯文本的方式读完这些语料。用Chat模板做CPT会稀释文本密度，而且会把模型往"对话体"方向带偏——你还没做指令对齐呢，让它练对话是多余的。

至于Masked Language Modeling（MLM）这种BERT时代的做法，现在做LLM的CPT基本已经没人用了。生成式模型要的是下一个Token的连贯预测能力，而不是双向编码表征，MLM和生成任务的目标不一致，强行混合收益很低。

1.3 CPT、SFT、RAG各自的分工边界

我在做技术评审的时候经常画一张表，把CPT、SFT和RAG的分工讲清楚。三者不是替代关系，而是解决不同层面的问题。

很多场景其实用RAG就够了，不一定非要花几十上百万去做CPT。如果你们的知识是高度结构化、更新频繁、而且回答时只需要从固定文档里找答案，那RAG是性价比最高的方案。反过来，如果你们的核心竞争力恰恰在"无法穷举的隐性知识"——比如设备故障现象和根因之间的复杂关联、律师对判例的自由裁量逻辑、医生对症状组合的判断——RAG检索不到这种"只可意会"的东西，CPT才真正值得做。

1.4 什么时候你不该做CPT？先泼盆冷水

CPT不是万能药，我见过不少团队在这上面踩大坑。如果你属于以下情况之一，我建议你先别上CPT：

• 领域数据量不足：有效去重后连几十亿Token都凑不出来。7B模型做CPT，低于10亿高质量Token基本没有明显收益，数据量太小不如直接RAG。
• 已有的基座模型已经覆盖到你的领域子集：比如你用法务场景，用了专门的Legal-Llama，再自己做CPT就属于重复造轮子。
• 业务场景只要求"答得对"而不要求"答得像行家"：标准化的FAQ模式，把检索做强比调整模型权重更可控。
• 没有GPU预算或耐心：CPT不是跑一个晚上就能见效果的事，通常需要几十到上百卡时，测试验证周期以周为单位。

我个人判断一个项目该不该做CPT，就看一句：你们的领域知识是否"高密度、强关联、难以用检索条目穷举"。是，就做；不是，慎做。

2. CPT超参设计的四个决定性问题：数据密度、学习率、混比与梯度缩放

CPT和SFT在超参上有本质差别。SFT的学习率通常可以放到1e-5到2e-5，因为数据量小、目标明确，稍微激进一点问题不大。CPT不一样，你要把模型在一个新的数据分布上更新成百上千个step，学习率稍微失控，模型直接"失忆"，通用能力就像漏水的水桶一样哗哗往下掉。

2.1 数据密度才是行业模型的真正壁垒

做CPT第一步要回答的问题不是"用什么模型"，而是"喂什么数据、喂多少"。数据密度是什么意思？就是单位Token里蕴含的领域知识含量。同样是医疗语料，一份《XX药品说明书汇编》和一份从网上爬来的健康论坛帖子，前者知识密度远高于后者。CPT模型的能力上限，基本由你喂进去的高质量行业数据决定，模型架构、训练技巧只能决定你离上限有多近。

我自己的经验是，数据准备时间至少要占到整个项目周期的50%以上，训练和调参只占30%，评估占20%。很多团队把80%的精力花在调参上，其实方向反了。CPT的收益主要来自"喂了什么"，而不是"怎么训的"。

2.2 学习率：小到让人不适才是对的

CPT的初始学习率，我强烈建议放在标准预训练学习率的1/10到1/5，SFT学习率的0.1到0.5倍。举个例子：7B模型做SFT常用2e-5，那CPT就从2e-6到5e-6起步。70B模型一般从1e-5到2e-5起步。

为什么这么小？因为模型在通用预训练中已经收敛到一个比较好的局部最优区域。你拿新的行业语料去训练，相当于在一座已经建好的城市里改造街道——推土机不能开太快，否则把老城区全铲平了。学习率过大的直接表现是：训练Loss在头几百步疯狂波动，然后通用能力评测分数（比如MMLU）断崖式下跌，而行业能力并没有明显提升。

一个比较实用的做法是Warmup + Cosine退火：前3%步数做Warmup，把学习率从0线性升到峰值，然后再按Cosine曲线缓慢衰减到峰值的10%左右。行业数据相对通用预训练语料来说量小很多，训练步数通常在几千到几万步之间，Cosine退火能让模型在后面稳步收敛，减少对早期样本的"记忆偏置"。

2.3 Gradient Scale：用很低的成本撬动行业数据的权重

这里说说Gradient Scale，很多人不太熟，但它在CPT里非常好用。简单说，Gradient Scale就是在反向传播时，对来自某一部分数据的梯度乘上一个系数，从而人为放大或缩小这部分数据对模型的影响。

举个例子。假设一个batch里有8000个通用Token，2000个行业Token，那行业Token的比例是20%。如果行业数据是你真正想注入的重点，你可以对行业Token的Loss乘上8倍，等效于让行业Token在梯度更新中的比例变成了：8乘以2000除以（8000加8乘以2000），约等于三分之二。这样你不需要真的把行业语料复制8遍去跑，内存和计算开销一分没多花，但模型对行业文本的敏感度大大提升。

Gradient Scale和简单的过采样（Oversampling）是有区别的：过采样是把你想要的样本在训练集里复制多份，会增加GPU的读取和计算量；Gradient Scale只在loss计算层面动手，几乎零成本。但它有个副作用——放大梯度会同时放大噪声，所以Scale系数不要太大，我个人经验是4到16之间比较安全，太大会导致行业数据过拟合，通用能力波动严重。

2.4 通用数据回灌：防遗忘的关键手段

CPT最大的敌人不是train loss不降，而是灾难性遗忘（Catastrophic Forgetting）。你只喂行业语料，模型确实会越来越"懂行"，但与此同时它可能慢慢忘掉怎么做好数学题、怎么写出流畅的通用文字、怎么处理它原来很擅长的一般性任务。

解决方案就是在训练数据里混入通用语料。通用数据和行业数据的配比通常在1：1到3：1之间，取决于行业数据的体量和特异性。如果你希望模型在行业能力上更精专，就把比例降一点；如果你非常看重通用能力不塌，就把通用数据比例提高。我把这个配比单独拿出来强调，因为它不是"锦上添花",而是决定CPT项目能不能落地的生死线。

一个比较稳妥的控制方式是"两阶段"：第一阶段先用高行业占比（比如通用：行业=1：2）快速注入领域知识；第二阶段切换成高通用占比（比如3：1）做"恢复性训练"，把模型的通用能力拉回来。这和健身先增肌再减脂一个道理。

3. 从原始文档到训练Token：行业语料清洗与序列构建的实战细节

这一章讲数据工程。很多人觉得数据处理是脏活累活，随便做做就行，但CPT这个环节恰恰最需要较真。喂进去的文本质量，直接决定了模型输出能力的上限。

3.1 清洗环节：宁可错杀一千，不可放过一个"坏Token"

行业语料从哪来？最常见的来源是公司内部的文档库、工单系统、质量报告、合同档案、设备手册，还有从公开渠道采集的行业网站、期刊、标准文件。这些原始材料大多是Word、PDF、HTML，甚至还有扫描件OCR出来的文本，落到你手里的时候通常都是脏的。

清洗的第一步是去噪：去掉网页导航菜单、页眉页脚、广告脚本、乱码、重复的版权声明、无意义的中间产物（比如PDF里断行的连字符）。行业文档里特别常见的问题是"表格被解析成一行行的碎片"，一个字段一个换行，这种数据丢给模型，模型会把换行符号当成正常Token去学，最后输出一堆碎块。我一般会写一套基于规则的清理流程：先做HTML标签剥离，再按行做噪声检测（比如整行只有一两个字符、连续符号超过一定长度），然后用正则做常见噪声替换。

第二步是质量打分。给每个清洗后的文档计算几个指标：平均句子长度、重复率（n-gram重叠度）、符号密度、语言困惑度（可以用一个小模型快速打分）。质量分低于阈值的文档直接淘汰，不要犹豫。有人担心优质数据被误杀，我宁可用稍高的阈值，因为一个坏数据对模型分布的污染，可能需要十个好数据才能抵消。

3.2 去重：MinHash + LSH的正确打开方式

行业数据里最容易被忽视的坑是重复。同一个设备手册，可能在几十个工单里被反复引用；同一份技术标准，可能在多个供应商文档里重复出现。如果不去重，模型会把高频重复的文本当作世界规律来学，症状就是：它会对某个固定说法"过度自信"，而在其他表达方式上一窍不通。

我推荐用**MinHash + LSH（局部敏感哈希）**做近重复检测：把文本按滑窗切成若干shingle（比如5-gram），对每个shingle计算多个哈希值，取最小值作为文档签名，然后通过LSH把相似的文档分桶。同桶内的文档再做两两精确对比，相似度超过阈值（比如0.8）就只保留质量分更高的一条。这套方案开源实现很多，比如datasketch库，不用自己从零写。

对长文档还要做内部去重，因为一个几百页的手册里可能前后重复了好几遍同样的注意事项。我会用滑动窗口对文档做子串去重，保留第一处出现，后面的重复段直接删除。这个操作能有效压缩训练Token总量，同时减轻模型对重复文本的过拟合。

3.3 格式化与序列打包：别让模型学会"读半句话"

行业文档清洗完之后，还有一个环节很多人忽略：格式转换与序列构造。原始文档的结构（章节层级、表格、列表、Key-Value键值对）本身包含信息，如果全部拍平成散文本，模型很难学到"参数名和数值之间的对应关系"。

我常用的做法是把表格转成自然语言描述。比如一张"故障代码表"，不要就这么一行行丢进去，而是转成类似这样的句子："当故障代码为E-203时，故障内容为伺服电机过温，处理建议为检查散热风扇是否正常运转。" 这样模型能学到"故障代码-现象-处理建议"之间的语义关联，而不是把表格当作一堆离散Token。

序列打包（Packing）是CPT训练里提升GPU利用率的关键操作。因为行业文档长短不一，如果每个样本都是独立的，短样本会导致大量Padding Token浪费算力。正确的做法是将多个文档拼接成一个固定长度（比如8192 Token）的序列，每个文档之间用"文档分隔符"（比如句号+两个换行）隔开，然后截断超长文档、填充短文档区间。这样GPU从头到尾都在算有效Token，显存利用率和训练吞吐都能明显提升。

另外要提醒一句：不要把头尾截断策略搞错。长文档被切断后，模型会学到"句子没说完就换下一个话题"的坏习惯，我见过模型输出到一半突然跳话题，就是因为训练数据里大量截断痕迹太重。解决办法是尽量从章节边界截断（按段落、按小节标题），而不是简单按字符数硬切。

4. 一张GPU能在多长时间内跑完？算力预算与训练工具选型

很多老板问的第一句话就是"这个训练要花多少钱"，第二个问题是"我们那几台A100够不够用"。CPT的算力消耗介于预训练和微调之间，但往大了算其实可以非常贵。这里教大家一个快速估算的方法，以及工具链怎么选。

4.1 先用FLOPs公式做一次粗算，再谈预算

模型训练的浮点运算量大致可以用一个经典公式估算：C ≈ 6 × N × D，其中N是模型参数量，D是训练Token数。注意这是理论最小值，实际因为激活重算、通信开销、非计算部分，真实吞吐会打折扣。

举个例子：7B模型，准备训50亿Token（5B）。那理论计算量就是6乘以7e9乘以5e9，约等于2.1e20 FLOPs。如果用的是8张H100，BF16下理论算力大概是每张990 TFLOPS，8张合计约7.9e15 FLOP/s。实际训练中的MFU（模型浮点利用率）按40%算比较现实，也就是约3.2e15 FLOP/s。两者一除，大概是6.6万秒，约18.3小时。也就是说，8张H100训7B模型吃5B Token，一天左右就能跑完，很流畅。

但如果是70B模型，同样吃5B Token，时间会放大10倍，8张H100要跑一周多。考虑到70B模型做全参数训练时，8张卡的显存非常吃紧，必须配合ZeRO Stage 3 + 梯度检查点，实际吞吐还会进一步下降。所以我的个人建议是：如果你还在验证阶段，先用7B或14B级别的小模型跑通数据流程和评估流程，确认数据质量没问题后再上大模型，否则一套数据没验证就烧70B的算力，纯属给机房做慈善。

4.2 工具链怎么选：Llama-Factory够用，但也有讲究

CPT的工具链，我不想写成"唯一答案"，但可以给一个大方向。目前开源生态里最主流的几套：

• Llama-Factory：上手快，配置化，支持full-tuning、LoRA、QLoRA等多种模式，CPT可以直接复用它的pre-training stage，数据集配好就能跑，适合大部分团队。
• torchtune：PyTorch官方出的微调库，代码简洁，适合想深度定制逻辑的团队，但生态相对小一些。
• PEFT + Transformers Trainer：如果你已经有一套基于HuggingFace的训练代码，用这个最顺手，其实就是写个自定义Trainer然后调用。
• Megatron-LM / DeepSpeed：百亿以上参数、多机多卡训练时的重武器，如果你要训13B以上全参模型，建议上这些，稳定性会好很多。

以Llama-Factory为例，CPT任务的YAML配置大概长这样（伪代码仅供参考，字段随版本会有变化）：

model_name_or_path: /data/models/Qwen2.5-14B stage: pt # 预训练阶段 do_train: true dataset: industry_corpus # 你打包好的训练数据集 finetuning_type: full # 全参数训练；LoRA做CPT效果一般，除非资源实在不够 cutoff_len: 8192 # 序列长度，越长越贵但上下文越好 packing: true # 开启序列打包，提升GPU利用率 learning_rate: 2.0e-5 # 从10e-5到5e-6之间调，别拍脑袋拉满 num_train_epochs: 1 # CPT一般1个epoch就够，重复多轮容易过拟合 per_device_train_batch_size: 2 gradient_accumulation_steps: 8 # 大batch提升稳定性 optim: adamw_torch lr_scheduler_type: cosine warmup_ratio: 0.03 bf16: true gradient_checkpointing: true max_grad_norm: 1.0 # 梯度裁剪，强烈建议开 save_steps: 500 logging_steps: 10

注意几点：CPT阶段我推荐全参数训练（full-tuning），LoRA在SFT阶段效果很好，但在CPT阶段能改动的参数面太窄，很难真正把新知识大规模嵌入模型。LoRA能做的更像是"让模型在新数据上换个口吻"，不足以改变知识结构。除非你的显卡实在跑不动全参，否则别偷这个懒。

4.3 混合精度、ZeRO与显存策略

显存优化的核心原则是：能少用一分是一分。BF16混合精度是目前的主流选择，相比FP16，BF16的动态范围大，训练更稳定，不需要频繁的loss scaling。7B模型BF16权重约占14GB，加上优化器状态（AdamW动量和方差）、梯度、激活值，8卡A100（80GB）跑全参7B基本够用，切14B就会比较勉强，18B以上基本要ZeRO Stage 3了。

还有一个常被忽略但很实用的技巧是激活检查点（Activation Checkpointing），开启后大约用20%的额外时间换回接近50%的显存余量，几乎是"必开的选项"。另外，梯度累积步数不要设太极端，一般积累到等效batch size为512到2048个序列之间比较合适，既能稳定训练，又不会让训练时间失控。

5. 防遗忘与验效果：CPT评估闭环到底怎么搭

训练跑完不等于项目结束。CPT最大的幻觉是"Loss降了，感觉模型变聪明了"，但实际效果如何，必须有严格的评估闭环来验证。这一章的评估方案，是我在多次项目里踩坑踩出来的。

5.1 训练过程监控：不能只盯着Loss曲线

训练中的实时监控能帮你提前发现灾难性遗忘的苗头。两个重要指标：验证集困惑度（PPL）和梯度范数。

验证集困惑度可以拆成两组来看：一组是行业数据（你希望它持续下降），另一组是通用数据（你希望它不会大幅上涨）。如果行业PPL在降、通用PPL在快速上升，说明模型正在偏向行业而忘掉通用，你需要增加通用数据混比，或者降低一点Gradient Scale。

梯度范数监控也很有价值。如果梯度范数在某个step猛增（比如从个位数跳到几十），大概率是遇到了异常batch（比如某个文档里有大段噪声或超长重复），这时要立即停止训练检查数据，而不是盲目跑完。

5.2 行业能力评估：自建评价集是刚需

训练完了怎么判断模型是否真的"懂行"？最直接的办法是自建行业评测集。找业务线的核心专家，让他们基于行业高频问题写几百条评测问答。覆盖四类能力：

• 术语理解：能不能解释行业内的黑话和技术名词。
• 场景推理：给一个复杂的设备故障现象，能不能推断出可能的根因。
• 操作建议：针对具体问题给出可执行的处置方式。
• 格式规范：生成的报告/工单格式是否符合行业惯例。

评测时不要只看回答对不对，还要看回答的"专业感"——比如是否用了行业内默认的单位、是否提到了关键的行业步骤、是否避开了常识错误。这部分判断最好让业务专家来做，算法工程师自己感觉良好不算数。

5.3 通用能力回归：拿标准基准测一下"失忆程度"

通用能力回归测试，我强烈建议用MMLU（多任务语言理解）、C-Eval（中文综合能力）和GSM8K（数学推理）三件套。不做这步，你的模型可能已经"变傻"了你都不知道。

实操时，把Base模型、CPT后模型、CPT+SFT后模型三者的分数放到同一张表里对比：

只要通用分数跌幅控制在3到5个点以内，行业能力有实质提升，这个CPT就是划算的。如果通用能力跌得太厉害，就回到第2章讲的配比去调通用数据混比，再跑一轮。

5.4 防遗忘的"回灌"修复法

如果回归测试发现通用能力出现明显塌方，最快的修复方式不是回到上一轮训练调参，而是用通用语料再做一轮小规模的复习式训练。通用数据比例调到80%以上，行业数据只需保留10%到20%，拿一个很小的学习率（比如1e-6到2e-6），跑上几百步，让模型重新"复习"一遍通用知识。这个操作在实践里救过我好几个项目，代价低、见效快，强烈推荐纳入CPT的标准流程。

6. 复盘几个典型翻车场景：Loss震荡、能力塌方与泛化崩坏

最后这部分是踩坑复盘。CPT不像SFT那样"训一版就有反馈"，它的问题往往在训练两三天之后才暴露，这时候再回头排查，时间成本已经很高了。所以我把最常见的翻车场景和排查思路整理出来，希望大家在等训练的间隙提前对照。

6.1 Loss震荡剧烈：先怀疑数据，再怀疑超参

现象：训练Loss在几百步内反复跳动，不收敛，有时候还会突然冲高。大多数人第一反应是调低学习率，但我的实际经验是——先去看数据，再动超参。

大概率是混进去了坏数据。比如某个文档全是符号、某个句子包含几十个重复字符，这种异常文本会让模型产生很大的loss spike。沙盘式排查：把最近的日志捞出来，找到loss冲高的那个step对应的数据文件，把样本打出来看，十次有九次能抓到"凶手"。解决后把异常样本清掉或做截断，loss就稳下来了。

如果数据检查完没问题，再考虑调参方向：降低学习率、增大batch size（通过梯度累积）、把max_grad_norm开得更紧（比如0.5）。这几招按顺序试，别同时全改，不然你永远不知道是哪一项起的作用。

6.2 行业知识记住了，通用能力塌了

现象：行业评测集上的得分明显上升，但MMLU、CEval分数掉了10个点以上，等于模型变成了一个"偏科的老师傅"——只会说自己那摊事，别的全忘了。

这通常是三个原因叠加：行业数据混比太高、Gradient Scale太太、训练轮数太多。我见过最夸张的案例是某个团队把行业数据跑了3个epoch，结果模型连基本的语言连贯性都快崩了。修复方案：回到第2.4节的"回灌"法，用通用数据做一轮复习式训练，同时下轮训练时把行业数据epoch控制在1，Gradient Scale从16降到8以下，再评估一轮看效果。

6.3 泛化崩坏：只会背训练文本，换个说法就露馅

现象：评测时发现模型对训练集里出现过的原话回答得特别完美，但只要换个问法、换个数据背景，就输出一堆胡话。这是典型的过拟合行业语料。

原因通常是行业语料里重复段落太多（去重没做干净）或者数据多样性不足。比如你全喂了某个厂商的设备手册，模型就会把"该厂商"的表达方式当成唯一的正确答案。解决思路：提高数据去重阈值，增加不同来源、不同撰写风格的同领域语料，同时在loss层面降低Gradient Scale，让模型多"泛化"、少"死记"。

我以前处理过一个极端案例：某团队用2000多篇招投标文件做CPT，模型在输出里开始大量复制招标文件里的固定套话，甚至把甲方的名称都背了下来。后来去重+多样化扩充语料，这个问题才缓解。做CPT一定记住：你希望模型学到的是"知识模式和领域语感"，而不是"背下数据集"。

从我自己的项目经验看，CPT是一条"上限高、下限更低"的路。做得好，模型会像真正读过十年行业文档的老师傅一样说话；做得糙，不如直接打包发给对方让他们自己调检索。建议第一次做CPT的团队，先别急着上大模型、大算力，拿一个7B模型、几十亿Token的行业数据，把从数据清洗到评估的整个闭环跑通，确认ROI为正了再全面铺开。这套方法我反复验证过，值得试试。