está capacitado en vastos conjuntos de datos y puede realizar una amplia gama de tareas. Muchos modelos básicos actuales se basan en alguna variante de la arquitectura transformadora de la que fueron pioneras empresas como Google y OpenAI. A pesar de que su entrenamiento requiere muchos recursos, los modelos basados en transformadores pueden lograr un alto rendimiento predictivo a escala, exhibir capacidades emergentes para realizar tareas sin capacitación explícita y pueden funcionar con diferentes tipos de datos de entrada y salida. Si bien los modelos de lenguaje grandes, como ChatGPT, se entrenan con datos de texto, los modelos básicos también se pueden entrenar con otras formas de datos (por ejemplo, imágenes, audio y video).
Recientemente, algunas empresas con grandes cantidades de datos tabulares han comenzado a invertir en modelos de base tabular. Estas empresas están haciendo una apuesta estratégica a que el gran gasto inicial necesario para construir modelos de base tabular generará importantes retornos futuros, desde un mayor rendimiento predictivo y productividad hasta desbloquear nuevas fuentes de ingresos. En el pasado, normalmente era necesario entrenar un modelo tabular separado por caso de uso. Para las grandes empresas con varios casos de uso de IA, el paradigma de “un modelo por caso de uso” tendía a generar costos significativos a lo largo del ciclo de vida del modelo. Por el contrario, un modelo básico podría potencialmente servir para muchos casos de uso a la vez gracias a las propiedades emergentes de generalización del modelo. Tener “un modelo para gobernarlos a todos” (un rey león entre los modelos, por así decirlo) parece instintivamente atractivo y podría ofrecer una serie de ventajas prácticas.
SAP es una empresa que recientemente ha generado cierta expectación al lanzar su propio conjunto de modelos de transformadores relacionales preentrenados (RPT): modelos básicos que pueden entrenarse en grandes conjuntos de datos históricos que abarcan varios dominios comerciales. En este artículo, la incursión de SAP en los modelos de base tabular servirá como un estudio de caso concreto para ayudarnos a comprender mejor las implicaciones prácticas de proporcionar y utilizar dichos modelos. Después de situar los modelos RPT dentro de su contexto histórico, repasaremos su arquitectura técnica, realizaremos una demostración práctica en Python, evaluaremos los pros y los contras y discutiremos formas estratégicas de avanzar para los modelos básicos tabulares en proveedores empresariales como SAP.
Transformadores relacionales preentrenados
El viaje hacia RPT en SAP
SAP es uno de los principales proveedores mundiales de software de planificación de recursos empresariales (ERP), que ayuda a las empresas a gestionar eficazmente flujos de trabajo críticos en áreas que van desde ventas y finanzas hasta recursos humanos y logística. SAP ha estado invirtiendo en IA durante varios años y hasta hace poco ofrecía dos tipos principales de modelos de IA a los clientes: modelos optimizados para su uso con el lenguaje ABAP de SAP y la tecnología de base de datos S/4HANA (por ejemplo, ver hana-ml) y modelos estrechos de IA alojados en la plataforma de tecnología empresarial de SAP. Desde la llegada de ChatGPT, SAP ha estado desarrollando su propio conjunto de ofertas de IA generativa y conversacional bajo la marca Joule (por ejemplo, Joule para consultores, Joule para desarrolladores). Los modelos de IA subyacentes a los productos Joule se entrenan con datos específicos de SAP para ofrecer respuestas de IA más relevantes en casos de uso que involucran recuperación de conocimientos y generación de código. SAP permite integraciones con proveedores externos de modelos previamente entrenados como OpenAI y Anthropic a través del centro de IA generativa y ahora, con el lanzamiento del conjunto de modelos SAP-RPT-1, SAP ha creado modelos básicos tabulares que se pueden entrenar en su propio y vasto tesoro de datos ERP específicos del dominio.
Mire el segmento de presentación de 30:16 a 34:46 para ver el lanzamiento oficial de SAP-RPT-1 en SAP TechEd 2025:
[insertar]https://www.youtube.com/watch?v=X9qHsLmPMk4[/embed]
Bajo el capó: Arquitectura técnica de SAP-RPT-1
Como sugiere el nombre, el transformador relacional preentrenado (RPT) adapta la arquitectura de los transformadores clásicos para manejar datos tabulares (o relacionales). Los modelos SAP-RPT-1 iniciales implementan la arquitectura ConTextTab descrita por Spinaci et al. (2025), que a su vez se basa en la arquitectura de TabPFN, propuesta por Hollmann et al. (2022).
TabPFN es un modelo de transformador previamente entrenado en tablas generadas sintéticamente que encapsula varias relaciones causales posibles entre celdas en columnas de tablas individuales. Al basarse únicamente en datos sintéticos, TabPFN puede, quizás sorprendentemente, superar a otros modelos en casos de uso que involucran tablas relativamente pequeñas con menos de 10.000 filas de datos representativos que pueden tener valores faltantes y valores atípicos. TabPFN puede generalizarse a una variedad de tareas de clasificación en el momento de la inferencia sin la necesidad de una mayor optimización o ajuste de hiperparámetros; Esto se puede lograr mediante el aprendizaje en contexto (ICL), en el que se proporcionan uno o más ejemplos de cómo realizar nuevas tareas como parte del mensaje del modelo básico. Figura 1, de un artículo de seguimiento de Nature realizado por Hollmann et al. (2025), muestra el flujo de trabajo de (a) el entrenamiento previo y el uso, y (b) la arquitectura de alto nivel de TabPFN.
Sin embargo, una desventaja de entrenar el modelo TabPFN usando solo datos sintéticos es que dichos datos no capturan adecuadamente los valores semánticamente significativos que se encuentran en conjuntos de datos reales (por ejemplo, de nombres de columnas, datos categóricos y texto libre). ConTextTab aborda este problema entrenando al transformador en conjuntos de datos del mundo real y utilizando incrustaciones semánticas para datos categóricos y textuales, incluidos los nombres de columnas. Figura 2, del artículo NeurIPS de Spinaci et al. (2025), ilustra la arquitectura de alto nivel de ConTextTab.
La suite SAP-RPT-1 inicial consta de tres modelos: sap-rpt-1-small (un modelo comercial liviano para inferencias y creación de prototipos rápidas), sap-rpt-1-large (un modelo comercial más grande que puede lograr un mayor rendimiento predictivo) y sap-rpt-1-oss (una versión liviana de código abierto disponible en HuggingFace y GitHub). En teoría, los modelos se pueden utilizar para una variedad de tareas de clasificación y regresión utilizando un aprendizaje en contexto de pocas oportunidades. Al momento de escribir este artículo, hay disponible una versión limitada gratuita de SAP-RPT-1 para evaluaciones y pruebas no productivas en un entorno de juegos; probaremos este modelo a continuación.
Demostración práctica
Configuración inicial
Para obtener acceso a la versión de prueba gratuita de SAP-RPT-1, vaya a este enlace e inicie sesión. En la parte inferior de la documentación, debería ver su token API personal; cópielo en un archivo llamado access_token.json para usarlo más adelante de la siguiente manera:
{ "access_token": "" }
Conjunto de datos de prueba
Cree un archivo CSV llamado sales_data_test.csv con los datos que se muestran en la Tabla 1 a continuación. Este conjunto de datos de juguetes también se puede obtener del entorno de juegos SAP-RPT-1 una vez que haya iniciado sesión.
La tarea consiste en predecir valores en la columna SALESGROUP (indicada por los marcadores de posición [PREDICT]) utilizando valores de las columnas restantes. SAP-RPT-1 pone en funcionamiento ICL de pocos disparos al requerir que los datos de entrada incluyan los siguientes tipos de filas:
Al menos dos filas de contexto que contienen los datos completos de un registro determinado, que pueden usarse como ejemplos para ICL. Al menos una fila de consulta que contenga marcadores de posición [PREDICT].
Aunque en teoría SAP-RPT-1 se puede utilizar para la predicción de múltiples objetivos, lo usaremos para la clasificación de un solo objetivo con el conjunto de datos de ventas.
Construyendo y publicando la solicitud de predicción
El punto final de predicción del modelo SAP-RPT-1 espera que la carga útil de la solicitud tenga el siguiente formato:
Especifique dos claves de nivel superior, filas y columna_índice. El valor de las filas deben ser las filas de la tabla de datos de entrada representadas como una lista de objetos del diccionario. El valor de index_column debe ser el nombre de la columna de índice de la tabla de datos de entrada; esto se utilizará como identificador de fila en la respuesta del modelo.
El siguiente fragmento de código muestra cómo crear la carga útil de solicitud según sea necesario desde sales_data_test.csv:
importar pandas como pd importar json solicitudes de importación df = pd.read_csv("sales_data_test.csv") # Cargar el archivo CSV filas = df.to_dict(orient="records") # Convertir a una lista de dicts index_column = "id" payload = { "rows": rows, "index_column": index_column }
La carga útil resultante debería verse así:
{ "filas": [ { "PRODUCTO": "Laptop", "PRECIO": 999,99, "CLIENTE": "Acme Corp", "PAÍS": "EE. UU.", "id": "35", "GRUPO DE VENTAS": "[PREDICTO]" }, { "PRODUCTO": "Silla de oficina", "PRECIO": 142,99, "CLIENTE": "Moebel Biehl", "PAÍS": "Alemania", "id": "571", "GRUPO DE VENTAS": "[PREDICTO]" }, { "PRODUCTO": "Computadora de escritorio", "PRECIO": 750.5, "CLIENTE": "Global Tech", "PAÍS": "Canadá", "id": "42", "GRUPO DE VENTAS": "Soluciones empresariales" }, { "PRODUCTO": "Macbook", "PRECIO": 750.5, "CLIENTE": "Global Tech", "PAÍS": "Canadá", "id": "99", "SALESGROUP": "Enterprise Solutions" }, { "PRODUCTO": "Smartphone", "PRECIO": 499,99, "CLIENTE": "Mobile World", "PAÍS": "Reino Unido", "id": "43", "SALESGROUP": "Consumer Electronics" }, { "PRODUCTO": "Silla de oficina", "PRECIO": 150,8, "CLIENTE": "Furniture Ltd", "PAÍS": "Alemania", "id": "44", "VENTAS GRUPO": "Mobiliario de oficina" }, { "PRODUCTO": "Rack de servidores", "PRECIO": 1200, "CLIENTE": "Data Dynamics", "PAÍS": "Australia", "id": "104", "VENTAS GROUP": "Infraestructura de datos" }, { "PRODUCTO": "Enrutador inalámbrico", "PRECIO": 89,99, "CLIENTE": "Tech Forward", "PAÍS": "India", "id": "204", "SALESGROUP": "Dispositivos de red" } ], "index_column": "id" }
A continuación, podemos crear un diccionario para definir los encabezados de solicitud HTTP de la siguiente manera:
import json # Cargue el token con open("access_token.json", "r") como token_file: token_data = json.load(token_file) AUTH_TOKEN = token_data["access_token"] # Definir encabezados de solicitud HTTP headers = { "Content-Type": "application/json", "Authorization": f"Bearer {AUTH_TOKEN}" }
Finalmente, podemos enviar la solicitud POST y (si tiene éxito) obtener las predicciones en la respuesta:
URL de solicitudes de importación = "https://rpt.cloud.sap/api/predict" respuesta = request.post(url, json=payload, headers=headers) print(response.json())
Si su solicitud no tiene éxito, aquí hay algunos motivos comunes y sus códigos de error:
Solicitud incorrecta (código de error 400): causada por un formato de datos no válido o un error de validación. Compruebe que los componentes de la carga útil (incluidos el contexto y las filas de consulta) estén construidos correctamente. No autorizado (401): causado por un token de API no válido o faltante. Asegúrese de que su token almacenado en access_token.json coincida con el generado para usted en el área de juegos SAP-RPT-1. Demasiadas solicitudes (429): ocurre si se excede el límite de velocidad o el servicio API no está disponible temporalmente. Este error incluye un encabezado Retry-After que indica cuánto tiempo debe esperar antes de enviar otra solicitud a la API. La limitación de tarifas garantiza que no se abuse del entorno del patio de juegos y también se puede utilizar en las API del modelo comercial para implementar planes de precios escalonados. Servicio no disponible (503): ocurre si el servidor API tiene una carga alta. Este error también incluye el encabezado Retry-After. Error interno del servidor (500): esto puede ocurrir debido a otros problemas del servidor en el lado de SAP (por ejemplo, problemas iniciales durante los meses posteriores al lanzamiento del producto). Póngase en contacto con atención al cliente.
Reformateo de la respuesta de predicción
Al momento de escribir este artículo, cuando se utiliza la API del área de juegos SAP-RPT-1 con los datos de ventas de prueba, el objeto de respuesta se parece a esto:
{ "prediction": { "id": "…", "metadata": { "num_columns": 5, "num_predict_rows": 2, "num_predict_tokens": 2, "num_rows": 6 }, "predicciones": [ { "SALESGROUP": [ { "confidence": null, "prediction": "Enterprise Solutions" } ], "id": 35 }, { "SALESGROUP": [ { "confidence": null, "prediction": "Office Furniture" } ], "id": 571 } ] }, "delay": 302.7692240476608, "aiApiRequestPayload": { "prediction_config": { "target_columns": [ { "name": "SALESGROUP", "placeholder_value": "[PREDICT]", "task_type": "clasificación" } ] }, "rows": [ … ], "index_column": "id", "data_schema": { "PRODUCTO": { "dtype": "categoría" }, "PRECIO": { "dtype": "número" }, "CLIENTE": { "dtype": "categoría" }, "PAÍS": { "dtype": "categoría" }, "id": { "dtype": "número" }, "SALESGROUP": { "dtype": "categoría" } } }, "aiApiResponsePayload": { "id": "84072280-e47e-430e-91e6-008066f1a6d3", "metadata": { "num_columns": 5, "num_predict_rows": 2, "num_predict_tokens": 2, "num_rows": 6 }, "predicciones": [ … ] } }
Lo que normalmente nos interesa son los valores de la clave de predicción (es decir, las predicciones y sus puntuaciones de confianza para los campos de destino) y la clave de retraso (que muestra el tiempo de procesamiento de la solicitud). Tenga en cuenta que los modelos comerciales arrojarían puntuaciones de confianza no nulas según sea necesario. Además, puede resultar conveniente reemplazar los marcadores de posición [PREDICT] con los valores previstos para determinadas tareas posteriores (por ejemplo, imputación de datos y autocompletado). Podemos escribir una función auxiliar para fusionar las predicciones de la respuesta de la API nuevamente en la carga útil original para que funcione para columnas de índice y destino arbitrarias de la siguiente manera:
def merge_predictions(payload, Response_json): # Extraer el nombre de la columna de índice index_column = payload["index_column"] # Extraer las columnas de destino de la carga útil de la solicitud config target_columns = [ col["name"] for col in Response_json["aiApiRequestPayload"]["prediction_config"]["target_columns"] ] # Construir un mapa de predicción codificado por index_column predict_map = {} para pred en respuesta_json["prediction"]["predictions"]: idx_value = pred[index_column] predict_map[idx_value] = {} para objetivo en target_columns: predict_map[idx_value][target] = pred[target][0]["predicción"] # Reemplazar marcadores de posición en las filas de carga útil complete_rows =[]para fila en carga útil["filas"]: idx_value = fila[index_column] para objetivo en target_columns: if str(row[target]).strip().upper() == "[PREDICT]": fila[destino] = predict_map.get(idx_value, {}).get(target, fila[target]) complete_rows.append(row) return { "rows": complete_rows, "columna_índice": columna_índice }
Uso de ejemplo:
Response_json = Response.json() if "error" in Response_json: # Ejemplo de manejo de un error de límite de velocidad print(f"Error de API: {response_json['error']}. Vuelva a intentarlo después de {response_json.get('retryAfter')} segundos.") else: complete_payload = merge_predictions(payload, Response_json) print(json.dumps(completed_payload, indent=2))
Esto debería reformatear la carga útil con los valores previstos completados:
{ "rows": [ { "PRODUCTO": "Laptop", "PRECIO": 999,99, "CLIENTE": "Acme Corp", "PAÍS": "EE. UU.", "id": 35, "SALESGROUP": "Enterprise Solutions" }, { "PRODUCTO": "Silla de oficina", "PRECIO": 142,99, "CLIENTE": "Moebel Biehl", "PAÍS": "Alemania", "id": 571, "SALESGROUP": "Mobiliario de Oficina" }, … ], "index_column": "id" }
Pros y contras
Algunos beneficios clave de los modelos de base tabular basados en ICL se derivan del hecho de que los clientes pueden comenzar con un modelo de IA sofisticado que está previamente entrenado en datos relevantes para el negocio a gran escala, en lugar de tener que entrenar un modelo desde cero. En las primeras etapas del descubrimiento y desarrollo de productos, los clientes pueden iterar sobre prototipos de casos de uso de IA de manera más eficiente y económica aprovechando el modelo previamente entrenado directamente con aprendizaje de pocas o ninguna oportunidad. Por ejemplo, trabajar con modelos SAP-RPT-1 puede ser tan simple como pasar algunas filas de datos en un formato tabular familiar a la API de IA y recibir una respuesta con predicciones en un formato estándar (por ejemplo, JSON) que se puede integrar fácilmente en el resto del flujo de trabajo del prototipo.
La combinación de un modelo previamente entrenado e ICL puede reducir drásticamente la barrera para la experimentación de casos de uso. Ofrecer modelos comerciales pequeños y grandes permite a los clientes diferir costos al optar por la versión pequeña durante la creación temprana de prototipos y cambiar a la versión grande para usar en producción según sea necesario. Trabajar con diferentes tamaños de modelos también brinda a los clientes información práctica sobre las compensaciones relacionadas (por ejemplo, entre precisión predictiva, latencia y costo, como se analiza en este artículo), lo que mejora la alfabetización en IA. De manera similar, ofrecer versiones de modelos de código abierto puede ayudar a educar a los clientes, fomentar la participación de la comunidad de desarrolladores y generar confianza en el proveedor del modelo.
Sin embargo, las mismas características del producto alabadas anteriormente pueden implicar posibles desventajas que podrían anular los beneficios. Para utilizar eficazmente los canales de inferencia basados en ICL en producción, los clientes aún pueden terminar invirtiendo significativamente en áreas como ingeniería de características, diseño rápido, generación de recuperación aumentada y ajuste de modelos. Dados los requisitos personalizados de muchos casos de uso (especialmente en ERP), es poco probable que los clientes utilicen modelos con aprendizaje de pocas o ninguna oportunidad.
De hecho, es muy posible que el paradigma ICL termine siendo (ab)usado para funcionar como el paso de entrenamiento en el aprendizaje automático supervisado tradicional, al cargar grandes conjuntos de datos de entrenamiento en el contexto del modelo para cada llamada de inferencia. Si se realizan varias llamadas para el mismo escenario de IA de alto uso (por ejemplo, predecir conversiones de ventas basándose en datos históricos de transacciones), los clientes pueden terminar cargando y enviando el mismo gran conjunto de datos (de entrenamiento) en el contexto del modelo para varias llamadas de inferencia. Es posible que el servicio que aprovisiona el modelo y/o las aplicaciones consumidoras deba implementar una lógica inteligente (por ejemplo, compresión de datos de contexto, reducción de resolución, almacenamiento en caché, etc.) para evitar transferencias de datos en línea redundantes, de alta latencia, ambientalmente insostenibles y potencialmente inseguras (especialmente para casos de uso de alta frecuencia y en tiempo real).
En última instancia, sin más innovación, paradigmas como ICL pueden simplemente trasladar los costos de un “grupo” a otro (por ejemplo, de “gastos generales de capacitación de modelos” a “gastos generales de ingeniería rápida” o “latencia de inferencia”) y no reducir sustancialmente los costos generales de desarrollo y mantenimiento de productos (ni aumentar el valor comercial) de los casos de uso de IA.
Caminos estratégicos a seguir
Las narrativas de marketing para los modelos básicos nos alientan a imaginar un futuro en el que una gran cartera de modelos de casos de uso específicos sea reemplazada por un conjunto mucho más pequeño de “supermodelos” de aplicación general, o incluso “un modelo que los gobierne a todos”. Por supuesto, el atractivo instintivo y el anhelo de modelos universales no es exclusivo de la IA. En física, por ejemplo, la búsqueda de la “teoría del todo” busca unificar las fuerzas fundamentales (gravedad, electromagnetismo y las fuerzas nucleares fuerte y débil) en un marco único y cohesivo. Sin embargo, una teoría tan abarcadora sigue siendo difícil de alcanzar; diferentes escalas (por ejemplo, cósmica versus cuántica) requieren diferentes modelos, la gravedad parece resistirse a la integración con la mecánica cuántica y terminamos con unificaciones parciales (por ejemplo, cromodinámica cuántica y teoría electrodébil). Y lo mismo puede ocurrir con los modelos básicos de IA. De hecho, durante el lanzamiento del producto SAP-RPT-1, SAP introdujo no una sino tres variantes de modelo (grande, pequeña y de código abierto). Estas variantes abarcaron al menos dos dimensiones conceptuales: tamaño del modelo (grande frente a pequeño) y transparencia (cerrado frente a código abierto).
Entonces, mirando hacia el futuro, la pregunta interesante no es si se producirá la especialización del modelo, sino con qué rapidez, en qué dimensiones conceptuales y con qué efecto práctico. Para un proveedor de ERP como SAP, por ejemplo, podría tener sentido ofrecer modelos básicos especializados para un conjunto manejable de procesos de negocio clave (por ejemplo, “obtener para pagar”, “diseñar para operar”, “generar efectivo” y “reclutar para jubilarse”). Los modelos podrían desglosarse aún más por industria o segmento de clientes para mejorar la calidad de la predicción. Incluso proporcionar un modelo especializado por cliente sería una mejora significativa con respecto al status quo; cada modelo podría entrenarse para aprender patrones específicos del cliente (asegurando que las predicciones tengan sentido en el contexto comercial de un cliente determinado) y no correr el riesgo de filtrar información confidencial entre los clientes (el modelo para el cliente A no habrá visto los datos utilizados para entrenar el modelo para el cliente B y, por lo tanto, no se puede piratear fácilmente para revelar patrones de datos confidenciales de B).
Finalmente, proveedores como SAP también pueden diferenciar entre modelos alojados centralmente y aquellos que se implementan en dispositivos perimetrales. Si bien los modelos alojados centralmente tienen varias ventajas (p. ej., escalabilidad, facilidad de actualización, acceso a datos de capacitación más amplios), los modelos implementados en el borde pueden adaptarse mejor a ciertas necesidades de casos de uso (p. ej., ajuste específico del dispositivo; requisitos regulatorios sobre el manejo de datos confidenciales en la atención médica; permitir la toma de decisiones en tiempo real en la fabricación, IoT y vehículos autónomos; trabajar en ubicaciones con conectividad a Internet irregular).
La envoltura
En este artículo hemos cubierto la teoría y un estudio de caso práctico de transformadores relacionales preentrenados en el contexto de modelos de base tabular. Mirando a través del prisma del lanzamiento de SAP de sus modelos RPT, queda claro que un futuro en el que un modelo los gobierne a todos está lejos de estar predeterminado. Al menos según la evidencia actual, es más probable que veamos el surgimiento de varios modelos de fundamentos especializados que reflejan la intersección de varias dimensiones conceptuales diferentes (por ejemplo, tamaño, dominio, apertura): menos un rey león entre modelos y más una colmena de abejas, cada una de las cuales aporta su fuerza única al conjunto colectivo. Las empresas ricas en datos, como SAP, tienen varias opciones estratégicas abiertas en su búsqueda por aprovechar el poder de los modelos de base tabular para construir un ecosistema de herramientas de inteligencia artificial con visión de futuro que pueda evolucionar con las necesidades comerciales y el progreso tecnológico.