Feature Store

Equipes de Machine Learning em organizações maiores frequentemente descobrem um problema de escala: o mesmo conjunto de features — transformações de dados brutas em variáveis para modelos — é recalculado independentemente por múltiplos times para múltiplos projetos. O time de recomendação recalcula "recência da última compra do usuário". O time de fraude recalcula "número de transações nos últimos 30 dias". O time de churn recalcula "frequência de login nas últimas 4 semanas". Cada time implementa a mesma lógica de forma ligeiramente diferente, com custo de engenharia duplicado e risco de inconsistência entre o modelo de treinamento e o modelo em produção.

Feature Store é uma plataforma centralizada para armazenar, gerenciar, descobrir e servir features de ML — tanto para treinamento de modelos quanto para inferência em produção. É o repositório compartilhado que elimina a duplicação de trabalho de feature engineering, garante consistência entre treino e produção, e acelera o desenvolvimento de novos modelos ao tornar features já computadas reutilizáveis.

O conceito surgiu em Uber (Michelangelo), Airbnb (Zipline) e outras empresas de tecnologia de escala como solução para os problemas de escala que emergiram quando dezenas de equipes de ML tentavam operar com infraestrutura de features ad hoc.

Training-serving skew: um dos problemas mais insidiosos em ML — o modelo é treinado com features calculadas de uma forma (frequentemente offline, em batch sobre dados históricos), e no momento de inferência em produção, as features são calculadas de forma diferente (frequentemente online, em tempo real). Diferenças sutis de implementação — arredondamentos diferentes, tratamentos diferentes de nulos, janelas de tempo ligeiramente diferentes — produzem features diferentes entre treino e produção, causando degradação de performance que é difícil de diagnosticar.

Feature Store resolve isso com uma única definição de feature usada tanto para treinamento histórico quanto para inferência em tempo real.

Duplicação de engenharia: cada time computa suas próprias features sem compartilhar. Feature Store transforma features em ativos reutilizáveis — o time de churn pode usar as features de comportamento de compra que o time de recomendação já computou, sem reimplementar.

Descoberta difícil: sem catálogo, ninguém sabe quais features já existem. Feature Store inclui catálogo com busca, documentação e estatísticas de cada feature.

Latência em features online: calcular features complexas em tempo real para cada requisição de inferência tem custo de latência. Feature Store pré-computa e armazena, respondendo com latência de milissegundos em vez de segundos.

A arquitetura de Feature Store distingue dois "lados":

Offline store: armazena valores históricos de features para treinamento de modelos. Usado para criar training datasets — combinar features de múltiplas fontes em diferentes pontos no tempo para um conjunto de entidades (clientes, produtos, usuários). Implementado sobre data warehouse (BigQuery, Snowflake) ou data lake (S3 + Parquet). Suporta point-in-time correctness — para treinar sem data leakage, é necessário buscar o valor da feature que estava disponível no momento do evento histórico, não o valor atual.

Online store: armazena os valores mais recentes de features para inferência em produção com baixa latência. Implementado sobre bancos de dados de baixa latência (Redis, DynamoDB, Cassandra). Atualizado por pipelines que calculam features continuamente de novas observações.

Pipeline de materialização: o processo que computa features dos dados brutos e as popula tanto no offline store quanto no online store. Pode ser batch (computa features periodicamente) ou streaming (computa features em tempo real a partir de streams de dados).

Feature registry: catálogo de todas as features definidas — nome, descrição, tipo, owner, transformação que as computa, quais modelos as usam. A "fonte de verdade" sobre o que existe e como foi calculado.

Feature Store introduz um conceito fundamental para treinamento sem data leakage: point-in-time correctness (ou point-in-time joins).

Quando se cria um training dataset com features históricas, cada observação precisa ser acompanhada dos valores de features que estavam disponíveis naquele momento no tempo — não os valores atuais. Se um cliente fez uma compra em janeiro e você quer treinar um modelo de churn, a feature "número de compras nos últimos 30 dias" deve ser calculada com os dados disponíveis até janeiro, não com dados de hoje que incluem o comportamento posterior.

Feature Stores com suporte a point-in-time joins fazem isso automaticamente — você define o evento (cliente X em data Y) e a feature store retorna os valores corretos para aquele momento no tempo.

Sem esse mecanismo, training datasets são construídos com data leakage — features calculadas com dados do futuro que não estariam disponíveis na previsão real — produzindo modelos otimistas que decepcionam em produção.

Feast (open source): a feature store open source mais adotada. Agnóstica de cloud, suporta múltiplos offline e online stores, tem Python SDK, integra com principais frameworks de ML. Boa opção para times que querem controle total.

Tecton: plataforma comercial focada em ML em produção. Suporta features streaming nativas com baixa latência, monitoramento de qualidade de features, retrocompatibilidade de APIs. Preferida por times com requisitos de features em tempo real.

Hopsworks: plataforma open core com Feature Store, Experiment Tracking e Model Registry integrados. Forte em features streaming.

Vertex AI Feature Store (Google): feature store managed no ecossistema Google Cloud. Integração nativa com BigQuery e Vertex AI Pipelines.

SageMaker Feature Store (AWS): feature store managed no ecossistema AWS. Dual store (online + offline), integração com SageMaker Pipelines.

Databricks Feature Store: integrado ao ecossistema Databricks (Unity Catalog). Vantajoso para times já na plataforma Databricks.

Feature Store adiciona complexidade de infraestrutura. Essa complexidade é justificada quando os problemas que resolve são reais.

Vale o investimento quando:

• Múltiplos modelos de ML em produção reutilizam features similares
• Training-serving skew é problema identificado (modelos degradam inexplicavelmente)
• Time gasta tempo significativo recriando features já existentes em outros projetos
• Há necessidade de features online com baixa latência (<100ms) para inferência em tempo real

Não vale o investimento quando:

• Há apenas um ou dois modelos em produção
• Features são simples o suficiente que training-serving skew não é problema prático
• O time ainda está construindo os fundamentos de dados e ML — Feature Store não é o gargalo

Feature Store é infraestrutura de ML avançada — adequada para organizações com maturidade de MLOps onde múltiplos modelos em produção criam problemas reais de consistência e duplicação. Para a maioria das PMEs, é prematura e desnecessária.

O ponto de atenção prático é o training-serving skew: mesmo sem Feature Store, qualquer time de ML deve ter disciplina de garantir que a lógica de computação de features em treinamento é idêntica à lógica em produção — seja documentando explicitamente, seja compartilhando código de feature computation entre notebooks e APIs de inferência. Esse é o princípio subjacente da Feature Store, implementável de forma simples antes de investir em plataforma dedicada.

Quando a organização chegar ao ponto onde múltiplos times de ML estão criando modelos concorrentemente e o reuso de features se torna necessidade real, Feast (open source) como ponto de entrada permite adotar o conceito sem o custo de licença de plataformas comerciais.