---
url: /kumo/introduction.md
description: >-
  NVIDIA Kumo
  Relational是什么？2026年10月21日开源的关系型基础模型，不用训练、不用特征工程，直接在数据库上预测流失/需求/欺诈，41项基准超越XGBoost与AutoGluon，代码Apache
  2.0
---

# 认识NVIDIA Kumo Relational

先说一件让我有点难受的事。

我花了整整三周，给公司做「用户流失预测」。三周里我干的事大概是：把 users、orders、products、payments 四张表 join 成一张宽表，手写「近30天平均客单价」「近90天登录次数」「最后一次下单距今天数」这类特征，一共 200 多列；然后调 XGBoost，调参，做时间切分防止穿越，上线。

最后 AUC 0.79。领导问「能不能再高点」，我说「给我两周」。

然后 2026 年 10 月 21 日，NVIDIA 发布了 **Kumo Relational**——一个预训练好的关系型基础模型。它干同样的事不需要 join、不需要手写特征、不需要训练，写一行类似 SQL 的预测语句，一次前向传播出结果。官方说，在 RelBench V1 的分类任务上，它比「专家手工特征 + 梯度提升树」平均高将近 **4 个 AUROC 点**。

三周，输给一行查询。这种感觉不太好，但作为一个天天写 SQL 的人，我知道这事的分量。

> 大模型把 NLP 里「每个任务训一个模型」的那套流水线干掉了。Kumo 想干的是同一件事，只不过战场从文本换成了你公司的数据库。

## 什么是 NVIDIA Kumo Relational

Kumo Relational 是一个**关系型基础模型（Relational Foundation Model, RFM）**。注意定语：不是「表格模型」，是「关系型」。

绝大多数结构化数据基础模型吃的是**一张扁平的宽表**。但真实世界的数据不长那样——用户连着订单，订单连着商品，商品连着库存，而且全都在随时间变化。要把这种结构喂给表格模型，你就得先把它「压平」成一行，也就是我上面干的那三周的活。压平的过程既费人力，又把结构信息丢掉了。

Kumo Relational 不压平。它**直接在数据库上工作**，认识表、认识外键、认识时间戳。

它的使用方式是**上下文学习（in-context learning）**：你给它一个预测问题，它自动从你的库里捞最多 **10,000 条历史样本**当上下文，每条样本是「某个实体在某个时间点的局部子图 + 这个实体后来的真实结果（比如这个用户流失了 / 这件商品卖了 142 件）」，然后**一次前向传播**给出预测。

关键点：模型的预训练权重是固定的，**不需要为每个任务训练**。想要极致精度时可以微调，但那不是必选项。

一句话定位：**把「一个预测需求 = 一个 ML 项目」，变成「一个预测需求 = 一条查询」。**

### 出身

Kumo 这家公司 2022 年成立于加州山景城，三位联合创始人挺吓人的：

* **Vanja Josifovski**：前 Airbnb、Pinterest 的 CTO
* **Jure Leskovec**：斯坦福大学教授，图机器学习领域顶级学者，PyTorch Geometric 的共同创造者
* **Hema Raghavan**：前 LinkedIn 工程与 AI 负责人

NVIDIA 在 2026 年把这支团队连同公司一起收了（多家外媒报道交易金额在 4 亿美元以上），三位创始人已于 2026 年 5 月入职 NVIDIA。所以这次开源，本质上是 NVIDIA 把买来的团队做成的技术，用开源的方式放出来。

对应论文是《KumoRFM-2: Scaling Foundation Models for Relational Learning》（[arXiv:2604.12596](https://arxiv.org/abs/2604.12596)）。

## 它凭什么这么干：三段式推理

Kumo Relational 要做一次预测，得完成三件事，架构也正好是三段。

### 1. 自动生成上下文（Automatic Context Generation）

你用 **PQL（Predictive Query Language，预测查询语言）** 描述要预测什么，而不是怎么预测。长这样：

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

意思是：预测每个用户在未来 30 天内的下单数。这跟 SQL 长得像，但语义是预测而不是查询。

对于时序任务，系统会**回放历史数据库状态**：以某个锚点时间戳为界，采样实体周围的子图，而标签只能从锚点之后的事件里算出来，喂给模型的数据则严格只取锚点之前的。这个设计是为了**防止数据穿越（leakage）**——做过时序预测的人都知道，这玩意儿能让你的离线 AUC 好看得离谱，然后上线就废。

### 2. 表内推理（Reasoning Within Tables）

一个轻量网络独立处理每张表，交替做两种注意力：

* **列注意力（column attention）**：关联同一列内不同行的值，理解这一列的分布
* **行注意力（row attention）**：关联同一行内不同列，理解这条记录

这一步的作用是**先在本地把噪声滤掉**，别急着往上传。

### 3. 跨表推理（Reasoning Across Tables）

一个更大的网络接手，通过**图注意力（graph attention）**沿主键/外键关系传播行向量，中间穿插**跨样本注意力（cross-sample attention）**，把上下文样本和当前待预测实体关联起来。

真正的「关系推理」发生在这里——比如把用户画像和它的交易历史连起来。

> 这套设计的聪明之处在成本：跨表阶段操作的是**行向量（row embeddings）**，不是表里每一个单元格。所以它避开了平方级开销，能撑住大上下文和深层子图。

## 它是在什么数据上预训练的

真实的企业关系数据库几乎不可能公开，所以 Kumo Relational **完全在合成关系数据上预训练**，分阶段推进：从单表开始，逐步过渡到越来越复杂的关系结构。

合成数据的生成器基于 **PluRel**（Kothapalli 等人，ICML 2026，[arXiv:2602.04029](https://arxiv.org/abs/2602.04029)），Kumo 团队本身就是这篇论文的共同作者。PluRel 分三步造一个数据库：

1. 生成一个 schema
2. 生成外键连接，让行的聚类方式跟真实数据一致
3. 用\*\*结构因果模型（Structural Causal Models）\*\*生成列值，带上时间趋势和跨表依赖

因为生成很轻量，预训练数据实际上**管够**。PluRel 论文里给出的结论是：随着合成数据库数量增加，预训练损失遵循**幂律（power law）**下降，而且这个收益**能迁移到真实数据库**上。

这事挺反直觉的——用假数据训出来的模型，在真数据上打赢了用真数据训的 XGBoost。但仔细想想也说得通：XGBoost 学的是「你给的这 200 个特征怎么映射到标签」，而 Kumo 学的是「怎么从关系结构里自己聚合出有用信息」。后者是元能力。

## 特点

* **零训练、零特征工程**：一个预训练模型覆盖所有任务，新预测是查询不是项目
* **不压平表**：直接吃多表结构，保留外键和时间信息
* **上下文上限 10,000 条**：推理时最多读一万条带标签的历史样本
* **自动防穿越**：时序任务自动回放历史状态，标签只从未来算、特征只取过去
* **规模可观**：自研图引擎支持 **500B+ 行**，靠内存映射 I/O 做到最高 **5 GB/s**
* **可选微调**：追求极致精度时可以针对具体数据集和任务微调
* **为 Agent 而生**：PQL 就是给 Agent 设计的预测接口，天然可被程序调用
* **开源协议友好**：NVIDIA 自研代码 **Apache 2.0**，权重为 **OpenMDW License Agreement 1.1**
* **同门师兄弟齐全**：同一个 `structured-data-models` 库里还有 Kumo Tabular（表格）、Kumo Forecast（时序预测）、KumoAnomaly（异常检测）、TimesFM3、TabICLv2、TabFM

## 性能：数字都在这儿

官方在 **41 个基准任务、15 个关系数据库**上做了评测，数据来自 RelBench V1、RelBench V2、SAP SALT 和 4DBInfer，覆盖电商、医疗、企业、社交、学术五个领域。**这些数据集在预训练时一个都没见过。**

结论是：分类和回归两个方向上，都超过了最强的监督学习模型，包括关系深度学习模型和专家手工特征的表格集成模型。

具体数字：

| 场景 | 对比对象 | 结果 |
| --- | --- | --- |
| RelBench V1 分类任务 | 专家特征 + 梯度提升树 | 平均高 **约 4 个 AUROC 点** |
| SAP SALT | 专家特征 + XGBoost | 开箱高 **7 个 MRR 点**，微调后高 **13 个** |
| SAP SALT | 大规模 AutoGluon 集成 | MRR 高 **8%**，微调后扩大到 **16%** |
| SAP SALT | 近期表格基础模型 | 高约 **25%** |

**速度这块更狠。** 在 RelArena-α 排行榜（基于 RelBench V1，对比关系模型的精度与效率）上：

* Kumo Relational：**每 1000 样本约 17 秒**，Elo **1842**
* 榜首 rt-plurel：Elo **1878**，**约 7300 秒**

精度差 36 分，速度快 **约 430 倍**。开箱即用地站在了精度-效率的帕累托前沿上。

**鲁棒性也测了**，三个极限条件：

* 上下文只给 **0.2% 的训练数据**：依然有效
* 删掉 **75% 的外键连接**：表现稳定
* 塞进大量噪声列：几乎不退化

最后一条尤其实用。真实数仓里的表，谁没几十个「不知道谁加的、也不知道有没有用」的列。

> 必须说一句公道话：上面每一个数字都是 NVIDIA 自己跑、自己选基线、自己调的，目前没有第三方复现。榜首那个 rt-plurel 精度确实更高一点点。「换掉你线上的 XGBoost」这个建议，是卖替代品的人提的。信一半，自己跑一遍再决定。

## 场景：谁在用，用在哪

PQL 能表达的任务类型覆盖分类、回归、预测（forecasting）和链接预测（link prediction，用于排序和推荐）。落到业务上：

### 客户流失预测（Churn）

这是最经典的场景。传统做法就是我开头讲的那三周——join 宽表、手工特征、XGBoost、时间切分。用 Kumo 的话，一句 `PREDICT ... FOR EACH users.user_id` 就完事，而且不用操心特征穿越。

### 需求与销量预测

`PREDICT COUNT(orders.*, 0, 30, days) FOR EACH users.user_id` 这种形式天然适合「未来 N 天会卖多少 / 会下多少单」。零售和供应链是重灾区。

### 欺诈与信用风险

Kumo 官方此前披露过，KumoRFM 能处理的预测跨度很大：从客户流失，到信用违约风险，再到「出院患者 24 小时内再入院的概率」。医疗和金融都对得上。

### 推荐与排序

链接预测直接对应「给用户推什么」，比协同过滤少了冷启动的痛苦。

### 真实公司案例

Kumo 在被收购前已经有不少落地客户，公开报道可查的包括：

* **DoorDash**：外卖平台，预测类需求密度极高
* **Reddit**：公开合作数据称广告精准度提升 **5.5 倍**
* **Sainsbury's**：英国连锁超市，零售预测场景
* **Databricks**：生态合作方，公开数据称转化率提升 **5.4 倍**
* **Snowflake**：生态合作方

需要说明的是，那两个「5.4 倍 / 5.5 倍」是收购前 Kumo 自己公布的口径，不是这次开源发布里的新数据，也没有第三方复核。但至少说明一件事：**这套东西在 500B+ 行的生产库上是跑得动的。**

### 最值得关注的其实是 Agent

我个人认为 Kumo 最狠的地方不在替代 XGBoost，而在于**它给 Agent 补上了「预测未来」这块拼图**。

大模型让 Agent 能读、能写、能推理。但「接下来会发生什么」——哪个客户要流失、哪笔交易有问题、哪个仓库要断货——这是另一回事。Kumo Relational 天生就是给 Agent 调用的：PQL 是声明式的，Agent 自己就能拼出预测语句；预测结果是一条查询的返回，不是一个项目的交付。

> 一个能自己写 SQL 查过去的 Agent，价值有限；一个能自己写 PQL 问未来的 Agent，才是真的开始干活了。

## 初体验：两种上手姿势

### 姿势一：本地库，直接在 GPU 上跑

```bash
pip install structured-data-models
```

```python
import sdm

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

pred = model(
    # 上下文训练表（外键 / 时间戳 / 标签）
    x_context=...,
    y_context=...,
    # 待预测样本（外键 / 时间戳）
    x_query=...,
    # 上下文与预测实体的多表信息
    related_context_tables=...,
    related_query_tables=...,
)
```

几个前置条件，先确认再动手：

* **Python 3.11+**，**PyTorch 2.7+**
* 需要 **CUDA 环境**（这是个 GPU 原生库，不是给你在笔记本 CPU 上玩的）
* 官方强烈建议额外装 `cudf`，让 dataframe 操作留在 GPU 上，避免来回搬数据
* 权重首次使用时自动从 Hugging Face Hub 下载

```bash
pip install git+https://github.com/NVIDIA/structured-data-models.git  # 想装 main 分支
```

### 姿势二：部署成 NIM 服务，用客户端调

如果你要把它当独立服务跑，部署成 **NVIDIA NIM**，然后用开源的 `structured-data-models-client` 从 notebook 里连：

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

```python
import sdm_client

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

query = sdm_client.PredictiveQuery(
    # 用 PQL 写预测任务
    "PREDICT COUNT(orders.*, 0, 30, days) FOR EACH users.user_id",
    # 多表数据用 pandas DataFrame 传入，主键/外键自动推断
    {"users": ..., "orders": ...},
)

pred = client.predict(
    query.materialize(indices=[1, 2, 3]),
    model=sdm_client.KumoRelational(),
)
```

这个模式下，上下文样本的收集和关联表的采样都由客户端代劳了，你只管写 PQL。客户端的示例 notebook 里有跑本地 NIM 和 Databricks 的完整流程。

运行方式上还有三种可选：纯内存、通过数据库/数仓连接器、或者走那套支持 500B+ 行的图引擎。

### 资源清单

| 项目 | 地址 |
| --- | --- |
| 论文 | https://arxiv.org/abs/2604.12596 |
| 官方文档 | https://docs.nvidia.com/sdgm/rfm/overview |
| 代码（Apache 2.0） | https://github.com/NVIDIA/structured-data-models |
| PyPI | https://pypi.org/project/structured-data-models/ |
| 客户端代码 | https://github.com/NVIDIA/structured-data-models-client |
| 权重（OpenMDW 1.1） | https://huggingface.co/nvidia/Kumo-Relational |
| 快速上手 notebook | `structured-data-models-client` 仓库的 `examples/local/relational.ipynb` |

## 先泼点冷水：官方自己列的限制

这节我原样转述，因为一家公司愿意把限制写清楚，比堆十个 benchmark 更让我信任它。

1. **它擅长有真实关联和时间动态的数据**，比如用户行为随时间的演变。如果你的数据本身关系稀薄、也没什么时间结构，别抱太大期望。
2. **训练集特别大的时候，监督模型可能反过来赢**。因为上下文上限是 10,000 条，而任务专属的监督模型能吃下全部标注数据。这时候就该上微调了——微调本来就是为这种情况准备的。
3. **预测信号必须在有限的跳数内可达**。所以官方建议：先用几张相关的表写一个聚焦的查询，再按需扩展图，别一上来就把整个数仓塞进去。

另外提醒一句：**OpenMDW License 1.1 不是 Apache 2.0**。代码可以随便用，权重是另一套条款。要上生产、尤其是对外提供服务之前，把这两份协议都读一遍，别想当然。

## 进阶

如果你只想记住一件事：**结构化数据的「一个任务一个模型」时代，可能真的要结束了。** 就像几年前 NLP 里的分词、词形还原、n-gram 流水线一夜之间变成历史一样。我那三周的手工特征，大概率是最后一次了。

想继续往下挖，可以顺着这几条线走：

* 把 RelBench 的评测跑一遍，用你自己数仓的数据跟线上 XGBoost 做个 A/B——**这是唯一值得信的结论来源**
* 读 PQL 论文（[arXiv:2602.09572](https://arxiv.org/abs/2602.09572)）和 PluRel 论文（[arXiv:2602.04029](https://arxiv.org/abs/2602.04029)），理解「关系型预训练」这件事为什么成立
* 同库的 **Kumo Forecast**（时序预测，2026 年 10 月 21 日同日发布）、**Kumo Tabular**（表格）、**KumoAnomaly**（异常检测）都值得看，它们是同一套思路在不同数据形态上的延伸
* 关心 Agent 落地的，重点看 `structured-data-models-client` 在 Databricks 上的端到端示例——那才是这套东西最可能的归宿

更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。