廠商告訴你，他們的 Text-to-SQL 系統「準確率 95%」。支撐這個數字的論文說的也是 95%。系統上線後，財務經理問「剔除內部交易後的淨銷售額」，SQL 自信滿滿地錯了。廠商和論文都沒撒謊——撒謊的是那個前提：那個資料集，長得和您的數倉一點也不像。
公開基準到底在測什麼
每家廠商的 PPT 上都是那兩個基準。搞清楚它們測什麼、不測什麼，是正確解讀 Text-to-SQL 宣傳口徑的最快途徑。
Spider（2018，耶魯大學）是被引用最多的。約 10,000 個問題、200 張表、138 個領域，且查詢設計成從表結構即可回答。它的繼任者 Spider 2.0（2024）釋出的原因很直白：原版已經被「做穿了」——模型在 Spider 1.0 上超過 90%，而包含真實企業 SQL 方言、超長上下文和多步分析的 Spider 2.0，最強系統初期得分不到 25%。版本之間這個斷崖，是全領域最有教育意義的一個資料點。
BIRD（2023）的構建初衷正是彌合學術查詢與混亂現實之間的差距：更大的資料庫、真實資料值、需要外部知識或領域推理的問題，由香港的學術團隊構建。它把 2023 年的榜單重置到 50–60% 區間；到 2025–2026 年，頭部系統借提示詞工程管線和微調開源模型，已把執行準確率推到 70–80% 以上。
兩者都是嚴肅、精心構建的資料集。它們能證明的，誠實地總結如下：
| 維度 | Spider 1.0（2018） | Spider 2.0（2024） | BIRD（2023） | 典型企業數倉 |
|---|---|---|---|---|
| 表結構規模 | 5–40 張表 | 數百張 | 數十至數百張 | 300–1,000+ 張 |
| 表結構衛生度 | 乾淨、有文件、單領域 | 真實方言、長上下文 | 真實值、少量噪聲 | 十年累積的命名、三種並存的幣種 |
| 問題風格 | 自包含、無歧義 | 多步驟、需探索 | 需領域知識 | 需要內部黑話解碼 |
| 資料歸屬 | 公開、靜態 | 公開、靜態 | 公開、靜態 | 私有、變動、有許可權 |
| 最優模型準確率（2025–2026，約值） | 90%+ | 約 40–60%，持續爬升 | 70–80%+ | 無人公開；從業者反饋 60–90%，取決於治理 |
最後一行才是重點。不存在針對您數倉的公開基準，而公開分數的可遷移性，每向企業現實靠近一步就衰減一分。
基準沒有告訴您的五件事
一、表結構的髒亂差
基準隨附的表結構乾淨又體面。您的數倉裡有一張叫 tbl_sal_sum_v3_final 的表，和一個叫 amt 的欄位——含義在 2021 年變過。同一位客戶因為 CRM 遷移存在四個主鍵下；收入按三種幣種入賬且沒有統一的換算日期；緩慢變化維讓「截至去年三月」成為一個真正有難度的問題。現實中 Text-to-SQL 的準確率，不取決於模型的 SQL 功力，而取決於系統能在多大程度上與這些髒亂差隔離開。每個嚴肅的部署，投在模型周圍那幾層——精選表集、經過測試的指標定義——的精力，都超過投在模型本身的。
二、業務黑話
基準問題是由看得見表結構的人寫的。您的業務使用者問的是「剔除已取消未發貨訂單的 GMV」「華南大區」（而在您的組織樹裡，自 2023 年組織調整後華南大區對應的門店每年都不同）、「活躍經銷商」——這個術語有三種互相打架的定義，從未對齊。模型不可能從表結構文件裡把這套詞彙對映到欄位上，因為對映根本不在表結構裡。它在機構記憶裡——通常只存在三個分析師的腦子裡。一個沒學過您家黑話的 NL-to-SQL 系統，不是「略有降級」，而是「在回答另一個問題」。
三、許可權與可見性
基準只有一個隱含使用者：全知全能。而企業裡有不該看到其他門店的店長、有 cleared 給總賬但看不到 HR 表的財務分析師、有上季度剛調整過管轄範圍的區域總監。生產環境的查詢生成不是「對著數倉寫 SQL」，而是「對著這個身份、此刻可見的那一片數倉寫 SQL」。這是一個本質不同的問題——一半是 SQL 生成，一半是執行時的訪問控制——公開基準對此完全不設考題。一個無視許可權、得分 85% 的系統，在企業裡不是 85% 準確；它是一條包裝精美的資料洩漏通道。
四、錯誤的代價不對稱
在基準上，一條錯誤查詢扣一分。在董事會上，一個錯誤數字賠上的是信任——以及（按高管的真實行為模式）整個分析專案。錯誤也分輕重：一個幻覺 JOIN 靜默把收入翻倍統計，比一句優雅的「答不了」糟糕得多，但執行準確率評分把兩者記成同一種失敗。因此生產系統需要校準過的置信度、拒答行為和可回溯源行的引用鏈——這些統統不出現在基準評分裡。
五、語義漂移
數倉在系統腳下變化：表被改名、指標定義被修訂、源系統被遷移。基準是凍結的，您的表結構不是。系統需要持續執行的迴歸評測，而不是一次性認證。這是最少被討論、卻在運維上最重要的鴻溝：準確率不是系統的屬性，而是系統在某個時點、面對某個特定表結構的屬性。
為什麼「裸 LLM 寫 SQL」是錯誤的架構
上述失敗模式解釋了一件事：2023 年演示效果驚豔的「把前沿模型直接懟到表結構上」的做法，到 2025 年已經不再是被推薦的架構。裸 LLM SQL 要求模型同時幹四份活——理解業務語言、探索表結構、記住指標定義、寫出方言正確的 SQL——並且對每一份活都給出與其把握不成比例的自信。
生產系統收斂出的替代架構，是把問題拆開：
- 語義層。 業務術語與物理表結構之間的受治理對映——指標定義、維度慣例、黑話別名——把模型任務從「發現表結構」降級為「基於已知定義組裝受治理查詢」。在我們的部署中，這是最大的單一準確率槓桿，在真實企業表結構上通常值 15–25 個百分點的可用回答率（我們自己的測量，與從業者公開反饋的方向一致）。
- 相關表結構的檢索。 不把 400 張表塞進上下文，而是按問題檢索相關的 10–20 張表及其文件。上下文更小，幻覺 JOIN 更少。
- 查詢治理。 執行時強制繫結身份的行級、列級安全，查詢日誌、成本控制、只讀強制。這一層不提升準確率；它讓準確率可以安全地被使用。
- 評測體系。 一套私有評測集——100–300 道來自真實業務、帶驗證答案、覆蓋您家黑話和表結構怪癖的問題——在每次模型、提示詞或表結構變更後執行。這才是真正重要的基準，而且沒有人能替您建。
經濟學論證和技術論證同樣有力。前沿模型的 token 成本已大幅下降（斯坦福 AI Index，2025），開源權重模型在多數 SQL 生成負載上達到同等水平——單次查詢的邊際成本持續下探。不會下降的，是一個被決策者信任的錯誤數字的代價。因此架構應該把複雜度預算花在攔截和預防錯誤的層上，而不是花在從模型身上擠最後幾分準確率上。
應該向廠商索要哪些準確率數字
當廠商報出一個數字時，正確的反應不是爭論數字本身，而是問五個把它轉化為資訊的問題：
- 在什麼資料集上？ 2026 年，Spider 1.0 的分數已無意義——90%+ 只是及格線，不是差異化。BIRD 或 Spider 2.0 的分數資訊量更大；追問版本和測試日期。
- 執行準確率還是完全匹配？對照的基準答案如何驗證？ 執行準確率可能「錯得碰巧對」；完全匹配會把格式不同但正確的查詢判錯。要問清基準答案是怎麼驗證的。
- 歧義問題怎麼算？ 如果模型把「銷售額」解成 GMV，而分析師指的是淨收入，這算失敗嗎？成熟廠商會把拒答和澄清單獨計數，與錯誤分開報告。
- 許可權如何執行、如何測試？ 問清楚行級安全是否對每一次查詢在執行時強制生效，他們的評測裡有沒有許可權越界測試。如果評測只測 SQL 正確性，您買到的其實是一條未經審計的數倉訪問路徑。
- 願不願意在我們的資料上打分？ 唯一能預測您部署效果的基準，是從您的問題和表結構裡建出來的評測集。對語義層路線有信心的廠商，會同意在結構化試點裡用固定題集、公開打分——付費試點（我們的是兩週、HKD 25k / RMB 20k）正是幹這個用的。拒絕在您資料上打分的廠商，本身就是在告訴您答案。
按我們的部署經驗和從業者反饋交叉印證，在治理良好的前提下、面對髒亂的真實企業表結構，合理預期是：精選語義範圍內 85–95% 的可用回答率，對範圍外的問題選擇拒答而不是幻覺——而且這個拒答行為，反直覺地，恰恰是系統成熟的標誌。承諾在無約束數倉上做到 99% 的人，是在向您承諾一場 Demo。
真正決定上線準確率的因素
彙總我們和其他團隊的部署經驗，準確率槓桿的排序非常穩定，而且在外行看來近乎無聊：
| 排名 | 槓桿 | 典型影響（估算，出自我們的部署） | 投入 |
|---|---|---|---|
| 1 | 覆蓋業務核心表的語義層 | 可用回答率 +15–25 個百分點 | 數週；需要指標 owner |
| 2 | 基於真實黑話問題的私有評測集 | 不直接加分——讓準確率顯形，撬動其他一切槓桿 | 1–2 周搭建，持續維護 |
| 3 | 從查詢日誌持續維護的黑話/別名詞典 | 長期 +5–15 個百分點 | 持續，成本低 |
| 4 | 表結構治理（檢視、文件、下線舊錶） | +5–10 個百分點，複利式 | 持續，與 BI 團隊共擔 |
| 5 | 模型選擇（前沿 vs 開源、提示詞調優） | ±5 個百分點 | 季度複評 |
注意排名在最後的是什麼：一切與模型有關的東西。這是 2025–2026 年部署的一致發現，也與基準文獻自己的診斷吻合——Spider 2.0 的作者把低分更多歸因於「在不熟悉的真實環境中探索和推理」的困難，而不是 SQL 本身寫不出來。模型已經不是瓶頸；上下文和治理才是。
還有兩條組織層面的觀察值得補充。其一，上面每一個槓桿都需要具名責任人：語義層要有指標 owner，黑話詞典要有分析師從查詢日誌裡持續維護，表結構文件要有 BI 工程師負責。Text-to-SQL 準確率衰減，往往不是因為系統壞了，而是因為沒有人對系統所編碼的定義負責。其二，評測集會實實在在地改善分析職能的內部政治：當準確率每週在真實問題上打分，關於「AI 回答能不能信」的爭論，就變成了「第 37 題為什麼錯了、怎麼修」的具體工程討論——這是健康的對話，而不是彌散的焦慮。公佈分數的企業贏得信任；隱藏分數的企業收穫小道訊息。
對 IM 時代對話式 BI 的啟示
最後一塊拼圖：Text-to-SQL 準確率在當下不是更不重要了，而是更重要了，因為交付面變了。當分析長在企業微信、釘釘、飛書、WhatsApp 或 Teams 裡，一個錯誤答案不再是給一位能自查的分析師看——而是瞬間被整個群聊看到，還蓋著您公司的名字。IM 原生交付同時抬高了準確率門檻和失敗行為的要求（拒答、引用、轉人工）。
這就是為什麼把準確率當模型問題的對話式 BI 廠商會持續讓人失望，而把它當治理問題的廠商——語義層、許可權、評測、引用——其系統才能在企業裡活得下去。評估 IM 原生分析平臺時，Text-to-SQL 準確率這個問題本身是成立的，但正確的問法是：「在像我們這樣的資料、並執行我們許可權的前提下，你們的實測準確率是多少？系統對答不了的問題會怎麼處理？」
這個問題的健康答案可度量、樸素、且有架構背書。不健康的答案是一張榜單截圖。
給 CIO 的一頁評估清單
2026 年評估 Text-to-SQL 宣傳口徑，壓縮成一張實操清單：
- Spider 1.0 分數直接忽略。 要 BIRD 或 Spider 2.0 結果（附日期），或與您類似的表結構上的分數。
- 要求具備拒答行為。 對超綱問題，系統必須回答「受治理資料範圍內答不了」——用陷阱問題顯式測試。
- 對抗性測試許可權。 試點期間安排低許可權使用者想辦法問出受限資料。任何一次得手即一票否決。
- 檢查引用鏈。 每個數字都應能回溯到源行，與數倉核對。
- 評測集建在試點之前，不是之後。 100–200 道帶驗證答案的真實問題，向您的黑話傾斜。每週打分，內部公佈。
- 測試表結構變更的應對。 試點中途給一張表改名，看會發生什麼——答案會告訴您系統背後是治理層，還是僅僅一段提示詞。
- 為無聊的層做預算。 如果報價單上的科目全是模型相關的，而沒有語義層和評測的科目，90 天后的準確率曲線會讓您失望。
2026 年對 Text-to-SQL 的成熟立場，既不是懷疑也不是狂熱。這項能力是真實的，而且在快速進步——基準文獻記錄了貨真價實的進展。但上線準確率是造出來的，不是買來的：它來自編碼了術語含義的語義層、決定每個身份能看什麼的許可權、每週向您說真話的評測集，以及一個把拒答做成工程能力而非尷尬的交付面。能向您展示這四樣東西的廠商，值得您的試點；只會展示榜單截圖的廠商，值得您的懷疑。
