这个标题有点意思。很多人嘴上说“我要训一个垂直大模型”，实际操作却是拉一个开源框架、装一堆文档、然后把数据丢进RAG管线就完事了。RAG当然能解决一部分“知识时效和检索引用”的问题，但它跟你“真正训练一个模型”是两码事。训练意味着你要改变模型内部的参数，把领域知识写进权重里，而不是临时查资料拼答案。这篇文章我只聊一件事：如果今天你拿到一块GPU集群、一份领域语料、一群业务方的需求，从零开始“真训练”一个垂直领域大模型，你到底要过哪些关卡、每一步怎么做、踩过哪些坑。
我按自己做过的项目经验，把完整链路拆成八步：需求定标、数据工程、继续预训练、领域微调、评估迭代、对齐约束、部署上线、长期运维。每一步都有可复现的细节和参数参考，不是那种“用开源库调一下就行”的模糊指导。
1. 先想清楚：你的“垂直领域大模型”到底是什么
很多人死在第一步，不是死在技术上，是死在目标不清晰。垂直领域大模型不是“一个模型”，它是一整套针对某个特定场景重新定制过的语言模型。你到底是想要一个懂法律条款的问答助手，还是想要一个能分析病历文本的诊断辅助系统，还是想要一个能生成特定格式代码的工程助手？同样叫“垂直大模型”，技术路径差别极大。
1.1 真训练和RAG的本质差别
RAG做的只是“检索+拼接”：把用户问题拿去搜文档，搜到相关内容后塞进提示词里，让模型基于这些内容回答。模型本身对领域一无所知，它的行为完全依赖外部检索质量。而真正的训练，是让模型的能力内化——它见过几十万甚至上亿条领域样本后，本身具备领域语言习惯、推理习惯和知识结构。
举一个常见的例子：金融领域的年报分析。RAG方案下，你问“这家公司的资产负债率为什么异常”，模型其实只是把年报片段拷贝出来，无法做跨章节的归纳推理。但经过继续预训练和微调的模型，它会把资产负债率、流动比率、现金流这些概念以及它们之间的勾稽关系内化成一种“推理本能”，你问它问题时，它是在自己的参数空间里组织答案。
所以一句话：RAG解决“没见过”的问题，训练解决“不会用”的问题。二者不冲突，甚至可以叠加使用，但要清楚你投入成本换来的能力是什么。
1.2 基座模型选择：从零预训练还是继续预训练
“真正训练”这个概念也有两个层级。一个是从随机初始化开始预训练一个大模型，这需要几千张卡、几个月、几十亿资金，不是一般团队玩的。另一个是选择开源基座模型做继续预训练（CPT，Continue Pretraining）和领域微调（SFT，Supervised Fine-Tuning），把领域能力注入已有的通用模型里。绝大多数有垂直领域需求的团队，实际做的是后者。
基座模型的选择有讲究。我试过几种路线，总结出来的经验是：
- 通用能力越强的底座，领域化之后效果越好，但训练成本越高
- 底座参数不是越大越好，要看推理成本和领域任务的复杂度，7B到14B是垂直领域的黄金规模
- 中文领域要优先看中文语料占比高的基座，很多英文强模型的中文能力明显偏弱
- 关注底座的上下文长度，这决定了你后续数据处理的上限
我的建议：初次做垂直领域模型，选一个大家都在用、社区活跃、有大量经验帖的7B或14B开源底座，不要追求参数最大。先把整个链路跑通，再考虑升级底座。
1.3 从算力倒推方案：一张卡也能训，但效果有边界
很多团队问的第一个问题是“我没有那么多卡怎么办”。回答这个问题前，先算一笔账。继续预训练阶段，一个14B模型，如果用单机8卡A100（每张80G显存），配合DeepSpeed ZeRO Stage 3或者FSDP，大致能支撑百万级别的数据量训练。如果你的语料达到数十亿token级别，那就不是“垂直微调”而是“领域预训练”了，单机很难吃得消。
我见过最务实的做法是：先用小模型跑通完整流程，比如用7B底座，在单机4卡上训练，确认所有步骤没有bug后，再上大规模集群做正式训练。训练一次的成本低，跑一轮可能也就几小时到十几小时，非常适合团队快速验证方向。不要一上来就追求最大规模，那是大厂的事情，垂直领域团队最重要的指标是“迭代速度”。
2. 数据工程：决定模型上限的那90%
如果说模型架构决定了下限，那数据质量直接决定上限。一个垂直领域模型的水平，约等于你喂给它的语料的水平。这个环节通常占整个项目60%以上的工时，也是最容易让人崩溃的环节。
2.1 数据从哪来：采集、清洗、过滤三步走
垂直领域的数据来源大概有四类：公开数据集、业务系统沉淀数据、行业报告和文档、人工构造数据。初次做的人容易犯一个错误：以为公开数据集拿来就能用。实际上，公开数据集的噪音比较大，格式不统一，甚至有很多错误信息，如果直接丢进训练，模型学到的不仅是领域知识，还包括错误的表达习惯。
清洗是我花时间最多的环节。需要处理的脏数据包括：重复段落（不同网页复制粘贴导致的冗余）、乱码文本（PDF转换产生的乱码）、模板化内容（页眉页脚、导航链接、广告文本）、不完整句子（截断导致语义断裂）。我常用的一套流程是：
- 先做语言识别，丢掉非目标语言的内容
- 再做规则过滤，按行或按段落清理HTML残留、超长无标点文本、纯数字序列
- 用启发式规则识别并移除页眉页脚，比如那些在全文反复出现且不符合语法特征的短句
- 最后做一次困惑度过滤，用一个小的通用语言模型跑一遍语料，把困惑度异常高（说明语义混乱）和异常低（说明是重复文本）的样本筛掉
2.2 去重与配比：像配菜一样控制比例
数据清洗完还要做去重。网上有大量重复传播的文章，如果不做去重，模型会严重偏向这些重复出现的表达模式。去重有两个层次：一个是MinHash做近似去重，把相似的段落聚在一起；另一个是精确去重，直接按哈希值匹配。对于垂直领域，我建议至少做到MinHash层次，阈值设在0.8左右，也就是说两段话80%雷同就去掉一条。
去重之后是配比，这是新手最容易忽略但影响巨大的环节。垂直领域模型不是只学垂直数据就行的，还需要保留通用能力。如果语料里只有法规条文和案例判决，模型尽管精通法言法语，但可能连基本的日常对话能力都退化。这就是灾难性遗忘的开始。我的经验配比大概是：垂直语料占60%到70%，通用语料占30%到40%。通用语料不一定多，但必须能稳住模型的基础能力。
2.3 CPT和SFT需要不同的数据形态
继续预训练和微调需要的数据形态完全不同，很多人把这两种数据混在一起做，结果训练完什么都沾一点，什么都不精。
继续预训练阶段，数据形态是纯文本，不需要问答对，只需要段落或篇章级别的原始文本。它的目标是让模型适应领域的语言风格和术语体系。而微调阶段，你需要的是“指令-回答”对，而且要有针对性地覆盖业务场景中的各种提问方式。CPT是学语言和知识，SFT是学行为和规范，这两种数据的组织方式、来源、质量要求都不一样，可以共用一部分原始素材，但处理流程必须分开。
3. 继续预训练：把你的领域写进参数里
继续预训练（CPT）是整个训练链路中最需要技术判断的环节，也是最容易翻车的环节。很多人以为CPT就是拿领域语料“再训一会儿”，实际上它有自己的训练目标、超参空间和风险评估。
3.1 训练目标与样本构造
CPT的核心目标不是让模型“学会回答问题”，而是让模型“熟悉这个领域的表达”。训练目标跟预训练一样，是最基础的自回归语言建模——给定前文预测下一个token。训练样本不需要指令模板，直接喂纯文本就行。比如法律领域，喂的就是法条、判决书、司法解释；医疗领域，喂的是论文摘要、病历、临床指南。
样本构造有几个细节需要注意。一个是长度问题，尽量把样本切成和模型上下文长度匹配的序列。比如模型上下文是4096，那每个训练样本最好是完整的、接近4096但不超过的序列，这样训练效率最高。另一个是切分方式，不要硬切，如果一个段落被截断，尽量选择在语义完整处切，否则模型会学到大量半句话。我常用做法是：先按自然段落做聚类，把语义相关的段落拼成一个训练序列，不足部分用下一个文档的头部补足，这样损失函数比较平滑。
3.2 关键超参数：学习率是个精细活
CPT阶段的学习率设置和通用预训练不一样。通用预训练是“从零学起”，学习率可以相对高；而CPT是在已有参数基础上做增量注入，学习率必须低，否则会把原有的模型能力冲掉。我常用的初始学习率区间在1e-5到3e-5之间，配warmup比例大概在总步数的3%到5%，再配合余弦退火把学习率降到接近0。
观察训练状态，主要看两个指标：loss值和困惑度。loss应当平稳下降，不应该出现明显的阶梯式跳变。如果训练到一半loss突然升高，优先检查数据里有没有异常样本——比如某一段文本混入了另一种语言，或者有一段数据前后不连贯导致loss暴涨。这些拖尾问题经常出现，处理办法是在训练脚本里加基于loss的过滤逻辑，遇到单样本loss高于中位数数倍的样本直接跳过，稳定整体训练曲线。
3.3 灾难性遗忘：通用能力崩了怎么办
CPT最常见的翻车现场：领域知识学得不错，但对话能力、数理能力、指令遵循能力全面退化。这就是灾难性遗忘。我之前做过一个税务领域的模型，CPT阶段跑了十几万个step之后，模型连“1+1等于几”都快说不利索了。
应对灾难性遗忘，我实测有效的手段有三个：
- 控制垂直语料和通用语料的配比，前面提到过，通用数据至少要占30%
- 用混合训练策略，每个batch里既包含垂直语料，也包含通用语料，让模型每时每刻都在温习通用能力
- 在CPT之后做一次“通用能力恢复微调”，用一部分通用指令数据重新校准模型的行为
其中第二个是核心，第三个是兜底。如果做完CPT发现通用能力有退化，不要慌，靠后续的SFT和恢复训练完全能拉回来。
4. 领域微调：让模型学会“回答问题”
继续预训练做完了，模型已经“懂行”，但它可能还是一张不会开口说话的嘴。微调，也就是SFT，负责教会模型以正确的形式回答问题。这一步是离业务最近的一环，数据质量直接决定用户体验。
4.1 指令模板与数据格式
SFT数据的标准形态是“指令-回答”对，但在实际操作中，指令格式设计非常影响训练效果。我见过不少团队直接把用户问题当作指令，输出当回答，丢进去训练。这样做不是不行，但会导致模型对指令变体不敏感：业务用户换了一种问法，模型就容易懵。
我的做法是构建一套多轮指令模板，把同一条知识改写成多种问法。比如某条法律条款的含义，可以问成“这条怎么理解”、“适用条件是什么”、“跟上一款有什么区别”等不同的样子。具体实现上，我用了一套chat模板，比如用某个开源的对话模板把用户query和模型answer组织成如下格式：
<|im_start|>system 你是一个专业的金融领域助手，请根据你的知识回答用户问题。 <|im_end|> <|im_start|>user 请解释一下减值准备和公允价值变动对利润表的影响。 <|im_end|> <|im_start|>assistant 减值准备和公允价值变动在会计核算上都会影响当期利润…… <|im_end|>这个格式不是随便定的，它必须跟基座模型预训练时用的对话格式保持一致。如果底座用的别的格式，你却用了一套自定义模板，训练完模型行为很可能混乱。这一步千万不能自创，先查底座的说明文档。
4.2 批次控制与过拟合判断
SFT阶段的超参跟CPT又不一样。学习率可以比CPT略高，常用区间在1e-5到2e-5；epoch数不宜多，2到4个epoch是常见的合理区间，再多就过拟合了。SFT阶段过拟合的表现不是“背答案”，而是模型只会回答训练集里的问法，换一种问法就不知所云。这比单纯背答案更隐蔽。
判断过拟合的一个实用技巧：训练过程中定期拿一小批复现验证集（跟训练数据不同但同分布的样本）看生成效果。如果训练集loss还在下降，但验证集上回答质量已经变差，那就停。我习惯把训练分成多个checkpoint保存，每跑一个epoch存一次，最后在验证集上对比各checkpoint的效果，选最优的那个。这个做法救了我好几次，特别是当训练过程被其他任务打断了很久、回来忘了该选哪个checkpoint的时候。
4.3 多轮对话指令与通用能力保留
垂直领域模型在实际业务中很少只被问一句就走，大概率会遇到追问、澄清、指代。比如用户问“这个案件适用哪条法律”，你回答了，用户可能紧接着追问“那这条法律有没有例外情况”。模型如果只训练了单轮问答，它根本抓不住“这条法律”指代什么。
所以SFT数据里至少要保证20%到30%是多轮对话样本。构造这些样本时要注意上下文连贯，不能把不相关的问答强行拼在一起。另外，SFT阶段也需要混入一部分通用对话数据，原因跟CPT一样——防止模型在学会了领域行为之后，丢掉通用的礼貌性表达和开放性追问能力。我通常的做法是领域指令占70%，通用指令占30%，这个比例可以根据业务形态微调。
5. 评估与迭代：不评估等于白训练
很多团队辛辛苦苦训完一个模型，上线之前只做几个样例测试，觉得“看起来不错”就发布了。这是垂直模型项目中最大的隐患。垂直领域的用户需求通常非常具体，一个错误答案可能不只是“不好笑”，而是会直接误导业务决策。评估体系不是可选项，是必选项。
5.1 评估集怎么建
评估集是衡量模型能力的“考卷”，它的构建质量决定了你判断模型好坏的水平。评估集不能全从训练数据里抽，那样测出来的都是“背题能力”。我建议按业务场景构建一个梯度化的评估集：
- 基础能力题：领域名词解释、概念问答，考察知识掌握程度
- 推理应用题：需要结合多个知识点进行推导的问题，比如基于财务数据判断经营风险
- 边界题：模糊的、有歧义的、甚至故意设坑的问题，考察模型的判断力和拒答能力
- 通用能力题：用通用数据集里的一部分样本，确认模型没有“遗忘”
每个场景至少准备200到500条，太少了测不出稳定差异。评估集的数据来源最好是业务侧真实收集的用户问题，而不是我们自己拍脑袋编的。
5.2 指标怎么选：传统指标加模型打分
评估指标的选择要分任务类型。如果是生成式问答，用传统的BLEU或ROUGE只能测字面相似度，测不出语义质量——模型明明换个说法把正确意思表达得更清楚，ROUGE分数反而更低。所以在垂直领域，我基本都是“传统指标+LLM-as-Judge（用大模型当裁判）”的组合拳。
具体做法是：拿通用能力最强的一个大模型当裁判，让它给待评估模型的回答从“事实正确性”“完整性”“相关性”“表达清晰度”四个维度打分，每个维度1到5分。把裁判的评分提示词固定下来，每次评估都用同一套标准跑，保证横向可比。裁判模型本身也会误判，所以我会定期抽查裁判的评分跟人工评分的一致性，发现系统性偏差就调整评分提示词。
5.3 跑完一轮怎么分析bad case
评估只是手段，真正的目标是找到bad case并改进。每轮评估之后，我习惯把所有得分低于4分的回答整理成一张表，逐条看是哪个环节出的问题。归类下来，最常见的几类：
- 知识不足型：模型不知道某个术语或事实，说明CPT语料缺失
- 表达错误型：知道答案但输出啰嗦或表述不清，说明SFT样本质量不高
- 推理错误型：多步推理中间某一步错了，需要优化SFT数据的推理链条
- 幻觉型：模型自信地给出了错误事实，这种最危险，需要检查数据里是否有互相矛盾的信息
每类问题对应不同的修复动作，而不是简单粗暴地“再加数据”。修完再评估，再分析，形成闭环。垂直模型项目的效果提升，靠的就是这种一轮一轮的迭代打磨。
6. 对齐与安全：模型好使的前提是可控
训练完一个能回答问题的模型还不够，你还得让它“知道什么能说、什么不能说、怎么说合适”。专业领域中，错误信息的危害远大于“不知道”。对齐训练是最后一道防线。
6.1 从SFT到偏好对齐
SFT阶段教模型“按格式回答”，而偏好对齐阶段教它“什么是好回答”。现在工程上最流行的偏好对齐方法是DPO（Direct Preference Optimization，直接偏好优化），相比传统RLHF，它不需要单独训练一个奖励模型，训练成本和稳定性都好很多，很适合中小团队。
DPO的训练数据是一组组“偏好对”：同一个问题，给一个“被偏好的回答”和一个“不被偏好的回答”，让模型学会往好的方向偏移。在垂直领域，这两个回答可以由领域专家手工编写或改写。比如医疗场景，一个严谨的回答应该先声明“这只是一种可能”，而一个不严谨的回答可能直接给出绝对化的诊断建议。把这两种回答配成一对，就是一条偏好数据。
6.2 护栏与输出约束
偏好对齐解决的是“倾向”，输出约束解决的是“底线”。垂直领域模型的输出约束最好在系统层做双重保险：训练阶段，在SFT和DPO数据中加入“拒答”样本，让模型遇到超出自身能力范围的问题时主动说“我不确定”或“建议咨询专业人士”；推理阶段，在后处理环节加入关键词过滤和长度控制，防止模型生成包含敏感内容或超过业务需要长度的回答。
这里特别提醒一下：不要过度约束。之前我把拒答样本比例加到20%，模型变得过于保守，很多明明能回答的问题也开始拒答，用户体验直线下降。后来把拒答样本降到5%到8%左右，同时配合推理阶段的置信度判断，才找到平衡点。
7. 部署与上线：模型训练完只是开始
模型训练好、评估通过，只是万里长征走完了一半。部署环节有大量工程问题，处理不好，再强的模型也撑不住业务压力。
7.1 推理性能优化：降低延迟和成本
垂直领域模型通常部署在自建服务器或内网环境，推理性能是首要考量。14B模型在FP16精度下推理，单卡A100大概能跑每秒几十个token，对大多数非实时业务够用，但对实时交互场景来说延迟偏高。我的常规做法是：
- 用量化把模型压到INT8或INT4，显存占用和延迟都能减少一半以上，精度损失在可控范围
- 用vLLM或类似的推理框架做批量调度和Continuous Batching（连续批处理），并发吞吐量比朴素实现高出数倍
- 开启KV Cache复用，处理长对话历史时，复用已经计算过的注意力缓存，显著降低重复计算
我踩过一次比较深的坑是量化精度损失：某次用INT4量化一个医疗问答模型，大部分回答没问题，但涉及剂量计算的问题开始出现严重错误。后来改成混合精度策略——关键术语识别和计算类问题走FP16分支，普通问答走INT4分支，才算解决。这个经验说明，量化方案上线前一定要过一遍完整的评估集，不能只看几个样例就拍板。
7.2 持续迭代与数据回流
垂直领域模型上线后，真正的价值之旅才刚开始。业务每天都会产生大量用户问题，这些数据如果不收回来重新训练，模型效果就永远停留在上线那一刻。我建议搭一套简单的数据回流机制：线上使用过程中记录用户提问和模型回答，定期做人工标注，把高质量的问答对补充进训练集，把不满意的问题挑出来重写。
持续的增量训练会面临灾难性遗忘，因此每做一轮增量SFT，都要重新跑一遍之前的评估集。如果发现某个方向的能力明显退化，就该像前面说的那样，把对应场景的旧数据重新混入训练样本，而不是只往里面加新数据。
8. 常见问题与避坑实录
最后整理一些实操中反复出现的问题，直接给排查思路和解决方案。
| 问题现象 | 可能原因 | 处理建议 |
|---|---|---|
| 训练loss大幅震荡不下降 | 数据里有异常样本或参数过大 | 检查数据清理逻辑，调低学习率 |
| loss已收敛但回答效果差 | 数据质量差或评估集不匹配 | 重新审视数据清洗，增加人工评估样本 |
| 训练中显存OOM | 单卡无法承载大batch | 减小batch size，开启梯度累积，使用ZeRO/FSDP |
| 领域知识有了，通用能力崩了 | 灾难性遗忘 | 增加通用语料比例，做通用能力恢复微调 |
| 换一种问法就不会回答 | SFT过拟合 | 减少epoch，增加指令多样性，扩充多轮数据 |
| 模型一本正经胡说八道 | 幻觉问题 | 增加DPO偏好数据，训练拒答样本，推理端加校验 |
| 量化后关键错误明显 | 量化精度损失 | 换混合精度或更高精度量化，关键场景走FP16 |
8.1 训练不稳定的排查顺序
训练loss跳变时，先查数据、再查超参、最后查集群环境。数据问题占比最高，可能是一条非法字符、一个截断错误、一段语言混杂的文本。超参问题通常体现在warmup设置不当或学习率过高。集群环境方面要注意多卡训练时数据采样顺序不一致导致的loss抖动，设置好全局随机种子。
8.2 显存不够的三个解法
显存不够是垂直领域团队最常遇到的问题。第一选择是减小batch size加梯度累积，注意梯度累积步数增加时要同步调整学习率；第二选择是使用参数高效微调，比如LoRA，它冻结原模型权重，只训练一小部分低秩矩阵，显存占用能降到原来的十分之一；第三选择是换更高层级的并行策略，比如ZeRO Stage 3或FSDP，把优化器状态分片到不同设备。这三个手段可以叠加，但也要注意叠加后训练的稳定性会下降，需要更保守的学习率。
8.3 垂直模型要不要一直追求大
不少团队总觉得模型越大越好，实际上垂直领域模型的核心优势是“专注”，不是“大”。7B模型在特定领域经过良好训练，往往比同等条件下部署的70B通用模型更精准、时延更低、成本更可控。而且小模型迭代快，一天可以跑好几个版本，大模型调一次就要等一周。做垂直领域项目，我强烈建议先小后大，先验证数据方向和训练流程，再逐步放大规模。
关于流程的一个经验总结
个人这几轮垂直模型项目做下来，最深的体感是：训练一个垂直领域大模型，真正的难点不在“训练”本身，而在数据、评估、迭代这套循环体系。小规模项目甚至可以用LoRA在单卡上跑完所有步骤，整套流程的逻辑完全一致。规模只是改变了训练成本和迭代周期，没有改变链路结构。
所以如果你正在犹豫要不要真的训练一个垂直模型，我的建议是：先找一块卡，挑一个7B底座，用几千条高质量领域数据跑通上面的完整流程，感受一下每个环节的痛点和手感。这个过程中积累的认知，远比你看一百篇教程有用。跑通之后，再根据业务需要决定要不要上大规模。垂直领域模型不是神秘的黑魔法，它就是一套工程体系，无非是数据、算力、评估三个要素的反复打磨。
