Feature stores: Feast (Gojek) e Feathr (LinkedIn)

01 · CONTEXTO

Por que uma feature store

Em ML, uma feature é um sinal sobre uma entidade do domínio. No exemplo do GO-JEK, a entidade é o motorista e uma das features é a contagem diária de viagens concluídas; várias features juntas formam a entrada de um modelo.

O anúncio do Feast aponta que, em equipes e ambientes grandes, a manutenção e o serving das features podem divergir bastante entre projetos. Entre os desafios típicos estão features refeitas várias vezes em vez de reaproveitadas, definições diferentes de um time para outro, dificuldade de servir valores atualizados que misturam dados em lote e em streaming, e inconsistência entre treino e serving.

Do lado do LinkedIn, o custo de construir e manter pipelines de dados de features era assumido de forma redundante por muitas equipes, porque cada uma tendia a ter o seu. Sem uma abstração comum, não havia nome uniforme para as features entre modelos, sistema de tipos uniforme nem forma uniforme de implantá-las e servi-las em produção.

02 · FEAST NO GO-JEK

Um warehouse para o histórico e um banco para o valor recente

O Feast foi desenvolvido em conjunto pelo GO-JEK e pelo Google Cloud como uma plataforma centralizada para padronizar a definição, o armazenamento e o acesso a features, tanto para treino quanto para serving. Ele faz a ingestão de dados em lote e em streaming e mantém dois tipos de armazenamento: um warehouse para o histórico e bancos de serving para os valores mais recentes.

1. As fontes em lote e em streaming alimentam uma ingestão unificada, que gerencia os dois tipos de dado.

2. A ingestão grava no feature warehouse, com o histórico, e no banco de serving, com os valores mais recentes.

3. Para treinar, o SDK Python gera datasets de treino a partir do feature warehouse.

4. Com o modelo implantado, uma biblioteca cliente consulta a Serving API, projetada para acesso de baixa latência aos valores mais recentes.

5. Os dois lados consultam features com o mesmo conjunto de identificadores.

Segundo o anúncio, é essa ingestão unificada que dá consistência entre treino e serving, e os mesmos identificadores valem no warehouse e na API de serving. Um armazém central também permite construir uma base de features reaproveitáveis entre projetos, e a plataforma funciona como ponte entre engenharia de dados e ML.

03 · FEATHR NO LINKEDIN

Features importadas por nome

O Feathr é o feature store que o LinkedIn construiu para simplificar o gerenciamento de features de ML e que foi aberto como código aberto. Ele oferece um espaço comum de nomes para definir features e uma plataforma comum para calculá-las, servi-las e acessá-las por nome, separando dois papéis: produtores definem e registram, consumidores importam.

Para o consumidor, a analogia do texto é uma ferramenta de gerenciamento de pacotes: ele lista os nomes das features que quer importar e o Feathr abstrai como elas são obtidas e calculadas. Do lado do produtor, as features são definidas a partir de fontes brutas, incluindo séries temporais, ou de outras features já definidas.

1. O produtor define a feature a partir de dados brutos ou de outras features e a registra no espaço comum de nomes.

2. O consumidor do fluxo de treino lista por nome as features que quer importar no seu modelo.

3. Para o treino, as definições registradas são reaplicadas sobre séries temporais históricas e as features são juntadas aos rótulos de forma correta no tempo.

4. Para a inferência, as features são pré-materializadas e implantadas em armazenamentos online, para serving de baixa latência.

O LinkedIn relata que implantou o Feathr em dezenas de aplicações, como Search, Feed e Ads. Segundo o texto, alguns dos maiores projetos de ML que trocaram pipelines próprios pelo Feathr reduziram o tempo de engenharia para adicionar e experimentar features de semanas para dias, e o Feathr chegou a ser mais rápido que os pipelines substituídos em até 50%. Sistemas de busca e recomendação sobre vagas, que tinham dificuldade de compartilhar features, passaram a compartilhá-las com facilidade.

04 · NÚCLEO TÉCNICO

Point-in-time e skew entre treino e serving

Um pipeline de features precisa reunir dados sensíveis ao tempo de várias fontes e juntar as features aos rótulos de treino de forma correta no tempo, o chamado point-in-time. No Feathr, isso vem de reaplicar as definições registradas sobre séries temporais históricas, para calcular cada feature em pontos específicos do tempo durante a geração dos dados de treino.

Para evitar o skew entre treino e serving, que o texto do LinkedIn chama de training-serving skew, os pipelines de features precisam garantir que elas sejam preparadas do mesmo modo nos contextos de treino e de inferência. O anúncio do Feast descreve como a inconsistência surge: o treino precisa de dados históricos, os modelos em produção precisam dos valores mais recentes, e surgem inconsistências quando os dados ficam isolados em sistemas independentes que exigem ferramentas separadas.

1. O treino precisa de acesso a dados históricos para montar o dataset.

2. O serving, por sua vez, precisa dos valores mais recentes.

3. Neste desenho, cada caminho tem a sua ferramenta; quando os dados ficam isolados em sistemas independentes que exigem ferramentas separadas, surgem inconsistências.

05 · COMPARAÇÃO

Feast e Feathr lado a lado

Os dois projetos atacam o mesmo problema de ML em produção: oferecer um ponto único para definir, calcular e servir cada feature, reduzindo a necessidade de cada equipe manter pipelines próprios.