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

垂直领域落地常见的卡点是：直接用大模型，领域术语答不准、单次成本压不下来、响应还慢；自己训一个小模型，又怕通用能力和长尾问题兜不住。这篇不讲概念，给的是分工思路、可执行的拆分步骤、验证顺序和退出条件，帮你判断什么时候该拆、拆完怎么对照。

垂直领域落地最常撞上的矛盾是：直接用大模型，术语答不准、单位成本压不下来、延迟还慢；自己训一个小模型，又怕通用能力和长尾问题兜不住。于是「大模型加小模型」成了很多团队的默认答案，但真正上线后跑得顺的并不多，问题几乎都出在分工没切干净、兜底路径没跑通。

这一节不讲概念，只讲判断顺序：先看该不该拆，拆了之后各自接什么活，怎么粘起来，怎么验证收益，最后说清什么情况下这套组合根本不划算。每一步都给可执行动作，不给绝对结论。

先判断到底该不该拆

别一上来就想训练小模型。先拿当前单模型方案当基准，把两类信号分清楚：属于「该拆」的，通常是领域术语密集、输出格式固定、单次调用成本高、延迟敏感、数据不能出内网；属于「不该拆」的，是任务本身高度开放、领域数据量很少、团队没有维护第二个模型的运维能力。信号混在一起时，优先看后两类。

拆之前把当前单模型方案的两个数记下来：一次典型请求的响应时间和单位成本。这两个数是后面判断拆得值不值的基准，别靠感觉，到 /tools/speed-test 和 /tools/model-cost-calculator 量出你自己场景下的口径，数字会随模型和时间变化，以当时页面为准。

还有一层是「输错代价」。答错会被用户立刻发现的，比如单号、金额、条款编号，属于高风险字段，是小模型的主战场，必须配校验；答错影响不大的，比如寒暄、摘要润色，交给谁差别不大，不必为它单独加一套机制。把这两类混在一起评估，很容易得出「拆分没用」的错误结论。

大模型和小模型各自该干什么

分工的核心原则是：小模型接输出空间有限、有明确对错的活；大模型接输出空间大、硬约束难写的活。中间那条线不是按任务难度分的，是按「能不能写出校验规则」分的。

• 小模型适合：意图分类与路由、领域实体抽取与槽位填充、固定模板的生成或校验、检索结果的相关性过滤。共同点是判定标准可以写死，错了一眼能看出来。
• 大模型适合：多轮澄清与对话、跨文档归纳、把结构化结果组织成自然语言。这些任务的答案空间大，小模型容易在长尾上翻车。
• 不要两者做同一件事。常见失败模式是让大模型也抽取一遍再比对，看似保险，实际把成本和延迟叠了一倍，还多出一套冲突消解逻辑。
• 真要做交叉校验，只在校验字段上做：小模型出结果，大模型只判「这条是否自洽」，不重新抽取。

如果团队人手紧，第一步只拆一个环节就够了，通常选字段抽取，因为它最容易量化，也最容易看出收益。全量拆完再上线，往往还没验证就先背上运维负担。

拼起来：路由、兜底与数据回流

主链路建议走「小模型先跑 → 置信度达标直接返回 → 不达标升级给大模型」。关键在升级条件要写死，比如解析失败、必填字段缺失、置信度低于你设定的阈值，而不是让模型自己说「我不确定」——那句话本身就是个不可靠信号。

1. 第一步 定路由规则把升级触发项列成清单，逐条对应到代码里的判断分支，能自动化判断的不要依赖模型自述。
2. 第二步 跑兜底通道保留一条纯大模型的降级链路，小模型服务挂掉时直接切过去，先保可用性。定期演练切换，确认切换后输出格式仍然合法。
3. 第三步 采集回流样本只留两类：小模型判错且大模型改对的、升级后被大模型拒答的。前者补训练集，后者多半是规则问题。
4. 第四步 查字段定义升级率异常高时先别急着加数据，去核对字段定义和校验规则，很多时候是规则写错了。

兜底路径必须能独立跑通，别让大模型成为唯一出口，也别让小模型成为唯一入口。两条路都要有监控，升级率和降级率分开看，混在一起看不出是哪一段出问题。

怎么验证这套组合真的省了

准备一条固定的基准问题集，同一条问题集分别跑纯大模型方案和组合方案，只比三件事：整体准确率有没有掉、单位成本降了多少、响应时间变化。任何一项明显变差，都要先定位是哪一段拖的，再决定要不要保留拆分。

注意平均值的陷阱：成本降了但长尾变慢很常见——大部分请求走小模型很快，少数升级请求把整体高分位延迟拉高。要按分位数看，不能只看均值。具体分位口径和测试方法可以参考 /tools/speed-test 里的说明，实测数值以当时页面为准。

• 验证集里专门放一批边界样本，看升级机制有没有把它们正确送上去。
• 垂直领域里「答错但看起来合理」比「答不出来」更危险，这类样本要单独统计。
• 升级率、降级率、小模型直返率三个指标分开记录，别合并成一个。
• 成本对比按同一问题集算单位成本，不要用不同问题集的数字对比。
• 准确率对比要按字段或按意图分别看，整体准确率会掩盖局部退化。

什么情况下这套组合不划算

拆分不是默认正确，它是一笔运维投资。下面几种情况先别拆，省下来的收益覆盖不了多维护一套服务的成本。

• 领域样本还凑不齐一轮训练的时候，小模型的准确率很可能还不如给大模型加几条好提示词。
• 任务量本身很小、调用频次很低时，便宜下来的钱覆盖不了额外的迭代和监控成本，用大模型加检索就够了。
• 领域规则还在高频变动时不适合拆，规则一变就要重训，迭代速度会被拖死，先把规则外置到提示词和检索层。
• 团队里没有能独立维护小模型全流程的人时慎拆，上线只是开始，后面还有版本、监控、回滚一堆活。
• 数据合规要求可以外发、延迟又完全不敏感时，拆分的动机通常不成立。

判断的落点还是那两个基准数：拆分后单位成本和响应时间的改善，能不能覆盖多养一套服务的长期成本。心里没底就先做一个小环节的灰度，用 /rankings 看同类方案的稳定性和口碑，再决定要不要扩大范围。

拆分是为了把确定的部分变便宜，不是为了把不确定的部分藏起来。