タスクに合ったモデルサイズを選ぶ

多くのチームは、予算で買える最大のモデルに手を伸ばし、それで一件落着とします。それはそれで機能します。有能なモデルは、投げかけられたほぼあらゆるものを処理してくれるからです。しかしそれが正しい判断であることはまれです。最大のモデルは最も遅く、最も高価な選択肢であり、多くのタスクはそれを必要としません。モデルサイズの選択はマッチングの問題です。正当化できる最大のものではなく、仕事を確実にこなせる最小のモデルを選びたいのです。

「サイズ」が実際に何を買ってくれるのか

モデルプロバイダーはたいてい一つのファミリーを提供します。小さく速く安いティアと、大きく遅く有能なティア、そしてしばしばその中間です。大きなモデルは、難しい推論、微妙な指示、長距離の一貫性、そして誤りが明白ではなく微妙であるようなタスクが得意です。小さなモデルは劇的に速く安く、単純なタスクではしばしば同じくらい正確です。

肝心な洞察は、能力とは常に最大まで回したいダイヤルではないということです。それは費やす資源です。「タスクが求める以上に賢い」モデルは、その余剰分について追加の価値を生みません。ただ費用が高く、応答が遅くなるだけです。目標は、タスクの難しさとモデルの能力が出会う地点を見つけ、そこで止めることです。

まずはタスクを正直に記述することから

モデルを比較する前に、そのタスクが本当に求めているものを記述しましょう。いくつかの問いがこれを手早く鋭くします。そのタスクは多段階の推論を必要とするのか、それとも参照や変換に近いのか。入力はどれくらい多様か、狭く予測可能な形式なのか、雑然とした自由形式のテキストなのか。誤った答えはどれくらい高くつくのか、些細な不快なのか、本当の失敗なのか。そしてレイテンシはどれくらい目に見えるのか、人間が応答を待っているのか、それともバックグラウンドで走るのか。

分類、抽出、整形、短い書き換え、ルーティングは、この意味でたいてい簡単です。予測可能な入力、明確な正解、浅い推論で済みます。自由形式の分析、多段階の計画立案、ニュアンスのある文章作成、そしてモデルが多くの制約を同時に保持しなければならないタスクは難しいものです。ここでは正直になりましょう。重要に感じるからといってタスクを難しいと呼びたくなる誘惑があります。重要さと難しさは別物です。仕組みが単純な重要なタスクは、やはり小さなモデルに属するのです。

安いものから始める方法

確実な選び方は、小さく始めて、迫られたときだけ上に上がることです。ファミリーで最小のモデルから始め、現実の多様な入力一式に対して走らせます。一つのデモではなく、簡単なケースも厄介なケースも網羅したひと握りの入力です。出力を読みましょう。小さなモデルが確実に十分良ければ、それで完了です。最も速く最も安い選択肢を手にしたことになります。

もし失敗するなら、どのように失敗するかを見ましょう。修正策が大きなモデルではなく、より良いプロンプトであることもあります。より明確な指示、一つか二つの例、名前を付けた失敗モードです。まずそれを試しましょう。公平なプロンプトを与えてもなお小さなモデルが及ばなければ、中間ティアに上げて繰り返します。最大のモデルへの引き上げは、本物の評価によって小さなものでは仕事ができないと示されたときだけにします。この最下層から登るアプローチは、デフォルトで払いすぎることを防ぎ、大きなモデルなら静かに覆い隠してしまったであろうプロンプトの問題を浮かび上がらせます。

モデルをアプリではなくステップに合わせる

よくある誤りは、アプリケーション全体に一つのモデルを選ぶことです。現実のシステムのほとんどは、難易度の異なるステップからなるパイプラインです。リクエストを適切なハンドラーへルーティングするのは簡単です。複雑な問いに丁寧な答えを起草するのは難しいことです。その答えをJSONに整形し直すのは、また簡単です。あらゆるステップに最大のモデルを使うということは、些細なものにまでプレミアム料金を払うことを意味します。

より良い設計は、各ステップにモデルサイズを割り当てます。安いモデルが分類、ルーティング、抽出、整形を担います。高価なモデルが、本当に深い推論を必要とする一つか二つのステップを担います。これはときにカスケード、あるいはルーターパターンと呼ばれます。小さなモデルが大半の作業をこなし、直接答えるか、難しいケースをより大きなモデルへ引き渡すのです。その結果が、能力の予算を重要なところに費やし、それ以外のあらゆる場所で節約するシステムです。

正確さだけでなく、コストとレイテンシも天秤にかける

正確さは見出しですが、唯一の軸ではありません。レイテンシはユーザー体験を直接形づくります。数秒かかる応答は、対話的なチャットでは壊れているように感じられますが、夜間のバッチジョブでは問題ありません。人間が待っているなら、わずかに洗練を欠いていても速い小さなモデルが、わずかに優れていても遅い大きなモデルに勝つことがあります。

コストはスケールで膨らみます。リクエストあたりでは些細に見えるティア間の価格差も、数百万回の呼び出しを掛け合わせれば、持続可能なプロダクトと持続不可能なプロダクトの分かれ目になります。評価する際は、候補ごとに正確さ、レイテンシ、コストを一緒に書き留めましょう。正しい選択はしばしば、正確さの基準をクリアする最小のモデルです。なぜなら、それは他の二つの軸で決定的に勝つからです。大きなモデルは、正確さの差が本物で、その賭け金がプレミアムを正当化するケースのために取っておきましょう。

時間をかけて判断を見直す

モデルの選択は永続的ではありません。プロバイダーは新しいモデルを定期的にリリースし、来年の小さなティアはしばしば去年の大きなティアに匹敵します。今日あなたの最大のモデルを必要としたタスクが、次のリリース後にはより安いもので快適に走るかもしれません。新しいモデルが出たときに対して再実行できるよう、評価セットは手元に残しておきましょう。最初に選ぶのを助けた同じセットが、その選択を安価に見直させてくれます。そして傾向はほぼ常に、上ではなく一段下へ移ることを支持します。

これはまた、特定のモデルに関する前提をプロンプトやコードにハードコードすべきでない理由でもあります。モデルを小さな抽象化の背後に置き、差し替えが書き直しではなく設定変更で済むようにしましょう。モデルの進歩から最も恩恵を受けるチームは、切り替えを容易にしておいたチームです。

まとめ

モデルサイズを選ぶことは、最大化ではなくマッチングです。タスクの本当の難しさを記述し、最小のモデルから始め、本物の評価が迫ったときだけ登りましょう。アプリごとではなくステップごとにサイズを割り当て、安いモデルが簡単な作業を、高価なモデルが少数の難しい部分を担うようにします。正確さと並べてレイテンシとコストを天秤にかけましょう。基準をクリアする最小のモデルが、たいてい総合で勝ちます。そして新しいモデルが出るたびに選択を見直しましょう。賢明なデフォルトは、ますます安くなり続けるのですから。