Construire un système de ranking ML sur des données temporelles sans data leakage

Dans un système de Machine Learning appliqué à des données temporelles, la qualité d’un modèle ne peut pas être dissociée de la manière dont ses données d’entraînement et d’évaluation ont été construites.

La contrainte devient plus forte lorsque plusieurs observations appartiennent au même événement, doivent être classées les unes par rapport aux autres et que les prédictions de plusieurs modèles sont réinjectées dans les niveaux suivants d’un stack.

Le système présenté ici répond précisément à ce type de problème : produire un ranking relatif entre plusieurs candidats à partir de données historiques, puis combiner plusieurs modèles au sein d’une architecture multi-niveaux.

Sa validation repose sur un invariant central :

Toute prédiction historique doit être calculée uniquement à partir d’informations qui auraient réellement été disponibles au moment où cette prédiction aurait été produite.

Garantir cette propriété sur un modèle isolé est relativement simple. La maintenir à travers le feature engineering, plusieurs niveaux de stacking, des transformations apprises et une phase de calibration impose en revanche de la traiter comme une propriété de l’architecture complète.

---

1. Un problème de ranking temporel

Le dataset est structuré autour d’événements contenant plusieurs candidats.

Le système ne cherche donc pas uniquement à estimer une valeur indépendamment pour chaque observation. Il doit également capturer les relations entre candidats à l’intérieur de chaque événement.

L’architecture peut pour cela combiner plusieurs objectifs d’apprentissage ou représentations du problème. Certains modèles produisent un signal individuel continu, tandis que d’autres exploitent plus directement la structure relative de l’événement.

Des approches différentes peuvent obtenir des performances globales proches tout en capturant des signaux ou des erreurs partiellement distincts. Cette complémentarité peut ensuite être exploitée par les niveaux suivants de l’architecture.

Conceptuellement, un niveau du système peut être représenté ainsi :

Le point important n’est pas la nature exacte des modèles utilisés, mais la circulation de l’information entre les niveaux.

Cette architecture introduit en effet une difficulté supplémentaire : les prédictions produites par un niveau peuvent devenir elles-mêmes des données d’entraînement pour le niveau suivant.

La causalité temporelle doit donc être garantie non seulement au niveau du dataset initial, mais également à chaque frontière du stack.

---

2. Causalité temporelle du protocole de validation

Un split aléatoire est exclu.

L’indépendance entre train et test ne suffit pas lorsqu’une relation temporelle existe. Une observation évaluée à l’instant t doit être produite par un pipeline dont l’ensemble de l’état a été construit exclusivement à partir d’informations antérieures à t.

Cela concerne le modèle, mais également les agrégations historiques, les transformations apprises et tous les artefacts dérivés des données.

La contrainte fondamentale peut s’écrire :

max(date_train) < min(date_evaluation)

Le protocole principal conserve donc une séparation chronologique stricte :

TRAIN → CALIBRATION → TEST

La période de test reste postérieure à toutes les données utilisées pour construire le système. Cette propriété suffit pour évaluer un modèle entraîné directement sur le train.

Mais elle ne suffit plus dès que ses prédictions servent à entraîner un autre modèle.

---

3. Le stacking crée une nouvelle frontière de leakage

Le meta-modèle doit apprendre à exploiter les sorties des modèles A et B.

Il serait incorrect d’entraîner A et B sur le dataset complet, de leur faire prédire ce même dataset puis d’utiliser ces prédictions comme données d’entraînement du meta-modèle.

Même si le meta-modèle n’a jamais directement accès aux cibles utilisées par A et B, il reçoit des scores générés par des modèles ayant déjà vu ces cibles.

Les données d’entraînement du niveau supérieur sont alors in-sample.

En production, leur distribution sera différente puisque les modèles de premier niveau devront prédire de véritables observations inconnues.

Le problème du stacking n’est donc pas uniquement d’empêcher L2 d’accéder directement à sa cible. Il faut également garantir que les informations produites par L1 et consommées par L2 ont elles-mêmes été obtenues hors échantillon.

---

4. Construction des prédictions OOF temporelles

Les features destinées au niveau suivant sont construites à partir de prédictions Out-of-Fold.

Dans un contexte temporel, la contrainte OOF classique n’est toutefois pas suffisante. Une observation peut être absente du train tout en étant prédite par un modèle entraîné sur son futur.

Les prédictions doivent donc satisfaire simultanément deux propriétés :

observation ∉ train

et :

max(date_train) < date_observation

Les OOF sont générés au moyen de fenêtres d’entraînement expansives.

Chaque fenêtre enrichit l’historique disponible sans jamais franchir la frontière temporelle de la période qu’elle doit prédire.

Après concaténation, on obtient un dataset dans lequel chaque score correspond à une véritable prédiction historique hors échantillon :

date       features       prediction_L1
─────────────────────────────────────────
t₁            ...              0.42
t₂            ...              0.71
t₃            ...              0.33
t₄            ...              0.64

Ces prédictions peuvent alors devenir des features du niveau suivant sans lui transmettre directement le résultat d’un apprentissage in-sample.

---

5. L’événement comme unité atomique de validation

La dimension temporelle n’est pas la seule contrainte du split.

Dans un problème de ranking, les observations appartenant au même événement ne sont pas indépendantes. Leur position n’a de sens que relativement aux autres candidats du même groupe.

Un événement ne peut donc jamais être réparti entre plusieurs folds.

Si un événement contient :

Event 42
├── A
├── B
├── C
├── D
└── E

ses cinq candidats doivent appartenir au même segment.

L’unité atomique de validation n’est donc pas la ligne du dataset mais l’événement complet.

Cette propriété doit être conservée dans les folds OOF, les comparaisons entre modèles et les procédures statistiques ultérieures.

Elle évite également une forme plus discrète de contamination : laisser un modèle apprendre une partie du contexte d’un groupe avant de lui demander d’en classer les observations restantes.

---

6. Causalité du feature engineering

Une séparation temporelle correcte des modèles ne garantit pas à elle seule l’absence de fuite.

Le feature engineering doit respecter exactement la même causalité. Pour toute feature historique calculée au temps t, la propriété attendue est :

feature(t) = f(observations antérieures à t)

Cette contrainte concerne notamment les :

• Statistiques cumulées
• Moyennes historiques
• Fréquences
• Taux de réussite
• Fenêtres glissantes
• Agrégations par catégorie
• Historiques de classement
• Transformations dépendantes de la cible

Une agrégation calculée une seule fois sur l’ensemble du dataset avant le split peut suffire à contaminer toutes les observations historiques, même lorsque les modèles eux-mêmes respectent parfaitement la chronologie.

La frontière temporelle doit donc être respectée dès la construction des données, et pas seulement lors de l’entraînement des modèles.

---

7. Isolation des transformations apprises

Le modèle n’est pas le seul composant du pipeline capable d’apprendre à partir des données.

Certaines étapes de préparation calculent elles aussi des informations à partir de l’historique. Une normalisation, par exemple, peut utiliser la moyenne et la dispersion observées dans les données pour transformer les valeurs :

x' = (x - μ) / σ

où :

• x est la valeur d’origine
• x' est cette même valeur après normalisation
• μ représente la moyenne des valeurs observées
• σ représente leur écart-type, c’est-à-dire leur dispersion autour de cette moyenne

Si μ et σ sont calculés sur l’ensemble du dataset, ils intègrent indirectement des informations provenant du futur. Les données historiques sont alors transformées à l’aide de valeurs qui n’étaient pas encore disponibles à leur date.

Le même risque existe avec de nombreuses opérations :

• le remplacement des valeurs manquantes à partir de statistiques observées
• certains encodages de variables catégorielles
• le target encoding
• la sélection de variables
• les transformations par quantiles
• la réduction dimensionnelle
• la sélection fondée sur l’importance des variables
• la calibration

Le principe est donc plus général que la distinction entre modèle et prétraitement.

La bonne question est simplement :

Cette étape apprend-elle quelque chose à partir des données pour faire son travail ?

Si oui, les informations qu’elle utilise doivent elles aussi respecter la chronologie.

Autrement dit : une étape de préparation peut créer une fuite temporelle exactement comme un modèle si elle est construite à partir d’informations qui n’étaient pas encore disponibles au moment considéré.

---

8. Propagation récursive de la contrainte OOF

Cette propriété devient particulièrement importante avec plusieurs niveaux de stacking.

Supposons une architecture :

L1 → L2 → L3

Les prédictions temporelles OOF de L1 permettent de construire le dataset de L2.

Mais entraîner ensuite L2 sur l’intégralité de ce dataset puis utiliser ses prédictions in-sample pour entraîner L3 réintroduirait exactement le leakage supprimé entre L1 et L2.

La contrainte doit donc être récursive : Chaque niveau destiné à alimenter un niveau supérieur doit produire ses propres prédictions hors échantillon et hors futur.

Autrement dit, chaque frontière entre deux niveaux constitue une nouvelle frontière de validation.

C’est une propriété structurelle du stack, pas une étape de contrôle ajoutée après son entraînement.

---

9. Profondeur du stack et érosion de l’historique exploitable

La causalité stricte introduit un coût moins visible que le temps de calcul : une partie de l’historique ne peut pas être utilisée par les niveaux supérieurs.

Considérons plusieurs segments temporels :

A → B → C → D → E

Pour produire les OOF de premier niveau :

A       → predict B
A+B     → predict C
A+B+C   → predict D
A+B+C+D → predict E

Aucune véritable prédiction OOF future-only ne peut être générée pour A, puisqu’aucune période antérieure n’est disponible.

Le dataset L2 commence donc nécessairement plus tard que le dataset L1. Si L2 doit à son tour produire des OOF pour L3, une nouvelle portion de l’historique sera indisponible.

La profondeur du stack crée ainsi un arbitrage entre :

• capacité de combinaison
• profondeur historique disponible
• taille des fenêtres
• nombre de folds
• stabilité statistique des derniers niveaux

Le découpage OOF n’est donc pas un simple paramètre de validation. Il participe directement à la conception de l’architecture.

---

10. Des modèles OOF à l’inférence de production

Les modèles entraînés lors de la construction des folds temporels ont d’abord une fonction précise : produire les prédictions hors échantillon nécessaires à l’entraînement des niveaux suivants.

Cela ne signifie pas pour autant qu’ils doivent nécessairement disparaître une fois les datasets OOF construits.

Selon l’architecture retenue, plusieurs stratégies sont possibles pour l’inférence. Les modèles issus des folds peuvent notamment être conservés et leurs prédictions combinées, ou servir uniquement à la construction OOF avant qu’un modèle destiné à l’inférence soit entraîné sur un historique plus large.

Dans le premier cas, pour un niveau composé de plusieurs folds temporels, on obtient par exemple :

Niveau
├── modèle fold 1
├── modèle fold 2
├── modèle fold 3
├── ...
└── modèle fold N

Lors de la construction du dataset OOF, chaque modèle est soumis à une contrainte temporelle stricte : il ne peut produire des prédictions d’entraînement que pour des observations postérieures aux données sur lesquelles il a appris.

Pour une nouvelle observation située après l’ensemble de ces périodes historiques, plusieurs de ces modèles peuvent en revanche être utilisés simultanément et leurs sorties agrégées.

Les modèles ayant servi à construire les OOF peuvent ainsi, selon la stratégie retenue, devenir également des composants du pipeline d’inférence.

Ce choix présente notamment l’intérêt d’exploiter plusieurs modèles construits à différents points de l’historique plutôt que de considérer systématiquement les folds comme de simples artefacts temporaires de validation.

Il ne constitue cependant pas une obligation liée à la méthode OOF.

Une autre architecture peut parfaitement utiliser les folds uniquement pour produire les données d’entraînement hors échantillon, puis construire séparément le modèle qui sera utilisé lors de l’inférence.

La distinction importante est donc la suivante :

• la génération OOF détermine comment construire des prédictions historiques sans fuite d’information
• la stratégie d’inférence détermine quels modèles seront effectivement utilisés une fois le système déployé

Ces deux décisions sont liées, mais elles ne doivent pas être confondues.

Quelle que soit la stratégie retenue, une contrainte supplémentaire subsiste : les signaux utilisés pour entraîner un niveau supérieur doivent rester représentatifs de ceux qu’il recevra réellement lors de l’inférence.

Une différence importante entre ces deux situations peut introduire un décalage de distribution, même lorsque la causalité temporelle est parfaitement respectée.

L’absence de data leakage constitue donc une condition nécessaire à la validité du stack, mais elle ne dispense pas de vérifier la cohérence entre les conditions d’apprentissage et celles de production.

---

11. Calibration des modèles sur une période temporelle dédiée

La calibration n’intervient pas nécessairement uniquement à la sortie finale du système.

Lorsqu’un modèle produit un score auquel on souhaite donner une interprétation probabiliste, une étape de calibration peut lui être associée.

Il faut donc distinguer deux fonctions :

• le modèle, qui apprend à produire un signal utile à la prédiction ou au classement
• le calibrateur, qui apprend à associer une probabilité à ce signal

Conceptuellement :

données → modèle → score → calibrateur → probabilité

Tous les composants d’une architecture multi-niveaux n’ont cependant pas nécessairement besoin de produire des probabilités.

La calibration n’est donc ni une opération obligatoire à chaque niveau, ni nécessairement une transformation unique appliquée à la toute fin du stack. Elle peut être associée aux modèles dont les sorties nécessitent une interprétation probabiliste.

La calibration dépend du rôle du modèle

Dans une architecture composée de plusieurs modèles, certains signaux peuvent être utilisés directement par le niveau suivant tandis que d’autres nécessitent d’abord une calibration.

Le principe important n’est donc pas le nombre ou la position exacte des calibrateurs, mais leur fonction :

Transformer, lorsque cela est nécessaire, le signal produit par un modèle en une probabilité possédant une interprétation statistique.

Cette distinction permet également de ne pas confondre la génération OOF et la calibration. Les OOF répondent à une contrainte de validation hors échantillon, la calibration répond à une autre question : quelle probabilité peut-on raisonnablement associer au signal produit par le modèle ?

Pourquoi la calibration possède-t-elle sa propre période ?

Un score produit par un modèle n’est pas nécessairement une probabilité. Deux candidats obtenant respectivement :

score A = 0,8
score B = 0,4

peuvent être correctement ordonnés sans que ces valeurs signifient respectivement 80% et 40% de probabilité de réalisation.

La calibration apprend précisément cette correspondance entre le signal produit par le modèle et la fréquence réellement observée.

Elle nécessite pour cela deux informations :

prédiction du modèle + résultat réellement observé

Le calibrateur ne doit pas être ajusté sur des prédictions in-sample, c’est-à-dire produites par un modèle ayant déjà utilisé les observations concernées pour son apprentissage.

La raison est simple : un modèle est généralement meilleur sur les données qu’il a déjà vues que sur de nouvelles données.

Prenons un exemple simplifié.

Supposons qu’un certain niveau de score corresponde à :

80% de réussite
sur les données utilisées pour entraîner le modèle

mais

65% de réussite
sur de nouvelles observations

Une calibration construite à partir des premières données pourrait associer ce score à une probabilité proche de 80%, alors que son comportement sur des observations réellement nouvelles se situe plutôt autour de 65%.

Le calibrateur apprend donc lui aussi à partir des données. Il doit être ajusté à partir de prédictions hors échantillon, produites sur des observations que le modèle concerné n’a pas utilisées pour son apprentissage.

Plusieurs protocoles permettent de respecter cette contrainte. Dans le protocole présenté ici, une période temporelle dédiée est réservée à la calibration, après la période utilisée pour entraîner le modèle.

Le modèle est d’abord entraîné sur son historique autorisé. Il produit ensuite des prédictions sur une période ultérieure qu’il n’a pas utilisée pour apprendre. Ce sont ces prédictions, associées aux résultats réellement observés, qui permettent d’ajuster le calibrateur.

Le calibrateur apprend ainsi à interpréter le comportement du modèle dans une situation beaucoup plus proche de celle qui nous intéresse réellement : lorsqu’il rencontre de nouvelles observations.

La séparation temporelle ne protège donc pas uniquement l’entraînement du modèle contre le data leakage. Elle évite également de construire une calibration artificiellement optimiste.

La calibration doit correspondre au signal réellement utilisé

L’isolation temporelle ne suffit cependant pas à elle seule.

Le calibrateur apprend une relation :

signal du modèle → probabilité observée

Le signal utilisé pour l’entraîner doit donc rester représentatif de celui qu’il devra interpréter lors de l’inférence.

Si la manière de produire ce signal change fortement entre calibration et production, la relation apprise peut ne plus être valable de la même manière.

Une modification du modèle, de son historique d’entraînement, de la manière dont plusieurs sorties sont combinées ou d’une transformation située en amont peut par exemple modifier la distribution des scores reçus par le calibrateur.

Deux propriétés différentes doivent donc être préservées :

La calibration doit être apprise à partir de prédictions hors échantillon, produites sur des observations que le modèle concerné n’a pas utilisées pour son apprentissage.

et :

Le signal utilisé pour apprendre la calibration doit rester représentatif de celui qui sera produit lors de l’inférence.

La première protège contre une calibration artificiellement favorable parce qu’elle aurait été construite à partir de prédictions in-sample.

La seconde protège contre un décalage entre les conditions dans lesquelles le calibrateur a appris et celles dans lesquelles il sera réellement utilisé.

Un composant appris à part entière

Le calibrateur doit finalement être considéré comme un composant appris du système, au même titre que les autres transformations dont les paramètres sont estimés à partir des données.

Il possède :

• des données d’apprentissage
• une frontière temporelle
• des paramètres appris
• une relation avec le signal qu’il transforme
• et des conditions d’utilisation qui doivent rester cohérentes avec celles de son entraînement

Le nombre et la position des calibrateurs dépendent donc du rôle des différents modèles et de la nature de leurs sorties, et non de la structure du stack elle-même : rien n’impose un calibrateur par fold ni, à l’inverse, une unique calibration finale pour l’ensemble du stack.

La règle générale est plus simple :

Toute calibration doit être apprise sur des prédictions hors échantillon et représentatives du signal qu’elle devra interpréter après déploiement.

La calibration constitue ainsi une frontière d’apprentissage supplémentaire du système, qui doit être validée avec la même rigueur que les modèles qu’elle accompagne.

---

12. Réutilisation du jeu de test et biais de sélection

Même lorsqu’aucune donnée future ne traverse le pipeline, une autre source de biais apparaît lorsque de nombreuses expériences sont comparées sur la même période de test.

Le mécanisme ne constitue pas un data leakage au sens strict : le modèle n’accède jamais aux données de test pendant son entraînement.

Le biais vient de la sélection des expériences.

Supposons que plusieurs dizaines de variantes soient évaluées sur le même échantillon :

Modèle A             → 35,8 %
Modèle B             → 35,9 %
Nouvelle feature     → 36,0 %
Modèle C             → 35,7 %
Nouvelle combinaison → 36,1 %
...

Chaque résultat influence la décision suivante : conserver une feature, abandonner une architecture, modifier un hyperparamètre ou explorer une nouvelle combinaison.

À mesure que le nombre d’expériences augmente, le risque augmente également de sélectionner une configuration qui exploite involontairement les particularités statistiques de cette période précise, plutôt qu’une amélioration réellement généralisable.

C’est pourquoi une faible progression sur le test n’est pas considérée, à elle seule, comme une preuve suffisante.

Elle doit être replacée dans le contexte du nombre d’expériences réalisées et confrontée à d’autres éléments : stabilité temporelle, comparaison appariée, bootstrap, cohérence sur différents segments et comportement du système complet.

Le jeu de test reste ainsi une mesure hors entraînement du modèle, mais sa réutilisation répétée impose de traiter les petits gains avec prudence.

---

13. Robustesse statistique des gains observés

Une validation temporelle rigoureuse garantit que les modèles sont comparés dans des conditions réalistes. Elle ne garantit pas pour autant que chaque différence observée entre deux modèles corresponde à une amélioration réelle.

Supposons que deux modèles soient évalués exactement sur les mêmes événements :

Modèle A : 35,7%
Modèle B : 36,1%

Sur cette période, B est effectivement meilleur de 0,4 point.

Mais une autre question reste ouverte :

B est-il réellement meilleur, ou avons-nous simplement évalué les deux modèles sur une période qui lui était légèrement plus favorable ?

Certains événements avantagent A, d’autres B. Lorsque l’écart final est faible, quelques événements particulièrement favorables à l’un des modèles peuvent suffire à inverser leur classement.

Il faut donc mesurer non seulement l’écart moyen, mais également la stabilité de cet écart.

Comparer les modèles sur les mêmes événements

Les comparaisons sont réalisées de manière appariée : A et B sont toujours évalués sur exactement les mêmes événements.

L’événement reste ici l’unité indivisible du problème.

On peut alors utiliser une procédure de bootstrap pour simuler de nombreux autres échantillons à partir de la période observée.

Le principe consiste à tirer aléatoirement des événements, avec remise :

Échantillon original :

[E1, E2, E3, E4, E5, E6, E7, ...]


Quelques rééchantillonnages :

Bootstrap 1 : [E4, E7, E7, E12, E2, ...]
Bootstrap 2 : [E3, E1, E9, E9, E14, ...]
Bootstrap 3 : [E8, E2, E4, E4, E11, ...]
...

Certains événements apparaissent plusieurs fois, d’autres pas du tout.

Pour chacun de ces échantillons, les performances des deux modèles sont recalculées puis comparées :

Δ = performance(B) - performance(A)

Après un grand nombre de répétitions, on ne dispose plus d’un seul écart de +0,4 point, mais d’une distribution des écarts possibles.

Conceptuellement :

Ce que cette distribution permet de vérifier

Si B possède un avantage robuste, la grande majorité des rééchantillonnages doivent continuer à favoriser B :

À l’inverse, si la distribution traverse largement zéro :

cela signifie que de petites modifications dans la composition de l’échantillon suffisent régulièrement à faire disparaître l’avantage de B, voire à rendre A meilleur.

Le résultat :

B = 36,1 %
A = 35,7 %

reste parfaitement exact pour la période mesurée.

Ce que le bootstrap remet en question n’est pas cette mesure, mais la solidité de la conclusion que l’on souhaite en tirer.

Une différence mesurée n’est pas nécessairement une amélioration exploitable

Cette distinction est particulièrement importante lorsqu’une architecture est déjà mature et que les gains recherchés deviennent faibles.

Un nouveau modèle peut obtenir une meilleure métrique moyenne sans que l’écart soit suffisamment stable pour justifier :

• davantage de complexité
• un temps d’entraînement supérieur
• une inférence plus coûteuse
• de nouveaux artefacts à maintenir
• ou le remplacement du modèle actuellement en production

La décision de promotion ne repose donc pas uniquement sur :

metric(B) > metric(A)

mais sur une question plus exigeante :

Les données fournissent-elles suffisamment d’éléments pour considérer que l’avantage observé est robuste ?

Le bootstrap apparié constitue l’un des outils utilisés pour répondre à cette question.

Il complète la validation temporelle : la première cherche à reproduire les conditions réelles d’inférence, le second mesure à quel point la conclusion tirée de cette évaluation dépend de l’échantillon particulier qui a été observé.

---

14. Évaluer un ranking sous plusieurs angles

La qualité d’un système de ranking ne peut pas être résumée par une métrique unique.

Deux systèmes peuvent obtenir des performances globales proches tout en se comportant très différemment : l’un peut être particulièrement efficace sur les premières positions, tandis que l’autre reproduit plus fidèlement l’ordre général des candidats.

L’évaluation doit donc observer plusieurs propriétés complémentaires.

Qualité des premières positions

Dans de nombreux problèmes de ranking, toutes les positions n’ont pas la même importance.

Une erreur entre les deux premiers candidats peut avoir beaucoup plus de conséquences qu’une inversion entre deux candidats situés en bas du classement.

Des métriques comme le HitRate@K permettent de mesurer directement la capacité du système à retrouver les candidats pertinents parmi ses premières positions.

Le NDCG@K va plus loin en tenant compte à la fois de la pertinence et de la position : une bonne réponse placée très haut dans le classement est davantage valorisée que la même réponse située plus bas.

Ces métriques répondent donc à une question ciblée :

Le système place-t-il les candidats importants suffisamment haut dans le classement ?

Cohérence du classement dans son ensemble

Se concentrer uniquement sur les premières positions peut cependant masquer le comportement du reste du classement.

Des métriques fondées sur les rangs permettent d’évaluer si l’ordre produit reste globalement cohérent avec l’ordre réellement observé.

Un système peut ainsi être très performant pour identifier le premier candidat tout en ordonnant assez mal les suivants.

À l’inverse, un autre peut produire un classement globalement très cohérent sans être systématiquement meilleur sur la première position.

Ces deux comportements ne sont pas équivalents et peuvent difficilement être décrits par un score unique.

Qualité des probabilités lorsqu’elles existent

Lorsqu’un système produit également des probabilités, une troisième propriété doit être évaluée : leur calibration.

Une probabilité de 0,8 ne signifie réellement « 80% » que si, sur un nombre suffisamment important de situations comparables, l’événement associé se réalise effectivement environ huit fois sur dix.

Cette propriété peut être étudiée avec des outils tels que :

• le Brier Score
• les courbes de calibration
• la comparaison entre probabilités annoncées et fréquences réellement observées

Il s’agit d’une dimension différente de la qualité du classement.

Un système peut parfaitement ordonner les candidats tout en étant trop confiant dans ses probabilités. À l’inverse, des probabilités correctement calibrées ne garantissent pas que les meilleurs candidats soient toujours placés dans le bon ordre.

Évaluer des propriétés plutôt que chercher un score universel

L’objectif n’est donc pas de trouver une métrique capable de résumer à elle seule toute la qualité du système.

Il est de vérifier plusieurs propriétés :

Ces mesures ne sont pas concurrentes. Elles décrivent des dimensions différentes du même résultat.

Cette approche est particulièrement importante lorsqu’il faut comparer deux configurations proches. Une amélioration sur une métrique peut parfois masquer une dégradation sur une autre.

La comparaison doit donc être effectuée en fonction des propriétés que le système doit réellement préserver, plutôt qu’en cherchant à réduire son comportement à un unique score.

Évaluer un système de ranking revient moins à demander « quel est son score ? » qu’à déterminer précisément sur quelles dimensions il est meilleur, équivalent ou moins performant qu’une autre configuration.

---

15. Coût computationnel du protocole

La validation temporelle multi-niveaux a un coût computationnel important : un « modèle » ne correspond plus nécessairement à un unique entraînement.

Pour produire des prédictions OOF sans fuite temporelle, chaque modèle doit être entraîné successivement sur plusieurs fenêtres historiques :

Un modèle
    │
    ├── entraînement fold 1
    ├── entraînement fold 2
    ├── entraînement fold 3
    ├── ...
    └── entraînement fold N

Cette opération doit être répétée pour les différents modèles concernés et, dans une architecture multi-niveaux, pour chaque niveau qui doit à son tour produire des prédictions OOF destinées au suivant.

Le coût global ressemble donc davantage à :

N folds × modèles du niveau 1
+
calibrations associées aux modèles du niveau 1
+
N folds × modèles du niveau 2
+
calibrations associées aux modèles du niveau 2
+
N folds × modèles du niveau k
+
calibrations associées aux modèles du niveau k

ou en notation courte :

Σₖ(entraînements OOF du niveau k + calibrations associées au niveau k)

La calibration n’est pas une unique opération ajoutée à la fin de cette chaîne. Elle est associée aux modèles qui en nécessitent une et possède son propre processus d’apprentissage. Dans le protocole présenté ici, celui-ci repose sur une période temporelle dédiée.

À cela s’ajoute la recherche d’hyperparamètres. Lorsqu’une configuration doit être évaluée dans des conditions temporelles réalistes, une seule expérience peut donc nécessiter plusieurs dizaines d’entraînements avant même de pouvoir être comparée à la référence.

Le coût de la validation fait partie du coût du modèle

Il serait possible de réduire fortement cette charge en utilisant moins de folds, en réutilisant des prédictions produites dans des conditions différentes ou en simplifiant certaines étapes de validation.

Mais une telle optimisation n’est pertinente que si elle conserve les propriétés que le protocole cherche précisément à garantir.

Le compromis n’est donc pas simplement :

plus de calcul ↔ moins de calcul

mais plutôt :

coût computationnel
        ↕
fidélité de la simulation temporelle
        ↕
quantité de données exploitable

Le nombre et la taille des folds influencent par exemple simultanément le temps d’entraînement, la quantité d’historique disponible pour chaque modèle et la quantité de prédictions OOF pouvant être transmise aux niveaux suivants.

Ces paramètres doivent donc être considérés comme des choix d’architecture, et non uniquement comme des moyens d’accélérer ou de ralentir une expérience.

Recherche et production n’ont pas exactement le même coût

Le coût doit également être distingué selon le contexte.

Pendant la recherche, une nouvelle hypothèse peut nécessiter de reconstruire une partie importante de la chaîne afin de mesurer son impact dans des conditions comparables à la référence.

En production, les artefacts nécessaires à l’inférence ont déjà été construits et validés. Le coût de construction du protocole est donc principalement supporté pendant l’entraînement et l’expérimentation, le coût quotidien dépend ensuite de la stratégie d’inférence retenue et du nombre de modèles effectivement exécutés.

Cette distinction est importante : la complexité computationnelle d’un système ML ne se mesure pas uniquement au coût d’une prédiction en production. Elle inclut également le coût nécessaire pour produire une évaluation suffisamment fiable pour décider qu’une nouvelle version mérite d’y être déployée.

---

16. Principes de conception du protocole de validation

L’architecture repose finalement sur plusieurs invariants. Ils ne constituent pas des précautions ajoutées après l’entraînement : ils déterminent directement la construction des datasets, des folds et des différents niveaux du stack.

1. Causalité temporelle stricte Toute prédiction associée à un instant t est produite par un modèle entraîné exclusivement sur des observations antérieures à t.

2. Intégrité des groupes L’événement constitue l’unité indivisible de validation. L’ensemble de ses candidats appartient au même segment temporel et au même fold.

3. Feature engineering causal Toute statistique historique, agrégation ou feature dépendante des données est calculée uniquement à partir des informations qui auraient réellement été disponibles au moment simulé.

4. Stacking exclusivement Out-of-Fold Un niveau du stack n’est jamais entraîné sur des prédictions produites par un modèle ayant déjà vu les observations concernées. Ses entrées sont construites à partir de prédictions OOF respectant elles-mêmes la causalité temporelle.

5. Propagation de la contrainte OOF entre niveaux Cette propriété est récursive : lorsqu’un niveau alimente le suivant, il doit à son tour produire des prédictions hors échantillon et hors futur. Chaque frontière du stack constitue ainsi une nouvelle frontière de validation.

6. Isolation de toute transformation apprise Toute opération dont les paramètres sont estimés à partir des données respecte une frontière temporelle adaptée à son rôle. Les transformations liées à l’entraînement sont ajustées uniquement sur les données autorisées. Lorsqu’une calibration est nécessaire, elle est apprise à partir de prédictions hors échantillon, dans le protocole présenté ici, une période temporelle ultérieure lui est dédiée.

7. Cohérence entre construction OOF et inférence de production La stratégie d’inférence peut conserver les modèles issus des folds ou utiliser des modèles construits spécifiquement pour la production. Dans tous les cas, les signaux reçus par les niveaux supérieurs doivent rester représentatifs de ceux utilisés pour leur apprentissage.

8. Prise en compte du biais lié à la réutilisation du test Le jeu de test reste entièrement exclu de l’entraînement des modèles. Sa consultation répétée au cours de nombreuses expériences peut néanmoins introduire un biais de sélection : une configuration peut finir par être favorisée par les particularités statistiques de cette période. Les faibles gains observés sont donc interprétés dans le contexte du nombre d’expériences réalisées et de leur stabilité.

9. Comparaisons appariées au niveau de l’événement Les modèles sont comparés sur exactement les mêmes événements. Lorsque les écarts sont faibles, leur variabilité est estimée afin de distinguer une amélioration suffisamment stable d’une différence pouvant s’expliquer par la composition particulière de l’échantillon.

10. Promotion fondée sur la robustesse du gain Une amélioration ponctuelle d’une métrique n’est pas considérée comme suffisante. Une nouvelle configuration doit conserver son avantage dans le protocole temporel complet, rester cohérente sur les propriétés évaluées et apporter un bénéfice suffisant pour justifier son éventuel coût supplémentaire.

Ces invariants ont une conséquence directe : le protocole de validation fait partie de l’architecture du système.

Modifier la manière de construire les features historiques, de produire les OOF, de définir les frontières temporelles, de calibrer les modèles ou de constituer les groupes de validation revient à modifier l’expérience elle-même.

Les métriques obtenues avant et après un tel changement ne sont donc pas nécessairement directement comparables.

---

17. Le protocole de validation comme composant de l’architecture

Dans un système temporel multi-niveaux, la performance d’un modèle ne peut pas être interprétée indépendamment du protocole qui l’a produite.

Deux résultats ne sont réellement comparables que si l’on connaît notamment :

• les frontières temporelles utilisées
• l’unité de regroupement des folds
• la construction des features historiques
• le périmètre d’apprentissage des transformations
• la méthode de génération des OOF
• la propagation de ces OOF entre les niveaux
• l’isolation de la calibration
• l’utilisation faite de la période de test
• l’incertitude autour des écarts mesurés

Cette propriété change la manière de considérer la validation. Elle n’est plus une étape exécutée après la conception du modèle, elle devient une contrainte qui traverse l’ensemble du système.

Le protocole détermine ce que signifie réellement une prédiction historique et, par conséquent, ce que mesure chaque métrique.

---

18. Conclusion

Sur un modèle temporel isolé, éviter le data leakage peut se résumer à une règle simple : entraîner sur le passé et évaluer sur le futur.

Dans un système de ranking combinant feature engineering historique, plusieurs modèles, stacking et calibration, cette règle ne peut plus être appliquée uniquement au découpage initial des données. Elle doit être préservée à travers l’ensemble de l’architecture.

Chaque niveau qui apprend, transforme ou transmet de l’information constitue une nouvelle frontière à contrôler.

Les prédictions utilisées pour construire un niveau supérieur doivent avoir été produites hors échantillon et sans accès au futur. Les transformations apprises doivent respecter leur propre périmètre temporel. Les calibrateurs doivent être ajustés à partir de prédictions hors échantillon représentatives des conditions d’inférence. Dans le protocole présenté ici, la calibration repose pour cela sur des périodes temporelles dédiées. Enfin, les différents niveaux comme le système assemblé doivent être évalués dans des conditions cohérentes avec leur utilisation réelle.

Derrière ces contraintes se trouve toujours le même invariant :

À chaque instant simulé, l’état complet du système doit pouvoir être reconstruit uniquement à partir des informations qui auraient réellement été disponibles à cet instant.

Cette discipline a un coût. La génération des OOF multiplie les entraînements, chaque niveau supplémentaire réduit une partie de l’historique exploitable par le suivant, la calibration introduit ses propres données et artefacts, et l’évaluation statistique augmente encore le coût expérimental.

Mais cette complexité n’est pas gratuite : elle permet de savoir ce que mesurent réellement les performances obtenues.

Un score légèrement supérieur n’a que peu de valeur si les données ayant permis de l’obtenir contiennent indirectement de l’information future. De la même manière, une amélioration observée sur une période donnée ne suffit pas nécessairement lorsqu’elle disparaît au moindre changement d’échantillon.

La validation doit donc répondre à deux questions complémentaires :

Le système aurait-il pu produire cette prédiction avec les seules informations disponibles à cet instant ?

et :

L’amélioration mesurée est-elle suffisamment robuste pour être considérée comme un progrès réel ?

C’est cette combinaison entre causalité temporelle, construction OOF, calibration hors échantillon et robustesse statistique qui permet de transformer une succession de métriques en une évaluation réellement exploitable.

Dans un système ML temporel multi-niveaux, le protocole de validation n’est donc pas une procédure appliquée après la conception de l’architecture.

Il en fait partie.