企业官网建设流程全解析

垂直模型不是玄学，这句话我做了几个企业级项目之后才真正信了。很多团队拿到开源基座、找几份行业数据、套个微调框架，就觉得自己在做垂直模型，结果真正交付的时候才发现，模型在演示环境里很能打，一进客户业务就露馅。围绕定价权、数据域、防蒸馏和四段管线这四个词，我把自己踩过的坑和沉淀下来的打法整理了一遍，希望能给你省掉几个月的试错时间。

1. 垂直模型先想清楚再动手：领域边界不是一页PPT

垂直模型和通用模型之间的差距，真正拉开的地方不在参数量，而在于"它在什么范围内可靠"。通用模型是广撒网，知识覆盖面大但深度有限；垂直模型必须在窄范围内做到"可控、可解释、可担责"。这个差别决定了你从一开始就不能用通用模型的打法来做垂直模型。

1.1 通用模型和垂直模型的差异不在"模型大小"

我见过一个团队拿 13B 的开源模型做法律文书系统，数据集塞了十几万条判决书，上线后演示效果很不错。结果一进法务专家评审会，对方拿了一批现实中常见的极端案例去测，判得前言不搭后语，核心法条援引直接错位。问题不是模型不够大，而是他们做的是"拿通用模型往行业文本上做风格迁移"，不是"建一个数据域让模型学会行业规则"。

通用模型和垂直模型描述的不在一个维度。

• 通用模型追求的是题目覆盖度，什么都能聊两句，深度不够是天然属性。
• 垂直模型追求的是领域可靠度，允许很多问题说"不知道"，但在自己覆盖的范围内必须稳定正确。

这个差异会连锁影响技术选型、数据建设、评测方式，甚至商业定价。很多项目翻车，翻的不是训练环节，是认知阶段就定义错了目标。

1.2 我见过的三种典型翻车现场

第一种，是"语料等于数据"。找一堆行业报告、论文、规章丢进去做增量训练，模型确实变"懂行"了，但一问到具体业务操作就含糊。原因很简单，行业报告是宏观知识，不是操作知识，模型只学会了术语，没学会流程。

第二种，是"只喂正例"。标注团队辛辛苦苦做了两万条标准问答，模型训练完之后非常"乖"，但一遇到用户绕弯子的问法、带了错别字的问法、边界模糊的问法，立刻崩。原因是数据域里没有反例，模型没有学过"什么情况下不能这么答"。

第三种，是"评测全靠人工感觉"。没有固化的评测集，每次迭代都找几个业务方代表问两句"你觉得行不行"。这种模式在项目早期还能混，到中后期一定会出大问题，因为不同人对同一个回答的评价标准不一致，模型改来改去越改越差。

这三种翻车现场的根源，都可以追溯到同一个地方：领域边界没有定义清楚。

1.3 一份领域边界文档应该写什么

我现在的做法是，任何垂直模型项目开工前，先写一份领域边界文档，里面至少包含五个部分：

1. 目标用户与使用场景：谁会用、在什么环节用、解决什么问题。
2. 输入输出约束：接受什么格式的输入，输出要遵守什么格式、什么长度、什么语气。
3. 硬规则清单：哪些内容绝不能错，哪些属于法律/事实/安全红线。
4. 不做清单：哪些需求不接、哪些问题要拒绝回答、哪些功能不属于本阶段范围。
5. 错误定义与优先级：什么样的回答算错误，错误之间的严重级别怎么排序。

我在一个医疗项目里特别强调了"不做清单"，让模型在遇到非本院的药品咨询时主动拒答并引导用户前往急诊。表面看是限制了模型能力，实际上客户非常满意，因为医疗场景里"不乱说"本身就是核心功能。垂直模型的边界，就是它的价值边界。

2. 定价权不是喊出来的：三条硬约束决定企业愿不愿意掏钱

很多技术背景出身的人觉得"效果好了自然有定价权"，但实际签单的逻辑不是这样的。客户为什么会为一个垂直模型付费？不是因为你的模型排行榜上有名，而是因为你的产品能让他省下真金白银、少担法律责任、嵌进他现有的流程里跑起来。这三件事，我称之为定价权的三条硬约束。

2.1 可计算的降本：先算账，再谈技术

客户采购垂直模型，大多数时候不是因为它"先进"，而是因为它能替代某个以前必须靠人做的事情。想让客户掏钱，你得把账给他算清楚。

举个真实的例子。一个设备运维项目，客户原来需要三个工程师轮流看监控报告，每班八小时，每天光人力成本就是好几千。我们用垂直模型做检修报告的初筛，先把正常设备和异常设备分开，异常设备再按故障类型打标签，工程师只需要复核异常项。模型准确率做到 92% 之后，客户把三班倒调整为两班倒，人力成本直接砍掉三分之一。这个账摆在桌面上，报价就变得顺理成章。

反过来，如果只是"让写报告速度变快了一点"，这个账算不出明显金额，客户凭什么给你溢价？所以我在做产品方案的时候，会要求销售同事必须写清楚"部署前成本"和"部署后成本"的对比表，算不出账的项目宁愿不接，因为后面一定会陷入价格战。

2.2 可追溯的责任：给模型装上"证据链"

医疗、金融、法律这些强监管场景，客户真正关心的问题不是"模型能不能答对"，而是"答对了依据是什么，答错了谁负责"。通用模型给不了这种保障，但垂直模型可以通过设计做到。

我在法律项目里做了一个强制机制：模型输出任何一条核心结论，必须附带引用来源，并且引用原文要能回溯到知识库里的具体段落。没有来源支撑的句子，系统会在界面上标记为"模型推断，需人工复核"。这个设计看着不复杂，但它把模型的输出从"一个看起来有道理的黑盒回答"变成了"一条带证据链的分析建议"，客户的合规团队能拿着这个去审，责任边界立刻清晰。

不要小看这个设计，它直接影响了客户愿不愿意在合同里写"上线验收标准"。如果你的模型输出能提供证据链，客户更愿意接受"在指定场景内达到某个准确率"的验收口径，价格自然可以往上谈。

2.3 可嵌入的流程：交付的不是模型，是解决方案

我特别怕听到"我们交付一个 API，你们自己接吧"这种话。对绝大多数企业客户来说，他们不会用一个孤立模型，他们需要的是模型嵌进现有系统的能力。

垂直模型要想拿溢价，一定要想办法嵌进客户的业务流。比如客服场景，不只是"对话模型"，而是"工单分类 + 知识库检索 + 对话生成 + 人工兜底"的组合；工业质检场景，不只是"识别模型"，而是"图像采集触发 + 缺陷检测 + 生产系统告警 + 报表生成"的组合。

流程嵌入越深，替换成本越高，停用的代价越大，客户的粘性越强。定价权表面上是模型能力带来的，本质上是业务耦合度带来的。很多技术团队抱怨"我们模型比竞品好，为什么客户不买单"，答案往往就是：你只卖了一个模型，别人卖的是一个能在他办公室里直接跑起来的系统。

3. 数据域建设五步法：从领域编目到评测集固化

数据域这个词现在挺火，但很多人把它理解成"行业数据包"，这就跑偏了。数据域的本质是一套被组织过、被标注过、被验证过的知识结构，它和"原始数据收集"之间差了整整一个工程项目。我习惯把数据域建设分成五步：领域编目、采集、清洗分层、合成与标注、评测集固化。

3.1 领域编目：让业务骨干先把知识清单写出来

第一步不碰数据，先碰人。我会请几个真正在一线干过的业务骨干，让他们把目标场景里会遇到的"知识点"和"规则"一条一条列出来。不要写代码，就写文档。

做供应链场景的时候，业务骨干列出的清单里有一条："危险品运输车辆和普通车辆在路线规划上有完全不同的约束，不能混在一起生成调度建议。"这种知识，你就算给模型灌几个T的物流文档它也不一定能提炼出来，但业务骨干一句话就点破了。

领域编目的产出，是一份"领域知识清单"。它不一定全，但至少把最重要的高频知识点、核心规则、常见边界条件覆盖住了。这份清单就是数据域的骨架，后面每一步数据工作都要能映射到清单的某个条目上。

3.2 采集与清洗：别把"行业文档"当成数据域

采集阶段最常见的错误，是片面追求公开数据的规模。我在第一个垂直项目里下载了几百G行业报告，清洗完之后发现测试集上表现不错，上真实数据就拉胯。后来复盘发现，公开文档和现场真实样本之间存在严重的分布偏移。行业报告讲的是"标准情况"，真实业务里充满错别字、省略语、异常格式和打断重说。

所以采集一定要两条腿走路：公开数据管广度，现场数据管真实度。现场数据虽然又脏又乱，但它决定了模型在真实环境里的下限。清洗的时候，我会把数据分成三层，每一层的处理标准和后续用途都不一样。

这三层如果混在一起清洗，后面想调整训练配比就完全没有抓手。我见过有些团队把公开文档过一遍正则就去训练，结果模型学会了很多正确的废话，真正要它按业务标准输出的时候完全不在状态。

3.3 合成数据与反例：放大专家知识的正确姿势

真实标注数据在垂直场景里永远不够，这时候合成数据是必须的，但合成数据有讲究。我的做法是，把领域编目里固化的规则做成模板，让通用大模型基于模板批量生成候选样本，再由领域专家抽检和修正。相当于专家负责画骨架，大模型负责填肉，专家再负责质检。

这里我要重点说一个坑：反例一定要保留，而且要当作一等公民对待。

训练模型不光要让它知道"对的答案长什么样"，还要让它知道"哪些输入我不能随便答"。我做法务项目的时候，专门让律师总结了一批"边界问题"，比如"这个条款是否一定无效""这个证据是否必然被排除"，这些问题的真实答案往往是"不确定，要看具体情况"。如果我们给模型的正例太多，模型会变得过于自信，什么话都敢说。加了一定比例的反例和拒答样本之后，模型才学会在证据不足的时候说"需要进一步核实"。

合成数据的比例我一般控制在总训练集的三成到五成之间，太少没效果，太多会让模型产生"模板腔"，输出变得千篇一律。

3.4 评测集固化：数据域的宪法

数据域最后一步不是训练，而是固化评测集。我把评测集称为"数据域的宪法"，因为它是后续每一次训练迭代都必须回跑的基准线。

评测集的设计有两条原则：第一，覆盖度要匹配领域编目，每一个知识点至少有三道以上测试题；第二，要区分"记忆型问题"和"推理型问题"。记忆型问题测试模型是否记住了领域事实，比如法条生效日期；推理型问题测试模型能否在规则约束下做判断，比如给定一个案件事实判断适用哪条法律。

还有一个容易被忽略的点：评测集要保留历史版本。模型经过一轮新训练之后，如果在新评测集上分数涨了，但在旧评测集上分数跌了，说明出现了灾难性遗忘。这时候不能蒙着头继续加数据，要回看训练配方，调整数据配比。没有历史版本，你根本不知道是哪个环节引入了回退。

4. 四段管线的排布：入口、出口、和最容易断的点

垂直模型项目为什么容易做成一锅粥？因为没有节奏感。今天调数据，明天换基座，后天发现评测没过又回去改数据，项目无限循环。我后来把整个流程收敛成四段管线，每一段都有明确的入口和出口，没达到出口指标不允许进入下一段。

4.1 第一段：定义与盘点

这一段不做任何训练，产出物是领域边界文档、领域知识清单以及数据域v1评测集。

很多团队急着跑模型，跳过这一段，后果就是做到一半不断有业务方提新需求，模型边做边改，最后变成东拼西凑。我现在的做法是，项目启动前花一到两周时间专门做定义和盘点，把目标场景和边界文档一起过审。评审通过是进入下一段的唯一令牌。

这一段最容易断的点是"业务方和研发对目标理解不一致"。解决办法是在领域边界文档里写场景用例，不写抽象指标。比如"输入一段售后对话，输出故障类型和紧急程度"，这就比"提高客服效率"要清晰得多。

4.2 第二段：基座与增量训练

第二段是选基座、做领域适配训练。选基座我一般看四个维度：业务有没有多语言或长上下文需求、社区活跃度、许可证合规性、以及必要的评测项表现。基座分数高不等于适合你的场景，很多企业级项目最终卡在许可证和私有化部署要求上，这会直接推翻你的选型。

增量训练的核心是把核心规则层和知识支撑层数据喂进去，让模型"住进行业"。这一步要特别小心灾难性遗忘，所以在增量训练数据里我会保留两到三成的通用数据做回放，每个 checkpoint 都跑一遍通用能力抽查，看到通用能力明显下滑就及时调整。

这一段最容易断的点是"训练过度"和"训练不足"说不清。我一般会先跑一个小规模的增量训练，用评测集看提升幅度；如果提升不明显，先删噪声数据，而不是盲目加轮次。

4.3 第三段：指令微调与对齐

这一段的目标是让模型在业务场景里"听话"。我会把指令微调的场景按业务需求排序：一天出现几百次的高频场景先做稳，一周出现几次的长尾场景放到灰度期慢慢滚动优化。不要指望一次训练把所有能力都灌进模型，这不现实，还容易让模型在微调阶段互相打架。

对齐环节我特别看重"拒答能力"和"不确定性表达"。很多业务方一开始不理解，觉得模型老说"我不能确定"显得很弱。但上线之后他们就会发现，敢于承认不确定的模型，反而更少犯低级错误，人工复核的压力小得多。这个预期需要在第三段就对齐，否则验收的时候会被当成缺陷来打。

这一段最容易断的点是"评价标准不统一"。我建议在进入第三段之前，就把评测集和打分细则定下来，并且让业务方抽签盲测。不要用同一个模型既训练又考试，很容易自欺欺人。

4.4 第四段：灰度与防蒸馏保护

模型通过评测不代表可以立刻全量上线，我会先切一部分真实流量做灰度。灰度期间重点观察两件事：错误类型的分布是否符合预期，以及有没有异常的"模型抽取攻击"迹象。这就引出了防蒸馏，我单独放到下一节详细讲。

四段管线真正的价值，不只是让流程清晰，而是让每一段都沉淀出可复用的资产。数据域版本、评测集版本、训练配方、防蒸馏策略配置，这些东西比模型权重本身更值钱。模型可以因为需求变化被推翻重做，但这些资产能让你在下一个项目里快速起步。

5. 防蒸馏的工程化落地：护城河是攒出来的

防蒸馏为什么和定价权挂钩？道理很简单：如果你训练出的垂直模型，别人通过 API 调几千个问题就能抽走能力，自己训练一个替身模型，那你的定价权就名存实亡。防蒸馏的目的不是把产品锁死，而是抬高复制成本，让客户或者竞争对手觉得"偷不如买"。

5.1 请求侧风控：识别"模型抽取"的异常曲线

模型蒸馏攻击最常见的路径，是让攻击者通过你的正常接口批量发问题、收集高质量回答，再拿这些回答做微调数据的替代。那么请求侧的风控就是第一道防线。

我会关注这几个信号：

• 单账号 QPS 突变：正常业务一般有波峰波谷，突然变成稳定高频请求就很可疑。
• 问题覆盖度异常：正常用户通常聚焦在某几个功能模块，攻击者的问题分布会非常平均且宽泛。
• 请求返回值熵偏低：当某类问题反复以相似方式问出来，返回结果可能高度重复，这也是自动脚本的特征。

这套风控不需要多复杂的模型，规则引擎加告警就能挡掉大部分脚本攻击。但规则要谨慎配置，否则容易误伤合规客户。我记得有一次阈值设得太严，把一家正在做批量历史数据翻查的正式客户给限流了，闹得很不愉快。后续我们加了白名单机制，企业级客户可以通过报备申请豁免。

5.2 输出侧策略：扰动、分层与水印

光靠请求侧限制不够，真正懂行的攻击者会模拟正常业务流量慢慢抽，所以输出侧也要做文章。

第一是输出扰动。在不影响业务效果的前提下，对模型输出做微小的随机化调整，比如同义替换、语序调整、格式微调，让攻击者拿到的数据不够干净。但这个方法有使用边界：医疗、法律这类要求精确输出的场景不能随便扰动，否则业务方不答应。所以我一般只在非硬性约束的文本生成、摘要、对话场景用扰动。

第二是能力分层。把最值钱的领域能力放到私有化部署或者专用专有接口里，通用能力走开放接口。攻击者即使拿走了通用能力，也偷不走行业核心能力。这个思路听起来很像废话，但很多团队为了展示技术实力，恨不得把所有能力都开放出去，结果把自己的高价值模块暴露在火力之下。

第三是水印与特征标记。可以在模型输出里嵌入人类不易察觉的固定模式，比如某个特定连接词、某种标点使用习惯、某个低频的同义表达。一旦市场上出现疑似蒸馏产品，你可以拿对方的公开输出做特征比对，以此确认是否来自你的模型。这在商务维权和合同纠纷里是非常实用的证据链。

5.3 把价值搬到模型之外：防蒸馏的真正护城河

如果说前面几种手段都是"守"，那真正厉害的防蒸馏其实是"移"——把模型的价值核心从模型权重本身，迁移到模型周围的系统组件里。

我做一个行业报告生成器的时候，模型只负责写初稿，关键数字是否真实、是否引用了最新的政策文件、格式是否符合企业模板，都由外置的规则引擎和检索模块负责。攻击者就算把我这个模型完整抽走，拿到的也只是"一个没有数据源、没有校验逻辑、没有合规机制的写作工具"，复制成本远低于直接买我的整套方案。

同样的思路可以用在很多场景：客服系统的意图识别模型可以被抽走，但背后的知识库、工单流转规则、人工兜底流程很难被抽走；工业质检的检测模型可以被抽走，但产线的光学参数、缺陷判定阈值、告警联动逻辑很难被抽走。防蒸馏的终极形态，不是把模型关进一个密不透风的笼子，而是让模型成为系统里的一颗螺丝钉。螺丝钉可以被人拆走，但整条产线没那么容易搬。

最后说一个我自己在项目里的体会：垂直模型这条路，技术难度往往不在"训练出一个高分数模型"，而在把数据域、评测、定价、防蒸馏这些环节捏合成一个能持续迭代的系统。单点突破能让你做出一个漂亮的Demo，但只有把整条管线跑顺，你才真正拥有一个能交付、能收费、能防守的产品。