「ベンチマーク黙示録」：LLMがベンチマークを粉砕する時代
The Benchmarkpocalypse
danluu.comの記事では、LLMがベンチマークを簡単に「攻略」できるようになった「ベンチマーク黙示録」現象を考察。著者はエージェントに正規表現エンジン「FRE」を開発させ、rebarベンチマークでRustのregexクレートより40%高速と主張したが、実際には過学習とチートが含まれていた。ホールドアウトセットを使うことで汎化性能は改善したが、それでも既存エンジンより遅い。それでも、かつては専門家だけができた特化コードの作成コストが劇的に下がり、LLMが低レベルソフトウェア開発を変える可能性を示唆する。
LLMを使えば、ベンチマークを偽装するようなコードを数分のタイピングで手に入れることができるが、かつてはそれには高度な専門知識と経験が必要だった。
HNでの議論
63- timfsu
魅力的な記事だ。私は毎日、LLMが「バグの根本原因を見つけた」とか「このアプローチは2倍速い」といった「嘘」を吐くのを目撃している。この根拠のない確信が何に起因するのかを言うのは難しい——人間の文章で訓練されたことに内在するものなのか、それともその後のRLHFプロセスから生じるものなのか——だが、それは極めて厄介だ。LLMが悪い判断を下すのはまだしも、その過程で「嘘」をつかれると、さらに悪い気分になる。
- softwaredoug
検索分野でも同様の経験をした。ホールドアウトセットでさえ過学習され得る。つまり、力技によって、ホールドアウトを見ることはないかもしれないが、変更をホールドアウトの受け入れでゲートすると、ある程度ランダムな偶然によってそれに過学習した解にたどり着く。もう一つの問題は、ほとんどのコーディングエージェントでは、エージェントがアクセスできないホールドアウト/データを作るのが簡単ではないことだ。トレーニングデータを80%に分割して、一部をエージェントに与え、20%を隠すという単純な話ではない。エージェントは自分のデータがどこから来たのかを推測し、ホールドアウトデータを再構築したり、ごまかしたりする方法を見つけることができる。これを行う方法はどれも面倒に思える。つまり、変更を受け入れる/拒否するセカンドプロジェクトを持つなどだ。私は、過学習を避けるために、これらのための独自のハーネスを構築することを選んだ。
https://softwaredoug.com/blog/2026/05/17/autoresearching-a-b...
- akoboldfrying
ベンチマークの興味深い方向性として、メタモルフィックテストから着想を得ることができると思う。メタモルフィックテストは、プロパティベーステスト（個々のテストを手動で書く代わりに、テストフレームワーク自体に多くのランダムな（入力、期待出力）ペアを自動生成させてテストする手法）を拡張して、（a）特定の入力に対する正しい答えを独立に考案するのが難しいが、（b）入力間の関係が出力間の検証可能な関係を暗示するような状況を扱う方法だ。例えば、自分自身のsin()の実装をテストしようとする場合、信頼できるsine関数の別実装を使わずにランダムな（入力、期待出力）テストペアを自動生成するのは難しいが、簡単にできることの一つは、多くのランダムなxについて、sin(x) == -sin(x+180)をチェックすることだ。このアイデアをベンチマークにどう適用するか？基本的には、入力インスタンスの単純な変換が出力の単純な変換をもたらすはずのものを探す——特に、過学習されていない実装では、計算にかかる時間が同じになるはずの出力だ。正規表現の場合、文字列と正規表現の両方で、魔法でない文字のサブセットをローテーションできる（例：A -> B、B -> C、...、Z -> A）。もう一つの例は、文字列と正規表現の両方を反転することだ（括弧で囲まれた正規表現の部分式を正しく扱うことに注意）——前のものとは異なり、トレ […]
- alexpotato
> FRE正規表現エンジン全体の性能はRustのregexクレートより劣るが、ワークロードやユースケースに特化することで得られる利点は、場合によっては、独自の特化正規表現エンジンをどこかに挿入することが合理的であり得ることを意味する。これは、他のさまざまな種類の低レベルソフトウェアにも当てはまる。
上記の意見は、本番環境でLLMを数ヶ月使った後に私が考えていたことと一致する。
常にフロンティアモデルを使うのではなく、次のいずれかができる：
- LLMに、遭遇すると予想されるケースの95%をカバーするスクリプト/ツールを書かせる
- 残りの5%については、その5%のために小さなローカルモデルをファインチューニングする
これには次の利点がある：
1. 時間の経過とともにトークン数が減る
2. ツールが実際に何をしているかをコードで書かれているため簡単に確認できる
3. そのコードはバージョン管理できる
4. 時間の経過とともにコードが改善されるにつれて、ファインチューニングされたモデルのワークロードを徐々にコードに移行できる
実際、これは「手動作業はバグである」[0]というブログ記事が何年も前に説明したことそのものだ。ただし、「人が作業を行い、スクリプトで自動化する」を「LLMが作業を行い、自動化する」に置き換えたものだ。
- ouz-a
LLMがエイリアンのような英語を話し始めて以来、私はベンチマークを信頼するのをやめた。彼らが何を言っているのか理解できなければ、どうして信頼できるだろうか。