La porte de fidélité : le backtesting du grossier au fin vous trompe plus vite, à moins que le proxy bon marché ne classe comme l'évaluation coûteuse
Fait partie de la série "Des backtests sans illusions".
Toute recherche de paramètres sérieuse se heurte au même mur : l'espace est immense, et chaque évaluation honnête coûte cher. Une stratégie multi-timeframe avec une douzaine de seuils et trois périodes d'indicateurs, évaluée sur un découpage walk-forward à plusieurs folds, peut coûter plusieurs secondes par configuration. Dix mille configurations, ce sont des heures. On cherche alors un raccourci, et le raccourci est toujours la même idée : évaluer à bas coût, ne promouvoir que les survivants vers le test coûteux. Filtrer dix mille configs sur un fold, garder les quelques centaines de meilleures, faire tourner celles-ci sur tous les folds. Filtrer sur des bougies horaires, descendre à la seconde uniquement pour les finalistes.
C'est la recherche du grossier au fin — drill-down, multi-fidélité, élimination successive, Hyperband, ASHA — et c'est l'une des idées authentiquement bonnes en optimisation. Elle peut transformer une journée de calcul en une heure. Nous l'utilisons. Mais elle cache un piège si discret que la plupart des personnes qui la déploient ne le vérifient jamais, et le piège est celui-ci : toute la méthode suppose que votre proxy bon marché classe les configurations de la même façon que l'évaluation coûteuse. Si ce n'est pas le cas, vous ne cherchez pas plus vite. Vous jetez vos futurs gagnants dès la première porte et vous promouvez du bruit — vous vous trompez juste plus vite.
Cet article porte sur la seule mesure qui vous dit si votre drill-down est réel ou une illusion. Nous l'avons appliquée à notre propre recherche multi-timeframe, et la réponse était inconfortable : à la fidélité la moins chère, notre proxy classait les configurations presque au hasard (ρ de Spearman ≈ 0.03). Si nous avions élagué agressivement à cette fidélité — comme y invite le réglage par défaut de tout ASHA prêt à l'emploi — nous aurions écarté dès le premier tour les gagnants qui auraient fini par s'imposer. Le correctif est une porte obligatoire qui s'exécute avant la recherche : mesurer la corrélation de rang, et refuser d'élaguer en dessous de la fidélité où elle est fiable.
Ce qu'est réellement la recherche multi-fidélité

Cette famille de méthodes a une seule forme. Vous définissez une fidélité (aussi appelée ressource ou budget) : un curseur allant du bon marché au coûteux qui, à son maximum, donne le véritable objectif. Vous exécutez ensuite les configurations à basse fidélité, vous les classez, vous gardez la meilleure fraction, et vous ne relancez que ces survivants à une fidélité plus élevée — en répétant jusqu'à ce qu'un petit nombre de finalistes ait été évalué à pleine fidélité.
L'élimination successive (Jamieson & Talwalkar, 2016) en est le cœur : on démarre N configurations à la ressource minimale, on garde le top 1/η, on multiplie la ressource par η, on répète. Hyperband (Li et al., 2018) enveloppe l'élimination successive dans une boucle externe qui se couvre contre différentes ressources de départ, pour que vous n'ayez pas à deviner avec quelle agressivité élaguer. ASHA (Li et al., 2020) en est la version asynchrone, adaptée au parallélisme. Le taux d'élimination η est le seul réglage qu'elles partagent ; la valeur par défaut canonique est η = 3 — garder le meilleur tiers à chaque palier, tripler le budget.
La fidélité elle-même peut être presque n'importe quel curseur du bon marché au coûteux qui converge vers la vérité :
- Nombre de folds walk-forward. Évaluer sur 1 fold, puis 2, puis 3, jusqu'à K. C'est la fidélité que nous étudions ci-dessous, car c'est la plus naturelle pour un backtest avec un découpage out-of-sample glissant.
- Résolution des bougies. Filtrer sur des barres de 1 heure, promouvoir vers 1 minute, descendre à la seconde ou aux trades bruts uniquement pour les finalistes. C'est l'idée du drill-down adaptatif appliquée à la recherche plutôt qu'à la simulation d'exécution.
- Longueur de l'historique, epochs, sous-échantillon du dataset — les fidélités classiques du ML.
Dans un backtest, les folds et la résolution sont les deux axes qui comptent, et — c'est tout l'objet de cet article — ils ne sont pas également sûrs. L'un des deux comporte un biais qui sélectionne silencieusement les mauvais paramètres, quel que soit le soin que vous mettiez à le contrôler par une porte.
L'unique hypothèse sur laquelle tout repose

Écrivons ce dont l'élimination successive a réellement besoin pour être correcte. Elle n'a pas besoin que la fidélité bon marché donne la bonne valeur de l'objectif — personne ne se soucie qu'un fold rapporte un Sharpe différent de celui de six folds. Elle a besoin de quelque chose de plus faible mais bien plus spécifique : la fidélité bon marché doit classer les configurations de la même façon que la fidélité coûteuse. Si la config A bat la config B à pleine fidélité, A devrait aussi tendre à battre B à basse fidélité. C'est tout. Et c'est aussi tout ce qui compte.
Formellement, la grandeur qui détermine si le drill-down fonctionne est la corrélation de rang entre l'objectif à basse fidélité et l'objectif à haute fidélité, sur l'ensemble de l'espace de configurations. Si cette corrélation est élevée, les survivants du tour bon marché sont les mêmes configs qui auraient gagné le tour coûteux, et vous avez économisé du calcul gratuitement. Si elle est faible, le tour bon marché est un filtre aléatoire : il écarte de bonnes configs et en promeut de mauvaises, et vous avez dépensé votre budget à accélérer votre chemin vers une réponse pire. Aucun réglage intermédiaire de η ne vous sauve — un mauvais proxy élagué en douceur laisse quand même fuir des gagnants ; élagué agressivement, il en fait une hémorragie.
L'échec est invisible de la façon habituelle. La recherche se termine, rapporte un champion, le champion a l'air bien en in-sample. Rien ne lève d'erreur. Vous ne découvrez que le proxy mentait que lorsque le champion s'effondre en out-of-sample — et à ce moment-là, vous avez attribué l'échec à la stratégie, pas à la recherche qui l'a sélectionnée. La discipline est donc toujours la même à laquelle cette série revient : mesurez ce que la méthode suppose, avant de faire confiance à la méthode. Pour le drill-down, ce qu'il faut mesurer est la corrélation de rang, et la mesure est bon marché.
La mesurer : la porte de fidélité

La porte est une petite expérience que vous menez une fois, avant la recherche proprement dite, sur le même espace que celui que vous vous apprêtez à explorer. La procédure :
- Tirer quelques centaines de configurations au hasard dans l'espace des paramètres (nous en utilisons ~200 — suffisant pour une estimation de Spearman stable, assez peu coûteux pour se le permettre).
- Évaluer chacune à chaque palier de fidélité : à 1 fold, 2 folds, … jusqu'aux K folds complets. Pour une fidélité en nombre de folds, cela ne coûte presque rien, car les folds calculés pour les paliers bon marché sont réutilisés dans le palier coûteux — une moyenne cumulative.
- Pour chaque palier
r, calculer la corrélation de rang de Spearman entre le classement à r folds et le classement complet à K folds, sur ces ~200 configs. - Le premier palier où ρ franchit un seuil (nous utilisons ρ ≥ 0.5) est la fidélité la plus basse à laquelle vous êtes autorisé à élaguer. En dessous, le classement est trop bruité pour qu'on lui fasse confiance ; vous ne devez éliminer aucune config à ce niveau-là.
Le tout tient en une vingtaine de lignes. En voici le cœur :
def fidelity_check(cache, n_probe, seed=7):
"""Spearman ρ: cumulative mean over the first r folds (in FOLD_ORDER)
vs the full K-fold objective, on n_probe random configs."""
rng = np.random.default_rng(seed)
k = len(FOLDS)
per_fold = np.empty((k, n_probe))
order_win = np.array([list(FOLDS[fi]) for fi in FOLD_ORDER], np.int64)
for j in range(n_probe):
p = _unit_to_params(rng.random(len(PNAMES))) # random config
scores, *_ = eval_group(cache, p, _sp_of(p)[None, :], order_win, False)
per_fold[:, j] = scores[0] # score on each fold
cums = np.cumsum(per_fold, axis=0) / np.arange(1, k + 1)[:, None] # r-fold mean
rhos = []
for r in range(1, k):
rho = spearmanr(cums[r - 1], cums[-1]).statistic # r folds vs all K
rhos.append(0.0 if math.isnan(rho) else rho)
return rhos
Remarquez un détail délibéré : les folds sont pris dans l'ordre FOLD_ORDER, un ordre entrelacé qui alterne tranches précoces et tardives du calendrier (fold 0, puis un fold du milieu, puis le fold 1, puis un plus tardif, …). Cela compte énormément et fait l'objet d'une section plus loin : cela signifie que "1 fold" est une tranche unique couvrant le milieu de l'historique, et "2 folds" est une tranche précoce plus une tardive — jamais une fenêtre récente contiguë. La fidélité bon marché devient moins chère en utilisant moins de folds, pas des folds plus récents.
Résultats : un seul fold classe presque au hasard

Voici ce que la porte a rapporté, exécutée sur deux de nos configurations multi-timeframe. Le nombre est le ρ de Spearman entre le classement à r folds et le classement complet à K folds, sur ~200 configs aléatoires — la fidélité avec laquelle le rang à basse fidélité prédit le rang à pleine fidélité.
Folds r |
Exécution multi-TF | Un régime plus difficile |
|---|---|---|
| 1 | +0.43 | +0.03 |
| 2 | +0.67 | +0.43 |
| 3 | +0.78 | +0.78 |
| 4 | +0.82 | — |
| 5 | +0.91 | +0.91 |
Lisez d'abord la colonne du régime plus difficile, car c'est la plus alarmante. À un fold, ρ = 0.03. Ce n'est pas une corrélation faible ; c'est une absence de corrélation — le classement à un fold de deux cents configurations est statistiquement indiscernable d'un classement obtenu en les mélangeant au hasard. Une exécution d'élimination successive configurée (comme la plupart le sont, par défaut) pour commencer à élaguer à min_resource = 1 ferait, dans ce régime, sa première coupe — et la plus agressive — à pile ou face. Les configs qui finiraient par gagner à pleine fidélité ont une chance sur deux de survivre au tout premier tour. Le temps d'atteindre la fidélité où le classement signifie quelque chose (ρ = 0.78 à trois folds), la plupart d'entre elles ont déjà disparu.
La colonne multi-TF est plus clémente mais illustre le même point différemment. Même là, un fold donne ρ = 0.43 — en dessous de notre seuil de porte à 0.5. Cela ressemble à une corrélation correcte, et c'est exactement là le danger : 0.43 est assez élevé pour vous endormir et assez bas pour laisser fuir vos meilleures configs. Ce n'est qu'à deux folds (ρ = 0.67) que le classement devient fiable.
Deux choses se généralisent à partir de là. Premièrement, ρ à un fold dépend du régime et n'est pas fiable — nous avons mesuré des valeurs allant de 0.03 à 0.43 selon les configurations, et dans aucun des deux cas un seul fold n'a franchi la barre. Deuxièmement, ρ augmente de façon monotone et rapide : à trois folds, les deux configurations sont à 0.78, et à cinq elles convergent vers 0.91. Le signal est bien là ; il faut simplement dépenser assez de fidélité pour le voir. Le rôle de la porte est de trouver le palier exact où commence ce "assez" — et d'interdire l'élagage en dessous.
Pourquoi un seul fold est si bruité
Le bruit n'est pas un bug dans notre construction des folds ; il est intrinsèque, et comprendre pourquoi vous évite de le "corriger" de la mauvaise façon. Un seul fold walk-forward est une fenêtre courte — des semaines d'un seul régime de marché. Le score d'une stratégie sur cette fenêtre est dominé par à quel point ses paramètres se trouvent coller à ce régime, ce qui n'a qu'un rapport lâche avec sa capacité à généraliser. Deux configs authentiquement différentes en qualité peuvent échanger leurs places sur un seul fold simplement parce que l'une d'elles a capté une tendance que ce fold contenait par hasard. L'objectif sur un fold est un estimateur à haute variance de l'objectif qui vous intéresse réellement, et la corrélation de rang est précisément ce que la haute variance détruit en premier — on peut préserver la moyenne d'un estimateur alors que son classement est du pur bruit.
Ajouter des folds fait baisser cette variance par moyennage. Chaque fold est un tirage partiellement indépendant des conditions de marché ; la moyenne à r folds est un estimateur à variance plus faible, et son classement converge vers le classement à pleine fidélité. C'est précisément la montée ρ = 0.03 → 0.43 → 0.78 → 0.91 : ce n'est pas l'objectif qui change, mais son estimation de rang qui se stabilise à mesure que la chance propre à un régime s'annule en moyenne. La leçon est que la fidélité, pour un backtest, concerne fondamentalement le nombre de régimes indépendants que vous avez échantillonnés — et un seul ne suffit presque jamais pour classer.
Cela explique aussi pourquoi le régime plus difficile part de 0.03 alors que l'exécution multi-TF part de 0.43. Dans le régime plus difficile, le fold unique est plus idiosyncratique au régime — les scores à un fold des configs sont davantage pilotés par la chance et moins par un edge durable, si bien qu'ils se classent plus près du hasard. La porte lit cette différence automatiquement et réagit en exigeant davantage de folds avant d'autoriser l'élagage. Vous n'avez pas besoin de savoir à l'avance dans quel régime vous êtes : vous mesurez.
La porte en code : relever automatiquement la fidélité minimale
La sortie de la porte est un simple entier : min_resource, la fidélité la plus basse à laquelle ASHA est autorisé à élaguer. La règle est mécanique — parcourir les paliers, prendre le premier dont le ρ franchit le seuil :
RHO_GATE = 0.5
min_res = len(FOLDS) # default: pruning OFF (full fidelity)
rhos = fidelity_check(cache, n_probe=200) # [ρ@1, ρ@2, …, ρ@(K-1)]
passing = [r for r, rho in enumerate(rhos, 1) if rho >= RHO_GATE]
if passing:
min_res = passing[0] # first rung that clears the gate
pruner = SuccessiveHalvingPruner(min_resource=min_res, reduction_factor=3)
Suivons cela sur les deux exécutions. Dans la configuration multi-TF, ρ@1 = 0.43 échoue à la porte mais ρ@2 = 0.67 la franchit, donc min_resource est automatiquement relevé à 2 : ASHA fait tourner chaque config sur au moins deux folds avant d'être autorisé à en éliminer, puis élague normalement à partir de là. Dans le régime plus difficile, ρ@1 = 0.03 et ρ@2 = 0.43 échouent tous les deux ; ρ@3 = 0.78 est le premier à franchir le seuil, donc min_resource devient 3. Et le repli crucial : si aucun palier n'atteint 0.5, passing est vide et min_resource reste à K — l'élagage est entièrement désactivé, et la recherche se dégrade proprement vers une simple recherche à pleine fidélité plutôt que vers une recherche rapide mais fausse. Un drill-down incapable de prouver la validité de son proxy refuse tout simplement d'élaguer.
C'est toute la philosophie en une ligne de flux de contrôle. Le comportement par défaut de toute bibliothèque d'élimination successive est "élaguer dès min_resource = 1, faire confiance au palier bon marché." La porte remplace cela par "élaguer à partir du premier palier que les données jugent fiable, et si aucun ne l'est, ne pas élaguer." Cela coûte une sonde initiale d'environ 200 configs, et cela transforme le drill-down d'un acte de foi en une décision mesurée. Le taux d'élimination η = 3 reste inchangé ; la porte ne touche pas à l'intensité de l'élagage, seulement au moment à partir duquel vous êtes autorisé à commencer.
Une remarque d'honnêteté visible dans le code ci-dessus : relever min_resource entame l'accélération. Élaguer à 3 folds plutôt qu'à 1 signifie que chaque config — y compris celles que vous allez écarter — paie pour trois folds. C'est le prix de la correction, et c'est le bon compromis : une accélération 2× plus petite sur une recherche qui trouve de vrais gagnants vaut mieux qu'une accélération 6× sur une recherche qui les écarte. La porte rend ce compromis explicite au lieu de le cacher.
Le mauvais axe bon marché : un historique plus court est un piège
Il existe une fidélité bon marché qui est tentante, évidente, et biaisée, et il vaut la peine de la nommer explicitement car tout le monde s'y précipite en premier : un historique plus court. Filtrer les configs sur le dernier mois, promouvoir les survivants vers les deux années complètes. C'est trivialement bon marché et cela donne l'impression d'être la même idée que moins de folds. Ce n'est pas le cas.
Moins de folds et un historique plus court diffèrent d'une manière décisive. Une fidélité en nombre de folds, bien construite, continue de couvrir le calendrier entier — elle l'échantillonne simplement plus grossièrement. Une fidélité en historique plus court échantillonne densément un sous-intervalle du calendrier. Et un sous-intervalle de l'historique de marché est un régime spécifique. Quand vous classez des configs sur le dernier mois, vous n'obtenez pas une estimation bruitée mais non biaisée de leur rang sur la période complète ; vous obtenez une estimation biaisée qui favorise systématiquement les configs calées sur le régime du dernier mois. Augmentez la taille de l'échantillon tant que vous voulez — moyennez sur plus de configs, plus d'essais — le biais ne rétrécit pas, car ce n'est pas de la variance. Vous promouvrez les configs qui collent le mieux à la fenêtre de filtrage, et ce sont précisément celles qui ont le plus de chances d'être en surapprentissage sur un régime transitoire.
C'est pourquoi notre fidélité parcourt les folds dans un ordre entrelacé plutôt que chronologique. Avec K folds répartis sur tout l'historique, "1 fold" est une tranche unique proche du milieu, "2 folds" est une tranche précoce plus une tardive, "3 folds" répartit précoce/milieu/tardif — chaque niveau de fidélité, même le moins cher, échantillonne sur l'ensemble du calendrier. Le proxy bon marché est une vue grossière de la période entière, jamais une vue précise d'une seule tranche de celle-ci. Cet entrelacement est ce qui fait que la fidélité en nombre de folds est simplement bruitée (curable par la porte) plutôt que biaisée (ce qu'aucune porte ne peut corriger — un ρ élevé par rapport à une cible biaisée ne fait que certifier que vous choisirez de façon fiable la config calée sur le régime). Si votre seul moyen de rendre une fidélité moins chère est de la rendre plus récente, vous n'avez pas une fidélité valide. Rendez-la plutôt plus grossière.
La résolution comme axe bon marché honnête
L'autre axe bon marché évite entièrement le biais, et c'est le partenaire naturel du drill-down adaptatif que nous avons décrit pour la simulation d'exécution : la résolution des bougies. Filtrer tout l'espace sur des barres de 1 heure, promouvoir les survivants vers 1 minute, et descendre à la seconde ou aux trades bruts uniquement pour la poignée de finalistes. Des bougies plus grossières sur le même historique complet sont moins coûteuses à évaluer — moins de barres, des passes d'indicateurs plus rapides, une simulation plus rapide — et, contrairement à une fenêtre plus courte, une vue grossière du calendrier entier n'est pas biaisée : elle voit chaque régime, simplement avec moins de détail intrabar.
Résolution et folds sont des axes de fidélité complémentaires, et la porte de fidélité s'applique aux deux. Avant de faire confiance à un filtrage à 1 heure, exécutez la même sonde : prenez ~200 configs, notez-les à 1h et à 1m, et mesurez la corrélation de rang. Si ρ(1h, 1m) est élevé, filtrer sur des heures est sûr et vous avez honnêtement acheté une grande accélération. Si c'est faible — ce qui arrive quand l'edge de la stratégie réside dans une structure intrabar que les bougies horaires effacent — alors le filtrage horaire est un filtre aléatoire pour cette stratégie, et la porte vous dit de recommencer plus fin. La règle ne change jamais : vous n'êtes autorisé à élaguer à une fidélité qu'après avoir mesuré que son classement concorde avec la vérité.
Les deux axes échouent aussi de façons opposées, ce qui est utile. Une résolution grossière perd de l'information intrabar ; moins de folds perdent de l'information inter-régimes. Une stratégie de momentum sur des horizons journaliers peut se classer parfaitement sur des bougies horaires mais avoir besoin de nombreux folds pour moyenner la chance liée au régime ; une stratégie de scalping peut se classer correctement sur peu de folds mais s'effondrer au-delà de la résolution à la seconde. La porte, exécutée par axe, vous indique sur quelle fidélité vous pouvez vous permettre d'être bon marché pour cette stratégie — plutôt que de présumer une réponse qui se trouve être commode.
D'où viennent réellement les gains
Une mise en garde qui garde le drill-down honnête : une fidélité n'économise du calcul que là où le coût réside réellement. Dans notre moteur multi-timeframe, la partie coûteuse est le précalcul des indicateurs — les signaux HMA et de séparation multi-timeframe — qui est payé une fois par configuration, avant qu'aucun fold ne s'exécute. La simulation par fold sur les signaux mis en cache est comparativement bon marché. Donc élaguer sur le nombre de folds n'économise que le coût de la simulation, pas le coût des indicateurs qui domine ; la fidélité en nombre de folds est réelle mais son plafond est plus bas que ce que suggère le simple ratio de folds.
L'axe de résolution, en revanche, attaque directement le coût dominant : des bougies plus grossières signifient moins de barres sur lesquelles calculer les indicateurs, si bien que le précalcul coûteux et la simulation bon marché rétrécissent ensemble. Ce n'est pas un détail — cela détermine quel drill-down vaut la peine d'être construit. Avant d'investir dans une recherche multi-fidélité, demandez-vous où passent vos secondes. Si 90 % correspondent au précalcul des indicateurs partagé entre les folds, une fidélité en nombre de folds vous rapporte peu et une fidélité de résolution vous rapporte beaucoup. Profilez d'abord ; le bon axe bon marché est celui qui supprime le coût que vous avez réellement, et il doit quand même franchir la porte.
Où cela se connecte
La porte de fidélité occupe une place précise dans la chaîne d'hygiène du backtesting que déroule cette série :
- Elle est en amont du contrôle du surapprentissage. Un drill-down qui élague sur un mauvais proxy est une nouvelle façon de surapprendre — vous laissez un palier précoce bruité sélectionner vos finalistes. Le champion doit quand même survivre au Deflated Sharpe et au PBO, et le décompte des essais alimentant ces portes doit inclure chaque essai élagué, pas seulement les survivants — élaguer ne rend pas un essai gratuit vis-à-vis du registre des tests multiples.
- Elle partage son ennemi avec l'analyse de plateau : une config qui gagne sur un fold ou une fenêtre de filtrage et nulle part ailleurs est le même artefact calé sur un régime que les deux outils existent pour rejeter. La porte refuse de sélectionner sur un tel fold ; l'analyse de plateau refuse de faire confiance à un champion qui repose sur un seul.
- Elle présuppose en dessous un découpage walk-forward honnête — des folds couvrant le calendrier complet, un out-of-sample mis de côté — et elle est le complément, au moment de la recherche, du drill-down que nous avons construit pour la simulation d'exécution : même principe du grossier au fin, appliqué à quelles configs évaluer plutôt qu'à avec quelle précision les exécuter.
- Et elle dépend absolument du fait que la fidélité soit exempte de fuite à chaque palier. Si le palier bon marché comporte un biais d'anticipation que le palier coûteux n'a pas, ρ mesure l'accord avec une cible contaminée et la porte certifie une fuite. Mesurez la corrélation de rang, oui — mais sur un objectif honnête.
L'idée unificatrice, encore une fois, est celle que cette série ne cessera pas de répéter : un backtest est une expérience statistique, et chaque raccourci qu'il contient est une hypothèse que vous êtes tenu de tester. L'hypothèse du drill-down est "rang bon marché ≈ rang coûteux." Elle est testable sur ~200 configs. Testez-la.
Points à retenir
- La recherche du grossier au fin repose sur une seule hypothèse : le proxy bon marché classe les configs comme le proxy coûteux. Pas la même valeur — le même classement. Si la corrélation de rang est faible, un élagage agressif écarte vos futurs gagnants et promeut du bruit. Vous cherchez plus vite vers une réponse pire.
- Mesurez-la avant de lui faire confiance. Tirez ~200 configs aléatoires, notez-les à chaque palier de fidélité, et calculez le ρ de Spearman entre chaque palier bon marché et le classement à pleine fidélité. C'est une vingtaine de lignes et une sonde bon marché.
- Un seul fold classe presque au hasard. Nous avons mesuré ρ@1 allant de 0.03 (pile ou face) à 0.43 (encore en dessous du seuil de confiance) selon le régime ; il grimpe à 0.67, 0.78, 0.82 et 0.91 à mesure que les folds s'accumulent. Le
min_resource = 1par défaut de tout ASHA prêt à l'emploi est, pour un backtest, généralement erroné. - Relevez automatiquement la fidélité minimale au premier palier où ρ ≥ 0.5, et si aucun ne franchit le seuil, n'élaguez pas du tout. La porte s'est traduite par
min_resource = 2pour une configuration et3pour une autre plus difficile ; le repli se dégrade proprement vers une recherche à pleine fidélité. La correction coûte un peu d'accélération — payez-la. - Choisissez l'axe bon marché selon qu'il est biaisé ou non, pas selon qu'il est bon marché. Un historique plus court est biaisé — il sélectionne des paramètres calés sur un régime, et aucune taille d'échantillon ne corrige cela. Utilisez moins de folds couvrant le calendrier complet (entrelacés, pas contigus) ou une résolution plus grossière sur toute la période. Et dépensez l'axe bon marché là où votre coût réside réellement.
Le drill-down est l'une des meilleures accélérations en backtesting, et l'une des plus faciles à transformer en une façon plus rapide de se tromper soi-même. La différence entre les deux tient en un seul nombre que vous pouvez mesurer avant que la recherche ne commence. Si votre proxy ne peut pas prouver qu'il classe comme la vérité, ce n'est pas un proxy — c'est un générateur de nombres aléatoires avec un profil de coût plausible.
Authors
Trading-systems engineer
Trading-systems engineer building bots since 2017: cross-exchange arbitrage (connected up to 30 venues), cointegration-based pairs arbitrage across spot and futures, scalping, news and sentiment-driven strategies, trend algorithms, and portfolio management and balancing algorithms. Also builds sub-millisecond order execution, big-data warehouses, backtesting engines, AI agents, and trading interfaces (incl. open-source profitmaker.cc). Stack: JS/TS, Python, Rust/Zig/Go, DevOps, backend, frontend, architecture.