從多語言企業資料管線中自動抽取 schema lineage，並用一個可拆解的複合指標同時衡量「結構正確」與「語意忠實」。1,700 筆人工標註、12 個語言模型、50,000+ 次抽取實驗。
企業資料倉儲最初都有完整的 metadata：schema 定義、欄位語意、business context。但資料一旦流經多階段、跨語言的處理管線，這份 metadata 就迅速失效。
論文把這個現象命名為 semantic drift（語意漂移，引用 Müller & Stein 2016）。實務上的樣貌是：一個 dashboard 上的 MAU、churn rate、revenue 指標，沒有人能準確說出它究竟從哪些原始欄位、經過哪些轉換與聚合而來。知識只存在於少數寫過那段 pipeline 的工程師腦中，或散落在過期的手工文件裡。
為什麼這件事在 LLM 時代更要緊：semantic drift 直接傷害兩個下游應用 —— RAG（知識庫裡的 schema 描述是錯的，檢索出來的 context 就是錯的）與 text-to-SQL（模型不知道欄位真正的語意，就會生出語法對、語意錯的 SQL）。這是本篇把 lineage 抽取當成「AI 基礎建設問題」而非「資料治理問題」來寫的原因。
論文在 Related Work 把前人方法分兩類，並各自指出斷點：
sqlparse、sqlfluff、Purview）：在單一語言、靜態環境可靠，但面對多階段跨語言管線就崩潰，而且每次 codebase 演進都要重寫規則。本篇的定位是 no-fine-tuning paradigm：一次 query 同時生出 table-level 與 operation-level lineage，且資料集是為「資料理解」而非「異常偵測」策展的。
針對多語言企業管線的 schema lineage 形式定義，涵蓋 source-to-output 語意、轉換邏輯與聚合。
50 支真實生產腳本、1,700 筆人工標註 lineage。
可拆解的複合評估框架，兼顧結構正確與語意忠實。
12 個語言模型 × 7 種 prompting 策略 × 6 個隨機種子。
論文把 schema lineage 定義成一個恰含四個 key 的結構化字典。這個「剛好四個 key」的設計不只是表示法，它同時是 evaluation 介面與 downstream parsing 介面。
任務設定：給定一支資料管線腳本 S（可能是 SQL、Python、PySpark、C# 的混合）與輸出表中的一個目標 schema σ，抽出對應的 lineage L。
lineage 起源的原始欄位。多個來源欄位以逗號分隔。
含有那些來源欄位的原始資料表，是資料的根源頭。
把來源欄位轉成目標 schema 的程式碼片段。多段轉換以 <CODEEND> 分隔。
GROUP BY / SUM / COUNT / MAX / MIN 及其 grouping key，同樣用 <CODEEND> 分隔。
設計要點：注意 lineage 追的是「一個欄位」而不是「一張表」。50 支腳本卻有 1,700 筆標註，就是因為每支腳本的輸出表有多個欄位，每個欄位各有一條獨立 lineage（平均 34 條／腳本）。
這是本篇最難複製、也最有價值的資產：全部來自 Microsoft 內部實際部署的生產管線，涵蓋 SQL、C#、Python（含 PySpark），用途橫跨 business metrics、marketing analytics、product insights、user experience。
論文用一個 0–3 分的三維度評分把腳本分級，每個維度符合就 +1 分：
存取 ≥ 3 個不同資料來源 → +1
存在轉換鏈（一個運算的輸出是另一個的輸入）→ +1
含任何聚合函數（SUM/COUNT/PIVOT）→ +1
總分 0–1 為 Easy、2 為 Medium、3 為 Hard。
| 難度 | 腳本數 | Token 平均 | Token 最小 | Token 最大 | Schema 總數 | Schema 平均 | Schema 最大 |
|---|---|---|---|---|---|---|---|
| All | 50 | 1,988.52 | 139 | 17,447 | 1,700 | 34.00 | 391 |
| Easy | 19 | 921.26 | 139 | 2,153 | 488 | 25.68 | 118 |
| Medium | 22 | 1,806.23 | 274 | 6,882 | 610 | 27.73 | 109 |
| Hard | 9 | 4,687.22 | 751 | 17,447 | 602 | 66.89 | 391 |
值得注意的分佈特性：Hard 只有 9 支腳本（18%），卻貢獻 602 筆 schema（35.4%），單支平均 66.89 個欄位、4,687 個 token，最長 17,447 token。也就是說 benchmark 的難度重心壓在少數幾支超長腳本上 —— 這既是它貼近真實的地方，也是 reviewer 會質疑 variance 的地方（見 §08）。
由於原始腳本含敏感商業邏輯，論文只在 Appendix A.2 放了一支合成的 hard 範例（PySpark clean_customers / clean_accounts / clean_transactions + SQL），保留原始的結構與邏輯特徵但抽換商業內容。多語言切換用 >>>>> 分隔符標記，lineage 追蹤採自底向上（bottom-up）traversal：從指定的目標欄位出發，沿計算圖往上游傳播。
另外，資料專家為每支腳本額外撰寫了人工 reasoning traces以支援 CoT prompting：easy 腳本 1 條、medium 2 條、hard 3 條。
論文的方法論核心。SLiCE 把「結構有效性」與「語意正確性」壓成 [0,1] 的單一分數，同時保留五個 component-level 診斷維度（format、source schema、tables、transformation、aggregation）。
這條式子最關鍵的性質：前兩項是「乘法閘」而非加權項。MFMT 與 MSRC 都是 binary（0 或 1）。只要輸出格式跑掉、或 source schema 集合沒有完全命中，整條 lineage 直接歸零，後面三項算再好都沒用。論文的說法是這反映了「基礎結構錯誤會在真實系統中向下游傳播」。這個設計解釋了 Table 2 裡 DeepSeek-Coder-1.3B base 分數是精確的 0.000。
依 prompting 策略要求兩種格式之一：
# 有 reasoning trace 時
<think> ... reasoning trace ... </think>
<answer> ... schema lineage dictionary ... </answer>
# 無 reasoning trace 時
<answer> ... schema lineage dictionary ... </answer><answer> 內必須是嚴格 key-value 字典、恰好四個 key。任何 tag 畸形、key 名錯誤、欄位缺漏 → 直接判 0。
因為表名有 database.schema.table vs table 這類命名慣例差異，純 exact match 太嚴苛：
這兩項的難點在於語法不同但邏輯等價的程式碼。論文提出 Multi-AST similarity 來支援多語言比對：
與 CodeBLEU 的差異（面試必答）：SLiCE 保留了 CodeBLEU 的 n-gram BLEU、weighted BLEU、AST similarity 三項基礎，但做了兩個關鍵改動 ——（1）把單語言 AST 擴展成語言感知的加權聚合，處理一段程式碼混雜多語言的情況；（2）刻意移除 data-flow matching 項，理由是 schema lineage 的 transformation 常常是部分且不可執行的程式碼片段，跑不了 data-flow 分析。同理，pass@k 這類 execution-based 指標在此完全不適用。
注意這是先腳本內平均、再跨腳本平均的 macro-average：每支腳本權重相同，不會因為 hard 腳本欄位多就主導總分。
論文設計了三個階層式的 prompting 類別，用來系統性檢驗「context 豐富程度」對抽取品質的影響。
只給管線腳本 + 明確的抽取指令（目標輸出格式與各 component 定義）。作為「最小必要 context」的基準線。
在 base 之上加入具體的 input-output 範例對。範例數量依腳本複雜度縮放：easy 給 1 個、medium 最多 2 個、hard 最多 3 個。
在 few-shot 之上，把範例換成人工撰寫的詳細 reasoning trace，逐步演示如何從管線程式碼推導出 lineage。
三大類展開成 7 種具體策略：base、one-shot、two-shot、three-shot、CoT-1、CoT-2、CoT-3。
工程細節（值得在面試提，顯示 system 面的掌握）：對開源 SLM 採用 PagedAttention（vLLM 的 KV cache 虛擬化機制）。關鍵觀察是 —— 同一支腳本內、不同目標 schema 的 prompt 前綴是完全相同的（腳本本身 + 抽取指令 + 範例都不變，只有目標欄位名在變）。因此 KV pair 每支 pipeline 只算並快取一次，而不是每個 schema 重算一次。以平均 34 個 schema／腳本、hard 腳本最多 391 個 schema 來算，這省下的重複計算非常可觀。
最初評估 18 個模型（2 個 LLM + 16 個 SLM），因推論時間過長或表現持續過差，剔除 6 個，最終呈現 12 個。
保留（12）：GPT-4.1、GPT-4o；Qwen2.5-Coder（1.5B / 3B / 7B / 14B / 32B）、Mistral-7B、Codestral-22B、DeepSeek-Coder（1.3B / 6.7B）、Phi-4（14B）。
剔除（6）：CodeLlama（7B / 13B / 34B）、Phi-4-mini、Phi-4-reasoning-14B、Qwen2.5-Coder 其一變體。
實驗規模：12 模型 × 50 腳本 × 7 策略 × 6 個隨機種子，合計 50,000+ 次抽取任務。
| Model | Size | Base | One-Shot | CoT-1 |
|---|---|---|---|---|
| GPT-4.1 | – | 0.418 ±.005 | 0.673 ±.008 | 0.767 ±.007 |
| GPT-4o | – | 0.284 ±.003 | 0.654 ±.007 | 0.759 ±.008 |
| DeepSeek-Coder | 1.3B | 0.000 ±.000 | 0.054 ±.015 | 0.038 ±.017 |
| Qwen2.5-Coder | 1.5B | 0.014 ±.002 | 0.309 ±.006 | 0.304 ±.017 |
| Qwen2.5-Coder | 3B | 0.100 ±.004 | 0.391 ±.015 | 0.445 ±.010 |
| DeepSeek-Coder | 6.7B | 0.003 ±.003 | 0.084 ±.018 | 0.509 ±.007 |
| Mistral | 7B | 0.026 ±.003 | 0.331 ±.005 | 0.227 ±.009 |
| Qwen2.5-Coder | 7B | 0.167 ±.005 | 0.487 ±.018 | 0.556 ±.009 |
| Phi-4 | 14B | 0.016 ±.003 | 0.511 ±.005 | 0.648 ±.005 |
| Qwen2.5-Coder | 14B | 0.286 ±.004 | 0.547 ±.005 | 0.646 ±.007 |
| Codestral | 22B | 0.126 ±.004 | 0.511 ±.005 | 0.662 ±.008 |
| Qwen2.5-Coder | 32B | 0.355 ±.004 | 0.623 ±.004 | 0.734 ±.007 |
① 加一個範例的邊際效益最大。從 base → one-shot，GPT-4.1 提升 61%、Qwen2.5-Coder-32B 提升 75%。而通用型模型（GPT-4o、Mistral、Phi-4）提升幅度超過 100% —— 因為它們的 base 分數被格式閘鎖死（Phi-4 base 僅 0.016，one-shot 直接跳到 0.511）。這其實是在說：one-shot 的主要作用是教會模型輸出格式，而不是教會它抽 lineage。
② CoT 對 < 3B 模型是負向的。DeepSeek-Coder-1.3B（0.054 → 0.038）與 Qwen2.5-Coder-1.5B（0.309 → 0.304）從 one-shot 換到 CoT-1 反而退步。論文給兩個解釋：CoT 推理是大模型才湧現的能力（Wei et al.）；以及 CoT 更長的 prompt 會塞爆小模型有限的 context window（呼應 Liu et al. "Lost in the Middle"）。Mistral-7B 也有同樣現象（0.331 → 0.227），顯示這不只是參數量問題，也和是否為 code-pretrained 有關。
③ 32B 開源模型 ≈ GPT 系列，這是全篇的 headline。Qwen2.5-Coder-32B 在 CoT-1 拿到 0.734，vs GPT-4o 的 0.759、GPT-4.1 的 0.767。更強的說法是：它的 base 分數（0.355）已經超過 GPT-4o（0.284），而在所有難度層級上，Qwen-32B 的 CoT-1 表現都超過 GPT-4o 的 one-shot。對企業而言這代表可以內部部署、不必把含敏感商業邏輯的管線腳本送出去。
④ 一條高品質 reasoning trace 就夠了，之後遞減。在 hard 腳本上，Qwen-32B 從 one-shot → two-shot 提升 23%（0.531 → 0.653），但 CoT-1 → CoT-2 只提升 6%（0.689 → 0.727）。Phi-4 在 hard 腳本上 CoT-1 得 0.660，遠高於 one-shot 的 0.397。結論：CoT 有效抵銷腳本複雜度帶來的衰退，但邊際報酬遞減得很快。
另外，難度分層分析（Figure 2a）確認了直覺：所有模型的 SLiCE 分數都隨腳本複雜度上升而下降；但從 one-shot 換到 CoT-1，所有模型在各難度都上升，等於 CoT 有效緩解了複雜度懲罰。
成本問題：proprietary LLM 雖強，但每個 prompt 都必須塞進完整管線腳本，可能超過數十萬 token，成本急遽上升。
可擴展性瓶頸：CoT 的效果依賴人類專家為每種腳本類型撰寫 reasoning trace。這個需求限制了方法的規模化 —— 這正是論文明示的最大痛點。
論文在 §3.2 結尾與 §7 Conclusion 兩處都主動點出同一件事，措辭幾乎是在替後續工作鋪路：
§3.2：「SLiCE 這種結構化的形式，不只適合用於評估，也非常適合在未來的 supervised fine-tuning 或 reinforcement learning 框架中作為 reward signal」（引用 DeepSeek-R1 與 execution-based RL code generation 兩篇）。
§7：「這個指標……提供了一個結構良好的 reward signal，可在未來工作中用於微調語言模型，為改善模型與 schema lineage 抽取任務的對齊提供了直接路徑。」
換句話說：本篇完全沒有做任何 fine-tuning，全部是 prompting-only。把 SLiCE 當 reward 去做 RL 微調，是作者自己留下的、且已在正文中公開宣告的下一步。
論文用 TotalAmountSpent 當例子說明 lineage 如何餵給 RAG：知道它來自 customer_id 與 amount、經過 SUM 聚合後，LLM 就能生成精確的商業敘述（「TotalAmountSpent 顯示每位客戶透過加總個別交易金額所花費的總額」）。對 text-to-SQL 而言，準確的 schema lineage 提供精確的欄位定義與商業脈絡，直接改善生成品質。