Together Research、LLMで不適切なdatabase query planを補正 最大4.78倍高速化と主張
Original: Together Research says LLMs can repair bad database query plans View original →
2026年4月3日、Together AIのXアカウントは、database optimizerがsemantic correlationを見落としたときにLLMがquery planを補正できるとする研究を紹介した。投稿の中心にあるのはDBPlanBenchという仕組みで、databaseのphysical operator graphをLLMに渡し、実行戦略全体を一から作り直すのではなく、既存planに局所的な修正を加えるという考え方だ。
研究の主張
Togetherによれば、DBPlanBenchはApache DataFusionのplan上で動作し、localized editとevolutionary search loopを組み合わせて候補を絞り込む。X投稿では、TPC-HとTPC-DSで最大4.78倍の高速化、評価したqueryの60.8%で5%以上の改善、さらに一例ではbuild memoryが3.3 GBから411 MBへ減少したと述べている。関連するarXiv論文は、従来のcost estimatorがデータやスキーマのsemantic correlationを捉え損ねると、誤ったjoin orderやaccess path、連鎖的なplanning errorにつながると説明している。
なぜ重要か
この事例は、LLMがアプリケーション層ではなく、通常は手書きheuristicに依存するシステムインフラの内部でどう使えるかを示している。特に重要なのは、モデルに完全な新規planを生成させるのではなく、すでにoptimizerを通過したphysical planを見せて、制約付きの変更だけを提案させる設計だ。こうした方式は、検証しやすさと失敗範囲の制御という点で実務的な意味を持つ。もしbenchmark外の実運用でも通用するなら、database engineや最適化スタックの中で、より狭く高信頼なLLM活用の道が開ける。
出典はTogether AIのX投稿と、Making Databases Faster with LLM Evolutionary Sampling論文である。
Related Articles
Anthropicが出したのは単なる高性能モデルではなく、同じ基盤モデルを一般向けFableと限定向けMythosに分ける配布設計だ。価格は入力$10/出力$50、危険領域ではOpus 4.8への切り替えと30日保持も組み込まれる。
AlibabaのQwenチームがエージェント重視のフロンティアモデルQwen3.7-Maxを公開した。Artificial Analysis評価でGPT 5.4に迫る5位を記録し、オープンウェイトフロンティアモデルの新基準を示している。
MinishLabが公開したSembleは、AIエージェントがコードベースを探索する際のトークン消費量をgrep+read比で98%削減するオープンソースのコード検索ライブラリ。Claude Code・Cursor等のAIコーディング環境にMCPサーバーとして即座に統合でき、Transformerモデルの99%の検索品質をCPUのみで実現する。