Apresentando o Precog, IA em tempo real de eventos do Nubank

Escrito por Cristiano Breuel, Gabriel Bakiewicz, George Salvino, Mariana Sant’Anna, Luana Campos, Cinthia Tanaka, Pedro Chaves, Allan Garcia, Kevvin Sahdo, Tan Mukhopadhyay

---

Imagine um mundo onde sua ligação para o banco seja atendida instantaneamente por um agente especializado que resolve seu problema rapidamente. Chega de ter que navegar por menus entediantes, ouvir a gravações intermináveis ou ser transferido de um agente para o outro. Para muitos clientes do Nubank, este não é um sonho distante, mas sim uma realidade, graças à nossa IA em tempo real de eventos, o Precog. 

Neste artigo, damos uma olhada na jornada do Nubank na última década, de uma empresa de produto único a uma potência financeira multiproduto operando em três países, que motivou o desenvolvimento do Precog, e detalhamos sua arquitetura de sistema, alguns dos desafios técnicos que enfrentamos e os resultados que alcançamos.

Histórico

Desde que o Nubank começou, há dez anos, utilizamos aprendizado de máquina para tomar decisões, começando pela concessão de crédito. Cientistas de dados altamente qualificados construíram alguns dos modelos de melhor desempenho para nos preparar para um sucesso sem precedentes.

Porém, naquela época, éramos uma empresa de produto único, em um único país, atendendo a usuários bastante homogêneos. Muita coisa mudou desde então, tanto dentro do Nubank quanto no mundo todo. O Nubank agora opera em três países, oferecendo mais de dez produtos financeiros diferentes (por exemplo, contas correntes/poupança, investimentos, seguros) para uma grande parcela da população. Esse ritmo e escala de mudança e complexidade tornaram quase impossível para algumas equipes de ciência de dados acompanharem, especialmente equipes horizontais, como Excelência do Cliente, que cuida do suporte.

Enquanto isso, no mundo exterior, a IA deu grandes saltos graças a novas arquiteturas de modelos e ao surgimento do paradigma do modelo básico. No final de 2021, uma visão para fazer IA no Nubank nesta nova realidade começou a tomar forma. Decidimos começar pelas nossas plataformas de apoio ao cliente, cujas responsabilidades incluem prever as necessidades de apoio do cliente em tempo real.

Conheça nossas oportunidades

Motivação

O Nubank está organizado em diversas unidades de negócios, que por sua vez oferecem diversos produtos e funcionalidades, implementados como microsserviços independentes. O resultado é um ambiente descentralizado que permite que as equipes se movam de forma rápida e independente. Isso também significa que pode ser um desafio ter uma visão completa do cliente em todos esses produtos. Tradicionalmente, confiávamos no conhecimento de negócios para pensar em recursos que poderiam ser úteis para modelos específicos e, em seguida, procurávamos dados em toda a organização para construir esses recursos. À medida que nosso portfólio de produtos e nossa complexidade cresciam, ficou mais difícil acompanhar e nossos modelos começaram a ficar para trás na evolução dos produtos.

Para resolver esse problema de forma fundamental, precisávamos automatizar e ampliar o processamento de dados em tempo real e incluir a engenharia de recursos para suportar muitas linhas de produtos e casos de uso. Foi aí que entrou o Precog.

Representação

O principal insight por trás do Precog é que os eventos do cliente (por exemplo, fluxo de cliques do aplicativo, transações) podem ser codificados como uma sequência de símbolos. Isso significa que podemos usar técnicas que foram originalmente desenvolvidas para processamento de linguagem natural, como incorporações e modelos de sequência, para compreender e prever as necessidades dos clientes.

A fonte de dados mais rica que faltava em nossos modelos era o fluxo de cliques do aplicativo, então foi por aí que decidimos começar. Esses dados são coletados por um sistema interno que recebe eventos do aplicativo mobile do Nubank e de outras fontes, por meio de uma API flexível.

O principal desafio desses dados é a falta de estrutura aplicada entre as diferentes equipes de produto. Cada registro é identificado por um nome de métrica e um JSON com pares de atributo/valor, todos determinados pelos engenheiros que implementam cada fluxo. Para evitar gargalos de desenvolvimento, não há governança centralizada e esses valores podem mudar rapidamente a cada atualização do app.

Para lidar com esses dados semiestruturados, o Precog transforma registros em sequências de identificadores baseados em texto, ao mesmo tempo em que descarta símbolos pouco frequentes, como ids exclusivos.

Existem muitas maneiras possíveis de aprender com essas representações de strings, com diferentes níveis de complexidade. Queríamos algo que não estivesse vinculado a nenhum domínio específico, para que pudesse ser facilmente reutilizado em diferentes modelos. Seguindo a nossa abordagem habitual de começar de forma simples para avaliar rapidamente o valor de uma solução, decidimos representar os clientes com um conjunto de palavras com os símbolos dos seus eventos.

O Precog aprende incorporações dos eventos de maneira autossupervisionada, usando aprendizagem contrastiva. Um conjunto de eventos de um cliente é colocado como âncora, com um único evento removido aleatoriamente dele para servir como uma amostra positiva, enquanto outros eventos que não ocorrem para esse cliente são amostrados aleatoriamente como negativos. A aprendizagem contrastiva tenta minimizar a distância entre a âncora e as amostras positivas e ao mesmo tempo maximizar a distância até as amostras negativas. Ao final, é produzido um vetor para cada símbolo do vocabulário e os agregamos para obter a representação do cliente. 

Arquitetura do sistema

O principal componente do Precog é um pipeline para treinar incorporações de eventos/clientes e, em seguida, incorporar as incorporações aprendidas em modelos de estágios posteriores no momento de treinamento e de atendimento. Para treinar as incorporações, usamos a biblioteca Starspace, que fornece uma implementação flexível e eficiente para aprender qualquer incorporação de entidade.

Para treinar um modelo de estágios posteriores, pegamos registros que são codificados por identificadores anônimos de clientes e registros de data/hora, juntamente com os rótulos que queremos prever e quaisquer outros recursos, e os juntamos aos conjuntos relevantes de eventos. Por exemplo, para prever o motivo do contato para uma chamada de suporte ao cliente, pegamos os eventos desse cliente na janela de eventos anterior à chamada e o motivo do contato conforme classificado pelos agentes.

Em tempo de execução, um microsserviço consumidor de evento (implementado em nossa linguagem canônica de serviço de negócios, Clojure) transforma os dados brutos do evento em um formato de string e os guarda em um armazenamento temporário de baixa latência (Redis). No momento da veiculação, o microsserviço do modelo de estágios posteriores (construído em Python) recupera eventos relevantes do cache, calcula incorporações e as usa como recursos para um modelo de classificação.

Desafios técnicos

Identificando a janela ideal para os eventos: Nossa abordagem de modelagem atual não leva em consideração a ordem ou a idade dos eventos, por isso notamos que o aumento da janela de eventos reduziu o desempenho do modelo, porque os eventos mais relevantes tendem a ser recentes. Porém, reduzir muito a janela diminuiria nossa cobertura, já que muitos clientes podem não ter interagido com o aplicativo recentemente. Depois de executar vários testes, decidimos por uma janela de 3 horas por enquanto, mas pretendemos explorar melhores maneiras de selecionar eventos que equilibrem cobertura e precisão, incluindo formas de incorporar informações sobre a idade do evento.

Volume e custo de dados: O volume desses dados é bastante grande, por isso previmos que os custos de armazenamento seriam um problema. Planejamos manter os dados preparados em armazenamento de baixa latência apenas durante o tempo necessário para inferência (os dados brutos históricos já são mantidos em armazenamento de alta latência). Para facilitar a implementação, nossa primeira versão usou um banco de dados de valores-chave de baixa latência com suporte integrado para limpeza de tempo de vida (AWS DynamoDB). Porém, o enorme volume de eventos a serem armazenados e a quantidade de escritas e leituras tornavam o custo proibitivo. Em seguida, mudamos para um banco de dados em memória (Redis), o que tornou a implementação um pouco mais complexa, mas reduziu o custo para uma pequena fração da versão original, tornando a solução econômica.

Necessidade de retreinamento frequente: Como as definições de eventos mudam frequentemente pelos motivos mencionados acima, também precisamos treinar novamente as incorporações com frequência. No entanto, retreinar as incorporações significa que também precisamos retreinar os modelos de estágios posteriores que dependem delas. Nossa solução para esse problema é fornecer um pipeline de retreinamento padronizado que possa ser facilmente adotado por modelos de estágios posteriores para retreinamento periódico.

Resultados

Nossa primeira aplicação do Precog é no roteamento de chamadas telefônicas, por meio de um modelo de estágios posteriores que usa incorporações do cliente e outros recursos para classificar o produto com maior probabilidade de que o cliente precise de ajuda. Se o modelo for suficientemente confiante, o sistema encaminha os clientes diretamente para especialistas. Caso contrário, conversarão com agentes generalistas, que poderão transferi-los para especialistas caso não consigam resolver o problema sozinhos.

Ao adicionar incorporações do Precog, conseguimos aumentar em mais de 50% o volume de chamadas que são roteadas corretamente para agentes especializados sem necessidade de intervenção do cliente, em comparação com o modelo anterior. Isso resultou em reduções significativas no tempo para resolver problemas e aumento na satisfação do cliente. Houve melhorias em todos os produtos que testamos, mas notamos que os maiores ganhos ocorreram em produtos mais novos, para os quais ainda não havíamos implementado recursos tradicionais. Isso confirma nossa hipótese de que podemos substituir a trabalhosa engenharia de recursos por uma abordagem mais escalável.

Outro benefício do Precog é a redução da latência. Para recursos tradicionais, tivemos que chamar vários serviços REST e processar os resultados, o que resultou em alta latência no pior caso. Com o Precog, o tempo para buscar e processar dados de eventos é muito menor e mais previsível, resultando em menor latência geral de serviço. A atualização dos eventos (tempo entre a ocorrência do evento e a disponibilidade para atendimento) foi uma preocupação inicialmente, mas na prática os vemos disponíveis quase instantaneamente, tornando essa abordagem muito competitiva com a recuperação REST síncrona.

Além dessas melhorias no tempo de execução, também percebemos que há um enorme benefício para o ciclo de desenvolvimento: adicionar recursos Precog a um modelo normalmente leva algumas semanas, em comparação com meses para abordagens tradicionais, o que nos permite iterar e entregar valor aos clientes com mais rapidez.

No momento, estamos trabalhando em outros aplicativos para o Precog, como recomendações de artigos de perguntas frequentes e sugestões de tópicos na interface de suporte do Chat. Além disso, prevemos muitos outros usos para ele no futuro.

Trabalho futuro

Este é apenas o começo para o Precog e a IA de representação do cliente no Nubank. Existem vários caminhos promissores para desenvolver ainda mais esta tecnologia e aplicá-la aos nossos produtos, como mais fontes de dados e técnicas de modelagem aprimoradas. Também pretendemos investir em Modelos Básicos adicionais para construir a próxima geração da stack de IA para o Nubank.