Feature Store do zero: DuckDB + Redis resolvem o skew entre treino e inferência

A implementação mínima descrita na notícia não é só 'simples', é uma arquitetura intencionalmente desacoplada em cinco papéis técnicos: (1) registro de features com metadados versionados, (2) offline store em Parquet + DuckDB para transformações SQL nativas e backfills rápidos, (3) online store em Redis com TTLs ajustáveis e estruturas hash por entidade (ex: user:123), (4) pipeline de materialização que roda em intervalos ou eventos (não em streaming contínuo), e (5) API FastAPI com tipagem Pydantic para garantir contrato entre treino e inferência. DuckDB aqui não substitui um data warehouse, ele executa joins complexos sobre dados históricos sem ETL prévio, aproveitando leitura direta de Parquet e otimizações de vetorização; já o Redis não é usado como cache genérico, mas como repositório transacional de features atualizadas em tempo real, com operações atômicas de HSET e HGETALL para recuperação por chave composta.

O trecho 'reduzir o gap entre treino e servimento' tem base concreta: o training-serving skew é mitigado porque a mesma definição de feature (ex: últimos 7 dias de cliques por categoria) é calculada *uma única vez* no DuckDB e replicada *sem transformação adicional* para o Redis, eliminando divergências por diferenças de bibliotecas, horários de processamento ou truncamento de precisão que ocorrem quando equipes recriam logicamente as mesmas features em Python e em C++/Rust no servimento.

Em abril, o CEVIU destacou o uso de Redis para observabilidade em motores de recomendação, mas como camada de telemetria, não como online store funcional. Agora, o Redis assume papel central de produção: armazena features prontas para inferência, não apenas métricas. Também há mudança de escopo em relação ao Feature Trimmer (04/05): antes, o Pinterest removia features redundantes *durante* a requisição; agora, a abordagem é preventiva, definir, persistir e sincronizar features *antes* da inferência, reduzindo a necessidade de filtragem em runtime. A stack DuckDB+Redis também se diferencia da plataforma 'Basement' com Iceberg+R2 (23/04): lá, o foco era custo zero para análise exploratória; aqui, é governança mínima para ML em produção, mesmo tech stack, objetivos distintos.

Equipes de dados não estão mais escolhendo entre 'feature store completo' e 'zero governança'. Essa implementação mostra que é possível ter controle de versão, consistência entre ambientes e baixa latência com menos de 200 linhas de código Python, sem Kubernetes, sem Kafka, sem serviço gerenciado. Isso muda o ponto de entrada para startups e squads internas: governança de features deixa de ser um projeto de infraestrutura de 6 meses e vira uma tarefa de engenharia de dados de 2 dias. Para RAG, significa que contextos estruturados (ex: histórico de suporte do cliente, preferências explícitas) podem ser injetados na inferência com latência sub-10 ms, sem depender de bancos vetoriais ou LLMs customizados.