2026-09-07

Text2SQL 實踐：企業自然語言查數怎麼做

從邊界、指標語義層、權限隔離到 SQL 校驗，系統拆解 Text2SQL 實踐方法，幫助企業安全、可控地實現自然語言查數。

一、先定邊界：不要從「萬能查數」開始試點

Text2SQL 試點首先要確定系統在哪些問題上可以作答，而不是先追求覆蓋多少問法。邊界判斷可看兩個變數：查詢本身有多複雜，以及回答錯誤會造成多大影響。BIRD-CRITIC 的公開評測反映出，涉及多表推理、複雜約束與深層巢狀時，現有模型仍難保持穩定。因此，複雜度不能全部交給模型消化，能通過資料建模簡化關聯、用 ETL 固化計算的邏輯，應先在資料側處理。

首批範圍宜收斂到一個業務主題內：資料表之間的關係已經固定，指標定義不存在爭議，查詢主要完成條件過濾、彙總統計與維度分組，並且只允許讀取。跨主題的資料歸因、需要多層子查詢的分析，以及直接影響結算結果的計算，可保留人工審核，不進入自動執行範圍。這樣做不是降低目標，而是把模型變數與資料治理問題分開，避免試點失敗後無法判斷究竟錯在語義、資料還是 SQL。

還要先區分使用對象。分析師具備閱讀和修改 SQL 的能力，系統可以定位為程式碼輔助工具：生成草稿、展示引用對象，由使用者檢查後執行。業務人員通常只看到最終數字，無法識別錯誤連接、遺漏過濾或聚合層級偏差，因此需要更嚴格的准入條件。此類入口應繫結經過治理的資料集，並限定可提問的指標、維度和時間範圍。兩種模式不能共用同一套驗收門檻。

白名單應描述「允許查詢什麼」，而不只是維護一組停用詞。每個場景需要繫結可訪問的資料對象、支援的指標和維度、允許的查詢形態、結果粒度，以及異常時的處理方式。否則，同一句自然語言在資料結構變化後，可能生成語法正確但業務含義已經漂移的 SQL。

試點驗收也不能停留在「是否成功生成 SQL」。至少要分別記錄：語句執行後是否得到正確結果，輸出是否遵循既定業務定義，系統在歧義問題上是否主動追問，對越界請求是否拒絕，端到端響應耗時是否可接受，以及多少請求最終需要人工處理。生成率只能說明鏈路能執行，不能證明它適合開放給業務使用。

邊界確定後，團隊應形成一份可審查的場景清單：哪些問題自動回答，哪些必須補充條件，哪些只生成草稿，哪些始終拒絕。後續擴展應以評測結果為依據逐項放開，而不是通過修改 Prompt 一次性擴大能力範圍。

二、指標口徑先於 Prompt：建設可檢索的語義層

企業查數最先暴露的問題通常不是 SQL 語法，而是業務詞沒有唯一解釋。模型看到訂單表、付款表和收入明細表，可以分別寫出可執行的「銷售額」查詢，但資料庫能執行不代表結果符合經營口徑。因此，Prompt 不應承擔定義指標的職責；口徑要先被整理成機器可檢索、可執行、可追溯的語義資產。

指標目錄是語義層的入口。每個指標條目需要描述其業務含義、標準稱謂、計算表示式、適用維度、預設週期、前置過濾、維護責任、版本狀態與生效區間。這裡不能只儲存一段說明文字，還要明確資料來源、聚合方式、時間欄位、去重規則以及空值處理。否則，檢索雖然找到了指標，生成階段仍要猜測具體演算法。

「新增客戶」「活躍使用者」之類的名稱往往同時存在集團定義和部門定義。工程上應為標準口徑設定穩定標識，再把部門變體和自然語言別稱掛接到對應版本。若使用者問題能夠命中多個有效定義，系統應返回候選項並詢問統計部門、時間範圍或業務範圍。讓模型根據上下文自行挑選，會把口徑衝突隱藏成一個看似正常的數字。

語義層還要能夠下沉到執行側。可將已審核的指標邏輯發布為受約束的查詢模板、語義模型或統一指標介面。模型只解析使用者提出的指標、觀察維度、條件、週期和排序要求，再由確定性元件組裝查詢。複雜計算、固定過濾和標準關聯不再臨時生成，審計時也能追蹤結果使用了哪個口徑版本。

Schema Linking 的目標不是把整個資料庫結構塞進上下文，而是縮小模型的選擇範圍。一次請求可以先檢索相關指標，再擴展到必要的事實資料、維度資料、欄位說明、連接鍵和候選列舉值。輸入模型的結構應限於本次查詢需要的子圖，並保留關聯方向與欄位語義，避免模型僅憑相似的物理命名建立錯誤連接。

中文檢索需要把術語理解和值匹配分開處理。企業縮寫、業務同義表達和欄位註釋適合進入語義檢索；機構名、地區名、商品名等具體值，則可同時建立字元、拼音和模糊匹配通道，再對候選結果精排。常見錯字、同音輸入及鍵盤誤觸不應直接交給大模型猜測，而應在檢索層產生可核驗的候選值。

• 唯一命中：攜帶指標版本和相關 Schema 進入查詢規劃。
• 多口徑命中：展示差異點，完成澄清後再生成 SQL。
• 只能匹配術語、無法定位指標：返回已識別條件，並提示補充業務範圍。
• 沒有可靠匹配：停止生成，避免從物理表名推斷業務含義。

這一層的驗收重點不是模型是否「理解」了術語，而是同一問題能否穩定繫結到確定的指標版本、連接路徑和過濾規則。只有這些決策可以被記錄和復現，後續的 SQL 校驗才有明確依據。

三、權限隔離：模型有能力生成，不等於使用者有權查詢

Text2SQL 的權限邊界不能建立在提示詞上。模型可以按要求補出表名、連接條件和過濾表示式，但它既不是身份認證元件，也不應參與授權決策。使用者在問題中寫下「我是財務負責人」，只能被當作查詢文本；真實的人員身份、所屬組織、業務角色、租戶範圍與訪問目的，應由登入態、身份服務或審批系統提供，並以不可被對話內容覆蓋的上下文傳入查詢鏈路。

可信上下文進入系統後，應先完成權限判定，再允許生成結果被執行。即使模型漏寫了部門條件，底層控制仍須阻止跨部門讀取；即使生成語句引用了敏感列，執行側也必須拒絕或按規則處理。換言之，授權約束要落在確定性元件中，而不是期待模型每次都正確拼接 WHERE 子句。

權限設計需要覆蓋對象、記錄、欄位和結果交付。對象範圍通過庫表或檢視清單收斂；記錄範圍按租戶、組織或資料歸屬強制裁剪；欄位範圍控制敏感列是否可見，並按策略隱藏或轉換內容；結果交付則約束返回規模、檔案下載和批次匯出。這裡的關鍵不是多設一道檢查，而是確保任何單點失效都不會直接擴大數據可見範圍。

生成元件與執行元件也應隔離。模型側只產出查詢候選，不接觸可直接連接資料來源的憑據；執行服務使用專門的受限帳號，只開放必要的讀取能力。建表、修改結構、寫入、刪除、呼叫儲存過程以及不必要的危險函式，應在帳號權限和閘道器規則中關閉，而不是只做字串攔截。資料訪問可經過查詢閘道器、隔離環境或只讀副本，使生成錯誤和惡意輸入無法直接影響生產寫路徑。

只讀並不等於低風險。一個合法的 SELECT 仍可能讀取過多明細、繞過租戶範圍，或通過複雜計算消耗大量資源。因此，執行前還要核對引用對象、權限策略和查詢結構；執行時應用超時、資源配額與結果規模約束；需要下載時，再進行獨立授權。輸入檢查和 SQL 注入防護屬於基礎措施，不能替代完整的權限模型。

審計記錄應貫穿整個請求，而不只是儲存最終 SQL。可追溯資訊包括原始提問、認證系統提供的主體屬性、檢索到的後設資料、候選語句及其變更軌跡、授權判斷、執行狀態、結果概況，以及檢視或匯出動作。日誌中不應再次暴露完整敏感結果，但要能回答：誰在什麼上下文中請求了哪些資料，系統依據什麼規則放行或阻斷，最終返回到了哪裡。

驗收權限隔離時，不要只測試正常查詢。還應覆蓋偽造身份、跨租戶提問、誘導訪問未授權表、請求敏感欄位、超量明細匯出和藉助複雜 SQL 繞過限制等情況。合格標準不是模型「通常會拒絕」，而是無論模型生成什麼，確定性的執行邊界都能保持不變。

四、生成鏈路：把一次性回答拆成可控制的工程流水線

企業 Text2SQL 不宜把需求理解、選表、SQL 編寫和錯誤修復全部塞進一個 Prompt。這樣雖然鏈路短，但中間決策不可見：一旦結果錯誤，很難判斷問題出在業務語義、表關係還是 SQL 表達。更可控的做法，是把生成過程拆成若干有明確輸入和輸出的環節。

其中最關鍵的隔離層是查詢計劃。模型不應從自然語言直接跳到最終 SQL，而應先提交機器可讀的中間表示。例如，將「統計對象」「分組欄位」「謂詞條件」「日期邊界」「聚合運算元」和「連接關係」分別放入固定欄位。後續元件再把它編譯成 MySQL、PostgreSQL 或數倉所需方言。這樣，業務語義與資料庫語法被分開處理：修改表名或函式寫法時，不必重新解釋使用者意圖；發生錯誤時，也能定位是計劃本身有誤，還是編譯結果偏離計劃。

生成方式不必全部交給模型。對於結構穩定、參數有限的查詢，應優先匹配查詢模板或參數化 SQL。模型只負責抽取日期、區域、產品等參數，並選擇適用模板。需要臨時組合維度、跨表探索且無法覆蓋模板的問題，再進入自由生成路徑。兩類路徑應顯式分流，而不是讓模型每次都重新組織完整語句。

Agent 適合處理需要多步工具呼叫的任務，例如篩選候選表、讀取必要的 Schema、審查候選語句、依據資料庫報錯進行修訂，或按需要發起後續查詢。但它不能擁有無限循環的自主權。執行配置至少要約束以下邊界：

• 只允許呼叫經過批准的檢索、檢查和查詢工具；
• 限制單次任務能夠推進的工具步驟；
• 限制同一錯誤觸發的修訂次數；
• 對整次任務設定統一的執行資源預算。

資料庫返回錯誤後，可以把候選 SQL 與錯誤內容送入修訂環節，用於處理識別符號引用、欄位型別或對象名稱等生成問題。但修訂必須重新經過檢查，而不是直接執行修改後的語句。整條鏈路的目標不是增加步驟，而是讓每次轉換都有可檢查的產物，使模板、模型和 Agent 分別承擔邊界清楚的工作。

五、SQL 校驗：從「能執行」升級到「可證明地可信」

資料庫接受一條 SQL，只能說明它符合語法並且引用對象存在，不能證明查詢安全、業務口徑正確或資源消耗合理。企業查數需要把校驗拆成執行前靜態檢查、業務語義核對、成本控制和執行後結果檢查，併為每一步保留可審計的判斷結果。

先解析結構，不直接檢查字串

執行服務應按目標資料庫方言把 SQL 解析為抽象語法樹，再檢查語句型別、引用對象、表示式與關聯關係。簡單搜尋 DELETE、DROP 等關鍵詞容易受到註釋、大小寫、巢狀表示式或方言差異影響，也無法識別隱藏在函式和子查詢中的風險。

• 語句範圍：僅放行只讀 SELECT，拒絕多語句以及任何資料定義、資料修改和權限變更操作。
• 對象範圍：表、檢視、欄位和函式必須位於授權清單內，通配欄位也要展開後逐項檢查。
• 結構風險：識別無連接條件的多表查詢、可疑關聯鍵、條件未傳遞到關聯表，以及可能放大結果集的 JOIN。
• 掃描風險：檢查明細查詢是否缺少必要的時間或租戶約束，是否存在無邊界排序、全表掃描傾向和過寬欄位投影。
• 繞過風險：拒絕註釋混淆、危險函式、動態 SQL、外部訪問能力及無法可靠解析的語句。

無法完成解析的 SQL 不應帶病執行。與其用字串規則猜測風險，不如返回生成環節重新構造，或者進入人工處理。

語法通過後，再核對業務語義

更隱蔽的問題通常不是 SQL 報錯，而是結果看似合理、實際口徑錯誤。校驗器需要將查詢計劃與語義層中的指標定義逐項對照：計算表示式是否匹配，使用的是業務發生時間還是資料寫入時間，聚合層級是否符合問題，去重主鍵是否正確，以及幣種處理和業務時區是否一致。

多表查詢還要驗證關聯路徑。事實表連接維表時，錯誤的鍵或不完整的過濾條件可能改變行數；一對多關係參與彙總時，則需要確認聚合發生在連接之前還是之後。若使用者問題存在時間範圍、組織範圍或指標定義歧義，應先澄清，不應依靠模型自行補齊。

把資源預算放在執行之前

靜態檢查和語義檢查通過後，再使用 EXPLAIN、最佳化器估算結果或資料平台提供的成本資訊評估查詢。執行策略應同時約束預計掃描規模、結果行數、執行時長和併發佔用。超過預算時，可縮小時間範圍、減少返回欄位、改為預聚合查詢；仍無法降到預算內的任務，轉為非同步處理或拒絕執行。

執行成功不等於校驗結束

結果返回後仍需檢查空集、數量級偏離、同比變化異常，以及分項彙總與總計無法對齊等情況。發現異常時，應區分「資料確實如此」和「查詢可能有誤」：前者附帶提示，後者阻止直接回答並進入修正流程。執行報錯可以把 SQL 與錯誤資訊交回修正環節，但必須限制重試，避免反覆生成近似語句持續消耗資料庫資源。

最終展示不應只有數字。至少應說明採用的指標口徑、實際篩選條件、統計時間範圍和資料截至時間；必要時補充表來源、關聯方式及聚合邏輯。這裡的目標不是向用戶傾倒完整 SQL，而是讓結果能夠被複核，讓安全、語義和成本判斷都有記錄可查。

六、失敗兜底：明確什麼時候澄清、重試、降級或轉人工

Text2SQL 的兜底不能統一處理成「生成失敗，請重試」。不同故障對應不同動作：缺資訊時補充條件，口徑衝突時讓使用者選擇，越權請求直接終止，語法問題才進入修復，資源消耗不可接受時改用低成本路徑，結果可信度不足時停止作答。先完成故障歸類，再決定是否繼續執行，避免模型在原因不明時反覆改寫 SQL。

澄清環節應輸出有限選項，而不是繼續開放式猜測。例如，要求使用者確認採用哪一種指標定義，選擇自然月還是自定義日期，限定組織範圍，並確定按日、周、月還是明細記錄返回。對話模組只負責收集缺失參數；參數未齊全之前，執行模組不應被呼叫。這樣可以避免同一個模型一邊補全假設，一邊把假設寫入查詢。

候選口徑需要展示決定結果的差異，而不只是列出幾個相近名稱。系統可以說明各候選項對應的時間欄位、過濾條件和聚合方式，讓使用者做業務選擇。若系統採用預設值，也應在結果前顯式列出，不能把預設條件隱藏在 SQL 內部。

自動修復的範圍必須收窄。適合機器處理的是技術性、局部且可驗證的問題，例如列名解析失敗、字串引號不符合目標資料庫要求、比較兩端型別不一致，或生成語法與實際資料庫方言不匹配。指標定義衝突、連接關係不確定、授權失敗和結果異常不屬於語法修補，不應交給修復循環自行猜測。

每輪修訂都應視為一條新查詢：重新檢查使用者權限和資料範圍，重新執行語法與對象校驗，再評估掃描成本、返回規模和執行限制。系統還要設定固定的重試上限；達到上限後立即退出，不能因錯誤資訊變化而無限循環。修復記錄應保留原始 SQL、錯誤摘要、修改內容與最終狀態，便於後續定位。

降級不等於返回一個精度更差卻未說明的數字。可行做法是收窄時間區間、減少維度、切換到已授權的彙總粒度，或者只生成查詢計劃供人工確認。任何降級都要向用戶說明哪些條件被調整；如果調整會改變業務含義，則必須再次確認。

最終兜底仍需提供下一步動作。輸出至少應說明失敗屬於語義、權限、執行還是結果校驗問題，列出已經識別的指標、時間、組織與粒度條件，並給出可直接選擇或改寫的問題模板。需要人工介入時，應一併移交原問題、結構化查詢計劃、候選 SQL、校驗結論和執行錯誤，減少資料分析人員重複排查。

七、從試點到上線：用評測集、影子流量和灰度機制推進

Text2SQL 上線不應以演示案例是否成功為依據，而要驗證系統在真實問題、權限約束和異常輸入下是否穩定。評測資料可從歷史查數工單、BI 搜尋記錄與分析師編寫的 SQL 中整理，並去除敏感資訊。樣本需要覆蓋常見查詢、同義改寫、表達不完整、越權請求、多表關聯、無資料返回及錯誤欄位等情況。

每條樣本應保留使用者問題、授權身份、預期口徑、參考結果和允許訪問的資料範圍。標準答案不宜只標一條 SQL，因為不同寫法可能得到相同結果；指標負責人應確認業務定義，分析師負責核對連接路徑、過濾條件與聚合方式。生產中發現的新問題再持續補入評測集，使其成為後續變更的迴歸基線。

Text2SQL 可以直接連接生產資料庫嗎？

試點階段不應讓模型生成的語句直接進入生產執行鏈路。上線前可先做影子執行：系統接收真實請求並生成候選 SQL，但結果不返回使用者。若需要驗證結果，應在受控的只讀環境中執行，再由分析師與既有報表或已確認查詢進行對照。

影子驗證通過後，再按業務部門、資料主題和風險級別逐步開放。灰度範圍內仍需保留只讀權限、查詢限額、審計記錄與人工停用入口。輔助分析師編寫 SQL 與面向業務人員自動返回答案，對準確性的要求不同，不能採用同一放行標準。

SQL 執行成功，是否就說明答案正確？

不能。資料庫接受語法，只能說明語句可執行，無法證明指標定義、時間欄位、關聯關係或權限範圍正確。離線評測應把不同問題拆開觀察，包括查詢能否正確執行、結果是否與參考資料一致、業務口徑是否命中、越權請求是否被阻斷，以及危險語句是否被錯誤放行。

也不宜用 SQL 字串完全一致作為主要判據。欄位順序、別名、子查詢和連接寫法不同，仍可能產生相同結果。評測應結合結構檢查、結果對照和口徑審核；涉及空結果時，還要區分「業務上確實沒有資料」與「過濾或連接條件寫錯」。

遇到「銷售額怎麼樣」這類模糊問題，系統應該猜還是追問？

當缺失的條件會改變業務結論時，應追問而不是猜測。評測集中需要專門加入歧義樣本，檢查系統能否識別缺少的時間範圍、組織範圍、統計口徑或對比基準。使用者補充條件、選擇澄清項以及改寫問題的記錄，都應進入後續迴歸測試。

若缺失資訊不影響結果，或語義層中已有經過確認的預設規則，可以繼續執行，但答案中應明確展示採用的條件。系統是否需要追問，應由口徑規則決定，不能依賴模型臨時推斷。

企業應如何判斷 Text2SQL 已達到上線標準？

上線標準應按場景風險分別設定，而不是只看一個綜合準確率。團隊需要為結果正確性、口徑符合度、權限阻斷和危險語句控制分別設定門檻；高風險主題未通過時，可以繼續關閉，即使其他主題已經開放。

生產執行後，應持續採集使用者改寫、澄清選擇、評價回饋、失敗分類和分析師修正後的 SQL。模型版本、Prompt、語義層或權限策略發生變化時，都要回放固定評測集，並比較新增失敗與歷史退化。只有離線評測、影子對照和限定範圍灰度均符合既定門檻，才適合擴大開放範圍。