Autor: Fabio Souza

En Nubank, estamos constantemente ampliando los límites de cómo la Inteligencia Artificial puede ayudarnos a comprender mejor las jornadas financieras de nuestros clientes. En publicaciones anteriores, detallamos cómo utilizamos modelos de base basados en transformadores para convertir secuencias de datos de transacciones en embeddings poderosos, lo que nos permite atender mejor las necesidades financieras de nuestros clientes en el momento adecuado [1, 4]. Exploramos la interfaz que traduce datos brutos de transacciones en embeddings que nuestros modelos pueden entender [2], discutimos las sutilezas de ajustar estos modelos para tareas específicas [3], y demostramos cómo optimizamos narrativas de usuarios seleccionando y representando cuidadosamente características y fuentes de transacción [5].

Sin embargo, el mencionado recorrido de optimizar narrativas de usuarios es continuo. Como destacamos en nuestras publicaciones anteriores, la elección de qué información incluir de una transacción y cómo representarla es importante, especialmente dado el contexto limitado de nuestras arquitecturas de transformadores. Hoy, nos adentramos en un aspecto crucial de los datos de transacción: la marca de tiempo de cuándo ocurrió la transacción. La forma en que codificamos el ″cuándo″ de una transacción puede impactar significativamente la capacidad de un modelo de base para entender el estado financiero de un cliente y predecir comportamientos futuros.

En el resto de esta publicación del blog, primero discutimos los desafíos de usar marcas de tiempo absolutas. Luego, proponemos un enfoque diferente que utiliza deltas de tiempo para representar la información temporal, detallando el proceso de diseño y decisiones clave. Por último, presentamos el diseño experimental y los resultados que validan este nuevo enfoque en un problema real de negocios.

El Desafío con Marcas de Tiempo Absolutas

Inicialmente, para representar transacciones, nuestros modelos a nivel de token utilizaban marcas de tiempo absolutas, codificadas por tokens especiales como <MES>, <DÍA> y <DÍA DE LA SEMANA> para cada operación. Aunque es un método simple, este enfoque creaba varios desafíos para un modelo de base, que está diseñado para crear representaciones de usuarios a lo largo de períodos extensos. La figura a continuación muestra el procedimiento de tokenización de transacciones que nuestros modelos [2,4] ya usaban.

Imagina que un cliente se quede inactivo por un largo período, como un año, y luego vuelva a realizar transacciones. Si el modelo depende únicamente de marcas de tiempo absolutas, las representaciones (embeddings) generadas durante el período de inactividad serían siempre las mismas. Es decir, el modelo no tiene una ″noción del ahora″. Esta falta de sensibilidad a los períodos de inactividad hace que las representaciones puedan no reflejar con precisión el comportamiento actual del cliente. Esta capacidad es, de hecho, algo inherente a los recursos de aprendizaje automático tradicionales, que se calculan a lo largo del tiempo en relación con una ″fecha de puntuación″ (por ejemplo, 1 mes, 3 meses, 6 meses).

Además, la codificación con marcas de tiempo absolutas puede hacer que los modelos se ajusten en exceso a períodos de fechas específicas o a combinaciones de <MES><DÍA><DÍA DE LA SEMANA> y otros atributos de transacción. Esto ocurre principalmente si los datos de entrenamiento cubren menos de un año completo o si el objetivo tiene una fuerte estacionalidad. Esto limita la capacidad del modelo de generalizar de forma efectiva durante la inferencia, especialmente para datos que están fuera del período de entrenamiento (out-of-time – OOT).

Descubre las oportunidades

Introducción a las Diferencias de Tiempo: Un Enfoque Relativo

Para solucionar las limitaciones de las codificaciones de tiempo absoluto, planteamos la hipótesis de que sería más eficaz representar la información de tiempo como un ″delta de tiempo″, o la ″edad″ de la transacción en relación con la fecha de puntuación (el ″ahora″). Este enfoque permite que las representaciones (embeddings) reflejen los períodos de inactividad y capten mejor la relevancia y la novedad de transacciones pasadas.

Al igual que hicimos con otros atributos de transacción, implementamos este enfoque creando un token especial. Más específicamente, cuantizamos los deltas de tiempo en ″cubos″ distintos, de forma similar a cómo manejamos los valores de las transacciones. Estos cubos luego son representados por sus propios tokens especiales, como:

  • <TIMEDELTA:1-DAY-OR-LESS>
  • <TIMEDELTA:BETWEEN-1-AND-2-DAYS>
  • <TIMEDELTA:BETWEEN-2-AND-3-DAYS>
  • …
  • <TIMEDELTA:BETWEEN-1-AND-2-MONTHS>
  • <TIMEDELTA:BETWEEN-2-AND-3-MONTHS>
  • …
  • <TIMEDELTA:ABOVE-2-YEARS> (with a chosen truncation cap)

Es importante notar que hay dos hiperparámetros que necesitamos elegir. Primero, se debe seleccionar la granularidad/escala de los deltas de tiempo. En segundo lugar, necesitamos definir un límite a partir del cual los deltas de tiempo son truncados. En el ejemplo anterior, el límite de truncamiento del delta de tiempo se definió como dos años. Así, en este caso, cualquier transacción que esté a más de dos años de la fecha de puntuación se trunca al token: <DELTA DE TIEMPO: MÁS-DE-2-AÑOS>. En la sección siguiente, exploramos la definición de estos parámetros al analizar la distribución de los deltas de tiempo en nuestros datos.

Definiendo el Horizonte y la Granularidad del Delta de Tiempo

Como se mencionó, un paso importante para usar de manera eficaz los tokens especiales de delta de tiempo es definir de manera sensata el límite máximo de truncamiento del delta de tiempo. Por ejemplo, elegir un límite muy pequeño puede llevar a la pérdida de información valiosa. Por otro lado, un límite excesivamente grande puede introducir un número exagerado de tokens especiales, que pueden estar mal entrenados si su ocurrencia es rara durante la fase de entrenamiento.

Al trazar la distribución acumulativa de los tamaños de las ventanas temporales de transacción (el tiempo entre la transacción más antigua y la más reciente en una secuencia) para nuestro conjunto de datos de entrenamiento, observamos que casi el 97% de las secuencias contenían transacciones de hasta dos años atrás. Con base en esto, decidimos comenzar a usar dos años como límite para nuestra codificación de delta de tiempo. A continuación, necesitamos elegir una granularidad para los ″cubos″ de delta de tiempo. Experimentamos con dos estrategias de cubos diferentes:

  • Estrategia Estándar: Cubos más granulares para datos recientes (hasta 3 meses), seguidos por cubos mensuales. Esto incluía límites como [0, 1, 2, …, 13, 14, 21, 30, 45, 60, 90, 120, …, 330, 365, …, edad_máxima] días.
  • Cubos menos granulares: Unificamos algunos cubos para transacciones con edades entre 1-2 semanas para evaluar si podíamos descartar la granularidad para transacciones un poco más antiguas. Sus límites eran [0, 1, 2, …, 6, 7, 14, 21, 30, 45, 60, 90, 120, …, 330, 365, …, edad_máxima] días.

Usando la estrategia estándar, trazamos el histograma de los cubos de delta de tiempo, comparando las distribuciones en los conjuntos de datos de entrenamiento, validación y prueba. Podemos ver que las distribuciones son consistentes en las tres divisiones del conjunto de datos, lo cual es una señal positiva para la generalización en el período fuera de tiempo (out-of-time). La estrategia menos granular tiene una distribución similar.

Diseño Experimental y Resultados

Para probar rigurosamente nuestra hipótesis de que una representación de tiempo relativa es mejor que una absoluta, pre-entrenamos cuatro variantes de modelos base en el mismo conjunto de datos, utilizando la tarea de predicción del próximo token. Luego, ajustamos cada variante del modelo para una tarea específica, utilizando un conjunto de datos etiquetados para un problema de negocio. Las variantes fueron:

  1. Línea de Base (Baseline): Usa tokens especiales de <DÍA>, <MES> y <DÍA DE LA SEMANA> para la codificación de marca de tiempo absoluta.
  2. Delta de Tiempo Relativo (REL): Usa solamente la codificación de delta de tiempo relativo con la estrategia de cubos estándar.
  3. Delta de Tiempo Relativo, Menos Granular (REL-LOW): Usa solamente la codificación relativa con la estrategia de cubos menos granular.
  4. Delta de Tiempo Relativo + Codificación Absoluta (REL+ABS): Combina el delta de tiempo relativo con la codificación absoluta de la línea de base.

Para aclarar la distinción entre estas variantes, analicemos un ejemplo de cómo cada una codifica un conjunto de transacciones. Consideremos un usuario que tiene las siguientes 4 transacciones (con fecha, descripción y valor):

  1. 30/08/2025: Supermercado, $300,00
  2. 22/08/2025: Suscripción de streaming, $30,00
  3. 22/07/2025: Suscripción de streaming, $30,00
  4. 10/02/2023: Gasolinera, $200,00

Entonces, usando la fecha de evaluación de 31/08/2025, 00:00:00 AM, obtendríamos los siguientes tokens para las representaciones de tiempo:

  1. Baseline:
    1. <DAY:30><MONTH:AUGUST><WEEKDAY:SUNDAY>
    2. <DAY:22><MONTH:AUGUST><WEEKDAY:FRIDAY>
    3. <DAY:22><MONTH:JULY><WEEKDAY:TUESDAY>
    4. <DAY:10><MONTH:FEBRUARY><WEEKDAY:FRIDAY>
  2. Relative Time-delta (REL):
    1. <TIMEDELTA:1-DAY-OR-LESS>
    2. <TIMEDELTA:BETWEEN-10-AND-11-DAYS>
    3. <TIMEDELTA:BETWEEN-30-AND-45-DAYS>
    4. <TIMEDELTA:ABOVE-2-YEARS>
  3. Relative Time-delta, Less Granular (REL-LOW):
    1. <TIMEDELTA:1-DAY-OR-LESS>
    2. <TIMEDELTA:BETWEEN-7-AND-14-DAYS>
    3. <TIMEDELTA:BETWEEN-30-AND-45-DAYS>
    4. <TIMEDELTA:ABOVE-2-YEARS>
  4. Relative Time-Delta + Absolute Encoding (REL+ABS)
    1. <TIMEDELTA:1-DAY-OR-LESS><DAY:30><MONTH:AUGUST><WEEKDAY:SUNDAY>
    2. <TIMEDELTA:BETWEEN-10-AND-11-DAYS><DAY:22><MONTH:AUGUST><WEEKDAY:FRIDAY>
    3. <TIMEDELTA:BETWEEN-30-AND-45-DAYS><DAY:22><MONTH:JULY><WEEKDAY:TUESDAY>
    4. <TIMEDELTA:ABOVE-2-YEARS><DAY:10><MONTH:FEBRUARY><WEEKDAY:FRIDAY>

Después de pre-entrenar y ajustar cada una de las variantes, evaluamos los cuatro modelos en un conjunto de datos de prueba que contenía información de un período posterior, lo que refleja de manera más precisa el desempeño en un entorno de producción real. La principal métrica de evaluación fue el AUC. La figura a continuación muestra el delta del AUC en comparación con la variante de línea de base.

Principales Conclusiones:

  • Aumento Significativo en el AUC con Codificación Relativa: El modelo con codificación de delta de tiempo relativo logró un aumento de 0,1 punto porcentual en el AUC en comparación con la línea de base de codificación absoluta. Aunque puede no parecer mucho, en un modelo ya altamente optimizado, este aumento se traduce directamente en un impacto comercial a gran escala. Es importante destacar que no estamos añadiendo ninguna información nueva al modelo; la ganancia se obtiene simplemente a través de una mejor representación de la información temporal.
  • No se Debe al Tamaño del Contexto: Curiosamente, la variante del modelo con codificación relativa+absoluta (REL+ABS) demostró un aumento de AUC similar al del modelo puramente relativo. Este es un hallazgo crucial, ya que la codificación relativa usa dos tokens menos por transacción, lo que la hace un 15% más eficiente en escenarios donde el tamaño del contexto está limitado. El hecho de que el REL+ABS (que tiene un tamaño de contexto efectivo menor que el REL debido a más tokens por transacción) aún presente un desempeño similar sugiere que el aumento del AUC es genuinamente debido a la representación del tiempo y no solo a una ventana de contexto extendida.
  • La Granularidad Importa: La codificación relativa con menor resolución tuvo un desempeño peor que las otras variantes. Esto indica que la información de delta de tiempo más granular para transacciones con edades entre una y dos semanas es, de hecho, valiosa. Esta granularidad es especialmente importante para capturar el tiempo transcurrido entre dos transacciones, lo que pierde precisión si las transacciones caen en cubos más amplios.
  • Mejor Generalización a lo Largo del Tiempo: Impulsados por los resultados positivos en el conjunto de prueba estándar, realizamos una evaluación ampliada en un conjunto de pruebas que cubría un período más largo en el futuro (fuera del período de entrenamiento). En este caso, el modelo de delta de tiempo relativo mostró un aumento de AUC aún mayor, de 0,2 pp, en comparación con la línea de base. Además, como se muestra en la figura a continuación, las métricas muestran una tendencia positiva en el delta del AUC (es decir, mejora relativa en comparación con la línea de base) a medida que pasa el tiempo, lo que respalda firmemente la hipótesis de que la codificación relativa generaliza mejor en períodos de tiempo futuros.

En este trabajo, descubrimos que la forma en que representamos la información temporal puede impactar significativamente la capacidad del modelo base para entender el comportamiento financiero del cliente. Codificar el tiempo como deltas de tiempo en lugar de fechas absolutas aumentó el ROC-AUC en 0,2 puntos porcentuales (pp), al mismo tiempo que redujo el número de tokens por transacción en aproximadamente un 15%, permitiendo historias de transacciones más largas dentro del mismo presupuesto de tokens. Estos hallazgos resaltan un principio fundamental: la forma en que diseñamos nuestra representación de datos puede tener un impacto sustancial en el rendimiento del modelo. Los resultados más débiles del ajuste de delta de tiempo menos granular destacan aún más la importancia de la experimentación y evaluación sistemáticas para lograr resultados óptimos.

Referencias

[1] Braithwaite, D., & Udagawa, H. (2025, 24 de Marzo). Entendiendo las finanzas de nuestros clientes a través de modelos fundacionales. Building Nubank. https://building.nubank.com/es/entendiendo-las-finanzas-de-nuestros-clientes-a-traves-de-modelos-fundacionales/ 

[2] Braithwaite, D., & Udagawa, H. (2025, 22 de Abril). Definiendo una interfaz entre los datos de transacciones y los modelos fundamentales. Building Nubank. https://building.nubank.com/es/definiendo-una-interfaz-entre-los-datos-de-transacciones-y-los-modelos-fundamentales/ 

[3] Braithwaite, D., Cavalcanti, M., & Udagawa, H. (2025, 14 de Mayo). Ajuste Fino de Modelos de Usuario Basados en Transacciones. Building Nubank. https://building.nubank.com/es/ajuste-fino-de-modelos-de-usuario-basados-en-transacciones/ 

[4] Braithwaite, D. T., Cavalcanti, M., McEver, R. A., et al (2025). Your Spending Needs Attention: Modeling Financial Habits with Transformers. arXiv preprint arXiv:2507.23267. 

[5] Foust, T. (2025, 29 de julio). Optimizando Narrativas de Usuario para Modelos Fundacionales. Building Nubank. https://building.nubank.com/pt-br/otimizacao-narrativas-usuarios-modelos-fundacionais/ 

Descubre las oportunidades