ベンチマークポカリプス

ベンチマークポカリプスについて、セキュリティ分野の「バルナポカリプス」ほどではないにせよ、あまり議論されていないように思います。深刻なパフォーマンス向上を達成することがかつてないほど容易になった一方で、ベンチマークを不正に操作して偽のパフォーマンス向上を報酬として与えることも、かつてないほど容易になりました。 前者は多くの異なる企業で静かに進行していると思われますが、後者は最近では週に少なくとも一度は目にします。誰かがXを最適化して既存のソフトウェアよりも大幅なパフォーマンス向上を得たと主張するのですが、よく見ると、実際の世界のパフォーマンスを向上させることなく、ベンチマークのパフォーマンスを向上させる最適化を行っただけだったりします。これは、しばしば「XをRustで書き直した」プロジェクトや、資金調達または販売を目指す新しいスタートアップによるものですが、他の種類のプロジェクトでも起こります。 もちろん、人々は昔から自分のペットプロジェクトが優れていることを示すために、代表的でないマイクロベンチマークを誇張してきました。代表的でないマイクロベンチマークを偽造することは常に容易であり、それは決して変わらないでしょう。変わったのは、かつては大規模なベンチマークスイートを不正に操作するには多くの作業が必要でしたが、LLMとループ（繰り返し処理）があればそれが簡単にできてしまうことです。 かつてこれが困難だった頃の、大規模ベンチマークスイートを不正に操作した有名な例がいくつかあります。例えば、かつてSPECint / SPECfpがワークステーションパフォーマンスの代理として重視されていた頃、CPUベンダーはベンチマークの計算を高速化するコンパイラの「最適化」を見つけようとしていました。例えば、SunはSPECfp2000の179.artを12倍改善する方法を見つけました。熟練したエンジニアは、そのようなベンチマークハックを見つけるために多くの時間を費やしました。 LLMはこれを些細なことにしてしまい、結果を監査するか、監査した誰かを信頼しない限り、かつて信頼されていたベンチマークを無意味なものにしています。誰かの悪い主張を指摘する代わりに、私がここで開発したエージェントによって構築された正規表現エンジンであるFREを挙げます。これは、かなり包括的なrebar正規表現ベンチマークスイートでRustの正規表現クレートを上回るため、世界最速の正規表現エンジンだと主張できます。しかし、これはエージェントを1ヶ月間ループに入れ、ベンチマークに過剰適合しないように指示しましたが、実際の監視はありませんでした。 ほとんどの場合、LLMに良いベンチマークスコアを出させるのは非常に簡単であり、このケースも例外ではありませんでした。Rustの正規表現クレートのパフォーマンスに大体追いつくのに数週間かかり、その後rebarで1.4倍速くなるのにさらに数週間かかりました。しかし、エージェントは、真剣なガードレールを設けない限り、ハックや過剰適合を報酬として与える傾向があります。このケースでは、実験としてそれを行いませんでした。 過剰適合をチェックするために、私はやや恣意的にripgrepベンチマークコーパスをホールドアウトベンチマークとして使用しました。ベンチマークがアルゴリズム的な破裂のために永遠にかかるわけではないケースでは10倍遅く、ベンチマークが完了するのを待つことさえ合理的ではないほど時間がかかるケースもありました。40%速いというのは、この結果からするとあまり良いとは言えません。 Andrew Gallant（別名BurntSushi）のrebarベンチマークスイートは、ベンチマークスイートとしてはかなり包括的ですが、たとえかなり包括的なベンチマークスイートであっても、エージェントは、必ずしも良い一般的なパフォーマンスを与えない方法で過剰適合しながら、高いスコアを獲得することに問題はありません。 次のステップは、以前に議論したトリックを使用することでした。LLMに不正をしないように指示するだけでなく、評価対象となるホールドアウトベンチマークセットがあることを伝えることです。その後、LLMはパフォーマンスを適度に一般化し、全体として最速の汎用正規表現エンジンの約2.4倍遅くなりました。これは、現存する最速の汎用正規表現エンジンと比較していることを考えると、かなり良いように聞こえます。 しかし、これらのベンチマークはコーディングエージェントによって作成されたことを思い出してください。ベンチマークが測定しているものを調べると、少なくとも同等の重みで含めるのが意味をなさないものもあります。重要だと思われるベンチマークのみを見ると、FREはホールドアウトで4倍遅くなります。これは、「ホールドアウトがある」と伝えるトリックを適用する前よりもかなり改善されていますが、それでも40%速いという主張からは程遠いです。 このことについて興味深い点がいくつかあります。 1. エージェントにベンチマークに過剰適合したり、不正に勝利しないように指示した場合でも、意味のない方法で非自明なベンチマークを「勝利」させることが容易であること。 2. LLMにホールドアウトセットがあることを伝えることは、LLMに汎用的な作業を行うか、過剰適合しないか、不正をしないように指示するよりも効果があったこと。 3. FREの全体的なパフォーマンスはそれほど良くありませんが、一部のユースケースでは実際にパフォーマンスが向上していること。一般的に、かつては特定のユースケースのために専門的なコードを書くのに高度なエンジニアリング経験を必要としたコストが大幅に低下していること。 (1)について、多くの偽の主張を目にするのも無理はありません。過去には、FREのように、40%の速度向上を偽って主張できるほどパフォーマンスを偽装するようなものを作成するには、かなりの専門知識が必要でした。少なくとも、文字列マッチングアルゴリズム、正規表現エンジン、およびまともな一般的なコード最適化とSIMD最適化スキルについてかなり深く理解している必要がありました。FREには正規表現をマシンコードにコンパイルするモードもあるため、コンパイラに関する専門知識も必要でした。今では、数分間タイプするだけで、そのようなベンチマークチート（チートを望むかどうかにかかわらず）を得ることができます。 (2)について、これが一般化するかどうかは興味がありますが、十分な例を試していないため、まだ判断できません。 (3)について、ほとんど人間の努力なしに作成された、堅牢で既存の、十分にテストされたライブラリよりも遅いバイブコードの正規表現ライブラリを使用する理由はありません。そのため、FREアーティファクトは興味深いものではありません。ここで興味深いのは、かつて希少で専門的で高価だった知識を、LLMがどれほど代替できるかということです。 過去には、たとえ知識があったとしても、おそらく特定のワークロードに最適化されたカスタム正規表現エンジンを書くことはなかったでしょう。人々がそのようなレベルのカスタマイズを行う大規模なユースケースがいくつかあります。例えば、私がBingインデックスに取り組んでいた頃、コードには複数の異なるコンパイラが含まれていました。なぜなら、検索エンジンではコンパイル時間とコンパイルされたパフォーマンスの両方を気にし、トレードオフは場所によって異なるため、通常のプロジェクトではインタプリタを使用したり、データ構造を「通常のコード」で直接ウォークしたりする代わりに、場所ごとにカスタムコンパイラを作成することで、より良いパフォーマンスが得られるからです。これらのコンパイラを作成した人物は、正規表現のようなコードに取り組む際に、複数のカスタム正規表現エンジンを作成したかもしれませんが、そのような専門的なコードにそのような時間を費やす専門知識と意欲の両方を持っている人はほとんどいませんし、ましてや仕事のために費やす自由を持っている人はさらに少ないでしょう。 そのBingエンジニア（当時パートナーレベルのエンジニアで、検索インデックスでの功績によりディスティンギッシュドエンジニアに昇進）のコストを、LLMをループで実行するコストと比較すると、この種の専門的なコードを書くコストは桁違いに低下しました。 FRE正規表現エンジンの全体的なパフォーマンスはRustの正規表現クレートよりも劣りますが、ワークロードやユースケースに特化することで得られる改善は、場合によっては、独自の専門的な正規表現エンジンをどこかに挿入することが合理的になる可能性があることを意味します。これは、さまざまな種類の低レベルソフトウェアにも当てはまります。 AIマキシマリストでなくても、数年以内に、データベースのようなより大きなものに対しても同様のことが起こる可能性があると考えるのはもっともらしいことです。 コメント/修正/議論について、Yossi Kreinin、Jamie Brandon、Peter Geoghegan、Luke Burton、John Spurling、Dennis Snell、Max Bittkerに感謝します。 追記：ここでの議論によると、LLMにより、少し触って好奇心を満たすのにかかる時間は大幅に短縮されましたが、ブログに掲載するのに十分な厳密さで何かを書き上げるのにかかる時間は（さまざまな理由で）実際には変わっていません。