垂类模型和垂域模型的区别

做行业项目时经常听到「垂类模型」「垂域模型」两个词被混着用：有人拿去指行业微调模型，有人拿去指某个任务专用的小模型，报价和交付标准也跟着乱。这篇不讲概念史，只把两者的判断边界、适用场景和选型动作拆开，帮你下次开会时能当场分清对方说的到底是哪一种，以及自己该按哪条路去验收。

做行业项目时，「垂类模型」和「垂域模型」这两个词经常被混着用。有人拿它指行业微调模型，有人拿它指某个任务专用的小模型，结果报价口径和交付标准跟着乱。这篇不讲概念史，只把两者的判断边界、适用场景和选型动作拆开，帮你下次开会时当场分清对方说的到底是哪一种，以及自己该按哪条路去验收。

先说个前提：两个词的差别不在规模、不在有没有微调，而在你给它划的那条「边界线」画在哪。判断的核心不是听对方怎么命名，而是看他实际交付的东西覆盖多宽、输入输出稳不稳、换个相邻任务还灵不灵。下面按这四个角度把边界和用法讲清楚。

先把两个词的边界画出来

垂类看的是「行业/场景」这条线：面向法律、医疗、金融、电商这类行业整体，能力可以横向铺开，覆盖多种意图。垂域看的是「任务/子领域」这条线：只覆盖行业里的一个窄口子，比如合同条款比对、票据字段抽取、投诉工单归类，输入输出基本固定。两条线的画法不一样，带来的验收标准也完全不同。

实操上可以用三个问题快速归类：输入输出是否固定、覆盖面有多宽、换一个相邻任务还灵不灵。三个都答「窄」的，基本就是垂域；答「宽」且能跨场景的，偏垂类。别按厂商宣传用词下结论，按他实际交付的东西归类。跨行业通用模型即使被包装成某个行业的名字，也不属于这两类，别硬套。

什么活儿该找垂类，什么活儿该找垂域

一个实用分法是看「人和模型的互动形态」。流程长、环节多、需要和人来回对话的岗位——客服、法务初筛、投研问答——偏垂类路线，因为要覆盖的意图太散，单点做深反而接不住用户随口问的下一句。字段级、规则级、有明确对错的环节——信息抽取、分类打标、单据核对——偏垂域路线，单点做深反而更稳、更容易验收。

• 客服、导购、初筛问答：意图发散、需要多轮，走垂类更省心
• 票据字段抽取、合同条款比对：有标准答案，走垂域更可控
• 质量抽检、合规打标：先确认口径是否稳定，稳了再考虑垂域
• 文档摘要、跨文档问答：边界模糊，垂域硬做容易反复返工
• 混合场景：外层用垂类做交互与路由，内层挂一个或多个垂域小模型干脏活

有个反向判断值得记住：如果任务本身没有稳定输入格式、口径每天在变，这时候硬做垂域，标注和维护成本会先把预算吃光。这类活儿更该先做流程标准化，再谈模型选型，而不是反过来指望模型去兜住混乱。

选型和验收的对照清单

先定边界再比模型。把任务拆成「必须答对」和「答错可接受」两栏：垂域的验收阈值通常要比垂类严得多，因为它的失败往往是硬错，不像垂类还能靠追问澄清。阈值怎么定，取决于这个错误传到下游会引发什么后果，而不是取决于模型本身看起来多聪明。

1. 拆任务把业务拆成必须答对和答错可接受两栏，写清每栏的判定口径，别用「大概准」这种词
2. 定阈值按错误后果定验收线，垂域任务通常要字段级核对，垂类任务用人工抽检加多轮评估
3. 抽样本验收样本按真实分布抽，别只用干净样例；垂域模型对格式变化敏感，换一版上游模板就可能掉分
4. 看交付形态确认是给权重、给接口还是给带界面的工具，三者后续维护责任完全不同，到 /open-weight-license-basics 把许可条件读一遍
5. 算总账除调用费外，把人工校验、标注回流和改版重训一起算进去，垂域模型的隐性成本往往藏在这两项

预算这件事容易被低估。垂域模型的单次推理可能很便宜，但标注回流和上游模板一变就要重训，长期成本未必低。具体数字各家差异很大，建议到 /price-watch 看当时的行情，别拿旧报价做决策。

几个容易踩的混淆点

第一个混淆是把「参数小」当垂域。小模型可以是通用模型，大模型也可以是垂域模型，规模和能力边界是两回事。一个参数量不大的通用对话模型，照样能答各种行业问题；反过来，一个很大的模型只干票种识别一件事，它也是垂域。看边界，别看大小。

第二个混淆是把「微调过」当垂类。拿几百条数据在通用模型上做一次微调，得到的是任务适配版，不代表有了行业级覆盖。第三个是把「能回答行业问题」当行业能力：问得动和答得准之间还隔着知识更新、引用来源和责任划分三道坎。

想核对手上的模型到底归哪类，可以到 /ai-dict 把术语口径对齐，再去 /stacks/specialized-models 看同类目录里别人是怎么归类的。归类本身没有绝对对错，关键是你和对方用的是同一套口径，不然验收时各说各话。