大規模言語モデルを「審判」に使うのは、いまやエージェント評価の定番だ。環境からの報酬信号は高価で遅く、デプロイ時にはそもそも手に入らない。そこで第二のLLMに採点を任せるわけだが、問題はその審判が「流暢だけど成功していない」軌道に騙されやすいこと。論文チームはこの現象をover-crediting、つまり過剰評価と呼ぶ。
手書きルールでも重み調整でもない第三の道
既存の自動審判には二つの流儀がある。G-Evalのように人間が採点基準を詳細に書くか、それとも審判モデルの重みを微調整するか。どちらも弱点がある。手書きルールはタスクの変化に追従しづらく、重み調整は判断プロセスがブラックボックス化する。RubricForgeはこの中間を行く。少量の正解ラベル付き軌道から、反射的進化を使って採点ルールを自動生成するのだ。生成されるのは純粋なテキストで、人間が読める。すべての採点結果が具体的な評定項目に遡れる。
処理は三つのステップに分かれる。ラベル付き軌道上で反射的進化を繰り返し、実際の環境報酬との一致率が最大化するまでルールを洗練させる。次にそのルールを固定する。最後に未見の軌道に対して、モデル呼び出し一回だけで判定を下す。環境報酬は一切使わない。この最適化の産物が可読テキストである点は思わぬ副産物を生む。どの判定も具体的な項目に紐づくため、微調整モデルのように説明不能なまま放置されない。
tau-benchとWebShopで何が起きたか
論文では凍結した7Bモデルをエージェント兼審判として使い、tau-bench（220件のロールアウトから173件のラベル付き軌道）とWebShop（160件）で比較実験が行われた。結果はこうだ。RubricForgeの改善は「総合一致率」ではなく「忠実度」に現れた。エッジの優位は統計的に有意とまでは言えず、絶対スコアの調整では汎用のG-Eval系審判にやや劣る。だが最も重要な指標では明確に勝った。過剰通過率がtau-benchで0.173から0.115へ、ほぼ半減している。
著者らは、報酬なし評価では過剰通過率が総一致率よりずっと重要だという。過剰通過は問題のあるエージェントを本番に送り出すが、過剰失敗はせいぜい再試行で済むからだ。
さらにWebShopの段階的評価では順位相関がわずかに上回った（Spearman 0.410対0.370）。実験中、従来なら見逃された失敗を三回検出し、逆方向の誤検出は一度も起きなかった。
誰にとって役に立つのか
- エージェント評価を自前で回しているチーム：G-Evalの手書きルールが不安定で困っているなら、低コストでルールを自動生成できる選択肢になる。
- 説明可能性が要るコンプライアンス領域：判定ルールも判定結果も遡れて、監査に耐えやすい。
- 単一の審判モデルに依存している運用側：小さなモデルがエージェントと審判を兼ねるので、追加の報酬計算が不要になる。
もちろん限界もある。現時点の実験規模は小さく、汎用モデルとの差は統計的有意ではないと著者自身が認めている。公開されている技術詳細も限定的で、アーキテクチャの違いは完全版論文を待つしかない。
使う側の注意点
再現や応用を考えているなら、次の点を押さえておきたい。第一に、RubricForgeの価値は過剰評価の低減にあって、通常の採点一致率を上げるものではない。評価するなら指標を間違えないこと。第二に、出力されるルールはテキストなので、審判がどの基準で点数をつけているのか直接検証できる。第三に、ベースモデルの選択が効く。7Bモデルはタスクによって挙動が安定しないことがある。
全体として、これは一つの方向検証だ。評価ルールを実データから「成長させる」ほうが、重みを弄るより制御しやすい。今後、より多くのタスクと大きなモデルで安定的な利得が確認できれば、自動評価基盤の信頼できる部品になるかもしれない。
コメント
コメントはまだありません
最初のコメントを書きましょう