{"id":32571,"date":"2025-04-22T09:55:31","date_gmt":"2025-04-22T12:55:31","guid":{"rendered":"https:\/\/building.nubank.com\/?p=32571"},"modified":"2025-05-14T12:15:16","modified_gmt":"2025-05-14T15:15:16","slug":"definindo-uma-interface-entre-dados-de-transacoes-e-modelos-fundacionais","status":"publish","type":"post","link":"https:\/\/building.nubank.com\/pt-br\/definindo-uma-interface-entre-dados-de-transacoes-e-modelos-fundacionais\/","title":{"rendered":"Definindo uma interface entre dados de transa\u00e7\u00f5es e modelos fundacionais"},"content":{"rendered":"\n

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

O trabalho descrito aqui \u00e9 um esfor\u00e7o colaborativo de v\u00e1rios engenheiros do Nubank (em ordem alfab\u00e9tica): 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 pelo apoio.<\/em><\/p>\n\n\n\n

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

\n\n\n\n

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

Este \u00e9 o segundo post de uma s\u00e9rie sobre como modelamos as finan\u00e7as dos nossos clientes usando modelos fundacionais. Para uma introdu\u00e7\u00e3o ao problema, confira o <\/em>primeiro post da s\u00e9rie<\/em><\/a>. <\/em><\/p>\n\n\n\n

No post anterior, \u201cEntendendo as finan\u00e7as dos nossos clientes por meio de modelos fundacionais<\/a>\u201d, mostramos como o Nubank usa modelos fundacionais para construir representa\u00e7\u00f5es de usu\u00e1rios a partir de dados de transa\u00e7\u00f5es. Apresentamos como esses modelos, treinados com grandes volumes de dados n\u00e3o rotulados por meio de aprendizado auto supervisionado, conseguem descobrir caracter\u00edsticas gerais e gerar embeddings informativos sobre o comportamento financeiro dos clientes. Essa abordagem vai al\u00e9m da forma tradicional de extrair e transformar atributos tabulares a partir de dados de transa\u00e7\u00e3o, com o objetivo de aprimorar nossa compreens\u00e3o das necessidades dos nossos usu\u00e1rios.<\/p>\n\n\n\n

Utilizamos transformers [1] como nossa arquitetura base, j\u00e1 que atualmente eles s\u00e3o a principal escolha para solucionar problemas que envolvem dados sequenciais. Al\u00e9m disso, s\u00e3o especialmente eficazes em capturar rela\u00e7\u00f5es de longo prazo dentro da sequ\u00eancia de entrada (em compara\u00e7\u00e3o com RNNs [2, 3]). Isso \u00e9 particularmente \u00fatil no caso de dados de transa\u00e7\u00f5es, considerando varia\u00e7\u00f5es sazonais e c\u00edclicas nos h\u00e1bitos de consumo (por exemplo, as pessoas costumam gastar mais durante o fim de ano).<\/p>\n\n\n\n

Transformers operam sobre sequ\u00eancias de embeddings. Por isso, precisamos definir um processo que converta as transa\u00e7\u00f5es de um usu\u00e1rio em embeddings que o transformer consiga processar. Aqui, apresentamos uma forma de criar essa interface que, essencialmente, transforma nosso problema de modelagem de transa\u00e7\u00f5es em algo que pode ser resolvido com t\u00e9cnicas padr\u00e3o de linguagem natural.<\/p>\n\n\n\n

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

Para este post, vamos assumir que uma transa\u00e7\u00e3o \u00e9 composta por tr\u00eas atributos: o seu valor representado como um n\u00famero decimal (float), a data representada como um timestamp, e a descri\u00e7\u00e3o representada como uma string. Embora esse formato seja simplificado, na pr\u00e1tica podemos construir representa\u00e7\u00f5es e codificadores para os muitos atributos \u00fanicos das transa\u00e7\u00f5es, como ID do comerciante, localiza\u00e7\u00e3o, categoria, motivo de recusa da transa\u00e7\u00e3o etc.<\/p>\n\n\n\n

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

Uma op\u00e7\u00e3o direta para construir essa interface \u00e9 atribuir um ID para cada transa\u00e7\u00e3o \u00fanica, de forma semelhante ao que \u00e9 feito na literatura de recomenda\u00e7\u00e3o sequencial, como o SASRec [4]. Por exemplo, podemos mapear cada combina\u00e7\u00e3o \u00fanica de descri\u00e7\u00e3o, data e valor para um ID diferente, e ent\u00e3o converter esses IDs em embeddings usando uma tabela de lookup aprendida junto com o transformador. No entanto, essa abordagem tem duas desvantagens principais. Primeiro, o n\u00famero de poss\u00edveis combina\u00e7\u00f5es de transa\u00e7\u00f5es \u00e9 muito alto, o que exigiria um espa\u00e7o de IDs enorme. \u00c9 poss\u00edvel reduzir esse espa\u00e7o usando, por exemplo, o ID do comerciante no lugar da descri\u00e7\u00e3o, mas isso pode remover informa\u00e7\u00f5es importantes e introduzir depend\u00eancias de pr\u00e9-processamento adicionais, tornando os modelos mais fr\u00e1geis. Segundo, essa abordagem tamb\u00e9m sofre com o problema de cold start \u2014 ou seja, o modelo n\u00e3o consegue lidar com transa\u00e7\u00f5es que nunca viu durante o treinamento.<\/p>\n\n\n\n

Outra poss\u00edvel interface entre transa\u00e7\u00f5es e transformers \u00e9 seguir a abordagem \u201ctext-is-all-you-need\u201d [5], que no contexto de recomenda\u00e7\u00e3o de produtos constroi strings de itens concatenando o nome dos atributos (como descri\u00e7\u00e3o, valor, data) com seus respectivos valores (por exemplo, \u201cNETFLIX.com\u201d, R$32,40, 12\/05\/2023). Essa t\u00e9cnica pode ser aplicada tamb\u00e9m aos dados de transa\u00e7\u00f5es usando o mesmo processo. As strings resultantes podem ser tratadas como linguagem natural e convertidas em embeddings com tokenizadores e tabelas de embeddings. Isso permite que o modelo generalize para transa\u00e7\u00f5es nunca vistas e at\u00e9 aproveite modelos de linguagem j\u00e1 existentes, sem necessidade de modifica\u00e7\u00e3o. Por\u00e9m, esse m\u00e9todo faz com que uma \u00fanica transa\u00e7\u00e3o seja representada por muitos tokens, o que \u00e9 um problema, j\u00e1 que o custo computacional do mecanismo de aten\u00e7\u00e3o cresce quadraticamente com o comprimento do contexto.<\/p>\n\n\n\n

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

A figura abaixo mostra um exemplo das duas interfaces entre transa\u00e7\u00f5es e embeddings mencionadas acima. No entanto, para os nossos modelos fundacionais, escolhemos uma vers\u00e3o modificada da abordagem \u201ctext-is-all-you-need\u201d, representando atributos num\u00e9ricos e categ\u00f3ricos com tokens especiais (os atributos num\u00e9ricos s\u00e3o quantizados em intervalos antes de se tornarem categ\u00f3ricos). Para os experimentos apresentados neste post, representamos uma transa\u00e7\u00e3o com os seguintes componentes:<\/p>\n\n\n\n

    \n
  1. Sinal do valor: um token que representa se o valor da transa\u00e7\u00e3o \u00e9 positivo ou negativo.<\/li>\n\n\n\n
  2. Faixa de valor (bucket): os valores absolutos s\u00e3o agrupados em intervalos, e cada um recebe um token diferente.<\/li>\n\n\n\n
  3. M\u00eas, dia e dia da semana: cada um \u00e9 representado com tokens pr\u00f3prios.<\/li>\n\n\n\n
  4. Descri\u00e7\u00e3o: o texto \u00e9 tokenizado como linguagem natural usando um tokenizador padr\u00e3o (como BPE).<\/li>\n<\/ol>\n\n\n\n

    Essa representa\u00e7\u00e3o tamb\u00e9m facilita a inclus\u00e3o de outros atributos categ\u00f3ricos e num\u00e9ricos. Al\u00e9m disso, o uso de tokens especiais reduz o n\u00famero de tokens em compara\u00e7\u00e3o \u00e0 abordagem puramente textual. Abaixo, mostramos um exemplo completo dessa representa\u00e7\u00e3o:<\/p>\n\n\n\n

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

    Agora que temos uma forma de representar uma transa\u00e7\u00e3o como uma string e tokeniz\u00e1-la, podemos aplicar isso ao hist\u00f3rico de um cliente simplesmente concatenando as strings das transa\u00e7\u00f5es com tokens separadores entre elas. Essa string concatenada \u00e9 cortada ao atingir um limite pr\u00e9-definido de tamanho de contexto.<\/p>\n\n\n\n

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

    Por fim, pr\u00e9-treinamos os transformers usando tarefas padr\u00e3o de modelagem de linguagem. Assim como nos modelos de linguagem natural, os tokens de transa\u00e7\u00f5es s\u00e3o convertidos em embeddings por meio de uma tabela de lookup, e o treinamento \u00e9 feito com tarefas auto-supervisionadas como predi\u00e7\u00e3o do pr\u00f3ximo token (NTP) ou modelagem de linguagem mascarada (MLM).<\/p>\n\n\n\n

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

    Claro que a classe de modelos baseada em transformers \u00e9 bastante ampla, o que demanda bastante experimenta\u00e7\u00e3o. A figura abaixo mostra o desempenho m\u00e9dio dos embeddings n\u00e3o supervisionados (ou seja, extra\u00eddos diretamente do modelo pr\u00e9-treinado) em quatro benchmarks de sistemas de recomenda\u00e7\u00e3o, conforme ajustamos a configura\u00e7\u00e3o do modelo. Para acelerar os experimentos (e respeitar os limites de hardware), utilizamos um contexto curto de 1024 tokens, que chamamos de CL.<\/p>\n\n\n\n