AI評価器は「見分けられない失敗」から育つ。EvalCEGARが示した自動評価の新しい作り方
AIが出した答えを、別のAIに採点させる。いまや珍しくない方法です。
ところが、評価する側のAIにも癖があります。文章が長いだけで高く見積もったり、自分に似た答えを好んだり、もっともらしい説明に引っ張られたりする。では、人が細かなルールをたくさん書けば安心でしょうか。
今回取り上げる論文では、そこにも落とし穴がありました。研究者が手作業で作った15個の検査ルールをまとめて使うと、正しい答えを選ぶ精度が逆に下がったのです。
一方、AIが作ったわずか55行のPythonルールは、428件の未見課題で評価精度を改善しました。しかも、一度ルールができれば、候補を評価するたびにLLMを呼ぶ必要はありません。
鍵は「よい評価ルールを書いて」と頼まないことでした。現在の評価器が見分けられない正解と誤答を探し、その具体的な盲点を次のルール作成依頼に変える。AWS Generative AI Innovation Centerの研究チームが提案したEvalCEGARは、評価器そのものを失敗から育てる仕組みです。
ただし、先に大切な線引きをしておきます。この論文が実証したのは、Pythonコード候補を選ぶ評価器です。レポート、企画書、画像など、正解が一つに定まらない制作物まで自動採点できたわけではありません。
そのうえで、EvalCEGARの考え方には、AIエージェントや記事制作の品質管理へ持ち込める重要な設計原則があります。
そもそも評価器がなければ、AIは改善できない
AIエージェントを改善する多くの仕組みは、「前よりよくなったか」を判定できることを前提にしています。
コードなら、テストに通るかを確認できます。計算なら、答えを照合できます。しかし、調査レポートや実行計画では、正解が一つとは限りません。文章の重なりを測るだけでは意味を取りこぼし、LLM審査員に任せれば審査員自身の偏りが混ざります。
人間がルールを作る方法もあります。たとえば、次のような検査です。
- 数値に出典があるか
- 結論と根拠が矛盾していないか
- 禁止語が残っていないか
- コードが例外を隠していないか
- 実行結果と説明が一致しているか
一つひとつは役立ちます。ただし、ルールを増やすほどよくなるとは限りません。正しい候補まで落とすルールが混ざれば、検査が厳しいのではなく、選別が下手になります。
EvalCEGARが向き合ったのは、この問題です。目標は万能な点数を作ることではありません。小さな検査ルールを一つずつ増やし、実際の選択結果がよくなるものだけを残します。
出発点は「評価できない二つ」を見つけること
EvalCEGARでは、各検査ルールを小さなPython関数として表します。関数は候補を見て、特定の欠陥があると判定する、問題なしと判定する、判断を控える、のいずれかを返します。
複数のルールがあると、各候補には判定の並びができます。たとえば、3個のルールがあるなら「問題なし、判断保留、問題あり」のような並びです。論文では、この並びをシグネチャと呼んでいます。
ここで、同じシグネチャを持つ二つの候補を考えます。一方は本当は正解で、もう一方は誤答です。現在の評価器から見ると両者は同じですが、正解データから見ると違う。この衝突こそ、評価器の盲点です。
EvalCEGARは、抽象化を反例で細かくしていくプログラム検証の考え方を借りています。評価ルールの集合を粗い地図と考え、その地図では同じ場所に見える正解と誤答を探す。見分けられない具体例が見つかったら、それを次の地図更新に使います。
重要なのは、AIへの依頼が毎回変わることです。
「役立つ評価ルールを作ってください」と何度も頼むのではありません。「この正解群と誤答群を分ける検査を書いてください」と頼みます。新しいルールが採用されれば候補の分かれ方が変わり、次に見つかる盲点も変わります。
単なる再抽選ではなく、失敗した場所が探索方向を決めるわけです。
EvalCEGARの一巡を5段階で見る
論文のアルゴリズムは、次の5段階に整理できます。
1. 現在のルールで候補を分類する
各候補にすべてのルールを適用し、判定シグネチャを作ります。同じシグネチャを持つ候補は、現在の評価器には区別できません。
2. 正解と誤答が混ざる最大の集団を探す
正解ラベルは学習側の課題だけで使います。同じシグネチャの中に正解と誤答が混ざっていれば、それが盲点です。EvalCEGARは、まず最大の盲点を対象にします。
3. 盲点を分ける小さな演算子をAIに書かせる
AIは抽象的な採点基準ではなく、具体的な失敗のまとまりを受け取ります。作るのは、一つの欠陥を指摘できる小さなPython演算子です。
4. 見える情報を必要なときだけ広げる
最初の演算子は、課題文と一つの候補コードだけを見ます。この狭い入力で3回失敗したら、同じ盲点を保ったまま入力を広げます。
広い入力では、同じ課題に対する別候補も参照でき、自分で入力を作って候補を実行できます。つまり、コードの形を見る検査から、候補同士の振る舞いを比較する検査へ進めます。
5. 欠陥の網羅率ではなく、実際の選択改善で採用する
候補ルールは、学習側の課題で正しい答えを選ぶ確率を改善したときだけ採用されます。少なくとも3課題を助け、害した課題より助けた課題が多いことも必要です。
ここが実務上とても重要です。「たくさん誤りを検出した」は採用理由になりません。検出数が多くても、正解を大量に落とせば選択器としては悪化します。
狭い検査では一つも採用されなかった
論文のアブレーション結果は鮮明です。
狭い入力だけで演算子を作らせた実験では、3回の独立実行で採用数はすべてゼロでした。研究全体でも、狭い入力から作った336個の候補は一つも採用されていません。
一方、他の候補を参照して実行できる広い入力へ進むと、役立つ演算子が生まれました。
これは、プロンプトを工夫すれば何でも見抜けるという話ではありません。必要な情報が入力にないなら、何回生成しても届かない。再試行回数を増やす前に、検査に必要な観測を渡せているかを見直すべきだという結果です。
もう一つの失敗は、欠陥再現率を30%以上にする条件を採用ゲートへ置いた実験です。こちらも3回すべて採用ゼロでした。
実際に最もよかった演算子は、既知の欠陥を広く拾うタイプではありません。少数でも選択に効く誤答を狙い撃ちする、疎で精密な検査でした。網羅率を先に求めると、そのようなルールを捨ててしまいます。
55行のルールは何をしていたのか
最良の演算子の中身は、意外に素朴です。
まず、問題文に見えている例を通る候補だけを残します。次に、少し変えた入力で各候補を実行します。そして、残った候補の多数派と振る舞いが違うものを疑います。
人が書いた最強の単独ルールも候補間の振る舞いを比べますが、生成されたルールはより少ない候補だけを落としました。
428件の未見課題、2,592個の候補で比較した結果は次の通りです。
| 評価方法 | 精度改善 | 到達可能な改善幅に占める割合 | 落とした候補数 | 候補ごとのLLM呼び出し | | — | —: | —: | —: | —: | | 最強の手書き単独ルール | +0.0069 | 16.3% | 515 | 0 | | 手書き15ルールを一括適用 | -0.0067 | -15.8% | 1,425 | 0 | | 最良のLLM審査員 | +0.0070 | 16.5% | 158 | 1回 | | EvalCEGARの55行ルール | +0.0065 | 15.4% | 126 | 0 |
絶対値が小さく見えるのには理由があります。428課題のうち、見えているテストを通った候補に正解と誤答の両方が残り、評価器で選び分けられる課題は58件だけでした。残りは、評価器を変えても結果が動きません。
その58件だけで見ると、55行ルールの改善は+0.0481です。論文は、改善可能な幅に対してどこまで進んだかも併記し、数字を大きく見せないようにしています。
LLM審査員と同じくらい効いたが、同じものは見ていない
最良のLLM審査員は、55行ルールとほぼ同じ精度改善を示しました。ただし、両者が問題ありとした候補の重なりは小さく、Jaccard係数は0.105でした。
つまり、結果の大きさは似ていても、捕まえた失敗はかなり違います。27件だけ両者が同意し、その一致部分は13課題を助け、害したのは1課題でした。
ここから、AICompanyとしては二つの示唆を読み取れます。
一つは、実行可能なルールとLLM審査は置き換え関係とは限らないこと。もう一つは、両者が同意した領域を高信頼な警告として扱える可能性です。
ただし、後者は論文結果から導く応用案であり、記事品質の自動判定として検証されたわけではありません。
コスト構造も違います。論文の最良実行では、演算子を作るために47回のモデル呼び出しが必要でした。しかし、完成後は候補ごとのモデル呼び出しがゼロです。LLM審査員は評価のたびに1回呼び出します。
大量の候補を繰り返し評価するなら、初期費用を払って小さな実行可能ルールへ変換する価値があります。逆に、評価回数が少ない仕事では、LLM審査員のほうが簡単かもしれません。
一度の成功ではなく、8回のばらつきを見ている
生成系の研究で気になるのは、たまたま当たりを引いただけではないかという点です。
EvalCEGARは、モデルのサンプリングだけを変えた8回の独立実行を報告しています。6回で演算子が採用され、採用された6個はすべて未見課題でプラスでした。改善の中央値は+0.0029、範囲は+0.0009から+0.0065で、6個中4個が個別に統計的有意でした。
HumanEval+への移行も確認されています。最良ルールは125課題中10件を助け、1件を害し、精度を+0.0125改善しました。最強の手書きルールと同じ改善幅ですが、落とした候補は36件で、手書き側の103件より少なく済んでいます。
さらに、ルール作成時に使わなかった3種類の生成器が作った9,320候補でも、到達可能な改善幅の22.1%を埋めました。
万能性の証明ではありませんが、一つの訓練分割だけに合った結果よりはかなり強い材料です。
評価ルールの組み合わせにも、評価が必要だった
論文の面白い点は、自分たちの組み合わせ方の失敗も詳しく調べていることです。
複数ルールから最大6個を選び、2個以上が問題ありとした候補を落とす。このとき当初は、誤答を落とした数から正答を落とした数を引く単純な目的関数を使っていました。
ところが、200万を超える組み合わせを総当たりで調べると、この目的関数が選ぶ組み合わせは、探索空間の下位に入る場合さえありました。
修正は、正答と誤答の不均衡を考慮することでした。正答を誤って落とすペナルティを、データ内のクラス比で調整したbalanced accuracy相当の基準は、4条件で91.1から98.7パーセンタイルに入りました。未見課題での改善も+0.0236から+0.0286でした。
「検査ルールを作るAI」が主役に見えますが、実は採用基準と組み合わせ基準の設計が同じくらい重要です。よい部品でも、目的関数が実際の運用目標とずれていれば、組み合わせたときに壊れます。
実務へ持ち込むなら、まず失敗台帳を作る
ここからはAICompanyの応用案です。
記事制作を例にすると、最初から「記事の品質を100点満点で採点するAI」を作る必要はありません。代わりに、現在のゲートが同じように通してしまった二つの例を残します。
- 出典はあるが、数値の対象期間が違う記事
- 参考リンクはあるが、主張を支える箇所がない記事
- 読みやすいが、一次情報と解釈が混ざった記事
- 形式上は正しいが、結論が本文の実験結果より強い記事
このうち、片方は公開可能、片方は差し戻しだったのに、現在のチェック結果が同じなら、それが衝突です。
次に、その二つを分ける小さな検査を考えます。たとえば「数値の直前と直後に、対象、条件、比較基準が揃っているか」「タイトルの中心的な約束が、本文中の一次資料で実証されているか」といった、単独で反証できる検査です。
そして、過去の判定済み記事へ適用します。検出件数ではなく、公開可否や修正優先度の判断を本当に改善したかで採用します。
運用の最小形は次のようになります。
- 現在のチェック結果と最終判断を保存する
- 同じチェック結果なのに最終判断が違う例を探す
- 違いを説明する小さな検査候補を作る
- 過去の判定済みデータで、助けた件数と害した件数を測る
- 未見の保留セットで再確認する
- 効いた検査だけを有効化し、挙動と版を固定する
ここでの主役は、生成モデルよりも失敗台帳です。何を誤って通し、何を誤って落としたかが残っていなければ、盲点を探せません。
まだ越えていない壁
EvalCEGARには、論文自身が認める限界があります。
生成されたルールは、見た目以上に似ている
ソースコードの文章は違っても、実際に落とす候補が同じという重複が多くありました。問題を指示する方法を変えても、モデルが書ける検査の発想には偏りが残っています。
183個の有効な候補演算子から得られた異なる判定集合は96種類でした。別の3シードでは、14回の採用のうち9回が既存演算子の再発見でした。
比較対象に勝ったとは言い切れない
論文が統計的に示しているのは、主に「何も落とさない評価器」よりよいことです。9回のペア比較では、ルール同士の差は有意になりませんでした。
最良の生成ルールが手書きルールやLLM審査員を一貫して上回った、という結論ではありません。
周りにいる候補が変わると判定も変わる
広い入力のルールは、他の候補を参照します。そのため、比較相手の集合を3倍にすると、調査した35個すべての演算子で一部の判定が変わりました。
再現可能な運用には、候補の集め方、件数、実行条件を固定する必要があります。
開放的な制作物ではまだ未検証
最大の注意点です。実験対象はMBPP+とHumanEval+で、どちらも隠しテストという正解判定を持つPython問題です。
記事や企画書には、そのような完全な正解判定がありません。EvalCEGARの考え方を移すには、人間が判定した小さな学習集合と、見ないで残しておく検証集合が必要です。
「評価器が自分で育つ」という見出しだけを持ち出し、人の判断を不要にするのは早すぎます。
結論。良い評価器は、良いルール集より良い失敗の残し方から生まれる
EvalCEGARの一番大きな貢献は、AIに上手な評価基準を書かせたことではありません。
現在の評価器が何を見分けられないかを具体例で示し、その盲点を次の作成依頼へ変え、実際の選択が改善したルールだけを残す。この循環を、実行可能で監査しやすい形にしたことです。
研究結果は慎重に読む必要があります。改善幅は絶対値では小さく、対象はコード生成に限られ、生成ルールの重複も多い。公開された一次資料からは、安定した実装リポジトリも確認できません。
それでも、評価の設計を「最初に完全な採点表を書く仕事」から「見分けられなかった失敗を一つずつ分離する仕事」へ変えた点は強い。
AIエージェントの品質を上げたいなら、ルールを増やす前に、いま同じ扱いをしてしまっている正解と失敗を探す。そこから始めるほうが、厳しいだけのゲートを作るよりずっと建設的です。
一次資料
本記事の数値は論文v1のSection 3、Algorithm 1、Tables 1から4、Section 6を中心に照合しました。AICompanyは論文の428課題を再実行していません。