Auditar los datos de interés abierto antes de interpretarlos · 3 / 5
Reproducir observaciones de OI según su disponibilidad y versión
Una marca temporal que indica qué instante describe un registro no demuestra cuándo podías utilizarlo. Conserva la disponibilidad y el historial de revisiones antes de reproducir una decisión basada en un umbral.
Athenum8 minActualizado:
A las 10:00:05, el registro posterior todavía no está disponible
El nuevo valor de A está disponible, pero el de B no. Combinar A=110 con el último B=200 produce 310 a partir de distintos tiempos de medición. Es una estimación con datos de diferente antigüedad, no el par sincronizado requerido. A la regla le falta una entrada disponible; no tiene una señal negativa válida. Un backtest que utiliza B=230 porque su etiqueta de medición indica 10:00 se ha adelantado 15 segundos respecto de esta decisión. Ordenar exclusivamente por tiempo de medición oculta ese error.
A las 10:00:25, el par recibido inicialmente cumple la condición
Han llegado las dos mediciones iniciales de las 10:00. Suman 340, un aumento de 40/300 = 13,333…%, por lo que se alcanza el umbral ilustrativo. Esto no demuestra que una operación pudiera ejecutarse al precio anterior del momento de medición. Un modelo de ejecución necesita cotizaciones disponibles después, cantidad, costes y sus propios supuestos temporales.
A las 10:00:45, una revisión cambia la observación reconstruida
El valor corregido de B ya está disponible. El par corregido suma 325, un aumento de 25/300 = 8,333…%, por debajo del umbral. Una base de datos que conserve únicamente el registro corregido final borraría retrospectivamente la marca anterior. Así podría hacer que una decisión en tiempo real pareciera imposible, aunque fuera coherente con la información recibida a las 10:00:25.
Conserva ambas versiones con sus tiempos de disponibilidad para reproducir lo que se observó entonces. Analizar los datos definitivos es otra pregunta válida, pero debe etiquetarse como tal. No compares silenciosamente una estrategia basada en lo observado con un benchmark de datos revisados e interpretes la diferencia como habilidad para operar.
Tarea y registro de observaciones
Distingue el instante que describe una medición del momento en que el sistema de investigación podía utilizarla. Este ejemplo sintético de dos plataformas emplea unidades de cantidad comparables contadas por un solo lado y relojes UTC. La hora de llegada significa que se ha recibido el registro completo y que el proceso de decisión puede usarlo. En una reproducción real habría que añadir cualquier retraso adicional de procesamiento.
La regla hipotética de revisión exige un par sincronizado de las 10:00 y marca un aumento de al menos el 10% respecto del par sincronizado de las 09:55. Es un activador de auditoría, no una instrucción para operar ni una afirmación sobre capacidad predictiva. El OI inicial es 300. El umbral numérico es 330.
| Plataforma | Hora de medición | Hora de llegada utilizable | OI | Versión |
|---|---|---|---|---|
| A | 09:55:00 | 09:55:02 | 100 | inicial |
| B | 09:55:00 | 09:55:03 | 200 | inicial |
| A | 10:00:00 | 10:00:02 | 110 | inicial |
| B | 10:00:00 | 10:00:20 | 230 | inicial |
| B | 10:00:00 | 10:00:40 | 215 | corrección |
Ampliar el diagrama- 10:00:05: par sincronizado no disponible
- 10:00:25: total inicial 340; umbral alcanzado
- 10:00:45: total corregido 325; umbral no alcanzado
Registro sintético UTC de mediciones, llegadas utilizables y correcciones. La información disponible para decidir cambia cuando llegan registros. El umbral ilustrativo es 330. Son resultados de auditoría, no operaciones ejecutadas ni latencias medidas de un proveedor.
El eje horizontal muestra la llegada utilizable en segundos desde las 10:00:00 UTC. Cada registro nuevo describe la misma medición de las 10:00. Las líneas muestran versiones disponibles, no una trayectoria continua del mercado. El signo de interrogación indica un dato sincronizado no disponible, no cero ni una prueba de umbral fallida.
B = 230: inicial. B = 215: corrección.
- 10:00:05: par sincronizado no disponible
- 10:00:25: total inicial 340; umbral alcanzado
- 10:00:45: total corregido 325; umbral no alcanzado
No reparar los tiempos con registros futuros
Arrastrar B=200 antes de la llegada de su nuevo valor oculta la antigüedad; insertar retrospectivamente B=230 antes de su llegada introduce información futura. Aplicar la corrección antes de las 10:00:40 introduce una versión posterior. Son tres errores distintos aunque todos se implementen como una unión por marcas temporales.
Antes de actuar
- Conserva por separado la hora de medición y la hora de llegada utilizable.
- Selecciona solo registros disponibles en el momento de la decisión.
- Preserva las correcciones y un orden fiable de versiones.
- Etiqueta las estimaciones de antigüedad mixta en lugar de llamarlas datos sincronizados.
- Distingue la disponibilidad de la señal de los supuestos de ejecución.
Comprueba lo aprendido
Cambia únicamente la llegada del valor inicial de B de las 10:00 a las 10:00:50 y mantén la llegada de su corrección a las 10:00:40. ¿Qué se conoce a las 10:00:25 y a las 10:00:45? ¿Debe la versión inicial más antigua que llega a las 10:00:50 sobrescribir la corrección?
Ver la respuesta explicada
A las 10:00:25, la medición requerida de B sigue sin estar disponible. A las 10:00:45, la corrección aporta B=215, por lo que el total sincronizado es 325 y la condición de marcado es falsa. Una corrección con una versión fiable no debe ser sobrescrita por una versión anterior que llega después. Sin una regla fiable que ordene versiones y correcciones, aísla el conflicto en lugar de suponer que el orden de llegada demuestra qué valor es autoritativo. Los campos y las reglas de revisión de proveedores reales requieren una verificación propia; este registro ficticio no afirma que Bybit exponga exactamente estos campos de versión o estos tiempos.