企业官网建设流程全解析

很多人一提到“训练垂直领域大模型”，第一反应是拿开源底座跑两个 epoch，或者干脆以为“接入 RAG 就算垂直领域了”。我一直觉得这两种想法都偏了：RAG 解决的是“知识检索与临时外挂”的问题，它治标；而真正的领域模型，是要把领域的行为方式、表达习惯、判断逻辑长进模型权重里——这需要实打实走完从数据清洗、继续预训练、指令微调、对齐到评估部署的全链路。这篇文章就把我实际跑过的完整步骤摊开讲，想从“会调 API”或“会搭 RAG”进阶到“真的能训一个领域模型”的开发者，应该能省下不少弯路。

我先把结论放在前面：垂直领域模型的训练，80% 的工作量不在“训练”本身，而在数据、基座选择、评估和迭代设计。你用了一个不错的中文底座，喂了 5 万条高质量领域问答，可能就已经比盲目喂 2000 万条网页语料再继续预训练效果更好。这也是很多团队一开始方向就错了的根源。

1. 先想明白：你需要的到底是“训练”还是“假装训练”

1.1 RAG 解决了什么问题，又留下了什么

RAG 的含义大家都清楚：检索-增强生成。它的整个逻辑是“模型不会的我也不硬教，我去数据库里把答案捞出来贴进上下文，让模型照着抄”。这套机制对知识密度高、答案相对确定的任务非常有效，比如企业制度问答、产品手册问答、政策条款查询。因为它把“知识存储”和“生成能力”解耦了，更新知识只需要换索引库，不需要动模型。

但 RAG 有个天然边界：它只能“引用”，不能“内化”。如果你问的是“我们这个行业的报价单为什么普遍采用这种计价方式？”，这种需要行业经验、判断逻辑和隐含规则的问题，文档里未必有现成答案，RAG 就抓瞎了。又比如“帮我把这段客户投诉改写成符合我们公司口吻的安抚话术”，这不是检索能解决的，你需要模型天然就懂这家公司的表达风格、禁忌词和语气分寸。

这背后的分野其实是：垂直领域模型的核心竞争力，不是“知道更多”，而是“更懂这个领域的说话方式和判断逻辑”。RAG 补的是前者，训练补的是后者。

1.2 哪些信号说明你真的该走训练这条路

我判断一个项目要不要真正训练模型，一般看三个信号，缺两个以上才值得开训：

• 业务场景存在“风格性输出”要求，比如固定格式的报告、特定口吻的客服话术、带行话的行业分析。这种光靠提示词约束不住，RAG 检索回来一堆原文也没法自动转换。
• 模型在领域任务上的“底线能力”不达标，比如连领域术语的指代都搞错，给的材料再全也写不出像样的产出。这说明底座本身缺这块能力。
• 你手里已经积累了大量的领域语料和反馈数据，而且还在持续增长。有数据却只拿来建索引，是一种资源浪费。

如果只是“我觉得应该有自己的模型”这种冲动，我的建议是你先别动。没有明确的能力缺口和数据储备，训练出来的模型大概率既贵又难维护，最后还得退回 RAG。

2. 数据工程：垂直领域模型的胜负手，90% 的人都低估了

2.1 数据从哪里来：三类语料各有各的脾气

真正训练垂直领域模型，数据源和 RAG 建库完全是两码事。RAG 追求的是“覆盖全”，训练追求的是“密度高、风格强”。我一般把语料分成三类：

• 领域公开语料：行业报告、论文、法规条文、技术标准、百科条目。这些数据权威性强，但表达风格中规中矩，对“领域风格内化”帮助有限，它们的价值是撑起领域常识骨架。
• 业务沉淀语料：历史工单、客服对话记录、咨询报告、内部培训材料、专家评审意见。这类数据是真正的宝藏，它包含真实场景的问题描述、被客户认可的答复、领域老手的表达习惯。缺点是噪音极大，隐私和格式问题多，清洗成本高。
• 人工构造的指令数据：社区问答、测试集、专家撰写的示范答案。这是后期指令微调阶段的“种子数据”，必须靠人力精雕细琢，量可以不大，但质量和覆盖面必须过关。

我见过一个团队做了个法律咨询模型，公开语料收集了 50GB，结果微调完之后回答还是像百度百科复读机。后来他们从律所手里拿到 3000 条真实的“客户提问-律师回复”脱敏数据，只训练了很小一个模型，回答的落点和对焦点的把握反而立刻提升。这就是业务语料和公开语料的差别。

2.2 清洗、去重与配比：比堆量更重要的三个动作

我处理数据的流水线，通常按下面这几步走，每一步都踩过坑：

第一，基础清洗。HTML 标签、无意义的换行和空格、乱码编码、页眉页脚、图表描述残留。这些不做干净，训练时模型会被垃圾格式“带偏”。尤其是爬下来的网页数据，经常一段正文后面拖着几十条无关推荐链接，轻度清洗根本去不掉。

第二，敏感与有害内容过滤。这一步不只是合规要求，更是模型安全性的根基。黑名单匹配加分类器过滤加人工抽检，三层过滤缺一不可。垂直领域尤其要小心“看起来专业实则误导”的内容，比如医疗建议、投资建议，这类内容一旦被模型学会，后果比普通垃圾数据严重得多。

第三，去重。很多人忽略去重的重要性。公开语料里同一个新闻稿可能出现在几十个网站，训练时反复看到同一段内容，等于人为放大了这段内容的权重，会让模型产生“复读机倾向”。我用的是 MinHash 做近似去重，句子级别再用 SimHash 跑一遍，经验阈值是相似度 0.8 以上直接过滤掉一条。

配比方面，我的建议是：通用数据依然占大头。垂直语料最多提到 30%-40% 的比例，再多模型可能“偏科”——领域话术倒是顺溜了，通用常识和泛化能力明显下降。你可以想象成一个厨师既通晓八大菜系又深研本地菜，才能把本地菜做得出彩；一辈子只做本地菜的师傅，遇到外地客人就束手无策了。

2.3 词表和 tokenizer 对垂直领域是否友好

这个点极容易被忽略。很多垂直领域词汇在通用 tokenizer 里会被拆得稀碎，比如“正交实验”可能被拆成“正交”和“实验”，“蒙特卡洛”可能被拆成三个字。Tokenizer 拆得碎不会让模型崩溃，但会让模型“读”起来更费劲，学到的语义关联更弱。

我处理过一个化学领域模型，发现他们用通用底座训练时，不少专业词被拆成 3-4 个 token，训练结果里这类词的用法明显不扎实。后来直接在底座基础上扩展了领域词表并做 embedding 初始化，问题改善了不少。

扩展词表不是每个项目都要做，但如果你发现领域高频词的 token 数平均值明显高于通用词，我建议加上这一步。具体做法是把领域语料喂给分词器统计高频词，人工筛选出需要合并的候选词，然后对底座的 embedding 层做维度扩展，新词的向量用相近已有词做加权初始化——这一步需要冻结原 embedding 参与后续训练，比例不能太高，否则会影响底座既有能力。

3. 基座选型与继续预训练：从“通用底座”进入“领域斜面”

3.1 基座模型怎么选：看四个维度而不是只看“打榜分”

选基座模型时，我一般看四样东西：底座的通用能力（尤其是中文表现）、开源协议是否允许商业使用、上下文长度、以及生态成熟度。

这四样里面，最容易被忽视的是协议。训练一个垂类模型通常要花不少钱，如果最后发现协议不允许商用，等于全部打水漂。我的习惯是：在选型阶段就请法务或者懂协议的人把商用许可、模型输出归属、再分发权限逐条确认一遍。

生态成熟度也很关键。同一个底座，生态好的意味着你能找到更多微调案例、量化工具链、部署框架的适配——这会省下你后面大量的排错时间。一个只有模型文件、支持工具稀稀拉拉的底座，即使评测分数高几个点，也会在部署阶段拖死你。

3.2 继续预训练的参数细节与资源估算

继续预训练（Continue Pretraining）不是必须的步骤，它适用场景很明确：你手里的领域语料大多是“文档/文本”形态，且模型在这些领域文本上的困惑度明显偏高。如果领域语料主要是问答对，直接做 SFT 反而效率更高。

决定继续预训练之后，几个关键参数我的经验值如下：

资源方面，一个 130 亿参数规模的底座，继续预训练用 8 张 80GB 显存的 GPU，配合 DeepSpeed ZeRO-3，大概能支撑 512 的批次。按 5 亿 token 数据量、单卡吞吐约 3000 token/s 来估算，总时长大致在 20 天上下。资金紧张的话可以先砍数据量，不要砍模型规模，后者更容易训练崩。

3.3 灾难性遗忘与领域能力如何平衡

继续预训练的经典副作用就是灾难性遗忘：模型学会了领域行话，却开始把“的、了”这种基础语法搞乱，或者通用知识出现张冠李戴。我的处理方式有三种，搭配着用：

• 混入通用语料：训练集里保持 60%-70% 通用语料，磨损模型既有能力。这不是浪费，是给你未来省返工成本。
• 降低学习率：继续预训练阶段 LR 要低，让模型“微调”而不是“重写”内部表征。
• 训练过程中持续做回滚验证：每个 checkpoint 保存完，先跑一组通用能力测试集（比如通用知识问答、写作基础），如果通用分掉得太多，宁可回退到上一个 checkpoint。

这里有一条我踩过坑的认知：loss 下降不等于模型变好。领域困惑度降得漂亮，通用能力可能正在悄悄崩掉。你真正要盯的是“领域损失下降”与“通用损失平稳”两条曲线一起看，而不是只看一条。

4. 领域指令微调：让模型学会“按这行的规矩说话”

4.1 指令数据的构造思路：宁可少而精，不要多而糙

领域微调阶段，数据形态从“文档”变成了“指令-回答”。这也是垂直领域模型真正开始“像专家”的地方。我的经验是，指令数据的构造必须回答三个问题：这个领域的用户到底会怎么问？被认可的专家会怎么答？哪些问法是要刻意规避的？

实际操作中，我会把指令分成任务型、知识型、分析型、纠错型几类。任务型是“把这段会议纪要按照行文规范改写成简报”，知识型是“解释产业链上游的定价逻辑”，分析型是“给这个销售数据做一个归因分析”。每一类指令，我要求不少于 200 条种子样本，且答案必须经过 2 名以上领域人员的交叉评审。

很多人觉得指令数据越多样越好，这句话只对了一半。多样性要建立在正确性之上。一份高质量的 3000 条种子数据，效果远好过 3 万条“网上随便扒的问答”。后者很可能会把模型的风格拉回通用模型，而不是“你的领域模型”。

4.2 SFT 训练参数与实践细节

SFT 阶段我的典型配置如下：

• 学习率 1e-5 到 2e-5，带余弦衰减；
• epoch 控制在 3-5 个，每 200 步存一次 checkpoint；
• 批次大小 128-256，梯度累积让总批次达到这个量级；
• 混合精度训练，损失曲线如果剧烈振荡，先降学习率而不是加数据。

SFT 过程中我习惯看两个指标：训练集精确匹配率和生成质量的抽样人工评分。原因在于 SFT 本质上是“模仿学习”，只看 loss 容易麻木。另外注意：SFT 阶段如果训练集里出现了一条错误的“标准答案”，模型会非常努力地学会它——因为 SFT 没有判别能力，它把一切示范都当成“应该这么做”。

所以在 SFT 之前，我强烈建议把所有种子数据里的每一条答案，让人重新过一遍。漏掉一条“有毒”数据，等于亲手给模型安装了一个定时炸弹。

4.3 指令数据质量排雷：我遇到的三个典型案例

• 案例一：答案里带了表格 Markdown 符号。模型学得很快，之后所有输出都莫名其妙地夹带符号。清洗时用正则把答案里的表格、链接、图片引用一律转成纯文本。
• 案例二：指令描述太长，平均超过 200 字，而真实业务提问通常就一句话。训练完之后模型变得很啰嗦，答一个问题前先来一段“理解与分析”。后来我把种子数据里约一半的指令压缩到 20 字以内。
• 案例三：正负样本失衡。某类指令全是“应该怎么做”，几乎没有“什么不该做”的样本。结果模型学会了大胆建议，不会表达拒绝。凡是涉及安全边界的任务，必须配足“兜底/拒绝”类指令。

5. 对齐与安全：垂直模型不能只会“有问必答”

5.1 用 DPO 做偏好对齐的实践

训练完 SFT 的模型，你通常会发现它水平还行，但偶尔会有“用力过猛”的表现：比如咨询场景里，用户只问了一个价格区间，模型却洋洋洒洒写了一大段行业分析。这说明模型还不会判断“什么回答在什么场景下更受认可”——这就是对齐要做的事。

对齐阶段，大团队会走 RLHF，小团队我基本推荐 DPO 路线。DPO 的优势是不需要单独训练奖励模型，只需要同一批 prompt 下有两份回答——一份是“被认可的”，一份是“欠佳的”，模型直接学偏好。

数据收集上，我采用的是“种子问题 + 模型多版本回答 + 人工排序”。具体流程是：拿 800 个高价值场景问题，用 SFT 模型、底座模型、以及微调前的历史版本各生成一遍回答，打乱顺序交给专家打分，最后筛出对比对。这个流程比较费人力，但效果直接。

DPO 训练参数我常用的是一开始 β 取 0.1 左右，学习率 1e-6 量级，只训练 1 个 epoch。DPO 特别容易过拟合，一旦过头，模型会变得油腔滑调，甚至开始用非常夸张的语气表达“我很专业”。训练完必须做一次人工盲测来把关。

5.2 安全性与“答不上来”的处理

垂直领域模型的安全性，不只是政治和敏感话题，还有一个很现实的问题：专业误导。模型如果对拿不准的法律条款、医疗建议、投资判断言之凿凿，这种“自信的错”比“不回答”危害大得多。

我的处理方式是双管齐下：一方面在指令数据中加入大量“模糊问题拒绝样本”，比如“这类问题需要专科医生面诊”“这个条款我建议以官方最新文件为准”；另一方面在做对齐时把“拒绝不当请求”作为偏好对中的优先项。

经验教训是：领域模型的安全问题，比通用模型更需要“场景化处理”。你想让模型学会的，不是“这个问题我回答不了”这种通用托词，而是符合行业规范的边界意识——知道什么该主动给、什么该引导用户找专业渠道。

6. 评估体系：不要用“感觉变聪明了”来衡量模型

6.1 一套可落地的三维评估框架

我把垂直领域模型的评估拆成三个维度：知识正确性、风格一致性、风险合规性。三个维度分开打分，合并判断，防止出现“知识全对但语气像机器人”或者“语气很好但事实错误”的偏科问题。

知识正确性：用领域留出集（模型训练时没见过的问题-答案对）做自动匹配和人工复核，重点看事实性错误率。

风格一致性：找领域老手做盲评，模型输出与“标准示范”在术语使用、句式结构、篇幅控制上是否接近。这一项主观但必须存在，因为它决定用户用起来“像不像自己人”。

风险合规性：构造边界测试题，比如涉及诊断、投资、法律承诺的问题，看模型是会谨慎兜底还是大胆断言。这项可以做成自动化测试集，每迭代一个版本都跑一遍。

6.2 和基座、RAG 基线对比时，怎么比才公平

很多团队在对比“我们的模型 vs 通用底座 + RAG”时，容易掉进一个陷阱：用自己模型的优势场景去比 RAG 的劣势场景。

公平的做法是：准备同一组业务问题集，基线方案是“RAG 增强的通用模型”，候选方案是你的领域模型，跑同一批评测标准。我还会额外做一个“交叉测试”：把领域模型的输出丢给 RAG 方案的用户看，把 RAG 方案回答丢给领域模型的用户看，看看哪边更接近用户的预期。交叉盲测的结果经常和自动指标不一致，这很正常——你要服务的是真实用户，不是评测集。

另一个我要提醒的点是：不要在评估集里复用训练数据。很多团队因为懒，评估直接用训练语料拆分，这会让分数虚高得离谱。垂直模型评估集应该单独构造，且保证与训练数据没有重叠——哪怕多花一两周人工建集，也完全值得。

7. 部署、上线与数据回流：训练结束才是闭环的开始

7.1 量化和推理优化的取舍

模型训练的终点是上线，而上线最绕不开的是推理开销。垂类模型一般规模不会太大，130 亿参数级别的模型，部署时我首选 INT8 量化，质量损失在可接受范围，显存需求能降大约一半。如果业务对速度特别敏感，再考虑 INT4，但建议量化后用评测集完整跑一遍，确认关键指标没恶化。

推理服务我用的是常见的 vLLM 方案，吞吐上比朴素的 Transformers 推理好很多。上下文长度、并发数、KV Cache 占用这三个参数需要联动配置，一个典型经验：先预估业务峰值并发和平均请求长度，反推所需的 KV Cache 大小，再确定需要几块卡——不要先买了卡再调参。

7.2 日志回流驱动的模型迭代闭环

模型上线后，真正的迭代才刚刚开始。我是这样设计回流机制的：服务层记录所有请求和回答，每周抽样两次，一次抽样 300 条，按满意/不满意/严重错误三档给结果打标，再把“严重错误”和“不满意”的样本定期流入下一轮 SFT 的数据池。

这个回流闭环是整个流程里最容易被偷懒跳过的一环。很多团队训完模型就万事大吉，等到两三个月后才发现模型已经跟不上业务变化。其实垂直领域模型的维护，本质上就是一个持续的学习工厂：上线收集反馈，反馈变成数据，数据变成新版本模型，新版本模型再上线。跑通这个闭环，比再训练一个模型更重要。

如果你想从一个最小可用版本开始，我的建议是先做 SFT，只收集 5000 条高质量指令数据，把模型训到“和 RAG 基线打平”就算及格。然后在这个基础上跑反馈回流，等数据积累翻倍后再考虑继续预训练和对齐。先跑通闭环，再追求性能，这个顺序能让你的投入产出比最大。我自己的项目就是这么滚起来的，每次都先被业务方嫌“慢”，但几个版本之后，模型在真实场景里的表现就会稳稳超过所有“一次性训练”的方案。