NVIDIA Kumo Relational 在关系型数据上超越监督式机器学习，且无需训练

NVIDIA Kumo Relational 是一个预训练的关系型基础模型，可直接在企业数据库上进行预测。给定一个预测查询，它会收集最多 10,000 个历史样本作为上下文，并在单次前向传播中预测流失、需求或欺诈等结果。它不需要任务专用训练，不需要特征工程，也不需要将表展平。Kumo Relational 是首个在常见关系型基准上超越监督式机器学习的少样本基础模型。在 15 个数据库的 41 项任务中，它优于监督式关系深度模型和专家工程化的梯度提升树流水线，并且在 SAP SALT 企业基准上，其平均倒数排名（MRR）比 AutoGluon 集成高出 8%。它可扩展到 500B+ 行的数据库，并通过 NVIDIA 开源的、GPU 原生的 structured-data-models 库或作为 NVIDIA NIM，同时服务于人类和智能体。文档：https://docs.nvidia.com/sdgm/rfm/overview

基础模型已经改写了语言和视觉的规则。不久前，生产级 NLP 意味着每个任务一个专用模型，各自配备自己的分词、词形还原和 n-gram 流水线。LLM 使这套技术栈基本过时，原因有三：它们比最好的任务专用模型更准确、投入生产要简单得多，并且足够灵活，足以开启智能体应用的新时代。同样的转变现在正在结构化数据上发生。关系型数据库支撑着世界上最关键的业务决策，但在其上进行预测建模仍然需要数周的特征工程、任务专用训练和调优的流水线。结构化数据基础模型出于同样的三个原因改变了这一点：今天更高的准确率：作为即插即用的替代品，这些模型已经超越许多生产流水线，尤其是 XGBoost。在 RelBench V1 分类任务上，Kumo Relational 在专家工程特征上比梯度提升树平均高出近 4 个 AUROC 点。在 SAP SALT 上，它在工程特征上开箱即比 XGBoost 高出 7 个 MRR 点，微调后高出 13 个 MRR 点。这些结果有力地支持了用 Kumo Relational 取代生产 XGBoost 流水线。简单与敏捷：一个预训练模型取代针对各个任务的独立流水线。一个新的预测变成一次查询，而不是一个项目，因此 ML 团队终于可以在组织的各个层面承接传统 ML 因过于繁琐而无法构建的用例。能够预测的智能体：LLM 让智能体能够阅读、写入和推理。结构化数据基础模型让它们能够预判接下来会发生什么，例如哪个客户会流失，并据此采取行动。Kumo Relational 已经为被智能体调用而构建，其预测查询语言（PQL）为它们提供了一个简单的接口来提出预测性问题。今天，我们推出 Kumo Relational（论文、文档），这是一个预训练基础模型，将这一范式带入关系型数据。连接数据库，描述要预测什么，在单次前向传播中获得预测。无需训练。大多数结构化数据的基础模型只在单个扁平表上运行。真实世界的数据却存在于关系型数据库中：用户连接订单连接产品，并且都随时间演变。通过手动聚合（例如，过去 30 天的平均订单价值）将这些关系展平成一行，会丢失细粒度的结构信号，并耗费大量人力。Kumo Relational 是一个关系型基础模型，直接在数据库上运行，尊重其表、外键和时间戳。它在一个反映真实世界数据集的合成关系型数据上预训练一次，并通过上下文学习适应每个新任务，在推理时读取最多 10,000 个上下文样本。每个样本将一个实体在某时间点的局部子图与其真实目标配对（例如，这个用户 ch…

NVIDIA 推出预训练关系型基础模型 Kumo Relational，可直接连接企业数据库，在单次前向传播中完成流失、需求、欺诈等预测，无需任务专用训练、特征工程或表展平。在 15 个数据库的 41 项任务上，它超越监督式关系深度模型与专家工程化 GBDT 流水线；在 SAP SALT 企业基准上，其平均倒数排名（MRR）比 AutoGluon 集成高 8%，并可扩展至 500B+ 行规模。

• NVIDIA 推出预训练关系型基础模型 Kumo Relational，可直接连接企业数据库，在单次前向传播中完成流失、需求、欺诈等预测，无需任务专用训练、特征工程或表展平。在 15 个数据库的 41 项任务上，它超越监督式关系深度模型与专家工程化 GBDT 流水线；在 SAP SALT 企业基准上，其平均倒数排名（MRR）比 AutoGluon 集成高 8%，并可扩展至 500B+ 行规模。
• 原贴提到：NVIDIA Kumo Relational is a pre-trained relational foundation model that
• 来源：huggingface.co

这是什么信号

NVIDIA 把“基础模型 + 上下文学习”这套在语言和视觉上已经验证过的范式，正式搬到了关系型数据库上。Kumo Relational 的定位很明确：不是又一个需要数据团队清洗、展平、做特征、再训练的建模工具，而是一个已经预训练好的模型，接上数据库、用预测查询语言（PQL）描述要预测什么，就在单次前向传播里给出流失、需求、欺诈这类结果。推理时它读取最多 10,000 条历史样本作为上下文，靠 in-context learning 适配新任务，不需要任务专用训练，也不需要特征工程。

更值得注意的不是“能预测”，而是它给出的对标方式：在 15 个数据库的 41 项任务上对比监督式关系深度模型与专家工程化的梯度提升树流水线；在 RelBench V1 分类任务上比专家特征 GBDT 平均高约 4 个 AUROC 点；在 SAP SALT 上开箱比 XGBoost 高 7 个 MRR 点、微调后高 13 个 MRR 点，并比 AutoGluon 集成高 8% MRR。它直接点名要替代的对象是生产环境里的 XGBoost 流水线，而不是学术基线。这是一个非常具体的“替换主张”。

为什么重要

企业里绝大多数预测任务并不缺算法，缺的是把关系型数据变成可用特征的工程人力。用户连订单连产品、还要带时间窗口，真正有价值的结构信号往往在手动聚合“过去 30 天平均订单价值”这类操作中被压平丢掉。Kumo Relational 直接在库表、外键、时间戳上建模，等于把这块最脏最贵的工程量抽走。原文把它和 LLM 取代 NLP 专用流水线类比，逻辑是同一套：更准、更简单、更灵活。前两条决定它能否进生产，第三条决定它能否被智能体调用——LLM 让智能体能读、写、推理，结构化数据基础模型让智能体能预判下一步并行动，PQL 就是给智能体的那个简单接口。

还有两个工程事实值得记住：可扩展到 500B+ 行的数据库，以及同时以开源 GPU 原生库和 NVIDIA NIM 两种形态交付。前者决定它能不能碰核心业务库，后者决定它能不能被现有系统低成本集成。

对谁有价值

最直接的是企业 ML 平台与数据工程团队：手里有一堆建了半年还没上线的 XGBoost 用例，可以用它做替代性验证。其次是做智能体产品的团队：如果智能体只能“说”不能“算”，价值有限；能挂上一个预测接口，才谈得上闭环。第三是企业内部的业务分析岗和低代码用户：预测从“一个项目”变成“一次查询”，意味着需求不必全部堆到中央 ML 团队。对 ISV 和行业解决方案商同样有意义——把预测能力嵌进数据库侧产品，比自建模型流水线更快。

可以怎么行动

第一步不要全量替换，挑一条已经在生产跑、价值明确、当前用 XGBoost 的预测链路做影子对比：同一时间切面、同一标签定义，比 MRR/AUROC 之外还要比上线成本与查询延迟。第二步把评估重点放在“时间一致性”上，关系型数据的泄漏风险极高，验证集切分方式必须按时间走，否则基准上的优势在自己数据上会消失。第三步梳理哪些业务问题现在因为“做特征太麻烦”而被搁置，用 PQL 快速试一批，这类长尾用例才是这类模型真正的增量价值。第四步，如果团队在做智能体，把预测能力抽象成一个可调用工具，让智能体在推理链里直接发预测查询，而不是先查数再自己算。

风险与限制

需要冷静看待的地方不少。其一，公开结果集中在 RelBench V1 与 SAP SALT 两类基准，41 项任务听起来多，但与一家企业真实库的表结构、脏数据、标签噪声相比仍是受控环境，独立复现很重要。其二，预训练数据是“反映真实数据集的合成关系型数据”，合成数据与实际业务分布的偏移，恰恰会在最赚钱的长尾场景上暴露。其三，推理时要读取上万条上下文样本，单次查询的成本、延迟与并发能力必须实测，不能只看准确率。其四，把模型直接接到企业数据库意味着权限、脱敏与审计问题前置，谁能发起预测查询、读到哪些表，需要治理设计。其五，采用 PQL 与特定 NIM 形态存在一定绑定成本，迁移路径要提前想清楚。最后，原文对“无需训练”是一种简化表述，实际落地仍需标签定义、时间切分、阈值与业务校准，这些工作不会消失，只是从特征工程转移到问题定义与评估上。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 huggingface.co 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《NVIDIA Kumo Relational 在关系型数据上超越监督式机器学习，且无需训练》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Hugging Face Blog 原帖