Bonnes pratiques de remplissage rétrospectif
Pour diverses raisons, il peut être nécessaire de remplir rétrospectivement des données : erreurs de données, nouvelles informations (comme de nouvelles fonctionnalités) ou rapprochement des données entre deux systèmes. Lorsque vous effectuez un remplissage rétrospectif, suivez les principes de cet article pour préserver la qualité des données et les performances du modèle.
Quand le remplissage rétroactif est-il nécessaire ?
Le remplissage rétroactif (backfilling) consiste à alimenter un jeu de données a posteriori avec des données historiques. Voici les scénarios les plus courants :
| Scénario | Description | Exemple |
|---|---|---|
| Nouvelles fonctionnalités | Vous avez identifié un nouvel indicateur important pour votre modèle et vous disposez des journaux historiques bruts pour le calculer. | Vous ajoutez le « taux de clics » comme fonctionnalité et avez besoin de trois mois d’historique pour que le modèle dispose de suffisamment de données pour apprendre. |
| Récupération de données | Votre pipeline de données a échoué certains jours, ce qui a créé des lacunes dans les données transmises à Decisioning Studio Pro. | Une panne du pipeline mardi a laissé une lacune. Une fois le correctif déployé, vous remplissez rétroactivement les enregistrements manquants à partir du système source. |
| Changements de logique | Vous avez mis à jour la formule de calcul d’une fonctionnalité ou modifié la définition d’un événement. | Vous avez redéfini la notion d’« utilisateur actif » et devez réexporter les données historiques pour que le modèle s’entraîne sur la nouvelle définition. |
Exigences
Pour que Decisioning Studio Pro fonctionne correctement, toutes les données entrantes doivent pouvoir être rétroactivement chargées (backfill) sur des périodes historiques. La fenêtre rétrospective requise (exprimée en mois) dépend des exigences d’entraînement du modèle d’IA. Contactez votre équipe AI Decisioning Services pour confirmer la valeur adaptée à votre cas d’usage.
Lors d’un chargement rétroactif des données historiques, les normes suivantes sont obligatoires :
- Cohérence des processus : Les instantanés historiques des fonctionnalités doivent être générés selon un processus parfaitement cohérent avec la création des instantanés en production. Si votre pipeline en production applique des transformations, des agrégations ou des filtres, ces mêmes étapes doivent également s’appliquer aux données chargées rétroactivement.
- Cohérence du schéma : Le schéma des données chargées rétroactivement doit correspondre exactement à celui du pipeline quotidien habituel, y compris les mêmes champs, les mêmes types de données et les mêmes conventions de nommage des colonnes.
Pièges courants
Fuite de données (biais d’anticipation)
La fuite de données est l’erreur de backfilling la plus critique. Elle se produit lorsque le processus de backfill intègre par inadvertance des informations qui n’étaient pas encore disponibles au moment où l’enregistrement historique a été généré.
Pourquoi c’est important
Si le modèle s’entraîne sur des données qui « connaissent l’avenir », il semblera performant pendant l’entraînement, mais produira de mauvais résultats en production, car les décisions en temps réel n’ont pas accès aux données futures.
Prenons l’exemple du calcul d’une fonctionnalité historique de « valeur vie client » à partir des dépenses totales d’un client à ce jour (c’est-à-dire jusqu’à aujourd’hui), puis de l’utilisation de cette valeur pour prédire un comportement survenu il y a plusieurs mois. Au moment de cet événement historique, la valeur vie client complète n’était pas encore connue.
Pour éviter ce problème, reconstruisez chaque fonctionnalité historique à partir des informations disponibles à l’horodatage historique correspondant.
Dérive du schéma et de la logique
Les structures de données et les définitions métier évoluent au fil du temps. Les incohérences entre les données historiques et les données en direct peuvent dégrader silencieusement la qualité du modèle.
- Dérive du schéma : Si un champ (par exemple,
zip_code) a été ajouté récemment à votre base de données, les enregistrements issus du backfill antérieurs à ce changement contiendront des valeurs nulles pour ce champ. Assurez-vous que votre pipeline gère correctement les champs manquants et que le modèle ne dépend pas excessivement de champs dont la couverture historique est faible. - Dérive de la logique : Si la définition d’un indicateur a changé à un moment précis (par exemple, la notion d’« utilisateur actif » a été redéfinie en 2024), appliquer uniformément la nouvelle définition aux données plus anciennes (par exemple, les enregistrements de 2022) peut créer des pics ou des baisses artificiels qui ne se sont jamais produits. Dans la mesure du possible, appliquez la définition en vigueur au moment de chaque enregistrement historique, ou documentez clairement le point de rupture afin que le modèle puisse en tenir compte.
Enregistrements en double dus à des tâches de backfill échouées
Les tâches de backfill qui échouent en cours d’exécution puis sont relancées peuvent produire des enregistrements en double si le processus n’est pas conçu pour l’éviter. Les doublons gonflent artificiellement les indicateurs et introduisent du bruit dans l’entraînement du modèle.
La solution : Concevez tous vos scripts de backfill pour qu’ils soient idempotents : exécuter deux fois la même tâche doit produire le même résultat qu’une seule exécution. Utilisez l’un des modèles suivants :
- Upsert (mise à jour ou insertion) : Basé sur un ID de transaction unique ou un horodatage, de sorte que la réinsertion d’un enregistrement existant le met à jour au lieu de créer un doublon.
- Suppression puis insertion : Supprimez les enregistrements existants pour la plage temporelle ciblée avant l’insertion, afin que le jeu de données soit toujours remplacé proprement.