Fazendo iniciativas de IA funcionarem para Machine Learning Engineering

Escrito por: Felipe Fábio Frigeri e Camila Fragoso

A IA generativa trouxe um conjunto totalmente novo de capacidades para as empresas de tecnologia. No Nubank, onde o código transforma ideias em produtos e em experiências melhores para os clientes, isso abre muitas possibilidades para Machine Learning Engineering (MLE). Preparação de dados, construção de datasets, experimentação, deploy e monitoramento envolvem etapas que a IA poderia ajudar a melhorar, e essas atividades sustentam modelos que embasam decisões de negócio e, no fim das contas, impactam nossos clientes.

Com Large Language Models (LLMs) rápidos e de fácil acesso, a tentação de automatizar quase todas as etapas é compreensível. Mas conseguir construir uma solução rapidamente levanta outra questão: o que vai torná-la útil além do primeiro experimento bem-sucedido?

Sem critérios claros, as aplicações podem começar a se acumular sem que ninguém saiba quem vai usá-las, como elas se encaixam no fluxo de trabalho ou se ainda cumprem seu propósito original. Há algo quase poético nisso: a facilidade e o poder de criar soluções sofisticadas podem se tornar justamente o motivo pelo qual perdemos o foco nos problemas que queríamos resolver.

No time de Cartão de Crédito PJ (Pessoa Jurídica), isso nos levou a ser mais seletivos sobre quais iniciativas de IA seguimos. Antes de nos comprometermos com a implementação, queríamos explicar qual problema um projeto resolveria, como avaliaríamos sua utilidade e se a abordagem poderia ajudar em outros casos de uso. Seguindo o valor do Nubank de buscar altos padrões e eficiência inteligente, organizamos essa discussão em torno de três perguntas práticas.

Neste post, compartilhamos essas perguntas e apresentamos um projeto de descoberta de features do time de Cartão de Crédito PJ. Explicamos a ideia, como respondemos a cada pergunta e como essas respostas ajudaram a definir o escopo e a abordagem do projeto.

Se você não sabe aonde quer chegar, qualquer IA serve

Essas perguntas nos dão um ponto de partida comum para discutir propostas antes de nos comprometermos a construí-las. Elas também nos dão algo para revisitar à medida que os projetos evoluem.

1. Qual problema ou fluxo de trabalho estamos tentando melhorar?

O trabalho de Machine Learning Engineering é uma sequência de tarefas que transita entre processos estruturados e trabalho criativo. Do lado dos processos, independentemente do problema que estamos resolvendo ou do modelo que estamos construindo, algumas etapas sempre fazem parte do trabalho: entender o contexto de negócio, coletar dados, construir datasets, fazer o deploy dos modelos e monitorá-los.

Depois, há o trabalho criativo: explorar uma nova técnica vinda da pesquisa, considerar um algoritmo que outro time vem usando ou desenhar uma sequência de experimentos para melhorar as métricas que nos importam. Esses dois lados muitas vezes se sobrepõem, mas nos dão duas formas úteis de abordar a primeira pergunta.

Qual etapa do processo de modelagem poderíamos tornar mais rápida ou mais fluida?

Isso pode significar simplificar a experimentação, construir datasets, validar premissas de negócio, preparar documentação, avaliar modelos ou decidir quando retreiná-los. Em um ambiente de modelagem em que boa parte do que fazemos já tem sua própria automação, ajuda ser específico sobre de onde viria a melhoria adicional. Qual parte ainda exige um esforço considerável? Onde gastamos tempo repetidamente que poderia ir para outro trabalho?

A IA poderia nos ajudar a explorar territórios ainda inexplorados?

Outro lugar para procurar oportunidades é o trabalho que continuamos adiando: hipóteses, técnicas ou fontes de dados que gostaríamos de investigar, mas para as quais ainda não tivemos capacidade. Isso pode envolver novos algoritmos, abordagens de feature engineering, fontes de dados ou formatos de dados. Também pode significar adaptar modelos existentes a um contexto diferente, por exemplo, investigar onde faria sentido passar de predições em batch para decisões online. Uma ideia que antes exigia mais tempo ou capacidade do que tínhamos pode agora se tornar viável.

Essas duas perguntas podem parecer apontar para direções diferentes, uma para a eficiência de tempo e a outra para a criatividade. Mas ambas vêm da mesma crença: devemos criar mais espaço para o pensamento científico e a experimentação. Facilitar tarefas recorrentes nos dá mais tempo para formular hipóteses, explorar abordagens diferentes e testar ideias. Ampliar o escopo do nosso trabalho nos permite investigar questões que antes não conseguíamos assumir. Ambas sustentam uma parte essencial de Machine Learning Engineering: transformar matemática e ciência em soluções práticas que melhoram as decisões de negócio e a experiência dos nossos clientes.

Com esse propósito claro, um projeto AI-first tem uma condição adicional: a IA precisa ser central para o que torna a abordagem proposta possível.

2. Como podemos medir o sucesso: tempo, escopo ou ambos?

Depois de identificarmos uma oportunidade, a próxima pergunta é o que nos convenceria de que segui-la fez diferença.

O tempo é um ponto de partida natural. Em engenharia, falamos com frequência de time to market, e reduzir o tempo necessário para entregar um modelo é um resultado útil. O mesmo raciocínio vale para etapas individuais, como construir um dataset ou avaliar um experimento. Se essa é a melhoria pretendida, devemos estabelecer uma linha de base, observando quanto tempo um trabalho comparável levava antes da introdução da solução. Mesmo uma medida aproximada nos dá algo concreto para revisitar, desde que o trabalho continue atendendo aos padrões de qualidade que esperamos.

Para iniciativas que ampliam o escopo do nosso trabalho, precisamos explicar como vamos avaliar a utilidade da nova capacidade. Conseguir rodar mais experimentos nos dá uma medida observável, mas também devemos identificar quais perguntas esses experimentos nos ajudam a responder e quais decisões eles podem embasar.

Por exemplo, poderíamos avaliar sistematicamente se duas populações de clientes se beneficiariam de modelos separados, revisitando uma premissa que antes tínhamos pouca capacidade de questionar. Precisaríamos de avaliações comparáveis e de critérios claros para decidir se uma mudança se justifica. Da mesma forma, descobrir mais features candidatas amplia nossas possibilidades, enquanto avaliar a contribuição delas nos diz quais valem a pena seguir.

Quando a oportunidade está mais próxima de uma iniciativa de negócio, devemos conectar a entrega ao resultado que ela pode viabilizar. Para uma nova política de crédito, isso pode significar identificar os clientes antes pouco atendidos que ela poderia alcançar. A relação nem sempre será direta, e aproximações são aceitáveis, mas devemos ser capazes de explicar como a nova capacidade contribui para os objetivos mais amplos do time.

Alguns projetos farão as duas coisas: ampliar o que conseguimos assumir e reduzir o tempo necessário para entregar. Quando isso acontecer, devemos deixar os dois ganhos explícitos. As medidas podem ser aproximadas no início, mas devem nos ajudar a avaliar se a iniciativa está tornando nosso trabalho mais eficaz e criando as oportunidades que justificaram sua construção.

3. Quão reutilizável é a nossa solução?

Um problema bem definido e critérios de sucesso claros dão a uma iniciativa de IA uma base sólida. Uma terceira pergunta que vale fazer desde o início é quanto da solução poderia ser útil em outros contextos, times ou problemas.

No início deste post, falamos sobre como a facilidade de construir com IA pode levar a soluções que são rapidamente esquecidas. Outro risco é construir algo tão preso ao seu contexto original que adaptá-lo dá quase tanto trabalho quanto começar do zero. Em modelagem, chamamos de overfitting quando um modelo aprende as particularidades dos dados de treino tão de perto que tem um desempenho ruim em dados novos. Há uma analogia útil aqui: uma solução de IA pode se tornar tão dependente de um modelo, de um repositório ou do fluxo de trabalho de uma pessoa que sua utilidade mal vai além daquele cenário.

Uma forma prática de abordar isso é olhar para as etapas recorrentes de Machine Learning Engineering. Preparar dados, avaliar experimentos, fazer o deploy de modelos e investigar alertas de monitoramento são atividades familiares para muitos times. A pergunta passa a ser: isso é algo que só eu faço, ou outro ML Engineer pode estar enfrentando o mesmo problema?

Mesmo dentro do nosso próprio time, essa pergunta pode mudar o design. Uma automação construída para avaliar um modelo também pode dar suporte a versões futuras ou a outros modelos se deixarmos suas premissas explícitas e mantivermos os inputs específicos do modelo separados da lógica de avaliação compartilhada. Outros times podem estar fazendo perguntas de negócio diferentes e, ainda assim, se beneficiar de partes do mesmo processo.

A facilidade de adoção também importa aqui. Outra pessoa precisa entender o que a solução faz, o que ela espera e como usá-la no próprio trabalho. Uma documentação clara e uma interface simples ajudam a transformar a possibilidade de reúso em algo que as pessoas realmente consigam adotar.

Um projeto AI-first real: descoberta automatizada de features por meio de grafos de rede

Para mostrar como essas perguntas guiam um projeto desde a ideia inicial até a implementação, apresentamos uma iniciativa de descoberta automatizada de features no time de Cartão de Crédito PJ. Discutimos as três perguntas antes de começar a programar e usamos nossas respostas para definir o escopo, os critérios de sucesso e as oportunidades de reúso.

Encontrando novas features além dos caminhos conhecidos

Nosso processo de descoberta de features vinha se concentrando em reutilizar features já adotadas por outros modelos, mas nunca testadas em PJ. Queríamos ampliar essa busca para incluir experimentos descartados e sinais que nunca tinham sido transformados em features. A modelagem baseada em grafos endereça uma parte específica dessa oportunidade: aprender interações entre features existentes e explorar relações em eventos brutos. Ela complementa, em vez de substituir, o trabalho de encontrar e reutilizar candidatas de outros modelos. Nosso objetivo é dar à IA generativa autonomia para treinar modelos preditivos e propor de forma criativa novas features candidatas com base nos insights desses experimentos.

Para investigar interações entre features existentes, escolhemos o artigo Automatic Feature Generation based on Graph Structure Learning (AFGSL) como referência de modelagem. Na fase 1, features agregadas se tornariam nós de um grafo que trocam informações entre si, produzindo embeddings contextualizados para um modelo de risco downstream. Essas são representações aprendidas, e não features de negócio automaticamente interpretáveis, e as conexões são preditivas, não causais.

A fase 2 exploraria transações e eventos, comparando um baseline de embeddings sem grafo com um grafo temporal que conecta empresas e entidades relacionadas. O modelo de grafo produziria embeddings relacionais; uma camada de leitura interpretável opcional transformaria o contexto aprendido em features nomeadas. Essas abordagens com eventos brutos vão além do artigo AFGSL e buscam revelar sinais ausentes nas colunas de features existentes.

Como avaliamos esses resultados

Esses resultados exigem avaliações diferentes. Para os embeddings de qualquer uma das fases, a pergunta é o que eles acrescentam ao modelo de risco downstream, o que é avaliado por meio de comparações com baselines adequados e de verificações de desempenho out-of-time, calibração e estabilidade. Para features com significado definido, um fluxo de validação automatizado pode identificar padrões de risco que o modelo atual não captura totalmente, oferecendo um indício inicial de sinal adicional, e não uma prova de ganho downstream. A avaliação se aprofundaria à medida que as candidatas avançassem, usando apenas informações disponíveis antes de cada decisão de crédito.

O objetivo de longo prazo é o reúso além de PJ. Quando demonstrarmos valor nos nossos modelos, componentes compartilhados de descoberta e avaliação poderão apoiar outros times de risco, enquanto os inputs específicos de cada modelo continuam configuráveis. Isso mantém a iniciativa ancorada em um problema concreto, em evidências de utilidade e em um caminho para uma adoção mais ampla.

Do que se trata, de fato, este trabalho

Este é um vislumbre do trabalho que fazemos como Machine Learning Engineers no Nubank. No centro do nosso dia a dia está buscar novas ideias, testar hipóteses e transformar pesquisa em modelos e experiências melhores para os clientes. As perguntas deste post nos ajudam a decidir quais oportunidades seguir e o que as tornaria valiosas para o negócio. Se esse parece um ambiente em que você gostaria de trabalhar e contribuir, conheça nossas vagas abertas no Nubank.