NVIDIA Kumo Relational 基礎模型：無需訓練，關聯式資料預測效能超越監督式機器學習

重點摘要

NVIDIA Kumo Relational 是一個預訓練的關聯式基礎模型，能夠直接在企業資料庫上進行預測。它接收一個預測查詢，收集多達 10,000 個歷史範例作為上下文，並在單次前向傳播中預測流失、需求或詐欺等結果。

它不需要針對特定任務的訓練、特徵工程，也不需要將表格扁平化。Kumo Relational 是第一個在常見關聯式基準測試中，表現優於監督式機器學習的少樣本基礎模型。

在 15 個資料庫上的 41 項任務中，它擊敗了監督式關聯式深度學習模型和專家設計的梯度提升樹管線。在 SAP SALT 企業基準測試中，它在平均倒數排名 (MRR) 上超越 AutoGluon 整合模型 8%。

它可擴展至超過 5000 億行的資料庫，並透過 NVIDIA 的開源 GPU 原生結構化資料模型函式庫或作為 NVIDIA NIM，供人類和代理程式使用。

結構化資料基礎模型的轉變

基礎模型已經徹底改變了語言和視覺領域的遊戲規則。不久前，生產級的自然語言處理 (NLP) 意味著每個任務都需要一個專用模型，每個模型都由自己的詞元化、詞形還原和 N-gram 管線提供資料。

大型語言模型 (LLM) 使這一堆疊在很大程度上過時了，原因有三：它們比最好的任務專用模型更準確、部署到生產環境中更簡單，並且足夠靈活，開啟了代理應用程式的新時代。

同樣的轉變現在正在結構化資料領域發生。關聯式資料庫為世界上最關鍵的商業決策提供支援，但其上的預測建模仍然需要數週的特徵工程、特定任務訓練和調整過的管線。

結構化資料基礎模型改變了這一現狀，原因也是這三點：

今日更優異的準確性： 作為直接替換，這些模型已經擊敗了許多生產管線，尤其是 XGBoost。在 RelBench V1 分類任務中，Kumo Relational 在專家設計的特徵上，平均比梯度提升樹高出近 4 個 AUROC 點。

在 SAP SALT 上，它在未經調整的情況下，比 XGBoost 在工程特徵上高出 7 個 MRR 點，經過微調後則高出 13 個 MRR 點。這些結果有力地證明了用 Kumo Relational 替換生產級 XGBoost 管線的必要性。

簡潔性和敏捷性： 一個預訓練模型取代了針對個別任務的獨立管線。新的預測變成了一個查詢，而不是一個專案，因此機器學習團隊終於可以處理傳統機器學習在組織各個層面都難以建立的應用案例。

能夠預測的代理程式： LLM 讓代理程式能夠閱讀、寫作和推理。結構化資料基礎模型讓它們能夠預測接下來會發生什麼，例如哪些客戶會流失，並採取行動。Kumo Relational 已經內建了可供代理程式呼叫的功能，其預測查詢語言 (PQL) 為它們提供了一個簡單的介面來提出預測性問題。

今天，我們正在推出 Kumo Relational (論文、文件)，這是一個預訓練的基礎模型，將這種範式帶入關聯式資料。連接資料庫，描述要預測的內容，並在單次前向傳播中獲得預測結果。無需訓練。

Kumo Relational 的運作方式

大多數結構化資料的基礎模型都在單一扁平表格上運作。然而，真實世界的資料存在於關聯式資料庫中：使用者連接到訂單，訂單連接到產品，所有這些都隨時間演變。

透過手動聚合（例如，「過去 30 天的平均訂單價值」）將這些關係扁平化為一行，會損失細緻的結構訊號，並需要大量的人力。

Kumo Relational 是一個關聯式基礎模型，它直接在資料庫上運作，尊重其表格、外部鍵和時間戳記。它在反映真實世界資料集的合成關聯式資料上進行一次預訓練，並透過上下文學習適應每個新任務，在推論時讀取多達 10,000 個上下文範例。

每個範例都將實體在某個時間點周圍的局部子圖與其真實目標配對（例如，「此使用者已流失」或「此商品售出 142 件」）。

圖 1. Kumo Relational 系統概覽。連接資料庫，指定預測查詢，Kumo Relational 會處理其餘所有事情，從上下文生成到模型推論。

為了進行預測，Kumo Relational 必須完成三件事：(1) 理解每個表格中的值，(2) 關聯跨表格的記錄，以及 (3) 將具有已知目標的上下文範例與正在預測的實體關聯起來。以下是它的運作方式：

圖 2. Kumo Relational 架構：(a) 上下文輸入，(b) 表格內推理，(c) 跨表格推理。

自動上下文生成： 任務以預測查詢語言 (PQL) 編寫，這是一個宣告式介面，您只需說明要預測什麼，而不是如何預測。對於時間性任務，Kumo Relational 會重播歷史資料庫狀態：它會採樣實體中心的子圖，直到一個錨點時間戳記，並從該時間戳記之後的事件計算每個目標，同時只向模型提供該時間戳記之前的資料。這可以防止資料洩漏。

表格內推理： 一個輕量級網路獨立處理每個表格，交替進行欄位注意力（關聯欄位內的值）和列注意力（關聯列內的特徵）。模型學習哪些欄位和列對於當前預測很重要，並在傳播之前過濾掉雜訊。

跨表格推理： 一個更大的網路透過圖注意力，將列嵌入分佈到關聯結構中，該圖注意力基於主鍵/外部鍵關係，並與跨上下文範例的跨樣本注意力交錯。這是關聯式推理發生的地方，例如將使用者的個人資料與其交易歷史連結起來。

由於此階段作用於列嵌入而不是每個表格中的每個單元格，因此該設計避免了二次成本，並可擴展到大型上下文和更深的子圖。

Kumo Relational 的建構方式

Kumo Relational 在完全合成的關聯式資料上進行預訓練，這些資料模擬了具有多樣化預測查詢的真實世界關聯式資料庫。預訓練分階段進行，從單一表格到日益複雜的關聯結構。

預訓練所需的多樣化關聯式資料庫很少公開，因此合成資料彌補了這一空白。Kumo Relational 的生成器建立在 PluRel (Kothapalli 等人，ICML 2026) 的方法基礎上，該方法將單一表格資料生成器擴展到完整的關聯式資料庫。

Kumo 團隊的成員協助開發了 PluRel 並共同撰寫了原始論文。PluRel 分三個階段生成每個資料庫：一個綱要、行之間像真實資料一樣聚類的外部鍵連結，以及來自具有時間趨勢和跨表格依賴性的結構因果模型的欄位值。

生成過程輕量化，因此預訓練資料實際上是無限的。PluRel 論文顯示，隨著合成資料庫的增加，預訓練損失遵循冪律，其收益會轉移到真實資料庫上。

透過這種預訓練，模型學會了過濾、關聯和聚合跨表格的資訊，而不是依賴固定的聚合。當需要最大準確性時，Kumo Relational 也可以針對特定資料集和任務進行微調。

效能表現

在本論文中，我們在來自 RelBench V1 和 V2、SAP SALT 以及 4DBInfer 的 15 個關聯式資料庫上的 41 個基準測試中評估了 Kumo Relational，涵蓋了電子商務、醫療、企業、社交和學術領域。這些資料集在預訓練中均未出現。

Kumo Relational 在分類和迴歸方面都超越了最強的監督式模型，包括關聯式深度學習模型和專家設計的表格整合模型。在 RelArena-α 排行榜上，該榜單比較了 RelBench V1 上的關聯式模型和系統，Kumo Relational 在開箱即用時也位於準確性-效率的帕累托前沿。

圖 3. RelArena-α 排行榜：跨任務的相對準確性 (Elo) 對比每 1,000 個樣本的中位推論時間 (對數尺度)。Kumo Relational 在相似準確度下，比得分最高的項目快約 430 倍。

該論文還報告，在 SAP SALT 企業基準測試中，Kumo Relational 在平均倒數排名 (MRR) 上超越大型 AutoGluon 整合模型 8%，並超越近期表格基礎模型約 25%。微調後，其領先 AutoGluon 的幅度擴大到 16%。

它在嚴苛條件下也能保持良好表現：即使僅使用 0.2% 的訓練資料作為上下文，它也能表現出色；當多達 75% 的外部鍵連結被移除時，它仍能保持穩定；即使添加許多雜訊欄位，其效能也幾乎沒有下降。

限制

Kumo Relational 在具有有意義關係和時間動態的資料上表現最佳，例如隨時間變化的使用者行為。對於訓練集非常大的任務，特定任務的監督式模型可能仍然會略優於上下文預測，我們的基準測試中最多使用了 10,000 個上下文範例。

基礎模型的微調正是為了解決這種情況而設計的。預測訊號也必須在有限的跳數內可達，因此應從針對幾個相關表格的重點查詢開始，並根據需要擴展圖形。

示範

Kumo Relational 原生支援在資料庫上進行上下文學習：它可以在記憶體中、透過資料庫和資料倉儲連接器，或透過自訂圖形引擎運行，該引擎透過記憶體映射 I/O 處理超過 5000 億行資料，速度高達 5 GB/秒。

它可在 NVIDIA 最新發布的 GPU 原生結構化資料模型函式庫中使用，該函式庫也是我們姊妹模型 Kumo Tabular 的動力來源。該函式庫在首次使用時會從 Hugging Face Hub 下載權重，因此您可以在支援 GPU 的筆記本中載入模型並直接從中進行預測。

以下程式碼將上下文範例、預測實體及其相關表格傳遞給模型：

```python

pip install structured-data-models

import sdm

model = sdm.models.KumoRelational(device="cuda")

pred = model(

In-context training table (fkeys/timestamps/targets):

x_context=...,

y_context=...,

Prediction examples (fkeys/timestamps):

x_query=...,

Multi-table information for context/prediction entities:

related_context_tables=...,

related_query_tables=...,

)

```

請參閱函式庫的關聯範例，以獲取完整的 RelBench 和 SAP SALT 管線，包括如何採樣每個實體的相關表格。

如果想將模型作為獨立服務運行，可以將其部署為 NVIDIA NIM，並從您的筆記本中將開源的 structured-data-models-client 指向它。您以 PQL 編寫預測，客戶端會收集上下文範例和相關表格，然後發送請求：

```python

pip install 'structured-data-models-client[relational]'

import sdm_client

client = sdm_client.SDMClient(url="http://localhost:8001") # NIM URL

query = sdm_client.PredictiveQuery(

Prediction task in Predictive Query Language (PQL):

"PREDICT COUNT(orders.*, 0, 30, days) FOR EACH users.user_id",

Multi-table dat

)```