遇码MeetCoding

Appearance

认识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）。

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

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），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
PyPIhttps://pypi.org/project/structured-data-models/
客户端代码https://github.com/NVIDIA/structured-data-models-client
权重（OpenMDW 1.1）https://huggingface.co/nvidia/Kumo-Relational
快速上手 notebookstructured-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）和 PluRel 论文（arXiv:2602.04029），理解「关系型预训练」这件事为什么成立
  • 同库的 Kumo Forecast（时序预测，2026 年 10 月 21 日同日发布）、Kumo Tabular（表格）、KumoAnomaly（异常检测）都值得看，它们是同一套思路在不同数据形态上的延伸
  • 关心 Agent 落地的，重点看 structured-data-models-client 在 Databricks 上的端到端示例——那才是这套东西最可能的归宿

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

遇码MeetCoding 开源技术社区

Copyright © 2024 meetcoding.cn All Rights Reserved. 遇码科技 版权所有

ChatGPT中文文档Gemini中文文档AI助力高考志愿填报Flet中文文档长网页一键截图Mojo🔥中文文档