Comparación de modelos fundacionales relacionales

Comparamos SAP-RPT-1-OSS contra el gradient boosting (LightGBM, CatBoost) en 17 conjuntos de datos tabulares que abarcan el espectro semántico-numérico, tablas pequeñas/de alta semántica, conjuntos de datos de negocio mixtos y grandes conjuntos de datos numéricos de baja semántica.

Nuestro objetivo es medir dónde los priores semánticos preentrenados de un LLM relacional pueden ofrecer ventajas frente a los modelos de árboles 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 (0.0 a 1.0). Una barra más alta indica que el modelo está consistentemente más cerca del mejor rendimiento posible para los conjuntos de datos de esa categoría.
• 100 – 500 filas (3 conjuntos de datos):
  • Incluidos: wine (178), sonar (208), vote (435).
  • Resultado: SAP obtiene el mejor rendimiento en 2 de los 3 conjuntos de datos. Alcanza las puntuaciones más altas en wine y sonar, lo que sugiere que los priores del LLM pueden ser beneficiosos cuando los datos de entrenamiento son escasos. Sin embargo, CatBoost obtuvo una victoria estrecha en el conjunto de datos vote (dentro del 0.1 %), lo que indica que los modelos de árboles siguen siendo altamente competitivos incluso a escalas pequeñas.
• 501 – 1.000 filas (3 conjuntos de datos):
  • Incluidos: cylinder_bands (540), breast_cancer (569), credit_g (1.000).
  • Resultado: SAP obtiene el mejor rendimiento en todos los 3 conjuntos de datos. 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 estudios de ablación adicionales para confirmar este mecanismo.
• 1.000 – 10.000 filas (5 conjuntos de datos):
  • 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 los 5 conjuntos de datos, con un rendimiento particularmente bueno en tareas con mucho texto como spambase y titanic. Sin embargo, CatBoost supera significativamente a SAP en compas por un 10.4 %, lo que indica características específicas del conjunto de datos que favorecen a los modelos de árboles incluso en este rango de tamaño.
• 10.000+ filas (6 conjuntos de datos):
  • 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 los 6 conjuntos de datos, ofreciendo mejor precisión a una fracción del coste computacional. La única excepción, california_housing, muestra una modesta ventaja del 1.7 % para SAP.

1. Tabla de resultados del benchmark de conjuntos de datos

A continuación se presenta el desglose completo del rendimiento del modelo en los 17 conjuntos de datos.

2. Análisis de coste y eficiencia

Calculamos el coste computacional directo de cada modelo 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 incrustaciones de texto y la sobrecarga de memoria elevada 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 particiones.

Coste promedio por conjunto de datos (promedio de 17 conjuntos)

Desglose de costes por tamaño del conjunto de datos

• Conjuntos de datos pequeños (<1K filas): SAP es relativamente barato (≈ $0.03 por ejecución). La alta tasa de éxito aquí hace que el coste sea insignificante.
• Conjuntos de datos grandes (>20K filas): SAP se vuelve caro.
  • Ejemplo: Entrenar en adult_income (48k filas) toma aproximadamente $12 minutos en total para 3 particiones.
  • Coste: 12 min X $0.06/min = $0.72 por experimento.
  • Comparación: LightGBM termina la misma tarea por $0.01.

Conclusión: Si bien $0.22 por conjunto de datos no es un coste elevado en términos absolutos, SAP es 22x más caro que la línea base. Esta diferencia de coste puede estar justificada para conjuntos de datos pequeños y ricos en semántica donde SAP muestra mejoras significativas en precisión (por ejemplo, cylinder_bands con una mejora del +5.5 %), pero se vuelve más difícil de justificar para conjuntos de datos grandes donde los modelos de árboles logran un rendimiento igual o mejor a una fracción del coste.

3. Marco de análisis: El espectro semántico

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

Nuestra hipótesis principal era que SAP (basado en LLM) sobresaldría donde los datos tienen significado lingüístico, mientras que los modelos de árboles dominarían en cálculos numéricos puros. Categorizamos nuestros conjuntos de datos en tres grupos distintos:

Grupo A: Conjuntos de datos de alta semántica (6 conjuntos)

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

• Conjuntos de datos:
  • cylinder_bands: Defectos de impresión industrial.
  • titanic: Nombres y títulos de pasajeros.
  • vote: Registros de votación del Congreso (Categórico “Sí/No” en políticas).
  • breast_cancer: Descripciones de tumores médicos.
  • spambase: Frecuencias de palabras en correos electrónicos.
  • wine: Orígenes químicos.

Grupo B: Datos de negocio mixtos (6 conjuntos)

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 (título del trabajo, raza, departamento).

• Conjuntos de datos:
  • employee_salaries: Títulos de trabajo vs. salario.
  • compas: Historial criminal y demografía (Atributos sensibles).
  • adult_income: Demografía del censo.
  • credit_g: Perfiles de riesgo crediticio alemanes.
  • default_credit: Datos de incumplimiento de crédito de Taiwán.
  • car_evaluation: Parámetros de compra de vehículos.

Grupo C: Datos de baja semántica/puramente numéricos (5 conjuntos)

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

• Conjuntos de datos:
  • higgs_100k: Cinemática de partículas de física.
  • diamonds: Dimensiones físicas y precio.
  • sonar: Rebotes de energía de frecuencia.
  • california_housing: Coordenadas Lat/Long y estadísticas del censo.
  • house_sales: Bienes raíces del condado de King (principalmente características numéricas).

4. Análisis en profundidad: Dónde gana SAP y dónde falla

Aplicando el marco de análisis a nuestros resultados se revelan cuatro patrones de rendimiento distintos. La tabla a continuación resume exactamente dónde SAP sobresale y dónde se descompone.

Fundamentos conceptuales de los modelos fundacionales relacionales

El objetivo principal de un modelo fundacional relacional es hacer predicciones precisas y realizar diversas tareas sobre tablas estructuradas. Estos modelos deben comprender cómo se representa la información en diferentes tablas, cómo se vinculan las entidades a través de relaciones y cómo la información temporal influye en los resultados.

Las capacidades clave de estos modelos incluyen:

• Generalización de esquema: La capacidad de adaptarse a nuevos esquemas relacionales sin reentrenar desde cero.
• Representación de entrada unificada: Manejo de diferentes tipos de columnas, como numéricas, categóricas y textuales.
• Integración del contexto temporal y estructural: Captura de dependencias a través del tiempo y entre entidades vinculadas por claves primarias y externas.
• Transferibilidad: Realización de tareas predictivas en nuevos conjuntos de datos mediante preentrenamiento y aprendizaje de cero disparos.

Griffin

Griffin es uno de los primeros intentos a gran escala de construir un modelo fundacional relacional unificado. Representa los datos relacionales como un grafo heterogéneo temporal, donde cada fila se convierte en un nodo y los bordes corresponden a relaciones de clave externa. Las características clave incluyen:

Codificador de características unificado

• Las características categóricas y de texto se codifican con un codificador de texto preentrenado, mientras que los valores numéricos utilizan un codificador de flotante aprendido.
• Los metadatos como nombres de tablas, nombres de columnas y tipos de bordes se incrustan para ayudar al modelo a reconocer el esquema relacional.
• Las incrustaciones de tareas permiten que un solo modelo 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 atención cruzada. El componente de paso de mensajes agrega información dentro y entre relaciones, mientras que la atención cruzada se centra en las celdas relevantes dentro de cada fila. Este diseño ayuda al modelo a manejar datos diversos y mantener el contexto entre entidades conectadas.

Preentrenamiento y ajuste fino

El modelo se preentrena en conjuntos de datos de una sola tabla mediante una tarea de completado de celdas enmascaradas y luego se ajusta finamente en bases de datos relacionales para tareas específicas. Los experimentos en grandes referencias relacionales muestran que Griffin supera a las líneas base tradicionales de GNN y a los modelos de una sola tabla tanto en precisión como en eficiencia de aprendizaje por transferencia.

Figura 1: Gráfico que muestra el marco del modelo Griffin.¹

Transformador relacional

Mientras Griffin se centra en la agregación de grafos, el Transformador Relacional (RT) aplica arquitecturas de transformadores directamente a las 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:

• Una incrustación de valor que depende de su tipo de dato (numérico, texto o fecha/hora).
• Una incrustación de esquema se genera a partir del texto de la tabla y la columna.
• Se utiliza un token de máscara cuando el valor está oculto durante el preentrenamiento.

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 características para combinar atributos dentro de la misma fila o filas padre vinculadas.
• Atención de vecinos para agregar información de filas hijo conectadas.

Together, estas capas de atención forman un transformador de grafo relacional que modela dependencias entre filas, columnas y tablas.

Resultados de entrenamiento y transferencia

RT se preentrena en bases de datos relacionales de RelBench. En experimentos, el modelo preentrenado alcanzó hasta el 94 % del rendimiento de los modelos completamente supervisados en configuraciones de cero disparos. También aprendió más rápido durante el ajuste fino, 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 avanzar en el aprendizaje profundo relacional, 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 marco estandarizado y reproducible para evaluar modelos que operan directamente sobre estructuras relacionales en lugar de depender del aplanamiento manual de características.

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

En enero de 2026, se lanzó RelBench v2, añadiendo cuatro nuevas bases de datos (SALT, RateBeer, arXiv y MIMIC-IV) y 40 tareas predictivas adicionales, incluyendo una nueva clase de tareas de Autocompletar que evalúan la capacidad de un modelo 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, permitiendo el acceso a más de 70 conjuntos de datos relacionales a través de ReDeLEx; añadió conectividad directa a bases de datos SQL; e incorporó siete conjuntos de datos del repositorio 4DBInfer en formato RelBench.

Más allá de los conjuntos de datos y tareas, RelBench proporciona una implementación de referencia de código abierto para el aprendizaje profundo relacional basado en redes neuronales de grafos, utilizando PyTorch Geometric para la construcción de grafos y PyTorch Frame para el modelado tabular, junto con un líder público para seguir el progreso.

El lanzamiento v2 también introdujo múltiples mejoras de usabilidad y rendimiento, incluyendo etiquetas con censura temporal opcional, soporte para la métrica NDCG en la predicción de enlaces, generación más rápida de incrustaciones de frases y gestión de caché configurable.⁴

VIEIRA

VIEIRA adopta un enfoque diferente al centrarse en la programación con modelos fundacionales en lugar de construir un único motor predictivo. Extiende el compilador de lógica probabilística SCALLOP con un lenguaje declarativo que integra grandes modelos de lenguaje, modelos de visión y otros componentes preentrenados como predicados externos.⁵

Paradigma relacional

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

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

Aplicaciones

El marco admite:

• Razonamiento de fechas y matemáticas usando GPT.
• Razonamiento de parentesco utilizando 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 a través de 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 modelos fundacionales 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

Estudios de caso

SAP Hana Cloud

SAP HANA Cloud es una base de datos como servicio nativa de la nube, completamente gestionada, diseñada 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 propósito único, SAP HANA Cloud se posiciona como una plataforma multimodelo que permite a las organizaciones construir “aplicaciones de datos inteligentes” sobre los datos de negocio operativos.

SAP HANA Cloud combina procesamiento en memoria con almacenamiento en disco e integración de data lake para soportar diferentes requisitos de rendimiento y coste. Este diseño flexible admite 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 multimodelo nativo, que admite datos relacionales, JSON/documento, 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 la Plataforma de Tecnología Empresarial de SAP, 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 nativa de IA centrada en lo relacional, en la que la base de datos relacional sirve como capa fundacional para análisis, datos multimodelo y aplicaciones de IA empresariales.

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

sap-rpt-1 de SAP

sap-rpt-1 introduce un único modelo fundacional relacional que realiza una amplia gama de tareas predictivas a través del aprendizaje en contexto. En lugar de reentrenar un nuevo modelo 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 modelo reconoce el patrón e inmediatamente produce predicciones precisas para nuevos datos.

El modelo está diseñado con un mecanismo de atención bidimensional que captura relaciones a través de filas y columnas, al mismo tiempo que incrusta metadatos, como nombres de tablas y columnas, en incrustaciones vectoriales. Este diseño le permite comprender la semántica de los esquemas relacionales y la información temporal dentro de las tablas de negocio.

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

• Un único modelo que funciona en múltiples tablas y dominios.
• Sin necesidad de ajustes finos repetidos o desarrollo personalizado.
• Acceso a conocimientos predictivos en minutos en lugar de semanas.
• Integración con almacenes de datos existentes y sistemas SAP.

Al incrustar sap-rpt-1 dentro del ecosistema SAP, los expertos de negocio pueden interactuar con sus propios datos directamente y recibir predicciones a través de interfaces intuitivas. El resultado es un camino más rápido desde los datos estructurados hasta las decisiones accionables sin ingeniería de características manual.

Figura 3: Factor de reducción de errores de sap-rpt-1-large frente a líneas base de IA estrecha en dominios 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 modelo 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 modelo fundacional desplegable dentro de la pila de IA empresarial de SAP, en lugar de una capacidad solo de investigación.

Además, SAP ofrece el SAP-RPT Playground, un entorno basado en web sin código donde los usuarios pueden probar el aprendizaje en contexto utilizando sus propios datos de muestra o los proporcionados por SAP.

SAP-ABAP-1

SAP-ABAP-1 es un modelo fundacional diseñado para apoyar 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 en 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 modelo está optimizado para comprender y explicar código ABAP, destacar mejores prácticas y proporcionar acceso al 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 planificadas para su lanzamiento en 2026.⁷

KumoRFM de Kumo.IA: un transformador de grafo relacional para análisis predictivo

Kumo.IA, fundada por el profesor de Stanford Jure Leskovec, creó KumoRFM, un modelo fundacional relacional que utiliza un transformador de grafo relacional para analizar bases de datos relacionales y almacenes de datos. Representa los datos relacionales como un grafo heterogéneo temporal, donde cada entidad es un nodo y las claves primarias y externas forman bordes entre tablas.

Este enfoque basado en grafos permite a KumoRFM aprender de múltiples tablas simultáneamente y adaptarse a nuevos esquemas relacionales. El modelo se preentrena en diversas fuentes de datos y puede generalizar a nuevos conjuntos de datos sin construir modelos separados para cada tarea predictiva.

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

• PQL (Lenguaje de Consulta Predictiva): Un lenguaje de consulta especializado para definir consultas predictivas en datos estructurados.
• Interfaz de lenguaje natural: Para usuarios no técnicos, las entradas en lenguaje natural se traducen automáticamente en consultas PQL.
• SDK de Python: Permite a los desarrolladores integrar el modelo 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 transformador de grafo relacional, que captura dependencias e información temporal entre entidades relacionadas. A través del aprendizaje en contexto, el modelo 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 fácil acceso y escalado
• Nativo de almacén de datos: Permite a las organizaciones utilizar sus propios datos en Snowflake o Databricks sin moverlos fuera de su entorno seguro

A diferencia de los grafos de conocimiento tradicionales que requieren definición manual del esquema, KumoRFM construye automáticamente su grafo relacional a partir de fuentes estructuradas. Esto lo hace adecuado para el comercio electrónico, finanzas y atención médica, donde las relaciones, los patrones temporales y el contexto en evolución son esenciales para predicciones confiables.

Las capacidades clave de KumoRFM incluyen:

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

Figura 4: La imagen muestra cómo funcionan los Modelos Fundacionales Relacionales (RFM) en múltiples dominios, como el comercio electrónico, finanzas y atención médica, 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 ligados a CPU y los modelos 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 bibliotecas 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: random_state=42 se utilizó de manera consistente en todas las divisiones, inicializaciones y modelos.

Conjuntos de datos: El espectro semántico

Evaluamos los modelos en 17 conjuntos de datos 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 LLM sobresalen donde las características contienen significado lingüístico en lugar de estadísticas brutas.

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 de los modelos y preprocesamiento

Apuntamos a una “comparación realista para profesionales”, utilizando valores predeterminados sólidos en lugar de una optimización exhaustiva de hiperparámetros.

LightGBM y CatBoost

Para garantizar una comparación justa contra el modelo 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: Codificación de etiquetas simple para categóricos; sin escalado para numéricos; imputación de mediana/moda para valores faltantes.

SAP-RPT-1-OSS

Configuramos SAP para equilibrar rendimiento y coste basándonos en nuestros experimentos de configuración preliminares.

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

Protocolo de evaluación

Estrategia de validación cruzada

Utilizamos validación cruzada de 3 particiones con barajado.

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

Métricas y diagnósticos

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

• Métricas principales de clasificación: ROC-AUC (Binaria), Precisión equilibrada (Multiclase), R² (Regresión).
• Diagnósticos secundarios: Seguimos el coeficiente de correlación de Matthews (MCC) y la pérdida logarítmica para asegurar que las victorias no fueran artefactos del desequilibrio de clases, y MAPE para la calibración del error de regresión.
• Cálculo de coste: Basado en el tiempo total de reloj (preprocesamiento + entrenamiento + inferencia) en la instancia RunPod H200 ($3.59/hora).

Significancia estadística

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

Limitaciones y validez interna

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

1. Configuraciones estandarizadas vs optimización: Utilizamos configuraciones fijas y sólidas por defecto para todos los modelos en lugar de realizar una optimización exhaustiva de hiperparámetros (por ejemplo, validación cruzada anidada o barridos con Optuna). Si bien esto garantiza una línea base consistente, vale la pena señalar que los modelos de árboles a menudo obtienen mejoras de rendimiento con la optimización específica del conjunto de datos, lo que podría reducir los márgenes en el grupo “Competitivo”.
2. Límites de escala de datos: Nuestro análisis se centró en conjuntos de datos de menos de 100k filas para simular escenarios típicos de empresas medianas. Observamos que la ventaja del LLM disminuía a medida que crecía el volumen de datos, pero no ampliamos las pruebas a escalas de millones de filas donde la latencia de inferencia 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 modelos en el mismo hardware NVIDIA H200. LightGBM y CatBoost están altamente optimizados para CPU comunes; por lo tanto, en un entorno de producción dedicado únicamente a modelos de árboles, 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 sólido rendimiento del LLM en conjuntos de datos abstractos como sonar y california_housing sugiere capacidades más allá de la comprensión lingüística. Esto indica que el modelo también puede estar aprovechando patrones de regularización de alta dimensión, un fenómeno que merece una investigación adicional más allá del alcance de este estudio inicial.

Cita esta investigación

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  = {{Comparación de modelos fundacionales relacionales}},
  year   = {2026},
  month  = aug,
  howpublished    = {\url{https://aimultiple.com/relational-foundation-model}},
  note   = {AIMultiple. Recuperado el 4 de Agosto de 2026}
}

Enlaces de referencia

1.

https://arxiv.org/pdf/2505.05568

2.

https://arxiv.org/pdf/2510.06377

3.

https://arxiv.org/pdf/2407.20060

4.

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

5.

https://arxiv.org/pdf/2412.14515

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 que 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, salud, 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 analista 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