为任务选择合适的模型规模
越大并不总是越好。这是一套实用方法,帮你挑出与任务、预算和你能接受的延迟相匹配的模型规模。
大多数团队会顺手抓起负担得起的最大模型,然后就此收工。这行得通,毕竟一个能力强的模型几乎能应付你扔给它的任何东西。但这很少是正确的选择。最大的模型是最慢、最贵的选项,而许多任务并不需要它。选择模型规模是一个匹配问题:你想要的是能可靠完成工作的最小模型,而不是你能找到理由用的最大模型。
"规模"到底买来了什么
模型提供方通常会推出一个家族——一个小、快、便宜的档位,和一个大、慢、能力强的档位,中间往往还有些介于两者之间的。更大的模型在困难推理、微妙指令、长程一致性,以及那些错误是细微而非显眼的任务上表现更好。更小的模型则快得多、便宜得多,在直截了当的任务上,它们往往一样准确。
关键的洞见是:能力不是一个你总想拨到最大的单一旋钮,它是一种你花出去的资源。一个"比任务所需更聪明"的模型,并不会为那份富余交付任何额外价值——它只是更贵、响应更慢。目标是找到任务的难度与模型能力相遇之处,然后就此打住。
先诚实地描述任务
在比较模型之前,先描述任务真正要求的是什么。几个问题能很快让这件事清晰起来。任务需要多步推理,还是更接近于查找或转换?输入的多样程度如何——是狭窄、可预测的格式,还是杂乱、开放的文本?答错的代价有多大——是小小的烦恼,还是真正的失败?延迟有多显眼——是有人在等着响应,还是它在后台运行?
分类、抽取、格式化、短文改写和路由,在这个意义上通常都很简单:输入可预测、有明确的正确答案、推理深度低。开放式分析、多步规划、有分寸的写作,以及模型必须同时持有许多约束的任务,则很难。在这里要诚实。诱惑在于,因为任务感觉很重要,就把它称为困难。重要与困难是两回事——一个机制简单的重要任务,仍然该归到小模型那里。
先用便宜的方法
可靠的选择方式是从小开始,只在被迫时才往上走。先用家族中最小的模型,让它跑一组真实、多样的输入——不是一个演示,而是覆盖了简单和棘手情形的一小批。读它的输出。如果小模型可靠地够好了,你就完成了,而且你拿到了最快、最便宜的选项。
如果它失败了,看看它是怎么失败的。有时解法是更好的提示词,而不是更大的模型——更清晰的指令、一两个示例、一个被点名的失败模式。先试这个。如果在公平的提示之后小模型仍然不够,就升到中档再重复一遍。只有当真实的评测显示更小的模型做不了这工作时,才升级到最大的模型。这种从底部往上爬的方法,让你不会默认地多付钱,也会暴露出那些大模型本会悄悄掩盖的提示词问题。
让模型匹配步骤,而非整个应用
一个常见的错误,是为整个应用选一个模型。大多数真实系统是由难度各异的步骤组成的流水线。把一个请求路由到正确的处理器很简单。为一个复杂问题起草一份细致的答案很难。把那份答案重新格式化为 JSON 又很简单。对每一步都用你最大的模型,意味着为那些琐碎的步骤付旗舰价。
更好的设计是为每一步分配一个模型规模。便宜的模型负责分类、路由、抽取和格式化。昂贵的模型负责那一两个确实需要深度推理的步骤。这有时被称为级联(cascade)或路由器(router)模式:一个小模型完成大部分工作,要么直接作答,要么把困难的情形上交给一个更大的模型。结果是一个把能力预算花在要紧之处、在其他一切地方都省下来的系统。
权衡成本与延迟,而不只是准确率
准确率是头条,但它不是唯一的维度。延迟直接塑造用户体验——一个要花好几秒的响应,在交互式聊天里会让人觉得坏掉了,但在每晚批处理任务里却没问题。如果有人在等着,一个稍欠打磨、但更快的小模型,可以胜过一个稍好一点、却更慢的大模型。
成本会在规模上叠加。两个档位之间一个就单次请求看来微不足道的价差,一旦乘以数百万次调用,就会成为一个可持续产品与一个不可持续产品之间的差别。当你评测时,为每个候选者把准确率、延迟和成本一起写下来。正确的选择往往是越过你的准确率门槛的最小模型,因为它在另外两项上决定性地获胜。把大模型留给准确率差距确实存在、且利害关系值得那份溢价的情形。
随时间重新审视这个决定
模型选择不是永久的。提供方会定期发布新模型,而明年的小档位往往能匹敌去年的大档位。一个今天需要你最大模型的任务,在下一次发布之后,也许就能轻松跑在一个更便宜的模型上。把你的评测集留着,这样当新模型上线时,你可以拿它重跑。当初帮你做出选择的那同一组评测,让你能廉价地重新审视这个选择——而趋势几乎总是偏向往下降一档,而不是往上。
这也是为什么你应该避免把对某个特定模型的假设硬编码进你的提示词和代码里。把模型藏在一层薄薄的抽象之后,这样替换它就是一次配置变更,而不是一次重写。从模型进步中获益最多的团队,正是那些让切换变得容易的团队。
总结
选择模型规模是匹配,而非求最大。描述任务真实的难度,从最小的模型开始,只在一次真正的评测逼迫你时才往上爬。按步骤而非按应用来分配规模,让便宜的模型做简单的活,昂贵的模型处理那少数困难的部分。把延迟和成本与准确率一起权衡——越过你门槛的最小模型,通常在整体上获胜。并随着新模型上线重新审视这个选择,因为聪明的默认选项只会越来越便宜。
