AI 查詢最佳化 QORL 實驗解讀：113 道查詢加總延遲少 44.7%（2026）

2026 年 9 月 16 日，Rohan Bansal 在個人網站發表〈Training a 4B model to produce 81% faster query plans than Postgres〉。這場 AI 查詢最佳化實驗讓一個 4B 模型替 PostgreSQL 提出查詢提示；作者報告，在 113 道 join-heavy 查詢上，最後的系統把加總執行延遲降低 44.7%。但先別被「81%」帶走：最亮眼的成績來自三次搜尋、執行回饋、規則選擇與預設方案回退的組合，不是模型一次就答對，更不是延遲下降 81%。

這篇文章最值得看的，不是「小模型打敗資料庫」的戲劇性，而是一套如何把嘈雜、昂貴、容易鑽漏洞的真實系統，改造成可訓練環境的工程方法。以下先拆解數字，再看模型究竟學了什麼，最後回答：這能不能搬進正式環境？

先算清楚：1.805 倍不等於延遲少 80.5%

作者公開的最終實驗報告把三種結果分開。模型在每次搜尋結尾自行選擇的 339 個結果，幾何平均速度是 1.4048 倍；改用執行回饋在單次搜尋內選擇，升到 1.4355 倍；每題搜尋三次、再從最多 15 個候選方案中按回饋選出最佳者，才得到 1.8054 倍。

選擇方式	幾何平均速度	加總延遲降幅	它代表什麼
模型自行選擇	1.4048×	19.13%	339 次搜尋的模型最終答案
單次搜尋內按回饋選擇	1.4355×	22.77%	每次搜尋用實測回饋挑候選方案
三次搜尋後按回饋選擇	1.8054×	44.67%	每題最多看 15 個候選方案，必要時保留預設方案

但實驗沒有讓最終 SFT checkpoint 跑相同的三次搜尋、最多 15 個候選方案對照，因此 44.7% 不能解讀成「RL 單獨帶來的增益」；它同時混合了 policy 更新與額外搜尋計算。

原文標題的「81% faster」是把約 1.81× 的速度比換成「速度增加約 81%」；它不是「延遲下降 81%」。1.8054 倍是每題速度比率的幾何平均；44.67% 則把每題中位數相加：PostgreSQL 對應的預設方案共 57.398 秒，選出的方案共 31.756 秒，所以延遲下降約為 1 − 31.756 ÷ 57.398 = 44.7%。AlphaLab 依公開的 per-query CSV 重算後得到相同加總；這只能核對公開表格的算術，不能替代對原始 SQL 執行的獨立重現。

AI 查詢最佳化到底在學什麼？

PostgreSQL 的 planner 不是把 SQL 依序執行。它會建立掃描方式、join 順序與 join 演算法的候選路徑，再用統計資料估算成本，挑出預期最便宜的可執行方案。問題是估算終究不是執行：資料相關性與選擇率若估錯，早期的 cardinality 誤差就可能一路放大；快取狀態估錯則會扭曲 I/O 成本與實際執行時間，但不是 cardinality 誤差本身。PostgreSQL 官方也說明，join 數量變大時，搜尋空間會快速爆炸；現行 extended statistics 對跨表 join 的選擇率估算仍有限制。

QORL 沒有取代這個 planner。4B 模型先檢查 relation、column statistics 與既有 plan，再輸出結構化的 PlanAction；harness 把它編譯成 pg_hint_plan 提示，仍由 PostgreSQL 產生並執行真正的 plan。候選方案跑得快或慢，再成為下一步搜尋與訓練的回饋。

We want our model to learn IMDb well.

中文：我們就是希望模型把 IMDb 學好。

Rohan Bansal

這句話界定了整個實驗。作者追求的不是一個對所有資料庫都通用的新 optimizer，而是讓模型記住某個穩定 workload 的結構與回饋，替那些會反覆執行、而且本身很昂貴的分析查詢，花較多前置成本找出更好的局部方案。

先用 SFT 學會工具，再用 RL 學會不要自欺

這裡的「4B」具體指 empero-ai/Qwen3.8-4B-Distill 的固定 revision；Hugging Face 記錄 4,659,865,088 個參數，base_model 為 Qwen/Qwen3.5-4B。因此它是 4B 級的第三方 distill，不是阿里另行發布的官方「Qwen3.8-4B」模型。

原始 4B 模型連 harness 的語言都不熟。Bansal 先用較大模型產生的 agent trajectory 做 off-policy supervised fine-tuning（SFT），讓小模型學會何時檢查 plan、如何組提示、怎麼提交候選方案。接著才進入兩段各 600 次 optimizer update 的 agentic reinforcement learning：模型自己搜尋，PostgreSQL 執行候選方案，結果回到權重更新。

真正困難的是 reward。執行時間看似「可驗證」，卻會受快取、排程與量測噪音影響。早期 reward 甚至讓模型學會一再保留預設方案，因為在同一組都很差的 rollout 裡，「沒犯大錯」也可能得到相對正分。作者後來把 advantage 錨定到 PostgreSQL 預設方案，加入 5% 中性帶、速度比裁切、無效 plan 懲罰與 default fallback；換句話說，訓練目標從「比同組其他壞答案好」改成「真的比既有系統好」。

漂亮數字背後，其實是「搜尋系統」的成績

最終的 44.7% 有四層共同貢獻：模型生成候選方案、資料庫實際試跑、feedback selector 挑選，以及不夠好就回到 PostgreSQL 預設方案。113 題中，最後有 68 題出現 material improvement、3 題落在中性帶、42 題保留預設方案；在這個 pooled sample 裡觀察到 0 個被選中的 regression。

這裡的 material 只表示速度比落在作者自訂的 abs(log(speedup)) ≤ 0.05 中性帶之外，約為 0.9512×–1.0513×；它不是統計顯著性檢定。公開報告沒有提供逐題 p 值或信賴區間。

「零退步」因此是選擇政策在這批樣本上的結果，不是模型本身的保證。模型自行選擇的 339 次搜尋裡，仍有 7 個 material regression、17 個低於 1× 的量測結果。這也解釋為什麼我認為最關鍵的發明不是 4B 權重，而是拒絕壞答案的 harness。

這條路也不是從零開始。Bao 已示範用學習系統與回饋去引導既有 optimizer；QORL 的新鮮處，在於把小型語言模型、結構化工具呼叫、SFT、agentic RL 與細緻的 PostgreSQL 量測 harness 組成一條可讀、可檢查的工程鏈，而不是發明了 learned query optimization 本身。

最強反例不是「結果造假」，而是不能外推

1. 測到的是同一個 IMDb 世界

訓練使用 CEB，評估使用 JOB；作者檢查過兩者沒有重疊的 join-graph topology，這比隨機切 query 嚴格。但兩者仍使用同一份 IMDb schema 與資料，而 JOB 在開發期間被反覆查看，並不是從未碰過的新盲測。JOB 本身也只有 113 道、33 個 template 的分析型 inner-join 查詢；JOB 創作者在 2025 年回顧中明確提醒，這套 benchmark 不代表所有真實資料庫 workload。

2. 測到的是受控、偏暖的執行環境

作者稱載入後的 IMDb fixture 約 8.5 GB；實驗把 shared_buffers 調到 2 GB、work_mem 設為 4 MB，候選方案在量測前 warm up，最後用三組交錯的 candidate/default 執行取中位數。這對降低噪音很合理，卻沒有建立冷快取、多人同庫競爭、寫入與鎖、資料漂移、更大資料量或不同硬體下的結果。repo 也固定了一組研究設定，包括關閉 GEQO、JIT 與 autovacuum；比較對象應稱為「該設定下 PostgreSQL 選出的預設方案」，不是抽象而通用的 PostgreSQL。

3. 報告的 latency 沒有算搜尋成本

44.7% 只比較選定 SQL plan 與對應 default plan 的執行中位數，不含模型推論、schema/plan 檢查、候選搜尋與挑選。三次搜尋的評估約跑了 104 分鐘，送出 2,543 次 model request、執行 4,183 次 SQL，搜尋預算約是單次搜尋的三倍。這不否定「把好 plan 快取起來、未來反覆使用」的價值，但它把適用場景收得很窄：查詢必須夠貴、夠常重複，而且省下的時間要能攤平找 plan 的成本。

4. 一次量測回饋仍會挑中幸運樣本

搜尋階段的 candidate feedback 只有一次 warmup 與一次計時；從最多 15 個候選方案挑最高值，天然有 winner’s curse。最後的三組交錯量測能再檢查勝者，卻沒有為 pooled winner 另跑一個全新的確認實驗。作者的公開報告也把 best-of-three 稱為 offline replay，而不是 production end-to-end benchmark。

截至 2026 年 9 月 18 日，公開 repo 可檢查 harness、固定設定、benchmark SQL、任務清單、結果摘要與 per-query aggregate CSV；但本文在公開 tree 裡沒有找到訓練後 adapter、339 筆 raw rollout、raw paired timing 或 prepared database，repo 的 .gitignore 也排除了 outputs/ 與準備後的資料。也因此，目前能獨立稽核的是設計與彙總算術，還不是從資料載入到模型權重與最終計時的完整重現。

我的判斷：突破在 harness，不在「4B 打敗 PostgreSQL」

我同意的部分：這個實驗很有價值。成熟系統不代表每個局部決策都已最優；只要能把真實結果轉成可重複 reward，小模型就可能學會某個組織、某份 schema、某類固定 workload 的實用政策。模型不用理解整個資料庫世界，只要提出值得量測的候選方案。

我存疑的部分：「模型贏了 PostgreSQL」省略了最重要的主詞。真正勝出的是「模型＋多次搜尋＋實際執行回饋＋selector＋default fallback」，而且只在同一個資料庫與受控 benchmark 上成立。pg_hint_plan 官方也列出提示可能被忽略、衝突或無法執行的功能限制；schema、版本或資料分布改變後，舊提示必須重新驗證。

真正可帶走的結論：reward 可量測，不等於 reward 很乾淨；模型會探索，不等於模型應該握有最後決策權。QORL 最強的部分，是把校準、plan 驗證、timeout、量測配對、5% 中性帶、fingerprint、門檻與回退機制接在模型外面。這些護欄既讓 RL 有訊號，也讓錯誤候選方案不必進入正式流量。

AI 查詢最佳化要搬進正式環境，先過這五道門

1. 只挑可攤提的 query：先找每天反覆執行、單次成本高、輸入形態穩定的分析查詢，不要從一次性 SQL 或低延遲 OLTP 開始。
2. 把目標改成 end-to-end：除了 query latency，納入推論與搜尋時間、CPU、I/O、記憶體、parallel worker、吞吐量與 p95/p99。
3. 用未來資料做盲測：依時間切出模型與開發者都沒看過的 workload，並測試 statistics 更新、資料成長、schema migration 與 PostgreSQL 升版。
4. 先 shadow、後 canary：候選提示先在隔離副本重放；上線後限制資源與 timeout，保留 plan fingerprint、有效期與一鍵回到 default 的路徑。
5. 用淨節省決定是否保留：只有當反覆執行省下的總成本，穩定超過搜尋、驗證與維運成本，這個 learned hint 才是資產，而不是昂貴的 benchmark 獎盃。

所以，這場實驗真正令人興奮的，不是 4B 模型突然比 PostgreSQL 更聰明，而是它在同一份 IMDb、受控且非盲測的設定裡，示範了一種值得進一步驗證的分工：成熟軟體守住正確性與 fallback，小模型負責在窄領域提出假設，真實系統負責打分。下一步的證據，不該再追求更大的 headline speedup，而應是跨資料漂移、併發與端到端成本仍能成立的盲測。