當資料表大到無法每次都對完整 production 資料庫執行——成本、延遲、權限、安全都卡——傳統 EX 失靈。本文整理學界、開源專案與大科技公司在這種情境下的實務作法。
Execution Accuracy 的標準做法：把 predicted SQL 與 gold SQL 都對同一個資料庫執行，比對結果集是否一致。在 Spider 1.0 這種小型乾淨 SQLite（平均不到 10 張表）沒問題，但在企業情境會撞牆。
對 TB 級的 BigQuery / Snowflake 倉儲反覆跑 query，又慢又貴。Spider 2.0 的 gold query 常超過 100 行。
Production 含 PII / 機敏資料，eval pipeline 不一定能直接連線執行。
私有資料、跨系統 workflow，在 eval 時根本無法重建。
在固定資料內容上比結果，語意不同的 query 可能巧合回傳相同結果（false pass），或語意相同卻因資料差異 false fail。
具體數字：原始 Spider metric 在固定資料庫上比對，平均有約 2.5% 的 false negative rate，最差情況達 8.1%。這正是「單一資料庫執行比對」不可靠的證據。
因此業界與學界發展出四條主線，核心精神都是「不要放棄執行，而是把執行縮小」：
不要在一個大資料庫上比結果，而是蒸餾出一小組「小而高 code coverage」的資料庫。
方法核心：從大量隨機產生的資料庫中，挑出能讓 gold query 達到高 code coverage 的最小子集，evaluation 時只在這個 distilled test suite 上比對 denotation（結果），即可算出語意正確率的一個緊上界（tight upper-bound），而且效率極高。作者用此法評測 Spider leaderboard 上 21 個模型，並人工驗證 100 個案例皆正確。
對 gold query 做微擾——例如 > 34 vs >= 34 vs > 35——產生語意相近但不同的 query。
產生許多 random databases，目標是找出能「區分 gold 與這些 neighbor」的資料內容。
挑出讓 gold query 達高 code coverage 的最小資料庫組，即 distilled test suite。
predicted query 只在這個小 suite 上跑並比對結果——執行成本被壓到極低，同時大幅降低 false pass / false fail。
為什麼解決「大表」：你不需要在原始大資料庫上跑，而是在「特製的小資料庫」上跑。已成為 Spider、SParC、CoSQL 的官方 metric，並涵蓋 Academic、ATIS、Advising、Geography、IMDB、Restaurants、Scholar、Yelp 共 11 個資料集。
Zhong, Yu, Klein · Semantic Evaluation for Text-to-SQL with Distilled Test Suites · EMNLP 2020 · arXiv:2010.02840
直接面對「真實企業大資料庫」：632 個來自真實資料應用的 workflow 問題，資料庫常超過 1,000 欄（極端可達 3,000+ 欄），跑在 BigQuery、Snowflake 等雲端系統上。它在「大到無法隨便跑」這件事上提供了關鍵工程設計：
spider2-lite / spider2-snow 做 benchmarking；另有 spider2-dbt（68 tasks）做 repository-level 的快速 benchmark。Lei et al. · Spider 2.0 · ICLR 2025 Oral · arXiv:2411.07763
主要是生成方法，但其評測觀念對「大表」很有用：用執行層級的等價（execution-level equivalence）而非結構比對判斷兩 query 是否相同，並引入 exact 與 approximate execution-based similarity，以 Minimum Bayes Risk（MBR）decoding 框架做理論支撐。
Borchmann & Wydmuch · Query and Conquer · Snowflake AI Research 2025 · arXiv:2503.24364
對結果集做部分配分——計算 predicted 與 gold 結果的重疊。100 列中對 99 列，Soft-F1 給高分而 EX 直接給 0。適合「能跑但結果未必完全相同」時提供細緻訊號與除錯依據。
當執行根本不可能（私有資料缺失、環境錯誤），用強力 LLM 比較 predicted 與 gold SQL 的語意邏輯。客觀性低於執行，但與人類判斷相關性高。
現實落差：Spider leaderboard EX 從 2023/03 的 ~40% 升到 2025/04 的 ~76%；但在 Spider 2.0 上，2025/04 最佳模型 EX 僅約 31%；Uber 自家 eval set 上與 ground-truth 表的重疊也僅約 50%。大型 schema 與語意歧義是核心挑戰。
Text-to-SQL for Enterprise Data Analytics · 2025 · arXiv:2507.14372
| 專案 | 用途 | 連結 |
|---|---|---|
| taoyds/test-suite-sql-eval | Test-Suite Accuracy 官方評測程式，涵蓋 11 個任務；Spider / SParC / CoSQL 官方 metric。 | github |
| ruiqi-zhong/TestSuiteEval | 產生 neighbor queries 與 random databases（fuzzing + distillation）的程式，搭配上者使用。 | github |
| xlang-ai/Spider2 | Spider 2.0 官方 repo：Spider-Agent 框架、lite/snow/dbt 設定、oracle ground-truth tables、免 Docker 快速 benchmark。 | github |
| RelationalAI/xlang-spider2 | Spider 2.0 fork，含 BigQuery / Snowflake 存取設定指南。 | github |
直接用 test-suite-sql-eval 蒸餾出小 test suite，把執行成本壓到最低。
參考 Spider 2.0 的 oracle tables 模式，只在 gold query 用到的表上執行；agent 設定可參考 spider-agent-lite / snow。
退回 Soft-F1（若能取得結果集樣本）或 LLM-as-Judge（純比語意）。
Uber 的 SQL 每天要在 TB 級資料上跑，因此 eval 不依賴對完整資料庫逐列比對結果集，而是建一套標準化評測程序：
另見 Uber 的 Prompt Engineering Toolkit：內建 LLM-as-Judge 與 code-based evaluator，並設「通過 eval threshold 才能上 production」的 gatekeeping。
QueryGPT (2024) · Prompt Engineering Toolkit (2024)
LinkedIn 建了客製化 benchmark 框架：用量身打造的 eval set、明確 metric、與人類＋LLM 共同評審（human-plus-LLM judging）來維持準確率、降低幻覺，並把 benchmarking 當成整合進產品開發的持續流程而非一次性任務。本質上避開「對 production 大表逐列比對」的成本——用人＋LLM 對語意與相關性評分。
LinkedIn Engineering · SQL Bot（轉述見 Rincón Herrera, 2025）
Pinterest 的關鍵啟發：把 table retrieval（找對表）這個元件單獨評測，用過往 table search 的 offline 資料，先確保 embedding-based table search 不比舊的 text-based search 差——也就是把「找對 schema 子集」當成可獨立評測的子問題。整體 Text-to-SQL 的初期評測主要拿來對齊文獻數字（在 Spider 上驗證實作），而非在自家大資料上做 result-level EX。
How we built Text-to-SQL at Pinterest (2024)
第三方評測指出：除了 EX，還可加上 Efficiency——query 是否對倉儲架構最佳化（join order、是否用到 Snowflake 特定優化）。對大倉儲而言，效率本身就是一個要評的維度，因功能正確但低效的 query 會吃光資源。對應到學界的 Valid Efficiency Score（VES）：評正確性的同時衡量執行效率。
資料庫能在 eval 時重建嗎？
├─ 能，且不大 → 標準 EX + Test-Suite Accuracy（蒸餾小 test suite）
├─ 能，但很大（TB 級雲倉） → Oracle / ground-truth tables 子集執行（Spider 2.0 模式）
│ + Efficiency / VES 一併評
└─ 不能（私有 / 無環境）
├─ 拿得到結果集樣本 → Soft-F1（部分配分）
├─ 只能比 query 本身 → LLM-as-Judge（語意比對）+ schema overlap proxy
└─ production 線上監控 → 人＋LLM 評審 + golden set + 多訊號 proxy（Uber / LinkedIn 模式）一句話總結：「大表無法隨意執行」時，共識不是「放棄執行」，而是把執行縮小——縮小資料（distilled test suite）、縮小 schema（oracle / relevant tables）、或縮小到語意層（LLM-judge / schema-overlap proxy），再搭配人＋LLM 評審與 golden set 在 production 持續監控。