次レベルのベンチマーク過学習 – Thomas Neumann

私の最近のブログ記事で述べたように、データベースベンチマークは危機に瀕しています。なぜなら、AIエージェントが疑わしい手法で個々のベンチマークに過学習し始め、実行時間をゼロに近づけているからです。これは過去にTPC-Dでも起こり、ベンチマークを壊しました。TPC-Hはルールでこれを防ごうとしていますが、(非公式な)TPC-Hの結果を発表するほとんどの人はルールを無視しています。過剰に意欲的なAIエージェントと組み合わせると、これは悲惨な過学習につながります。

私たちはGenDB-Vシステムで、その次のレベルを見ています。関連する論文は「Stop Handcrafting Your Engine! GenDB-V: Towards AI-Generated and Formally Verified Database Systems」と題されており、UmbraとDuckDBに対して22倍から61倍の速度向上を報告しており、しかも完全に検証されたシステムでこれを行っています。これらは確かに印象的な主張であり、従来のデータベースエンジンが危機に瀕していることを示唆するはずです。

しかし、一歩引いて考えると、Umbraに対する22倍のパフォーマンス向上は、少なくとも従来のクエリ処理の話であれば、非現実的であることは明らかです。SF10では、22のTPC-Hクエリは約15GBの（圧縮された）ベースデータを読み込みます。9950X3D上のUmbraは、すべてのクエリを合計約540ミリ秒で実行します。そのマシンでは、データによって触れられるメモリをメモリ帯域幅（54GB/s）で割っただけでも約280ミリ秒かかります。それ以下は非現実的です。より良い圧縮でそれを少し減らすことはできますが、桁違いには減らせません。

予想通り、GenDB-Vの最も劇的な改善は事前計算から来ています。エージェントは、ロード時に計算される各クエリのために補助データ構造を注意深く手作りしており、これによりほとんどの作業が回避されます。物理設計もクエリに大きくチューニングされています。例えば、supplier行をs_acctbal DESC順にリストする追加の構造があり、これによりQ2が非常に簡単になります。同様のクエリごとのデータ構造がほとんどのクエリのために構築されています。そして、パフォーマンスの数値にもそれが表れています。SF100では、いくつかのクエリはすでにほぼ定数時間で実行されています。Q2は0.7ミリ秒、Q17は約15ミリ秒、Q4は約17ミリ秒（1スレッドあたり）です。これはTPC-Dの症状であり、保存された集計はありません。

「プレーン配列」モードもあり、一見するとより公平です。これは過剰な準備を回避し、約3倍のパフォーマンス向上を報告しており、これは達成可能に見えます。しかし、よく見ると、ここではエージェントがさらに狂ったことをしていることがわかります。彼らはデータジェネレータに関する知識をハードコーディングしています。各顧客 k が行 k-1 にあることを「知って」います。そして、dbgenが i 番目の注文を 32·(i/8) + i%8 と番号付けすることを知っているので、キー k は行 8·(k/32) + k%32 − 1 にあるはずです。これにより、クエリ Q18 の結合が非常に安価になります。

これらすべてが、完全に検証されたデータベースエンジンの主張とどのように一致するのでしょうか？まあ、コードは、ハードコーディングされたデータジェネレータに関する知識が実際には有効かどうかをチェックします。例えば、推測された結合パートナー行が正しいかどうかをチェックします。もし間違っていれば、非常に遅い汎用ネストループ実装にフォールバックしますが、公式TPC-Hデータジェネレータではそれが決して起こらないため、報告された実験ではそのコードパスは無関係です。

そして、これは私の元のブログ記事の主張に戻ります。AIエージェントに特定のデータベースベンチマークを最適化させることは、ベンチマークを無用なものにします。彼らはこの特定のベンチマークを高速化するための狂ったトリックを見つけるために最善を尽くしますが、それらのどれも実際のシステムでは機能しないでしょう。高いチューニングと合成時間とは別に、単一のタプルを削除する（または途中に挿入する）だけで、アプローチ全体が崖から落ちる可能性が非常に高いです。なぜなら、それは遅いフォールバックパスを強制するからです。これは本番システムで望ましいものではありません。