O que é uma feature store e quando você precisa de uma

Gabriel Guarisa
Pier. Stories
Published in
7 min readFeb 13, 2023
Fonte: https://unsplash.com/photos/R84Oy89aNKs

O presente artigo apresenta o que é uma Feature Store, quais problemas esta arquitetura busca resolver e por fim conclui com uma breve discussão sobre quando ela é necessária.

Problemas comuns no uso de modelos de Machine Learning em produção

Modelos de Machine Learning usam dados para aprender padrões e realizar predições em novos exemplos. Os dados, na maioria dos casos, são tratados para representar uma característica ou medida que faça sentido para o modelo construído. Esses dados transformados são chamados de features, e o processo de transformação é conhecido como feature engineering.

Esse fluxo, apesar de aparentar ser simples, pode esconder problemas que são complexos de serem identificados, tendo em vista que muitas vezes a construção das features está dispersa em diversas bases de códigos distintas, em queries definidas diretamente no código. Outro cenário muito comum são as transformações dos dados sendo feitas fora de pipelines, acopladas a chamada do modelo, o que torna a depuração de eventuais erros complexa e até mesmo inviável.

Training-serving skew

Um desses problemas é conhecido como training-serving skew que, de forma simplificada, ocorre quando há uma distinção na performance do modelo nos momentos de treinamento e predição, de forma que ao apresentar uma mesma entrada para um determinado pipeline ML (transformações + modelo) durante a validação do treinamento e em produção, diferentes valores de features e até mesmo predições são retornados.

Esse tipo de problema é causado por uma diferenciação no modo de construção das features de treinamento e predição. Isso costuma ocorrer pois a forma como os dados são consumidos pode variar, o que pode levar a situações em que uma mesma feature possui múltiplos pipelines de construção.

Imagine que num primeiro momento o modelo é construído usando dados históricos consumidos em lotes. Já na predição, são usados os dados mais recentes, que podem ser consumidos de duas formas distintas:

  • Consumo em lotes: Múltiplas, ou até mesmo todas, as linhas da tabela de features são usadas, e as predições são armazenadas para consumo posterior;
  • Consumo em tempo real: O modelo é disponibilizado através de uma API ou equivalente, e suas predições são realizadas de acordo com a demanda.

Na imagem abaixo temos a representação dos dois métodos de predição.

Diferença entre predição em lotes e em tempo real

Como exemplo do problema de training-serving skew, imaginemos um modelo que foi treinado com uma de suas features sendo uma medida no sistema métrico. Entretanto, no momento de predição a mesma feature agora foi passada para o modelo usando o sistema imperial. Este tipo de erro muitas vezes será silencioso até que seja tarde demais. Apesar de não ser no contexto de Machine Learning, esse exato problema de uso incorreto de medidas já ocorreu no sistema de navegação de um foguete da NASA.

Problema de training-serving skew

Data drift

Outro problema, que apesar da similaridade da degradação do modelo gerada pelo training-serving skew, resulta de uma causa diferente, é o data drift. Esse tipo de problema é definido como uma variação nas distribuições dos dados de produção dos dados que foram usados para testar e validar o modelo antes de implantá-lo em produção.

Exemplo de data drift

O que é uma feature store?

“…uma camada de gerenciamento de dados para Machine Learning que permite compartilhar e descobrir recursos e criar pipelines de aprendizado de máquina mais eficazes” — Feature Store for ML — What is a Feature Store?

A ideia de uma Feature Store foi publicamente apresentada pela primeira vez em 2017 pela Uber. Sua principal função, além de facilitar a reutilização, descoberta e documentação de features, é garantir a entrega correta dos dados para os modelos de Machine Learning de forma consistente para evitar o problema de training-serving skew, apresentado anteriormente.

Podendo possuir muitas responsabilidades adicionais, focaremos somente nas partes essenciais que compõem uma Feature Store que, primariamente, pode ser considerada como um banco de dados duplo, possuindo uma Offline Store e uma Online Store:

  • A Offline Store funciona como um Data Warehouse, servindo de repositório central, onde muitos dados são armazenados, mantendo uma coerência no histórico de cada tabela, para futuras análises e eventuais construções de modelos e predições em lote. Comumente, os dados são periodicamente adicionados ao histórico das tabelas através de um orquestrador, usando serviços como o Apache Airflow ou Luigi. Uma outra responsabilidade que o orquestrador pode ter é a de calcular métricas sobre os novos dados, de forma que tenhamos um histórico da evolução das métricas que pode ser usado para medir e detectar problemas de data drift.
  • A Online Store é um banco de baixa latência, normalmente um banco em memória, em que somente os valores mais recentes das features são armazenados para consumo de modelos em predições em tempo real.
Fluxo de transformação dos dados em features

Além disso, outro componente essencial numa Feature Store é um Feature Registry, que armazena os metadados das features como descrição, autor, query de criação, etc. Tal estrutura funciona como um catálogo que pode ser usado para descobrir e compartilhar features. O serviço de orquestração consome os metadados e registra as métricas nessa estrutura.

Componentes de uma Feature Store

Desta forma, vamos para um exemplo de uso de uma Feature Store:

  • Após investigar algumas bases de dados disponíveis no Data Lake de sua empresa, uma cientista de dados decide criar algumas features que serão usadas num novo modelo que ela está desenvolvendo;
  • Ela monta uma query que criará essa nova tabela de features e, após isso, realizará seu registro no Feature Registry, onde também serão armazenados metadados como, por exemplo, o nome da cientista de dados, a data de criação, as dependências daquela tabela, e a periodicidade que aquela query deve ser executada;
  • Uma vez registrada, essa query será executada periodicamente por um serviço de orquestração, que adicionará aquele novo ponto no tempo ao histórico da tabela presente na Offline Store;
  • Após desenvolver o modelo usando as novas features que ela criou, a cientista de dados decide que irá implantar seu modelo para realizar predições em tempo real. Para isso, ela altera o registro da tabela no Feature Registry, solicitando que a safra mais recente seja sempre enviada para a Online Store;
  • Deste momento em diante, o orquestrador responsável pela criação da tabela na Offline Store também enviará os valores mais recentes para a Online Store;
  • Uma vez implantado, o novo modelo da cientista de dados consumirá, de acordo com a demanda, suas features diretamente da Online Store, obtendo os dados necessários no menor tempo possível e com a garantia de que estão devidamente atualizados.

Quando devo ter uma Feature Store?

Uma Feature Store pode ser uma ferramenta valiosa em qualquer projeto de ML em que a quantidade e a complexidade dos dados sejam considerações importantes. Ela pode ajudar a melhorar a eficiência e a eficácia de fluxos de trabalho dos times de ciência e engenharia de dados de uma empresa. Assim, haverá uma forma padronizada de consumo dos dados pelos modelos, que impacta na efetividade da construção de novas features e permite que você crie e implante modelos de Machine Learning com maior confiança.

A estrutura é indispensável quando pensamos na escalabilidade ao manter o histórico das features possibilitando reprodutibilidade de experimentos. Outro ponto: sua característica de repositório central dos metadados e definições das features usadas pelos modelos de Machine Learning é uma ferramenta útil em fluxos de governança de dados.

Dito isso, para implantar e manter tal ferramenta no ar há um custo de tempo, além do esforço computacional que precisa ser levado em consideração. Normalmente, a adoção de uma Feature Store é um passo de maturidade por parte da área de dados de uma empresa, sendo realizado após alguns modelos já terem sido desenvolvidos, implantados e validados. Outro fator que deve ser considerado é a existência de um Data Lake ou Data Warehouse, necessárias na construção da Offline Store, que armazenará o histórico das features.

Caso estes pontos já tenham sido avaliados e você chegou a conclusão de que de fato precisará de uma Feature Store, no próximo artigo falaremos das soluções existentes no mercado e de como aqui na Pier construímos uma Feature Store a partir da infraestrutura presente na empresa.

--

--