過去這幾年，大語言模型（LLM）和電腦視覺在產業界狂飆，但我們每天處理的商業核心數據，其實還是乖乖躺在資料庫、CRM 系統和財務帳本裡的表格資料。傳統做法很痛：每換一個資料集，就得重新洗資料、做特徵工程、跑超參數優化，部署後還得盯著資料漂移不斷重訓。這套流程拖慢了產品上市速度，也把數據工程師綁在流水線上。Google 研究團隊這次推出的 TabFM，打算直接砍掉這道繁雜的訓練循環。他們把表格預測當成一個**情境學習（In-Context Learning）**問題，讓模型在推理時直接「看」歷史資料就能出結果。這背後反映的不只是技術躍進，更是企業數據架構從「模型驅動」轉向「資料驅動的推理」的訊號。
為什麼現有模型吃不太下表格？
很多人第一直覺會是：既然 LLM 這麼強，直接喂表格進去不行嗎？我實際觀察過這類想法的落地狀況後，發現有三個硬傷。第一，語境視窗會被瞬間撐爆。一張只有幾千列、幾百個欄位的表，轉換成文字後，token 數量直接讓模型癱瘓。第二，分詞機制會破壞數值精確度。LLM 習慣把數字拆成碎片，數學計算的嚴謹性就流失了。第三，也是最致命的，結構盲視。二維的表格被拉平成一行一行的文字，模型根本搞不清哪個數值對應到哪一行哪一欄。正如 Google 研究員 Weihao Kong 點破的，現在讓 LLM 寫程式去調 XGBoost，其實比直接讓它讀表格還有效。
TabFM 的架構邏輯與成本反轉
TabFM 的解法很聰明，它沒有走 LLM 的老路，而是結合了先前 TabPFN 的深層上下文理解，以及 TabICL 的**行壓縮（Row Compression）**技術。原始表格經過交替的行與欄注意力機制後，每一列的資訊會被壓縮成一個高密度向量。接著，因果 Transformer 就在這些壓縮後的 CLS tokens 上進行情境學習。
這帶來了一個根本性的成本結構反轉。傳統機器學習是「訓練慢且貴，推理快且便宜」；TabFM 則是「訓練成本歸零，推理變重」。因為每次預測都要把歷史資料當上下文跑一遍前向傳遞，運算和記憶體需求會明顯上升。
| 維度 | 傳統機器學習（如 XGBoost） |
Google TabFM |
|---|---|---|
| 資料準備 | 需清洗、填補缺失值、手動編碼特徵 | 直接輸入 pandas DataFrame，原生處理混合欄位 |
| 訓練循環 | 針對每個資料集獨立訓練 + 超參數調優 | 零訓練，單一前向傳遞完成零樣本預測 |
| 推理成本 | 極低，適合單數毫秒級 API | 較高，需載入完整歷史資料作為 KV caching 快取 |
| 資料漂移應對 | 需持續監控並觸發重訓管線 | 直接更新上下文資料即可，無需重新訓練權重 |
| 授權狀態 | 開源算法廣泛可用 | 原始碼 Apache 2.0，模型權重為非商業授權 |
「傳統機器學習的訓練過程，在本質上就變成了情境視窗裡的『預填充』（prefill）階段。這筆前期成本很可觀，但只需要付一次，之後的查詢都能重複使用快取。但預測延遲是無法靠快取消除的。」 — Weihao Kong, Google Research
未來一到兩年的演變預測
我看好 TabFM 會在快速原型開發與高資料漂移環境裡先跑出來。企業不需要養一堆專職數據科學家去盯管線，後端工程師直接呼叫 TabFMClassifier 就能拿到高品質的基線模型。不過，它不會在兩年内取代那些已經被磨到極致的生產級模型。對於需要極致延遲的即時服務，或是超過百萬列的超大表，傳統做法還是更穩。我預計未來一年內，Google 會把 AI.PREDICT 指令進一步深化，讓基礎模型推理直接嵌進資料倉儲裡。到那個時候，數據分析師查詢表格的方式，可能會跟現在寫 SQL 沒什麼兩樣。
延伸思考與常見問題
Q1：情境學習（In-Context Learning, ICL）在表格預測中具體是什麼意思？ 答：情境學習是指模型在推理時不需要更新任何權重，而是直接將歷史範例（含標籤）與待預測的新資料合併成一個提示字串，讓模型在執行前向傳遞的過程中即時從上下文中學習欄位與行之間的關係。
Q2：為什麼 TabFM 選擇完全使用合成資料進行預訓練，而不直接用真實的商業 CSV 檔案？ 答：透過結構因果模型（SCM）動態生成數億筆合成資料，TabFM 能夠學習到表格特徵互動的基礎數學先驗，同時避開直接使用真實資料可能帶來的隱私爭議與資料偏倚問題。
Q3：TabFM 目前有哪些硬性限制，會直接影響企業在生產環境的部署決策？ 答：目前模型僅支援分類任務最多 10 個輸出類別，並優化於最多 500 個特徵的表格；此外，模型權重採用非商業授權，若需直接用於商業產品須等待授權解鎖或搭配 Google Cloud 的專屬方案。