Un agent IA de stratégie peut produire un backtest valide tout en utilisant des informations qui n’existaient pas au moment où ses transactions étaient censées avoir lieu. Le code s’exécute. La courbe de capital paraît plausible. Le signal peut même être pertinent. Pourtant, un horodatage, une jointure ou un champ de données révisé lui a discrètement fourni la réponse de demain.
Pour y remédier, il faut intégrer la date de disponibilité au contrat de recherche. Pour chaque donnée d’entrée, il faut répondre clairement à deux questions : à quelle période cette valeur se rapporte-t-elle, et à partir de quand la stratégie aurait-elle pu la connaître ?
À quoi ressemble le biais d’anticipation dans une stratégie générée par l’IA ?
Le cas évident, c’est un signal calculé à partir de la clôture de la bougie, suivi d’une exécution à ce même cours de clôture. Si la stratégie a besoin du cours de clôture pour prendre sa décision, elle ne peut pas aussi passer un ordre à ce cours. Mais les agents créent souvent des cas plus subtils en joignant des sources de données ou en choisissant des valeurs par défaut pratiques.
Supposons qu’un modèle calcule une moyenne mobile sur 20 bougies à la clôture de chaque minute et prenne une position lorsque la clôture la franchit. Si le backtest exécute l’ordre à cette même clôture, il utilise le dernier échange de la bougie avant que la stratégie ait pu en disposer. Décaler l’ordre à l’ouverture de la bougie suivante peut être une approximation raisonnable, même si un ordre au marché doit aussi tenir compte des frais et de l’impact.
Remplaçons maintenant cette variable par une donnée fondamentale quotidienne sur une action ou un instantané de l’intérêt ouvert en crypto. La date de la ligne peut indiquer lundi, mais la valeur a peut-être été publiée après la clôture de lundi, ou corrigée par la suite. Une date n’est pas un horodatage de disponibilité.
Comment horodater les données d’entrée d’une stratégie ?
Conservez au moins trois horodatages lorsque la source le permet : la période à laquelle une valeur se rapporte, l’heure à laquelle l’éditeur l’a publiée et l’heure à laquelle votre système l’a reçue. À l’heure de la décision, l’ensemble d’informations de la stratégie ne peut inclure que les valeurs déjà disponibles.
| Champ | Question correspondante | Piège courant |
|---|---|---|
| Heure de l’événement | Quand l’événement de marché a-t-il eu lieu ? | Utiliser la clôture d’une bougie avant qu’elle soit terminée |
| Heure de publication | Quand la source a-t-elle publié cette valeur ? | Traiter une étiquette de fin de journée comme une publication à l’ouverture |
| Heure d’ingestion | Quand le système de recherche a-t-il pu la traiter ? | Ignorer les retards du fournisseur ou du pipeline |
| Heure de révision | Quand cette version a-t-elle été enregistrée ou corrigée ? | Rétroalimenter l’historique révisé comme s’il s’agissait des données originales |
Pour une stratégie à 1 minute, un retard d’une seconde n’est pas forcément négligeable. Son importance dépend du moment où la décision est prise et des données utilisées par le signal. Si la donnée d’entrée est une statistique horaire calculée sur une période terminée, l’effet peut être minime. S’il s’agit d’un déséquilibre du carnet d’ordres observé juste avant l’ordre, il peut inverser la transaction.
Un stockage de données à date donnée peut-il empêcher les fuites ?
Oui, si « à date donnée » signifie qu’on peut récupérer la valeur connue à un moment de décision historique, y compris la version alors en vigueur. Une table qui contient simplement des dates historiques peut malgré tout inclure les valeurs corrigées aujourd’hui pour ces dates.
Pour chaque enregistrement, conservez un intervalle de validité et un horodatage de disponibilité, et gardez les révisions au lieu de les écraser. Rendez ensuite les requêtes historiques explicites : renvoyez la dernière version disponible à l’heure simulée de la décision. C’est particulièrement important pour les données fondamentales, la composition des indices, les publications économiques et les jeux de données nettoyés par les fournisseurs.
Il y a aussi un détail opérationnel peu reluisant : un horodatage de publication parfait ne sert à rien si le traitement d’ingestion a pris 20 minutes de retard. Si le stockage historique ne conserve pas l’heure d’ingestion, appliquez un délai prudent et indiquez-le. Une précision que la source n’a jamais enregistrée ne sert qu’à faire joli.
Quels contrôles détectent le biais d’anticipation avant le trading simulé ?
Demandez à l’agent de recherche de produire, en plus du backtest, une chronologie des variables et des ordres. Pour chaque décision, consignez l’heure de disponibilité la plus récente de la source pour chaque variable, l’heure de décision, l’heure d’envoi de l’ordre et l’heure d’exécution modélisée. Rejetez toute ligne où une donnée d’entrée est arrivée après la décision.
- Décalez les signaux d’une bougie et comparez les résultats. Une forte dégradation peut révéler une dépendance au calendrier clôture à clôture, mais il s’agit d’un diagnostic, pas d’une preuve de fuite.
- Tronquez chaque source à une date historique donnée, relancez le pipeline et comparez les variables obtenues aux variables historiques stockées.
- Remplacez une variable suspecte par une constante. Si les performances restent presque identiques, vérifiez si le code a vraiment utilisé la série prévue.
- Faites passer une variable future délibérément impossible dans le pipeline. La validation doit échouer clairement lorsque son heure de disponibilité est postérieure à l’heure de décision.
Ces contrôles ne certifient pas une stratégie. Ils rendent visibles certaines hypothèses de calendrier et détectent les violations courantes.
Le trading simulé prouve-t-il que le backtest ne comportait aucune fuite ?
Non. Le trading simulé peut révéler qu’un flux de données en direct arrive en retard, est incomplet ou n’est pas aligné comme le flux historique. Il ne peut pas établir que les variables d’entraînement historiques correspondaient aux informations disponibles à l’époque. Un modèle peut aussi cesser de profiter d’une fuite simplement parce que l’avenir qu’il a vu par accident est devenu le présent.
Utilisez le trading simulé pour vérifier la cohérence : comparez les valeurs des variables en direct, les horodatages de décision, la génération des ordres et les exécutions modélisées avec les définitions du backtest. En cas d’écart, remontez à la donnée d’entrée précise et à son horloge. Une équipe d’agents capable d’expliquer l’ensemble d’informations associé à chaque décision mène des recherches utiles. Une équipe qui ne peut montrer qu’une courbe régulière a omis l’audit le plus difficile.
← Tous les articles
