这个标题有点意思。很多人嘴上说“我要训一个垂直大模型”实际操作却是拉一个开源框架、装一堆文档、然后把数据丢进RAG管线就完事了。RAG当然能解决一部分“知识时效和检索引用”的问题但它跟你“真正训练一个模型”是两码事。训练意味着你要改变模型内部的参数把领域知识写进权重里而不是临时查资料拼答案。这篇文章我只聊一件事如果今天你拿到一块GPU集群、一份领域语料、一群业务方的需求从零开始“真训练”一个垂直领域大模型你到底要过哪些关卡、每一步怎么做、踩过哪些坑。我按自己做过的项目经验把完整链路拆成八步需求定标、数据工程、继续预训练、领域微调、评估迭代、对齐约束、部署上线、长期运维。每一步都有可复现的细节和参数参考不是那种“用开源库调一下就行”的模糊指导。1. 先想清楚你的“垂直领域大模型”到底是什么很多人死在第一步不是死在技术上是死在目标不清晰。垂直领域大模型不是“一个模型”它是一整套针对某个特定场景重新定制过的语言模型。你到底是想要一个懂法律条款的问答助手还是想要一个能分析病历文本的诊断辅助系统还是想要一个能生成特定格式代码的工程助手同样叫“垂直大模型”技术路径差别极大。1.1 真训练和RAG的本质差别RAG做的只是“检索拼接”把用户问题拿去搜文档搜到相关内容后塞进提示词里让模型基于这些内容回答。模型本身对领域一无所知它的行为完全依赖外部检索质量。而真正的训练是让模型的能力内化——它见过几十万甚至上亿条领域样本后本身具备领域语言习惯、推理习惯和知识结构。举一个常见的例子金融领域的年报分析。RAG方案下你问“这家公司的资产负债率为什么异常”模型其实只是把年报片段拷贝出来无法做跨章节的归纳推理。但经过继续预训练和微调的模型它会把资产负债率、流动比率、现金流这些概念以及它们之间的勾稽关系内化成一种“推理本能”你问它问题时它是在自己的参数空间里组织答案。所以一句话RAG解决“没见过”的问题训练解决“不会用”的问题。二者不冲突甚至可以叠加使用但要清楚你投入成本换来的能力是什么。1.2 基座模型选择从零预训练还是继续预训练“真正训练”这个概念也有两个层级。一个是从随机初始化开始预训练一个大模型这需要几千张卡、几个月、几十亿资金不是一般团队玩的。另一个是选择开源基座模型做继续预训练CPTContinue Pretraining和领域微调SFTSupervised 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之后模型连“11等于几”都快说不利索了。应对灾难性遗忘我实测有效的手段有三个控制垂直语料和通用语料的配比前面提到过通用数据至少要占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-5epoch数不宜多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阶段教模型“按格式回答”而偏好对齐阶段教它“什么是好回答”。现在工程上最流行的偏好对齐方法是DPODirect 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偏好数据训练拒答样本推理端加校验量化后关键错误明显量化精度损失换混合精度或更高精度量化关键场景走FP168.1 训练不稳定的排查顺序训练loss跳变时先查数据、再查超参、最后查集群环境。数据问题占比最高可能是一条非法字符、一个截断错误、一段语言混杂的文本。超参问题通常体现在warmup设置不当或学习率过高。集群环境方面要注意多卡训练时数据采样顺序不一致导致的loss抖动设置好全局随机种子。8.2 显存不够的三个解法显存不够是垂直领域团队最常遇到的问题。第一选择是减小batch size加梯度累积注意梯度累积步数增加时要同步调整学习率第二选择是使用参数高效微调比如LoRA它冻结原模型权重只训练一小部分低秩矩阵显存占用能降到原来的十分之一第三选择是换更高层级的并行策略比如ZeRO Stage 3或FSDP把优化器状态分片到不同设备。这三个手段可以叠加但也要注意叠加后训练的稳定性会下降需要更保守的学习率。8.3 垂直模型要不要一直追求大不少团队总觉得模型越大越好实际上垂直领域模型的核心优势是“专注”不是“大”。7B模型在特定领域经过良好训练往往比同等条件下部署的70B通用模型更精准、时延更低、成本更可控。而且小模型迭代快一天可以跑好几个版本大模型调一次就要等一周。做垂直领域项目我强烈建议先小后大先验证数据方向和训练流程再逐步放大规模。关于流程的一个经验总结个人这几轮垂直模型项目做下来最深的体感是训练一个垂直领域大模型真正的难点不在“训练”本身而在数据、评估、迭代这套循环体系。小规模项目甚至可以用LoRA在单卡上跑完所有步骤整套流程的逻辑完全一致。规模只是改变了训练成本和迭代周期没有改变链路结构。所以如果你正在犹豫要不要真的训练一个垂直模型我的建议是先找一块卡挑一个7B底座用几千条高质量领域数据跑通上面的完整流程感受一下每个环节的痛点和手感。这个过程中积累的认知远比你看一百篇教程有用。跑通之后再根据业务需要决定要不要上大规模。垂直领域模型不是神秘的黑魔法它就是一套工程体系无非是数据、算力、评估三个要素的反复打磨。 
长河君 · 2026/10/22 8:12:42 · 阅读 1.2k 垂直领域大模型从零训练全流程：八步构建专属AI能力
这个标题有点意思。很多人嘴上说“我要训一个垂直大模型”实际操作却是拉一个开源框架、装一堆文档、然后把数据丢进RAG管线就完事了。RAG当然能解决一部分“知识时效和检索引用”的问题但它跟你“真正训练一个模型”是两码事。训练意味着你要改变模型内部的参数把领域知识写进权重里而不是临时查资料拼答案。这篇文章我只聊一件事如果今天你拿到一块GPU集群、一份领域语料、一群业务方的需求从零开始“真训练”一个垂直领域大模型你到底要过哪些关卡、每一步怎么做、踩过哪些坑。我按自己做过的项目经验把完整链路拆成八步需求定标、数据工程、继续预训练、领域微调、评估迭代、对齐约束、部署上线、长期运维。每一步都有可复现的细节和参数参考不是那种“用开源库调一下就行”的模糊指导。1. 先想清楚你的“垂直领域大模型”到底是什么很多人死在第一步不是死在技术上是死在目标不清晰。垂直领域大模型不是“一个模型”它是一整套针对某个特定场景重新定制过的语言模型。你到底是想要一个懂法律条款的问答助手还是想要一个能分析病历文本的诊断辅助系统还是想要一个能生成特定格式代码的工程助手同样叫“垂直大模型”技术路径差别极大。1.1 真训练和RAG的本质差别RAG做的只是“检索拼接”把用户问题拿去搜文档搜到相关内容后塞进提示词里让模型基于这些内容回答。模型本身对领域一无所知它的行为完全依赖外部检索质量。而真正的训练是让模型的能力内化——它见过几十万甚至上亿条领域样本后本身具备领域语言习惯、推理习惯和知识结构。举一个常见的例子金融领域的年报分析。RAG方案下你问“这家公司的资产负债率为什么异常”模型其实只是把年报片段拷贝出来无法做跨章节的归纳推理。但经过继续预训练和微调的模型它会把资产负债率、流动比率、现金流这些概念以及它们之间的勾稽关系内化成一种“推理本能”你问它问题时它是在自己的参数空间里组织答案。所以一句话RAG解决“没见过”的问题训练解决“不会用”的问题。二者不冲突甚至可以叠加使用但要清楚你投入成本换来的能力是什么。1.2 基座模型选择从零预训练还是继续预训练“真正训练”这个概念也有两个层级。一个是从随机初始化开始预训练一个大模型这需要几千张卡、几个月、几十亿资金不是一般团队玩的。另一个是选择开源基座模型做继续预训练CPTContinue Pretraining和领域微调SFTSupervised 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之后模型连“11等于几”都快说不利索了。应对灾难性遗忘我实测有效的手段有三个控制垂直语料和通用语料的配比前面提到过通用数据至少要占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-5epoch数不宜多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阶段教模型“按格式回答”而偏好对齐阶段教它“什么是好回答”。现在工程上最流行的偏好对齐方法是DPODirect 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偏好数据训练拒答样本推理端加校验量化后关键错误明显量化精度损失换混合精度或更高精度量化关键场景走FP168.1 训练不稳定的排查顺序训练loss跳变时先查数据、再查超参、最后查集群环境。数据问题占比最高可能是一条非法字符、一个截断错误、一段语言混杂的文本。超参问题通常体现在warmup设置不当或学习率过高。集群环境方面要注意多卡训练时数据采样顺序不一致导致的loss抖动设置好全局随机种子。8.2 显存不够的三个解法显存不够是垂直领域团队最常遇到的问题。第一选择是减小batch size加梯度累积注意梯度累积步数增加时要同步调整学习率第二选择是使用参数高效微调比如LoRA它冻结原模型权重只训练一小部分低秩矩阵显存占用能降到原来的十分之一第三选择是换更高层级的并行策略比如ZeRO Stage 3或FSDP把优化器状态分片到不同设备。这三个手段可以叠加但也要注意叠加后训练的稳定性会下降需要更保守的学习率。8.3 垂直模型要不要一直追求大不少团队总觉得模型越大越好实际上垂直领域模型的核心优势是“专注”不是“大”。7B模型在特定领域经过良好训练往往比同等条件下部署的70B通用模型更精准、时延更低、成本更可控。而且小模型迭代快一天可以跑好几个版本大模型调一次就要等一周。做垂直领域项目我强烈建议先小后大先验证数据方向和训练流程再逐步放大规模。关于流程的一个经验总结个人这几轮垂直模型项目做下来最深的体感是训练一个垂直领域大模型真正的难点不在“训练”本身而在数据、评估、迭代这套循环体系。小规模项目甚至可以用LoRA在单卡上跑完所有步骤整套流程的逻辑完全一致。规模只是改变了训练成本和迭代周期没有改变链路结构。所以如果你正在犹豫要不要真的训练一个垂直模型我的建议是先找一块卡挑一个7B底座用几千条高质量领域数据跑通上面的完整流程感受一下每个环节的痛点和手感。这个过程中积累的认知远比你看一百篇教程有用。跑通之后再根据业务需要决定要不要上大规模。垂直领域模型不是神秘的黑魔法它就是一套工程体系无非是数据、算力、评估三个要素的反复打磨。