垂直模型落地四道关：数据域、定价权、防蒸馏与管线实践

垂直模型不是玄学这句话我做了几个企业级项目之后才真正信了。很多团队拿到开源基座、找几份行业数据、套个微调框架就觉得自己在做垂直模型结果真正交付的时候才发现模型在演示环境里很能打一进客户业务就露馅。围绕定价权、数据域、防蒸馏和四段管线这四个词我把自己踩过的坑和沉淀下来的打法整理了一遍希望能给你省掉几个月的试错时间。1. 垂直模型先想清楚再动手领域边界不是一页PPT垂直模型和通用模型之间的差距真正拉开的地方不在参数量而在于它在什么范围内可靠。通用模型是广撒网知识覆盖面大但深度有限垂直模型必须在窄范围内做到可控、可解释、可担责。这个差别决定了你从一开始就不能用通用模型的打法来做垂直模型。1.1 通用模型和垂直模型的差异不在模型大小我见过一个团队拿 13B 的开源模型做法律文书系统数据集塞了十几万条判决书上线后演示效果很不错。结果一进法务专家评审会对方拿了一批现实中常见的极端案例去测判得前言不搭后语核心法条援引直接错位。问题不是模型不够大而是他们做的是拿通用模型往行业文本上做风格迁移不是建一个数据域让模型学会行业规则。通用模型和垂直模型描述的不在一个维度。通用模型追求的是题目覆盖度什么都能聊两句深度不够是天然属性。垂直模型追求的是领域可靠度允许很多问题说不知道但在自己覆盖的范围内必须稳定正确。这个差异会连锁影响技术选型、数据建设、评测方式甚至商业定价。很多项目翻车翻的不是训练环节是认知阶段就定义错了目标。1.2 我见过的三种典型翻车现场第一种是语料等于数据。找一堆行业报告、论文、规章丢进去做增量训练模型确实变懂行了但一问到具体业务操作就含糊。原因很简单行业报告是宏观知识不是操作知识模型只学会了术语没学会流程。第二种是只喂正例。标注团队辛辛苦苦做了两万条标准问答模型训练完之后非常乖但一遇到用户绕弯子的问法、带了错别字的问法、边界模糊的问法立刻崩。原因是数据域里没有反例模型没有学过什么情况下不能这么答。第三种是评测全靠人工感觉。没有固化的评测集每次迭代都找几个业务方代表问两句你觉得行不行。这种模式在项目早期还能混到中后期一定会出大问题因为不同人对同一个回答的评价标准不一致模型改来改去越改越差。这三种翻车现场的根源都可以追溯到同一个地方领域边界没有定义清楚。1.3 一份领域边界文档应该写什么我现在的做法是任何垂直模型项目开工前先写一份领域边界文档里面至少包含五个部分目标用户与使用场景谁会用、在什么环节用、解决什么问题。输入输出约束接受什么格式的输入输出要遵守什么格式、什么长度、什么语气。硬规则清单哪些内容绝不能错哪些属于法律/事实/安全红线。不做清单哪些需求不接、哪些问题要拒绝回答、哪些功能不属于本阶段范围。错误定义与优先级什么样的回答算错误错误之间的严重级别怎么排序。我在一个医疗项目里特别强调了不做清单让模型在遇到非本院的药品咨询时主动拒答并引导用户前往急诊。表面看是限制了模型能力实际上客户非常满意因为医疗场景里不乱说本身就是核心功能。垂直模型的边界就是它的价值边界。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但只有把整条管线跑顺你才真正拥有一个能交付、能收费、能防守的产品。