Durante casi toda la última década, si necesitabas un modelo de machine learning para detección de fraude, PBC o crédito que funcionara bien en producción, entrenabas un modelo de árboles con gradiente potenciado (gradient-boosted tree). XGBoost no triunfó porque la investigación no ofreciera nada mejor, sino porque nadie igualaba su coste, su velocidad y su facilidad de explicación. El aprendizaje profundo implicaba un costoso entrenamiento en GPU para cada cliente, una inferencia más lenta y un modelo que los equipos de riesgo tenían que justificar ante la creencia generalizada de que era una caja negra. 

En Oscilar también trabajábamos así. Desarrollamos un modelo específico para cada cliente y cada tipología de riesgo, asignamos un científico de datos para ajustarlo y lo reentrenamos conforme llegan nuevas etiquetas. Funciona. Pero también es lento de construir, se vuelve obsoleto entre reentrenamientos y cada nuevo cliente supone un modelo más que mantener. Ninguno de esos modelos aprende del resto.

Por eso, nuestro equipo de ciencia de datos se planteó otra pregunta:

¿Podría un único modelo atender a cada cliente y tipología de riesgo, mantenerse al día con cada caso confirmado y seguir siendo tan explicable como XGBoost?

Ese es el modelo fundacional tabular que hemos construido. En este artículo explicamos nuestro enfoque: qué es un modelo fundacional tabular, las tres formas en que el sector está aplicando estos modelos al riesgo y por qué nos decantamos por esta opción.

¿Qué es un modelo fundacional tabular?

Un modelo fundacional tabular es un modelo preentrenado con grandes volúmenes de datos estructurados en filas y columnas, de modo que puede hacer predicciones sobre una nueva tabla sin haber visto esos datos antes ni haber sido entrenado específicamente con ellos. En lugar de reentrenarse con los datos de cada cliente, lee los ejemplos etiquetados y la transacción entrante como contexto en el momento de la decisión, y devuelve una puntuación directamente.

El término «modelo fundacional» suele asociarse a los chatbots, pero los modelos del lenguaje (LLM) son solo una de sus vertientes. La idea de fondo es más amplia, al igual que la arquitectura. La mayoría de los modelos fundacionales, incluidos los LLM, se basan en transformers, y estos se presentan en distintas variantes. El nuestro es un transformer diseñado para tablas. En lugar de leer palabras en una frase, lee filas y columnas, y utiliza la atención para ponderar qué ejemplos y variables del pasado son más relevantes para la transacción actual. El modelo se preentrena una sola vez con un conjunto de datos amplio y variado para que aprenda patrones generales; a partir de ahí, puede abordar nuevas tareas sin necesidad de entrenarse desde cero.

Cuando le haces una pregunta a un LLM, no se reentrena con ella: lee tu instrucción (prompt) y responde. Un modelo fundacional tabular hace lo mismo con filas y columnas. El «prompt» es el historial etiquetado del cliente: transacciones, solicitudes, cuentas y sus resultados confirmados. La respuesta es una puntuación de riesgo.

La entrada no incluye texto libre, por lo que el modelo no puede alucinar. Lee los mismos datos estructurados que ya utilizan nuestros modelos. Además, es un modelo distinto de los LLM que alimentan a nuestro copiloto de IA y a los agentes. Alojamos el modelo de riesgo internamente, sin ninguna API de terceros en el flujo de decisión.

Tres formas de aplicar modelos fundacionales a la toma de decisiones de fraude y riesgo

El sector ha optado a grandes rasgos por tres enfoques.

1. Embeddings integrados en otro modelo. Es el camino seguido por arquitecturas como TabBert, FATA-Trans y TransTab. Cada transacción se convierte en un vector de alta dimensión que se introduce en un clasificador, como XGBoost, junto a las variables existentes. Esto puede aportar mejoras, pero añade un segundo modelo. La decisión pasa a depender de cientos de dimensiones inexplicables y generar esos vectores en tiempo real resulta costoso. 

2. Modelos fundacionales relacionales.  KumoRFM es el referente de este enfoque. Su gran ventaja es la capacidad de procesar múltiples tablas a la vez sin necesidad de ingeniería de variables. Sin embargo, presenta inconvenientes notables: altos costes de computación, reentrenamientos diarios y un modelo destilado para cumplir con la latencia. Además, generan embeddings en lugar de puntuaciones, por lo que un modelo posterior sigue tomando la decisión, y cualquier cambio en el esquema afecta a todo el pipeline. Los cambios tardan al menos un día en reflejarse, lo que resta agilidad frente a alternativas, sobre todo en un entorno de fraude que puede cambiar en cuestión de 15 minutos. Por último, no son explicables, un rasgo clave en casos de uso de fraude y crédito.

3. Modelos fundacionales tabulares. Operan sobre una sola tabla y proporcionan la puntuación directamente. El entrenamiento se realiza durante la inferencia. Algunos ejemplos conocidos son TabPFN y TabICL. 

Elegimos el tercer enfoque y queremos ser transparentes sobre lo que implica. Un modelo tabular no elimina la ingeniería de variables, por lo que automatizamos ese proceso. Tampoco ofrece de forma nativa la baja latencia que exige la detección de fraude en tiempo real; lograr que respondiera en menos de 100 milisegundos requirió un esfuerzo de ingeniería considerable. Asumimos ese trabajo por las ventajas que ofrece a cambio.

Ventajas del enfoque con modelos fundacionales tabulares

El uso de un modelo fundacional tabular ofrece cinco ventajas clave frente a las otras alternativas: 

• El entrenamiento se realiza en la inferencia. Cada caso confirmado enriquece la siguiente decisión, sin reentrenamientos nocturnos ni esperas al siguiente ciclo del modelo. Esta cualidad transforma la operativa de los equipos de riesgo.

• Puntúa de forma directa. Un solo modelo toma la decisión. No hay un clasificador secundario por detrás.

• Las explicaciones funcionan igual que hoy. La atribución de variables mediante valores SHAP y los códigos de motivo funcionan exactamente igual que en XGBoost, de modo que auditores y reguladores analizan los mismos informes habituales. Si un proceso de cumplimiento exige el formato tradicional, podemos destilar el modelo en un XGBoost estándar.

• Las variables se modifican en segundos. Añadir, eliminar o modificar una variable no obliga a reconstruir el modelo. En cuanto los datos de entrada cambian, el modelo queda listo para operar.

• Un solo modelo cubre fraude, PBC, crédito y riesgo de dispositivos y comportamiento. Mejoramos y mantenemos un único activo en vez de una flota creciente de modelos a medida. El tiempo de desarrollo pasa de semanas a días.

Rendimiento

Los resultados varían según el conjunto de datos y el caso de uso. En nuestras pruebas de rendimiento, el modelo fundacional tabular ha mejorado la exhaustividad (recall) entre un 35% y un 65% manteniendo la misma tasa de impacto en ciertos conjuntos de datos: detecta más fraude sin penalizar a los buenos clientes. En otros, rinde al mismo nivel que XGBoost. Aun así, se obtiene esa precisión a partir de un único modelo compartido que actualiza su contexto en segundos, en lugar de esperar a un reentrenamiento.

Su ventaja es más evidente cuando escasean los datos etiquetados. Un modelo XGBoost por cliente necesita un amplio historial etiquetado para ser fiable. Un modelo fundacional tabular parte de lo aprendido durante su preentrenamiento, por lo que rinde mucho mejor con un volumen menor de casos confirmados.

Con qué datos se entrena el modelo

El modelo se preentrena de forma desconectada con patrones de fraude del sector y escenarios de ataque sintéticos, incluidos casos diseñados para anticipar patrones aún no etiquetados. Al momento de la decisión, los casos confirmados del cliente se incorporan como contexto.

Los datos y etiquetas de cada cliente se utilizan exclusivamente para sus propias predicciones. Nunca influyen en los resultados de otros clientes.

El modelo sigue necesitando etiquetas. Para ciertos casos de uso (ACH, PBC, depósitos con tarjeta y señales de dispositivo y comportamiento), disponemos de versiones optimizadas listas para usar desde el primer día. En el resto, su valor aumenta a medida que se incorporan los resultados confirmados con rapidez. Los equipos con pocos datos etiquetados también obtienen grandes resultados, ya que ahí es donde la ventaja frente a XGBoost es mayor.

Modelos fundacionales tabulares frente a modelos de consorcio

Los modelos de consorcio aúnan datos etiquetados de múltiples participantes y entrenan un único modelo para un caso de uso específico. Su principal atractivo es que funcionan de inmediato. En contrapartida, se actualizan lentamente, suelen beneficiar a los participantes más grandes, cada cambio en las variables debe esperar al siguiente ciclo de entrenamiento y solo reconocen patrones ya experimentados por sus miembros.

Una forma de entender esta relación: un modelo de consorcio es un modelo fundacional cuyo contexto no se puede modificar. Los datos etiquetados con los que se entrena un consorcio son equivalentes al contexto que lee un modelo fundacional tabular. Al cambiar el contexto, se obtiene un modelo adaptado a otro caso de uso, actualizado con la siguiente etiqueta en lugar de esperar a una revisión anual.

La ventaja competitiva no reside en el modelo

No buscamos competir con los mayores laboratorios de IA en el entrenamiento básico de modelos, ni nos hace falta. La investigación sobre modelos fundacionales tabulares es de acceso abierto. Lo que determina si uno de estos modelos funciona en un entorno de riesgo real es todo lo que lo rodea: qué datos procesa, con qué rapidez responde, cómo justifica sus decisiones y cómo se monitoriza y despliega.

Ahí es donde nuestro equipo de ciencia de datos centra sus esfuerzos. Al eliminar el entrenamiento individual por cliente, el factor determinante en el rendimiento pasa a ser la ingeniería continua de contexto tabular, es decir, decidir qué datos debe consultar el modelo en cada decisión. Es una disciplina incipiente, y es ahí donde queremos seguir marcando la diferencia.

Qué supone este cambio para los equipos de riesgo

• Modelos más rápidos. Crear un modelo hoy lleva semanas en vez de meses, y trabajamos para implementar en una semana un punto de conexión activo y listo para evaluar transacciones en producción.

• Decisiones siempre actualizadas. El modelo aprende del fraude confirmado hoy mismo, sin esperar al siguiente reentrenamiento. Actualizamos su contexto en segundos (5,8 segundos, exactamente) sin interrumpir la evaluación en directo.

• La misma trazabilidad para auditorías. Se mantienen los mismos códigos de motivo y atribuciones de variables, ofreciendo la misma claridad ante las preguntas de un regulador.

• Una base más sólida para los agentes de IA. Los agentes investigan, redactan informes y recomiendan reglas, mientras que el modelo y tus reglas toman las decisiones. Dado que el modelo genera códigos de motivo, tanto tus analistas como los agentes pueden explicar con precisión lo ocurrido.

En qué punto nos encontramos

El modelo ya está operativo con nuestro primer cliente piloto y compartiremos los resultados en cuanto estén listos para publicarse. Además, anunciaremos próximamente un seminario web donde Saurabh Bajaj y Eddy Fathi explicarán este enfoque en directo, incluyendo una demostración interactiva de cómo razona el modelo en cada decisión.

Preguntas frecuentes

¿Qué es un modelo fundacional tabular?

Es un modelo preentrenado con grandes volúmenes de datos estructurados en filas y columnas, capaz de hacer predicciones sobre una nueva tabla sin necesidad de entrenarse desde cero. En el momento de la decisión, lee el historial etiquetado de un cliente como contexto y devuelve directamente una puntuación de riesgo.

¿En qué se diferencia de XGBoost?

Un modelo XGBoost suele entrenarse para un cliente y un tipo de riesgo en particular, y debe reentrenarse cada vez que llegan nuevas etiquetas. Un modelo fundacional tabular sirve para múltiples clientes y tipos de riesgo, y cada etiqueta confirmada actualiza la siguiente decisión sin requerir un reentrenamiento. La explicabilidad no cambia: utiliza atribuciones de variables SHAP y códigos de motivo.

¿Pueden los reguladores y auditores revisar sus decisiones?

Sí. Genera los mismos códigos de motivo y atribuciones de variables SHAP que XGBoost. Si un proceso de cumplimiento normativo requiere el formato tradicional, el modelo se puede destilar en un modelo XGBoost estándar.

¿Es un modelo fundacional tabular un modelo del lenguaje (LLM)?

No. Solo procesa datos estructurados, sin texto libre, por lo que no genera alucinaciones. Oscilar aloja el modelo de forma interna y no interviene ninguna API de terceros en la toma de decisiones.

¿Afectan los datos de un cliente a las puntuaciones de otro?

No. Los datos y etiquetas de cada cliente se emplean exclusivamente en sus propias predicciones.