Nous avons testé 240 jeux de paramètres. Le meilleur affichait un ratio de Sharpe de 2.1 ; la médiane était de 0.1 ; et seuls 17 dépassaient 1.0. Ces chiffres ressemblent à une découverte, jusqu’à ce qu’on apprenne que même si aucune stratégie ne présente de véritable avantage, une recherche aussi vaste peut produire un résultat flatteur.
Le chiffre surprenant, c’est 240. Un rapport de backtest présente généralement la stratégie retenue comme si elle était apparue seule. Or, la recherche ne se déroule pas ainsi. Chaque ajustement de paramètre, remplacement de variable, changement d’univers et nouvelle exécution après un résultat décevant donne au bruit une nouvelle occasion de ressembler à un signal.
Pourquoi essayer davantage de stratégies fait-il gonfler le meilleur Sharpe ?
Imaginez 240 stratégies indépendantes sans véritable avantage, dont les estimations de Sharpe sont bruitées. La plupart des estimations sont proches de zéro, mais la valeur maximale tend à être positive. Plus vous examinez de candidats, plus cette valeur maximale peut s’éloigner de la vérité.
À titre d’illustration approximative, supposons que l’erreur standard du Sharpe estimé de chaque candidat soit de 0.5. Avec 240 tirages indépendants, l’estimation la plus élevée peut se situer autour de 1.4 erreur standard au-dessus de la moyenne, soit environ 0.7 de Sharpe, par simple effet de sélection. Les vrais candidats à une stratégie sont corrélés ; ce calcul n’est donc pas une correction à appliquer directement dans un rapport. Il montre pourquoi « le gagnant a fait mieux que zéro » constitue un indice faible après une recherche étendue.
Et la recherche ne se limite presque jamais à la grille de paramètres. Vous avez peut-être essayé trois familles de signaux, écarté deux d’entre elles après avoir vu leurs courbes, modifié l’univers de trading, puis relancé le candidat restant avec un autre calendrier de rééquilibrage. Si les résultats ont influencé ces choix, ils font partie de l’historique de recherche.
Qu’est-ce qui compte comme un essai de backtest ?
Comptez une décision comme un essai lorsque son résultat aurait pu influencer le choix de la stratégie. Cela inclut les exécutions que vous n’avez pas publiées et les variantes que vous avez arrêtées prématurément parce que la courbe de capital semblait mauvaise. Un échec de compilation ne constitue pas un essai de performance ; une exécution qui a produit un Sharpe décevant en est généralement un.
| Action de recherche | À compter en général ? | Pourquoi |
|---|---|---|
| Modifier une période de calcul de 20 à 30 après examen des résultats | Oui | Le premier résultat a influencé le candidat suivant |
| Exécuter la même stratégie prédéfinie sur une nouvelle période déterminée à l’avance | Généralement, pas un nouvel essai de sélection | La règle était fixée avant l’observation de ces éléments de preuve |
| Modifier l’univers après avoir vu quels actifs étaient gagnants | Oui | La sélection de l’univers peut améliorer le résultat apparent |
| Corriger une erreur de syntaxe et relancer le code sans le modifier | Non | Aucun choix de recherche ne dépendait de la performance |
La limite tient à l’usage que vous avez fait d’un résultat pour prendre une décision. Il peut être difficile de reconstituer cela de mémoire ; c’est pourquoi un journal d’expériences doit consigner l’hypothèse, la version du code ou de la configuration, la période des données, les hypothèses de coûts et le résultat de chaque exécution.
Puis-je corriger les tests multiples ?
Il existe des méthodes pour estimer le biais de sélection ou ajuster la significativité en fonction du nombre d’essais. Elles peuvent être utiles, mais reposent sur des hypothèses concernant les relations entre candidats et le comportement des rendements. Une p-value nominale ou une seule estimation de Sharpe déflaté ne peut pas compenser la perte de l’historique réel de la recherche.
Commencez par les éléments que vous contrôlez. Figez une spécification finale avant d’évaluer une période réellement laissée de côté. Gardez visibles tous les candidats. Lorsque vous testez de nombreuses variantes liées, regroupez-les selon la décision qui les a produites au lieu de prétendre que chacune constitue une découverte indépendante. Présentez aussi la recherche : nombre d’essais, règle de sélection et indication précisant si l’évaluation finale a entraîné d’autres modifications.
Un test utile : Si le résultat sur la période de validation est décevant, allez-vous modifier la stratégie et qualifier de nouveau cette même période de période de validation ? Si oui, elle fait désormais partie de la recherche. Il vous faut de nouveaux éléments de preuve pour la prochaine évaluation.
Que doit consigner un agent de recherche IA ?
Un agent peut générer des candidats plus vite qu’une personne ne peut les garder en mémoire de travail. Le suivi des essais fait donc partie du système de recherche ; ce n’est pas une corvée administrative. Enregistrez chaque candidat avant son exécution, avec l’expérience dont il découle et sa raison d’être. Conservez les exécutions échouées et écartées. Notez quand une personne ou un agent a examiné les performances et quelle décision a suivi.
Rendez ensuite le processus de sélection reproductible : avec le même ensemble de candidats et la même règle, il doit choisir le même gagnant. Si un agent modifie son prompt, son objectif ou ses contraintes après avoir vu les résultats, ces modifications font également partie de la recherche.
Un Sharpe de 2.1 mérite peut-être qu’on s’y intéresse. Sa signification dépend du chemin qui y a conduit. Lorsque le journal de recherche indique que 240 candidats étaient en lice pour faire la une, vous pouvez poser la bonne question suivante : quels éléments de preuve nous restent-ils que ces choix n’ont pas déjà épuisés ?
← Tous les articles
