Aller au contenu

Hors échantillon

Évaluation sur des observations non employées pendant le développement : séparation temporelle, intégrité du test, purging, embargo et walk-forward sans raccourci universel.

À qui s’adresse cette page — À quiconque développe ou évalue des stratégies systématiques et doit distinguer une mesure obtenue sur des données réellement non consultées d’une simple prolongation du processus d’optimisation.

Un test hors échantillon (out of sample, OOS) évalue une spécification déjà définie sur des données qui n’ont pas servi à choisir ses règles, variables, paramètres ou critères de sélection. Il mesure la capacité à généraliser au-delà de l’échantillon de développement. Il ne démontre pas que le comportement se poursuivra : il réduit une forme particulière d’optimisme, à condition que la séparation soit réelle.

L’intégrité de l’OOS concerne le flux des décisions, pas seulement une colonne de dates. Si le résultat du test conduit à modifier le modèle, ce segment est désormais une information de développement. La version modifiée exige un nouveau test non consulté ; il serait incorrect d’ajuster la stratégie et de continuer à qualifier les mêmes données de « hors échantillon ».

Un segment OOS réutilisé pour choisir features, paramètres ou règles perd donc son statut de test jamais vu, même s’il conserve la même étiquette.

Découpages temporels et walk-forwardÉchantillon réservé, fenêtre glissante et fenêtre croissante répondent à des questions différentes. Les proportions et fenêtres sont illustratives ; la dépendance, l’horizon des étiquettes et le régime guident la conception.Découpages temporels et walk-forwardÉchantillon réservé, fenêtre glissante et fenêtre croissante répondent à des questions différentesLes proportions et fenêtres sont illustratives ; la dépendance, l’horizon des étiquettes et le régime guident la conception.Échantillon réservé fixeLe développement et l’évaluation finale restentséparés ; chaque consultation consomme le test.Fenêtre glissanteL’entraînement et le test avancent avec unemémoire de longueur constante.Fenêtre croissanteL’entraînement accumule l’historique tandis quechaque test reste ultérieur dans le temps.Test final intactPréserve une vérification distincte de lasélection itérative lorsque l’échantillon lepermet.Cyclepedia · schéma pédagogique conditionnel, ni prévision ni promesse
Les étiquettes dépendent de l’usage : une période ne reste un test final que tant qu’elle n’oriente aucun choix du modèle.

In-sample, validation, test et forward ne sont pas synonymes

Bloc Usage autorisé Ce qui le contamine
Training / in-sample estimation et ajustement des paramètres il n’est pas destiné à une évaluation impartiale
Validation choix entre spécifications et hyperparamètres les consultations répétées sont admises, mais doivent être comptées
Test final OOS évaluation finale d’une spécification gelée toute modification guidée par son résultat
Walk-forward séquence de fits et de tests ordonnée dans le temps règles remaniées après observation de toute la séquence
Forward ou paper test observation ultérieure, souvent sans argent réel différences entre exécutions simulées, fonctionnement et capital réel

Un OOS peut être un holdout final, une fenêtre d’une procédure rolling ou une partie de validation croisée temporelle. Son nom ne précise pas à lui seul le plan. Il faut documenter largeur des fenêtres, ordre, horizon des labels, fréquence de réajustement et nombre total de décisions prises sur les résultats.

Le découpage n’a pas de proportion universelle

Il n’existe pas de règle générale telle que « 70 % développement, 30 % test ». Le choix dépend de la quantité et de la qualité des données, de la fréquence, de l’horizon de prévision, de la stabilité du processus, du nombre de paramètres et de la nécessité d’observer plusieurs régimes. Un test très long réduit les données de développement ; un test trop court peut produire des estimations imprécises ou ne représenter qu’un seul régime.

Dans les séries temporelles, l’ordre compte. Un découpage aléatoire standard peut faire entrer dans le training des observations fortement liées à celles du test. Il ne faut toutefois pas le déclarer universellement invalide : son adéquation dépend du problème et des hypothèses de dépendance. En finance, autocorrélation, features construites sur fenêtres et labels qui se chevauchent exigent souvent des découpages bloqués, rolling ou des techniques spécifiques de séparation.

Purging et embargo

Lorsqu’un label utilise un intervalle futur — par exemple le rendement entre l’ouverture et la clôture d’une position — une observation de training peut partager une partie du même intervalle informationnel avec une observation de test. Le purging retire du training les observations dont les intervalles de label chevauchent le test. L’embargo ajoute une zone tampon temporelle pour réduire les dépendances résiduelles autour de la frontière.

Le tampon doit être justifié par l’horizon, la disponibilité des données et la structure de dépendance ; un pourcentage fixe n’est pas un principe général. Purging et embargo ne corrigent ni biais de survie, ni données révisées, ni coûts irréalistes, ni tests multiples, ni changements de régime.

Protocole de validation

  1. Définir l’unité informationnelle. Préciser les horodatages des features, le début et la fin du label, la fréquence et les chevauchements possibles.
  2. Séparer les rôles. Affecter les données au training, à la validation et au test avant de voir les métriques finales ; ne pas appeler « test » le bloc employé pour le tuning.
  3. Choisir le plan. Justifier holdout, rolling origin, fenêtre expanding ou rolling, validation croisée bloquée et éventuels purge ou embargo.
  4. Geler la chaîne. Versionner transformations, features, univers, hyperparamètres, coûts, benchmark et règle de décision.
  5. Enregistrer tous les essais. Compter modèles, graines, périodes, filtres et métriques consultés, pas seulement la variante publiée.
  6. Exécuter le test final. Calculer métriques nettes, incertitude et comparaison au benchmark sans rouvrir la sélection.
  7. Qualifier le résultat. « Non concluant », « incohérent avec l’hypothèse » et « compatible avec une vérification supplémentaire » sont plus justes qu’un pass/fail fondé sur un seuil universel.
  8. Documenter toute réutilisation. Si le résultat oriente une modification, transférer formellement cette période dans le patrimoine de développement.

Walk-forward et test final

Dans le walk-forward, le modèle est estimé en n’utilisant que les données antérieures à chaque fenêtre de test. La procédure imite des réajustements successifs et montre comment le résultat varie dans le temps. Elle doit préciser si la fenêtre de training s’élargit ou se déplace, le pas d’avancement, l’horizon testé et la cadence de recalibration.

La concaténation des fenêtres ne constitue pas automatiquement un historique pur. Si, après avoir observé l’ensemble, on modifie la famille du modèle, les features, les fenêtres ou les règles d’arrêt, toute la séquence a participé au développement. Lorsque c’est possible, une procédure de sélection interne peut être complétée par un holdout final externe jamais consulté.

Exemple illustratif

Exemple explicitement illustratif — Un modèle mensuel est réestimé avec une fenêtre mobile et évalué sur le mois suivant. Les labels des positions peuvent s’étendre sur plusieurs jours : avant chaque test, les observations de training qui en croisent l’intervalle sont supprimées. Le chercheur compare quatre familles de modèles dans la validation interne et les enregistre toutes. Un bloc temporel ultérieur reste scellé pour la décision finale. Les durées appartiennent à l’exemple et ne sont pas des proportions recommandées.

Le résultat doit présenter la dispersion entre fenêtres, les coûts et les expositions, et non seulement une métrique agrégée. Une moyenne favorable peut masquer que presque toute la valeur provient d’une période unique.

Limites

  • Un holdout unique peut être fortement influencé par le régime qu’il contient.
  • Plusieurs réserves de données ne créent pas d’information indépendante nouvelle.
  • La non-stationnarité peut rendre training et test peu représentatifs.
  • Le choix du plan de validation est lui-même un choix de recherche et doit figurer dans le registre des essais.
  • OOS, purging et walk-forward ne remplacent ni données point-in-time, ni simulation causale, ni coûts plausibles, ni contrôle du data snooping.

Références

Liens connexes