Este año, en AUSAPE, organizamos un pequeño experimento en el stand de Code10: un desafío de predicción en directo, Humanos vs SAP-RPT-1, el modelo básico de SAP para datos relacionales.
Mostramos un caso extraído de un conjunto de datos real, la gente adivinó el resultado y, a continuación, le pedimos al modelo que hiciera lo mismo. Tras casi 70 rondas, ganaron los humanos: 67% frente a 54%.
Ese resultado provocó algunas risas y muchas preguntas. La que más me repetían era: ¿Cómo lo has construido exactamente? A continuación, te ofrecemos una explicación técnica: qué es el RPT-1, cómo lo pusimos en marcha en la feria y en qué situaciones tiene sentido utilizar un modelo como este en la producción.
¿Qué es SAP-RPT-1 (y por qué es interesante)?
La mayoría de los modelos predictivos con los que has trabajado están entrenados para una sola tarea: se toma un conjunto de datos, se entrena un modelo con él, y ese modelo solo conoce ese problema. Hay que volver a entrenarlo para el siguiente conjunto de datos.
RPT-1 adopta un enfoque diferente: la misma idea que subyace a los grandes modelos de lenguaje, aplicada a las tablas. No se entrena por conjunto de datos. Se le proporciona un conjunto de filas de ejemplo como contexto, a continuación, se le proporciona una nueva fila y se le pide que prediga el valor que falta. Sin actualizaciones del gradiente, sin ajuste fino. El modelo generaliza los ejemplos que tiene delante. A esto se le suele llamar aprendizaje contextual, y RPT-1 lo adapta a datos estructurados y relacionales.
Hay dos aspectos que hacen que esto resulte llamativo viniendo de SAP. En primer lugar, se basa en un artículo que publicaron: ConTextTab, a artículo destacado en NeurIPS 2025, una investigación revisada por pares que respalda el lanzamiento de un producto, algo que no se ve todos los días en el ámbito del software empresarial. En segundo lugar, han publicado la implementación en Hugging Face como sap-rpt-1-oss bajo una licencia Apache 2.0. Una advertencia que conviene tener en cuenta para el uso empresarial: los checkpoints de código abierto están pensados para la investigación, por lo que heredan las restricciones de sus datos de entrenamiento (por lo que no son una solución lista para usar en producción). Para ello, SAP ofrece versiones alojadas a través de SAP AI Core (la línea alojada ha pasado desde entonces a RPT-1.5). Aun así, disponer de una implementación abierta para descargar es lo que nos permitió crear una demostración en días en lugar de meses.
La arquitectura
La configuración constaba de tres elementos:
- Interfaz de usuario: la interfaz de usuario del stand en el que jugaban los usuarios, alojada en AWS.
- Servidor: un servicio FastAPI que contiene la lógica del juego (conjuntos de datos, rondas, puntuación), también en AWS.
- Inferencia: un servicio independiente que envuelve el modelo y se ejecuta localmente en un NVIDIA DGX Spark (Edición Fundadores).
¿Por qué mantener la inferencia por separado? Porque RPT-1 está diseñado para ejecutarse en una GPU. SAP recomienda una GPU con 80 GB de memoria para el tamaño de contexto completo. Ya teníamos un NVIDIA DGX Spark en la oficina que utilizamos para experimentos, así que para un evento de dos días tenía sentido ejecutar la inferencia allí en lugar de pagar por una instancia de GPU en la nube. El backend simplemente lo invocó a través de un sencillo punto de conexión HTTPS, y el marcador se trasladó a AWS S3.
Esa separación también es una buena práctica en general: el servicio del modelo se dedica a una sola cosa (predecir), y a la aplicación que lo rodea no le importa si el modelo se ejecuta localmente, en la nube o a través de la API alojada de SAP. Cambiar uno por otro es tan sencillo como modificar la configuración.
Cómo funciona realmente la predicción
El modelo de código abierto ofrece una interfaz familiar, al estilo de scikit-learn. Hay que tener en cuenta que la función `fit()` no realiza el entrenamiento; simplemente pasa las filas del contexto.
from sap_rpt_oss import SAP_RPT_OSS_Classifier
clf = SAP_RPT_OSS_Classifier(max_context_size=2048)
# "fit" solo carga filas de ejemplo como contexto; aquí no se realiza ningún entrenamiento
clf.fit(context_rows, context_labels)
# Predecir un caso no visto
prediction = clf.predict(new_case)
confidence = clf.predict_proba(new_case)[0].max()Si utilizas la API alojada en lugar del modelo local, el mismo concepto se refleja en el formato de la solicitud. Se envían las filas de contexto y la fila de consulta juntas, y se marca el valor que se desea predecir con un token [PREDICT]:
{
"filas": [
{"importe": "1200", "país": "ES", "objetivo": "Legítimo"},
{"amount": "9900", "country": "RU", "target": "Fraud"},
{"amount": "4300", "country": "ES", "target": "[PREDICT]"}
]
}El modelo lee los ejemplos etiquetados y rellena el campo [PREDICT]. Eso es todo. No hay fase de entrenamiento ni hay que gestionar ningún archivo del modelo por cada conjunto de datos.
Para el juego, utilizamos dos conjuntos de datos públicos de Kaggle (fraude bancario y mantenimiento predictivo)
Por qué ganaron los humanos (y por qué eso no es lo que aparece en los titulares)
Es tentador interpretar “67% contra 54%” como “los humanos vencieron a la IA”. Y así fue, en este juego. Pero el juego estaba deliberadamente diseñado para que resultara fácil a un humano: un solo caso, unas pocas columnas, una apuesta de sí o no. Con dos o tres variables sobre la mesa, la intuición humana es difícil de superar.
Ese no es el tipo de datos para el que se ha diseñado RPT-1. Está pensado para tablas de gran tamaño (con docenas de columnas, registros históricos y relaciones entre tablas) en las que una persona no puede asimilar toda la información mentalmente. SAP informa de hasta Un rendimiento 3,5 veces superior al de un modelo de lenguaje grande (LLM) de uso general en tareas de predicción tabular en ese contexto (su número, no un punto de referencia independiente). Un juego de adivinanzas en una feria comercial no mide nada de eso.
Así que la conclusión honesta que se puede sacar del experimento no es que “los humanos ganan”. Es que la pregunta nunca es humano o IA. Es ¿Cuál, para qué problema?.
¿En qué casos tiene sentido utilizar un modelo como el RPT-1 en la producción?
Esto es lo que realmente importa una vez que hayas superado la demo. Algunas reglas generales que he aprendido al desarrollar esto:
Es una opción ideal cuando:
- Tienes un problema de predicción tabular/relacional (rotación de clientes, fraude, retrasos, riesgo de fallo) con muchas columnas y datos históricos.
- Necesitas resultados rápidamente y no quieres crear y mantener un modelo entrenado para cada caso de uso. El enfoque contextual elimina el proceso de entrenamiento.
- Te encuentras en una situación de «arranque en frío»: un problema nuevo del que dispones de algunos ejemplos etiquetados, pero no los suficientes como para justificar un proceso de entrenamiento completo.
Ten cuidado cuando:
- La latencia y el coste son importantes a gran escala. La inferencia requiere una GPU. En el caso de un stand, se trata de una inversión puntual; en cambio, en una línea de producción a gran escala, supone un gasto real que hay que tener en cuenta a la hora de dimensionar el proyecto.
- El problema es pequeño o sencillo. Si unas pocas características y un poco de lógica de dominio ya bastan para resolverlo, un modelo base es excesivo y, como demostró nuestro juego, no es necesariamente mejor.
- La gobernanza de los datos y las licencias están en juego. Hay dos aspectos que hay que tener en cuenta. El envío de registros empresariales a un punto final alojado plantea las cuestiones habituales relacionadas con los datos. Por otra parte, los puntos de control de código abierto están pensados para uso en investigación (heredan las restricciones de sus datos de entrenamiento), por lo que son ideales para experimentar en tu propio hardware, pero no constituyen por sí solos una solución para producción. Para la producción, se utilizaría la versión alojada y con licencia de SAP, razón por la cual la división entre local y nube en nuestra arquitectura es importante.
En muchos casos empresariales, la respuesta adecuada sigue siendo un modelo clásico y bien conocido (como el «gradient boosting», por ejemplo). El RPT-1 demuestra su valía cuando la alternativa es ningún modelo en absoluto porque no merecía la pena formar a uno. Y eso supone más problemas de lo que parece.
Lo que haríamos de otra manera
La versión de prueba se creó con el objetivo de divertirnos y ganar velocidad. Para una evaluación real, la aplicaríamos a un conjunto de datos empresarial realmente amplio (del tipo para el que está pensada la RPT-1), la compararíamos directamente con una línea de base de gradient boosting optimizada y mediríamos la latencia y el coste bajo carga, en lugar de por clic. Ese es el experimento que realmente indicaría a un cliente si debe utilizarla.
