Lección de método

Contra qué se compara: el nulo

Una señal no se compara contra cero, sino contra lo que habría dado el azar en la misma época y con la misma duración. Equivocarse de época multiplica el listón por siete.

La pregunta: Mi señal ganó un 4 % de media por operación. ¿Es eso mucho?

Qué se encontró

Depende enteramente de cuándo y durante cuánto. Una ventana aleatoria de 20 días de Bitcoin ha rendido de media un +8,63 % sobre la historia completa, un +3,86 % post-2017 y un +1,22 % en los últimos dos años. La misma operación del 4 % es un fracaso en un contexto y un éxito en otro. Por eso el nulo tiene que estar emparejado por DURACIÓN y por ÉPOCA: se sortean ventanas aleatorias del mismo largo y del mismo tramo temporal que las operaciones que se están juzgando, y la señal tiene que batir a eso, no a cero. El proyecto tenía un bug real justo aquí: su función de nulo sorteaba siempre sobre el array de precios COMPLETO, incluso al puntuar un subconjunto reciente, así que un candidato de los últimos dos años se comparaba contra un listón siete veces más rico.

0.0%5.8%11.5%17.3%23.1%1.8%1.0%0.7%0.3%5d8.6%3.9%2.6%1.2%20d20.6%8.2%5.8%2.1%40dHistoria completaPost-2017Post-2020Últimos 2 años
Retorno medio de una ventana ALEATORIA de Bitcoin, por duración y por época. Este es el listón que hay que batir, y cambia por un factor de siete según de dónde se sortee.docs/research-postmortem-and-plan-2026-09-07.md §2.4

Pruébalo tú mismo

Pon el resultado medio de tu señal y el del azar en la misma época y duración. La resta es lo único que cuenta.

Exceso sobre el azar = Retorno de la señal − Retorno de una entrada aleatoria comparable
Exceso sobre el azar

Qué parte del resultado de la señal era simplemente el mercado (%):

Con los valores por defecto —una señal del 4 % contra el 3,86 % que daba el azar post-2017 a 20 días— el exceso es de 0,14 puntos. El 96 % del resultado era el mercado. Prueba a cambiar el nulo a 8,63 (historia completa) o a 1,22 (últimos dos años) y mira cómo cambia el veredicto sin tocar la señal.

Números de ejemplo para practicar — no son datos reales.

Cómo se probó, paso a paso

  1. Se toma cada operación de la señal y se anota su duración exacta y el tramo temporal en el que ocurrió.
  2. Se sortean miles de ventanas aleatorias con esa MISMA duración, dentro de ese MISMO tramo. Esa nube de resultados es lo que habría dado entrar al azar.
  3. La puntuación de la señal es su percentil dentro de esa nube. Un percentil de 0,52 significa "indistinguible del azar"; uno de 0,95, "mejor que el 95 % de las entradas aleatorias comparables".
  4. La corrección que adoptó el proyecto: el rango del que se sortea es ahora un argumento OBLIGATORIO, y la función lanza una excepción si ese rango no contiene las operaciones que se están evaluando. Más un test unitario que falla si alguien lo vuelve a desemparejar.
Qué NO dice esto. Lo interesante es lo que pasó al arreglarlo: re-puntuando los 13 candidatos rechazados con un nulo emparejado por época, CERO cambian de veredicto. El bug era real, había que arreglarlo, y no resucitó a nadie. Merece la pena decirlo porque es la forma correcta de cerrar un bug: arreglarlo, re-correr lo afectado, y publicar que no cambió nada — en vez de dejar la duda flotando o de usarlo como excusa para reabrir candidatos muertos. Un segundo defecto del mismo instrumental, también documentado: la función llamada "block bootstrap" no era tal, sino un remuestreo independiente de operaciones, que ignora el agrupamiento temporal y subestima la incertidumbre cuando las señales se disparan en racimos.

Seguimiento

Este hallazgo no tiene un número en vivo: se midió sobre datos archivados y publicar un gráfico aquí daría a entender un seguimiento continuo que no existe. Las cifras están arriba, con el script que las produjo.

← Toda la investigación