mais lidos
Life at Nu
Conheça a sede do Nubank em Pinheiros, São Paulo/Brasil jan 11
Design
A nova aparência do Nubank: conheça nossa nova logo maio 17
Culture & Values
Como os valores e a cultura da Nu moldam os produtos que criamos ago 7
Carreiras
Reunimos grandes mentes de diversas origens que permitem a discussão e o debate e melhoram a resolução de problemas.
Saiba mais sobre nossas carreiras
Escrito por: Ricardo Ocampo, Carlos Pegueros e Gabriel Ferreira
No Nu, temos uma cultura voltada para os clientes, onde queremos que eles tenham uma experiência agradável em cada passo de sua jornada conosco. Cada aspecto dos nossos produtos é pensado para ser o mais simples e direto possível, com o objetivo de empoderar os clientes e fazer com que nos amem fanaticamente 💜. Como esperado, tratamos o Suporte ao Cliente com muita seriedade. Ter um incrível atendimento ao cliente é um dos pilares do Nu e já nos rendeu vários prêmios.
Quando falamos de Atendimento ao Cliente, há diversos sistemas que precisam funcionar nos bastidores para que possamos fornecer a fantástica experiência que nossos clientes merecem e esperam.
Quer conhecer esses sistemas e descobrir como é desafiador colocá-los em prática em diferentes regiões? Continue lendo esse artigo!
Encaminhamento de chamada
Atualmente, o Nu tem três canais principais pelos quais os clientes podem nos contatar: telefone, e-mail e chat. Toda vez que um cliente entra em contato por um desses canais, temos a tarefa de direcioná-lo para a equipe mais adequada, a fim de esclarecer sua dúvida. Chamamos esse processo de “encaminhamento”.
Um bom encaminhamento é importantíssimo, pois nos permite fornecer um melhor atendimento aos clientes, que são atendidos por especialistas no respectivo assunto. Eles também recebem um atendimento mais rápido e não precisam aguardar enquanto são transferidos (o que pode ser muito incômodo). No geral, quando esse processo funciona bem, temos um serviço mais rápido e clientes mais satisfeitos.
Se quiser saber mais sobre o funcionamento desse sistema no Nu, não deixe de ler este outro artigo.
Conheça nossas oportunidades
Respostas automáticas
Quando os clientes entram em contato conosco por chat e por e-mail, queremos fornecer respostas atenciosas e rápidas para perguntas simples e comuns. Isso nos ajuda a garantir que os clientes não precisem esperar muito para terem suas dúvidas solucionadas. Acionamos esse tipo de mensagem quando nossos sistemas avaliam que uma mensagem personalizada e pré-definida poderia ser suficiente para esclarecer o problema apresentado. Vale ressaltar que nosso foco está sempre na satisfação do cliente. Queremos resolver seus problemas acima de tudo. Por isso, não impomos barreiras quando um cliente deseja falar com um atendente.
Os dois sistemas mencionados (encaminhamento e resposta automática) funcionam com modelos de Aprendizado de Máquina. Os modelos recebem entradas dos clientes (por exemplo, o que eles digitaram no chat ou no corpo do e-mail) e retornam uma classificação por assunto (que identifica o assunto do qual o cliente está falando). Então, a saída é usada pelos nossos sistemas para decidir se devemos enviar uma resposta automática ou encaminhar o cliente para um atendente.
Complexidade global
Atualmente, o Nu opera no Brasil, na Colômbia e no México, totalizando mais de 70 milhões de clientes. Quando falamos de internacionalizar esses sistemas para países diferentes, os sistemas de tomada de decisão e microsserviços costumam ser mais simples de adaptar e reutilizar. Porém, os Modelos de Aprendizado de Máquina podem se tornar um obstáculo e um desafio, pois o modelo criado em um país não é facilmente reutilizado em outro.
As principais dificuldades para a reutilização dos modelos são:
No resto deste artigo, explicaremos o problema de reutilização de Modelos de Aprendizado de Máquina com mais detalhes, como isso afeta a escalabilidade e como estamos resolvendo esse problema no Nu.
Encarando Problemas de Escalabilidade
No começo, a equipe focou em iterações rápidas e acabou com um problema técnico pelo caminho. Assim, havia um modelo implementado com um código próprio para cada uma de nossas tarefas downstream (encaminhamento de chamada e resposta automática) e canais (e-mail, chat, telefone).
Ter diferentes implementações do mesmo problema causou problemas de escalabilidade, que impactaram a manutenção do código e geraram redundância na força de trabalho. Como tínhamos modelos diferentes para cada canal e tarefa downstream, tivemos que designar mais recursos humanos para cada modelo à medida que nos expandíamos para o México e para a Colômbia.
Mas nem tudo estava perdido, porque o Nubank reconhece como MLOps contribuem para a empresa. Quando começamos a lidar com os problemas de escalabilidade, uma estrutura chamada Sheep já estava em atividade. A estrutura cuida do ciclo de vida do desenvolvimento de um modelo, é independente do modelo e fornece as ferramentas necessárias para treinar e mobilizar modelos para os nossos ambientes.
A estrutura nos permitiu executar diversos experimentos e adotar a natureza de iteração rápida da Ciência de Dados.
Quando começamos a operar no México, a equipe de experiência do cliente já tinha cerca de 6 modelos para lidar com encaminhamento de chamada e respostas automáticas para cada um dos três canais. Além disso, seguimos o mesmo padrão e adicionamos mais 2 no México (encaminhamento de chat e resposta automática). Após implementarmos esses modelos, começamos a ter alguns problemas gerados por duplicação de código. Por exemplo, se encontrássemos uma falha no modelo de encaminhamento de chamada, tínhamos que consertá-la no modelo de resposta automática também. Além disso, em alguns casos a falha não era consertada nos dois códigos-fontes, e eles começavam a divergir. Isso dificultava bastante a manutenção.
Para complicar, a propagação do código era preocupante. O processamento, treinamento, interferência e até mesmo os testes de unidade eram quase idênticos. As únicas diferenças eram o alvo e o processamento. O processo de depuração era muito demorado, pois mesmo com os modelos resolvendo problemas similares, cada membro que implementava os modelos adicionava suas próprias características. Convenções de nomes, definição de função, escopo e implementação variavam entre os modelos. Isso dificultava até mesmo a execução dos Pull Requests.
Ainda nos dias de hoje, parece que supor que os modelos são completamente independentes entre si, como era na concepção original de Sheep, não é o bastante. Por outro lado, é proveitoso pensar em uma camada intermediária de abstração que transforma não apenas o código e a estrutura dos modelos, mas também de todos os domínios como caixas-pretas.
Como resolvemos isso?
O problema poderia ser generalizado como uma classificação de texto aplicada a diferentes domínios ou tarefas downstream. Por exemplo, (1) para encaminhamento de chamada, a entrada é a descrição do problema feita pelo cliente (texto), e a saída é a equipe especializada que pode ajudá-lo. (2) para resposta automática, a entrada é a mesma, e a saída é a resposta que tenta solucionar a dúvida.
Com todas essas considerações, decidimos enfrentar o problema focando nos 4 princípios principais de desenvolvimento de modelos de Aprendizado de Máquina no Nubank, mais 2 novas adições:
Portanto, decidimos construir uma biblioteca para centralizar todos os códigos comuns entre esses modelos, seguindo uma abordagem voltada para a configuração, composta de etapas configuráveis e pipelines.
Por que voltada para configuração?
Porque isso nos permite expor modelos por meio de um framework de configuração declarativa que tem duas vantagens: os arquivos de configuração não precisam ser testados (exceto pela conferência da validade das configurações) e teremos menos espaço para falhas se expusermos menos códigos aos usuários.
Por que etapas e pipelines?
Porque os modelos de aprendizado de máquina podem ser bem compreendidos como uma série de operações (conhecidas como etapas) vinculadas a pipelines que formam um modelo. Essa abordagem tem duas limitações:
Juntamente com a necessidade de fazer a biblioteca funcionar em harmonia com nossa infraestrutura atual, a API declarativa foi construída sobre o pydantic (um framework que fornece validação de dados e gerenciamento de configurações por meio de anotações do tipo Python) para otimizar três benefícios principais que o tornam um intermediário perfeito entre nossa filosofia e o Sheep:
Com essas 3 ideias em mente, é possível imaginar a biblioteca como um framework de abstração para envolver pipelines de Aprendizado (a abstração para modelos que usamos no Nubank) em configurações JSON imutáveis e serializáveis que fornecem integridade, no sentido de serem suficientes para representar um modelo.
Na prática, esses pipelines seriam as caixas-pretas que contêm o conhecimento de domínio dos modelos de Excelência do Cliente, e podem ser entendidos como fábricas serializáveis de pipelines de Aprendizado. Como essas fábricas são imutáveis, a reprodutibilidade é garantida. Assim, as duas fábricas sempre criarão o mesmo modelo, e as configurações serão validadas logo após a criação para garantir que possam existir previsões de falhas.
Quando uma fábrica é serializada, distribuir modelos a serem treinados e mobilizados em tarefas específicas é apenas uma questão de distribuir JSONs e conectá-los em nossa infraestrutura. Eles são passados ao Sheep com as funções analisadoras adequadas construídas na biblioteca que sabem como transformá-los em modelos de Excelência do Cliente.
A centralização do código facilitou a distribuição de modelos por diferentes casos de uso. Isso melhora a manutenção e mantém os modelos limpos ao mesmo tempo. Além disso, possibilita análises de código mais rápidas, validações mais fáceis e menos conflitos de mesclagem, ao custo de perder um pouco de flexibilidade. Encontrar o ponto ideal sobre o quanto vale a pena perder tem sido um processo de vários meses de tentativas e erros, com diferentes níveis de abstração. Contudo, aprendemos bastante com o domínio de Excelência do Cliente e, ainda que exista espaço para melhorias, todos os benefícios começaram a se destacar desde a etapa de protótipo.
A História de Sucesso
Quando a primeira versão da biblioteca foi lançada, ela começou a ser usada em 4 modelos diferentes, no México que foram lançados para produção. Pouco tempo depois, o Nubank decidiu integrar modelos semelhantes na Colômbia. Mesmo com todas as incertezas e poucos funcionários que vêm com a abertura de um novo negócio em territórios desconhecidos, conseguimos lançar rapidamente 2 modelos diferentes com um custo de manutenção tão baixo que poderiam ser perfeitamente gerenciados pela equipe existente. No momento, estamos trabalhando com a equipe de operações do Brasil para testar a solução lá.
Hoje, isso totaliza 6 modelos diferentes, que cuidam de tarefas como Encaminhamento e Resposta Automática (para chat e e-mail) executadas no México e na Colômbia, usando a biblioteca desenvolvida. O fato mais surpreendente é que todos os modelos usam exatamente o mesmo código (graças à Biblioteca). A única diferença é a configuração específica e os dados subjacentes usados, que variam conforme a tarefa downstream, o canal e o país.
Isso reduziu a duplicação de código em 85% e, como nossos modelos são na maioria compostos por arquivos de configuração declarativa, espalhar um novo recurso (ou uma correção de erro) para todos os modelos é apenas uma questão de atualizar a versão da biblioteca.
Essa capacidade de resolver um problema técnico rapidamente ou de propagar grandes alterações sem um código enorme diminui a quantidade de horas de engenharia dedicadas à manutenção, reduzindo os custos consequentemente. Além disso, sobra tempo para a equipe aprimorar nossos dados e testar novas ideias que estão surgindo no acelerado campo de Processamento de Linguagem Natural, que tem sido primordial para entregar a marca registrada do Nubank desde a sua criação: um excelente serviço ao cliente.
Conheça nossas oportunidades