NVIDIA Kumo Relational supera al ML supervisado en 41 tareas sin entrenamiento

NVIDIA ha publicado Kumo Relational, un modelo foundation relacional preentrenado que hace predicciones directamente sobre la base de datos corporativa. El usuario describe qué quiere predecir y obtiene el resultado en un único pase hacia delante, sin entrenamiento para cada tarea, sin agregados manuales y sin aplanar las tablas. En 41 tareas de 15 bases de datos, el modelo superó a los modelos supervisados y al gradient boosting con características de experto. En SAP SALT supera en un 8% a los grandes ensembles de AutoGluon en mean reciprocal rank. Entre los autores figuran Jure Leskovec y Matthias Fey, y el trabajo se publicó junto con el equipo de Kumo.

La predicción como consulta, no como proyecto

Lo habitual para una tarea como el abandono de clientes lleva semanas. Los ingenieros calculan el «ticket medio de 30 días», unen users, orders y products en una sola fila, configuran XGBoost y mantienen el pipeline. Kumo Relational funciona de otra manera: lee las tablas, las claves externas y las marcas temporales tal cual. La tarea se formula en Predictive Query Language, por ejemplo `PREDICT COUNT(orders.*, 0, 30, days) FOR EACH users.user_id`.

El sistema construye el contexto por sí mismo. Toma ejemplos históricos, recorta alrededor de cada entidad un subgrafo local en un momento concreto del tiempo y añade el resultado conocido, como «el usuario se fue» o «el producto se vendió 142 veces». En las tareas temporales, la base se reproduce según sus estados históricos: el modelo solo ve los datos anteriores a la marca ancla, y el objetivo se calcula con los eventos posteriores. La fuga de datos del futuro queda descartada por diseño.

La arquitectura tiene dos etapas. Una red ligera procesa cada tabla por separado mediante column attention y row attention y filtra el ruido. Después, una red más grande propaga los embeddings de las filas por la estructura de la base mediante graph attention sobre las relaciones de claves primarias y externas, y a continuación aplica cross-sample attention entre los ejemplos de contexto. Como la segunda etapa opera sobre embeddings de filas y no sobre cada celda, no hay coste cuadrático, y los contextos con subgrafos profundos siguen siendo manejables.

Datos sintéticos en lugar de bases cerradas

Casi no hay bases relacionales diversas en abierto para el preentrenamiento, así que el modelo se entrenó íntegramente con datos sintéticos. El generador se apoya en PluRel (Kothapalli et al., ICML 2026) y construye una base en tres pasos: el esquema, las relaciones entre filas con una agrupación realista y los valores de las columnas a partir de modelos causales estructurales, con tendencias temporales y dependencias entre tablas.

Generar es barato, de modo que la cantidad de datos para el preentrenamiento es prácticamente ilimitada. La pérdida (loss) baja según una ley de potencias a medida que se añaden bases, y la mejora se traslada a los datos reales. El entrenamiento avanza por etapas: de tablas individuales a estructuras relacionales complejas.

La evaluación se hizo con datasets que el modelo no había visto: RelBench V1 y V2, SAP SALT y 4DBInfer. Cubren comercio electrónico, medicina, empresa, redes sociales y datos académicos.

• 41 tareas en 15 bases relacionales.
• RelBench V1, clasificación: unos 4 puntos de AUROC por encima del gradient boosting con características de experto.
• SAP SALT: 7 puntos de MRR por encima de XGBoost con características de ingeniería listas para usar, y 13 puntos tras el ajuste fino.
• SAP SALT frente a los grandes ensembles de AutoGluon: un 8% más de MRR, y un 16% más tras el fine-tuning.
• RelArena-α (leaderboard a 21.09.2026): el modelo está en el frente de Pareto de precisión y velocidad, unas 430 veces más rápido que rtl-plurel con una precisión comparable.
• Robustez: funciona con un 0,2% de los datos de entrenamiento en el contexto, aguanta la eliminación de hasta el 75% de las relaciones por clave externa y apenas se degrada al añadir columnas de ruido.
• Escala: kumo-engine procesa bases de más de 500 mil millones de filas mediante memory-mapped I/O a una velocidad de hasta 5 GB/s.

Los propios autores señalan las limitaciones. El modelo rinde mejor donde hay relaciones con significado y dinámica temporal, por ejemplo en el comportamiento de los usuarios. En tareas con muestras de entrenamiento muy grandes, los modelos supervisados especializados pueden salir ganando. La señal predictiva tiene que estar dentro de un número limitado de saltos por las relaciones.

Cómo ponerlo en marcha y dónde ahorrar

El principal ahorro está en las horas de ingeniería, no en tokens. En lugar de un pipeline distinto para cada tarea, hay un único modelo y un conjunto de consultas. Una nueva predicción se reduce a una línea de PQL, y los equipos pueden abordar casos que antes no compensaban el desarrollo. Para los agentes, PQL sirve como interfaz sencilla: el LLM lee y razona, y Kumo Relational aporta la predicción, por ejemplo qué cliente se irá.

Hay tres vías de uso. La primera es la biblioteca abierta nativa para GPU structured-data-models (`pip install structured-data-models`), donde `sdm.models.KumoRelational(device="cuda")` acepta tablas de contexto, tablas de consulta y tablas relacionadas. Los pesos se descargan de Hugging Face Hub en el primer uso. La segunda es el despliegue como NVIDIA NIM con el cliente structured-data-models-client, donde la consulta PQL y el DataFrame de pandas se convierten en contexto de forma automática. El repositorio incluye notebooks para NIM local y para Databricks. La tercera es kumo-engine, con conectores a bases de datos y almacenes para grandes volúmenes.

El código se publica bajo Apache 2.0 y los pesos bajo OpenMDW License Agreement 1.1. La prueba práctica es sencilla: tome una tarea de producción resuelta con XGBoost, como el abandono o la demanda, ejecútela en Kumo Relational y compare las métricas y el tiempo de desarrollo. Si la señal en los datos está a un par de saltos por claves, lo más probable es que se pueda sustituir el pipeline.