通用大模型 vs 行业垂类 vs 自建小模型：差 3 个点，和差23 个点

整体准确率看着差不多的两个模型，到了你最关心的那 10% 上，可能差 23 个点。

保险行业里常见的一份选型评估报告大致是这样——3 个候选模型，跑 5000 条业务样本：

• 通用大模型 A——整体准确率89%
• 行业垂类 B——整体准确率92%
• 自建小模型 C——整体准确率87%

报告结论是"选 B，差距 3 个点不大但优势明显"。听起来合理。

把 5000 条里业务最关心的那一段单独拆出来再跑一次——投诉类、理赔争议类、涉及金额纠纷的那部分——结果是：

• A——那部分准确率62%
• B——那部分准确率85%
• C——那部分准确率78%

整体差 3 个点的两条线，到了业务最痛的部分上，差了 23 个点。

整体准确率是个加权平均数——它会把"大多数简单的题"和"几百条业务真正在意的难题"混在一起算。简单题贡献了大头，难题被稀释成几个百分点。但业务部门只用难题考你。

整体准确率为什么会骗人

模型选型 90% 栽在"整体准确率"这一个数字上。根因不是评估团队不专业，是测试集的构造方式决定了你能看到什么。

大多数测试集是这样做的——从业务系统里随机抽 5000 条历史数据、标注答案、让 3 个模型各跑一遍。问题在这一句——真实业务的频率分布，和真正重要的频率分布，不是同一回事。

举个例子。保险客服一年处理 100 万条咨询——

• 80% 是常规咨询（保单查询、缴费提醒、地址变更）——简单题
• 15% 是产品咨询（条款解读、对比建议）——中等题
• 5% 是争议处理（理赔被拒、金额异议、投诉升级）——难题

按真实频率抽 5000 条，4000 条简单、750 条中等、250 条难题。简单题上三家模型都 95%+，差距拉不开；中等题差几个点；难题差 20 多个点。加权一算整体只差 3~5 个百分点。

但业务部门的真实痛苦全在那 5%。常规咨询出错没人有感觉，争议处理错了可能上升为投诉、上升为监管投诉、上升为媒体事件。模型选型的关键，就是看它在那 5% 上扛不扛得住。

三类模型，三种典型场景

不是"选难题准确率最高的"就完事。三类模型有各自适合的场景——场景错了，再高的准确率也用不上。

通用大模型：广而浅

优势是覆盖面广——同一个模型客服能用、写文档能用、翻译能用、辅助决策也能用。劣势是行业深度不够——不懂你的合同条款细节、不懂你的产品代码命名规则、不懂监管文件的最新解读。

适合：业务跨度大、单点深度要求不高、用量弹性大、合规要求宽松——内部知识问答、文档摘要、邮件起草。

不适合：涉及专业判断（医疗诊断、法律意见、金融合规）、涉及专门术语（药品适应症、保险条款）、涉及最新监管动态。

行业垂类：深而窄

行业垂类是过去 18 个月增长最快的一类——金融、医疗、法律、政务各有几家头部供应商。

优势是行业深度——训练数据里大量是行业语料，对术语、流程、监管要求有内建认知。劣势是覆盖面窄、跨行业能力弱；升级速度慢——通用大模型每 3 个月一次能力跃迁，垂类大概一年一次。

适合：业务集中在一个行业、对难题准确率要求高、合规约束强、业务规模相对稳定——保险理赔判定、医疗病历摘要、法律合同审查。

判断方法：把业务难题样本拿给候选垂类跑。在难题上比通用大模型高出 15 个点以上，垂类深度价值是真的；低于 10 个点，这家"垂类"大概率只是套壳通用模型，没真深耕。

自建小模型：专而稳

自建小模型最容易被误解。它的优势不是准确率最高，而是可控、可解释、可固化——模型权重在自己手里、推理在自己机房、数据完全不出域、合规天然过关。

劣势是前期投入大——需要数据团队、标注流程、训练资源；不擅长开放问题——只能解决提前定义好的封闭任务。

适合：合规要求极强（金融风控、医疗影像）、任务定义清晰（信用评分、影像分类、欺诈识别）、业务相对稳定不频繁变化、有持续的数据团队投入。

不适合：业务在快速试错、任务定义随时变、需要写作或生成能力——这些场景下自建小模型的研发周期跟不上业务节奏。

三个最容易被忽略的判断点

除了准确率和场景匹配，还有 3 件事在选型时容易被忽略——它们决定了 18 个月之后项目还跑不跑得动。

升级账算了没

通用大模型的升级是免费跟着供应商走的；垂类大概一年付一次升级费；自建每次升级都是一笔再次研发投入。

业务持续依赖最新模型能力——选通用，省钱。业务定型了——选垂类或自建，长期看稳。

数据出域的真账

通用大模型基本都是云端服务，请求数据走 API 出去；垂类有的支持本地化、有的强制云端；自建完全本地。

不要听供应商说"我们承诺不存储您的请求数据"——这种承诺在合规检查时不算数。合规看的是数据"有没有可能出域"，不是"承诺不存"。

行业里见过的情况是这样——上线后才发现那家垂类的"本地化部署"实际上是"边缘节点 + 云端兜底"——非高峰走本地，高峰路由到云端。技术上没毛病，但法务复审直接判为"数据出域"，方案整改 2 个月。

业务部门能不能改 Prompt

这一点对中长期成本影响极大。

通用大模型和好一些的垂类，Prompt 业务部门可以直接改——业务规则变了，业务运营改两行 Prompt 就好。

自建小模型每一次"业务规则变化"都要重新训练或微调——每次业务调整都是一次研发排期。这一笔账没算清楚的项目，上线后 12 个月里研发团队大概会有 60% 时间在响应"业务规则微调"，而不是做新功能。

一张表：3 类模型的真账

业务部门要做的一件事

选型评估的正确做法，是把两份评估报告打印出来，约业务部门负责人坐到一张桌子上。

第一件事是让业务部门自己定义"什么是难题"——

• "你们这边一年有多少投诉是因为我们处理错了？错的都是哪一类？"
• "理赔争议里，模型如果给错了答案，最坏的后果是什么？"
• "投诉升级到监管的，过去 2 年发生过几次？"

讨论 40 分钟，业务部门能给出一份清单——通常落在6 类高敏感场景，约占业务量 4.3%。

然后用这 4.3% 做一份专项测试集——300 条难题样本，让 3 个候选模型再跑一次。

结果出来后，业务部门当场拍板——"选 B，其他两个我们扛不住。"

把"什么是难题"的定义权交回业务部门——这一步做完，3 个候选模型选哪个，是业务部门主动决策的，不是 IT 单方面推荐的。这种决策上线之后，也不会有"为什么当初没选 A"的回头炮。

写到最后

那份"整体 89%"的报告本身没错——89%、92%、87% 都是真实数据。错的是只看那一组数字就下了结论。

模型选型最大的陷阱不是被供应商骗，是被自己看到的那一组"看起来很正确"的数字误导。整体准确率是真实的，但它不在你最痛的那个点上。

如果手边正放着一份选型报告——今晚做一件事——把测试集里"业务最关心的那部分"圈出来，让每一家供应商只跑这部分，单独出一份分数。那份分数才是你选型该看的数字。

供应商可能不舒服——他们准备了 5000 条样本来展示"整体强项"，你只看那 300 条业务最痛的点。但这个反差恰恰是该坚持的——你不是替供应商验证产品，是替自己的业务部门兜底。

昱图智慧

jadefmea.com