Comparar modelos de fundamentos relacionales

con

actualizado el Abr 15, 2026

Realizamos una evaluación comparativa de SAP-RPT-1-OSS con el método de potenciación de gradiente (LightGBM, CatBoost) en 17 conjuntos de datos tabulares que abarcan todo el espectro semántico-numérico, tablas pequeñas/de alta semántica, conjuntos de datos empresariales mixtos y grandes conjuntos de datos numéricos de baja semántica.

Nuestro objetivo es medir dónde los priors semánticos preentrenados de un LLM relacional pueden ofrecer ventajas sobre los modelos de árbol tradicionales y dónde presentan dificultades en estructuras de escala o de baja semántica.

SAP-RPT-1-OSS frente a Gradient Boosting: Resultados de la prueba comparativa

Loading Chart

Tasa de éxito: Representa la puntuación normalizada promedio (de 0,0 a 1,0). Una barra más alta indica que el modelo se acerca de forma consistente al mejor rendimiento posible para los conjuntos de datos de esa categoría.
100 – 500 filas (3 conjuntos de datos):
- Incluido: vino (178), sonar (208), voto (435).
- Resultado: SAP obtiene el mejor rendimiento en 2 de los 3 conjuntos de datos. Alcanza las puntuaciones más altas en vinos y sonar, lo que sugiere que las distribuciones a priori de LLM pueden ser beneficiosas cuando los datos de entrenamiento son escasos. Sin embargo, CatBoost obtuvo una ajustada victoria en el conjunto de datos de votación (con una diferencia inferior al 0,1%), lo que indica que los modelos de árboles siguen siendo altamente competitivos incluso a pequeña escala.
501 – 1000 filas (3 conjuntos de datos):
- Incluido: cylinder_bands (540), breast_cancer (569), credit_g (1.000).
- Resultado: SAP ofrece el mejor rendimiento en los tres 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 los defectos industriales, aunque se necesitarían más estudios de ablación para confirmar este mecanismo.
1.000 – 10.000 filas (5 conjuntos de datos):
- Incluido: titanic (1.3K), car_evaluation (1.7K), spambase (4.6K), compas (5.2K), employee_salaries (9.2K).
- Resultado: SAP obtiene los mejores resultados en 4 de los 5 conjuntos de datos, con un desempeño particularmente bueno en tareas con gran cantidad de texto, como Spambase y Titanic. Sin embargo, CatBoost supera significativamente a SAP en Compass en un 10,4%, lo que indica características específicas del conjunto de datos que favorecen a los modelos de árbol incluso en este rango de tamaño.
Más de 10 000 filas (6 conjuntos de datos):
- Incluido: california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs_100k (98K).
- Resultado: A medida que aumenta el volumen de datos, la ventaja potencial del "conocimiento previo" del LLM disminuye. LightGBM y CatBoost obtienen los mejores resultados en 5 de los 6 conjuntos de datos, ofreciendo mayor precisión con un coste computacional mucho menor. La única excepción, california_housing, muestra una modesta ventaja del 1,7 % para SAP.

1. Tabla de conjuntos de datos de resultados de referencia

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

2. Análisis de costos y eficiencia

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

SAP-RPT-1-OSS genera costos significativamente mayores debido al tiempo requerido para el preprocesamiento de incrustación de texto y la gran sobrecarga de memoria de la arquitectura LLM. En contraste, LightGBM y CatBoost completan las tareas casi instantáneamente en este hardware. Los costos que se muestran a continuación reflejan el tiempo total de ejecución (preprocesamiento + entrenamiento) para una validación cruzada de 3 pliegues.

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

Desglose de costos por tamaño del conjunto de datos

Conjuntos de datos pequeños (<1000 filas): SAP es relativamente económico (aproximadamente 0,03 dólares por ejecución). La alta tasa de éxito en este caso hace que el coste sea insignificante.
Grandes conjuntos de datos (>20.000 filas): SAP se vuelve costoso.
- Ejemplo: El entrenamiento en adult_income (48k filas) toma ≈$12 minutos en total para 3 pliegues.
- Costo: 12 minutos x $0.06/min = $0.72 por experimento.
- Comparación: LightGBM realiza la misma tarea por 0,01 dólares .

Conclusión: Si bien 0,22 dólares por conjunto de datos no es caro en términos absolutos, SAP es 22 veces más caro que el modelo de referencia. Esta diferencia de coste puede justificarse para conjuntos de datos pequeños y con gran riqueza semántica, donde SAP muestra mejoras significativas en la precisión (por ejemplo, cylinder_bands con un incremento del +5,5 %), pero resulta más difícil de justificar para conjuntos de datos grandes, donde los modelos de árbol logran un rendimiento igual o superior a una fracción del coste.

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

Para interpretar estos resultados, es fundamental comprender cómo seleccionamos los datos. No elegimos los conjuntos de datos al azar; seleccionamos cuidadosamente un conjunto de 17 conjuntos de datos elegidos específicamente 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 modelos de árbol dominarían en el cálculo numérico puro. Clasificamos nuestros conjuntos de datos en tres grupos distintos:

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

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

Conjuntos de datos:
- bandas_cilindro: Defectos de impresión industrial.
- Titanic: Nombres y títulos de los pasajeros.
- Votación: Registros de votación del Congreso (respuesta categórica "Sí/No" sobre las políticas).
- cáncer_de_mama: Descripciones médicas de tumores.
- Spambase: Frecuencia de palabras en correos electrónicos.
- Vino: Orígenes químicos.

Grupo B: Datos empresariales mixtos (6 conjuntos de datos)

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

Conjuntos de datos:
- salarios de empleados: Puestos de trabajo frente a salarios.
- brújula: Antecedentes penales y datos demográficos (atributos sensibles).
- adult_income: Datos demográficos del censo.
- credit_g: Perfiles de riesgo crediticio alemanes.
- default_credit: Datos de impago de crédito en Taiwán.
- evaluación_del_vehículo: Parámetros de compra del vehículo.

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

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

Conjuntos de datos:
- higgs_100k: Cinemática de partículas en física.
- Diamantes: Dimensiones físicas y precio.
- sonar: la energía de la frecuencia rebota.
- Vivienda en California: Coordenadas de latitud/longitud y estadísticas del censo.
- ventas de casas: Bienes raíces en el condado de King (principalmente datos numéricos).

4. Análisis en profundidad: Dónde SAP triunfa y dónde fracasa

Al aplicar el marco de análisis a nuestros resultados, se revelan cuatro patrones de rendimiento distintos. La siguiente tabla resume con precisión en qué aspectos SAP destaca y en cuáles presenta deficiencias.

Fundamentos conceptuales de los modelos de fundamentos relacionales

El objetivo principal de un modelo de base relacional es realizar predicciones precisas y ejecutar 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 mediante relaciones y cómo influye la información temporal en los resultados.

Las principales capacidades de estos modelos incluyen:

Generalización de esquemas: La capacidad de adaptarse a nuevos esquemas relacionales sin necesidad de volver a entrenar desde cero.
Representación unificada de la entrada: Manejo de diferentes tipos de columnas, como características numéricas, categóricas y textuales.
Integración del contexto temporal y estructural: Captura de dependencias a lo largo del tiempo y entre entidades vinculadas por claves primarias y foráneas.
Transferibilidad: Realización de tareas predictivas en nuevos conjuntos de datos mediante preentrenamiento y aprendizaje de cero disparos.

Grifo

Griffin es uno de los primeros intentos a gran escala de construir un modelo de base relacional 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 externa. Sus características principales 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 coma flotante aprendido.
Los datos como los nombres de las tablas, los nombres de las columnas y los tipos de aristas se incorporan para ayudar al modelo a reconocer el esquema relacional.
Las incrustaciones de tareas permiten que un único modelo realice tareas de regresión y clasificación con decodificadores compartidos.

Transmisión 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 las 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 a mantener el contexto entre las entidades conectadas.

Preentrenamiento y ajuste fino

El modelo se preentrena con conjuntos de datos de una sola tabla mediante una tarea de completar celdas enmascaradas y, posteriormente, se ajusta con precisión en bases de datos relacionales para tareas específicas. Los experimentos realizados con grandes conjuntos de datos relacionales demuestran que Griffin supera a los modelos GNN tradicionales 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 que Griffin se centra en la agregación de grafos, el Relational Transformer (RT) aplica arquitecturas de transformadores 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 ficha combina:

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

Esta estructura permite a RT procesar bases de datos relacionales con diferentes esquemas, manteniendo al mismo tiempo un formato de entrada coherente.

Atención relacional

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

Atención a las columnas para aprender las distribuciones de valores dentro de las columnas.
Presta atención a las funciones que permiten combinar atributos dentro de la misma fila o filas principales vinculadas.
Atención del vecino para agregar información de filas secundarias conectadas.

En conjunto, estas capas de atención forman un transformador de grafos relacionales que modela las dependencias entre filas, columnas y tablas.

Resultados de la formación y la transferencia

RT se entrenó previamente con bases de datos relacionales de RelBench. En experimentos, el modelo preentrenado alcanzó hasta el 94 % del rendimiento de los modelos totalmente supervisados en entornos de aprendizaje sin ejemplos previos. Además, 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 diferentes dominios y que la tokenización a nivel de celda proporciona una base práctica para las tareas predictivas sobre datos estructurados.

RelBench

RelBench está diseñado para impulsar el aprendizaje profundo relacional, que se centra en el aprendizaje integral 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 abarcaban dominios como la atención médica, las redes sociales , el comercio electrónico y los deportes, con 70 tareas predictivas diseñadas para ser a la vez desafiantes y relevantes para el dominio específico. ³

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

Esta versión también amplió el acceso a los datos mediante la integración de CTU, lo que permitió acceder a más de 70 conjuntos de datos relacionales a través de ReDeLEx; añadió conectividad directa con 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 las tareas, RelBench proporciona una implementación de referencia de código abierto para el aprendizaje profundo relacional basado en redes neuronales gráficas, utilizando PyTorch Geometric para la construcción de gráficos y PyTorch Frame para el modelado tabular , junto con una tabla de clasificación pública para realizar un seguimiento del progreso.

La versión v2 también introdujo múltiples mejoras de usabilidad y rendimiento, incluyendo etiquetas opcionales con censura temporal, compatibilidad con la métrica NDCG en la predicción de enlaces, generación más rápida de incrustaciones de oraciones y gestión de caché configurable. ⁴

VIEIRA

VIEIRA adopta un enfoque diferente al centrarse en la programación con modelos base 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 base 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 utilizar GPT para extraer conocimiento de un texto y almacenarlo como relaciones estructuradas.
CLIP puede clasificar imágenes y vincularlas a etiquetas de texto en una tabla.

Aplicaciones

El marco admite:

Razonamiento matemático y de fechas utilizando GPT.
Razonamiento de parentesco mediante extracción de texto e inferencia lógica.
Sistema de respuesta a preguntas que combina recuperación de informació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 crear sistemas interpretables que utilizan modelos base preentrenados para responder a consultas predictivas sobre datos estructurados e imágenes.

Estudios de caso

SAP Hana Cloud

SAP HANA Cloud es una base de datos como servicio (DBaaS) nativa de la nube y totalmente administrada, diseñada para funcionar como una plataforma de datos unificada para aplicaciones empresariales que combinan transacciones, análisis e inteligencia artificial. En lugar de ser una base de datos relacional de propósito único, SAP HANA Cloud se posiciona como una plataforma multimodelo que permite a las organizaciones crear aplicaciones de datos inteligentes a partir de datos operativos de negocio.

SAP HANA Cloud combina el procesamiento en memoria con el almacenamiento en disco y la integración de data lakes para satisfacer diferentes requisitos de rendimiento y coste. Este diseño flexible admite cargas de trabajo en tiempo real y se escala dinámicamente según fluctúan los volúmenes de datos y el uso.

Una característica clave que lo diferencia es su motor multimodelos nativo, que admite datos relacionales, JSON/documentos, gráficos, espaciales y vectoriales dentro de una única base de datos. Esto permite que las aplicaciones combinen consultas SQL, relaciones gráficas y búsquedas de similitud vectorial sin necesidad de transferir datos entre sistemas separados, lo que simplifica la arquitectura y reduce la latencia.

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

En resumen, SAP HANA Cloud es una plataforma de datos centrada en las relaciones y nativa de la IA, en la que la base de datos relacional sirve como capa fundamental para el análisis, los datos multimodelo y las aplicaciones de IA empresarial.

Figura 2: Imagen que muestra la base de datos unificada de Hana y
Procesamiento de datos multimodelos. ⁶

SAP sap-rpt-1

sap-rpt-1 introduce un modelo relacional único que realiza una amplia gama de tareas predictivas mediante aprendizaje contextual. En lugar de reentrenar un nuevo modelo para cada caso de uso, los usuarios proporcionan algunos ejemplos del patrón que buscan, como «clientes que pagaron a tiempo» y «clientes que pagaron tarde». El modelo reconoce el patrón y genera inmediatamente predicciones precisas para nuevos datos.

El modelo está diseñado con un mecanismo de atención bidimensional que captura las relaciones entre filas y columnas, a la vez que incorpora metadatos, como nombres de tablas y columnas, en representaciones vectoriales. Este diseño le permite comprender la semántica de los esquemas relacionales y la información temporal presente en las tablas de negocio.

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

Un único modelo que funciona en múltiples tablas y dominios.
No es necesario realizar ajustes repetidos ni desarrollos personalizados.
Acceso a información predictiva en minutos en lugar de semanas.
Integración con los almacenes de datos 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 proceso más rápido que transforma los datos estructurados en decisiones prácticas, sin necesidad de ingeniería de características manual.

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

A finales de 2025, SAP confirmó que SAP-RPT-1 está disponible de forma general a través del centro de IA generativa en SAP AI Foundation (SAP AI 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.

Esta versión formaliza el papel de SAP-RPT-1 como un modelo base desplegable dentro del conjunto de herramientas de IA empresarial de SAP, en lugar de una capacidad exclusivamente para la investigación.

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

SAP-ABAP-1

SAP-ABAP-1 es un modelo fundamental diseñado para dar soporte a casos de uso de productividad de desarrolladores basados en IA para clientes y socios de SAP.

Está disponible a través del centro de IA generativa de SAP y se ha entrenado con más de 250 millones de líneas de código ABAP, 30 millones de líneas de código CDS y una amplia documentación técnica. El modelo está optimizado para comprender y explicar el código ABAP, identificar las mejores prácticas y proporcionar acceso a conocimientos actualizados sobre desarrollo en SAP.

SAP ofrece acceso de prueba gratuito a SAP-ABAP-1 a través de su plataforma de IA generativa, con funcionalidades adicionales previstas para su lanzamiento en 2026. ⁷

KumoRFM de Kumo.AI: un transformador de grafos relacionales para análisis predictivo.

Kumo.AI, fundada por el profesor de Stanford Jure Leskovec, creó KumoRFM, un modelo de base relacional que utiliza un transformador de grafos relacionales para analizar bases de datos relacionales y almacenes de datos. 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 las tablas.

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

KumoRFM se puede utilizar a través de diferentes interfaces dependiendo de 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.
SDK de Python: Permite a los desarrolladores integrar el modelo en las aplicaciones y flujos de trabajo de IA empresariales.

La arquitectura KumoRFM muestrea dinámicamente la base de datos para crear subgrafos de contexto y de predicción. Estos subgrafos son procesados por el transformador de grafos relacionales, que captura las dependencias y la información temporal entre entidades relacionadas. Mediante el aprendizaje contextual, 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 facilitar el acceso y la escalabilidad.
Almacenamiento de datos nativo: 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 la definición manual del esquema, KumoRFM construye automáticamente su grafo relacional a partir de fuentes estructuradas. Esto lo hace idóneo para el comercio electrónico, las finanzas y la atención médica , donde las relaciones, los patrones temporales y el contexto cambiante son esenciales para realizar predicciones fiables.

Las principales capacidades de KumoRFM incluyen:

Flexibilidad en diferentes tablas y estructuras de esquema.
Compatibilidad con diversos tipos de columnas 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 de Fundamentos Relacionales (RFM, por sus siglas en inglés) en múltiples dominios, como el comercio electrónico, las finanzas y la atención médica, para hacer predicciones, proporcionar explicaciones y evaluar resultados. ⁸

Metodología de evaluación comparativa

Configuración y entorno de referencia

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

Hardware: Instancia de RunPod con una GPU NVIDIA H200 de 140 GB .
Software: Python 3.12 con bibliotecas fijas para garantizar la 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 forma 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 obtenidos de OpenML y Scikit-Learn. En lugar de una selección aleatoria, seleccionamos cuidadosamente este conjunto para abarcar el "Espectro Semántico-Numérico", poniendo a prueba la hipótesis de que los modelos de lenguaje natural (LLM) destacan cuando las características contienen significado lingüístico en lugar de simples estadísticas.

El inventario:

Pequeño y semántico (<1000 filas):
- vino (178), sonar (208), voto (435), bandas de cilindros (540), cáncer de mama (569).
Media/mixta (1K – 10K filas):
- credit_g (1K), titanic (1.3K), car_evaluation (1.7K), spambase (4.6K), compas (5.2K), employee_salaries (9.2K).
Datos grandes/numéricos (más de 10 000 filas):
- california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs (muestreado a 100K).

Tareas realizadas:

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

Configuraciones y preprocesamiento del modelo

Nuestro objetivo era realizar una "comparación práctica" realista, utilizando valores predeterminados robustos en lugar de un ajuste exhaustivo de los hiperparámetros.

LightGBM y CatBoost

Para garantizar una comparación justa con el modelo SAP, que requiere una gran capacidad de cálculo, aumentamos los estimadores predeterminados robustos.

LightGBM: n_estimators=500, learning_rate=0,05, num_leaves=31. Se ejecuta en la CPU (n_jobs=-1).
CatBoost: iteraciones=500, tasa de aprendizaje=0,05, profundidad=6. Se ejecuta en la GPU (task_type=”GPU”).
Preprocesamiento: Codificación de etiquetas simple para variables categóricas; sin escalado para variables numéricas; imputación de mediana/moda para valores faltantes.

SAP-RPT-1-OSS

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

Configuración: max_context_size=4096, bagging=4.
Nota:
- Contexto: Las pruebas realizadas 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 frente a 0,917 ROC-AUC).
- Bagging: Aumentar el bagging de 4 a 8 (configuración predeterminada de SAP utilizada en el artículo) ⁹ ) ofrecieron rendimientos decrecientes.
Preprocesamiento: Ninguno. El DataFrame pandas sin procesar 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 triple con aleatorización.

Redujimos el método estándar de 5 pliegues a 3 pliegues para adaptarnos a los tiempos de inferencia lentos de SAP (ahorro de tiempo del 40 %) manteniendo la validez estadística.
Método de división: StratifiedKFold para clasificación; K-Fold estándar para regresión.

Métricas y diagnósticos

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

Métricas de clasificación principales: ROC-AUC (binaria), precisión equilibrada (multiclase), R² (regresión).
Diagnóstico secundario: Hicimos un seguimiento del coeficiente de correlación de Matthews (MCC) y de la pérdida logarítmica para asegurarnos de que las victorias no fueran artefactos del desequilibrio de clases, y del MAPE para la calibración del error de regresión.
Cálculo de costes: Basado en el tiempo total transcurrido (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 de modelos 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 limitaciones en nuestra metodología:

Configuraciones estandarizadas frente a ajustes: Utilizamos configuraciones predeterminadas fijas y robustas para todos los modelos en lugar de realizar una optimización exhaustiva de hiperparámetros (por ejemplo, validación cruzada anidada o barridos de Optuna). Si bien esto garantiza una base consistente, cabe destacar que los modelos de árbol suelen experimentar mejoras de rendimiento con ajustes específicos para cada conjunto de datos, lo que podría reducir los márgenes en el grupo "Competitivo".
Limitaciones de la escala de datos: Nuestro análisis se centró en conjuntos de datos con menos de 100 000 filas para simular escenarios típicos de empresas medianas. Observamos que la ventaja del modelo LLM disminuía a medida que aumentaba el volumen de datos, pero no extendimos las pruebas a escalas de millones de filas, donde la latencia y el coste de la inferencia probablemente se convertirían en las principales limitaciones.
Uniformidad de la infraestructura: Para mantener un entorno de prueba consistente, ejecutamos todos los modelos en el mismo hardware H200 (NVIDIA). LightGBM y CatBoost están altamente optimizados para CPU estándar; por lo tanto, en un entorno de producción dedicado exclusivamente a modelos de árboles, la diferencia de costos probablemente sería mayor.
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 desempeño del modelo LLM en conjuntos de datos abstractos como sonar y california_housing sugiere capacidades que van más allá de la comprensión lingüística. Esto indica que el modelo también podría estar aprovechando patrones de regularización de alta dimensión, un fenómeno que justifica una investigación más profunda que la que se aborda en este estudio inicial.

Enlaces de referencia

https://arxiv.org/pdf/2505.05568

https://arxiv.org/pdf/2510.06377

https://arxiv.org/pdf/2407.20060

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

https://arxiv.org/pdf/2412.14515

SAP HANA Cloud

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

SAP

Kumo.AI trains foundation model for relational databases

blocksandfiles

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

Sıla Ermut

Analista de la industria

Sıla Ermut es analista de la industria en AIMultiple, especializada en marketing por correo electrónico y vídeos de ventas. Anteriormente trabajó como reclutadora en empresas de gestión de proyectos y consultoría. Sıla es licenciada en Psicología Social y en Relaciones Internacionales.

Ver perfil completo

Investigado por