2026-08-18

Text2SQL 落地指南：架構、資料權限、SQL 安全與上線驗收

系統介紹 Text2SQL 實踐方法，涵蓋應用邊界、系統架構、資料權限、SQL 安全校驗、指標口徑治理與上線驗收，幫助企業可靠實現自然語言查數。

一、先判斷適不適合：Text2SQL 的企業應用邊界

企業引入 Text2SQL，首先要回答的不是「模型能不能生成 SQL」，而是「生成結果在什麼後果範圍內可以被接受」。同一套能力用於分析師臨時探查資料，和用於生成經營決策依據，風險等級並不相同。前者允許使用者檢查、修改和重跑；後者一旦把錯誤結果送入報表、審批或自動化流程，問題就不再只是語句寫錯，而可能變成業務判斷失真。

從使用方式看，企業可以把場景按人工介入程度劃分為不同層級。一種場景是 SQL 草稿輔助：模型負責把自然語言轉成起始語句，工程師或分析師審核後再執行，適合驗證模型是否理解表結構和基本查詢意圖。

場景本身並不限於 BI。企業可以把它放在自然語言查數入口，幫助客服根據授權範圍檢索業務資訊，也可以作為低程式碼應用的資料操作層，或用於分析人員快速試探資料。但這些場景的驗收標準不同：客服更關注回答是否越權、是否能說明資料來源；分析探索更關注靈活性和修改成本；業務自助查詢則更依賴指標定義是否清楚；自動化流程還要額外證明錯誤結果不會無條件向下遊擴散。

有些環境不適合直接把 Text2SQL 放在前面。例如，表之間缺少穩定關係，資料模型靠個人經驗維持；同一個指標在部門之間存在不同演算法，名稱相同但含義不同；查詢需要頻繁跨庫拼接，且資料庫方言、更新延遲和主資料規則不一致；結果會直接影響預算、風控、績效或其他經營動作。遇到這些情況，優先順序應放在資料建模、指標定義和語義治理上。模型只能表達已經明確的業務規則，不能替企業補齊未達成共識的口徑。

因此，評估專案時不要只看模型在公開榜單上的準確率。更實用的判斷方式，是把以下問題放在一起看：資料是否敏感，問題是否經常需要多表或巢狀計算，錯誤一次的修正代價有多高，預計使用者是否足夠多，以及是否有分析師、資料工程師或業務負責人承擔人工兜底。若資料敏感度高、查詢鏈路複雜、容錯空間小，同時又缺少複核人員，應先縮小範圍，而不是擴大模型權限。反過來，如果資料域邊界清楚、問題相對固定、使用者願意核對結果，Text2SQL 更適合作為受控的查詢輔助能力逐步驗證。

二、系統架構：把自然語言查數拆成可治理的鏈路

企業場景不宜把使用者問題直接交給模型，再讓模型自行連接資料庫。各環節都應保留中間產物，這樣出現錯誤時，可以判斷問題來自理解、選表、生成還是執行，而不是只看到一個最終答案。

這套拆分的關鍵，不是把流程做得更長，而是避免不同型別的問題互相掩蓋。語義理解負責回答「使用者想查什麼」，生成模組負責把已確認的意圖轉成查詢結構，後續修正模組再處理語法、欄位引用和執行約束。三者可以分別建立測試集，也可以獨立替換實現。比如，某類問題頻繁選錯指標時，應優先檢查概念識別和後設資料召回，而不是盲目調整 SQL 生成提示。

Schema 目錄也不能停留在表名、列名和資料型別。對模型和審核流程真正有用的後設資料，還包括欄位的業務含義、常用稱呼、指標計算方式、主外部索引鍵關係、允許的連接路線、敏感等級以及少量經過處理的示例值。沒有這些語義資訊，模型即使寫出語法正確的語句，也可能選中含義相近但口徑不同的欄位。

後設資料檢索應先縮小候選範圍，再把必要上下文交給後續模組。把整個資料庫的結構一次性塞入提示上下文，會增加無關資訊，也會讓關聯路徑和指標定義更難被穩定利用。更適合的方式是按業務域、問題實體和指標候選篩選，並明確哪些表可用、哪些欄位不可用、表之間允許怎樣連接。對於敏感欄位，目錄中還應標註其訪問條件，但最終放行不能只依賴模型判斷。

簡單問題可以通過受約束的模板生成查詢；涉及多表連接、巢狀聚合或分階段計算的問題，建議先形成查詢計劃或抽象語法樹，再轉換成具體資料庫方言。中間表示可以把「先過濾什麼、如何關聯、在哪一層聚合」等決定顯式化，便於檢查和修改，也能減少模型直接拼接長 SQL 時出現結構漂移的風險。轉換器還應對目標資料庫的函式、日期處理和分頁方式作適配。

執行層必須與生成層隔離。模型只能提交待審核的查詢對象，不能自行獲得生產庫的任意訪問能力；執行服務負責再次套用訪問邊界、資源限制和執行策略，並把成功、失敗或被攔截的狀態返回給上游。結果解釋也不應重新猜測資料，而應基於實際執行結果、採用的指標定義和查詢條件，說明統計範圍、時間口徑及可能的缺失項。

落地時，建議為每個階段定義可觀測的輸入、輸出和失敗原因，並儲存版本資訊：使用了哪份後設資料、採用了哪條指標定義、生成了什麼計劃、最終執行了哪條語句。這樣既方便回放單次請求，也便於定位是目錄變更、口徑調整還是模型行為導致結果變化。架構的目標不是讓模型承擔整條鏈路，而是把它放在有邊界、可替換、能被審計的環節中。

三、企業資料權限：模型能看什麼，使用者最終能查什麼

Text2SQL 的權限問題，不能靠提示詞解決。Prompt 可以提醒模型不要訪問某些表，但它不是強制邊界：模型仍可能生成未授權欄位，使用者也可能通過改寫問題、猜測列名或構造 JOIN 試探資料。真正的權限判定應落在資料庫、查詢閘道器或受控執行器一側，SQL 在執行前必須綁定當前使用者的身份與授權上下文。

1. 權限判斷要跟著請求走

模型生成 SQL 之前，系統需要明確請求屬於誰、來自哪個租戶、可以使用哪些資料域，以及該使用者在當前角色下擁有何種訪問範圍。這裡的校驗不是一次性的登入檢查，而是貫穿後設資料檢索、SQL 生成、執行和結果返回的連續約束。

權限控制不能只在生成階段檢查一次。執行器應在 SQL 進入資料庫前再次校驗，並對租戶條件、行級過濾和敏感列做強制約束。

2. 無權後設資料也不應進入上下文

Schema 檢索是權限控制的前置環節。系統不應把完整資料庫結構交給模型，再依賴提示詞說明哪些內容不能使用，而應先依據當前使用者權限裁剪可見的表、欄位、列舉值和示例資料。問題中的實體、關鍵詞和業務值可以用於檢索相關 Schema，例如將地區名稱對映到資料庫中的標準值，但檢索候選集本身必須已經過授權過濾。

這樣做有兩個工程收益：一是減少模型接觸無權後設資料的機會，二是降低無關表列進入上下文後造成的誤選。需要注意，隱藏欄位名並不能替代執行側權限；即使模型沒有見過某列，使用者仍可能通過猜測欄位或函式構造請求，因此最終邊界仍應由閘道器或資料庫強制執行。

3. 給模型和生產庫之間加執行隔離

模型不應直接持有生產資料庫的高權限連接。更穩妥的做法是使用只讀身份，將請求交給受控查詢閘道器或執行器處理。

每次請求都應留下可追溯記錄：操作者身份、租戶和資料域、原始問題、實際提供給模型的 Schema、生成 SQL、權限判定、執行結果狀態以及返回摘要。日誌既用於事後審計，也用於定位「生成正確但授權錯誤」或「權限正確但結果異常」的問題。日誌本身同樣需要訪問控制，不能因為審計而擴大敏感資料暴露面。

4. 權限驗收不能只測正常查詢

測試集應專門覆蓋越權路徑：使用者猜測未授權欄位時是否被攔截，跨租戶條件是否無法成立，利用 JOIN 是否能夠繞過行級限制，拆分篩選或改變聚合維度後是否會洩露小群體資訊。還要驗證模型輸出中出現危險語句、未授權表名和外部函式時，系統是在執行前拒絕，而不是依賴資料庫報錯兜底。

判斷 Text2SQL 是否可上線，關鍵不是模型「知道多少表」，而是系統能否穩定地把「模型可見範圍」和「使用者可執行範圍」分開管理，並讓後者成為不可繞過的工程約束。

四、SQL 校驗與執行安全：生成出來不等於可以執行

Text2SQL 的安全邊界不能建立在「資料庫會報錯」之上。資料庫只能識別部分語法、對象和型別問題，無法判斷查詢口徑是否正確、使用者是否應當獲得結果，也不會主動阻止一條合法但代價過高的查詢。工程上應在執行入口前設定必要的串聯校驗；任一環節未通過，SQL 都不進入正式執行環境。

其中最容易被低估的是語義校驗。SQL 可以成功執行，卻仍然回答錯問題。多表查詢尤其需要核對關聯路徑是否在治理規則允許的範圍內，篩選條件能否正確作用到相關表，以及一對多連接是否放大了聚合結果。對計數、去重和比率類指標，還應檢查分母範圍、去重鍵與聚合粒度，避免出現語法正確但重複統計的結果。

風險控制不宜只依賴關鍵詞過濾。系統應解析語句結構，識別寫操作、缺少有效約束的大表查詢、笛卡爾積、高成本巢狀以及可能產生過量返回資料的請求。執行側再配置超時、返回行數、掃描規模和修訂次數的上限。閾值應按資料平台能力和業務場景設定，不應由模型臨時決定。

正式執行前，可以先獲取執行計劃，或在隔離環境中進行試執行。檢查重點不是「能不能跑」，而是訪問了哪些對象、採用何種連接方式、預計掃描多大範圍，以及是否觸發資源限制。對於動態 SQL 或執行計劃難以可靠評估的查詢，應優先進入沙箱，而不是直接提交到生產資料庫。

修訂代理適合處理引號、對象名稱和欄位型別等可由資料庫錯誤明確定位的問題。它不應藉助報錯無限循環，也不應擅自改變指標定義、連接關係或篩選範圍。每輪修訂都要受次數上限約束，並保留 SQL 版本、修改原因、校驗結果與執行狀態，形成可複核的過程鏈。

失敗處理同樣屬於產品能力。系統應區分語法失敗、權限拒絕、口徑不清和資源超限，並向用戶說明可採取的下一步：補充時間或範圍條件、選擇明確指標、縮小資料規模，或者轉交人工分析。可靠的 Text2SQL 不是保證每次都生成可執行語句，而是在無法確認正確性與安全性時明確停止。

五、口徑治理：先解決「查什麼」，再解決「怎麼寫 SQL」

一條 SQL 可以通過語法檢查、正常執行，卻仍然回答錯問題。原因通常不在查詢語句本身，而在業務概念沒有被明確。

因此，Text2SQL 不宜直接從使用者問題跳到資料庫結構。中間需要建立可治理的指標語義，將業務概念轉換為確定的計算約束。模型應優先檢索這層定義，再選擇欄位並組織 SQL；只有語義層沒有覆蓋時，才考慮從表結構和欄位描述中推斷。

指標定義之外，還要處理自然語言與資料庫取值之間的差異。工程上可維護業務術語表、標準列舉及欄位取值對映，再通過 Schema Linking 把問題中的詞語連接到候選表、欄位和具體值。這樣既能減少模型猜測，也能只提供與當前問題相關的資料庫上下文。

多表查詢還需要單獨治理關聯關係。欄位同名不代表可以連接，名稱相似也不能證明業務含義一致。系統可維護經過確認的關聯路徑，記錄主資料標識、關聯方向、基數特徵和結果去重方式。生成 SQL 時優先使用已登記路徑；找不到可信關係時，應停止自動拼接並轉入澄清或人工確認，而不是讓模型根據列名自行補全 JOIN。

澄清機制是口徑治理的一部分，不應被當作互動上的補丁。若問題沒有說明日期區間、彙總層次或必要篩選項，直接採用隱含預設值會讓結果看似合理，卻難以審計。較穩妥的鏈路是先判斷資訊是否足夠，再提出針對性問題，待使用者確認後才進入 SQL 生成。澄清判斷與語句生成分開處理，也更便於分別測試：前者檢查是否識別歧義，後者檢查是否忠實執行已確認的口徑。

驗收語義層時，不要只驗證 SQL 是否執行成功。更有效的檢查方式是選取同一業務概念的多種問法，確認它們能否落到同一版本的指標定義；再對容易混淆的時間、區域、使用者狀態和去重規則做反例測試。只有系統能夠說明採用了哪項定義、哪些過濾條件以及哪條關聯路徑，查數結果才具備複核基礎。

六、上線驗收：用真實業務問題證明結果可靠

Text2SQL 驗收不能等同於模型跑分。公開資料集適合比較基礎能力，卻無法覆蓋企業內部的指標口徑、權限邊界和資料品質問題。

每道題都要有可複核的基準。基準可以是經審核的 SQL，也可以是固定資料快照下的預期結果；涉及經營指標時，還需記錄定義、統計週期、過濾條件和適用組織。只有答案而沒有口徑，資料變化後便難以判斷偏差來自模型、資料還是業務定義。題目、基準和所依賴的資料版本應一併管理，避免評測結果失去可重複性。

所有指標都應明確分母和失敗歸類。例如，SQL 因權限策略被拒絕，不應直接計入生成錯誤；使用者問題本身缺少時間範圍，也不宜按結果錯誤處理。驗收報告應按業務域、查詢複雜度和風險等級拆分，否則總體平均值會掩蓋局部不可用的問題。

魯棒性測試要主動製造異常，而不是等待生產環境暴露。測試輸入可加入近義說法、輸入錯誤和條件缺失；資料側應覆蓋時間臨界點、無匹配記錄及重複行；安全與執行側則應模擬租戶隔離、越權請求、大範圍掃描和資料庫異常。每類失敗都要驗證系統是拒絕、澄清、降級還是轉交人工，並檢查返回資訊是否洩露表結構或敏感內容。

放量範圍應由驗收結果決定，不以單一準確率作為上線開關。查詢風險較高時，介面應保留生成 SQL、指標定義和關鍵過濾條件，並在執行或交付結果前加入人工確認。複雜推理能力可以通過候選生成等方法改善，但不能替代權限檢查、查詢約束和業務複核。

驗收集也不是上線前的一次性材料。生產執行後，應持續歸集使用者改寫的 SQL、負面回饋、失敗日誌以及反覆出現的澄清請求，經脫敏和審核後補充到評測集，並同步修訂指標詞典、參考示例與校驗規則。每次模型、提示詞、Schema 或口徑變更，都應迴歸同一批核心問題，確認品質提升沒有以安全性或穩定性下降為代價。

七、FAQ：企業落地 Text2SQL 前常見的問題

企業是否應該直接讓大模型連接生產資料庫？

不建議把資料庫憑據交給模型，也不應讓模型繞過現有的資料訪問體系直接執行任意 SQL。模型適合完成意圖解析、資料對象匹配和查詢草案生成，真正的訪問決策與執行應留在可控制的服務鏈路中。

更穩妥的架構是在模型與資料庫之間設定執行層：模型只接觸完成任務所需的後設資料；執行層根據當前使用者的權限處理查詢，攔截寫操作、越權訪問與高風險語句，並對執行時間、掃描範圍和返回規模進行約束。對於生產環境，是否允許查詢還應取決於資料敏感性和資料庫承載能力，而不是取決於模型「認為這條 SQL 沒問題」。

技術選型時，應重點確認模型是否支援受控的上下文注入、結構化輸出和穩定的工具呼叫。單次生成效果只是基礎條件，無法替代訪問控制與執行隔離。

Text2SQL 的準確率達到多少才適合上線？

不存在一個適用於所有企業的統一百分比。離線測試中的平均正確率，無法直接回答系統能否進入業務環境。企業更需要判斷：錯誤發生在哪些問題上，錯誤能否被識別，以及錯誤結果會造成什麼後果。

驗收集應來自真實業務提問，並保留問題對應的統計口徑、期望結果和可接受偏差。評估不能只看 SQL 是否與參考答案一致，還要檢查查詢結果、資料範圍、指標定義和權限處理。兩條寫法不同的 SQL 可能返回相同結果；一條可以正常執行的 SQL，也可能回答了另一個問題。

上線判斷應按場景進行。對錯誤成本較低、答案容易複核的查詢，可以採用提示使用者確認或展示計算依據的方式開放；涉及經營決策、敏感資訊或不可逆操作的場景，則需要更嚴格的人工複核與拒答機制。關鍵不是追求一個好看的總分，而是讓系統知道何時不能回答。

為什麼 SQL 能執行成功，查詢結果仍然可能是錯的？

資料庫執行成功只能證明語句符合語法，並且引用的對象在當前環境中可訪問，不能證明它正確理解了業務問題。常見偏差來自指標含義、時間範圍、資料版本和關聯關係。

表關聯同樣可能引入重複行，空值處理、退款狀態和歷史快照也會改變最終結果。

因此，Text2SQL 不能只依賴表名與欄位名。企業需要把指標定義、適用範圍、資料來源和計算規則整理為機器可檢索的語義資訊，並讓結果頁能夠說明本次查詢採用了什麼口徑。發現歧義時，系統應先追問，而不是自行補全業務假設。

哪些企業暫時不適合落地 Text2SQL？

如果同一指標在不同部門存在長期爭議，核心表缺少明確負責人，欄位含義依賴少數員工口頭解釋，或者現有權限無法對映到查詢執行鏈路，直接上線 Text2SQL 往往只會放大已有的資料問題。

另一個需要謹慎的情況是，業務方無法提供代表性的真實問題，也沒有人員負責核對答案。缺少驗收基準時，團隊只能評價生成的 SQL 「看起來是否合理」，無法證明結果是否可用。

這並不意味著必須先完成全面的資料治理。更可行的判斷方法是選擇邊界清楚、口徑已有共識且能夠人工複核的範圍進行驗證；如果連這一範圍也無法確定，應先補齊資料目錄、指標定義、權限規則和責任歸屬。Text2SQL 的核心交付物不是一個大模型介面，而是一條可約束、可解釋、可驗收的資料產品鏈路。