Uma feature store sem vazamento
Uma definição por feature, servida offline para treino e online para inferência, com joins point-in-time que nunca espiam o futuro.
- Feast
- DuckDB / Parquet
- Redis
- Apache Airflow
- Great Expectations
Demo interativa
Arraste uma bandeira pela linha do tempo para mover o rótulo · arraste o fundo para girar
Linhas de treino que este join produz
| Cliente | Rótulo | purchases_30d | Valor do dia | Estado |
|---|
O experimento
Os mesmos clientes sintéticos, o mesmo modelo (regressão logística com 3 features), duas formas de montar o conjunto de treino. “Offline” é o score de validação que você reportaria; “produção” é como o modelo realmente se sai quando, na hora de prever, só existe o passado.
O que experimentar
- Troque para “Último valor”: toda ligação que passa da sua bandeira fica vermelha. Essas linhas ensinam ao modelo como é o churn depois que ele já aconteceu.
- Arraste a bandeira do C-102 para os lados: o join point-in-time sempre pega a última barra estritamente antes dela, nunca uma depois.
- Baixe o TTL até o C-104 perder o valor: uma feature velha vira ausente em vez de fingir que está fresca.
- Rode o experimento: o modelo com vazamento parece perfeito offline e desaba para cara ou coroa em produção. Nada nas métricas offline avisa.
O problema
A maioria dos modelos em produção é pior do que no notebook porque o treino usou um valor que ainda não existia no momento da previsão. Uma feature store existe para tornar esse erro impossível, e para impedir que cinco times calculem “usuários ativos” de cinco jeitos diferentes.
Como funciona
- As features são declaradas uma vez (fonte, entidade, transformação, frescor) num registro.
- O armazenamento offline guarda o histórico completo; os conjuntos de treino são montados com joins point-in-time: para cada rótulo, o valor mais recente da feature estritamente antes do timestamp do rótulo.
- Jobs de materialização enviam os valores mais recentes para o Redis, para leituras online em milissegundos.
- Uma checagem de consistência compara os valores online e offline para a mesma entidade e instante.
O que é real, o que é simulado
Real
- O join point-in-time, a regra de TTL e a detecção de vazamento na linha do tempo são a lógica de verdade, rodando no seu navegador.
- O experimento realmente treina duas regressões logísticas com 2.800 linhas e as avalia em 1.200, calculando o AUC pela estatística de Mann–Whitney.
Simulado nesta demo
- Os clientes e o comportamento deles são sintéticos, gerados para que a atividade pare depois do churn, que é exatamente o que faz o “último valor” vazar.
- A entrada do registro é ilustrativa; não há um servidor Feast por trás desta página.
Ainda não construído
- Repositório Feast com armazenamento offline (Parquet/DuckDB) e online (Redis)
- Job de materialização no Airflow
- Checagem de consistência online/offline com Great Expectations