PostgreSQLクエリ最適化に4Bモデルを導入：GRPO学習と推論抽出でコストを抑える設計指針

はじめに：クエリ最適化におけるLLM活用のパラダイムシフト

PostgreSQLのクエリオプティマイザが直面する結合順序決定問題はNP-hardであり、テーブル数が増加するにつれ探索空間が指数関数的に拡大する傾向にある（QoRLの実験レポート）。PostgreSQLは小規模な結合に対して動的計画法を用い、大規模な結合ではヒューリスティックな手法も用いて探索空間を剪定しているが、いずれもグローバル最適解を保証するものではない。この構造的な限界に対して、4Bパラメータの軽量モデルをSFTおよび強化学習でファインチューニングし、PostgreSQLのデフォルトプランと比較して高速なクエリプランを生成させる事例が報告されている（QoRLの実験レポート）。

この結果が示唆するのは、クエリ最適化という決定論的なインフラ課題において、大規模モデルへの依存を回避しつつ実用的な性能向上を実現できる可能性である。4Bという規模は、オンプレミス環境で単一GPUノードに収まり、推論コストが管理可能な範囲に留まる場合が多い。つまり、性能とコストのバランスが「実装可能」な領域にあると考えられる。

本記事は、RAGやエージェントの活用事例を紹介する既存記事とは異なる立場から書く。焦点を当てるのは、確率的モデルを決定論的なインフラ層のタスクに適用する際の学習プロセスの設計であり、特にノイズの多い実環境で強化学習を安定させるための技術的知見である。技術責任者が「自環境で再現できるか」を判断するために必要な設計判断の根拠と、よくある落とし穴を具体的に見ていく。

背景：なぜクエリ最適化にLLMなのか？探索空間の爆発と限界

探索空間の規模と既存手法の限界

結合クエリの最適化が困難な根本原因は、テーブル数が増えるごとに考慮すべき選択肢が組合せ的に増大することにある。3テーブル結合の場合、結合順序・向き・アルゴリズム・スキャン方法の組み合わせで多数の実行計画が存在しうる（QoRLの実験レポート）。テーブルが増加すれば探索空間は膨大になる。PostgreSQLは動的計画法でこの空間を剪定するが、結合数が増加すると計算コストの観点からヒューリスティックな手法への依存度が高まる。ヒューリスティックな近似解探索であり、解の品質が初期集団やパラメータに依存する。グローバル最適解に到達する保証はない。

LLMアプローチの位置づけと課題

LLMが従来のルールベースや統計モデルと異なる点は、クエリの文脈（スキーマ、統計情報、ワークロード特性）を自然言語や構造化入力で受け取り、文脈に応じた柔軟な計画立案を「推論」として実行できる点にある。しかし、この柔軟性は裏を返すと学習データと評価指標の設計が極めて重要になることを意味する。

実際、報告された実験では結合-heavyなクエリに対して、4Bモデルの初期状態ではプラン生成に失敗するケースが見られた（QoRLの実験レポート）。これはモデルの事前知識がPostgreSQLのオプティマイザ内部ロジックを十分に内包していないことを示しており、学習プロセスの設計が性能を左右することを如実に示す。

表に示すように、LLMアプローチの利点はテーブル数増加に伴う性能劣化を回避できる可能性にある一方、GPUリソースと学習データの構築という新たなコストを発生させる。このトレードオフをどう設計するか、が本記事の核心である。

学習手法：GRPOとノイズ耐性のあるRL rollout設計

GRPOの設計思想とPostgreSQL環境への適用

DeepSeekMathで導入されたGRPO（Group Relative Policy Optimization）は、PPOのバリアントとして、クリティックネットワークを不要とすることでメモリ使用量を最適化しつつ、数学的推論能力の強化を目指す手法である（GRPO論文）。DeepSeekMath 7BはCommon Crawl由来のデータで事前トレーニングされ、MATHベンチマークで一定のスコアを記録したと報告されている（GRPO論文）。

PostgreSQLのクエリ最適化にGRPOを適用する際の核心的な課題は、報酬信号のノイズである。クエリの実行時間は、OSのページキャッシュ状態、CPUのスケジューリング、ディスクI/Oの競合など、モデルの出力品質とは無関係な要因によって変動する。実験では、Linuxのページキャッシュ競合ノイズを最小限に抑えるためのPostgreSQL測定基盤が別途構築された（QoRLの実験レポート）。しかし、環境の固定化だけではノイズを完全に排除できない。そこで設計されたのが、カスタマイズされたGRPOバリアントである（QoRLの実験レポート）。

グループ内相対比較によるノイズ相殺の仕組み

GRPOの核心は、同一プロンプトに対して複数（グループ）のサンプリングを行い、グループ内の相対的な優劣で報酬を正規化することにある。絶対的なレイテンシ値がノイズで変動しても、同じ環境条件下で生成された複数プランの「相対的な順位」は安定しやすく、ノイズが相殺される。この性質が、インフラ測定のような不安定な環境で有効である理由である。

4Bモデルはある条件でレイテンシ削減を達成したが（QoRLの実験レポート）、これは単なるSFT（教師あり微調整）だけでは達成困難な水準である。アジェンティックRLによる反復的な改善——モデルがプランを生成し、PostgreSQLで実行し、結果を報酬として受け取ってポリシーを更新するサイクル——が寄与していると考えられる。初期状態ではプラン生成に課題があったモデルが、この反復プロセスを経て実用的な性能に到達した点は、RLの設計が本質的であることを示す。

flowchart TD
    A["クエリセット"] --> B["4Bモデル（ポリシー）"]
    B --> C["プラン候補のグループ生成"]
    C --> D["PostgreSQL実行環境"]
    D --> E["レイテンシ測定（ノイズあり）"]
    E --> F["グループ内相対報酬の計算"]
    F --> G["ポリシー更新（GRPO）"]
    G --> B

インフラ設計：分散推論と測定環境の構築

QoRLの実験では、vLLMとトレーナーを複数のマシンに分散し、H100ノードとPostgreSQLコンテナでRLを実行した事例が報告されている（QoRLの実験レポート）。この構成は、リソース制約下で「推論」と「学習」を分離する設計判断の一例として参考になる。

なぜ2台のマシンに分けたのか。LLMの推論（vLLMによるバッチ推論）とRLトレーナーの勾配計算は、それぞれGPUメモリと計算リソースを大きく消費する。同一ノードに同居させると、メモリ帯域の競合によって推論レイテンシが変動し、報酬信号のノイズが増大する可能性がある。これを分離することで、推論側のレイテンシ測定値が安定し、GRPOのグループ内比較が意味をなすようになる。

PostgreSQLコンテナを複数用意した理由は、クエリ実行の並列化にある。モデルがプランを生成し、その実行結果を報酬として取得するサイクルを高速回すには、単一インスタンスの直列実行ではスループットが不足する。コンテナ単位でインスタンスを分離することで、クエリ間のページキャッシュ競合を抑制しつつ並列実行が可能になる。ただし、コンテナ数とGPUノード数の比率は、クエリセットのサイズとモデルの推論速度に応じて調整が必要であり、特定の構成が汎用的に最適とは限らない。

オンプレミス環境での実装において、ここで直面する課題は2つある。1つ目はGPUリソースのプール管理である。vLLMの推論とトレーナーの計算が時間的に重なる時間帯に、GPU利用率が逼迫すると、どちらか一方の処理がスロットリングされる可能性がある。2つ目はDBインスタンスのライフサイクル管理である。RLの各エポックでPostgreSQLコンテナを再起動する必要がある場合（ページキャッシュのクリアなど）、そのタイミングとトレーナーの同期をどう制御するかが設計上の分岐点になる。

4Bモデルという軽量モデルを選定したことは、推論レイテンシとコストのバランスを取る上で合理的な判断である。H100クラスのリソースを投入しても、モデルが70B以上になるとバッチ推論のレイテンシがRLのタイムアウト制約に抵触する可能性がある。4Bモデルであれば、1回の推論が短時間で完了し、1エポックあたりのクエリ実行回数を増やせる。これは「モデルの能力」と「学習ループの回転数」のトレードオフにおいて、後者を選択した設計判断と言える。

推論の抽出：プロプライエタリなモデルからの知識蒸留

PostgreSQLのオプティマイザ内部ロジックは、ソースコードが公開されているものの、統計情報の解釈やコスト推定式のパラメータ設定など、実効的な最適化戦略の全貌を外部から復元することは容易ではない。特に、プロプライエタリなLLMが「なぜその結合順序を選んだか」という推論過程を出力しない場合、その知識を直接転移させる手段が限られる。

ここで有効なのが、推論トレースの抽出（トレースインバージョン）である。プロプライエタリなLLMは最終的なプラン出力は行っても、中間の推論過程（Chain of Thought）を隠蔽していることがある。この場合、トレースインバージョンモデルを用いて、出力されたプランから逆算的に合成された推論トレースを生成し、その合成トレースで学生モデル（4Bモデル）をファインチューニングするという手法が適用できる可能性がある（How to Steal Reasoning Without Reasoning Traces）。

この手法の本質は、黒箱のモデルが暗黙に持っている「状況判断のロジック」を、観測可能な出力から再構成することにある。PostgreSQLの文脈では、例えば「このクエリではテーブルAをインナースキャンし、テーブルBをハッシュジョインで結合する」という最終判断から、「テーブルAの選択率が高く、インデックスが有効であるためインナースキャンがコスト的に有利」という推論を逆算して生成する、という流れになる。

ただし、この手法の性能上限は推論トレースの質で決まる。インバージョンモデルの精度が低ければ、誤った推論が学生モデルに学習され、逆に性能を劣化させる可能性がある。また、合成データの多様性も重要で、特定の結合パターンに偏ったトレースセットでは、分布外クエリへの汎化が期待できない。実装上は、インバージョンモデルの出力を人間がサンプリングして検証するプロセスを挟むことで、明らかな論理矛盾を排除するのが現実的な対策になる。

DeepSeekMath 7BがCommon Crawl由来のデータで事前トレーニングされ、MATHベンチマークで一定のスコアを記録した事例（GRPO論文）は、大規模な事前学習データが推論能力の土台になることを示している。一方、クエリ最適化のようなドメイン特化タスクでは、事前学習の規模よりも、ドメイン固有の推論トレースの質と量の方が性能に直結する。この点で、推論抽出による知識蒸留は、大規模事前学習に投資できない環境において現実的な選択肢となる。

sequenceDiagram
    participant P as プロプライエタリLLM
    participant T as トレースインバージョンモデル
    participant S as 学生モデル（4B）
    participant V as 検証プロセス
    P->>T: プラン出力（推論トレースなし）
    T->>T: 推論トレースの逆算生成
    T->>V: 合成トレースの提出
    V->>V: 論理整合性のサンプリング検証
    V->>S: 検証済み合成トレースセット
    S->>S: ファインチューニング実行

実装ステップ：4Bモデルを用いたクエリ最適化パイプライン

ここまでの設計指針を踏まえ、実装を4つのステップに分解する。各ステップには、失敗しやすいポイントと対策を併記する。

Step 1: クエリセットの収集と実行計画の記録

対象となる結合-heavyなクエリを収集し、PostgreSQLでEXPLAIN ANALYZEを実行して既存のデフォルトプランと実際のレイテンシを記録する。QoRLの実験では113件のクエリが使用された（QoRLの実験レポート）。ここで重要なのは、クエリセットの多様性を担保することである。特定の結合パターン（例：3テーブルのハッシュジョイン）に偏ったセットでは、モデルがそのパターンに過学習し、分布外クエリで性能が急落する可能性がある。テーブル数の分布、結合アルゴリズムの種類、データ量の変動幅を意識してサンプリングする。

Step 2: 比較基盤の構築と測定環境の固定化

LLM生成プランと既存オプティマイザプランの比較には、公平な測定環境が前提になる。QoRLの実験では、Linuxのページキャッシュ競合ノイズを最小限に抑えるためのPostgreSQL測定基盤が構築された（QoRLの実験レポート）。具体的には、各クエリ実行前にページキャッシュをクリアし、コンテナを再起動する、あるいはposix_fadviseでアドバイザリなキャッシュ制御を行うなどの手法が考えられる。この固定化を行わずに測定すると、キャッシュヒット/ミスによるレイテンシ変動が報酬信号を汚染し、RLの収束が不安定になる可能性がある。

Step 3: GRPOによるRLトレーニングとカリキュラム設計

初期状態では99件のクエリでプラン生成すらできなかったモデルに対して、全クエリを同時に学習させるのは非効率である。ここでカリキュラムラーニングを適用する。まずはモデルがプランを生成できた14件（113件から99件を引いた残り）で学習を安定させ、徐々に生成できなかったクエリを学習セットに追加していく。この順序により、モデルが基本的なプラン構造を身につけた上で、より複雑な結合パターンに挑戦できる可能性がある。GRPOのグループサイズや学習率の調整は、このカリキュラムの段階に応じて変える必要がある。

Step 4: 推論トレースの抽出とフィードバックループ

モデルが選択したプランの根拠を可視化し、誤った推論のパターンを特定するプロセスを回す。例えば、モデルが「テーブルAの行数が少ないからインナースキャンが有利」と推論している場合、実際の統計情報（pg_stat_user_tablesやpg_classのreltuples）と照合して、推論の前提が正しいか検証する。前提が誤っている場合、その推論トレースを修正して再学習データに反映させる。このフィードバックループを回すことで、モデルの推論品質が段階的に向上し、最終的なレイテンシ削減（QoRLの実験レポート）が実現したと報告されている。

トレードオフ：性能向上と導入コストの比較検討

4Bモデルによる高速化という数字は魅力的だが、技術責任者として判断材料にするには、その背後にあるコスト構造を分解する必要がある。この実験では、vLLMとトレーナーを2台のマシンに分散し、2×H100ノードと4つのPostgreSQLコンテナで強化学習を実行した。H100単体の購入コストや電力消費、学習に要する日数、そして学習後の推論サービングに常時割り当てるGPUリソースを合計すると、単純なインデックス追加やパラメータ調整と比較して桁違いの初期投資になる場合がある。

手法別のROI比較

クエリ最適化の手法は、導入コスト・維持コスト・性能向上効果・適用範囲の4軸で比較するのが有効だ。インデックス追加は個別クエリには劇的な効果があるが、書き換え対象が限定的で、データ量の変化に伴い効果が減衰する可能性がある。オプティマイザのパラメータ調整（random_page_cost や work_mem 等）はコストが低いものの、効果は数%〜十数%程度に留まり、環境固有のチューニングが毎回必要になる。一方、LLMによるプラン生成は、結合-heavyなクエリ群に対して一括で適用でき、新しいスキーマやデータ分布にも適応する可能性がある。ただし、モデルの再学習コストとGPUインフラの維持費を継続的に支払う必要がある。

ここで重要な判断基準は、「どの程度のクエリ数が結合-heavyで、現在のレイテンシが許容範囲をどれだけ超過しているか」である。結合-heavyなクエリが数十件程度で、既存のインデックスやパラメータ調整で十分改善できる場合、LLM導入のROIは成立しにくい可能性がある。逆に、数百件以上の結合-heavyなクエリが存在し、従来の手法で頭打ちになっている場合、LLMアプローチの相対的優位性が生まれる可能性がある。この閾値は組織ごとに異なるため、まず対象クエリのインベントリをとり、既存手法で改善可能なものを除外した残りに対してLLMの効果を評価する、という二段構えの判断プロセスを推奨する。

もう一つのリスクは、モデルのバージョン管理とDBスキーマ変更への追従性である。PostgreSQLのテーブルにカラムが追加されたり、パーティション構成が変わったりすると、オプティマイザが参照する統計情報が変化し、モデルが学習時に前提とした結合コストの分布が崩れる可能性がある。この場合、モデルの再学習が必要になる頻度が運用コストに直結する。スキーマ変更が月1回程度なら対応可能だが、日次で変化する動的スキーマ環境では、再学習のサイクルが運用を圧迫する可能性がある。このため、スキーマ変更の頻度と影響範囲を事前に評価し、必要に応じて再学習のトリガー条件（例：主要テーブルの reltuples 変化率が閾値超過）を定義しておくことが重要である。

落とし穴：ノイズと過学習への対処

測定ノイズがRL学習に与える影響

この実験で最も地味だが重要な課題は、Linuxのページキャッシュ競合による測定ノイズだった。PostgreSQLのクエリ実行時間は、OSレベルのページキャッシュの状態に大きく依存する。複数クエリを連続実行すると、先頭クエリがページキャッシュを汚染し、後続クエリのレイテンシが人工的に変化するという問題が生じる。実験では、この競合ノイズを最小限に抑えるためのPostgreSQL測定基盤を別途構築し、各クエリ実行前にキャッシュ状態をリセットする処理を挟んだ。

このノイズがRLの報酬信号に与える影響は深刻だ。通常のPPOでは、各サンプルの絶対的な報酬値がポリシー更新に直接使われるため、測定ノイズがそのまま学習のバイアスになる可能性がある。一方、カスタマイズされたGRPOバリアントは、グループ内の相対的な優劣で報酬を正規化するため、全サンプルに共通するシステマティックなノイズ（ページキャッシュの温まり具合など）が相殺される。これが、インフラ測定のような不安定な環境でGRPOが有効である理由の一つと考えられる。

実装上の注意点として、グループサイズを小さくしすぎると、相対比較の統計的有意性が低下し、ノイズの相殺効果が薄れる可能性がある。逆にグループサイズを大きくすると、1ステップあたりの計算コストが線形に増大する。この実験では、4つのPostgreSQLコンテナで並列にrolloutを実行する構成をとっており、これはグループサイズと推論スループットのバランスを考慮した設計判断と読み取れる。自環境で再現する場合、PostgreSQLインスタンスの数とGPUの推論スループットの比率を事前にベンチマークし、グループサイズを決定する必要がある。

コールドスタート問題と過学習

初期状態では113件の結合-heavyなクエリのうち99件でプラン生成すらできなかった、という事実は、4Bモデルの事前知識がPostgreSQLのプラン構造に対して不十分であることを示している。これはSFTの段階で十分な多様性の学習データを与えられなかった場合の典型的な症状であり、モデルが「正しいプランの形式」自体を習得できていない状態だ。この段階でRLに進むと、報酬信号がほぼゼロ（プランが生成されない＝実行不能）になり、学習が停滞する可能性がある。

過学習の観点では、113件という学習クエリ数は統計的に少ない。モデルが特定の結合パターンに過剰に適合し、分布外のクエリ（例えば、学習時に含まれていないスキーマ形状）に対して不安定なプランを生成するリスクがある。対策として、評価セットを学習セットと完全に分離し、スキーマ形状やデータ分布が異なるクエリを含むことを推奨する。また、推論時の確信度（確率のエントロピー）をモニタリングし、確信度が低いクエリは従来のオプティマイザにフォールバックする、というハイブリッド運用が現実的なリスク管理となる可能性がある。

運用と発展：オンプレミス環境でのスケーリング戦略

モデルサイズのスケーリングとインフラ制約

4Bモデルから8B、13Bへのスケールアップは、推論品質の向上を期待できる一方、学習コストと推論レイテンシがモデルサイズにほぼ比例して増大する可能性がある。2×H100ノードで4BモデルのRLを実行する構成が成立したとしても、13Bモデルにスケールすると、同一ノードでのバッチサイズが大幅に縮小し、学習時間が数倍に伸びる可能性がある。このため、モデルサイズを上げる前に、4Bモデルで達成できる性能の天井を正確に評価し、残りの性能ギャップがモデルサイズでは埋まらない（例えば、学習データ量や報酬設計の改善で解決できる）場合があることを確認すべきである。

ここで推論トレースの合成による知識蒸留が有効な手段になる。プロプライエタリなLLMからトレースインバージョンモデルを用いて合成された推論トレースで学生モデルをファインチューニングする手法は、より高性能な教師モデルが登場した場合でも、既存の4Bモデルインフラ資産を活かして性能を引き上げる経路を提供する可能性がある。教師モデルの推論コストはオフラインで一度だけ発生し、学生モデルの推論は既存のH100ノードで実行できるため、常時大規模モデルをサービングするコストを避けられる可能性がある。この蒸留パイプラインを運用に組み込むことで、モデルの世代交代をインフラの全面刷新なしに実現できる場合がある。

継続的な評価と再学習サイクル

PostgreSQLのバージョンアップや拡張機能（pg_stat_statements の更新、パーティションの再設計など）に伴い、オプティマイザの挙動が変化すると、モデルが学習時に獲得した結合コストの推論が前提を失う可能性がある。このため、モデルのバージョン管理とDBスキーマ変更への追従性を統合した運用プロセスが必要になる。具体的には、PostgreSQLのマイナーバージョンアップや主要テーブルの統計情報更新（ANALYZE）をトリガーに、評価セットでモデルの性能を自動検証し、性能低下が閾値を超えた場合に再学習を起動する、というCI/CD的なサイクルを設計する。

組織体制の観点では、このパイプラインの運用には、LLMの微調整（RLの報酬設計、GRPOのパラメータ調整）だけでなく、PostgreSQL内部のオプティマイザ動作原理（結合順序の探索戦略、コストモデルの構造）と、システムプログラミング（ページキャッシュの挙動、コンテナのI/Oスケジューリング）の両方の知識が同時に求められる。単一のエンジニアが全領域をカバーするのは困難なため、DBAとMLエンジニアの連携体制、あるいは両方に深い知識を持つ少数のエンジニアの配置が現実的な選択肢になる可能性がある。このスキルセットのギャップを埋めるコストも、導入判断の材料に含めるべきである。

まとめ：インフラ最適化におけるLLMの実用的な位置づけ

4Bモデルを用いたクエリ最適化の実験は、大規模モデルへの依存を前提とする現在のLLM活用トレンドに対して、明確な代替経路を示している。高速化という結果の裏には、カスタマイズされたGRPOバリアントによるノイズ耐性の設計、推論トレースの合成による知識蒸留、2×H100ノードと4つのPostgreSQLコンテナというリソース制約下での分散構成、という複数の設計判断が重なっている。これらの技術的知見は、単一のベンチマークスコアではなく、コストを抑えた継続的な改善プロセスを可能にする設計パターンとして、他のインフラ最適化課題（ストレージのI/Oスケジューリング、メモリプール管理など）にも転用可能である可能性がある。

技術責任者としての判断において重要なのは、性能向上の数字を孤立して見ずに、その背後にある学習コスト（GPUリソース・時間）、維持管理コスト（再学習サイクル・スキーマ追従）、ノイズ耐性設計（測定基盤の構築・GRPOのグループサイズ）を総合的に評価することである。数字が魅力的に見えても、運用負荷が組織のキャパシティを超える場合、従来の手法（インデックス設計、パラメータ調整、クエリリファクタリング）で十分である可能性がある。

最終的に、LLMはPostgreSQLのオプティマイザの代替ではなく、複雑な結合パターンに対して従来のヒューリスティックが到達しきれない領域を補完するツールとして位置づけるべきである。既存のインフラ（PostgreSQLインスタンス、インデックス、統計情報）との統合方法、フォールバック戦略、継続的な評価サイクルを設計した上で、段階的に適用範囲を広げていくことが、オンプレミス環境でのLLM活用の現実的な道筋となる可能性がある。

関連記事

• Apple SiliconのVMでLLM推論を高速化する：Metal GPUパsthroughの実践と注意点
• AI生成コードの信頼性：C4モデルからDSTまで、実装検証のためのリライアビリティスタック構築指南
• AIエージェントの暴走を防ぐ：while(true)ループの限界とEventStoreによる状態管理の実践

参考

本記事は海外の技術トレンド「Training a 4B model to produce 81% faster query plans than Postgres」（Hacker News）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。