從普通到自進化：構建會自己優化的 Text-to-SQL 智能系統
學習如何借助 Stanford 的 Agentic Context Engineering 構建能自我糾錯并自動優化性能的自適應數據庫查詢系統。
作者使用 AI 生成的圖片
當下大多數 Text-to-SQL 系統采用多智能體架構與單體式提示詞（monolithic prompts）。它們通過一串復雜的、分工明確的智能體來生成可運行的查詢——一個負責 schema 分析，另一個負責查詢規劃，第三個負責 SQL 生成。
這些單體系統確實能用。它們可以把“show me top customers”變成可執行的 SQL。但結果常常低效且讓人沮喪。
它們在該用 LEFT() 更快時卻使用 SUBSTRING()。它們偏愛嵌套子查詢而不是干凈的 JOIN。它們會因 PostgreSQL 的 GROUP BY 錯誤而崩潰——這些錯誤任何初級開發者都能一眼看出。
修復方法通常是花上幾個小時微調提示詞。祈禱修改不會牽一發而動全身，然后不斷循環。
我基于 Stanford 的 Agentic Context Engineering（ACE）框架構建了一種更好的方法。這個系統能自我修錯，并且隨著每一次查詢而變得更聰明。
為什么現有方案會失效
大多數團隊面臨一個昂貴的選擇：微調模型，或優化提示詞。
微調動輒要花費數千美元和數周算力。你需要標注數據、GPU 集群，還要重新部署模型。一次數據庫 schema 變更就可能讓一切失效。
提示詞工程看似更便宜，但會撞上兩堵墻：
- 簡短偏置（brevity bias）會讓系統為了簡短提示而忽略關鍵信息。
- 上下文塌縮（context collapse）會讓系統把知識改寫成通用但無用的摘要。
傳統多智能體系統因對每個智能體都使用單體式提示詞而加劇了這些問題。一旦出錯，你得在多個組件中調試成塊的長文本。
ACE 的思路不同。它把上下文表示為結構化的、條目化的要點（bullets），而不是單個的單體式提示詞。每條 bullet 只包含一條聚焦的知識——一個 schema 規則、一個 SQL 模式、或一個常見錯誤。這種設計支持“外科手術式”的更新，而非大范圍重寫。
系統用你能讀懂并可直接改動的英文來學習領域知識。需要 GDPR 合規？刪除特定規則即可。想加入新的業務邏輯？系統可以從示例中學習。
ACE 如何工作
ACE 由三個組件組成，像一個軟件開發團隊一樣協同運作：
圖源 Standford Research Paper
- Generator 依據當前知識和數據庫 schema 信息編寫 SQL 查詢。把它當作你的 SQL 開發者。
- Reflector 在查詢失敗或表現不佳時分析問題所在。它是你的代碼審查者，能從上百次失敗中歸納模式。
- Curator 將這些洞見轉化為對知識庫的小而精準的更新。它添加新規則、更新計數、移除過時建議。關鍵創新在于對結構化 bullet 條目的增量 delta 操作，而不是大幅重寫，避免丟失好不容易積累的知識。
每個 bullet 只包含一條知識點：
- sr-00003: customer.customer_id → rental.customer_id (1:N relationship)
- code-00001: Revenue template using explicit JOINs
- ts-00002: PostgreSQL requires ALL non-aggregated columns in GROUP BY
這種粒度讓“外科手術式”更新成為可能。當系統學到一個新模式，Curator 就新增一條 bullet。當某條規則有害，就只刪除它。playbook 會有機增長而不丟失已有知識。
系統把知識存放在三個位置：
- Episodic Memory 記錄每一次查詢嘗試，形成可搜索的成功與失敗歷史
- Semantic Memory 把數據庫 schema、連接模式（join patterns）和 SQL 示例存入 vector database
- Procedural Memory 以結構化 bullet 條目的形式維護不斷演進的 SQL playbook
這種 playbook 結構可防止上下文塌縮。ACE 不再使用會被改寫成泛化文本的巨型提示詞，而是維持數百條聚焦的 bullets。每個條目跟蹤自身的使用統計與有效性評分：
{
"id":"sr-00001",
"content":"customer.customer_id → rental.customer_id (1:N relationship)",
"usage_count":45,
"helpful":42,
"harmful":3
}這種細粒度跟蹤使系統能提升有用模式、修剪有害模式，而不丟掉其他一切。
真實的性能收益
結果證明 ACE 有效。Stanford 的評測顯示，與傳統提示詞優化相比，ACE 的適配時間降低了 86.9%。當像 GEPA 這樣的辦法需要超過 53,000 秒和 1,434 次嘗試才能改進時，ACE 僅用 951 秒和 238 次嘗試就完成了相同工作。
ACE 使用更小的開源模型就匹配了 IBM 的頂級生產智能體（由 GPT-4 驅動）。在不改動任何模型參數的情況下，離線性能提升 10.6%，在線性能提升 8.6%。
構建可用于生產的系統
我使用 PostgreSQL 的 DVD 租賃數據庫進行構建——一個包含 15 張表的 DVD 租賃商店數據集，包括 customer、rental、payment、film 和 inventory。它帶來多條連接路徑與業務邏輯的現實復雜度。
架構由五個核心組件協同工作：
- Memory Fabric 將知識分三層存儲。Episodic Memory 在 PostgreSQL 中記錄每次查詢嘗試，便于回放與調試。Semantic Memory 在 ChromaDB vector database 中保存 schema 信息、連接模式和 SQL 示例，便于快速檢索。Procedural Memory 以結構化 JSON 形式維護不斷演進的 playbook。
- Generator 基于當前的 playbook 知識與通過 Retrieval-Augmented Generation（RAG）檢索到的 schema 信息生成 SQL。它接收用戶查詢、相關 playbook bullets 與 schema 元數據，產出可執行的 PostgreSQL。
- Reflector 在查詢失敗或表現不佳時進行分析。它將生成的 SQL 與基準答案對比，識別聚合、連接等錯誤類型，并提煉可復用的洞見。
- Curator 基于 Reflector 的洞見對 playbook 進行“外科手術式”增量更新。它不是重寫一切，而是添加新規則、更新計數，或移除有害建議。
- Evaluator 使用有效性、正確性、效率與安全性的量表對 SQL 打分。得分超過 85% 的查詢會被自動提升，用于更新 playbook。
技術棧使用 LangChain 進行 LLM 編排，使用 ChromaDB 進行向量存儲，推理由 OpenAI 的 GPT-4 提供。全部運行在標準的 Python 和 PostgreSQL 上。
系統運行過程
當有人提出“Show me top customers by revenue”的請求時，系統會：
- 通過向量相似度檢索獲取相關 schema 知識
- 加載與查詢模式匹配的 playbook bullets
- 在 token 預算內組裝上下文
- 以逐步推理方式生成 SQL
- 在 DVD 租賃數據庫上執行
- 對成功或失敗進行分析，提煉洞見
- 僅在必要時以 delta 操作更新 playbook
playbook 從簡單規則起步，例如 customer.customer_id → rental.customer_id (1:N relationship)，逐步演化為更復雜的模式，例如“在計算客戶收入時，總是對所有非聚合列使用顯式 GROUP BY 以避免 PostgreSQL 錯誤”。
演示：性能優化學習
這部分最有意思。用戶提問：“Show me the rentals for each month in the year 2005?”
系統生成了可運行的 SQL，但使用了低效的模式：
SELECT
EXTRACT(MONTHFROM r.rental_date) ASmonth,
COUNT(r.rental_id) AS rental_count
FROM rental r
WHEREEXTRACT(YEARFROM r.rental_date) =2005
GROUPBYmonth
ORDERBYmonth;雖然可用，但性能較差。WHERE 和 GROUP BY 中的 EXTRACT() 阻礙索引使用，并引入不必要的計算。
我提供反饋：“當在時間戳列上按月或年聚合時，在分組中使用 date_trunc，并在 WHERE 中使用范圍過濾，以便可用索引。不要在 WHERE 里用 EXTRACT/DATE_PART/CAST 包裹日期列。”
系統回應：“已根據你的指令更新 playbook。”你會注意到最后更新時間從 12:12 刷新到 12:14，表示 SQL playbook 已更新。
當我再次提出相同問題時，系統生成了優化后的 SQL：
SELECT
date_trunc('month', r.rental_date) AS rental_month,
COUNT(*) AS rental_count
FROM rental r
WHERE r.rental_date >= '2005-01-01' AND r.rental_date < '2006-01-01'
GROUP BY rental_month
ORDER BY rental_month;Curator 向 playbook 新增了一條 bullet：ts-00008: Use date_trunc for time grouping and range filters for WHERE clauses to enable index usage.
這種學習會應用到后續所有基于日期的查詢中。系統通過真實使用不斷積累性能優化知識。
持續改進
真正的突破在于每晚的學習循環。系統用不同版本的 playbook 回放近期失敗案例，并使用 Thompson sampling 找到真正更有效的做法。成功的變更會自動晉升到生產環境。
這就打造了一個會隨使用而改進的 Text-to-SQL 系統。無需昂貴的再訓練，而是通過實時的、經策展的指令不斷累積。查詢越多，系統越聰明。
這對 Text-to-SQL 系統意味著什么
這種方法改變了組織處理數據庫查詢的方式。傳統的 Text-to-SQL 系統需要持續維護——改提示詞、更新示例、在 schema 變更時重訓模型。
基于 ACE 的系統會隨著時間推移變得更有價值，因為它在積累智慧。每一次失敗的查詢都能教給系統新東西。每一次性能優化都會被編碼為可復用的知識。
成本收益也非常可觀。與傳統提示詞優化相比，我的實現將適配時間縮短了 86.9%。當其他系統需要數百次昂貴的 LLM 調用才能改進時，ACE 通過對特定知識條目的“外科式”更新就能獲得更好的結果。
更重要的是，系統讓組織層面的學習成為可能。數據庫管理員可以把精力放在 schema 設計上，而不是提示詞工程。領域專家可以通過自然的反饋貢獻業務規則，而無需撰寫技術性提示。知識庫成為捕捉組織智慧的“活資產”。
想想合規場景。當 GDPR 要求移除客戶數據引用時，你只需刪除特定的 playbook bullets，而不必重訓整個模型。新業務規則出現時，系統會從查詢模式和反饋中有機學習。
這類影響還超越 SQL 生成本身。我們正走向真正能適應環境的 AI 系統，而非需要昂貴再訓練周期的系統。這些系統會成為你的同事，理解你領域的細微差別、你團隊的偏好，以及你組織的約束。
這是一種根本性的轉變：從會隨時間退化的靜態 AI，轉向會隨使用改進的自適應 AI。你的 Text-to-SQL 系統不僅把語言翻譯成查詢——它還能構建會復利增長的組織知識。
想看 ACE 的實際表現？完整實現已在 [GitHub](??https://github.com/MKcodeshere/Self-Improving-Text2SQL/tree/main??) 開源，包含 PostgreSQL dvdrental 數據庫的安裝說明。
下一部分，我將介紹像 Episodic、Semantic 和 Procedural 這樣的知識庫如何在 ACE 框架下賦能 Text2sql 系統。
參考資源：https://www.arxiv.org/pdf/2510.04618
本文轉載自??PyTorch研習社??，作者：AI研究生
