実運用のプロダクトに合うAIモデルの選び方

モデル選定は、ランキング問題として扱われることが多い。最も優れたモデルを見つけ、それを使う、という発想だ。しかしこの発想からは、決まって二つの結果しか生まれない。単純な作業に高コストなシステムを使ってしまうか、誰もテストしていない場面で失敗する安価なシステムができあがるか、のどちらかである。

より適切な発想は調達である。まず制約条件、次に候補の絞り込み、最後にテスト。 実際の作業の大半を担うのは制約条件であり、それはモデルに対する意見ではなく、自社のプロダクトが持つ性質そのものである。

適合性を決める6つの要素

自社タスクにおける品質。 一般的な品質ではない。美しい文章を書けるモデルが構造化フィールドの抽出は不得手なこともあれば、数学的な推論に強いモデルが分類作業では無用に遅いこともある。一般的なランキングは、どのモデルをテスト対象とするかを絞り込むふるいであって、テストそのものの代わりにはならない。

リクエストあたりのコスト。 入力・出力トークンの単価に、実際のトラフィック量を掛け合わせて算出する。重要なのは想定利用量における月間支出額であり、これは事後ではなく事前に計算しておく価値がある。なお、推論型モデルは内部の思考過程も出力トークンとして課金されるため、タスク完了あたりの実質コストは公表単価の数倍に達することがある点に注意したい。

レイテンシー。 一つではなく二つの数値で捉える。最初のトークンが返るまでの時間は、ストリーミング形式のインターフェースにおける体感応答性を左右する。生成完了までの総時間は、バッチ処理におけるスループットを左右する。対話型プロダクトは概ね前者を重視し、夜間バッチ処理は後者のみを気にすればよい。

コンテキストウィンドウ。 実際の入力データの分布を、95パーセンタイルで測定する。まれにしか発生しない最大値に合わせて選定すれば、月に数回しか使わない容量分のコストを、すべてのリクエストで支払い続けることになる。

統合機能。 ツール呼び出しの信頼性、スキーマに従った出力の強制、ストリーミング挙動、必要であれば画像や音声の入力対応。これらはモデル間で、一般的な品質スコアが示唆する以上に大きくばらつく要素であり、統合がうまく機能するかどうかそのものを左右することが多く、単に機能の出来不出来にとどまらない。

運用環境とデータに関する制約。 データがどこで処理されうるか、保持ポリシーはどうなっているか、リージョン別のエンドポイントが存在するか、自社環境内で稼働させられるか。これらはエンジニアリングチームの外で決定されることが多く、他のどの要素にかかわらず候補を除外しうる。

自社の実例でテストする

2〜3件に絞り込んだ候補に対して、最終的な判断を下すのはテストであり、そのテストは大がかりなものである必要はない。

自社の実際のトラフィックから抽出した50件の実例を用意し、各候補で実行したうえで、平均値ではなくケースごとに比較する。平均値からはほとんど何も分からない。重要な情報は、どの具体的なケースでどのモデルが間違えるか、そしてそのケースが実際に重要かどうかである。全体としてはやや劣るモデルであっても、コストの高いカテゴリーでは一度も失敗しないのであれば、そちらのほうが優れた選択となる場合があり、こうしたことは総合スコアからは分からない。

実務上の注意点が二つある。最初の比較では全候補に同一のプロンプトを使い、公平な基準を確保すること。そのうえで、決定を下す前に、最有力候補向けにプロンプトを少し調整する時間を取るとよい。モデルによって反応の仕方が異なるため、一つのモデル向けに調整されたプロンプトは、他のモデルの実力を過小評価してしまうことがあるからだ。そしてレイテンシーとコストは同じ実行の中で測定すること。そうすることで、三つの指標すべてが一つの実験から得られることになる。

大半のトラフィックには最強のモデルは不要

これは最も大きな財務上の影響を持つ着眼点であり、ほぼすべてのプロダクトに当てはまる。

実際のトラフィックの難易度は一様ではない。サポート用のアシスタントは、大量の定型的な質問と、少数の本当に難しい質問に対応する。分類パイプラインが目にするのも、大半は明確に判断できる案件である。そのすべてを利用可能な最強のモデルに送るということは、最も簡単な作業に対して最も難しいケース向けの料金を支払っているということにほかならない。

標準的な対処法はルーティングである。小規模で高速なモデルが大半を処理し、信頼度シグナル、カテゴリー、あるいは検証エラーが難易度を示した場合にのみ、より大きなモデルへとエスカレーションする。この方法による節約幅はしばしば大きく、コストがかさむのは高頻度な部分であるため、そこを抑えつつ、必要なケースについては品質の上限を維持できる。

ルーティングにはそれ自体のコストもある。二つのモデルを評価する手間、ルーティングルールの保守、そしてルーターが難しいケースを小規模モデルに送ってしまうという新たな失敗パターンである。一定のトラフィック量があれば見合うが、ある閾値を下回ると割に合わない。この閾値は自社のトラフィックに固有のものであり、算出するには半日ほどの作業で足りる。

変化を見越して選ぶ

何を選んでも、いずれは置き換えられる。一年後に利用可能なモデルは、より安く、より速く、あるいはより優れたものになっているはずであり、今下す判断が、後から見直すのに手間のかかるものであってはならない。

このコストを低く抑える習慣が三つある。プロンプト、ツール定義、出力のパース処理は自社のコード側に保持すること。そうすれば、プロバイダーの切り替えは書き直しではなく設定変更で済む。評価用データセットを保持すること。これがあれば、新しい候補の評価は一大プロジェクトではなく一日仕事で済むようになる。そして変動するエイリアスを追うのではなく、モデルのバージョンを明示的に固定すること。そうすれば、挙動の変化は偶然発見するものではなく、こちらのスケジュールで対応するものになる。

最後の点は特に強調しておきたい。プロバイダーの最新エイリアスに追従し続けるシステムは、あらゆる挙動の変化を自動的に引き継ぐことになり、それには入念に調整したプロンプトを壊してしまうような変化も含まれる。バージョンを固定し、新しいバージョンが登場したら評価を実行し、意図的にアップグレードすること。

手順のまとめ

1. 5つの制約条件を数値として書き出す。
2. それらを満たす候補を絞り込む ― 通常は2〜3件になる。
3. それぞれについて50件の実例を実行し、ケースごとの品質、レイテンシー、コストを合わせて測定する。
4. 最有力候補向けにプロンプトを調整し、再実行する。
5. 最高スコアのモデルではなく、合格ラインを満たす中で最も安いモデルを選ぶ。
6. バージョンを固定し、評価用データセットを保持し、新しいモデルが登場したら見直す。

手順5こそが、コスト削減の大半が生まれる箇所であり、同時に人々が飛ばしがちな手順でもある。最強のモデルを選ぶほうが、十分なモデルを選ぶよりも安全に感じられるからだ。しかし、リクエスト単位で一年間を通して見れば、実際にはそうとは限らない。