Comparar Models Fundacionales Relacionales

Evaluamos SAP-RPT-1-OSS frente a gradient boosting (LightGBM, CatBoost) en 17 datasets tabulares que abarcan el espectro semántico-numérico, tablas pequeñas/altamente semánticas, datasets empresariales mixtos y datasets numéricos grandes de baja semántica.

Nuestro objetivo es medir dónde los priors semánticos preentrenados de un LLM relacional pueden ofrecer ventajas sobre los tree models tradicionales y dónde enfrentan desafíos bajo escala o estructura de baja semántica.

SAP-RPT-1-OSS frente a Gradient Boosting: Resultados del benchmark

• Tasa de éxito: Representa la puntuación normalizada promedio (de 0.0 a 1.0). Una barra más alta indica que el model se acerca de manera consistente al mejor rendimiento posible para los datasets de esa categoría.
• 100 – 500 filas (3 Datasets):
  • Incluidos: wine (178), sonar (208), vote (435).
  • Resultado: SAP rinde mejor en 2 de 3 datasets. Logra las puntuaciones más altas en wine y sonar, lo que sugiere que los priors del LLM pueden ser beneficiosos cuando los datos de entrenamiento son escasos. Sin embargo, CatBoost consiguió una victoria ajustada en el dataset vote (dentro del 0,1 %), lo que indica que los tree models siguen siendo muy competitivos incluso a pequeña escala.
• 501 – 1.000 filas (3 Datasets):
  • Incluidos: cylinder_bands (540), breast_cancer (569), credit_g (1.000).
  • Resultado: SAP rinde mejor en los 3 datasets. En cylinder_bands, SAP superó a LightGBM por un margen del 5,5 %, posiblemente debido a un mejor manejo de las descripciones semánticas de defectos industriales, aunque se necesitarían más estudios de ablación para confirmar este mecanismo.
• 1.000 – 10.000 filas (5 Datasets):
  • Incluidos: titanic (1.3K), car_evaluation (1.7K), spambase (4.6K), compas (5.2K), employee_salaries (9.2K).
  • Resultado: SAP logra los mejores resultados en 4 de 5 datasets, con un rendimiento especialmente bueno en tareas con mucho texto como spambase y titanic. Sin embargo, CatBoost supera significativamente a SAP en compas por 10,4 %, lo que indica características específicas del dataset que favorecen a los tree models incluso en este rango de tamaño.
• 10.000+ filas (6 Datasets):
  • Incluidos: california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs_100k (98K).
  • Resultado: A medida que crece el volumen de datos, la posible ventaja de “conocimiento previo” del LLM disminuye. LightGBM y CatBoost logran los mejores resultados en 5 de 6 datasets, ofreciendo mejor precisión a una fracción del coste computacional. La única excepción, california_housing, muestra una ventaja modesta del 1,7 % para SAP.

1. Tabla de datasets de resultados del benchmark

A continuación se muestra el desglose completo del rendimiento del model en todos los 17 datasets.

2. Análisis de coste y eficiencia

Calculamos el coste computacional directo de cada model basándonos en el precio de la instancia RunPod H200 de $3,59/hora.

SAP-RPT-1-OSS incurre en costes significativamente más altos debido al tiempo necesario para el preprocesamiento de text embedding y la gran sobrecarga de memoria de la arquitectura del LLM. Por el contrario, LightGBM y CatBoost completan las tareas casi instantáneamente en este hardware. Los costes a continuación reflejan el tiempo total de reloj (preprocesamiento + entrenamiento) para una ejecución de validación cruzada de 3 pliegues.

Coste promedio por dataset (Promedio de 17 Datasets)

Desglose de costes por tamaño de dataset

• Datasets pequeños (<1K filas): SAP es relativamente barato (≈ $0,03 por ejecución). La alta tasa de victorias aquí hace que el coste sea insignificante.
• Datasets grandes (>20K filas): SAP se vuelve caro.
  • Ejemplo: Entrenar con adult_income (48k filas) toma ≈$12 minutos en total para 3 pliegues.
  • Coste: 12 min X $0,06/min = $0,72 por experimento.
  • Comparación: LightGBM termina la misma tarea por $0,01.

Conclusión: Aunque $0,22 por dataset no es caro en términos absolutos, SAP es 22x más caro que la línea base. Esta diferencia de coste puede estar justificada para datasets pequeños y ricos en semántica donde SAP muestra mejoras de precisión significativas (por ejemplo, cylinder_bands con una mejora de +5,5 %), pero resulta más difícil de justificar para datasets grandes donde los tree models logran un rendimiento igual o mejor a una fracción del coste.

3. Analysis framework: el espectro semántico

Para interpretar estos resultados, es crucial entender cómo seleccionamos los datos. No elegimos datasets al azar; seleccionamos un conjunto de 17 datasets específicamente elegidos para abarcar el espectro semántico-numérico.

Nuestra hipótesis principal era que SAP (al estar basado en LLM) destacaría donde los datos tienen significado lingüístico, mientras que los Tree models dominarían en el cálculo numérico puro. Categorizamos nuestros datasets en tres clústeres distintos:

Clúster A: datasets de alta semántica (6 datasets)

Características: Las features contienen descripciones de texto enriquecidas, etiquetas categóricas con significado del mundo real (por ejemplo, “congelación de honorarios médicos”) o terminología específica del dominio.

• Datasets:
  • cylinder_bands: defectos de impresión industrial.
  • titanic: nombres y títulos de pasajeros.
  • vote: registros de votación del Congreso (categóricos “Sí/No” sobre políticas).
  • breast_cancer: descripciones médicas de tumores.
  • spambase: frecuencias de palabras en correos electrónicos.
  • wine: orígenes químicos.

Clúster B: datos empresariales mixtos (6 datasets)

Características: El formato tabular estándar que se encuentra en la mayoría de las bases de datos empresariales, una mezcla de valores numéricos (salario, edad) y cadenas categóricas (puesto de trabajo, raza, departamento).

• Datasets:
  • employee_salaries: puestos de trabajo frente a salario.
  • compas: historial delictivo y demografía (atributos sensibles).
  • adult_income: demografía censal.
  • credit_g: perfiles de riesgo crediticio alemanes.
  • default_credit: datos de impago de crédito de Taiwán.
  • car_evaluation: parámetros de compra de vehículos.

Clúster C: datos de baja semántica/numéricos puros (5 datasets)

Características: Las features son mediciones abstractas, lecturas de sensores o coordenadas físicas. Los nombres de las columnas a menudo no importan; lo que importa son las relaciones matemáticas.

• Datasets:
  • higgs_100k: cinemática de partículas físicas.
  • diamonds: dimensiones físicas y precio.
  • sonar: rebotes de energía de frecuencia.
  • california_housing: coordenadas Lat/Long y estadísticas censales.
  • house_sales: bienes raíces del condado de King (principalmente features numéricas).

4. Análisis profundo: dónde SAP gana y dónde falla

Aplicar el analysis framework a nuestros resultados revela cuatro patrones de rendimiento distintos. La tabla siguiente resume exactamente dónde destaca SAP y dónde falla.

Fundamentos conceptuales de los relational foundation models

El objetivo principal de un relational foundation model es hacer predicciones precisas y realizar tareas diversas sobre tablas estructuradas. Estos models deben comprender cómo se representa la información en diferentes tablas, cómo se vinculan las entidades mediante relaciones y cómo la información temporal influye en los resultados.

Las capacidades clave de estos models incluyen:

• Generalización de esquemas: La capacidad de adaptarse a nuevos esquemas relacionales sin reentrenar desde cero.
• Representación de entrada unificada: Manejar diferentes tipos de columnas como features numéricas, categóricas y textuales.
• Integración del contexto temporal y estructural: Capturar dependencias a lo largo del tiempo y entre entidades vinculadas por claves primarias y foráneas.
• Transferibilidad: Realizar tareas predictivas en nuevos datasets mediante pre-training y aprendizaje zero-shot.

Griffin

Griffin es uno de los primeros intentos a gran escala de construir un relational foundation model unificado. Representa los datos relacionales como un grafo temporal y heterogéneo, donde cada fila se convierte en un nodo y las aristas corresponden a relaciones de clave foránea. Las features clave incluyen:

Codificador de features unificado

• Las features categóricas y de texto se codifican con un text encoder preentrenado, mientras que los valores numéricos utilizan un float encoder aprendido.
• Los metadatos, como nombres de tablas, nombres de columnas y tipos de aristas, se incrustan para ayudar al model a reconocer el esquema relacional.
• Los task embeddings permiten que un único model realice tareas de regresión y clasificación con decodificadores compartidos.

Paso de mensajes y atención

Griffin integra redes neuronales de paso de mensajes con un módulo de cross-attention. El componente de paso de mensajes agrega información dentro de las relaciones y entre ellas, mientras que la cross-attention se centra en las celdas relevantes de cada fila. Este diseño ayuda al model a manejar datos diversos y mantener el contexto entre entidades conectadas.

Pre-training y fine-tuning

El model se preentrena en datasets de una sola tabla mediante una tarea de completado de celdas enmascaradas y luego se fine-tuned en bases de datos relacionales para tareas específicas. Los experimentos en benchmarks relacionales grandes muestran que Griffin supera a los baselines GNN tradicionales y a los single-table models tanto en precisión como en eficiencia de transferencia de aprendizaje.

Figura 1: Gráfico que muestra el Griffin Model Framework.¹

Relational transformer

Mientras que Griffin se centra en la agregación de grafos, el Relational Transformer (RT) aplica arquitecturas transformer directamente a bases de datos relacionales. Trata cada celda como un token enriquecido con su valor, nombre de columna y nombre de tabla.

Representación de entrada

Cada token combina:

• Un value embedding que depende de su tipo de dato (numérico, texto o fecha/hora).
• Se genera un schema embedding a partir del texto de la tabla y la columna.
• Se utiliza un mask token cuando el valor está oculto durante el pre-training.

Esta estructura permite a RT procesar bases de datos relacionales con diferentes esquemas manteniendo un formato de entrada consistente.

Atención relacional

RT introduce un mecanismo de atención relacional que opera a nivel de celda. Incluye:

• Atención de columna para aprender distribuciones de valores dentro de las columnas.
• Atención de features para combinar atributos dentro de la misma fila o filas padre vinculadas.
• Atención de vecinos para agregar información de las filas hijas conectadas.

Together, estas capas de atención forman un relational graph transformer que modela dependencias entre filas, columnas y tablas.

Resultados de entrenamiento y transferencia

RT se preentrena en bases de datos relacionales de RelBench. En los experimentos, el model preentrenado alcanzó hasta 94 % del rendimiento de los models totalmente supervisados en configuraciones zero-shot. También aprendió más rápido durante el fine-tuning, requiriendo menos pasos de entrenamiento para alcanzar una alta precisión.²

Este enfoque sugiere que las bases de datos relacionales comparten patrones transferibles entre dominios y que la tokenización a nivel de celda proporciona una base práctica para tareas predictivas en datos estructurados.

RelBench

RelBench está diseñado para impulsar el relational deep learning, que se centra en el aprendizaje de extremo a extremo a partir de datos distribuidos en múltiples tablas relacionadas en bases de datos relacionales.

Dado que las bases de datos relacionales siguen siendo el sistema de gestión de datos dominante en la industria y la ciencia, RelBench proporciona un framework estandarizado y reproducible para evaluar models que operan directamente sobre estructuras relacionales en lugar de depender del aplanamiento manual de features.

Las versiones anteriores de RelBench introdujeron 11 bases de datos relacionales que abarcan dominios como la atención sanitaria, las redes sociales, el comercio electrónico y los deportes, con 70 tareas predictivas diseñadas para ser desafiantes y relevantes para el dominio.³

En enero de 2026 se lanzó RelBench v2, que añadió cuatro bases de datos nuevas (SALT, RateBeer, arXiv y MIMIC-IV) y 40 tareas predictivas adicionales, incluida una nueva clase de tareas Autocomplete que evalúan la capacidad de un model para predecir columnas existentes dentro de una base de datos relacional.

El lanzamiento también amplió el acceso a los datos mediante la integración de CTU, lo que permite acceder a más de 70 datasets relacionales a través de ReDeLEx; añadió conectividad directa a bases de datos SQL; e incorporó siete datasets del repositorio 4DBInfer en formato RelBench.

Más allá de los datasets y las tareas, RelBench ofrece una implementación de referencia de código abierto para relational deep learning basada en redes neuronales de grafos, usando PyTorch Geometric para la construcción de grafos y PyTorch Frame para el modelado tabular, junto con una tabla de clasificación pública para seguir el progreso.

El lanzamiento de v2 también introdujo múltiples mejoras de usabilidad y rendimiento, incluidas etiquetas censuradas por tiempo opcionales, soporte para la métrica NDCG en la predicción de enlaces, generación de sentence embeddings más rápida y gestión de caché configurable.⁴

VIEIRA

VIEIRA adopta un enfoque diferente al centrarse en programar con foundation models en lugar de construir un único motor predictivo. Extiende el compilador de lógica probabilística SCALLOP con un lenguaje declarativo que integra large language models, vision models y otros componentes preentrenados como predicados externos.⁵

Paradigma relacional

En VIEIRA, los foundation models se tratan como funciones sin estado con entradas y salidas relacionales. Esto permite componer models como GPT, CLIP o SAM según reglas lógicas. Por ejemplo:

• Un programa puede usar GPT para extraer conocimiento de texto y almacenarlo como relaciones estructuradas.
• CLIP puede clasificar imágenes y vincularlas a etiquetas textuales en una tabla.

Aplicaciones

El framework soporta:

• Razonamiento de fechas y matemáticas con GPT.
• Razonamiento de parentesco mediante extracción de texto e inferencia lógica.
• Respuesta a preguntas que combina recuperación y razonamiento.
• Respuesta visual a preguntas y edición de imágenes mediante composición multimodal.

Al unificar la lógica simbólica y la inferencia neuronal, VIEIRA permite a los analistas de datos y desarrolladores construir sistemas interpretables que utilizan foundation models preentrenados para responder consultas predictivas sobre datos estructurados e imágenes.

No te pierdas nuestros análisis comparativos e insights basados en datos. El botón abre Google; seleccionar AIMultiple confirma que deseas ver AIMultiple con más frecuencia en los resultados de búsqueda de Google.

Añadir como fuente preferida

Casos de estudio

SAP Hana Cloud

SAP HANA Cloud es un servicio de base de datos como servicio totalmente gestionado y nativo de la nube, diseñado para actuar como una base de datos unificada para aplicaciones empresariales que combinan transacciones, analítica e IA. En lugar de servir como una base de datos relacional de un solo propósito, SAP HANA Cloud se posiciona como una plataforma multi-model que permite a las organizaciones construir “aplicaciones de datos inteligentes” sobre datos empresariales operativos.

SAP HANA Cloud combina procesamiento en memoria con almacenamiento basado en disco e integración de data lake para soportar diferentes requisitos de rendimiento y coste. Este diseño flexible soporta cargas de trabajo en tiempo real mientras escala dinámicamente a medida que fluctúan los volúmenes de datos y el uso.

Un diferenciador clave es su motor multi-model nativo, que soporta datos relacionales, JSON/documentos, grafos, espaciales y vectoriales dentro de una única base de datos. Esto permite a las aplicaciones combinar consultas SQL, relaciones de grafos y búsqueda de similitud vectorial sin mover datos entre sistemas separados, simplificando así la arquitectura y reduciendo la latencia.

Como parte de SAP Business Technology Platform, SAP HANA Cloud se integra directamente con fuentes de datos SAP y no SAP, incluido el acceso en vivo sin replicación, y proporciona seguridad, disponibilidad y cumplimiento de nivel empresarial por defecto.

En general, SAP HANA Cloud es una plataforma de datos centrada en lo relacional y nativa de IA en la que la base de datos relacional sirve como capa fundacional para analítica, datos multi-model y aplicaciones de IA empresariales.

Figura 2: Imagen que muestra la base de datos unificada de Hana y
el procesamiento de datos multi-model.⁶

SAP’s sap-rpt-1

sap-rpt-1 introduce un único relational foundation model que realiza una amplia gama de tareas predictivas mediante in-context learning. En lugar de reentrenar un nuevo model para cada caso de uso, los usuarios proporcionan algunos ejemplos de su patrón objetivo, como “clientes que pagaron a tiempo” y “clientes que pagaron tarde”. El model reconoce entonces el patrón y produce inmediatamente predicciones precisas para nuevos datos.

El model está diseñado con un mecanismo de atención bidimensional que captura relaciones entre filas y columnas, al tiempo que incrusta metadatos, como nombres de tablas y columnas, en vector embeddings. Este diseño le permite comprender la semántica de los esquemas relacionales y la información temporal dentro de las tablas empresariales.

El enfoque de SAP aporta varias ventajas para los analistas de datos y usuarios empresariales:

• Un único model que funciona en múltiples tablas y dominios.
• No hay necesidad de fine-tuning repetido ni desarrollo personalizado.
• Acceso a perspectivas predictivas en minutos en lugar de semanas.
• Integración con los data warehouses y sistemas SAP existentes.

Al integrar sap-rpt-1 en el ecosistema SAP, los expertos empresariales pueden interactuar directamente con sus propios datos y recibir predicciones a través de interfaces intuitivas. El resultado es un camino más rápido desde los datos estructurados hasta decisiones accionables sin ingeniería de features manual.

Figura 3: Factor de reducción de errores de sap-rpt-1-large frente a las líneas base de IA estrecha en los dominios de SAP.

A finales de 2025, SAP confirmó que SAP-RPT-1 está disponible a través del hub de IA generativa en SAP IA Foundation (SAP IA Core).

El model se ofrece en dos variantes de producción:

• SAP-RPT-1-small, optimizado para predicciones de baja latencia y alto rendimiento,
• SAP-RPT-1-large, diseñado para priorizar la precisión predictiva.

Este lanzamiento formaliza el papel de SAP-RPT-1 como un foundation model desplegable dentro del stack de IA empresarial de SAP, en lugar de una capacidad solo de investigación.

Además, SAP ofrece SAP-RPT Playground, un entorno web no-code en el que los usuarios pueden probar el in-context learning con sus propios datos de muestra o con los proporcionados por SAP.

SAP-ABAP-1

SAP-ABAP-1 es un foundation model diseñado para soportar casos de uso de productividad de desarrolladores basados en IA para clientes y socios de SAP.

Está disponible a través del hub de IA generativa de SAP y está entrenado con más de 250 millones de líneas de código ABAP, 30 millones de líneas de código CDS y extensa documentación técnica. El model está optimizado para comprender y explicar código ABAP, mostrar las mejores prácticas y proporcionar acceso a conocimiento de desarrollo SAP actualizado.

SAP ofrece acceso de prueba gratis a SAP-ABAP-1 a través del hub de IA generativa, con capacidades adicionales previstas para su lanzamiento en 2026.⁷

KumoRFM de Kumo.IA: un relational graph transformer para analítica predictiva

Kumo.IA, fundada por el profesor de Stanford Jure Leskovec, creó KumoRFM, un relational foundation model que utiliza un relational graph transformer para analizar bases de datos relacionales y data warehouses. Representa los datos relacionales como un grafo temporal y heterogéneo, donde cada entidad es un nodo y las claves primarias y foráneas forman aristas entre tablas.

Este enfoque basado en grafos permite a KumoRFM aprender de múltiples tablas simultáneamente y adaptarse a nuevos esquemas relacionales. El model está preentrenado con fuentes de datos diversas y puede generalizar a nuevos datasets sin crear models separados para cada tarea predictiva.

KumoRFM se puede utilizar a través de diferentes interfaces según la experiencia del usuario:

• PQL (Predictive Query Language): Un lenguaje de consulta especializado para definir consultas predictivas sobre datos estructurados.
• Interfaz de lenguaje natural: Para usuarios no técnicos, las entradas en lenguaje natural se traducen automáticamente a consultas PQL.
• Python SDK: Permite a los desarrolladores integrar el model en pipelines y aplicaciones de IA empresarial.

La arquitectura de KumoRFM muestrea dinámicamente la base de datos para crear subgrafos de contexto y subgrafos de predicción. Estos subgrafos son procesados por el relational graph transformer, que captura dependencias e información temporal entre entidades relacionadas. Mediante in-context learning, el model proporciona predicciones precisas y puede explicar su proceso de razonamiento.

Kumo ofrece dos opciones de implementación adecuadas para entornos empresariales:

• Plataforma SaaS: Un servicio basado en la nube construido sobre Apache Spark para facilitar el acceso y el escalado
• Nativo de data warehouse: Permite a las organizaciones usar sus propios datos en Snowflake o Databricks sin sacarlos de su entorno seguro

A diferencia de los knowledge graphs tradicionales que requieren una definición manual del esquema, KumoRFM construye automáticamente su grafo relacional a partir de fuentes estructuradas. Esto lo hace muy adecuado para eCommerce, finanzas y salud, donde las relaciones, los patrones temporales y el contexto cambiante son esenciales para predicciones fiables.

Las capacidades clave de KumoRFM incluyen:

• Flexibilidad entre diferentes tablas y estructuras de esquemas.
• Compatibilidad con una variedad de tipos de columnas e identificadores personalizados.
• Adaptación a tareas específicas durante el tiempo de inference.
• Alta precisión e interpretabilidad en tareas predictivas.

Figura 4: La imagen muestra cómo funcionan los Relational Foundation Models (RFMs) en múltiples dominios, como eCommerce, finanzas y salud, para hacer predicciones, proporcionar explicaciones y evaluar resultados.⁸

Metodología del benchmark

Configuración y entorno del benchmark

Para garantizar comparaciones justas entre los árboles limitados por CPU y los models acelerados por GPU, utilizamos un entorno de alto rendimiento capaz de manejar ambos de manera eficiente.

• Hardware: Instancia RunPod con una NVIDIA H200 140GB GPU.
• Software: Python 3.12 con librerías fijadas para reproducibilidad:
  • scikit-learn 1.5.2, lightgbm 4.5.0, catboost 1.2.7
  • torch 2.5.1, pandas 2.2.3, numpy 2.1.3
  • sap-rpt-oss (Fuente: GitHub oficial)
• Reproducibilidad: se utilizó random_state=42 de manera consistente en todas las divisiones, inicializaciones y models.

Datasets: el espectro semántico

Evaluamos los models en 17 datasets de aprendizaje supervisado provenientes de OpenML y Scikit-Learn. En lugar de una selección aleatoria, seleccionamos este conjunto para abarcar el “espectro semántico-numérico”, probando la hipótesis de que los LLMs destacan donde las features contienen significado lingüístico en lugar de estadísticas crudas.

El inventario:

• Pequeños y semánticos (<1K filas):
  • wine (178), sonar (208), vote (435), cylinder_bands (540), breast_cancer (569).
• Medianos/mixtos (1K – 10K filas):
  • credit_g (1K), titanic (1.3K), car_evaluation (1.7K), spambase (4.6K), compas (5.2K), employee_salaries (9.2K).
• Grandes/numéricos (10K+ filas):
  • california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs (muestreado a 100K).

Tareas cubiertas:

• 11 tareas de clasificación binaria
• 2 tareas de clasificación multiclase
• 4 tareas de regresión

Configuraciones del model y preprocesamiento

Buscábamos una “comparación realista de profesionales”, usando valores predeterminados sólidos en lugar de un ajuste exhaustivo de hiperparámetros.

LightGBM y CatBoost

Para garantizar una comparación justa con el model SAP computacionalmente pesado, aumentamos los estimadores predeterminados robustos.

• LightGBM: n_estimators=500, learning_rate=0.05, num_leaves=31. Se ejecuta en CPU (n_jobs=-1).
• CatBoost: iterations=500, learning_rate=0.05, depth=6. Se ejecuta en GPU (task_type=”GPU”).
• Preprocesamiento: Label Encoding simple para categóricas; sin escalado para numéricas; imputación de mediana/moda para valores faltantes.

SAP-RPT-1-OSS

Configuramos SAP para equilibrar rendimiento y coste en base a nuestros experimentos de configuración preliminares.

• Configuración: max_context_size=4096, bagging=4.
• Nota:
  • Contexto: Las pruebas con adult_income mostraron que aumentar el contexto de 4096 a 8192 triplicaba el tiempo de ejecución (de 4 min a 12 min) para una ganancia de precisión insignificante (0.917 frente a 0.917 ROC-AUC).
  • Bagging: Aumentar el bagging de 4 a 8 (la configuración predeterminada de SAP utilizada en el artículo⁹) ofrecía rendimientos decrecientes.
• Preprocesamiento: Ninguno. El DataFrame crudo de pandas se pasa directamente. El model codifica usando text embeddings (sentence-transformers/all-MiniLM-L6-v2).

Protocolo de evaluación

Estrategia de validación cruzada

Utilizamos validación cruzada de 3 pliegues con barajado.

• Redujimos el estándar de 5 pliegues a 3 pliegues para adaptarnos a los tiempos lentos de inference de SAP (40 % de ahorro de tiempo) manteniendo la validez estadística.
• División: StratifiedKFold para clasificación; K-Fold estándar para regresión.

Métricas y diagnóstico

Fuimos más allá de la simple precisión para capturar una visión holística del rendimiento del model:

• Métricas de clasificación principales: ROC-AUC (Binaria), Precisión equilibrada (Multiclase), R² (Regresión).
• Diagnósticos secundarios: Realizamos un seguimiento del coeficiente de correlación de Matthews (MCC) y de la log loss para asegurar que las victorias no fueran artefactos del desequilibrio de clases, y de MAPE para la calibración del error de regresión.
• Cálculo de costes: Basado en el tiempo total de reloj (preprocesamiento + entrenamiento + inference) en la instancia RunPod H200 ($3,59/h).

Significación estadística

Aplicamos una prueba de rangos con signo de Wilcoxon (p<0.05) a comparaciones de models por pares para determinar si las diferencias de rendimiento eran estadísticamente significativas o ruido aleatorio.

Limitaciones y validez interna

Reconocemos explícitamente las siguientes restricciones en nuestra metodología:

1. Configuraciones estandarizadas frente a ajuste: Utilizamos configuraciones predeterminadas fijas y sólidas para todos los models en lugar de realizar una optimización exhaustiva de hiperparámetros (por ejemplo, CV anidado o barridos con Optuna). Si bien esto garantiza una línea base consistente, vale la pena señalar que los Tree models a menudo obtienen mejoras de rendimiento con un ajuste específico del dataset, lo que podría reducir los márgenes en el clúster “Competitivo”.
2. Límites de escala de datos: Nuestro análisis se centró en datasets de menos de 100k filas para simular escenarios empresariales típicos de tamaño medio. Observamos que la ventaja del LLM disminuía a medida que crecía el volumen de datos, pero no extendimos las pruebas a escalas de millones de filas donde la latencia de inference y el coste probablemente se convertirían en las principales limitaciones.
3. Uniformidad de infraestructura: Para mantener un entorno de pruebas consistente, ejecutamos todos los models en el mismo hardware NVIDIA H200. LightGBM y CatBoost están altamente optimizados para CPUs de consumo; por lo tanto, en un entorno de producción dedicado únicamente a Tree models, la diferencia de coste probablemente sería mayor.
4. Generalización más allá de la semántica: Nuestra hipótesis del “espectro semántico” predijo con éxito muchos resultados, pero el fuerte rendimiento del LLM en datasets abstractos como sonar y california_housing sugiere capacidades más allá de la comprensión lingüística. Esto indica que el model también puede estar aprovechando patrones de regularización de alta dimensionalidad, un fenómeno que merece más investigación fuera del alcance de este estudio inicial.

Cita este benchmark

Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.

@misc{ermut2026,
  author = {Ermut, Sıla and Sarı, Ekrem},
  title  = {{Comparar Models Fundacionales Relacionales}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/relational-foundation-model}},
  note   = {AIMultiple. Recuperado el 15 de septiembre de 2026}
}

Registro de cambios

2 actualizaciones

2026

1. 4 de feb

   Se añadió SAP HANA Cloud a la sección de estudios de caso.

2. 21 de ene

   Se eliminó la sección "Modelos fundamentales para datos relacionales y estructurados".

Enlaces de referencia

1.

Griffin: Towards a Graph-Centric Relational Database Foundation Model

2.

RELATIONAL TRANSFORMER: TOWARD ZERO-SHOT FOUNDATION MODELS FOR RELATIONAL DATA

3.

RELBENCH: A Benchmark for Deep Learning on Relational Databases

4.

GitHub - stanford-star/relbench: RelBench: Relational Deep Learning Benchmark · GitHub

5.

Relational Programming with Foundation Models

6.

SAP HANA Cloud

7.

SAP Business AI: Release Highlights Q4 2025 | SAP News Center

SAP

8.

Kumo.AI trains foundation model for relational databases

blocksandfiles

9.

[2506.10707] ConTextTab: A Semantics-Aware Tabular In-Context Learner

Sıla Ermut

Analista de la industria

Síguenos

Sıla Ermut es analista de la industria en AIMultiple y cubre modelos de IA, infraestructura de IA, gobernanza de IA y aplicaciones empresariales de IA. Su investigación se centra principalmente en el uso de la IA en marketing, atención sanitaria, cadenas de suministro y sostenibilidad.
Anteriormente trabajó como reclutadora en empresas de gestión de proyectos y consultoría. Sıla tiene un máster en Psicología Social y una licenciatura en Relaciones Internacionales.

Ver perfil completo

Investigado por

Ekrem Sarı

Investigador de IA

Síguenos

Ekrem es investigador de IA y científico de datos en AIMultiple. Diseña y ejecuta benchmarks prácticos para sistemas de IA y LLM.

Ver perfil completo

Sé el primero en comentar

Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.

Nombre

Dirección de correo electrónico

Comentario

0/450

Publicar comentario