エバリュエーター・オプティマイザー

課題

1回の実行（シングルパス）による出力では要件を満たせない可能性があり、使用前にそれをチェックして改善するための組み込みメカニズムが存在しません。

適用対象

明確な評価基準を定義でき、反復的な改善によって結果が測定可能に向上する場合（翻訳品質、テストに合格する必要があるコード、ルーブリックに沿った執筆など）に、エバリュエーター・オプティマイザーを使用します。

解決策

非推奨のケース

• 基準を明確に定義できない場合。
• 1回の実行（シングルパス）で十分に良好な結果が得られる場合。
• レイテンシーやコストの予算（上限）が非常に厳しい場合。

テクノロジー

事例

• コードを生成し、テストを実行し、合格するまで修正する。
• 翻訳の下訳を作成し、原文に照らし合わせて洗練させる。
• 批評家が各基準を強制するルーブリックに沿って執筆する。

KPI

承認率

エバリュエーターが最初のパスで承認した候補出力の割合。高すぎる場合は基準が低すぎ、低すぎる場合はジェネレーターまたはルーブリックに問題があります。

承認までの反復回数

承認されるまでの平均的な「評価→修正」ループ回数。回数の増加は、ジェネレーターの性能不足または基準の曖昧さを示しています。

承認された出力あたりのコストとレイテンシー

最終的な呼び出しだけでなく、すべてのループ反復における総トークン数と実時間（ウォールクロック時間）。ループによって両方が乗算されます。

評価と人間の合致度

サンプルセットにおいて、評価器の判定が人間のレビュー担当者と一致する頻度。ループの品質は評価器の品質に依存します。

観察された失敗パターン

• 報酬ハッキング：生成器が本来の目標ではなく、評価器の文言を満たすように学習してしまうこと。
• 脆弱または調整不足の評価器：不適切な出力を受け入れたり、適切な出力を拒否したりするため、品質が向上しないままループのコストだけが増加すること。
• 無限ループまたは振動ループ：どの候補も基準をクリアできない場合、反復回数の上限を設定していないとコストが無限に膨らむこと。
• 基準のドリフト：評価基準（ルーブリック）が曖昧または変動することで、承認プロセスが非決定論的になり、監査が困難になること。

得られた教訓

• 反復回数に上限を設け、フォールバック（これまでの最善策を返す、またはエスカレーションする）を定義して、ループが必ず終了するようにします。
• 承認基準を明確かつ安定したものにします。評価器の品質は、その評価基準（ルーブリック）の品質に依存します。
• 評価器をゲートとして信頼する前に、人間の判断と照らし合わせて検証します。
• コストの倍増に見合う品質が求められる場合にのみループを使用し、低コストでリスクの低い出力には使用しません。

FAQ

リフレクション（自己反省）とはどのように違うのですか？

リフレクションは、同一のモデルが自己批判を行います。評価器-最適化器（Evaluator-Optimizer）パターンでは役割を分離し、独立した評価器が生成器を判定するため、より鋭く偏りの少ないフィードバックが得られることが多くなります。

評価器を決定論的にすることはできますか？

はい。コードの場合はテストランナーが理想的な評価器となり、構造化出力の場合はスキーマチェックが有効です。ニュアンスの伴う基準には、モデルによる判定（Model Judge）を使用します。

反復回数は何回にすべきですか？

予算（例：2〜3回）を設定し、基準をクリアした時点で停止します。制限のないループはコストを浪費し、収束しない可能性があります。

参考文献

• Anthropic — Building Effective Agents (2024)

関連パターン