Pipeline de Recursos para Modelos (Feature Pipelines)

Construindo Pipelines de Recursos (Feature Pipelines)

Quando usar

• Projetar recursos para modelos de ML a partir de dados de warehouse/stream.
• Prevenir vazamento de rótulo e skew entre treino e produção.
• Configurar um feature store, serviço online ou retrocargas históricas.
• Não usar para modelagem ou agregação geral (use skills dbt/Spark) a menos que alimente recursos de ML.

Workflow

- [ ] Definir cada recurso com uma chave de entidade e um timestamp de evento
- [ ] Construir conjuntos de treinamento com junções temporalmente corretas (as-of o tempo do rótulo)
- [ ] Compartilhar UMA definição para offline (treinamento) e online (servir)
- [ ] Definir actualização/materialização para recursos online
- [ ] Retrocarregar recursos históricos de forma idempotente para treinamento

1. Correção temporal (point-in-time). Juntar recursos de acordo com o timestamp de cada rótulo — usar apenas dados conhecidos antes do momento da predição. Isso previne o vazamento de rótulo, o bug mais prejudicial em features.
2. Paridade offline/online. Calcular um recurso da mesma forma para treinamento (offline, batch) e servir (online, baixa latência). Lógica divergente causa skew entre treino e produção e degradação silenciosa.
3. Atualização (Freshness). Recursos online devem ser materializados em uma agenda que atenda à tolerância de obsolescência do modelo.
4. Retrocargas idempotentes. Recomputar recursos históricos deve ser repetível (ver designing-backfills-and-replays).

Padrões

Junção temporal (as-of join) — obter o valor mais recente do recurso estritamente anterior a cada evento de rótulo:

SELECT l.entity_id, l.label_ts, f.value AS feature
FROM labels l
LEFT JOIN features f
  ON f.entity_id = l.entity_id
 AND f.event_ts <= l.label_ts          -- apenas dados passados; sem vazamento
QUALIFY ROW_NUMBER() OVER (
  PARTITION BY l.entity_id, l.label_ts ORDER BY f.event_ts DESC) = 1;

Definição única, dois caminhos — definir o recurso uma vez (ex.: Feast FeatureView); materializar para um armazenamento offline para treinamento e para um armazenamento online para servir, de modo que ambos usem lógica idêntica.

Atualização + materialização — agendar materialização online; monitorar a atualização dos recursos como qualquer SLA de dataset (implementing-pipeline-observability).

Armadilhas comuns

• Vazamento de rótulo — juntar recursos computados após o timestamp do rótulo infla as métricas offline e colapsa em produção; sempre utilizar junção as-of.
• Skew entre treino e produção — implementações separadas para offline e online derivam; compartilhar uma definição única.
• Recursos online obsoletos — o modelo serve com valores antigos; definir e monitorar a atualização.
• Retrocargas não reproduzíveis — histórico de treinamento inconsistente; tornar a recomputação de recursos idempotente.
• Ausência de chaves de entidade/timestamp — recursos não podem ser unidos corretamente ao longo do tempo; exigir ambos.
• Recursos não versionados — redefinição silenciosa quebra a comparabilidade do modelo; versionar as definições de recursos.