AIエージェントがTPC-Hを無意味にする、Umbra作者がGenDB-Vの「22倍高速化」を痛烈に批判
Next-Level Benchmarking Overfitting – Thomas Neumann
Umbraの作者Thomas Neumannが、AIエージェントでデータベースエンジンを自動生成するGenDB-Vの主張を検証した。Umbra比22〜61倍という高速化の大半は、クエリごとに負荷時に作り込んだ補助構造や、dbgenの行番号規則をコードに埋め込んだことによるもの。TPC-Dを壊した過学習の再来であり、ベンチマークを最適化させる限りその結果は実システムでは通用しないと指摘する。
AIエージェントに特定のデータベースベンチマーク向けの最適化を任せれば、そのベンチマークは無意味になる。彼らはこのベンチマークだけを高速化する異常なトリックを全力で探し出すが、そのどれも実システムでは機能しない。
HNでの議論
13- lmeyerov
私たちは、エージェント支援を使って、データフレーム上のオープンソースのベクトル化CPU/GPU cypher向けにGFQLを構築してきました（グラフ版duckdbのようなもので、DBは不要）。そして私たちの考えでは、これはさらにアグレッシブな何かへの足がかりです。
今日、私たちは以前なら維持するには高コストすぎたであろう、いくつかのパターン向けのホットパス特化の最適化を受け入れています。LLMがそのコストを許容範囲に保ってくれ、重要なユーザー（例えば私たちのアナリスト製品Graphistryのユーザー）のためにそれができることは超能力です。グラフコミュニティのベンチマークでの私たちのスコアは大手を打ち負かしています。しかも重要なのは、私たちが気にかけるあらゆるものにおいてです。
私たちが本当に目指したいのは、ランタイム／ロードタイムの特化です。顧客は間違いなく、自分のトップクエリを自動チューニングしてほしいと望むでしょう。DB研究はすでにここへ大きく傾いており、10年前のコンパイラ研究のトレースに似ています。今可能になっていることについて、私はかなり強気です。
- augment_me
GPUカーネル開発コミュニティでも同様の問題がありました。
それは、ベンチマークが提供する価値はあなたのユースケースに依存する、という理解によって解決されました。記事の著者は、DB検索とはこうあるべきだという自身の考え（信頼性が高く、汎用的）からベンチマークを怒鳴りつけているように聞こえ、ベンチマークが測定しているものからではないようです。
ほんのいくつかの形状に対して最速のカーネルが欲しいだけなら、脆くても速いコードを書かせておけばいい。
広範で汎用的なソリューションに興味があるなら、50の異なるエントリをベンチマークし、考えられるあらゆるエントリに対してアセンブリ分岐を許さないようにコードサイズを制限する。
ビット単位の等価性やその他のエンドタスクの制限をそこに課す。
公開データセットと非公開データセットを用意する。
これはむしろ、なぜこれらのものが欲しいのか、何を欲しいのかをもっと考えるべきだという証明であり、古いやり方で物事を行うのではなく、それを反映したベンチマークを設計すべきだと思います。
- qsort
著者が指摘しているのは、これが既存のトレンドの継続と増幅であるという点で正しい。
私はデータ領域で善戦しており、「Just Using Postgres」の福音を広めていますが、極めて疑わしいベンチマークをますます見かけます。クエリパフォーマンスは、通常のプログラミングでデータ構造を選ぶのと同じです。それはほぼ完全に、実行時に予想されるアクセスパターンに依存します。ハッシュテーブルが必要なのに、世界最速のリンクリストを探すのは全く無意味です。現代のデータエンジニアリングの状況と比較してください。ベンチマークで測定されたソリューションは、本当にあなたの問題の解決策なのでしょうか。ましてや、Just Using Postgresに対する大幅な改善なのでしょうか？測定しましたか、それともマーケティングや雰囲気に頼っていますか？
繰り返しますが、このようなソリューションには居場所があると確信していますが、少なくとも今のところ、それは従来のエンジンと同じ場所ではありません。