{"id":32575,"date":"2025-04-22T09:55:31","date_gmt":"2025-04-22T12:55:31","guid":{"rendered":"https:\/\/building.nubank.com\/?p=32575"},"modified":"2025-05-14T12:13:01","modified_gmt":"2025-05-14T15:13:01","slug":"definiendo-una-interfaz-entre-los-datos-de-transacciones-y-los-modelos-fundamentales","status":"publish","type":"post","link":"https:\/\/building.nubank.com\/es\/definiendo-una-interfaz-entre-los-datos-de-transacciones-y-los-modelos-fundamentales\/","title":{"rendered":"Definiendo una interfaz entre los datos de transacciones y los modelos fundamentales"},"content":{"rendered":"\n

Author: Daniel Braithwaite<\/a> and Hiroto Udagawa<\/a><\/em><\/p>\n\n\n\n

El trabajo descrito aqu\u00ed es un esfuerzo colaborativo de varios ingenieros de Nubank (en orden alfab\u00e9tico): Abhishek Shivanna, Arissa Yoshida, Austin McEver, Brian Zanfelice, Cristiano Breuel, Evan Wingert, Fabio Souza, Felipe Meneses, Helder Dias, Henrique Fernandes, Liam O\u2019Neill, Marcelo Buga, Matheus Ramos, and Misael Cavalcanti. We also thank Rohan Ramanath, Daniel Silva, and Guilherme Tanure por su apoyo.<\/em><\/p>\n\n\n\n

<\/p>\n\n\n\n

\n\n\n\n

<\/p>\n\n\n\n

Este es el segundo art\u00edculo de una serie de publicaciones sobre c\u00f3mo modelamos las finanzas de nuestros clientes utilizando modelos fundacionales. Para una introducci\u00f3n al problema, te recomendamos leer <\/em>la primera publicaci\u00f3n de la serie<\/em><\/a>.<\/em><\/p>\n\n\n\n

En nuestra publicaci\u00f3n anterior, \u201cEntendiendo las finanzas de nuestros clientes a trav\u00e9s de modelos fundacionales<\/a>\u201d, presentamos c\u00f3mo Nubank utiliza modelos fundacionales<\/em> para construir representaciones de usuarios a partir de los datos de transacciones. Explicamos c\u00f3mo estos modelos, entrenados con grandes cantidades de datos no etiquetados mediante aprendizaje auto-supervisado, pueden descubrir caracter\u00edsticas generales y generar embeddings informativos del comportamiento financiero de los clientes. Esta estrategia va m\u00e1s all\u00e1 de la ingenier\u00eda de atributos tabulares tradicional y nos ayuda a comprender mejor las necesidades de nuestros usuarios.<\/p>\n\n\n\n

Usamos transformers [1] como la arquitectura base para nuestros modelos de secuencia a secuencia, ya que actualmente son la opci\u00f3n predominante para resolver problemas de modelado secuencial. Adem\u00e1s, son especialmente buenos aprovechando relaciones de largo plazo dentro de las secuencias de entrada (en comparaci\u00f3n con las RNNs [2, 3]), lo cual puede ser particularmente \u00fatil en datos de transacciones, dado que los h\u00e1bitos de consumo suelen tener variaciones c\u00edclicas o estacionales (por ejemplo, durante las festividades muchas personas tienden a gastar m\u00e1s).<\/p>\n\n\n\n

Los transformers operan sobre secuencias de embeddings, as\u00ed que necesitamos definir un proceso que convierta las transacciones de un usuario en una forma que el modelo pueda procesar. Aqu\u00ed presentamos una manera de construir esa interfaz que, en esencia, convierte nuestro problema de modelado de transacciones en uno que puede abordarse con t\u00e9cnicas est\u00e1ndar de lenguaje natural.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Para este art\u00edculo, asumimos que una transacci\u00f3n tiene tres atributos: el monto (representado como un n\u00famero decimal), la fecha (como un timestamp) y una descripci\u00f3n (como texto libre). Si bien este enfoque es simplificado, en la pr\u00e1ctica podemos construir representaciones y codificadores para muchos otros atributos relevantes de una transacci\u00f3n, como el ID del comercio, la ubicaci\u00f3n, la categor\u00eda, el motivo de rechazo, etc.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Una opci\u00f3n simple para construir esta interfaz ser\u00eda asignar un ID a cada transacci\u00f3n \u00fanica, como se hace en literatura sobre recomendaci\u00f3n secuencial (por ejemplo, SASRec [4]). Por ejemplo, podr\u00edamos mapear cada combinaci\u00f3n de descripci\u00f3n, fecha y monto a un ID distinto, y luego convertir estos IDs en embeddings utilizando una tabla de lookup entrenada junto con el transformador. Sin embargo, este enfoque tiene dos desventajas importantes. Primero, el n\u00famero de combinaciones posibles de transacciones es extremadamente alto, lo que implicar\u00eda un espacio de IDs inmenso. Es posible reducir ese espacio usando, por ejemplo, el ID del comercio en lugar de la descripci\u00f3n, pero esto eliminar\u00eda informaci\u00f3n potencialmente valiosa y agregar\u00eda dependencias de preprocesamiento, lo que vuelve el modelo m\u00e1s fr\u00e1gil. Segundo, este enfoque sufre del problema del cold start: el modelo no puede manejar transacciones que no haya visto durante el entrenamiento.<\/p>\n\n\n\n

Otra opci\u00f3n para conectar transacciones con transformers es usar el enfoque text-is-all-you-need [5], que en el caso de la recomendaci\u00f3n de productos crea cadenas de texto combinando los nombres de atributos (como descripci\u00f3n, monto, fecha) con sus valores correspondientes (por ejemplo, \u201cNETFLIX.com\u201d, $32.40, 12\/05\/2023). Esta t\u00e9cnica tambi\u00e9n puede aplicarse a datos de transacciones. Las cadenas resultantes pueden tratarse como lenguaje natural y convertirse en embeddings mediante un tokenizador y una tabla de embeddings. Esto permite que el modelo generalice a transacciones no vistas y que incluso aproveche modelos de lenguaje existentes sin modificaciones. Sin embargo, este enfoque hace que cada transacci\u00f3n se represente con muchos tokens, lo cual puede ser un problema, ya que el costo computacional del mecanismo de atenci\u00f3n crece de forma cuadr\u00e1tica con la longitud del contexto.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

La figura de abajo muestra un ejemplo de las dos interfaces transacci\u00f3n-embedding mencionadas. Sin embargo, para nuestros modelos fundacionales, elegimos una versi\u00f3n modificada de text-is-all-you-need, donde representamos caracter\u00edsticas num\u00e9ricas y categ\u00f3ricas usando tokens especiales (las caracter\u00edsticas num\u00e9ricas se convierten previamente en categor\u00edas discretas mediante un proceso de cuantizaci\u00f3n). En los experimentos presentados en esta publicaci\u00f3n, representamos cada transacci\u00f3n de la siguiente forma:<\/p>\n\n\n\n

    \n
  1. Signo del monto: un token que indica si el monto es positivo o negativo.<\/li>\n\n\n\n
  2. Rango de monto (bucket): los valores absolutos se agrupan en intervalos, y cada intervalo recibe un token distinto.<\/li>\n\n\n\n
  3. Mes, d\u00eda y d\u00eda de la semana: cada uno se representa con su propio token.<\/li>\n\n\n\n
  4. Descripci\u00f3n: el texto se tokeniza como lenguaje natural usando un tokenizador est\u00e1ndar (por ejemplo, BPE).<\/li>\n<\/ol>\n\n\n\n

    Este formato tambi\u00e9n facilita incluir otros atributos categ\u00f3ricos o num\u00e9ricos adicionales. Adem\u00e1s, usar tokens especiales nos permite reducir el n\u00famero total de tokens en comparaci\u00f3n con una estrategia 100% textual. A continuaci\u00f3n mostramos un ejemplo completo de esta representaci\u00f3n:<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Ahora que tenemos una forma de representar una transacci\u00f3n como una cadena y tokenizarla, podemos aplicarlo al historial de un cliente simplemente concatenando las cadenas de sus transacciones, usando tokens separadores entre ellas. Esta secuencia se trunca cuando alcanza un l\u00edmite de contexto predefinido.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Finalmente, preentrenamos nuestros transformers utilizando tareas est\u00e1ndar de modelado de lenguaje. Al igual que en los modelos de lenguaje natural, los tokens de transacci\u00f3n se convierten en embeddings mediante una tabla de lookup, y entrenamos el modelo con tareas auto-supervisadas como predicci\u00f3n del siguiente token (next token prediction, NTP) o modelado de lenguaje enmascarado (masked language modeling, MLM).<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Por supuesto, la familia de modelos basados en transformers es muy amplia y requiere bastante exploraci\u00f3n. La figura de abajo muestra el rendimiento promedio de los embeddings no supervisados (es decir, embeddings generados por el modelo preentrenado) en cuatro tareas de recomendaci\u00f3n est\u00e1ndar, a medida que variamos la configuraci\u00f3n del modelo. Para acelerar los experimentos (y respetar los l\u00edmites de hardware), usamos una longitud de contexto corta de 1024 tokens, que llamamos CL.<\/p>\n\n\n\n