Publié
Chaque configuration dans ma base de données de backtest enregistre trois façons dont une transaction peut se terminer : elle atteint la rentabilité, elle atteint un arrêt ou elle s'épuise sur un arrêt de temps difficile sans faire l'une ou l'autre. J'avais surtout ignoré ce troisième nombre, time_stop_rate, le traitant comme un effet secondaire de tout ce qui se passait d'autre. Ensuite, j'ai trié les 12 331 configurations par elle. Le taux de victoire chute presque en ligne droite à mesure que le taux d'arrêt augmente. Le facteur profit bouge à peine. Deux mesures de résultats, un numéro d'entrée, deux réponses complètement différentes.
Le taux de victoire chute de près de 30 points, de haut en bas
| Taux d'arrêt | Configs | Taux de gain moyen | Facteur de profit moyen | Drapeaux des meilleurs candidats |
|---|---|---|---|---|
| 0 à 10 % | 2 785 | 76,3 % | 2.03 | 47 |
| 10 à 20 % | 2 078 | 71,6% | 1.23 | 3 |
| 20 à 30 % | 1.892 | 67,0% | 1.13 | 0 |
| 30 à 40 % | 2.013 | 64,9 % | 1,09 | 0 |
| 40 à 50 % | 1 710 | 61,2% | 1,04 | 0 |
| 50 - 60 % | 894 | 57,9% | 1.02 | 0 |
| 60-70% | 515 | 54,2% | 0,98 | 0 |
| 70 | 444 | 48,0% | 1.11 | 0 |
C'est 76,3 % en baisse à 48,0 %, une baisse de 28,3 points du taux de victoire moyen du compartiment d'arrêt le plus bas au compartiment le plus élevé, sur huit compartiments qui se déplacent dans la même direction à chaque fois. Formellement, il s'agit d'une corrélation de -0,41 Pearson entre time_stop_rate et wr across all 12,331 configs -- moderate, not perfect, but far from noise. Net profit correlates even harder, at -0.52. The top-candidate flag makes the same point in a cleaner form: 47 of my 50 flagged configs sit in the 0-10% bucket, the rest in 10-20%. Not one top candidate exists past a 20% time-stop rate. The exact range across all 50 flagged configs is 0.12% to 16.69%, averaging 4.13%. A config where more than one in six trades just times out, waiting for a move that never comes, has never once earned my top-candidate flag.
Le facteur de profit s'en moque
Voici ce à quoi je ne m'attendais pas. Exécuter la même corrélation contre pf au lieu de... wr and you get -0.04 -- statistically nothing. Look at the table again: profit factor drifts from 2.03 down to roughly 1.0 across most of the range, but then the 70%+ bucket, the worst win-rate bucket of all, actually ticks back up to 1.11. A config can time out on most of its trades and still hold a perfectly respectable profit factor, as long as the trades that do resolve on their own resolve well. Win rate measures how often you're right. Profit factor measures what you make when you are, against what you lose when you aren't. A high time-stop rate wrecks the first number by definition -- a timeout isn't a win -- but says almost nothing about the second, because it's silent on the size of the trades that didn't time out.
J'ai vérifié si c'était juste « n'importe quel taux de raisonnement de sortie prédit les résultats » en exécutant le même test de compartiment sur fi_rate, the rate at which a trade exits on a final invalidation stop. No clean pattern: win rate bounces between 64.0% and 70.0% across its five buckets with no consistent direction, and the top-candidate flags don't concentrate at either end the way they do for time-stop rate. Not every exit-reason column is a hidden predictor. This one specifically is, because a time-stop is really a measurement of how often the entry thesis simply failed to play out in either direction -- a different kind of signal than a stop-loss, which measures how often it played out against you.
Ce que cela change dans la façon dont je lis une configuration
Utilisés pour traiter time_stop_rate en tant que bris d'égalité, quelque chose à regarder après le taux de victoire et le facteur de profit a déjà raconté l'histoire. J'en fais la promotion. Si je scanne un nouveau lot de configurations et que je veux un seul filtre précoce avant d'exécuter le plein GOOD_FOR_DEEP_TEST/is_top_candidate pipeline on all of them, sorting by time-stop rate and cutting anything above 20% would have discarded every single config that never produced a flag anyway -- without needing the rest of the pipeline to tell me so. What it won't do is tell me whether a low-time-stop config is actually profitable; for that I still need profit factor, because the two numbers are measuring different failure modes and one doesn't substitute for the other. If you're evaluating your own backtest exports, run win rate and profit factor through the calculateur de facteur de profit séparément avant de faire confiance à l'un ou l'autre seul - une stratégie qui a l'air propre sur un axe peut encore être discrètement brisée sur l'autre.
Méthode : 12 331 lignes de notre propre tableau de résultats de backtest (le même pipeline derrière backtest-reports.html), couvrant 5 familles de stratégies à travers 176 symboles suivis en direct. time_stop_rate, wr, pf et is_top_candidate sont les propres champs enregistrés du pipeline. Les corrélations sont le r de Pearson calculé sur l'ensemble des 12 331 lignes, et pas seulement les moyennes de seau indiquées ci-dessus.