Hay una pregunta que todo backtest esquiva: ¿el mismo código, alimentado con el mismo mercado en vivo, habría hecho lo mismo? No se responde con más backtesting. Solo se responde ejecutando la estrategia contra datos en vivo con semántica de ejecución real y comprobando después — operación por operación — que ambos mundos coinciden. Hacemos esa comprobación todos los días, de forma automática, y ha sido con diferencia el cazador de bugs más productivo de la plataforma.
Día uno: construir el espejo
Cada estrategia promocionada corre en su propio nodo en vivo aislado, consumiendo streams reales del exchange: quotes en vivo para los fills, spreads reales, horarios de sesión reales. Sin estado compartido entre estrategias (esa la aprendimos por las malas — con un nodo compartido, las consultas de posición de una estrategia se colaban en las de otra). Cada fill se registra junto con el valor de señal que lo produjo.
Cada mañana: replay y diff
Un job diario toma la ventana en paper de cada estrategia, pasa el código idéntico por el motor de backtesting sobre el mismo periodo con datos del catálogo y empareja los fills uno a uno: mismo lado, misma tolerancia de timestamp, mismo tamaño. El resultado no es una correlación ni una sensación. Es una tabla: emparejados, solo en paper, solo en replay. Una estrategia sana se sitúa en 54 de 55 emparejados. Una enferma te dice exactamente qué operación divergió y cuándo.
Qué se rompió, en el orden en que se rompió
- Fills durante el warmup. El nodo en vivo alimentaba histórico para calentar los indicadores — y las estrategias con handlers de barras personalizados operaban tan felices sobre él. Los backtests nunca veían esas entradas fantasma. La solución fue un guard en la capa de envío de órdenes, no un arreglo por estrategia, porque de lo contrario todas heredan el bug.
- Warmup secuencial multi-pata. Una estrategia cross-sectional calentaba un instrumento cada vez; cada pata veía a sus hermanas vacías y el ancla nunca se inicializaba. En vivo no operaba nada; en replay operaba bien. Cero operaciones emparejadas — pero solo el diff lo dijo en voz alta.
- Crash loops por precisión del tick. Los ticks de aggTrade en vivo llegan con una precisión distinta a la que esperaba el instrumento del sandbox. El nodo entraba en crash loop por una aserción que el backtest jamás podría disparar, porque las barras del catálogo ya vienen normalizadas.
- Amnesia tras reinicios. Los reinicios de proceso volvían a disparar la lógica de entrada sobre posiciones que ya existían — en una estrategia de rebalanceo, un reinicio se convertía silenciosamente en un rebalanceo. En trading en vivo eso no es una nota al pie sobre paridad; es una señal de alarma con dinero de por medio.
Fíjate en el patrón: ninguno de estos es un bug de señal. Todos son bugs de la frontera de ejecución — warmup, estado, precisión, reinicios. Es exactamente la clase de fallo ante la que los backtests son estructuralmente ciegos, porque en un backtest el motor es la frontera de ejecución.
Las asimetrías que mantenemos a propósito
Los dos mundos no son idénticos, y es deliberado. El backtest cobra un medio spread modelado más impacto de raíz cuadrada dentro del PnL; el paper paga el spread real en el precio del fill y no aplica modelo de impacto. Añadir el spread modelado al paper (o el real a los backtests) sería contarlo dos veces. Paridad significa mismas decisiones, mismos fills dentro de la tolerancia — no un PnL idéntico bit a bit. Saber qué diferencias son intencionadas y cuáles son bugs es la mayor parte de la disciplina.
Un backtest es una hipótesis. El paper trading es el experimento. La paridad de replay es el cuaderno de laboratorio que te pilla engañándote a ti mismo.
Si operas estrategias y no comparas de forma periódica el comportamiento en vivo contra el comportamiento replicado en replay, tienes toda una categoría de bugs que nunca has visto. Nosotros encontramos uno más o menos cada dos semanas, y cada uno de ellos era invisible desde dentro del backtest.
← Todos los artículos