Un agent de stratégie peut contaminer un jeu de test sans qu’une seule ligne de test soit intégrée à un entraînement. Si l’agent voit le score du test, modifie un paramètre et relance une exécution, ce score a déjà influencé la stratégie. Le code peut qualifier la période de « hors échantillon ». Le processus de recherche l’a intégrée à l’exploration.
J’ai vu cela se produire par commodité : un agent lance un lot d’expériences, lit un tableau récapitulatif, puis propose une petite amélioration. Personne ne lui a demandé d’ajuster le modèle sur le jeu de réserve. La boucle de rétroaction s’en est chargée.
Erreur 1 : laisser l’agent consulter les résultats après chaque exécution
Le problème se manifeste généralement par un Sharpe de test qui grimpe par petits paliers réguliers. L’agent essaie 30 variantes, garde la meilleure, puis en teste 30 autres autour de celle-ci. Chaque modification prise isolément semble raisonnable. Ensemble, elles transforment la période de test en objectif d’optimisation.
Prenons un exemple simplifié. Supposons que la stratégie n’ait aucun avantage réel et que vous testiez 100 variantes indépendantes sur un jeu de réserve. En sélectionnant le Sharpe le plus élevé, vous pouvez tout à fait obtenir par hasard un résultat flatteur. Dans la plupart des recherches de stratégies, les variantes ne seront pas vraiment indépendantes, mais cela ne sauve pas le processus : une rétroaction répétée favorise toujours les réglages qui s’adaptent par chance aux particularités du jeu de réserve.
Placez le jeu de réserve derrière une barrière d’accès aux résultats. L’agent peut développer la stratégie à partir des périodes d’entraînement et de validation, mais ne peut pas récupérer les métriques ni les graphiques du jeu de réserve. Effectuez l’évaluation finale dans une tâche distincte, une seule fois, après avoir figé les choix de recherche, puis consignez la version de la stratégie et l’instantané des données avec le résultat.
Erreur 2 : qualifier de « nouvelle » toute période ultérieure
Une plage de dates n’est pas nouvelle simplement parce qu’elle vient après la fenêtre d’entraînement. Si l’agent a vu un score pour cette plage, ou si une personne s’est servie de son drawdown pour choisir une autre caractéristique, cette plage fait désormais partie de la boucle de rétroaction.
| Période | Utilisation autorisée | Ce qui en change le statut |
|---|---|---|
| Entraînement | Ajuster les règles et les paramètres | Rien : cette période est destinée à être explorée |
| Validation | Comparer les candidats et prendre des décisions de recherche | Une utilisation répétée augmente le risque de surapprentissage |
| Jeu de réserve final | Une évaluation du candidat figé | Consulter le résultat et modifier le candidat |
| Période future en simulation | Observer le comportement de mise en œuvre au fil du temps | Ajuster la stratégie en fonction des résultats lance un nouveau cycle de recherche |
Une évaluation glissante en walk-forward peut aider à estimer le comportement d’un processus de recherche fixe au fil du temps. Elle n’autorise pas à consulter sans limite les résultats de chaque fenêtre. Si un agent voit les résultats des fenêtres et adapte son exploration, ces résultats deviennent eux aussi une rétroaction. Gardez une période finale intacte pour la décision que vous cherchez réellement à prendre.
Erreur 3 : figer le code tout en changeant la question
Parfois, le code de la stratégie reste inchangé, mais le chercheur modifie l’évaluation après avoir vu le résultat : remplacer l’indice de référence, exclure un mois difficile, présenter un autre univers ou mettre en avant la métrique la plus favorable. Le jeu de test a orienté le récit, même si aucun paramètre n’a changé.
Le problème prend la forme d’un rapport soigné, avec un seul titre convaincant et aucune trace des autres analyses effectuées. Une stratégie actions peut sembler faible face à un indice de marché large, mais performante face aux liquidités ; une stratégie crypto peut briller sur une plateforme après que plusieurs plateformes ont été examinées. Ces comparaisons peuvent être utiles, mais choisir entre elles après avoir consulté le jeu de réserve constitue une nouvelle étape de sélection.
Tenez un journal de recherche. Pour chaque exécution, consignez l’hypothèse, la version du code, l’instantané des données, l’exploration des paramètres, les fenêtres d’évaluation, les métriques demandées et le fait que l’agent ou le chercheur ait consulté ou non le résultat. Un journal concis est plus utile qu’une étiquette « hors échantillon » qui sonne parfaitement.
Précisez ensuite la question finale avant l’évaluation : quel candidat, quel univers de marché, quel indice de référence, quels coûts et quelles métriques ? Si la réponse change après l’arrivée du résultat, considérez l’exécution suivante comme une étape de recherche et réservez de nouvelles données pour le prochain contrôle final.
Que puis-je encore apprendre d’un jeu de réserve contaminé ?
Il n’est pas inutile. Il peut montrer comment une stratégie s’est comportée pendant cette période et aider à diagnostiquer un échec. Cessez simplement de présenter son score comme une confirmation indépendante. Utilisez-le comme un élément de développement, figez le prochain candidat, puis évaluez-le sur une période future en simulation réellement inédite, avec les mêmes hypothèses comptables et d’exécution.
Dans un processus piloté par des agents, on perd facilement le compte des expériences : une seule instruction peut en déclencher des dizaines avant que quiconque ne s’en aperçoive. La protection repose sur la procédure. Limitez ce que l’agent peut consulter, consignez chaque expérience et gardez une évaluation dont le résultat ne peut pas influencer le candidat évalué.
← Tous les articles
