HarnessSQL 研究讓 AI 在資料庫環境裡練習：生成 SQL 之前，先學會查證

請 AI 寫一段 SQL，與讓它正確回答資料庫問題，是兩種不同難度的工作。HarnessSQL 研究把模型放進可查詢的資料庫環境裡訓練，讓它先看資料表、檢查結果，再交出答案。

這篇論文最近在 X 被分享，引起 SQL 代理開發者討論。它最值得注意的方向，是把訓練時的工具與部署時的工作方式接起來，讓模型練習實際需要完成的查證步驟。

HarnessSQL 讓模型在資料庫裡分步工作

SQL 是查詢資料庫的語言。只看自然語言問題生成 SQL，可能忽略資料表之間的關係、欄位實際內容，或某個值是否真的存在。執行查詢後，這些問題才比較容易被看見。

HarnessSQL 提供列出資料表、查閱結構、執行查詢與提交答案等工具。代理可以透過工具觀察環境，根據結果修改下一步，而不必在資訊不足時一次寫完查詢。

例如，題目問某類訂單的平均金額，代理需要先找到對應資料表，確認金額與分類欄位，再決定篩選方式。若查詢回傳空結果，它也需要辨識原因，而不是直接把零當作答案。

訓練包含完整工作軌跡與執行結果

論文先用經過驗證的完整工作軌跡訓練模型。工作軌跡指從問題、工具呼叫到最後答案的一連串步驟，讓模型學習查閱與修正的順序。

接著，研究使用執行結果作為回饋進行強化學習。強化學習可以理解為根據工作成果調整模型，讓較能得到正確結果的行為，逐漸更容易出現。

這兩個階段一起處理的，是代理如何在環境中完成工作。論文也強調訓練與部署環境的一致性：如果模型練習時與實際使用時的工具差很多，學到的流程就可能難以沿用。

對開發者來說，這提供了一個檢查方向。遇到代理查詢不穩定時，除了換模型，也可以檢查工具說明、回傳格式，以及代理有沒有足夠資訊判斷自己的查詢是否合理。

Spider 2.0 成績提高，仍有測試範圍

在 Spider 2.0 的 SQLite 測試中，論文報告 8B 模型的執行準確率從 15.5% 提高到 45.2%，14B 模型則從 22.2% 提高到 54.8%。B 代表十億，這裡用來描述模型參數規模。

SQLite 是一種資料庫系統，Spider 2.0 則是評估資料庫問答的測試集合。這些百分比反映論文指定模型、訓練方法與測試設定的結果，不能直接當成企業資料上的保證。

研究也提供其他資料集上的轉移測試，顯示不同環境仍有明顯挑戰。即使模型在原本題組進步很多，換到欄位命名、資料內容與任務規則不同的系統，仍需要重新驗證。

這項成果顯示，HarnessSQL 能在指定測試中提高 SQL 代理表現。企業資料、工具與任務不同，仍需要各自驗證。

企業能直接下載成為資料分析助理嗎？

作者公開的儲存庫提供研究流程程式碼，並不是附帶全部模型權重、資料與設定的一鍵產品。模型權重是訓練完成後，決定模型如何運作的核心參數。重現訓練需要處理運算資源、資料準備與環境相容性。

想把這個方向帶進企業，可以先建立幾個答案已知的內部問題，讓代理在受控、唯讀的資料環境查詢，再比對它使用的資料表、查詢與答案。唯讀代表允許查資料，不允許改動資料。

HarnessSQL 的啟發，是讓 AI 有機會在交出答案前看見實際結果。當工具與驗證接進訓練流程，資料庫代理的進步就比較能回到可追查的工作步驟，而不只是一段看起來正確的 SQL。

SQL 代理為什麼需要先探索資料，再交出查詢

資料庫問答容易出錯，常見原因是題目中的概念沒有直接對應欄位。例如，使用者問「活躍客戶」，資料表裡可能只有登入、訂單與會員狀態，需要先定義怎樣才算活躍。

代理如果只根據文字生成查詢，可能選到看似合理的欄位。讓它查看資料結構與執行結果，能增加修正的機會，但業務定義仍需要使用者或團隊提供。

先確認資料表之間如何對應

訂單、商品與退款可能存在不同資料表裡，查詢時需要知道它們如何連接。識別碼就是用來對應同一筆實體的欄位，代理應先確認這些關係，再安排查詢。

如果一張訂單有多筆商品，直接連接兩張表後加總訂單金額，可能讓同一金額被算多次。這種錯誤的查詢能正常執行，所以只看程式有沒有報錯並不夠。

使用者可以要求代理說明一列結果代表什麼，以及連接之後資料筆數有沒有改變。這些資訊能讓查詢邏輯更容易被核對，也幫助人發現重複計算。

空結果也需要解釋

查詢沒有資料，可能代表條件真的沒有符合項目，也可能是名稱、日期格式或欄位選錯。代理應該先檢查原因，再決定是否需要改寫查詢。

例如，資料中的狀態可能使用代碼，題目卻使用中文名稱。如果代理直接拿文字去篩選，就可能得到空結果，不能因此認定該類訂單不存在。

這也是工具回覆的重要性。清楚的欄位、樣本與錯誤資訊，會讓代理比較容易理解環境，而不是一直在同一個錯誤假設下改寫 SQL。

完整工作軌跡，提供了什麼訓練資訊

一個最後正確的查詢，只展示了終點。完整工作軌跡還包含代理先看哪張表、為何執行某個查詢，以及結果不符合預期時如何修改。

HarnessSQL 使用這種軌跡作為訓練資料，讓模型學習在工具環境中工作。這個方向的價值，是把探索與修正也納入學習，而不只是模仿最後一段 SQL。

好的軌跡需要能被驗證

軌跡如果包含錯誤解讀，即使最後碰巧得到答案，也未必適合作為學習依據。論文先使用經過驗證的資料，正是為了讓過程與結果具有較清楚的可靠性。

從開發角度看，保存完整過程也有助於查錯。若模型選錯資料表，問題出在探索階段。若表選對但統計範圍錯，則需要看查詢邏輯。

這種分類能幫助團隊決定下一步。改善工具說明、補齊業務定義與調整訓練資料，處理的是不同原因，不能只用更換模型作為唯一修正方式。

執行回饋需要符合真正的任務目標

強化學習使用結果來調整模型，結果指標如何定義，就會影響模型學到的行為。SQL 能執行，與答案符合題目，是不同程度的完成要求。

在實際應用裡，可以先檢查查詢能否執行，再核對答案與必要條件。若只獎勵沒有錯誤訊息，代理可能偏向容易執行、卻沒有回答問題的查詢。

論文中的訓練設定有特定測試範圍，企業不能直接把它當成自己的業務標準。導入時仍要定義哪些答案算正確，以及哪些行為不應被允許。

評估 SQL 代理，先建立一組答案已知的問題

一個容易開始的方式，是把團隊經常問的問題整理成小型測試集。每題保留問題、正確答案、資料版本與判斷依據，讓代理結果可以被重複核對。

測試題可以包含總數、分組、日期範圍與多表連接。不同題型會暴露不同問題，比只看一個簡單查詢，更容易知道代理目前能處理到哪裡。

答案相同，不代表每個查詢都合適

兩段查詢可能在小樣本上得到同樣答案，換到更完整資料後卻不同。例如，某個欄位在測試資料裡沒有空值，不代表正式資料永遠如此。

因此，可以在測試集加入缺漏、重複與邊界日期等情況。這些例子能觀察代理是否真正理解條件，而不只是剛好符合一份資料。

若任務允許多種正確查詢，評估也應保留彈性。比較重點是答案、範圍與必要限制，不一定要求模型逐字生成和人相同的 SQL。

資料版本需要固定

同一題目如果每次查詢的資料都在變，答案差異就不一定來自模型。保留固定測試版本，才容易比較更新前後的表現。

正式環境則可以另外觀察最新資料上的工作結果。把固定測試與實際使用分開，能同時看見模型變化與資料變化，不必把兩種原因混在一起。

測試紀錄還應保留失敗案例。沒有回答、答案錯誤與查詢超出範圍，都需要被看見，這樣後續改善才有清楚方向。

唯讀工具與受控環境，讓試驗比較容易管理

論文的 SQL 工具以讀取與提交答案為主，適合用來理解研究範圍。企業初次試驗也可以先提供唯讀資料，讓代理練習查詢，而不直接賦予修改正式資料的能力。

唯讀仍需要限制可以讀哪些資料。若題目只需要匯總數字，就不必讓代理取得與任務無關的個人內容。資料範圍應該對應實際問題。

給代理需要的結構，不把所有內容一次交給它

資料表說明可以包含欄位用途、單位與表之間的關係。這些資訊能讓代理少猜一些概念，也比一次輸入全部原始資料更容易掌握範圍。

工具回覆則可以保留足夠的執行資訊，例如查詢是否成功、結果是否完整，以及是否有需要注意的限制。這讓代理知道自己目前看見了什麼。

當某個問題需要更多權限或業務定義，可以轉交人確認。把這些情況記錄下來，也能知道現有工具與資料是否足以支持團隊真正想問的問題。

研究程式與可用產品之間，還有整合工作

作者儲存庫公開的是研究流程，重現訓練還需要資料、模型與運算環境。即使研究成果有吸引力，也不能把下載程式碼當成企業助理已經準備完成。

團隊可以先借用它的評估思路，確認自己在哪些查詢上最需要改善，再決定是否投入重現或訓練。這會讓研究方向與實際問題更容易接起來。

HarnessSQL 常見問題

執行準確率和 SQL 語法正確率一樣嗎？

兩者不同。語法正確代表查詢形式可被資料庫接受，執行準確率則要看結果是否符合測試要求。能執行的查詢，也可能回答錯誤的問題。

理解這個差別，才不會把沒有錯誤訊息當成答案可信。實際應用應保留題目、查詢與結果之間的核對。

模型參數比較大，就一定更適合公司資料嗎？

參數規模只是其中一項資訊，工具、資料與任務定義也會影響表現。論文數據有指定設定，自己的環境仍需要測試。

可以先用相同題組比較候選模型，再看費用與人工修正。這樣的結果會比只依模型大小選擇，更容易對應工作需求。

一開始需要自己重現完整訓練嗎？

不一定。可以先建立可驗證的問題集與唯讀工具，觀察現有代理在哪些地方失敗。知道問題來源後，才比較容易決定是否需要新的訓練方法。

若資料定義不清楚，先補文件可能比訓練更直接。若工作流程本身不穩定，也應先確認工具與驗收方式。

最值得帶回企業的啟發是什麼？

讓代理在交答案前有機會探索資料與修正查詢，並保存可核對的工作過程。這能把流暢回答接回實際執行，而不是只憑文字判斷可靠性。

HarnessSQL 展示了這個方向在指定測試中的進步。企業下一步則是讓同樣的工作方式，符合自己的資料定義、權限範圍與完成標準。

先建立題目與答案，再評估新的研究方法

團隊可以從經常使用的報表挑出幾道問題，固定資料版本與答案，讓代理在唯讀環境完成查詢。保存完整工作軌跡後，就比較容易知道失敗來自哪一步。

如果問題是資料定義不清楚，可以先改善文件。如果代理不懂工具結果，再檢查回傳方式。只有當失敗原因被看見，才容易決定是否需要額外訓練。

HarnessSQL 的進步提供了研究方向，企業的評估則需要自己的資料與完成標準。把可執行與可查證接起來，SQL 代理的結果才更容易被理解與信任。

想持續追蹤 AI 科技新聞與實用工具，可以免費註冊 AI 郵報會員，閱讀更多新功能的用途與實作解讀。

延伸閱讀：Replit 收購 Atta：不用寫 SQL，聊天就能做互動圖表？功能、限制與適合團隊。

延伸閱讀：ChatGPT Data agent 是什麼？不用寫 SQL，也能把公司資料變成互動儀表板。

資料來源

HarnessSQL 論文作者 一手資料、X 原始貼文。