証拠に基づいてモデルを選ぶ

何を判断するかを定める

モデルを比較するには、具体的な用途が必要です。小さな関数の説明が得意なモデルでも、大きなリポジトリの変更を同じように扱えるとは限りません。定型的な変換なら、低コストのモデルで品質要件を満たせる場合があります。難しい調査には、より高い推論能力が必要かもしれません。

最初にタスクと制約を書きます。使用を許可するデータ、必要なツール、応答時間、許容できる費用の上限を含めます。一部の制約は必須です。別の点数が高いからといって、データの扱いに関する制限を平均点で相殺してはいけません。

チームが実際に行う作業から、小さな評価セットを作ります。評価環境が機密データの利用を承認されていなければ、そのデータを取り除いてください。簡単なタスク、難しいタスク、不足情報を求めるのが正解となるタスクを含めます。

架空のレポートサービスなら、既知の日付の不具合、小さなフィルター機能、認可ルールの説明を使います。比較を実行する前に、期待する結果を準備します。既知の不具合があると失敗するネガティブテストも含めます。

一部のタスクは、プロンプトの調整用から分けておきます。すべての例でプロンプトを繰り返し調整すると、最終点数が一般的な性能を過大に示す可能性があります。別の評価セットがあれば、調整に使った例以外でも改善したプロンプトが機能するか分かります。

モデルの正確なバージョン、プロンプト、渡したコンテキスト、ツール、権限を記録します。開始時の状態を同等にしてください。一方のモデルにリポジトリ全体を渡し、他方には一つのファイルだけを渡すと、モデルに加えてワークフローも比較することになります。

ワークフローの比較も有用です。ただし、何を比較したか正しく示します。エージェント製品にはモデル以外の要素もあります。コンテキストの選択、ツール、実行上の制限、復旧時の動作も結果に影響します。

出力のばらつきが重要な場合は、繰り返し実行します。最良の結果だけを報告せず、失敗した試行も記録してください。主観的な基準には、文書化した評価基準を使い、可能なら複数人でレビューします。

まず必須の受入基準を確認します。変更は要件を満たしていますか？アクセス制御を保っていますか？関連テストは成功しますか？レビュー担当者は差分を理解できますか？

次に、受入可能な結果について工数、経過時間、費用を比較します。再試行と人のレビューも含めます。回答の単価が安くても、何度も修正が必要なら、タスク全体では高くなることがあります。

公開ベンチマークは候補を探す助けになります。ただし、特定のタスクセットと採点方法を使っています。その点数を、チームの生産性を直接測った値として扱わないでください。

推奨範囲は狭くても構いません。例えば「このリポジトリで小さなテストを追加する場合に、既存のレビュー要件を守ってこのモデルを使う」です。すべてのタスクに一つのモデルを使う必要はありません。

何が起きたら再評価するかを明記します。モデルのバージョン変更、ツール設定の変更、新しいデータ分類、継続的な失敗パターンなどが考えられます。選んだモデルの能力を超えるタスクには、代替手段を用意します。

評価の目的は、実際の判断に伴う不確実性を減らすことです。支援対象の仕事より多くの工数を使う、終わりのないモデル比較にしないでください。