英伟达发布 Kumo Relational，一款面向关系型数据库的预训练基础模型，能够直接利用多表、外键与时间戳等上下文进行少样本推理，减少为每个预测任务重新训练或压平表的需求。论文与基准测试显示其在多项任务上优于部分监督式基线，但实际生产效果仍需通过微调、验证与长期独立评测来检验。
英伟达（NVIDIA）发布了 Kumo Relational，一款面向关系型数据库的预训练基础模型。它不要求用户为每一个预测任务重新训练模型，也不要求先把多张相关表格压平成一张特征表，而是直接利用数据库中的表、外键关系、时间戳以及历史样本进行推理。
按照英伟达在 Hugging Face 发布的官方介绍，Kumo Relational 可以在一次前向推理中，使用最多 10,000 个历史示例作为上下文，完成客户流失、需求、欺诈等预测任务。该团队称，模型在 15 个关系型数据库的 41 项任务上击败了部分监督式关系学习模型和经过专家特征工程的梯度提升树流水线；在 SAP SALT 企业基准上，它相对于 AutoGluon 集成模型的平均倒数排名（MRR）提升了 8%。
不过，这些结果首先是论文和英伟达团队报告的基准测试结果，并不等同于模型已经在所有企业生产环境中取代 XGBoost 或其他传统机器学习系统。Kumo Relational 可以微调，且官方文档仍要求开发者根据具体行业和数据进行测试、验证与安全评估。
从“每个任务训练一个模型”转向“把预测写成查询”
企业数据库通常不是一张孤立的表。客户与订单相连，订单与商品相连，账户又可能与支付、客服或风险记录相连。传统机器学习要利用这些关系，往往需要先设计聚合特征，例如“过去 30 天的平均订单金额”或“最近一次交易距今天数”，再为具体任务训练和调优模型。
这种流程并非不可行，但成本很高。每增加一个预测问题，数据团队可能都需要重新定义标签、清洗数据、设计特征、选择模型、调整参数，并建立新的部署和监控流程。关系被压平之后，原始数据中的细粒度连接和时间顺序也可能被削弱。
Kumo Relational采用了不同的路径。用户通过 Predictive Query Language（PQL）描述要预测的对象和目标，系统根据数据库结构生成相关的历史上下文，再交给模型进行推理。换句话说，新预测任务在理想情况下更像是提出一个查询，而不是从头启动一个机器学习项目。
这一思路延续了基础模型在语言和视觉领域带来的变化：模型先通过大规模预训练获得通用能力，面对新任务时再利用输入上下文进行适配。但 Kumo Relational 的输入不是文本序列，而是具有表格、外键和时间关系的数据库子图。
模型如何直接理解多张相关表
英伟达团队在论文《KumoRFM-2: Scaling Foundation Models for Relational Learning》中，将关系型数据库描述为一个随时间变化的异构图。数据库中的记录可以看作节点，主键和外键之间的连接构成边；每个预测样本还对应一个时间点，模型只能使用该时间点之前可获得的数据。
这一区分对于企业预测很重要。如果模型在预测历史上的客户流失时意外读取了流失之后的订单或状态，就会产生数据泄漏，测试成绩也会失去意义。Kumo Relational的上下文生成机制会重放历史数据库状态，在锚定时间之前截取相关数据，并根据之后发生的事件计算目标标签。
模型的推理过程大致分为三个层次。第一层在单张表内处理列和行之间的关系，判断哪些字段和记录与当前任务有关；第二层通过图注意力沿着主键—外键关系传播信息，把客户、订单和商品等实体联系起来；第三层让带有已知目标的上下文样本与待预测实体互相参照。
这样的架构试图避免把每一个表格单元都进行昂贵的全连接计算。模型先形成行级表示，再在表与表之间传递这些表示，从而在更大的上下文和更深的关系图上保持可扩展性。
论文结果：少样本上下文击败部分监督式基线
KumoRFM-2的论文在 RelBench V1、RelBench V2、SAP SALT 和 4DBInfer 等数据集上进行了评估，覆盖电子商务、医疗、企业、社交和学术等领域。论文称，模型在 41 项预测任务上优于多种监督式模型和少样本基础模型。
在 RelBench V1 上，论文报告 KumoRFM-2 相比上一代模型提高约 10%，并在分类和回归任务上超过最接近的任务专用监督式关系图模型约 5%。在 SAP SALT 企业基准上，模型相对于大型 AutoGluon 集成模型的表现提升约 8%，相对于近期表格基础模型的表现提升约 25%；微调后，优势还会进一步扩大。
英伟达在介绍中还给出了更具体的比较：在 RelBench V1 分类任务中，Kumo Relational相对于基于专家特征工程的梯度提升树，平均 AUROC 高出接近 4 个百分点；在 SAP SALT 上，未经微调时相对于 XGBoost 的 MRR 高出 7 个百分点，微调后差距扩大到 13 个百分点。
需要注意的是，论文摘要和官方博客中的百分比通常是相对于特定基线和评测配置的相对比较。MRR、AUROC 和 Elo 等指标也不能直接互换，更不能简单转化为企业收入、风险下降或业务决策准确率。不同的数据切分、时间窗口、硬件和上下文采样方式，都会改变最终结果。
论文还报告称，模型在只使用约 0.2% 训练数据作为上下文时仍能保持一定能力；当最多 75% 的外键连接被移除，模型性能相对稳定；加入大量噪声列后，模型也没有出现明显退化。这些结果说明，研究团队关注的不只是完整数据条件下的排名，也包括冷启动、稀疏关系和噪声数据等企业常见问题。
5000亿行数据库与开源部署路径
Kumo Relational并不只面向内存中的小型数据集。论文称，模型可以连接 SQL 数据库和云数据仓库，数据处理既可以下推到底层数据库，也可以通过使用内存映射 I/O 的 SSD 图引擎完成。官方介绍给出的规模上限是支持包含 5000 亿行以上数据的数据库。
这里的“支持”主要描述数据访问和推理架构能够处理的规模，并不意味着模型会把 5000 亿行数据一次性装入 GPU，也不意味着任何企业数据库都能在相同延迟下完成预测。实际效果仍取决于查询范围、相关子图大小、硬件、数据仓库连接器和上下文生成策略。
开发者可以通过英伟达发布的 structured-data-models 代码库在 GPU 上使用模型。该库包含结构化数据的张量类型、数据处理组件以及 Kumo Relational 的参考实现；代码采用 Apache 2.0 许可证，模型权重则受 OpenMDW License Agreement 1.1 约束。
另一条路径是将模型作为 NVIDIA NIM 服务部署，再通过客户端提交结构化数据和 PQL 查询。英伟达的官方文档显示，Kumo Relational支持二分类、多分类、回归、预测和时间链接预测等任务，并可通过 Python 客户端返回预测、概率、评分、排名、分位数或诊断解释。
从产品布局看，Kumo Relational并不是英伟达在结构化数据上的孤立尝试。此前发布的 Kumo Tabular面向单张表格的分类和回归；同一系列的 Kumo Forecast则把预训练表示和历史模式检索结合到时间序列预测中。三者共同指向一个更广泛的方向：把传统上依赖专用流水线的结构化数据任务，逐步纳入可以复用的基础模型接口。
“无需训练”并不意味着无需验证
Kumo Relational最容易被误解的地方，可能是“无需训练”这句话。它准确描述的是：用户在面对一个新任务时，可以直接提供上下文样本进行少样本推理，而不必先为该任务更新模型参数。它不意味着企业可以跳过数据治理、标签审查、留出集测试、监控和模型校准。
英伟达团队也列出了模型的限制。对于训练数据非常多的任务，任务专用监督式模型仍可能超过最多使用 10,000 个上下文示例的少样本推理；这正是微调可能更合适的场景。此外，预测信号必须能够在有限跳数的关系图内被访问，因此查询应从少量相关表开始，而不是无条件地把整个数据库连接起来。
模型还依赖关系本身具有预测价值。如果外键连接质量很差、时间记录不完整、标签定义不稳定，模型即使能够读取这些关系，也未必能得到可靠的业务结论。对于金融、医疗、保险和供应链等高风险场景，预测准确率之外，还需要检查数据权限、审计记录、解释信息和错误决策的处理机制。
这意味着 Kumo Relational 的现实价值，可能首先体现在降低试验门槛和缩短建模周期，而不是立即取代所有传统机器学习系统。企业可以用它快速评估一个新的预测问题是否值得投入，再决定是否进行微调、建立专用模型，或继续使用已经经过长期验证的 XGBoost、随机森林和关系图模型。
结构化数据基础模型的下一场竞争
语言模型让智能体能够阅读、写作和调用工具，但一个真正参与企业流程的智能体，还需要判断下一步可能发生什么：哪个客户可能流失，哪笔交易风险更高，某类库存是否即将短缺，或一项服务请求是否可能升级。
Kumo Relational试图把这种预测能力接入智能体。通过 PQL，智能体可以提出结构化的预测问题；模型则从企业数据库中提取相关上下文，返回概率、排名或预测结果。这样，智能体不只是对已经发生的事实进行总结，也可以把预测结果纳入后续行动。
但这条路线的关键考验仍在生产环境。未来需要观察的不是模型能否在论文基准上击败某个基线，而是它能否在时间分布变化、行业迁移、标签延迟、权限限制和历史模式失效的条件下保持稳定。只有当这些问题被长期验证，关系型基础模型才可能从“快速预测工具”变成企业数据库上的通用决策层。
目前可以确认的是，英伟达正在把结构化数据视为基础模型竞争的新战场。Kumo Relational的发布，把这场竞争从单表分类进一步推进到多表关系、时间一致性以及面向智能体的预测接口；它能否兑现“把预测从项目变成查询”的承诺，则仍需要更多独立评测和真实业务数据来回答。