Escrito por: Felipe Almeida, com contribuições de Luiz Felix

Esta é a primeira parte de uma série de três partes sobre feature stores para ML em tempo real no Nubank. Na parte 2, exploraremos as lições que aprendemos ao usar feature stores em produção. Na parte 3, percorreremos arquiteturas ponta a ponta usadas em cenários do mundo real.

Introdução a feature stores

Uma das poucas constantes no desenvolvimento de software é que os sistemas tendem a acumular entropia e ficar mais complexos com o tempo. É possível, no entanto, desacelerar essa deterioração extraindo funcionalidades comuns para bibliotecas e plataformas. Isso simplifica os sistemas e mantém a complexidade em níveis gerenciáveis.

Conforme uma organização orientada por dados cresce e amadurece, o código de ML também tende a se tornar cada vez mais complexo. Por exemplo, quando os modelos começam a ser usados em vários times, é comum ver a lógica de features duplicada em diversos lugares. Isso torna muito mais difícil gerenciar e manter esses modelos e impede o reúso de código na organização.

“Todos os problemas em ciência da computação podem ser resolvidos [adicionando] outro nível de indireção” — David Wheeler

Uma estratégia comum para lidar com esse problema é centralizar toda a lógica de features em uma biblioteca, de modo que os times possam reusar as features uns dos outros em vez de ter que reescrevê-las e duplicá-las sempre que treinam um novo modelo.

Quando os modelos são usados para inferência em tempo real, existe ainda mais uma camada de código envolvida, a saber, o código usado para recuperar features no tempo de inferência. Esse código de “tempo de inferência” normalmente fica em microsserviços no ambiente de produção.

Feature stores são plataformas que centralizam a lógica de features para todos os modelos de uma organização. Em cenários de inferência em tempo real, a feature store também fornece endpoints centralizados para a recuperação de features.

Uma feature store é uma plataforma que centraliza o gerenciamento de features (no tempo de treino e no tempo de inferência).

Vamos olhar dois exemplos de como fica o código de ML com e sem uma feature store, tanto no tempo de treino quanto no tempo de inferência.

Tempo de treino

No tempo de treino, usar uma feature store significa que cada time importará as definições de features de uma biblioteca padrão, em vez de definir as suas próprias, específicas do time. Na Figura 1 abaixo, mostramos exemplos de como o código de treino fica com e sem uma feature store:

Figura 1 — From feature_store import: no tempo de treino, os times de ciência de dados geralmente partem de um dataset base contendo IDs de entidades e timestamps, e iterativamente “aplicam” features sobre ele. Com uma feature store, essa “lógica de features” é extraída para uma biblioteca compartilhada e reutilizável.

Tempo de inferência

No tempo de inferência, as features precisam ser recuperadas por algum tipo de orquestrador. Em arquiteturas baseadas em microsserviços, esse orquestrador será um serviço (chamado “Serviço upstream” na Figura 2 abaixo) que vai montar o payload, enviá-lo para o modelo de ML em tempo real e tratar as predições do modelo:

Figura 2: uma feature store abstrai toda a complexidade envolvida em recuperar, calcular e transformar features usadas em tempo real.

Atendimento de features por “chamada direta” vs. baseado em streaming

Para fornecer uma feature a um serviço upstream, a feature store precisa primeiro recuperar essa informação de alguma forma. As duas estratégias mais comuns são:

  • (1) Chamada direta: nesse modelo, a feature store faz chamadas HTTP diretamente aos microsserviços que possuem os dados necessários sempre que uma feature é solicitada.
  • (2) Streaming: aqui, os microsserviços publicam eventos em uma camada de streaming, como o Kafka, à medida que os eventos acontecem. A feature store então consome esses eventos e recupera as features da camada de streaming quando necessário. Em alguns casos, essas features também são armazenadas em bancos de dados locais para acesso mais rápido.

Essas duas estratégias são ilustradas abaixo:

Figura 3: as features podem ser recuperadas diretamente dos serviços de origem ou por meio de plataformas de streaming como o Kafka. As features baseadas em streaming são frequentemente chamadas de near-real-time porque podem ter pequenos atrasos de atualização, normalmente da ordem de milissegundos ou segundos.

Uma única feature store pode suportar ambas as estratégias simultaneamente. É muito comum que algumas features sejam recuperadas diretamente de fontes primárias (caso (1)), enquanto outras são recuperadas de plataformas de streaming.

Cada estratégia traz vantagens, desvantagens e modos de falha distintos. Vamos discutir isso na próxima parte desta série.

Nas próximas seções, listaremos as vantagens e desvantagens de usar feature stores, com base na nossa experiência no Nubank.

Conheça nossas oportunidades

Prós

Pró: Feature stores mitigam o viés entre treino e inferência (training-serving skew)

Training-serving skew refere-se às diferenças entre como as features são definidas no tempo de treino e no tempo de inferência.

Essas inconsistências quebram a suposição de que os dados em tempo de inferência seguirão uma distribuição semelhante à usada durante o treino. Quando essa suposição falha, as métricas de desempenho estimadas durante o treino deixam de refletir o comportamento real do modelo.

O training-serving skew acontece porque a definição de features no tempo de treino é feita no ambiente analítico, por cientistas de dados, enquanto no tempo de inferência muitas vezes é feita no ambiente de produção, por engenheiros. Como é feita por pessoas diferentes, em ambientes diferentes (frequentemente usando stacks diferentes), diferenças nas implementações são muito comuns e difíceis de detectar. Veja um resumo na Figura 4 abaixo:

Figura 4 — Diferenças entre tempo de treino e tempo de inferência: o trabalho do modelo é feito não só por pessoas diferentes, mas também em ambientes diferentes e frequentemente usando stacks diferentes. Essas diferenças são a principal causa do training-serving skew.

Se a feature store conseguir lidar tanto com os dados de tempo de treino quanto com a recuperação em tempo de inferência, ela pode eliminar — ou pelo menos mitigar — o training-serving skew, porque as duas definições passam a viver no “mesmo lugar”, por assim dizer.

As feature stores reduzem o risco de training-serving skew porque a lógica de features — no tempo de treino e no tempo de inferência — é feita “no mesmo lugar”.

O monitoramento do training-serving skew também fica mais fácil e eficiente. Como todos os dados necessários estão centralizados em um único lugar, o monitoramento pode ser feito pelo próprio time da feature store.

Pró: Feature stores permitem a descoberta e o reúso de features entre times

As feature stores normalmente possuem um registro ou catálogo onde as features individuais dos modelos são definidas, descritas e versionadas.

Isso pode ser tão simples quanto uma pasta dentro de um repositório comum, uma biblioteca, ou um site interno completo onde os usuários inserem informações (veja a Figura 5 para inspiração).

Figura 5 — Exemplo de registro de features: UI web de exemplo para um registro de features imaginário. Os usuários podem buscar features existentes e encontrar informações sobre elas. Aqui vemos que a feature reported_income está na versão 3, está sendo usada por 4 modelos e tem como dona a BU de Onboarding.

Esses registros são o lugar perfeito para que potenciais usuários (ou seja, praticantes de ML) naveguem pelas features existentes e descubram aquelas que não sabiam que existiam. Os usuários podem facilmente escolher features existentes para adicionar a um modelo, reduzindo o Time-to-Market (TTM).

Dois cenários nos quais registros de features são úteis:

  • Criar um modelo baseline (v0) de baixo custo usando features existentes: você pode simplesmente procurar algumas features comuns e rapidamente subir um modelo baseline simples para testar uma hipótese.
  • Aumentar um modelo existente: adicionar novas features a modelos existentes é uma das tarefas mais comuns nas quais cientistas de dados se envolvem. Os registros de features permitem ver rapidamente quais features já estão disponíveis e o esforço envolvido em adicioná-las ao seu modelo.

Pró: Feature stores aumentam o incentivo para a criação de features

As empresas costumam basear a progressão de carreira dos funcionários em critérios objetivos, para alinhar incentivos e promover uma dinâmica de trabalho mais justa. Exemplos de métricas usadas incluem impacto financeiro gerado por um projeto, número de pessoas usando uma determinada ferramenta ou plataforma, NPS ou feedback de usuários, etc.

Criar features é uma tarefa importante, que costuma ter impacto financeiro na organização. Por isso, os praticantes de ML são incentivados a fazê-lo, já que isso leva a um maior impacto financeiro que, por sua vez, leva a uma melhor progressão de carreira. Esse impacto fica ainda maior se outros times conseguirem usar as features criadas por indivíduos; portanto, o incentivo para os praticantes criarem features também aumenta. Veja um resumo na Figura 6 abaixo:

Figura 6 — Os incentivos importam: criar features em uma feature store normalmente envolve trabalho extra (é preciso criar metadados, conseguir revisões de outros times, etc.), mas isso aumenta de forma desproporcional o impacto dessas features, o que, por sua vez, ajuda a progressão de carreira dos praticantes. Ganha-ganha.

Incentivos são importantes: as feature stores aumentam o impacto das features que, por sua vez, aumenta o impacto organizacional dos praticantes de ML e os incentivos para criá-las.

Pró: Feature stores centralizam o gerenciamento de features em uma única plataforma, aumentando a eficiência

Recuperar features de modelo em tempo real a partir de uma feature store (em vez de a partir dos serviços de origem de cada feature individualmente) significa que muitas responsabilidades agora podem ser “abstraídas” na plataforma.

Observabilidade é um bom exemplo. Uma feature store pode facilmente instrumentar a recuperação de features com logs e métricas sempre que elas forem solicitadas por um serviço upstream. Ela também pode gerar dashboards de monitoramento genéricos para que as partes interessadas tenham visibilidade sobre as distribuições de features e monitorem problemas. Veja uma representação visual abaixo.

Figura 7 — Logs e métricas centralizados permitem que os serviços clientes obtenham observabilidade “de graça”, sem precisar implementar funcionalidades repetitivas para cada integração.

Muitas outras responsabilidades também podem ser extraídas para uma plataforma de feature store, para que os times-clientes não precisem lidar com elas:

  • Documentação: toda a documentação de features pode ser centralizada em um registro de features (como mostrado na Figura 5), que é parte da feature store.
  • Manutenção: atualizar o código das features para corrigir bugs, melhorar a eficiência e gerenciar o versionamento. Tudo isso fica muito mais eficiente quando feito por um time dedicado e especializado.
  • Capacidades de depuração/troubleshooting: a plataforma pode criar ferramentas centralizadas de visualização e processamento de logs (ex.: visualização de tracing distribuído, queries SQL em logs, e mais).
  • Cache: é muito comum que valores de features sejam cacheados para reduzir custos e tempos de processamento. Prover essa camada de cache nos pontos de entrada da plataforma pode ser feito facilmente pelo time da feature store.
  • Governança/Auditoria: organizações que operam em ambientes altamente regulados (ex.: bancos, saúde, defesa) frequentemente precisam manter trilhas de auditoria precisas de como os modelos são usados. Alguns exemplos:
  • Quais foram os valores exatos das features e o score de saída para cada instância individual pontuada? (ou pelo menos uma amostra disso)
  • Qual versão exata do modelo estava sendo usada em um momento específico?

Contras

Contra: Feature stores podem se tornar gargalos para times que precisam iterar rápido

Do ponto de vista dos times-clientes, recuperar uma feature de uma plataforma de feature store pode ser mais difícil do que fazê-lo “da maneira usual” (ou seja, consultando diretamente a fonte primária).

Como resultado, times com ciclos de experimentação muito curtos podem ver a plataforma como uma fonte de fricção. Isso geralmente acontece em cenários como:

Provas de conceito (PoCs) rápidas

Um time quer criar uma feature simples para testar uma nova fonte de dados, mas ter que adicioná-la primeiro à FS gera overhead demais e descaracteriza o propósito de uma PoC simples.

Capacidades ainda não disponíveis na feature store

Um time precisa de uma funcionalidade customizada (como pré-processamento ou pós-processamento customizado) que ainda não existe na plataforma. No entanto, o time da FS tem o próprio roadmap e objetivos e não consegue priorizar habilitar essa funcionalidade agora.

É claro que o time da FS pode e deve tornar a plataforma o mais simples possível de usar. A facilidade de uso reduz o overhead e, portanto, reduz esses problemas. Aprendemos várias lições sobre esse tema, como veremos na parte 2 desta série.

Contra: Arquiteturas ingênuas podem introduzir latência adicional

A implementação mais “ingênua” de uma feature store em tempo real é como uma “camada intermediária” entre os modelos e os serviços upstream que possuem as features.

Entretanto, essa nova camada vai adicionar algum overhead de latência quando comparada ao acesso direto a essas fontes (simplesmente porque chamadas extras de rede ou de banco de dados estão sendo adicionadas ao fluxo).

Pode ser um problema em cenários em que milissegundos fazem diferença (ex.: High-frequency Trading), mas esses casos são raros. Ainda assim, existem várias estratégias para reduzir esse impacto:

  • Prefetching: refere-se a buscar e cachear as próximas features (antes mesmo que elas sejam solicitadas). Em outras palavras, se sabemos que a feature C é sempre solicitada depois das features A e B, podemos calcular C com antecedência, de modo que ela já esteja disponível quando for solicitada.
  • Cache local: dados usados para construir features críticas podem ser armazenados localmente na plataforma da FS para recuperação rápida (em vez de serem buscados pela rede). Por exemplo, se features relacionadas a transferências forem muito importantes para você, todas as transferências poderiam ser armazenadas em um key-value store local como o Redis, de modo que a recuperação seja instantânea quando/se as features forem solicitadas.
  • Busca em paralelo: features independentes podem ser recuperadas em paralelo através de multithreading.

Vale notar, no entanto, que nem todas as implementações de feature store seguem essa abordagem ingênua. Na verdade, muitas escolhas de arquitetura podem, de fato, reduzir o tempo de busca de features em vez de aumentá-lo.

Contra: Feature stores podem dificultar a observabilidade e a depuração para os times-clientes

Introduzir uma feature store para recuperar features em tempo real geralmente significa que observabilidade (visualização de logs e métricas) e depuração (rastrear a causa raiz de um problema) vão mudar. Isso acontece porque a lógica de recuperação agora está abstraída, e os logs podem não se parecer mais com aquilo a que os times-clientes estão acostumados.

Isso muitas vezes cria uma resistência inicial à adoção. É importante garantir que os times-clientes não percam a capacidade de observar e depurar a recuperação de features por conta própria, porque ninguém gosta de perder a autonomia ao resolver problemas em produção.

Na prática, essa resistência pode ser significativamente reduzida quando a feature store segue as mesmas convenções usadas pelos outros serviços da organização. Práticas importantes incluem:

Seguir as convenções de logging existentes

Logs e métricas emitidos pela plataforma da feature store devem ser o mais parecidos possível com os usados por outros serviços (não-ML): usando as mesmas tecnologias, os mesmos padrões, a mesma estrutura, seguindo os mesmos padrões de tracing distribuído onde aplicável.

Garantir que as necessidades básicas dos usuários sejam atendidas

Os casos de uso “mínimos” devem permanecer simples e fáceis. Todos os times-clientes devem ser capazes de:

  • Inspecionar as features de entrada brutas para instâncias individuais pontuadas por um modelo.
  • Ver métricas de latência (médias e percentis) para features individuais ao longo do tempo.
  • Ver mensagens de exceção e stack traces sempre que ocorrerem erros durante a recuperação de features.

Incluir todas as dimensões necessárias em logs e métricas

Logs e métricas devem incluir o nome do modelo chamador e quaisquer outras dimensões necessárias para distinguir diferentes fluxos de chamada (ex.: chamadas em modo shadow vs. não-shadow).

Esse “contra” é apenas uma questão durante a adoção inicial de uma feature store. No longo prazo, uma feature store pode prover capacidades de observabilidade e depuração até melhores do que serviços comuns.

Conclusão

Feature stores carregam um custo real de implementação e adoção, especialmente para organizações que ainda estão começando a estruturar seus sistemas de ML em tempo real. Ainda assim, à medida que o número de modelos, times e casos de uso cresce, os benefícios de padronização, reúso, governança e eficiência operacional tendem a superar esse investimento inicial.

Ao centralizar a lógica de features em uma única plataforma, as organizações conseguem reduzir problemas como o training-serving skew, simplificar a manutenção de pipelines de ML, acelerar a experimentação e criar sistemas de inferência em tempo real mais escaláveis. Além disso, efeitos de segunda ordem como descoberta de features entre times, observabilidade centralizada e reúso de componentes são amplificados conforme a adoção cresce.

Na parte 2 desta série, exploraremos as principais lições aprendidas ao usar feature stores em produção no Nubank. Fique ligado!

Conheça nossas oportunidades