O que é uma Feature Store?
--
Um dos temas extremamente em alta hoje é a utilização de uma feature store em um pipeline de MLOps, chique colocar palavras novas, né? Hahaha, mas eu gostaria de aproveitar este post como um método de estudo e também para dividir um pouco com alguém que tenha feito o questionamento já.
Partirei da premissa que você, leitor, já está por dentro de alguns conhecimentos sobre o ciclo de vida de modelos de machine learning e está deparando com novos conceitos no mercado que estão no âmbito de engenharia.
Vamos definir de largada algumas perguntas para respondermos ao longo do texto.
- O que é uma Feature?
- Que tipos de Features existem em Machine/Deep Learning?
- Porque preciso de um “Store”?
- Quais requisitos funcionais eu tenho para uma Feature Store?
- Quais os tipos de arquiteturas de Feature Stores?
- Quando alguém cria uma Feature, quem é responsável por ela?
- Onde deveria estar catalogada?
- Como manter um rastro da lógica que a implementa?
O que é uma “Feature”?
Uma feature (variável), no contexto de Machine Learning, é considerado um dado utilizado como entrada para um modelo.
Que tipos de Features existem em um projeto de ML/DL?
Seu nome por vezes é complicado pois não atribui um significado único, podendo esta ser uma coluna em uma tabela, cujo significado é “quantidade de compras no mês”, uma variável booleana que indica se houve compra ou não nos últimos quinze minutos, o logaritmo neperiano de alguma coluna de um determinado valor, ou mesmo um vetor ininteligível que é uma representação resumida de uma imagem/texto/áudio/vídeo por técnicas de “Extração de Features”.
Por sua especificidade em alguns casos, você pode se perguntar o motivo de existir uma capacidade tecnológica só para lidar com as Features, afinal, cada projeto não deveria lidar com seus problemas de forma independente?
Porque preciso de um “Store”?
A palavra store no contexto de Feature store não faz referência ao significado de armazenamento, e sim mais relacionado a uma loja, devido a capacidade de reutilização, embora o “storage” também faça parte do escopo.
Em um projeto de Analytics geralmente costuma-se seguir o fluxo abaixo.
O problema ocorre quando você passa a ter inúmeros destes, e percebe que no final a maioria dos seus modelos de ML usufruem das mesmas features, ou seja, você está gastando um tempo/dinheiro desnecessário em custo computacional, vide imagem.
Quais requisitos funcionais eu tenho para uma Feature Store?
Apenas a questão de pipelines redundantes é uma parte do que uma FS poderia endereçar, mas existem ainda dentro de um projeto de Analytics outras falhas em potencial que podem ser endereçadas com o uso de uma FS, tais como:
- Training/Serving Skew
Lembre-se que um cientista de dados treina um modelo em um conjunto de dados, geralmente em bases que foram persistidas ao longo do tempo.
Todas as transformações que foram realizadas em tempo de treinamento precisam ser efetuadas de forma idêntica em momento de “serving”, quando o modelo for levado a produção, ou do contrário o seu modelo poderá apresentar resultados inconsistentes e o time levará muito tempo para descobrir o que houve. A FS é capaz de resolver isso abstraindo estes dois momentos de train/serve por uma simples parametrização numa API/SDK.
- Data Leakage/Point in time correctness
Mesmo que as transformações tenham sido feitas de forma idêntica, ainda pode existir a possibilidade de um erro em um projeto de ML no que tange ao ajuste temporal.
Imagine que um cientista de dados precisa desenvolver um modelo para empréstimos e conseguiu criar um modelo que determina bem quem solicita um empréstimo. Em sua avaliação, o que determina quem solicita um empréstimo são as compras realizadas nos últimos sete dias, e todas as agregações são feitas de forma diária. O conjunto de teste também deu a entender que estava tudo certo e o modelo foi a produção, do ponto de vista de um cientista estava tudo perfeito no que tange a boas práticas de ML, mas ainda assim ele não deu o resultado esperado, o que aconteceu? Como identificar?
Por qualquer motivo que seja, pressão para entrega, distração, desconhecimento em transformações com pyspark, ou mesmo foco em outras coisas, isso o levou a realizar um join de seu público alvo com as variáveis dos últimos sete dias, mas a questão é que ele considerou os clientes que de fato pedem um empréstimo e logo efetuam uma compra em seguida.
Isso ocasionou o que chamamos de Data Leakage, o vazamento de uma informação futura que não estará presente quando ele for para produção.
Embora a ilustração tenha sido longa, o objetivo era apenas pontuar que um outro problema potencial que discutimos resolver com uma FS é abstrair este tipo de erro, o que pode levar um projeto de meses a uma falha silenciosa. Isso é feito com uma capacidade chamada de Point in Time Correctness, garantindo que todas as transformações respeitem uma linha temporal perfeita.
(Como todo cenário, más implementações sempre são sujeitas a falhas)
- Regras perdidas de negócios/Feature tracking/Data lineage
Em um certo projeto que trabalhei, eu me deparei com uma necessidade de identificar quais eram os clientes ”ativos” de um produto, e após dois meses de trabalho e inúmeras reuniões para reconceber as regras, eu cheguei a uma conclusão triste: Costumamos não versionar o conhecimento de negócios e as premissas, com a desculpa de que “negócios precisa ser ágil e muda o tempo todo”, o que naquele momento pode ser uma verdade. Mas o débito técnico escondido é que uma pessoa que acabou de chegar na companhia e/ou outras pessoas de outras partes do negócio gastam um tempo infrutífero para redescobrir as próprias regras de funcionamento.
Ao criar uma tabela de Features, com a governança e processo correto, somos capazes de mapear e versionar do ponto de vista técnico e por fim avançar mais um passo na resolução deste problema. (Um adendo a este tópico é levantado no final do texto, leia com cuidado e não tome decisões erradas.)
Por todas estas razões, e outras, mas não vou estender mais neste assunto, uma “loja” com algumas capacidades se faz necessário, vamos detalhar um pouco sobre a arquitetura de uma Feature Store de forma funcional.
Arquitetura de uma Feature Store
A arquitetura diverge de empresa para empresa, em soluções in-house ou de mercado, ao passo que tentarei trazer uma pesquisa de algumas disponíveis como produtos ou mesmo soluções in-house de empresas que estão na vanguarda de ML por suas necessidades peculiares.
Três tipos de arquitetura (por FeatureForm)
No artigo Feature Stores Explained, Simba Khadder conta um pouco da história das Feature Stores muito antes de terem um nome bonito, onde empresas como AirBnB, Uber e Twitter ao se deparar com as dificuldades que mencionamos criaram suas próprias soluções para endereçar os problemas. Khadder em análise sugere que podemos classificar em três design patterns: literal, physical e virtual feature stores.
Literal Feature Stores: Neste cenário a FS atua como um armazenamento centralizado de feature values. Os cientistas de dados utilizam seus pipelines para processar as Features e armazenam na Feature Store. Por sua vez utilizam a API da FS para treinar e servir seus modelos.
Como o próprio nome indica, essa opção atua bem com seus data pipelines, e serve apenas ao propósito de uma FS não adquirindo nenhuma responsabilidade, é a forma mais leve das três arquiteturas cm um custo de adaptação baixo. Se o time já está feliz como constrói, mantém e implementa pipelines de dados, a literal FS geralmente é uma boa opção.
A mais popular com este tipo de arquitetura é a Feast.
Physical Feature Stores: Unificam ambas as etapas de armazenamento e processamento. Geralmente substituem a infraestrutura atual como Spark/Redis por uma ferramenta completa que endereça ambos os problemas. É a arquitetura mais comum entre vendors e projetos desenvolvidos in-house.
Possui sua Domain specific language para endereçar transformações, e sua própria camada de storage para armazenar e servir Features.
Sua arquitetura consiste de:
- Uma camada de metadados
- Uma inference store
- Uma training store
- E uma engine de transformação
Por ser um conjunto pré construído ao invés de efetuar integrações, costuma ter o máximo de funcionalidades e performance, mas também vem com um alto custo de adoção. O usuário fica travado em uma arquitetura, não tendo flexibilidade ou controle, e por gerenciar a camada de transformação, o usuário não pode selecionar entre Spark, Flink, Presto, mas a transformation layer tenta ser uma camada de abstração semelhante ao Spark.
As opções mais populares com esse tipo de arquitetura são o Zipline da AirBnB, Dryft da Lyft e Michelangelo da Uber (FS integrada a ML Platform) e a ferramenta Tecton que é baseada na arquitetura de FS do Michelangelo.
Virtual Feature Stores: Esse tipo de arquitetura transforma a infraestrutura existente em uma FS. Centraliza e padroniza as definições de Features enquanto distribui entre um conjunto heterogêneo de providers, buscando resolver os problemas organizacionais ao redor da construção e manutenção de features, mantendo um baixo custo de adoção e alta flexibilidade.
Ao contrário de uma Literal Feature Store,as VFS ainda gerenciam as transformações. No entanto, ao contrário de uma PFS, a Virtual Feature Store coordena e gerencia as transformações ao invés de efetivamente processar, continuando agnóstica a processing layer/API.
A VFS é mais parecida com um framework ou workflow do que uma peça adicional de infraestrutura. Ela transforma sua infraestrutura de dados existente em uma FS.
Sua arquitetura é composta de:
- Uma camada de metadados
- Uma training store
- Uma inference store
- Um coordinator
Semelhante a algumas literal Fs, as camadas de treinamento e inferência ficam em cima da infraestrutura atual da companhia. O objetivo do coordenador é colocar a infraestrutura no mesmo estado dos metadados. Por exemplo, se um usuário define uma feature como um conjunto de Spark jobs, então o coordenador se encarrega de garantir que eles rodaram com sucesso. Desta forma, ela geralmente irá substituir uma peça como o Airflow para casos de uso de geração de Features.
Ao contrário de uma PFS, o código atual de infraestrutura não precisa ser portado para uma Domain specific language. Sua API requer que os cientistas de dados especifiquem nomes, versões, descrições, owner, providers e outros metadados necessários para criar e manter Features.
De acordo com Khadder, eles perceberam na Triton que o maior problema era relacionado a organização e workflow, e não a infraestrutura atual. Por tal razão, chegaram a conclusão que os cientistas de dados precisavam de uma peça de workflow adequada e não mais infraestrutura, motivo pelo qual desenvolveram a FeatureForm (VFS).
Algumas arquiteturas conhecidas
Para dar uma visão mais completa como se fosse um panorama geral de diversas arquiteturas, vou adicionar algumas outras opções que podem auxiliar na hora de escolher a melhor opção.
Hopsworks FS
No cenário da Hopsworks, ter tudo dentro de si traz o benefício de uma menor quantidade de integrações, mas também aumenta o custo de adoção de uma ferramenta como essa quando se tem todas as peças geridas por times independentes em uma grande organização.
Databricks — FS
Embora não necessariamente uma arquitetura aberta e detalhada, como podemos obter com alguns outros providers, a Databricks também segue de forma semelhante a idéia da Hopsworks (tal como o Michelangelo) de uma plataforma única e centralizada com todas as peças integradas, cada qual tem seu benefício e malefício, a exemplo de interações inteiramente baseadas em notebooks no caso da última.
Outros providers também trazem suas próprias visões do que é uma Feature Store, tentarei elencar mais duas opções legais para conhecermos.
Netflix — Axion FS
A Netflix construiu sua própria solução dentro de casa, dadas as suas necessidades específicas de lidar com tipos de dados não estruturados e também estruturados.
Aqui temos uma terminologia que pode ser considerada ligeiramente diferente e, pessoalmente como cientista, considero mais elegante, onde:
· Fatos: São pontos de dados atômicos sobre um usuário ou vídeo no Netflix. Por exemplo, um fato poderia refletir os videos adicionados a uma lista de preferência de um usuário. Fatos são geralmente utilizados por aplicações de processamento (compute) para gerar as features correspondentes.
· Aplicação de processamento (Compute): São as aplicações que processam os fatos e geram as features utilizadas em modelos de ML.
· Online Feature Generator: São os componentes que processam as features utilizadas em aplicações de ML em tempo real.
· Offline Feature Generator: Estes componentes são jobs Spark que executam longos processos de computação para calcular as features.
· Share Feature Encoders: São componentes compartilhados entre aplicações de compute e offline feature generators para servir a correta representação de features.
Tal representação é ainda mais interessante para casos em que consideramos a terminologia feature como um elemento que entra diretamente no modelo, e não necessariamente na essência do dado de qualidade.
Ao pegar um caso de uso que considera textos como informação principal, para que isso possa ser processado em um modelo simples, tal como uma regressão logística, estes textos precisam passar por um processo de codificação, ao qual chamamos de Feature Extraction.
Neste caso específico, pode-se pegar um texto e:
- Remover as stopwords (palavras de pouca informação/irrelevantes para o contexto)
- Remover a pontuação
- Aplicar a tokenizacao, considerando uma frase como uma lista de palavras.
- Utilizar técnicas de codificação, tal como Term-Frequency Inverse Document Frequency, para obter no final uma lista com valores que vão de 0 a 1.
Ao final deste processo todo, a lista com os valores que vão de 0 a 1 é o que costumamos considerar como a palavra feature.
Trocando o cenário para uma instituição qualquer onde temos "Quantidade de compras/vendas" ou "Soma do valor de compras em um determinado dia", poderiamos convencionar que o que estamos querendo dizer é que isto são fatos.
Ainda assim, somente os fatos deveriam ser catalogados numa Feature Store? Não necessariamente, deve-se considerar o custo computacional, a reutilização destes elementos e se o seu processo sofre de alguns dos problemas que identificamos como dores na produtização de modelos de Machine Learning.
Como falei acima, a transformação de textos para um vetor numérico exige um custo computacional X, imagine o mesmo processo se para todo modelo eu precisasse transformar um video em algo inteligível, que convencionalmente pela academia existe uma forma mais relevante de extração de features?
Para não entrarmos num loop infinito de tecnicidade, saiba que a determinação sobre o que deve ser catalogado numa Feature Store depende inteiramente das características da companhia, de sua reutilização entre casos de uso, e mesmo num único caso de uso ainda vale a pena, lembra do problema de training-serving skew?
LinkedIn — Feathr FS (Open source)
Gostaria de adicionar mais uma das N soluções/arquiteturas disponíveis, para falarmos um pouco mais sobre a experiência do usuário.
Outra empresa que adotou o caminho Open source foi o LinkedIn com sua solução de Feature Store de nome Feathr.
Com uma quantidade de integrações já pré disponibilizadas em um cloud provider como a Azure, pode ser um caminho interessante para se adotar quando a Cloud Stack já está definida.
Soluções do tipo ganham espaço quando pensamos na experiência do usuário, veja:
Perceba que não fiz uma analise extensiva, pois este post já está bastante longo, mas convido você a uma análise aprofundada nas soluções comentadas aqui.
Para finalizar, haviamos separado os pontos abaixo que tangem mais ao dia a dia depois de ter implementado uma feature.
- Quando alguém cria uma Feature, quem é responsável por ela?
- Onde deveria estar catalogada?
- Como manter um rastro da lógica que a implementa?
Gostaria de pegar os três pontos e discutir em um único tópico, nomeadamente Feature Governance.
Governança de features
Quando alguém cria uma Feature, quem é responsável por ela?
Vimos que há organizações considerando camadas Gold de uma arquitetura de dados como features, enquanto outras consideram Features tão somente o resultado final, prévio ao modelo, tal como a literatura acadêmica indica.
Dado que, independente da definição, existe um time responsável por este cálculo, o time por sua vez deveria ser o responsável por tal "produto de dados" quando catalogado.
Mas e se o time estiver cruzando um dado de consumo com um dado de perfil? Não deveria ser responsabilidade dos donos dos dados?
Considere que a razão pela preocupação evidente em relação a um dado é pautada por potenciais problemas. Caso ocorra um vazamento, quem é responsável? E se ali houver um deslize?
É incorreto atribuir a um proprietário de um dado de consumo por exemplo, a responsabilidade de dar o acesso ou de explicar um eventual problema na lógica ali aplicada.
Quando um time de projeto de ciência de dados for o produtor dessas features, cabe ao time a responsabilidade de responder por elas, caso queira cataloga-las de forma pública para todos, e por cascata ao responsável por este time de projeto.
Quando um time de domínio de dados for o responsável, caberá a este time a responsabilidade, e por cascata ao owner deste domínio.
Para garantir que este fluxo funcione bem, você precisará garantir os seguintes requisitos técnicos:
- Controle de acesso granular por feature view, segmentado em grupos, com um proprietário por grupo.
- Separação das features entre "específicas para caso de uso" e "públicas".
- Monitoração completa da linhagem do dado, desde a criação de features até a origem do dado.
Onde deveria estar catalogada?
A descoberta é parte fundamental do sucesso no reuso dos dados, garanta que a usabilidade da ferramenta endereça todas as dúvidas feitas quando se pensa em um conjunto de dados.
"E se eu testasse a hipotese de que um cliente propenso ao produto A, sempre olha o produto B?"
"Mas o cliente antes de efetuar uma compra na minha loja, por onde passa? Será que eu tenho o dado de geolocalização?"
"Eu consigo identificar este perfil no mercado? Será que eu tenho o dado comprado e mastigado?"
O processo de descoberta parte de um pensamento inteiramente humano, e exploratório no quesito comportamento (quando for cabível), e portanto trazer uma hierarquia de separação auxiliará numa descoberta efetiva.
Categoria: Livros
Subcategoria: Estoque, Vendas, Arquivamento
Uma segunda parte fundamental na descoberta é uma boa interface, demonstrei a interface da Feathr logo acima, e para não ser repetitivo trarei outras opções:
A facilidade de buscas, quais filtros você disponibiliza, tal como um descritivo detalhado do que é cada Feature pode ser o essencial para um cientista de dados.
Além disso, sua ferramenta deve ser capaz de integrar com a linhagem: dado que uma feature é composta de 2 conjuntos de dados no datalake, de onde estes vieram e quais transformações existem neles? E de onde eles consomem? O que significa cada coisa?
Por fim, uma última pergunta a responder.
Como manter um rastro da lógica que a implementa?
Outro recurso interessante de uma FS é que ela serve muito bem para:
- Catalogar pipelines de dados
- Manter a linhagem de regras de transformação
- Servir como peça de monitoração deste pipeline
Uma ferramenta como essa é capaz de ter seu uso desvirtuado para que áreas de negócio passem a catalogar suas transformações, e resolver o principal problema de uma organização: conhecimento perdido ao longo do tempo.
No entanto, lembre-se que a utilização primária de uma FS deve ser realizada por sua API/SDK e nasceu primariamente para resolver problemas de Machine Learning, como vazamento de dados futuros, ou mesmo um viés entre treino e produção.
Evite, a todo custo, desvirtuar o propósito de sua ferramenta para que ela sirva como um mecanismo de catalogação de transformações de dados, pois este não é o objetivo.
Tenha em mente a clareza e o propósito de cada pipeline que você habilita em sua organização.
Eu desejo resolver os problemas de ML na minha organização? Uma FS pode auxiliar.
Eu desejo catalogar o conhecimento e passar a versionar regras de negócio, tal como criações de cubos e demais tipos de produtos de dados? Idealmente, você deveria ter um pipeline de dados específico para isso.
Este foi um post construído com um pouco de conhecimento coletado no quesito Feature Store nos últimos tempos, não tem a pretensão de ser uma autoridade máxima no que tange a uma FS, tal como é um tema novo no mercado e não existem "certos e errados".
Como guia para quem quiser conhecer mais, deixarei alguns links interessantes, e um livro sobre Feature Stores que ainda preciso ler posteriormente.
Se desejar contribuir, gostaria de saber também sua opinião, me mande uma mensagem!
Recursos extras:
Feature Stores Explained — FeatureForm
Enabling Data Governance with Feature Store
Livros:
