{"id":34578,"date":"2025-09-17T10:21:16","date_gmt":"2025-09-17T13:21:16","guid":{"rendered":"https:\/\/building.nubank.com\/?p=34578"},"modified":"2025-09-17T10:55:31","modified_gmt":"2025-09-17T13:55:31","slug":"dandole-a-los-modelos-de-fundacion-una-nocion-del-ahora","status":"publish","type":"post","link":"https:\/\/building.nubank.com\/es\/dandole-a-los-modelos-de-fundacion-una-nocion-del-ahora\/","title":{"rendered":"D\u00e1ndole a los Modelos de Fundaci\u00f3n una Noci\u00f3n del Ahora"},"content":{"rendered":"\n

Autor: Fabio Souza<\/em><\/p>\n\n\n\n

En Nubank, estamos constantemente ampliando los l\u00edmites de c\u00f3mo la Inteligencia Artificial puede ayudarnos a comprender mejor las jornadas financieras de nuestros clientes. En publicaciones anteriores, detallamos c\u00f3mo 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\u00edficas [3], y demostramos c\u00f3mo optimizamos narrativas de usuarios seleccionando y representando cuidadosamente caracter\u00edsticas y fuentes de transacci\u00f3n [5].<\/p>\n\n\n\n

Sin embargo, el mencionado recorrido de optimizar narrativas de usuarios es continuo. Como destacamos en nuestras publicaciones anteriores, la elecci\u00f3n de qu\u00e9 informaci\u00f3n incluir de una transacci\u00f3n y c\u00f3mo 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\u00f3n: la marca de tiempo de cu\u00e1ndo ocurri\u00f3 la transacci\u00f3n. La forma en que codificamos el \u2033<\/span>cu\u00e1ndo\u2033<\/span> de una transacci\u00f3n puede impactar significativamente la capacidad de un modelo de base para entender el estado financiero de un cliente y predecir comportamientos futuros.<\/p>\n\n\n\n

En el resto de esta publicaci\u00f3n del blog, primero discutimos los desaf\u00edos de usar marcas de tiempo absolutas. Luego, proponemos un enfoque diferente que utiliza deltas de tiempo para representar la informaci\u00f3n temporal, detallando el proceso de dise\u00f1o y decisiones clave. Por \u00faltimo, presentamos el dise\u00f1o experimental y los resultados que validan este nuevo enfoque en un problema real de negocios.<\/p>\n\n\n\n

El Desaf\u00edo con Marcas de Tiempo Absolutas<\/h2>\n\n\n\n

Inicialmente, para representar transacciones, nuestros modelos a nivel de token utilizaban marcas de tiempo absolutas, codificadas por tokens especiales como <MES>, <D\u00cdA> y <D\u00cdA DE LA SEMANA> para cada operaci\u00f3n. Aunque es un m\u00e9todo simple, este enfoque creaba varios desaf\u00edos para un modelo de base, que est\u00e1 dise\u00f1ado para crear representaciones de usuarios a lo largo de per\u00edodos extensos. La figura a continuaci\u00f3n muestra el procedimiento de tokenizaci\u00f3n de transacciones que nuestros modelos [2,4] ya usaban.<\/p>\n\n\n\n

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

Imagina que un cliente se quede inactivo por un largo per\u00edodo, como un a\u00f1o, y luego vuelva a realizar transacciones. Si el modelo depende \u00fanicamente de marcas de tiempo absolutas, las representaciones (embeddings) generadas durante el per\u00edodo de inactividad ser\u00edan siempre las mismas. Es decir, el modelo no tiene una \u2033<\/span>noci\u00f3n del ahora\u2033<\/span>. Esta falta de sensibilidad a los per\u00edodos de inactividad hace que las representaciones puedan no reflejar con precisi\u00f3n el comportamiento actual del cliente. Esta capacidad es, de hecho, algo inherente a los recursos de aprendizaje autom\u00e1tico tradicionales, que se calculan a lo largo del tiempo en relaci\u00f3n con una \u2033<\/span>fecha de puntuaci\u00f3n\u2033<\/span> (por ejemplo, 1 mes, 3 meses, 6 meses).<\/p>\n\n\n\n

Adem\u00e1s, la codificaci\u00f3n con marcas de tiempo absolutas puede hacer que los modelos se ajusten en exceso a per\u00edodos de fechas espec\u00edficas o a combinaciones de <MES><D\u00cdA><D\u00cdA DE LA SEMANA> y otros atributos de transacci\u00f3n. Esto ocurre principalmente si los datos de entrenamiento cubren menos de un a\u00f1o 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\u00e1n fuera del per\u00edodo de entrenamiento (out-of-time – OOT).<\/p>\n\n\n\n

Introducci\u00f3n a las Diferencias de Tiempo: Un Enfoque Relativo<\/h2>\n\n\n\n

Para solucionar las limitaciones de las codificaciones de tiempo absoluto, planteamos la hip\u00f3tesis de que ser\u00eda m\u00e1s eficaz representar la informaci\u00f3n de tiempo como un \u2033<\/span>delta de tiempo\u2033<\/span>, o la \u2033<\/span>edad\u2033<\/span> de la transacci\u00f3n en relaci\u00f3n con la fecha de puntuaci\u00f3n (el \u2033<\/span>ahora\u2033<\/span>). Este enfoque permite que las representaciones (embeddings) reflejen los per\u00edodos de inactividad y capten mejor la relevancia y la novedad de transacciones pasadas.<\/p>\n\n\n\n

Al igual que hicimos con otros atributos de transacci\u00f3n, implementamos este enfoque creando un token especial. M\u00e1s espec\u00edficamente, cuantizamos los deltas de tiempo en \u2033<\/span>cubos\u2033<\/span> distintos, de forma similar a c\u00f3mo manejamos los valores de las transacciones. Estos cubos luego son representados por sus propios tokens especiales, como:<\/p>\n\n\n\n