Author: Daniel Braithwaite and Hiroto Udagawa

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

Este es el segundo artículo de una serie de publicaciones sobre cómo modelamos las finanzas de nuestros clientes utilizando modelos fundacionales. Para una introducción al problema, te recomendamos leer la primera publicación de la serie.

En nuestra publicación anterior, “Entendiendo las finanzas de nuestros clientes a través de modelos fundacionales”, presentamos cómo Nubank utiliza modelos fundacionales para construir representaciones de usuarios a partir de los datos de transacciones. Explicamos cómo estos modelos, entrenados con grandes cantidades de datos no etiquetados mediante aprendizaje auto-supervisado, pueden descubrir características generales y generar embeddings informativos del comportamiento financiero de los clientes. Esta estrategia va más allá de la ingeniería de atributos tabulares tradicional y nos ayuda a comprender mejor las necesidades de nuestros usuarios.

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

Los transformers operan sobre secuencias de embeddings, así que necesitamos definir un proceso que convierta las transacciones de un usuario en una forma que el modelo pueda procesar. Aquí presentamos una manera de construir esa interfaz que, en esencia, convierte nuestro problema de modelado de transacciones en uno que puede abordarse con técnicas estándar de lenguaje natural.

Para este artículo, asumimos que una transacción tiene tres atributos: el monto (representado como un número decimal), la fecha (como un timestamp) y una descripción (como texto libre). Si bien este enfoque es simplificado, en la práctica podemos construir representaciones y codificadores para muchos otros atributos relevantes de una transacción, como el ID del comercio, la ubicación, la categoría, el motivo de rechazo, etc.

Una opción simple para construir esta interfaz sería asignar un ID a cada transacción única, como se hace en literatura sobre recomendación secuencial (por ejemplo, SASRec [4]). Por ejemplo, podríamos mapear cada combinación de descripción, 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úmero de combinaciones posibles de transacciones es extremadamente alto, lo que implicaría un espacio de IDs inmenso. Es posible reducir ese espacio usando, por ejemplo, el ID del comercio en lugar de la descripción, pero esto eliminaría información potencialmente valiosa y agregaría dependencias de preprocesamiento, lo que vuelve el modelo más frágil. Segundo, este enfoque sufre del problema del cold start: el modelo no puede manejar transacciones que no haya visto durante el entrenamiento.

Otra opción para conectar transacciones con transformers es usar el enfoque text-is-all-you-need [5], que en el caso de la recomendación de productos crea cadenas de texto combinando los nombres de atributos (como descripción, monto, fecha) con sus valores correspondientes (por ejemplo, “NETFLIX.com”, $32.40, 12/05/2023). Esta técnica también 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ón se represente con muchos tokens, lo cual puede ser un problema, ya que el costo computacional del mecanismo de atención crece de forma cuadrática con la longitud del contexto.

La figura de abajo muestra un ejemplo de las dos interfaces transacción-embedding mencionadas. Sin embargo, para nuestros modelos fundacionales, elegimos una versión modificada de text-is-all-you-need, donde representamos características numéricas y categóricas usando tokens especiales (las características numéricas se convierten previamente en categorías discretas mediante un proceso de cuantización). En los experimentos presentados en esta publicación, representamos cada transacción de la siguiente forma:

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

Este formato también facilita incluir otros atributos categóricos o numéricos adicionales. Además, usar tokens especiales nos permite reducir el número total de tokens en comparación con una estrategia 100% textual. A continuación mostramos un ejemplo completo de esta representación:

Ahora que tenemos una forma de representar una transacción 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ímite de contexto predefinido.

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

Por supuesto, la familia de modelos basados en transformers es muy amplia y requiere bastante exploración. 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ón estándar, a medida que variamos la configuración del modelo. Para acelerar los experimentos (y respetar los límites de hardware), usamos una longitud de contexto corta de 1024 tokens, que llamamos CL.

  • Modelo 1 (Baseline): atención bidireccional con tarea de MLM.
  • Modelo 1 fragmentado (Chunked): extiende artificialmente la longitud de contexto al ejecutar el mismo modelo sobre bloques independientes y promediar los embeddings (fragmentos de 8 × CL tokens). Mejora de 1.64 puntos sobre el baseline.
  • Modelo 2: utiliza atención dispersa (sparse attention) para duplicar la longitud del contexto a 2 × CL sin errores de memoria. Mejora de 1.8 puntos.
  • Modelo 2 fragmentado: mejora relativa de 2.78 puntos.
  • Modelo 3 SM: cambia a atención causal, elimina los embeddings posicionales mediante NoPE [6] (los modelos causales aprenden su propia noción de posición) y agrega FlashAttention [7] (una implementación más eficiente de la atención, con mejor escalabilidad), permitiendo una longitud de contexto de 8 × CL. Mejora de 3.93 puntos.
  • Modelo 3 LG: cuadruplica el número de parámetros y mejora 7.2 puntos en comparación al baseline.

Finalmente, el modelo LG afinado (Fine-tuned LG) aplica un procedimiento de fine-tuning adicional sobre el Modelo 3 LG, entrenándolo para predecir directamente la etiqueta objetivo. Este modelo mejora 9 puntos respecto al baseline.

Para ponerlo en perspectiva: una mejora relativa de apenas 1 a 1.25 puntos en estas tareas ya es lo suficientemente significativa como para justificar el lanzamiento de una nueva versión del modelo.

En este artículo mostramos cómo reducir el problema de modelar secuencias de transacciones a uno que puede resolverse con métodos de lenguaje natural estándar. A pesar de su simplicidad, este enfoque genera embeddings útiles que aportan valor a múltiples tareas dentro de Nubank. También vimos un adelanto del impacto que puede tener el ajuste fino (fine-tuning).

Este es el segundo artículo de nuestra serie sobre modelos fundacionales aplicados a transacciones. Estos modelos nos permiten entender mejor las finanzas de nuestros clientes y responder a sus necesidades en el momento justo. En el próximo artículo hablaremos sobre nuestra estrategia de joint fusión, que nos permite adaptar estos modelos fundacionales a tareas específicas e incorporar soluciones basadas en atributos tabulares. También exploraremos otros aspectos de nuestro enfoque de modelado fundamental en futuras publicaciones.

Resumen de la serie

Si llegaste hasta aquí, te invitamos a revisar el resto de la serie de blogs para obtener más contexto y profundidad técnica sobre este enfoque.

  • En el primer blog post, evaluamos el potencial de los foundation models aplicados a datos transaccionales, demostrando cómo el aprendizaje auto-supervisado puede generar embeddings generales que capturan el comportamiento del cliente sin depender de datos etiquetados.
  • En el segundo blog post, profundizamos en la formulación técnica de nuestros foundation models, detallando la arquitectura basada en transformadores causales y cómo estos embeddings pueden aplicarse a distintas tareas downstream.
  • En el tercer blog post, exploramos cómo mejorar el rendimiento en tareas específicas mediante supervised fine-tuning e introdujimos el concepto de joint fusion, un enfoque que combina datos secuenciales y tabulares en un único proceso de entrenamiento de extremo a extremo.

Descubre las oportunidades

Referencias

[1] Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., … & Polosukhin, I. (2017). Attention is all you need. Advances in neural information processing systems, 30.

[2] Rumelhart, David E; Hinton, Geoffrey E, and Williams, Ronald J (Sept. 1985). Learning internal representations by error propagation. Tech. rep. ICS 8504. San Diego, California: Institute for Cognitive Science, University of California.

[3] Jordan, Michael I. (May 1986). Serial order: a parallel distributed processing approach. Tech. rep. ICS 8604. San Diego, California: Institute for Cognitive Science, University of California.

[4] Kang, W. C., & McAuley, J. (2018, November). Self-attentive sequential recommendation. In 2018 IEEE international conference on data mining (ICDM) (pp. 197-206). IEEE.

[5] Li, J., Wang, M., Li, J., Fu, J., Shen, X., Shang, J., & McAuley, J. (2023, August). Text is all you need: Learning language representations for sequential recommendation. In Proceedings of the 29th ACM SIGKDD Conference on Knowledge Discovery and Data Mining (pp. 1258-1267).

[6] Kazemnejad, A., Padhi, I., Natesan Ramamurthy, K., Das, P., & Reddy, S. (2023). The impact of positional encoding on length generalization in transformers. Advances in Neural Information Processing Systems, 36, 24892-24928.

[7] Dao, T., Fu, D., Ermon, S., Rudra, A., & Ré, C. (2022). Flashattention: Fast and memory-efficient exact attention with io-awareness. Advances in neural information processing systems, 35, 16344-16359.

Descubre las oportunidades