Construction de Pipelines de Fonctionnalités
Quand l'utiliser
- Ingénierie de fonctionnalités pour des modèles ML à partir de données d'entrepôt/stream.
- Prévention des fuites de labels et du skew train/serve.
- Mise en place d'un feature store, service en ligne, ou backfills historiques.
- Ne PAS utiliser pour la modélisation/agrégation générale (utiliser les compétences dbt/Spark), sauf si cela alimente des fonctionnalités ML.
Workflow
- [ ] Définir chaque fonctionnalité avec une clé d'entité et un horodatage d'événement
- [ ] Construire des ensembles d'entraînement avec des jointures temporelles correctes (as-of le moment du label)
- [ ] Partager UNE SEULE définition pour le hors ligne (entraînement) et le en ligne (service)
- [ ] Définir la fraîcheur/la matérialisation pour les fonctionnalités en ligne
- [ ] Backfiller les fonctionnalités historiques de manière idempotente pour l'entraînement
- Correction temporelle. Joindre les fonctionnalités en fonction de l'horodatage de chaque label — utiliser uniquement les données connues avant l'heure de prédiction. Cela évite la fuite de labels, le bug de fonctionnalité le plus nuisible.
- Parité hors ligne/en ligne. Calculer une fonctionnalité de la même manière pour l'entraînement (hors ligne, batch) et le service (en ligne, faible latence). Une logique divergente provoque un skew train/serve et une dégradation silencieuse en production.
- Fraîcheur. Les fonctionnalités en ligne doivent être matérialisées selon un calendrier qui respecte la tolérance au vieillissement du modèle.
- Backfills idempotents. Recalculer les fonctionnalités historiques doit être reproductible (voir
designing-backfills-and-replays).
Patterns
Jointure temporelle (as-of) — choisir la valeur de fonctionnalité la plus récente strictement avant chaque événement de label :
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 -- uniquement données passées ; pas de fuite
QUALIFY ROW_NUMBER() OVER (
PARTITION BY l.entity_id, l.label_ts ORDER BY f.event_ts DESC) = 1;
Définition unique, deux chemins — définir la fonctionnalité une fois (par ex. Feast FeatureView) ; matérialiser vers un store hors ligne pour l'entraînement et un store en ligne pour le service, afin que les deux utilisent une logique identique.
Fraîcheur + matérialisation — planifier la matérialisation en ligne ; surveiller la fraîcheur des fonctionnalités comme tout SLA de jeu de données (implementing-pipeline-observability).
Pièges courants
- Fuite de labels — joindre des fonctionnalités calculées après l'horodatage du label gonfle les métriques hors ligne et s'effondre en production ; toujours utiliser une jointure as-of.
- Skew train/serve — les implémentations hors ligne et en ligne séparées dérivent ; partager une seule définition.
- Fonctionnalités en ligne obsolètes — le modèle sert sur des valeurs anciennes ; définir et surveiller la fraîcheur.
- Backfills non reproductibles — historique d'entraînement incohérent ; rendre le recalcul des fonctionnalités idempotent.
- Absence de clés d'entité/d'horodatage — les fonctionnalités ne peuvent pas être jointes correctement dans le temps ; exiger les deux.
- Fonctionnalités non versionnées — une redéfinition silencieuse casse la comparabilité des modèles ; versionner les définitions de fonctionnalités.