Publicado
Cada configuración en mi base de datos de backtest registra tres formas en que una operación puede terminar: llega a take-profit, llega a una parada o se queda sin reloj en un momento difícil, sin hacer ninguna de las dos cosas. En su mayoría había ignorado ese tercer número, time_stop_rate, tratándolo como un efecto secundario de cualquier otra cosa que estuviera sucediendo. Luego ordené las 12,331 configuraciones por él. La tasa de ganancias cae casi en línea recta a medida que aumenta la tasa de tiempo de parada. El factor beneficio apenas se mueve. Dos métricas de resultados, un número de entrada, dos respuestas completamente diferentes.
La tasa de ganancias cae casi 30 puntos, de arriba a abajo
| Tasa de tiempo de parada | Configuraciones | Tasa media de ganancias | Factor de ganancia | Banderas de los mejores candidatos |
|---|---|---|---|---|
| 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 |
| Más del 70 % | 444 | 48.0% | 1.11 | 0 |
Eso es un 76.3% hasta un 48.0%, una caída de 28.3 puntos en la tasa de ganancias promedio desde el cubo de tiempo de parada más bajo hasta el más alto, en ocho cubos que se mueven en la misma dirección cada vez. Formalmente es una correlación de -0.41 Pearson entre time_stop_rate y 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.
Al factor beneficio no le importa
Esto es lo que no esperaba entrar. Ejecutar la misma correlación contra pf en vez 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.
Comprobé si esto era solo "cualquier tasa de razón de salida predice los resultados" ejecutando la misma prueba de cubo en 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.
Lo que esto cambia sobre cómo leo una configuración
Se utilizan para tratar time_stop_rate como un desempate, algo a lo que echar un vistazo después de la tasa de ganancias y el factor de ganancias ya contó la historia. Lo estoy promocionando. Si estoy escaneando un nuevo lote de configuraciones y quiero un solo filtro temprano antes de ejecutar el 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 calculadora de factor de beneficio por separado antes de confiar en uno solo: una estrategia que se ve limpia en un eje puede romperse silenciosamente en el otro.
Método: 12.331 filas de nuestra propia tabla de resultados de backtest (el mismo pipeline detrás backtest-reports.html), que cubre 5 familias de estrategias en 176 símbolos rastreados en vivo. time_stop_rate, wr, pf e is_top_candidate son los propios campos registrados del pipeline. Las correlaciones son la r de Pearson calculada en las 12 331 filas, no solo las medias de los cubos que se muestran arriba.