垂类模型和通用大模型的区别，选错了多花的钱都在这

团队要做行业问答、单据审核、代码助手，一开会就有人问：是不是得训个垂类模型？另一派说直接调通用大模型加提示词就行。两边都有道理，但都没算清账。这篇不谈参数比拼，只讲两类模型各自能干到哪、哪里会翻车、钱花在哪一格，最后给一份能当场用的拆分清单和试跑顺序。

开会时有人问「是不是得训个垂类模型」，另一派说直接调通用大模型加提示词就行。两边都没算清账：前者没算维护成本，后者没算知识注入要花多少人力。这篇不谈参数比拼，只讲两类模型各自能干到哪、哪里会翻车、钱花在哪一格。

先给个结论方向：垂类模型不是「更懂你」，它只是「在见过的输入形态上更稳」。你的业务输入越固定，它越占优；输入越杂、跨领域越多，通用模型加检索的组合反而更抗打。下面按四条线拆开说，最后给一份能当场用的拆分和试跑顺序。

先把「垂类」这个词拆开，不然会一直在鸡同鸭讲

市面上被叫「垂类模型」的东西至少三种，能力上限差得很远，但销售话术里常被混成一个词。第一种是厂商在通用底座上做过行业微调的成品，你只能调接口，权重摸不到；第二种是你们自己拿开源权重微调出来的版本，权重和数据都在自己手里；第三种最虚，只是套了行业提示词、挂了个知识库的通用模型，本质还是通用模型。

• 能不能拿到权重：拿不到就基本没有自主迭代空间，只能等厂商发版
• 训练数据归谁、含不含你的业务数据：这条直接决定隐私边界和后续迁移难度
• 出问题谁兜底：是厂商按 SLA 赔付，还是你们自己运维团队扛
• 升级节奏谁定：自动升级对稳定性的冲击，往往比模型本身强弱更影响业务

这四种问法不用很专业，采购会上就能问。对方支支吾吾说不清权重归属的，多半是第三种套壳方案。这不是说套壳不能用，而是要按套壳的价格和心理预期去买，别为「垂类」两个字付溢价。

能力边界的真实分界：通用模型输在「口径」，垂类模型输在「意外」

通用大模型知识面宽、表达顺，但对你们公司的术语、审批口径、产品代号一无所知，细节全靠你在上下文里喂进去。喂得进去还好，喂不进去就开始编，而且编得很顺，外行看不出来。这是通用模型落地最常见的翻车点。

垂类模型反过来。它在训练覆盖到的输入形态上很稳，表单字段、单据版式、行业话术都对得上。但一旦遇到没见过的表达、跨领域问题或者版式奇怪的长尾单据，退化往往比通用模型更突然——因为它没有那层宽泛的兜底常识。判断分界线不是「谁更聪明」，而是任务输入是否高度可枚举。输入形态越固定，垂类越占优；输入越开放，通用模型加检索越稳。

这张表不是让你照着选，而是提醒你：先把自己的任务按输入形态分个类，再决定哪一类交给谁。很多团队一锅端，把所有任务塞给一个模型，结果两头都不讨好。

数据这一笔账：垂类不是买回来就懂你的业务

厂商的行业模型学的是行业公开语料，不是你的内部制度、报价规则和历史工单。这部分仍然要自己做知识注入或者微调，钱和人力省不掉。真要微调，得先有清洗过的标注样本，还要留一批不参与训练的样本做验证。样本规模各家口径不一，具体数字到微调服务商目录里核对当时的说法。

数据出不出内网是硬约束。涉及客户信息、合同条款、工单原文的场景，先看安全与合规页面再谈模型选型，顺序别反。很多项目卡在这一步，不是技术不行，是数据根本出不去。

知识注入

把内部文档、制度塞进上下文或检索库，不改模型权重，见效快、可回退

微调

用标注样本改模型行为，适合固定输出格式，但每次换底座都要重来

检索

模型每次答题前先查内部资料，适合口径类问题，维护成本主要在文档整理

一个常见误判：以为微调完模型就「学会」了业务，其实它学的是样本里的模式，制度一变就得重新喂。所以知识注入和检索这两条轻路线，通常应该排在微调前面试。

钱花在哪一格：四笔开销对照着看

调用费上，通用模型按量计费透明，垂类成品常按席位或年框报价，单价不好横向比，要折算到每次任务的实际成本。别只看合同总价，要问清单次调用怎么算、超额怎么计。具体价位到价格追踪页核对当时的数字，这里不写死。

算力费是自建垂类绕不开的。租还是买，按买卡还是租卡那套三年账算，把闲置率算进去，很多团队只算了满载成本。数据费最容易被低估：标注、清洗、复核都是人力，这是垂类路线最容易超支的一项。维护费则藏在升级里，通用模型升级由厂商负责，自建垂类每次换底座都是一次迁移工程，得预留验证和回退的人力。

• 调用费：折算到每次任务，别只比合同总价
• 算力费：按三年账算，把闲置率算进去
• 数据费：标注清洗复核的人力，最容易超支
• 维护费：换底座的迁移和回退，要单独列预算

把这四笔加总，往往能看出一个反直觉的结论：业务量小的时候，自建垂类的固定成本根本摊不平，通用模型加人工复核反而更便宜。

试跑顺序：别一上来就训模型

1. 第一步：通用模型加提示词跑真实工单拿两周真实任务跑，把失败样本收上来，先确认瓶颈是知识缺失还是推理不行。这一步几乎零成本，却能挡掉大半不必要的微调。
2. 第二步：挂检索补内部口径把制度和文档塞进检索库，用内部文档补齐口径。能解决就先停在这，成本最低、回退最容易。
3. 第三步：小样本验证微调收益只在失败样本集中在固定输入形态时才考虑微调。先小样本跑，确认收益能覆盖后续维护成本再扩大。
4. 第四步：留回退方案每一步都留可回退的路，别让业务方在切换期无路可走。切换前先约定好回退触发条件。

这个顺序的核心是：先用便宜的手段把瓶颈定位清楚，再决定要不要动贵的。直接训模型，等于在没定位问题前就付了最贵的一笔钱。

验收清单：拿这几条去卡，比看演示有用

厂商演示一定好看，那是挑过的样例。验收要自己出题：用一批带标准答案的历史任务做盲测，不接受厂商自带样例。另外单独统计「拒答」和「答错」两类——垂类模型常见的毛病是把不确定的问题也硬答，看起来覆盖率很高，实际错得很自信。

• 用自己出的历史任务盲测，不用厂商样例
• 拒答和答错分开统计，别混成一个准确率
• 压测并发和长输入，短句演示好看不等于批量跑得动
• 问清版本锁定策略：升级自动还是手动，旧版本保留多久
• 抽几条失败案例让厂商现场解释，看是能力问题还是接入问题

版本锁定这条特别容易被忽略。自动升级听起来省心，但业务正跑着的时候模型行为一变，工单分类口径可能跟着漂，排查起来很费劲。宁可手动升级、自己控节奏。

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

有几种场景上面这套拆解要打折。监管明确要求使用已备案的行业模型时，选择空间被压缩，重点应该从「选谁」转到「怎么验收和留痕」，把盲测和日志做扎实比纠结选型更有用。

业务量极小的场景，自建垂类的固定成本根本摊不平，直接用通用模型加人工复核更实际，别为了技术先进硬上。还有一种：输入形态还在快速变化的早期业务，训出来的模型很快过时，先别急着固化，等形态稳定了再考虑微调。说白了，垂类模型是给「已经稳定下来的流程」提速的，不是给「还在找方向」的业务指路的。