{"id":34555,"date":"2025-09-17T10:21:16","date_gmt":"2025-09-17T13:21:16","guid":{"rendered":"https:\/\/building.nubank.com\/?p=34555"},"modified":"2025-09-18T23:53:28","modified_gmt":"2025-09-19T02:53:28","slug":"dando-aos-modelos-fundacionais-uma-nocao-do-agora","status":"publish","type":"post","link":"https:\/\/building.nubank.com\/pt-br\/dando-aos-modelos-fundacionais-uma-nocao-do-agora\/","title":{"rendered":"Dando aos Modelos Fundacionais uma No\u00e7\u00e3o do Agora"},"content":{"rendered":"\n

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

No Nubank, estamos constantemente ampliando os limites de como a Intelig\u00eancia Artificial pode nos ajudar a compreender melhor as jornadas financeiras de nossos clientes. Nossos posts anteriores detalharam como utilizamos modelos de base baseados em transformadores para converter sequ\u00eancias de dados de transa\u00e7\u00e3o em embeddings poderosos, permitindo-nos atender melhor \u00e0s necessidades financeiras de nossos clientes no momento certo [1, 4]. Exploramos a interface que traduz dados brutos de transa\u00e7\u00f5es em embeddings que nossos modelos podem entender [2], discutimos as nuances de ajustar esses modelos para tarefas espec\u00edficas [3], e demonstramos como otimizamos narrativas de usu\u00e1rios selecionando e representando cuidadosamente caracter\u00edsticas e fontes de transa\u00e7\u00e3o [5].<\/p>\n\n\n\n

No entanto, a jornada mencionada de otimizar narrativas de usu\u00e1rios \u00e9 cont\u00ednua. Como destacamos em nossos posts anteriores, a escolha de qual informa\u00e7\u00e3o de uma transa\u00e7\u00e3o incluir e como represent\u00e1-la \u00e9 importante, especialmente dado o contexto limitado das nossas arquiteturas de transformadores. Hoje, nos aprofundamos em um aspecto crucial dos dados de transa\u00e7\u00e3o: o timestamp de quando a transa\u00e7\u00e3o ocorreu. A forma como codificamos o “quando” de uma transa\u00e7\u00e3o pode impactar significativamente a capacidade de um modelo de base em entender o estado financeiro de um cliente e prever comportamentos futuros.<\/p>\n\n\n\n

No restante deste post do blog, primeiro discutimos os desafios de usar timestamps absolutos. Em seguida, propomos uma abordagem diferente que utiliza deltas de tempo para representar a informa\u00e7\u00e3o temporal, detalhando o processo de design e decis\u00f5es-chave. Por fim, apresentamos o desenho experimental e os resultados que validam essa nova abordagem em um problema real de neg\u00f3cios.<\/p>\n\n\n\n

O Desafio com Carimbos de Data\/Hora Absolutos<\/h2>\n\n\n\n

Inicialmente, para representar transa\u00e7\u00f5es, nossos modelos de n\u00edvel de token usavam carimbos de data\/hora absolutos, codificados por tokens especiais como <M\u00caS>, <DIA> e <DIA DA SEMANA> para cada opera\u00e7\u00e3o. Apesar de ser um m\u00e9todo simples, essa abordagem criava v\u00e1rios desafios para um modelo fundacional, que \u00e9 feito para criar representa\u00e7\u00f5es de usu\u00e1rios ao longo de per\u00edodos extensos. A figura a seguir mostra o procedimento de tokeniza\u00e7\u00e3o de transa\u00e7\u00f5es que nossos modelos [2,4] j\u00e1 usavam.<\/p>\n\n\n\n

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

Imagine que um cliente fica inativo por um longo per\u00edodo, como um ano, e depois volta a fazer transa\u00e7\u00f5es. Se o modelo depender apenas de carimbos de data\/hora absolutos, as representa\u00e7\u00f5es (embeddings) geradas durante o per\u00edodo de inatividade seriam sempre as mesmas. Ou seja, o modelo n\u00e3o tem uma “no\u00e7\u00e3o do agora”. Essa falta de sensibilidade aos per\u00edodos de inatividade faz com que as representa\u00e7\u00f5es possam n\u00e3o refletir com precis\u00e3o o comportamento atual do cliente. Essa capacidade \u00e9, na verdade, algo inerente a recursos de aprendizado de m\u00e1quina tradicionais, que s\u00e3o calculados ao longo do tempo em rela\u00e7\u00e3o a uma “data de pontua\u00e7\u00e3o” (por exemplo, 1 m\u00eas, 3 meses, 6 meses).<\/p>\n\n\n\n

Al\u00e9m disso, a codifica\u00e7\u00e3o com carimbos de data\/hora absolutos pode fazer com que os modelos se ajustem excessivamente a per\u00edodos de datas espec\u00edficas ou a combina\u00e7\u00f5es de <M\u00caS><DIA><DIA DA SEMANA> e outros atributos de transa\u00e7\u00e3o. Isso acontece principalmente se os dados de treinamento cobrirem menos de um ano inteiro ou se o objetivo tiver uma forte sazonalidade. Isso limita a capacidade do modelo de generalizar de forma eficaz durante a infer\u00eancia, especialmente para dados que est\u00e3o fora do per\u00edodo de treinamento (out-of-time – OOT).<\/p>\n\n\n\n

Introdu\u00e7\u00e3o \u00e0s Diferen\u00e7as de Tempo: Uma Abordagem Relativa<\/h2>\n\n\n\n

Para solucionar as limita\u00e7\u00f5es das codifica\u00e7\u00f5es de tempo absoluto, levantamos a hip\u00f3tese de que seria mais eficaz representar a informa\u00e7\u00e3o de tempo como um “delta de tempo”, ou a “idade” da transa\u00e7\u00e3o em rela\u00e7\u00e3o \u00e0 data de pontua\u00e7\u00e3o (o “agora”). Essa abordagem permite que as representa\u00e7\u00f5es (embeddings) reflitam os per\u00edodos de inatividade e captem melhor a relev\u00e2ncia e a rec\u00eancia de transa\u00e7\u00f5es passadas.<\/p>\n\n\n\n

Assim como fizemos com outros atributos de transa\u00e7\u00e3o, implementamos essa abordagem ao criar um token especial. Mais especificamente, quantizamos os deltas de tempo em “baldes” distintos, de forma semelhante a como lidamos com os valores das transa\u00e7\u00f5es. Esses baldes s\u00e3o ent\u00e3o representados por seus pr\u00f3prios tokens especiais, como:<\/p>\n\n\n\n