很多团队在立项会上会卡在同一句话上：到底该买一个什么都能聊的通用模型，还是找人做个「懂我们行业」的模型。说不清这三类的边界，后面预算、数据准备、验收标准全都对不上。这篇不比较谁更聪明，只讲三类模型各自解决什么问题、什么条件下不值得选，以及从哪一步开始动手验证。
很多团队在立项会上会卡在同一句话上：到底该买一个什么都能聊的通用模型，还是找人做个「懂我们行业」的模型。说不清这三类的边界，后面预算、数据准备、验收标准全都对不上。这篇不比较谁更聪明，只讲三类模型各自解决什么问题、什么条件下不值得选，以及从哪一步开始动手验证。
先把一个常见误区摆出来：很多人拿参数量、榜单名次来判断该上哪一类，其实那属于另一个维度。模型类别的判断要看你的任务范围、你手里有什么数据、以及答错了要付多大代价。这三条线想清楚，选型方向基本就定了；想不清楚，就算把模型库翻一遍也还是会犹豫。
先把三类的边界划清楚：按什么分，不按什么分
分类看的是「知识范围 + 任务范围 + 交付形态」这三件事的组合，不是看参数大小。参数量、架构这类底层概念属于另一个话题，可以到 /ai-dict/category/tech 对照着看，别混进选型讨论里。
- 通用大模型
- 覆盖面广、任务泛化能力强，但没有你公司的内部口径，回答行业细节时容易给出「听起来对」的答案；各家定位描述可以到 /models 的模型库看。
- 行业大模型
- 面向一个行业的知识与流程（金融、医疗、制造等），通常靠行业语料继续训练或大规模指令微调得到。
- 垂直大模型
- 面向一个具体任务或岗位，比如合同审阅、代码补全、客服质检，范围更窄，但验收标准能写得很死。
三组自问：任务范围、数据可得性、错误代价
这三组问题建议在同一个会上一次问完，别分几次开。问题本身不复杂，难的是逼所有人把答案写下来，而不是用「大概」「差不多」糊过去。
- 任务范围：把所有需求写在一张纸上，如果超过五类互不相关的活，通用模型打底加少量专用更划算；只有一两类活且高频，垂直模型才可能回本。
- 数据可得性：问清有没有成规模、可授权、可脱敏的行业语料。拿不到干净语料时，行业模型的优势基本兑现不了，这条路就该先停。
- 错误代价：错一次只是让人多改两行，还是涉及合规、赔付、责任认定？代价高的场景，宁可缩小范围做垂直模型并加人工复核。
| 判断线 | 倾向通用 | 倾向行业/垂直 |
|---|---|---|
| 任务范围 | 需求分散、跨多个部门 | 单一任务、出现频次高 |
| 数据可得性 | 没有成规模的内部语料 | 有可授权、可脱敏的行业语料 |
| 错误代价 | 错了人工改一下即可 | 错了涉及合规、赔付或责任认定 |
| 验证方式 | 公开评测加少量自测 | 必须自建评测集、人工盲评 |
有一种情况要单独拎出来：数据敏感度极高但预算只够一个人干。这时候优先解决的是数据不出内网的问题，模型类别反而往后放，合规口径可以到 /safety 对照着看。选型顺序搞反了，后面全是返工。
落地成本与验证方式：三类模型的账不一样
三类模型的钱花在不同地方，不能用同一套预算表去套。把成本项拆开看，比笼统问「哪个便宜」有用得多。
- 通用模型
- 成本主要在调用量与并发，按量还是包月要按真实用量算，可以先到 /tools/model-cost-calculator 跑一遍自己的量级。
- 行业模型
- 成本在语料整理、标注，以及后续每次基座换代都要重跑一遍，这笔账常被低估；相关流程可看 /stacks/fine-tuning 的服务商目录。
- 垂直模型
- 成本在验收与回归测试，一套固定的评测集比模型本身更值钱，评测集怎么搭参考 /benchmarks 的思路。
- 准备真实输入拿 50-100 条你们真实业务的输入，覆盖典型场景和边界场景，不要用公开数据集里的样例。
- 候选各跑一遍三类候选模型用同一批输入各跑一遍，输出格式统一，避免后面人工比的时候受格式干扰。
- 人工盲评评测人不知道哪条输出来自哪个模型，按同一套标准打分，分歧大的条目单独记下来复盘。
- 核对公开数字公开榜单只能当参考，榜单读法见 /rankings 与 /crowd-radar，真要下判断还是以自己那批输入的结果为准。
别被锁死：换代、迁移与退出的准备
选型时就要想好以后怎么换，而不是等出问题了再临时找方案。三类模型里，行业和垂直模型的迁移成本通常更高，这一点在签合同前就要确认清楚。
- 把提示词、评测集、后处理逻辑和模型解耦，换模型时只替换一层，改动面才可控。
- 行业与垂直模型尤其要问清权重能不能拿到、能不能自己部署、许可证边界在哪，见 /stacks/specialized-models 与 /open-vs-closed-model-basics 的对照思路。
- 留一条退路：通用模型作为兜底通道，垂直模型出问题时能降级，不至于业务停摆。
- 接口层面尽量走统一网关，别把某家的 SDK 直接写进业务代码，换的时候改一处而不是改一片。
有一种情况要区别对待：如果任务本身就是合规审计类的强监管环节，降级通道可能不被接受，这时要把人工复核写进流程而不是写进备选。把「兜底」当默认方案，在强监管场景里反而会出问题。
三类模型不是三个档次，而是三种范围；选错范围的代价，往往比选错具体某家模型大得多。下一步先把你们团队的任务清单列出来，再对照三组自问打勾，最后到站内价格与模型页面核对当前实际情况，比在会上空谈方向要快得多。→
常见问题
我们公司规模不大，是不是只能选通用大模型？
不一定，但多数情况确实从通用模型起步更稳。判断依据是任务是否集中、频次是否高、有没有可授权语料。小团队做垂直模型最常见的问题不是模型不行，而是没有稳定的评测集去证明它行，最后验收扯皮。先用通用模型跑通流程、攒够真实样本，再决定要不要往窄处收。
行业大模型和垂直大模型听起来一样，到底差在哪？
差别在覆盖面：行业模型覆盖一个行业的多种任务，垂直模型只覆盖一个任务或一个岗位。前者的价值是行业术语和常识更准，后者的价值是输出格式和判断标准能写死。选的时候问自己一句：你要的是一批懂行的人，还是一个能按规矩干一件事的岗位。
能不能先上通用模型，以后再换成行业模型？
可以，但要提前把耦合点拆开：提示词、检索层、评测集、后处理都别写死在某一个模型上。换模型时最大的坑不是接口，而是同一批输入在新模型上输出格式变了，下游解析全崩。留一套固定的回归测试，换代就能几天内验证完。
