垂类模型和通用大模型的区别，怎么做和怎么选

很多人是这么卡住的：通用大模型效果还不错，但行业术语、口径、格式总是差半口气，于是开始想要不要上垂类模型。可真去问供应商，对方说的「垂类」和你想的不是一回事。这篇先把两者的能力边界拆开，再给一套从场景到验证的判断步骤，帮你决定这个环节该用通用模型加约束，还是砸钱做专属模型。

很多人是这么卡住的：通用大模型效果看着还行，可一碰行业术语、内部口径、固定格式就总差半口气。于是有人开始想，要不要弄个垂类模型。可真去问供应商，对方嘴里的「垂类」和你想的往往不是一回事——有的只是微调了一下通用模型，有的拿提示词包了一层，有的才是真正在领域数据上预训练过的。

所以这事得拆成两条线看：一条是能力边界，谁的错更少、在哪种错上更少；另一条是落地成本，钱和人力到底砸在哪一段。两条线对上了，选型才站得住。下面按「先把口径对齐、再看能力边界、再算成本、最后走判断步骤」的顺序讲，尽量给能直接用的东西。

先对齐口径：什么样的东西才算垂类模型

市面上一堆叫「行业大模型」「垂直大模型」的东西，能力上限差得很远。谈需求之前，先让对方把形态说清楚，别被一个词糊过去。最省事的办法是拿一张对照表去核对：它是微调出来的，是在领域语料上预训练出来的，是专门做一件事的小模型，还是只是提示词加工作流的套壳方案。

判断是不是「真垂类」，看三处就够了：训练数据有没有真的覆盖这个领域；输出是不是稳定符合行业口径，而不只是偶尔对一次；以及换个任务是不是立刻拉胯。第三条最容易被忽略——只在一个任务上表现好、稍微变个问法就乱，多半说明它学到的是模板，不是领域知识。

能力边界差在哪：不是谁更聪明，而是谁更不容易出错

两者不是「水平高低」的关系，是「在什么错上更少犯」的关系。通用大模型强在世界知识和泛化，遇到没见过的问法也能接住；弱在必须按你们规矩来的地方：术语怎么叫、数值口径怎么算、格式怎么排、引用哪些来源。这些地方它没有内部约定，只能靠你外面加约束。

垂类模型的优势通常来自约束和分布匹配，不是参数量比别人大。所以别指望它在开放问答、跨领域推理上压过通用模型，那本来就不是它的战场。反过来，如果你的任务输入分布很散、问法千变万化，专属模型反而更容易崩。

给每个任务单元过一遍下面三项，三项都偏严，才值得认真考虑垂类路线。只有一项严，先去试通用模型加约束，成本低得多。

• 错一次的代价：错了要不要返工、要不要对外解释、有没有合规风险；代价高的任务，优先压低方差
• 答案有没有唯一标准：能对口径、能拿规则判对错的，适合用约束或专用模型固化；开放讨论类任务交给通用模型
• 输入会不会跑出分布：真实输入如果长尾很多、问法很活，专属模型的稳定性优势会被稀释

反过来说，如果某个任务错误代价低、答案本身就模糊、输入又千奇百怪，那不管供应商怎么说，用通用模型加人工抽检更划算。这一点在后面的成本一节还会反复出现。

落地成本结构：钱花在哪、什么时候不值

垂类路线最容易被低估的不是训练本身，而是训练之外那几块：数据标注与清洗、评测集建设、上线后的回归监控。训练是一次性投入，后面这些是持续的。具体量级别听口头报价，到 /stacks/fine-tuning 看各家服务商当时的口径，再按你们的数据脏乱程度往上加。

通用模型加提示词、加检索、加输出校验，前期确实便宜，但每次需求变更都要回头调约束，长期维护成本会慢慢爬上来。两条路线的成本不是简单比大小，而是比「钱花在哪个阶段」。

• 领域知识更新快：知识一变模型就过时，重训频率跟不上，先别碰专属模型
• 需求还在快速试错：业务形态一周一变，这时选型结论很快就会过期
• 单日调用量很小：投入摊不开，通用加约束更务实
• 团队没人维护评测集：模型再好也没法验证，等于裸奔

这几种情况不是「永远不能做」，而是「现在做不划算」。等业务定型、需求稳定、调用量上来了，再回头评估专属路线，判断依据会清楚得多。

选型四步走：从场景切分到小规模验证

别整体评估「要不要上垂类模型」，那是个没法回答的问题。按任务单元拆开，一步步收敛，每一步都有能验证的产出。

1. 第一步：切场景把业务拆成任务单元，逐个标「通用够用 / 差一点 / 完全不行」。标注要有真实样本支撑，别凭印象；标完统计一下三类各占多少。
2. 第二步：定基线先用通用模型加提示和输出校验跑一批真实样本，把错例分类：是知识不知道、格式不合规，还是推理不稳。这一步的结论决定后面走哪条路。
3. 第三步：选路线错误集中在知识和口径，优先检索加后处理；集中在稳定输出风格、且手里有足够多高质量样本，才考虑微调或专用模型。顺序别倒过来。
4. 第四步：设退出条件上线前写清什么指标不达标就回退到通用方案，比如错例率、人工返工率或延迟。没写退出条件的项目，最后往往陷在半死不活的状态里。

第三步是最容易走偏的地方。很多人一上来就想微调，其实大多数「差半口气」的问题是知识没接上或格式没管住，用检索加后处理就能解决大半。把错误分类做扎实，比急着训练模型有用。

投产前的验证清单：别只看演示

演示是挑好的场景给你看，验证得自己去挑难看的场景。自建一批测试集，规模不用大，但要脏：包含长尾输入、边界问法、故意写错的输入，以及你们业务里真实出现过的坑。

对照测法效率最高：同一批样本分别跑通用方案和候选垂类模型，人工只看两边结论不一致的样本。一致的部分基本不用管，分歧样本才是决定选型的地方。

• 测试集要覆盖长尾和对抗输入，别只放标准问法
• 错例按知识、格式、推理三类归档，便于判断该走哪条路线
• 延迟和并发一起测，专属模型常在吞吐上吃亏；量基线可以先用 /tools/speed-test
• 是否要自己部署再估一层，算力账参考 /compute/sizing
• 形态和适配范围去 /stacks/specialized-models 核对
• 上线后保留回归抽检，防止上游更新或数据漂移后悄悄变差

混合路线：多数企业最后落在中间

实际落地时，非黑即白的选择很少。更常见的是混合：通用模型做兜底和开放问答，垂类模型或规则模块处理高频、高风险、有固定口径的任务，中间用路由分发。这样既压住了关键环节的错，又不至于为长尾场景付全额成本。

路由的触发条件必须可观测、可解释：按任务类型分流、按模型自报的置信度分流、按关键词或字段分流都行，但别靠猜。分流规则越模糊，出问题时越说不清是哪一段错了。

• 先定主干：哪类任务必须走确定性更高的路线，哪类任务允许通用模型直接答
• 路由规则写成可读的配置，别藏在代码里
• 按段打日志：输入、路由决策、各段输出都留痕，方便归因
• 定期回看路由命中分布，某条分支长期没人走就清掉

混合方案的风险是责任边界模糊。一旦答案出错，要能定位是检索没给对、垂类模型判断错，还是通用模型改写时带偏了。日志按段打点，比事后争论有用。

什么情况下这套判断不适用

上面那套步骤有前提：你能拿到真实数据、能建评测集、业务相对稳定。前提不成立时，结论要打折扣，甚至该先解决别的问题。

• 强监管行业有数据不出内网的要求：先解决部署形态和合规问题，再谈模型类型，顺序反了会白折腾
• 业务还没定型、需求变化很快：任何选型结论都很快过期，当下该做的是把评测集建起来，而不是锁模型
• 团队人手不足以维护评测集：通用模型加人工抽检更稳，上一个没人维护的专属模型反而是新风险
• 调用量小且场景单一：规则或通用加约束可能就够，不必升级到专属模型

垂类与否只是手段，真正要回答的是：这个环节的错，你能不能用更便宜的方式压下去。