mundial-2026-ml

El README de este repositorio decía que las features se construyen «sin fuga de datos». Es cierto para nueve de las catorce y falso para cinco, que se reparten en dos tipos distintos. Lo descubrí auditando el archivo después de haberlo escrito, y el segundo tipo lo encontré en una segunda pasada, cuando las métricas de arriba ya estaban publicadas.

Tipo uno: el snapshot del ranking FIFA, en tres variables. fifa_diff es la diferencia de puntos del ranking FIFA entre los dos equipos. El código carga un solo archivo de ranking, con fecha 2026-06-11, y lo consulta para cada fila del histórico:

home_fifa = fifa_latest.get(home, home_elo)
away_fifa = fifa_latest.get(away, away_elo)

Para un partido de 2004 eso significa que la variable arrastra información de veintidós años después. Es fuga de la difícil de ver: no viene del resultado de la propia fila —el elo_diff que va al lado sí está bien construido, se escribe después de emitir la fila— viene de una tabla que parecía estática y no lo es.

Y no es una variable, son tres. El mismo records.append escribe también fifa_diff_x_home_form y fifa_diff_x_away_form, que son literalmente fifa_diff multiplicado por la forma reciente de cada equipo: el snapshot entra intacto en las dos. Durante un tiempo declaré sólo fifa_diff y presenté las otras trece como limpias. Eso era la versión optimista del mismo error, y contarlo así es peor que no haber auditado, porque suena a que audité.

Tipo dos: la tasa de penales, en dos variables, y esta no la había declarado en ninguna parte. home_penalty_win_rate y away_penalty_win_rate no se calculan fila a fila. Se calculan una sola vez, sobre data/raw/shootouts.csv entero, antes de que empiece el bucle walk-forward:

wins = shootouts["winner"].value_counts()
games = pd.concat([shootouts["home_team"], shootouts["away_team"]]).value_counts()
penalty_win_rate = (wins / games).fillna(0.5).to_dict()

Un partido de 2001 recibe una tasa calculada con tandas de hasta el 7 de julio de 2026. De las 682 tandas del archivo, 168 —el 24,6 %— son de 2018 en adelante, es decir, en la ventana de prueba o más allá de ella: 150 caen dentro de 2018–2025 y 18 son de 2026, pasado su final. Esto no es un snapshot reutilizado como el anterior: es el resultado agregado de partidos que el modelo no debería haber visto, los mismos que tenía que predecir en la ventana de prueba. Es otra clase de fuga, y la clase importa, porque el arreglo también es otro.

Y por aquí es por donde el muro duro tiene el agujero que anuncié en la decisión 2. El corte filtra por la fecha de cada fila, así que ninguna fila posterior al 10 de junio de 2026 entra al entrenamiento ni a la evaluación; pero la tasa de penales se agrega antes de ese filtro y sobre el archivo completo, que incluye las cuatro tandas del propio Mundial 2026 posteriores al corte: Alemania-Paraguay y Países Bajos-Marruecos el 29 de junio, Australia-Egipto el 3 de julio y Suiza-Colombia el 7 de julio. Presenté ese corte como la garantía de que el torneo en curso no puede filtrarse al modelo que lo predice. Por esta ruta sí puede, y parcialmente lo hace.

Dos cosas que no voy a afirmar. No voy a afirmar que el efecto sea pequeño, porque no lo he medido para ninguna de las cinco. Y no voy a afirmar que el 59,96 % de arriba esté libre de ellas, porque no lo está: backtest.py relee el mismo match_features.csv, así que ese número, y el 0,879, el 0,517 y el 0,172 que van a su lado, están todos medidos con las cinco fugas dentro. Son un techo optimista, no una estimación limpia. Son los números que tengo, no los que me gustaría tener.

Lo que sí puedo decir es qué costaría arreglarlo y cómo se sabría el tamaño del daño. Para las tres del ranking hace falta la serie histórica del ranking FIFA por fecha de publicación, unirla a cada partido por su fecha con un merge_asof, y las dos interacciones se arreglan solas al arreglar el factor. Para las dos de penales hace falta mover la agregación dentro del bucle, acumulando cada tanda sólo después de emitir su fila, igual que el Elo. Y después volver a correr el backtest de ventana expansiva. Si la accuracy ponderada baja poco, esas cinco eran casi redundantes con elo_diff y el modelo nunca dependió de ellas. Si baja mucho, el número publicado era optimista y toca republicarlo. Las dos respuestas son útiles. Ninguna la tengo todavía.

outputs/calibration_report.csv tiene tres filas y dice algo incómodo:

El modelo sin calibrar gana en las tres. La selección se queda con sigmoid porque está escrita así:

best_method = min(("isotonic", "sigmoid"), key=lambda m: metrics[m]["brier"])

raw se mide, se imprime y se guarda en el reporte, pero no entra al min. Eso no es una decisión, es un descuido en el código de selección, y prefiero llamarlo por su nombre antes de defenderlo.

¿Debería entonces quitar la calibración? No estoy seguro, y ahí está la parte interesante. Quien consume estas probabilidades no es una métrica: es un simulador Monte Carlo que las muestrea 5.000 veces por torneo. Ahí no basta con que la probabilidad esté bien ordenada; importa que su nivel sea correcto, porque un modelo que dice 70 % donde la frecuencia real es 60 % produce demasiados campeones favoritos y las probabilidades de campeón salen sesgadas. El Brier mide las dos propiedades juntas en un solo número y por eso no responde esta pregunta.

La forma de responderla es descomponer el Brier en confiabilidad y resolución, o comparar directamente las probabilidades de campeón que produce el simulador con raw frente a con sigmoid. No lo he hecho. Hasta que lo haga, lo honesto es esto: la calibración está puesta por un argumento que suena bien y que no he verificado, y las métricas publicadas arriba son las del backtest, no las de este cuadro.

No hay un solo test_, no hay pytest.ini, no hay workflow. En un proyecto cuyo argumento central es «mi metodología de evaluación es honesta», la ausencia de pruebas es la crítica más justa que se le puede hacer: la construcción walk-forward de las features es exactamente el tipo de código que una prueba debería fijar, porque un cambio inocente en el orden de dos líneas reintroduce una fuga sin que nada se queje. Las cinco fugas de arriba son la prueba: en este repositorio no había nada que las fuera a atrapar salvo yo leyendo el archivo.

En el modo que simula el torneo completo, el sorteo del cuadro es aleatorio en vez de seguir las reglas reales de emparejamiento por grupo y confederación. Y las tandas de penales se resuelven con la tasa histórica de cada equipo, no con un modelo — la misma tasa agregada de una vez que arriba declaro como fuga. Las dos cosas ensanchan la incertidumbre de las probabilidades de campeón más allá de lo que sugiere el número de simulaciones.