小模型还是前沿大模型？你的AI功能该选哪个

当SaaS产品决定嵌入AI功能时，创始人最常问的问题往往是“哪个模型最聪明”。但真正该问的是：在我的评估集上，能以可接受的准确率通过、且运行成本最低的模型是哪一个？ 这个视角的转换，决定了AI功能是成为利润中心还是成本黑洞。

为什么“最聪明”是个错误问题

排行榜上的冠军模型，很少是产品里每月运行五万次的那个功能的最佳选择。以工单分类为例：每月五万张工单，排行榜冠军和某个蒸馏版“flash”模型对明显工单的标注结果完全一致。差异只出现在模糊案例上——而一个检查标签是否在允许列表内的输出验证器，加上失败重试，能捕获小模型相当一部分错误。

关键测量方法很简单：拿五十到几百条真实工单跑两个模型，把每次调用的价格和准确率并排对比。决策就从对厂商营销的押注，变成了工程测量。

蒸馏模型（distilled model） 是指用大模型的输出作为训练信号，训练出的参数量更小、推理成本更低的模型。常见做法是让小模型模仿大模型在大量输入上的回答分布，从而把大模型的部分能力“压缩”进小模型。蒸馏版模型在模式清晰、输入分布稳定的任务上往往接近教师模型的表现，但在需要即兴推理或处理分布外输入时会明显退化。这正是文中“明显工单标注一致、模糊案例出现差异”的技术根源：蒸馏保留了高频模式，丢失了长尾判断力。因此评估蒸馏模型时，必须用真实业务样本覆盖边界案例，而不能只看平均准确率。

决定模型层级的四个问题

1. 任务是否有界？

有界任务有已知的输入形状、输出形状和可接受答案集合。“从这份PDF中提取发票号、到期日和总额”是有界的；“读完客户最近六封邮件并决定怎么做”不是。小模型在有界任务上表现强劲，因为提示词可以承载大部分智能——模式定义、规则、三个示例。它们在无界任务上会退化，因为需要即兴发挥，而参数越少，即兴发挥的质量越差。

2. 输出能否被廉价检查？

如果能用确定性检查捕获大部分坏输出，就可以跑更小的模型，让验证器扛起重任。JSON模式校验、日期金额的正则、数据库查询、长度上限——这些每次调用零成本，把模型的偶发错误变成一次重试，而不是客户看到的bug。反之，如果只能靠人眼阅读来检查输出，模型就必须一次做对更多次，价格自然往上走。

输出验证器（output validator） 是一段与模型解耦的确定性程序，负责在模型输出进入下游之前判断其是否可接受。常见形式包括 JSON Schema 校验、字段类型与取值范围检查、正则匹配、枚举白名单、以及对外部数据库或事实源的查询核对。验证器的价值在于把“模型偶尔出错”转化为“可检测并重试的失败”，从而降低对模型本身准确率的依赖。设计良好的验证器应满足三点：判定逻辑确定、单次执行成本趋近于零、失败时能给出可用于重试的具体原因。验证器无法判断语义层面的“选对了事实”，这正是它适用边界的所在。

3. 错误答案的代价有多大？

一张标错的客服工单，让坐席多花十秒钟。医疗工具里错误的剂量摘要，或电商代理里错误的退款决策，代价则高得多。要衡量失败的成本，而不是调用的成本。 失败代价低的地方，优化每次调用成本；失败代价高的地方，前沿模型的每token溢价相对于风险微不足道，而且无论用哪个模型都该加人工审核。

4. 输入放得下吗？需要记忆吗？

小模型的可用上下文通常较短，在长文档中更早“迷路”。如果功能需要同时审视200页合同，或跨20步工作流携带状态，你要么激进分块（更多工程），要么为能装下的模型付费。多步工具调用型代理是前沿模型最清晰的使用场景。

上下文窗口（context window） 指模型单次调用能接收的最大 token 数量，包括提示词、示例、输入文档和已产生的对话历史。窗口不足时通常有两种应对：分块（chunking）把长文档切成多段分别处理，或摘要压缩把历史状态提炼成短文本。分块会切断跨段引用，需要额外的合并与去重逻辑；摘要压缩则可能丢失细节。多步代理还需要在每一步之间携带状态，状态本身也占用窗口。因此“输入放得下吗”实质是在问：任务所需的全部信息加中间状态，能否在单次调用的窗口内共存，否则就要为更大窗口的模型付费或承担额外工程。

小模型的真正强项：我们的外联引擎

我们自己的外联工具是个具体例子。它用自托管的Firecrawl爬取每个潜在客户的网站，把页面文本交给本地模型，为每家公司撰写一封定制邮件。任务有界：输入是几页文本，输出是遵循模板和语气的短邮件，验证器拒绝过长、提到不存在的产品、或未能引用网站事实的内容。

令人意外的是，单次调用完成“提取事实+撰写邮件”在成本和质量上都击败了多步链（先提取、再规划、再撰写），即便用的是更小的模型。跳数越少，模型偏离源文本的机会就越少。对采购者的启示是：一个约束良好的小模型加验证器就是对的工具，前沿模型只会增加成本而不改变回复率。

什么时候该为前沿模型付费

对“便宜反而昂贵”的场景要诚实。上述外联引擎能用小模型，原因只有一个：单跳、文本进邮件出、背后有验证器。去掉任一条件，局面就变了。

• 对杂乱输入的开放式推理。 需要判断力而非规则的分诊。验证器能拒绝一封未引用网站事实的邮件，但无法判断模型是否选了正确的事实——当这种判断本身就是功能时，你需要更强的模型。
• 多步工具使用。 当任务变成“爬网站、判断哪些页面重要、查CRM、再写邮件”，小模型就要跨跳携带状态，这正是它丢线索的地方。
• 低频高价值调用。 每月只跑几百次、每个结果都由资深人员审核的功能，成本差异是噪音。买准确率。
• 代码生成与复杂转换。 这里的质量差距仍然很大。
• 第一版、还没有评估集时。 常常更便宜的做法是先用强模型上线，收集真实流量，从中构建五十到几百条真实样本的评估集，然后在评估集允许的地方降级。

最后一点很重要。从前沿模型起步再下移，是有评估集支撑的测量决策；从小模型起步、在生产中发现不够用，则是在压力下重写提示词和护栏，而且没有评估集告诉你何时改完。

模型选择如何改变报价

创始人通常以为小模型会让项目构建更便宜。多数情况下不会。构建成本在提示词设计、验证器、评估集、重试与回退逻辑、以及产品集成上——无论背后是哪个模型，这些工作都一样。小模型甚至需要更厚的验证层，工程略有增加。

改变的是运行成本。前沿模型和小型托管模型的每调用价格差很多倍，一年真实流量下来，差额可能超过最初的构建预算。签约前要求按三档用量做成本预测。至于自托管小模型，vLLM和Ollama让技术上很容易，但只有在稳定用量或数据驻留要求下才划算；典型早期阶段用量下，算上工程时间，便宜的托管API模型胜出。

对冲策略：建开关，不建赌注

无论怎么选，都别让它焊死在代码里。在需求文档中坚持三件事：

• 模型藏在一个配置值后面。 从前沿模型切到小模型、或更换供应商，应该是一次部署，而不是一个冲刺。
• 随功能交付一个评估集。 五十到几百条带预期输出的真实样本，每次模型变更前都跑一遍。没有它，“更便宜的模型够不够好”就只能靠猜。
• 一条回退路径。 小模型连续两次验证失败时，把这一次调用升级到更强的模型，而不是让用户看到失败。这样你得到的是小模型的经济性加上前沿模型的最坏情况质量。

这样做，模型问题就变成了随流量和证据逐渐调整的旋钮，而不是一个没有数据支撑、一锤定音的决定。