目錄
- Agenda：語言、compiler、兩組評估
- answer 與 summary 是語言邊界
- Compiler 決定它是否可用
- Lecture 6 留下的缺口
- summary 與 answer 的語意
- Semantic parser 要學的是新 target language
- Compiler optimization 的三個核心動作
- Optimizer 也必須保留語意
- 餐廳應用怎麼做 end-to-end evaluation
- HybridQA 測的是跨 representation composition
- 自己做最小 SUQL prototype
- 評估分兩個世界
- 動手讀法
- 材料缺口
- 參考資料
本文依據官方 Fall 2025 講義重建本講；下文的系統設計與講義所報結果，除非在主張處另連原論文，均歸屬這份歷史課程材料。
第七講承接前一堂的混合資料問題：SQL 擅長型別、篩選、排序與聚合，文字檢索擅長從評論或介紹裡找語意。如果先各自回答再叫 LLM 合併，最佳化與可追蹤性都會斷掉。SUQL 的選擇是設計一個高階語言同時表達兩者。
Agenda：語言、compiler、兩組評估
講義依序說明 SUQL 的設計理由與自由文字支援、semantic parser 與 compiler，然後在 Yelp 型餐廳應用評估，最後用 HybridQA 檢查表格與文字跨跳問題。 (講義來源)
answer 與 summary 是語言邊界
SUQL 保留 SQL 結構，另外讓查詢對文字欄位呼叫 answer(text, question) 或 summary(text)。於是「找 Palo Alto、評論提到適合約會的日本餐廳，並摘要評論」可以在同一個查詢中保留結構化條件與文字判斷。 (講義來源)
這比直接讓 LLM 回答多一層契約：semantic parser 的輸出可被解析，資料庫欄位與自由文字問題各自清楚；查錯結果時，也能判斷是 parse、資料列選擇，還是 answer 函式出錯。
Compiler 決定它是否可用
天真執行會對每一列都呼叫 LLM，成本與延遲無法接受。講義的 optimizing compiler 先執行便宜的 SQL predicates，只把必要的 top results 送入文字函式，並採 lazy evaluation：結果沒有被後續條件或輸出需要時就不求值。中間結果可放進暫存表，讓既有 SQL 引擎執行大部分工作。 (講義來源)
Lecture 6 留下的缺口
前一講的 database agent 可以把結構化問題轉成 SQL，也能把純文字問題送到 IR pipeline；困難是同一句同時含兩種條件。若先跑 SQL、把 rows 轉成文字再問 LLM，query optimizer 看不到文字條件；若先全文檢索，則可能丟掉 table 中的精確 filter、join 與 ordering。 (講義來源)
SUQL 把這個缺口定義成 language-design problem。使用者仍說自然語言，semantic parser 卻不是選 SQL 或 RAG，而是產生同時含 relational operators 與 free-text functions 的單一 program。Executor 因而知道哪些步驟可由 DB 完成、哪些必須呼叫語言模型。
這個選擇也讓 agent architecture 保持簡單。Agent 不需在每一步自由選工具；parser 一次表達計畫，compiler 依 cost 與 dependency 安排執行。它犧牲任意工具探索，換取 query 可重跑、可 inspect 與可 optimize。
summary 與 answer 的語意
summary(text_column) 對選定 rows 的文字內容產生摘要，適合把多則評論壓成可讀輸出。answer(text_column, question) 則把文字當作可查詢資料，回傳針對問題的值。後者不只用在 SELECT；講義例子把 answer 結果放進 WHERE、ORDER BY 與比較，讓從文字抽出的資訊參與 relational computation。 (講義來源)
例如 table 有 event year 與一欄描述性 passage，問題問「在 Rio 舉行的 Olympic event 名稱」。SUQL 可對 passage 問地點，再用回傳值篩 rows。另一題比較兩屆旗手年齡，則先從文字抽生日、cast 成 date，再排序。這些 table-to-passage-to-table hops 若改成聊天式 tool loop，很難保證每一步使用相同 rows。
Free-text function 的輸出型別很重要。若 answer 永遠回自然語言字串，日期與數值比較會脆弱；query 應指定或推斷 cast，compiler 也要處理 parse failure 與 unknown。語言把 LLM output 放進 SQL，不代表它自動取得 SQL 的確定性。
Semantic parser 要學的是新 target language
Parser prompt 包含 DB schema、SUQL constructs 與 examples。它需要判斷哪個條件能用 SQL，哪個必須讀 text column，以及兩者的 dependency。把所有條件都丟給 answer 雖然可能跑得動，卻失去精確性與最佳化；把文字語意硬寫成 LIKE 則會漏同義表達。 (講義來源)
Evaluation 因此不能只看 syntax validity。要檢查 operator placement、column selection、question passed to free-text function、casts 與 aggregation。Parser 產生錯誤 SUQL 時，compiler 可能仍成功執行並回 plausible rows，這比 syntax error 更難發現。
講義的 real-life restaurant examples 特別測 popular dishes、reviews、location 與 structured filters 的邊界。Error analysis 顯示某些資訊存放位置與使用者直覺不同：菜名可能只在 reviews，不在 popular-dishes 欄。Schema description 必須說清楚資料分布，或讓 parser 在空結果後診斷 column choice。
Compiler optimization 的三個核心動作
第一是 predicate pushdown。City、price、rating 等 SQL conditions 應先縮小 rows，再呼叫昂貴的 answer。若順序反過來，模型會讀全表文字。這跟資料庫傳統 optimizer 相同，只是 cost difference 更大，因為一次 LLM call 遠高於 scalar comparison。 (講義來源)
第二是只回傳必要 results。Text function 的 context 有上限，最終 response 也不需要成千 rows；compiler 應依 query semantics 做 top-k、limit 與 projection，避免把不使用的 columns 傳給模型。這同時降低 cost、noise 與資料暴露。
第三是 lazy evaluation。answer 或 summary 只有在 row 通過其他條件、且其值真的用於 output/condition 時才執行。Compiler 可先把 SQL-compatible fragments 跑完，把中間 rows 放 temporary table，再逐步 materialize free-text results。講義強調 SQL engine 不需修改，外部 functions 與 compiler rewrite 承擔整合。
Optimizer 也必須保留語意
把 predicate 移動到 text function 前後不一定等價。若 summary 要涵蓋所有 reviews，先 top-k 可能改變摘要；若 ordering 依 answer 結果，太早 limit 會漏掉真正最高值。Compiler 必須理解 dependency，而不是一律「SQL 先、LLM 後」。 (講義來源)
Free-text function 非決定性也影響 caching。相同 input、model 與 prompt version 才能安全重用；來源文字更新時 cache 要失效。Temporary table 若保存 LLM-derived values，trace 應記錄生成版本，否則之後重跑 query 得到不同結果卻無法解釋。
Optimization 的 evaluation 要同時報 answer quality、model calls、tokens、latency 與 rows processed。只說準確率提高，無法證明 compiler 的價值；只說 calls 減少，也可能是因為錯誤丟掉 evidence。Lecture 把語言設計與 compiler 放在同一講，正是因為兩者不能分開判斷。
餐廳應用怎麼做 end-to-end evaluation
本文建議： 以下是依本講方法延伸的實作或檢核方式，不是投影片所報研究結果。
真實 app 的 schema 固定但語句開放，適合測 semantic parsing 與 result precision。講義不只比較 final answer，也看 query 是否找對餐廳、response 是否使用正確 results。No-result 案例再回頭檢查 parser：錯欄、錯 enum 或文字資訊其實在另一欄。
Baseline 可以是 SQL-only agent、RAG over flattened records 或 agentic tool use。公平比較需要相同資料與相同 base model，並揭露 flattened representation 是否丟掉 types。SUQL 的 claim 應限於「這種 query language 對混合操作的表達與最佳化」，不是所有對話任務都優於 agent。
人類 spot check 仍不可少。SUQL query 看似複雜，錯一個 free-text question 就可能回合理但不符合使用者條件的 rows。Reviewer 應同時看 NL、predicted SUQL、intermediate function outputs 與 final results。
HybridQA 測的是跨 representation composition
HybridQA 每題帶 table schema 與相關 passages，題型包含 table-to-passage、passage-to-table 與多 hop comparison。SUQL 把 passage 放進 text-array columns，讓 answer 的輸出可以被 relational operators 使用。這是一個 controlled benchmark，跟任意 web QA 不同。 (講義來源)
講義把多種問題並列，顯示同一語言能表達 filter、superlative、cell-to-passage hop 與跨年份比較。Language coverage 是重要結果，但仍要分 parser error 與 execution error。Gold SUQL 能答對、predicted SUQL 答錯，問題在 parser；連 gold program 都無法表達，才是 language limitation。
Dataset 每題自己的 schema 也測 schema generalization。Parser 不能只背餐廳欄名，要讀新 table definition 並正確選 textual fields。這比在單一 production DB 上高 accuracy 更接近「高階 query language」的泛化 claim。
自己做最小 SUQL prototype
本文建議： 以下是依本講方法延伸的實作或檢核方式，不是投影片所報研究結果。
先不要發明完整 grammar。用 SQLite table 加兩個 deterministic mock functions：answer 從標註 JSON 取值、summary 回固定摘要。手寫十條 hybrid queries，確認 SQL filtering、function dependency、casts 與 ordering semantics。這一步測 language，不讓 LLM noise 混進來。
第二步接 semantic parser，用 gold programs 做 execution comparison；第三步才換成真實 text model，另外評 function accuracy。最後加 compiler optimization，逐 query 記錄原始 rows、pushdown 後 rows、function calls 與 result equivalence。每加一層都保留前一層 tests。
本文延伸： Production 使用時還要加 query sandbox、PII column policy、timeout、token budget 與 provenance。answer 能讀文字欄不代表每個欄都可以送到外部模型。Compiler 正好是集中執行這些 policy 的位置。
評估分兩個世界
餐廳應用測真實 schema 上的 semantic parsing、結果 precision 與 end-to-end 回應，也專門檢查 parser 錯誤造成的假空結果。HybridQA 則含 table-to-passage、passage-to-table 與多步組合；SUQL 需要把文字欄位的答案當成可篩選、排序或比較的值。 (講義來源)
評估語言設計不能只看答案分數。還要問：同一查詢能不能清楚表達、compiler 是否少做不必要的 LLM calls、錯誤是否能定位。這也是 SUQL 相對「agent 自己決定下一個工具」的核心取捨。
動手讀法
本文建議： 以下是依本講方法延伸的實作或檢核方式，不是投影片所報研究結果。
挑一個含產品規格欄與評論欄的資料表，寫三題：純 SQL、純文字、兩者混合。先手寫 SUQL，再估算天真執行會呼叫幾次文字函式；加入 SQL pre-filter 與 lazy evaluation 後再算一次。
材料缺口
本文建議： 以下是依本講方法延伸的實作或檢核方式，不是投影片所報研究結果。
投影片展示語法片段與 compiler 策略，不是完整 grammar 或穩定 API 文件；表格中的實驗摘要也不能取代論文方法與程式碼。本文不推測課堂 quiz 的未公開答案。
參考資料
Loading...