4Bモデルを訓練し、Postgresより81%高速なクエリプランを生成させる
Training a 4B model to produce 81% faster query plans than Postgres
クエリ最適化はNP-hardであり、Postgresのコスト推定は一様分布仮定に依存するため、結合順序を誤ると処理量が数倍に膨らむ。著者は4BのオープンウェイトモデルをSFTとエージェント型RLで事後訓練し、113の結合重視クエリで44.7%のレイテンシ削減を達成。pg_hint_planでPostgresを誘導し、ノイズの多い環境向けにGRPO変種を設計、vLLMとトレーナーを2x H100ノードに、4つのPostgresコンテナを机上に分散させた実験を解説する。
一様分布を仮定するのはヒューリスティックとしては問題ないが、それが失敗するときは大きく失敗する。
HNでの議論
136- refibrillator
「Postgresより81%高速なクエリプラン」…ただし、完全にメモリに収まる8GBのデータセットで、shared_buffersはそのごく一部に制限され、測定前にクエリをウォームアップし、読み取り専用のSELECTに限った話だ。
私は過剰適合には慎重になるべきだと思う。そうしたクエリプランが、スケール時やもう少し現実的なOLTPワークロードで、本当にPostgresのヒューリスティクスよりも最適になるかどうかは判断しにくい。
いずれにせよ、プロファイル誘導最適化とはそういうものだ。データベースのワークロードが時間とともに、またスケールとともに変化しうることは、多くの人が理解している。
著者が自ら手を動かして実験をまとめたことに敬意を表する。
- hamilyon2
最適なプランの構築は数学とアルゴリズムが重視され、ワークロードによっても異なる。ジャストインタイムインデックスの作成などの選択肢もあるため、解空間は記事が示すよりもさらに速く成長する。時には、クエリプランナー自体が全体の実行時間のうち遅い部分であることもある。
ここでLLMを使うのは、どちらかといえば鈍器のようなものだ。私はむしろAlphaGoスタイルのニューラルネットヒューリスティクスを待っている。
- 2001zhaozhao
エンジニア：「助けて、本番DBが以前は問題なく動いていたこのクエリで固まってる！」
インフラ：「うーん、確認してみよう…あらまあ、どうやら君のLLMクエリプランナーは普段はうまく動いて高速なクエリを生成するようだけど、今回は変数名を変えてクエリの再構築をトリガーしたときに、たまたまハルシネーションを起こしてインデックスを見落としたみたいだね。高速なクエリが得られるまでLLMを何回か再実行してくれないかな？」
- devsda
> フロンティアの知能は極めて強力であり、Astraの軌跡から行った蒸留は、大規模モデルがなくなることはない十分な証拠だ
これを認めることは、クローズドモデルとオープンモデルの間で飛び交う蒸留の非難によって面倒を招かないだろうか。
- sgarland
省略されていなければ、どのテーブルにもPK以外のインデックスはなく、追加の統計もなかった。ここには相関する列がある。例えば、ある国は映画産業が成長するにつれて特定の年代により多くの映画を制作したかもしれないし、ある国は映画よりもテレビシリーズを多く制作するかもしれない、などだ。
誰かがクエリにヒントを使うのを見るほぼ毎回、それは統計が不正確だからだ。ヒントを追加するのは問題を覆い隠すだけで、後でデータの形が変わると裏目に出ることがある。
- Someone
> Lambdaから2x H100 SXMノードを約95時間レンタルするのに約800ドル、Astra軌跡のデモンストレーションを生成するためにOpenAI API料金で約400ドルを支払った。
> 小さな4Bモデルが、ラップされていたハーネスを理解できない状態から、joinの多いSQLクエリのワークロード全体で1.81倍の幾何平均スピードアップと合計レイテンシ44.7%削減を達成した
記事の中に見つけられなかったが（読み飛ばしすぎたかもしれない）、ベンチマークの数値にその約95時間は含まれていないのではないかと疑っている。
すべてのデータベースベンダーは、クエリプランの導出に大量の時間を費やす余裕があれば、クエリオプティマイザーがもっとうまくやれることを知っていると思う。
⇒ これは一部のワークロードには役立つかもしれないが、それでも、4Bモデルが良いクエリプランを選び続けることを保証するために、時折何時間も費やして更新する余裕があるだろうか？
- rixed
良いクエリプランを見つけるためにニューラルネットワークを訓練するのは確かに良いアイデアだが…LLM？
- jerpint
すぐにすべてのコードライブラリが、その特定のライブラリ用のCLIと非常に小さなファインチューンを一緒に同梱するようになるだろうという理論を持っている。