Publicado
Cada configuración en mi base de datos de backtest obtiene una sola puntuación compuesta, una combinación de factor de ganancia, tasa de ganancias y resultado neto, por lo que puedo ordenar 12,331 filas y encontrar las mejores sin leer cada una a mano. Hoy corrí ORDER BY score DESC LIMIT 1 por costumbre, esperando a los sospechosos habituales. Lo que regresó fue un pullback_reclaim configurar en BSUSDT: 200 operaciones, tasa de ganancias del 100%, puntuación 49.908,87. La segunda puntuación más alta de toda la tabla, cualquier símbolo, cualquier familia de estrategias, es 427,78. El "mejor" resultado en mi base de datos es 116 veces más alto que el subcampeón. Esa brecha es la clave.
Lo que una puntuación de 49.908 en realidad es
El factor beneficio son las ganancias brutas divididas por las pérdidas brutas. Cuando una muestra de 200 operaciones llega a cero operaciones perdedoras de tamaño significativo, ese denominador colapsa hacia cero y la relación quiere ir al infinito. Mi pipeline capta eso y limita el factor de ganancia a un valor centinela de 999 en lugar de devolver inf -- un guardia razonable. Lo que no es razonable es que la fórmula de puntuación tome ese 999 limitado y se ejecute con él, produciendo un número compuesto de dos órdenes completos de magnitud por encima de cualquier cosa que un resultado real pueda producir. La barandilla de seguridad detuvo un choque de división por cero. No impidió que el número dejara de tener sentido.
| Config | Vientos alisios | Tasa de ganancia | FP | Neto | Puntaje |
|---|---|---|---|---|---|
| BSBUSDT pullback_reclaim (#1 en general) | 200 | 100% | 999 | +$ 47.88 | 49.908,87 |
| BILLUSDT micro_momentum (#2 en general) | 200 | 99,5 % | 9.28 | 55 / 81 | 427,78 |
| BSBUSDT Pullback_Reclaim, misma familia, muestra completa | 2.000 | 95.0% | 1.96 | +$ 471.18 | 53.79 |
* Límite centinela, no es un factor de ganancia real: el oleoducto sustituye a 999 cuando las pérdidas brutas se redondean a casi cero en una muestra pequeña. Figuras extraídas directamente de backtest_results, ids 2, 35 y 102.
La misma moneda, anotó 861 veces menos, haciendo 10 veces más
BSBUSDT pullback_reclaim no solo existe como una casualidad de 200 operaciones, sino que es una de las combinaciones de símbolo/familia más probadas en toda la base de datos, que se ejecuta en tamaños de muestra desde 200 hasta la ventana estándar de 2.000 operaciones docenas de veces. Entre esas carreras de tamaño completo, la mejor red +$ 471.18 en una tasa de ganancia creíble del 95% y un factor de ganancia de 1.96, un número real, no un tope. Su puntaje: 53.79ESO ES Pierna ( partes ) que el golpe de suerte de 200 intercambios, para una configuración que hizo más o menos Contar con más dinero. Si hubiera confiado solo en el campo de puntuación, habría elegido la peor operación cada vez.
La parte que realmente tenía
Esto es lo que no se rompió: la lista corta de 50 configura las banderas de mi pipeline is_top_candidate -- the ones that actually get walked forward into deeper validation -- all require a minimum of 808 trades. The 200-trade fluke never got near that gate; it isn't on the shortlist, and never was. A second, completely independent filter caught what the score alone couldn't. That's the system working as intended one layer down. But the score field itself -- the one a human (or a careless query) reads first -- has sat in the database this whole time reporting that a $47.88 trade is the single best result out of 12,331, by a factor of 116.
What I actually check now
Score is a sort key, not a verdict. Before I trust any number near the top of a sorted list, I now check trade count first -- anything under roughly 800 trades in this pipeline gets read as "too early to tell," full stop, regardless of what the headline number says. I also stopped trusting profit factor above single digits on sight; a PF of 9 is suspicious, a PF of 999 is a bug report. The same logic applies outside my own database: if you're evaluating any backtest -- yours or someone else's -- and the sample size isn't stated next to the headline number, run the one you do have through riesgo de ruina before you size a real position off it. A great score on a small sample and a mediocre score on a large one are not the same kind of claim, even when the small one reads higher.
Method: queried directly against our own backtest pipeline's SQLite store (backtest_results, 12,331 rows across all symbols/families; is_top_candidate shortlist, 50 rows). Scores, trade counts and profit factors are the pipeline's own stored output, not recomputed by hand. Research findings on paper/simulated strategies, not a live trading record. Not financial advice.
- Calculadora de riesgo de ruina — how bust probability scales with a thin, uneven edge
- Required win rate calculator — the win rate your payoff ratio actually needs
- Win rate calculator — track your own numbers trade by trade
- Break-even win rate calculator — where fees push the line