背景：當預測還是一項工程專案
企業最關鍵的決策大多跑在關聯式資料庫上：使用者連著訂單，訂單連著商品，所有紀錄都隨時間演進。但在這種資料上建立預測模型，至今仍是一項勞力密集的工程。資料團隊必須先花上數週做特徵工程，用人工聚合把多張表壓成單一寬表，例如算出「過去三十天的平均客單價」，再為每一個任務各自訓練一個專用模型，並持續維護調校過的管線。這個過程不只昂貴，還會在攤平的過程中丟掉細緻的結構訊號。
自然語言處理曾經走過同一條路。幾年前，生產環境的 NLP 是每個任務一個模型，各自搭配分詞、詞形還原與 n-gram 前處理。大型語言模型之所以讓那整套堆疊幾乎失效，理由有三個：比最好的任務專用模型更準、更容易放進生產環境、而且靈活到足以開啟代理式應用的新階段。NVIDIA 認為結構化資料正走到相同的轉折點，並在 2026 年 10 月 21 日以 Kumo Relational 作為對這個判斷的實作回應，論文與文件同步公開，作者群包含 Jure Leskovec、Matthias Fey 等 NVIDIA Kumo 團隊成員。
核心：把一次預測從專案變成一道查詢
Kumo Relational 是一個預訓練的關係型基礎模型（Relational Foundation Model），運作位置就在企業資料庫上。使用時只要連接資料庫，用宣告式語言描述想預測的目標，模型便以單次前向傳播輸出結果，過程中不需要任務專屬訓練、不需要特徵工程、也不需要把資料表攤平。它面對的預測型態包含客戶流失、需求預測與詐欺偵測等。
支撐這項能力的是上下文學習（in-context learning），也就是模型不靠事先記住的任務權重，而是在推論當下閱讀範例來判斷。Kumo Relational 在推論時讀取最多一萬筆歷史範例作為上下文，每一筆範例都是一個實體在某個時間點周邊的局部子圖，並附上已知的正確答案，例如「這位使用者流失了」或「這個商品賣出 142 件」。模型藉由比對這些範例與待預測實體之間的關係來給出答案，這類做法一般稱為少樣本（few-shot）預測。
NVIDIA 將 Kumo Relational 定位為第一個在常見關係型基準上超越監督式機器學習的少樣本基礎模型。研究團隊在 41 項任務、15 個資料庫上進行評估，來源涵蓋 RelBench V1 與 V2、SAP SALT 與 4DBInfer，領域橫跨電商、醫療、企業、社群與學術，且這些資料集都沒有出現在預訓練階段。
運作方式：先在表內推理，再跨表推理
要完成一次預測，模型得依序處理三件事：理解每張表內的數值意義、跨表關聯紀錄、以及把帶有已知答案的上下文範例與待預測實體對應起來。
第一步是自動上下文生成。任務以預測查詢語言（Predictive Query Language，PQL）描述，這是一種宣告式介面，使用者只說明要預測什麼，而不是怎麼算。對時間性任務，Kumo Relational 會回放資料庫的歷史狀態：它沿著時間軸取樣以實體為中心的子圖，把目標值從錨定時間點之後的事件算出，卻只把錨定時間點之前的資料餵給模型，藉此避免資料洩漏。
第二步是表內推理。一個輕量網路獨立處理每張表，交替使用欄內注意力（column attention，關聯同一欄位中的數值）與列內注意力（row attention，關聯同一筆紀錄中的特徵）。模型會自行判斷哪些欄與列對當前預測重要，在資訊往外傳遞之前先過濾噪聲。
第三步是跨表推理，也是關係推理真正發生的地方。一個較大的網路透過主鍵與外鍵關係上的圖注意力，把列嵌入（row embedding，代表一筆紀錄的向量表徵）沿著關聯結構分送到各處，並與跨樣本注意力交錯，例如把使用者的個人檔案連結到他的交易歷史。由於這個階段處理的是列嵌入，而不是每張表的每一個儲存格，設計上避開了平方級成本，因此能擴展到更大的上下文與更深的子圖。
預訓練：用合成資料庫換取泛化能力
Kumo Relational 的預訓練資料全部是合成生成的關係型資料，目的是模擬真實世界資料庫的多樣性與各種預測查詢。訓練分階段推進，從單表起步，逐步進入越來越複雜的關聯結構。
之所以不用真實資料，是因為預訓練所需的多元資料庫幾乎都不公開。團隊的生成器建立在 PluRel（Kothapalli 等人，ICML 2026）的方法之上，該方法把單表資料生成器延伸為完整的關聯式資料庫；Kumo 團隊成員參與了 PluRel 的開發，也是原始論文的共同作者。PluRel 分三階段生成每個資料庫：先產生綱要（schema，也就是資料表的欄位與型別定義），再建立列與列之間的外鍵連結，使其像真實資料那樣叢集分布，最後用結構因果模型產生欄位值，其中包含時間趨勢與跨表依賴。由於生成過程輕量，預訓練資料實際上沒有上限；PluRel 論文也顯示，隨著合成資料庫增加，預訓練損失呈冪律下降，且這些增益能遷移到真實資料庫。
透過這樣的預訓練，模型學到的是跨表過濾、關聯與聚合資訊的能力，而不是依賴固定的聚合規則。當準確度是最高優先時，Kumo Relational 仍可在特定資料集與任務上進行微調。
效能：基準上的領先幅度
在 RelBench V1 的分類任務上，Kumo Relational 在專家特徵工程的基礎上，平均比梯度提升樹高出近 4 個 AUROC 點；AUROC 是衡量分類模型把正負樣本排序得好不好的指標，數值越高代表區辨能力越強。在 SAP SALT 企業基準上，它開箱即比基於特徵工程的 XGBoost 高出 7 個 MRR 點，微調後差距擴大到 13 個 MRR 點。同一基準上，它比大型 AutoGluon 集成高出 8% 的平均倒數排名（mean reciprocal rank，MRR，用來衡量正確答案排在多前面的指標），比近期的表格基礎模型高出約 25%，微調後對 AutoGluon 的領先擴大到 16%。研究團隊據此主張，生產環境的 XGBoost 管線有理由被替換。
在比較關係型模型與系統的 RelArena-α 排行榜上，它開箱即站在準確度與效率的帕雷托前緣：每 1,000 筆樣本的中位推論時間約 17 秒，Elo 約 1,842；Elo 是排行榜用來表示跨任務相對準確度的評分。榜上最高分的 rt-plurel 達到 Elo 1,878，但需要約 7,300 秒，慢了約 430 倍。其餘的基礎模型、特徵工程系統與監督式模型，分數與速度都落後。
模型在嚴苛條件下仍有一定韌性：只取 0.2% 的訓練資料作為上下文也能運作；移除多達 75% 的外鍵連結仍保持穩定；加入大量噪聲欄位時效能幾乎不退化。
影響與限制
這項工作的意義在於把預測的單位從「專案」改成「查詢」。一個預訓練模型取代了過去每個任務各自一條的管線，新的預測需求可以用一道查詢表達，不必再動員一輪特徵工程，這讓 ML 團隊有機會承接過去因為成本過高而放棄的使用情境。對代理式系統而言，大型語言模型讓代理能讀、能寫、能推理，關係型基礎模型則補上「預測接下來會發生什麼」的能力，例如判斷哪位客戶即將流失，再據此採取行動；Kumo Relational 本身即設計成可供代理呼叫，PQL 就是它給代理的提問介面。
限制同樣明確。Kumo Relational 在有實質關係與時間動態的資料上表現最好，例如使用者隨時間變化的行為；若任務的訓練集非常龐大，任務專屬的監督式模型仍可能勝過上下文預測，因為基準測試中最多只使用一萬筆上下文範例，而微調正是為此設計的補救手段。此外，預測訊號必須在有限跳數內可達，實務上建議先從少數相關資料表的聚焦查詢開始，再視需要擴展圖的範圍。
可用性
Kumo Relational 即日可用，程式碼以 Apache 2.0 授權釋出，模型權重採 OpenMDW 授權協議 1.1 版。它原生在資料庫上執行上下文學習，可透過記憶體內處理、資料庫與資料倉儲連接器，或一套以記憶體映射 I/O、最高每秒 5 GB 吞吐處理 500B 以上列數的自訂圖引擎來運行。模型收錄於 NVIDIA 新釋出、GPU 原生的 structured-data-models 開源函式庫，與姊妹模型 Kumo Tabular 同庫；函式庫會在首次使用時從 Hugging Face Hub 下載權重，因此可以直接在支援 GPU 的 notebook 中載入模型並預測。若要以獨立服務形式部署，則可包裝為 NVIDIA NIM，再以開源的 structured-data-models-client 從 notebook 指向該服務：預測以 PQL 撰寫，客戶端負責蒐集上下文範例與相關資料表後送出請求。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。