大模型 小模型 解决领域问题

手上有个具体领域问题要落地，比如合同条款抽取、工单分类、内部知识问答。有人劝你直接上大模型 API，有人说小模型微调更省，两边都说得通，就是没人告诉你按什么顺序决策。这篇给一套可执行的判断流程：先把任务拆到能评估的粒度，再对照大模型和小模型各自的适用边界，最后用最小成本跑一轮验证，避免一上来就锁死路线。

手上有个具体领域问题要落地，比如合同条款抽取、工单分类、内部知识问答。有人劝你直接上大模型 API，有人说小模型微调更省，两边都说得通，就是没人告诉你按什么顺序决策。

这篇给一套可执行的判断流程：先把任务拆到能评估的粒度，再对照大模型和小模型各自的适用边界，最后用最小成本跑一轮验证，避免一上来就锁死路线。全程只讲怎么判断和怎么动手，具体数字一律到站内对应页面核对当时的行情。

先把「领域问题」拆成能判断的任务

很多人卡住不是因为模型不够强，而是问题本身没被拆开。你先别问该选哪个模型，先问这个任务能不能被写成「输入一段什么、输出一段什么、对错怎么判」的形式。写不出来，说明还得继续拆。

1. 先答三件事输入输出格式是否固定、答案是否可枚举或可校验、错一次的代价有多大。三个都偏向固定、可枚举、低代价的，小模型通常够用；只要有一项是开放输入或高代价，先按大模型路线设计再想优化。
2. 拆成流水线把端到端问题拆成抽取、分类、检索、生成、校验几个环节，每个环节单独标注输入输出。不同环节可以走不同路线，不必整条链路统一一个模型。
3. 列硬约束写清是否要求数据不出内网、是否要求低延迟、是否要离线跑、有没有合规审计要求。约束往往比效果更早决定选型，先列出来能省掉大量无意义的对比。
4. 确认对错可判如果连人工都判不准对错，先停下来把判定标准建起来。这一步不做，后面跑什么模型都是白费。

• 抽取类（条款、字段、实体）：输出结构固定、可校验，是小模型最舒服的场景
• 分类类（工单、意图、风险等级）：标签体系固定就有戏，标签经常变就要谨慎
• 检索问答类：难度主要在检索质量，模型大小的影响往往没那么大
• 生成类（摘要、改写、回复）：开放度高，通常留在大模型侧，或者做成混合架构
• 校验类（格式、合规、逻辑）：规则和轻量模型就能干，别上大模型

大模型和小模型各自能兜住什么

两边的差别不在「谁更聪明」，而在「谁更适合你的输入分布和调用模式」。下面这张表只是判断方向，不是绝对结论，具体表现要以你自己的抽样测试为准。

• 大模型擅长开放输入、跨领域迁移、少样本即用，代价是单次调用成本、延迟和数据外流风险都由外部控制
• 小模型擅长输入分布稳定、标签体系固定、量大且对延迟敏感的场景，前提是你有足够且干净的标注数据
• 中间路线要单独算：小模型打底加规则校验，大模型只处理小模型置信度低的那部分，这类混合架构往往比二选一更划算
• 领域知识本身在快速变化时，小模型刚训完就过时，维护成本可能超过直接调用大模型

算力、许可证这两笔账先算清

决定走小模型之前，别急着买卡。先把两件事算明白：跑起来需要多少显存和并发，以及这份权重你到底能不能商用。这两笔账算错了，后面效果再好也落不了地。

显存估算

按参数量和量化档位反推权重占用，再留出激活值和 KV 缓存的空间，别只按参数量的一半凑数

并发测算

根据峰值请求数和单条延迟上限，反推需要几张卡或几个实例，到站内部署测算页面代进去看当时的数字

许可证门槛

权重能不能商用、有没有用户量或收入门槛、衍生模型怎么署名，这三条要逐条读原文，别只看别人转述

维护成本

数据漂移后要重训、要重新评测、要重新上线，这部分人力往往被低估

用最小成本跑一轮对照再定

前面都是纸面判断，最后一定要用真实数据验一遍。目标不是证明谁更好，而是找出「在什么量级、什么错误类型下该换路线」的那个分界点。

1. 准备测试集从真实业务里抽几十到一两百条样本，必须来自实际分布，不要用构造数据。分层抽样比随机抽更有代表性。
2. 同批跑两条线同一批样本分别跑大模型 API 和小模型，各记录三组数字：正确率、单条延迟、单条成本。成本按当时的报价算，到站内价格页面核对当时的数字。
3. 先定义判定标准正确率怎么算要提前写清楚，是逐字段比对还是人工打分。标准不统一，两边跑出来的数字没法比。
4. 看错误类型而不只看错误率小模型的错集中在某几类，说明补数据和加规则能救；错得均匀散落，说明模型容量不够，考虑换更大规模或走混合路线。
5. 写成切换条件结论落地成一句话：什么量级以下继续用大模型，超过之后切小模型，并写清切换的触发条件，比如日调用量或错误率阈值。

跑完这一轮，你手上应该有一份很短的决定：主路线是什么、备选是什么、什么条件下重新评估。这比争论哪个模型更强有用得多。

选型不是选最强的模型，是选在你当前约束下最不容易翻车的模型。