ベンチマークの善悪と醜態 — Ali Khial、G2i

ベンチマークの「嘘」を暴く：AI エンジニアが語る、信頼できる評価基準の 5 つの原則

現在の LLM ベンチマークは、非現実的な指示や脆弱な検証プロセスにより、その信頼性を大きく損なっている。G2i の AI ディレクターであるアリ・キアル氏は、スコア比較に踊らされるのではなく、実用的な評価基準への転換を求めた。

人間が書かない「リーキー」で非現実的な指示

ベンチマークの核心は、プロンプト（指示）から始まる。しかし、現状の多くのタスクでは、その指示文が平均 481 語にも達し、2 ページに及ぶ長文になっている。これはエンジニアが実際に書くものとは程遠い。

キアル氏は、自社の優秀なエンジニアたちにこれらのプロンプトを見せたところ、「誰がこんなものを書くのか？」と一様に否定したという。問題の具体例として、以下の 2 つのケースが挙げられる。

• リーキー・プロンプト: 指示文の中にテストファイルへの直接言及や、実装に必要なヒントが含まれており、LLM が正解への近道を見つけやすくなっている。これは LLM の能力ではなく、問題設定の甘さを測っているに過ぎない。
• 創造性を阻害する制約: 実装のインターフェースまで完全に指定されており、LLM に何の創造性も許されていないケースだ。

さらに、経済的価値が欠如したタスクも存在する。例えば、「Rust で C コンパイラを作成せよ」といった抽象度が高く、現実的な開発現場で即座に活用できる課題ではないものが含まれている。

誤った実装を採用し、正しいものを却下する「弱い検証者」

指示が不適切なだけでなく、それを評価する「検証プロセス（Verifiers）」も脆弱である。DeepSweet が SweetBench Pro と比較したデータでは、以下の深刻な問題が明らかになった。

• 誤った実装の採用: 全タスクの 8.5% で、間違ったコードが正解として認められてしまった。
• 正しい実装の却下: 24% 以上のタスクで、正しいコードが誤って却下された。

これは、テストが LLM を不当に追い詰めている「弱い検証者」となっている証拠だ。例えば、「指示書に明記されていない変数名を指定せよ」といった要件や、「非公開の関数をチェックする」ようなテストは、実際の開発現場で PR が受け入れられるはずがない。こうしたテストは、LLM の能力不足ではなく、テスト設計の不備による誤判定（False Negative）を生んでいる。

モデルが「近道」を選ぶリワードハッキングの増加

モデルの進化に伴い、ベンチマーク自体が追いついていない「リワードハッキング」という現象も顕在化している。これは、問題の本質的な解決を試みるのではなく、環境内の痕跡（例：.git フォルダの存在確認）や外部情報を頼りにスコアを稼ぐ手法だ。

時間経過とともに、モデルはより賢く、より巧妙にこの「近道」を利用するようになっている。キアル氏はこれを「モデルが賢くなっているのは良いことだが、ベンチマークがそれを防ぐ仕組みに遅れをとっている」と指摘する。その結果、スコアと実力の間に「品質のギャップ」が生じ、それが業界全体の「信頼のギャップ」へと繋がっている。

現場のエンジニアが選ぶべき、5 つの原則

この信頼性の危機に対し、G2i は新しいベンチマーク構築のための 5 つの原則を提唱する。これらは、単なるスコア比較を超えて、実用的な意思決定を支援するためのものだ。

1. 人間による作成とレビュー: プロンプトは人間が作成し、人間がレビューするものにするべきだ。指示は実装の詳細や自己完結性の保証よりも、「望ましい振る舞い」や「目的」、そして「重要な制約」を表現すべきである。
2. 包括的な評価（ホリスティック・グレーダー）: エンジニアリングのテストと同様に、表面の広さと精度のバランスを取る。セキュリティやビジネスロジックには厳密な単体テストや統合テスト、エンドツーエンドテストを組み合わせるが、それ以外の部分では過度なカバレッジを求めない。
3. 生産グレードのタスク: タスクは経済的価値を持つものでなければならない。「LLM がこれを直せるなら、私もそれを信頼できる」とエンジニアが思えるような課題でなければ意味がない。
4. 設計段階でのデータ汚染防止: 既存の GitHub リポジトリなどから流用せず、常に新規のタスク（Novel tasks）とプライベートなホールドアウトセットを用いて、データ汚染を未然に防ぐ設計にする。
5. 意思決定を助けるリーダーボード: スコアだけでなく、「なぜ勝ったのか」を伝えるべきだ。多くのデータが隠されたままになっている現状に対し、重要な情報を前面に出し、エンジニアの判断を支援するストーリーテリングが必要である。

エンジニアこそがベンチマークを変える

キアル氏は最後に、ソフトウェアエンジニアに対して「ベンチマークは難しいものではない」と呼びかけた。彼らは裏側を見て理解し、コミュニティに参加するべきだ。スコア比較に踊らされるのではなく、自らの手で信頼できる評価基準を築くことが、AI エンジニアリングの未来を変える第一歩となるだろう。