Author: Daniel Braithwaite and Hiroto Udagawa

O trabalho descrito aqui é um esforço colaborativo de vários engenheiros do Nubank (em ordem alfabética): 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 pelo apoio.

Este é o segundo post de uma série sobre como modelamos as finanças dos nossos clientes usando modelos fundacionais. Para uma introdução ao problema, confira o primeiro post da série. 

No post anterior, “Entendendo as finanças dos nossos clientes por meio de modelos fundacionais”, mostramos como o Nubank usa modelos fundacionais para construir representações de usuários a partir de dados de transações. Apresentamos como esses modelos, treinados com grandes volumes de dados não rotulados por meio de aprendizado auto supervisionado, conseguem descobrir características gerais e gerar embeddings informativos sobre o comportamento financeiro dos clientes. Essa abordagem vai além da forma tradicional de extrair e transformar atributos tabulares a partir de dados de transação, com o objetivo de aprimorar nossa compreensão das necessidades dos nossos usuários.

Utilizamos transformers [1] como nossa arquitetura base, já que atualmente eles são a principal escolha para solucionar problemas que envolvem dados sequenciais. Além disso, são especialmente eficazes em capturar relações de longo prazo dentro da sequência de entrada (em comparação com RNNs [2, 3]). Isso é particularmente útil no caso de dados de transações, considerando variações sazonais e cíclicas nos hábitos de consumo (por exemplo, as pessoas costumam gastar mais durante o fim de ano).

Transformers operam sobre sequências de embeddings. Por isso, precisamos definir um processo que converta as transações de um usuário em embeddings que o transformer consiga processar. Aqui, apresentamos uma forma de criar essa interface que, essencialmente, transforma nosso problema de modelagem de transações em algo que pode ser resolvido com técnicas padrão de linguagem natural.

Para este post, vamos assumir que uma transação é composta por três atributos: o seu valor representado como um número decimal (float), a data representada como um timestamp, e a descrição representada como uma string. Embora esse formato seja simplificado, na prática podemos construir representações e codificadores para os muitos atributos únicos das transações, como ID do comerciante, localização, categoria, motivo de recusa da transação etc.

Uma opção direta para construir essa interface é atribuir um ID para cada transação única, de forma semelhante ao que é feito na literatura de recomendação sequencial, como o SASRec [4]. Por exemplo, podemos mapear cada combinação única de descrição, data e valor para um ID diferente, e então 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úmero de possíveis combinações de transações é muito alto, o que exigiria um espaço de IDs enorme. É possível reduzir esse espaço usando, por exemplo, o ID do comerciante no lugar da descrição, mas isso pode remover informações importantes e introduzir dependências de pré-processamento adicionais, tornando os modelos mais frágeis. Segundo, essa abordagem também sofre com o problema de cold start — ou seja, o modelo não consegue lidar com transações que nunca viu durante o treinamento.

Outra possível interface entre transações e transformers é seguir a abordagem “text-is-all-you-need” [5], que no contexto de recomendação de produtos constroi strings de itens concatenando o nome dos atributos (como descrição, valor, data) com seus respectivos valores (por exemplo, “NETFLIX.com”, R$32,40, 12/05/2023). Essa técnica pode ser aplicada também aos dados de transações 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ções nunca vistas e até aproveite modelos de linguagem já existentes, sem necessidade de modificação. Porém, esse método faz com que uma única transação seja representada por muitos tokens, o que é um problema, já que o custo computacional do mecanismo de atenção cresce quadraticamente com o comprimento do contexto.

A figura abaixo mostra um exemplo das duas interfaces entre transações e embeddings mencionadas acima. No entanto, para os nossos modelos fundacionais, escolhemos uma versão modificada da abordagem “text-is-all-you-need”, representando atributos numéricos e categóricos com tokens especiais (os atributos numéricos são quantizados em intervalos antes de se tornarem categóricos). Para os experimentos apresentados neste post, representamos uma transação com os seguintes componentes:

  1. Sinal do valor: um token que representa se o valor da transação é positivo ou negativo.
  2. Faixa de valor (bucket): os valores absolutos são agrupados em intervalos, e cada um recebe um token diferente.
  3. Mês, dia e dia da semana: cada um é representado com tokens próprios.
  4. Descrição: o texto é tokenizado como linguagem natural usando um tokenizador padrão (como BPE).

Essa representação também facilita a inclusão de outros atributos categóricos e numéricos. Além disso, o uso de tokens especiais reduz o número de tokens em comparação à abordagem puramente textual. Abaixo, mostramos um exemplo completo dessa representação:

Agora que temos uma forma de representar uma transação como uma string e tokenizá-la, podemos aplicar isso ao histórico de um cliente simplesmente concatenando as strings das transações com tokens separadores entre elas. Essa string concatenada é cortada ao atingir um limite pré-definido de tamanho de contexto.

Por fim, pré-treinamos os transformers usando tarefas padrão de modelagem de linguagem. Assim como nos modelos de linguagem natural, os tokens de transações são convertidos em embeddings por meio de uma tabela de lookup, e o treinamento é feito com tarefas auto-supervisionadas como predição do próximo token (NTP) ou modelagem de linguagem mascarada (MLM).

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

  • Modelo 1 (Baseline): atenção bidirecional com a tarefa de MLM.
  • Modelo 1 em blocos (Chunked): aumenta artificialmente o contexto ao rodar o mesmo modelo em múltiplos blocos independentes e fazer a média dos embeddings (blocos de 8 × CL tokens). Isso gera uma melhora de 1,64 ponto sobre o baseline.
  • Modelo 2: usa atenção esparsa para aumentar o contexto para 2 × CL sem estourar a memória. Melhora de 1,8 ponto sobre o baseline.
  • Modelo 2 em blocos: melhora relativa de 2,78 pontos sobre o baseline.
  • Modelo 3 SM: troca para atenção causal e adiciona NoPE [6] (ou seja, remove embeddings posicionais, pois modelos causais aprendem sua própria noção de posição) e FlashAttention [7] (uma implementação mais eficiente da atenção, com melhor escalabilidade), permitindo contexto de até 8 × CL. Gera um ganho de 3,93 pontos.
  • Modelo 3 LG: aumenta o número de parâmetros em 4 vezes e gera um ganho de 7,2 pontos sobre o baseline.

Por fim, o Fine-tuned LG aplica um ajuste fino adicional no Modelo 3 LG, treinando o transformador para prever diretamente o rótulo. Esse modelo ajustado traz uma melhora de 9 pontos em relação ao baseline.

Para contextualizar: um ganho relativo de apenas 1 ~ 1,25 ponto nessas tarefas já é significativo o suficiente para justificar o lançamento de um novo modelo.

Neste post, mostramos como conseguimos transformar o problema de modelar sequências de transações em um problema de linguagem natural padrão. Apesar da simplicidade, essa abordagem gera embeddings informativos que agregam valor a diversas tarefas dentro do Nubank. Também vimos uma prévia das vantagens do fine-tuning.

Este é o segundo post da nossa série sobre o uso de modelos fundamentais aplicados a dados de transações. Esses modelos nos ajudam a entender melhor as finanças dos nossos clientes e a atendê-los no momento certo. No próximo post, vamos discutir nossa abordagem de joint fusion, que nos permite ajustar esses modelos fundamentais para tarefas específicas e incorporar soluções baseadas em atributos tabulares. Também planejamos explorar outros aspectos do nosso setup de modelos fundacionais em posts futuros.

Resumo da série

Se você chegou até aqui, aproveite para acessar os demais posts da série e entender com mais profundidade o contexto e os detalhes técnicos dessa abordagem.

  • No primeiro blog post, avaliamos o potencial dos foundation models aplicados a dados de transações, mostrando como o aprendizado auto-supervisionado pode gerar embeddings gerais que capturam o comportamento do cliente sem depender de dados rotulados.
  • No segundo blog post, aprofundamos na formulação técnica dos nossos foundation models, detalhando a arquitetura baseada em transformadores causais e como esses embeddings podem ser aplicados a diferentes tarefas.
  • No terceiro blog post, exploramos como melhorar o desempenho em tarefas específicas com o supervised fine-tuning e introduzimos o conceito de joint fusion — uma abordagem que combina dados sequenciais e tabulares em um único processo de treinamento fim a fim.

Conheça nossas oportunidades

Referências

[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.

Conheça nossas oportunidades