Tennis Live Analytics
Proyecto de datos en tiempo real y ML que estima la probabilidad de ganar de cada jugador en partidos de tenis en vivo, evaluado con paper trading.
Rol: Diseño y desarrollo del proyecto
- Python
- Machine Learning
- JSON
- CLI
Problema
Un partido de tenis cambia punto a punto, y con cada punto cambia también la probabilidad de que cada jugador gane el set y el partido. Seguir eso a mano es imposible, y hacerlo bien exige dos cosas a la vez: datos que llegan en tiempo real y un modelo que sepa traducirlos a una probabilidad creíble.
Lo interesante, como problema de ingeniería, es que tiene un juez objetivo. Una probabilidad bien calibrada se puede medir: si el modelo dice 70 % en cien situaciones parecidas, debería acertar en unas setenta. Eso permite evaluar el trabajo con números y no con impresiones.
Solución y funciones clave
Tennis Live Analytics es un experimento de datos en tiempo real y aprendizaje automático. Lee el marcador de partidos en vivo, estima la probabilidad de ganar el set y el partido, y deja un registro de cada señal para poder analizarla después. Está escrito en Python y se maneja desde la línea de comandos. No es un producto publicado ni tiene demo pública.
Estas son sus piezas principales:
- Lectura del marcador en vivo mediante adaptadores, uno por fuente de datos, que lo convierten a un formato común.
- Un modelo logístico por set, combinado con un puntaje Elo de cada jugador, para estimar la probabilidad en cada momento.
- Un motor de señales que reúne las estimaciones y las reglas, y escribe cada decisión en un registro JSONL.
- Backtest sobre partidos históricos y un reporte de calibración con el puntaje de Brier, que mide qué tan cerca están las probabilidades de lo que pasó de verdad.
- Evaluación con paper trading: todo se registra de forma simulada para comparar lo que el sistema decide con lo que ocurre.
- Objetivos de latencia para vigilar muchos partidos a la vez y reaccionar a un cambio de marcador en pocos segundos.
Cómo lo trabajo
El proyecto avanza por ciclos cortos. Primero mido, con el backtest y la calibración, qué tan bien funciona una regla o un modelo sobre datos propios. Después reviso un reporte con propuestas de cambio y su tamaño de muestra, y solo entonces apruebo lo que entra. Ese orden evita que una racha buena o mala me haga tomar decisiones por impulso.
También cuido que cada etapa se pueda medir por separado: la lectura de datos, la señal y el registro. Si la latencia sube, quiero saber en qué punto exacto se pierde el tiempo, no solo que algo está lento.
Lo cuento como lo que es: un experimento personal, útil para aprender y para mostrar cómo planteo un problema de datos con rigor. No lo presento como un negocio ni prometo resultados. Lo que sí puedo mostrar es el método: datos en vivo, un modelo simple y explicable, medición honesta y decisiones que se pueden justificar.
Arquitectura
Diagrama simplificado; omite detalles internos por privacidad.
- Los adaptadores convierten cada fuente de datos a un mismo formato de partido.
- El motor combina el modelo por set con Elo y escribe cada señal en un registro JSONL.
- Con ese registro se hacen el backtest, la calibración y la evaluación con paper trading.
Decisiones técnicas
Un adaptador por fuente de datos, todos hacia un mismo formato de partido.
- Por qué
- Cada fuente entrega el marcador con su propia forma. Si el motor de señales solo conoce un formato común, cambiar de fuente o añadir otra no toca la lógica del modelo.
- Trade-off
- Hay que escribir y mantener una capa de traducción por fuente, y cualquier dato que no cabe en el formato común se pierde o se complica.
Los cambios de reglas se proponen en un reporte y los aprobo yo antes de aplicarlos.
- Por qué
- Ajustar reglas mirando resultados recientes lleva casi siempre a un sobreajuste: la regla funciona con el pasado y falla con lo nuevo. Pedir una propuesta con su tamaño de muestra obliga a mirar si hay evidencia suficiente.
- Trade-off
- Iterar es más lento que dejar que el sistema se ajuste solo, a cambio de que cada cambio quede justificado y se pueda revertir.
El modelo se exporta a un archivo JSON plano y la inferencia se hace sin librerías de aprendizaje automático.
- Por qué
- En vivo importa la latencia y la simplicidad. Con los coeficientes en JSON, predecir es una suma ponderada que corre en microsegundos y sin dependencias pesadas.
- Trade-off
- Solo sirven modelos sencillos, como uno logístico. Probar una arquitectura más compleja obligaría a cambiar la forma de ejecutarlo.
Galería
Mi rol
Lo diseño y lo construyo yo solo como un experimento personal: desde la lectura del marcador en vivo hasta el modelo, el backtest y los reportes de calibración. Lo uso para practicar ingeniería de datos y aprendizaje automático sobre un problema que cambia cada segundo.