Sobre MíServiciosProyectosContacto
Blog·13/06/2026

Fugas entre train y test: el error que infla todas tus métricas

Una fila que aparece en entrenamiento y en test hace que el modelo parezca mejor de lo que es. Es fácil de introducir sin querer y difícil de ver a ojo. Dónde se cuela y cómo detectarlo antes de creerte tus números.

Fugas entre train y test: el error que infla todas tus métricas

El propósito del conjunto de test es estimar cómo se comportará el modelo con datos que no ha visto. En el momento en que un ejemplo aparece tanto en entrenamiento como en test, esa estimación deja de ser honesta: el modelo ya vio la respuesta, así que la métrica sube, pero no porque el modelo generalice mejor, sino porque está recordando.

Cómo se cuela una fuga sin que te des cuenta. Casi nunca es un fallo evidente. Es un `concat` de dos ficheros que ya se solapaban. Es un dataset regenerado y vuelto a partir sin fijar la semilla. Es duplicación en origen: el mismo evento registrado dos veces con un id distinto. Es normalización de texto que colapsa dos filas casi idénticas en la misma. En datos temporales, es partir al azar en lugar de por fecha, y entrenar con el futuro para predecir el pasado.

Por qué no la ves a ojo. Un solapamiento del 2% entre train y test puede subir tu accuracy un par de puntos, lo justo para que un modelo parezca mejor que la baseline sin serlo. Dos puntos no saltan a la vista en una tabla de resultados; parecen una mejora legítima. Y como la fuga infla exactamente la métrica que estás mirando, refuerza la conclusión equivocada.

Detección: exacta y normalizada. La comprobación mínima es buscar filas idénticas entre splits. La comprobación que de verdad pilla casos reales es la normalizada: comparar tras pasar a minúsculas, quitar puntuación y colapsar espacios, porque la duplicación suele venir con diferencias cosméticas. Lo que importa medir es qué fracción del conjunto de test aparece también en entrenamiento; esa fracción es tu fuga.

Contaminación contra benchmarks. El mismo problema aparece a mayor escala cuando entrenas o haces fine-tuning con datos que, sin saberlo, contienen ejemplos del benchmark con el que luego te evalúas. El resultado es un número espectacular que no se sostiene en producción. La defensa es la misma: comparar tu conjunto de entrenamiento contra el benchmark antes de confiar en la cifra.

Automaticé esta comprobación en splitcheck: compara dos o más splits, reporta el solapamiento exacto y normalizado, y falla en CI cuando la fuga supera un umbral. La regla que sigo es simple: ninguna métrica de test es creíble hasta que has comprobado que el test no contiene nada del entrenamiento.

Trabaja con JMWEB

Construyamos algo que llegue a producción.

Todo arranca con una conversación. Trae un dataset, un objetivo o un modelo que se atasca; del resto me ocupo yo.

Empezar un proyecto

Sigue leyendo:

hola@jmwebsoluciones.com