Fuga de datos: las dos formas

Volvamos al modelo del principio de todo esto: el que predecía las bajas de clientes con un 94% de acierto y resultó que leía una variable que solo se rellenaba cuando el cliente ya se había dado de baja. Ese error tiene nombre, y es el más caro y más difícil de ver de todo el oficio: fuga de datos. Ocurre cuando información que el modelo no debería tener se cuela en su entrenamiento, y el resultado es siempre el mismo: un acierto espectacular en tu examen y un fracaso rotundo en producción. Es el error que más proyectos ha hundido, y el que más cuesta detectar precisamente porque el síntoma, un número buenísimo, parece una buena noticia.

La fuga de datos toma dos formas distintas, y hay que aprender a distinguirlas bien, porque se detectan y se arreglan de maneras diferentes. La primera es una columna que contiene la respuesta, o un reflejo de ella. La segunda es un orden de operaciones que deja que el examen vea información del entrenamiento. Las dos dan el mismo síntoma (acierto irreal) y las dos son silenciosas: no lanzan ningún error, no rompen nada, solo te regalan un número falso. Vamos una por una.

## Forma 1: una columna que contiene la respuesta

La primera forma es la más intuitiva una vez la ves, y la más fácil de colar sin querer. Entre las variables que le das al modelo hay una que, en realidad, es la respuesta disfrazada, o algo que solo existe cuando la respuesta ya es conocida. El caso del principio es el ejemplo perfecto: para predecir si un cliente se dará de baja, incluir una variable como «días desde la cancelación» es tramposo, porque esa casilla solo tiene un valor cuando el cliente ya canceló. El modelo descubre enseguida que esa columna lo delata todo: si tiene valor, el cliente se fue; si está vacía, se quedó. No predice nada, mira la respuesta.

La trampa es que esta columna envenenada no siempre es tan evidente. A veces es un proxy: una variable que no es la respuesta, pero que está tan ligada a ella que solo se genera después de que ocurra lo que quieres predecir. Para predecir si alguien impagará un préstamo, una variable como «importe recuperado por el departamento de cobros» es una fuga, porque solo hay recuperación si hubo impago. Para predecir si un paciente tiene una enfermedad, usar «medicación recetada para esa enfermedad» es una fuga. La pregunta que las caza a todas es: en el momento en que de verdad tendría que hacer la predicción, ¿existiría ya el valor de esta variable? Si la respuesta es no, porque esa casilla solo se rellena después de conocerse el desenlace, es una fuga.

La palabra que da la pista en todos estos casos es temporal: la variable envenenada es la que se genera después, en el tiempo, de lo que quieres predecir. Un identificador que la empresa asigna al cerrar un expediente, un campo que solo rellena el departamento que actúa cuando el problema ya ocurrió, una fecha que no existe hasta que el desenlace se produce. Todas comparten que, en la línea de tiempo del caso, nacen después de la respuesta. Y por eso, en el instante en que de verdad tendrías que predecir, no estarían ahí. El modelo las usa durante el entrenamiento porque en los datos históricos sí están rellenas (ahí todo ya ocurrió), pero en producción, prediciendo sobre casos vivos aún sin desenlace, esas casillas estarían vacías, y el modelo se quedaría sin su chuleta.

Hay un ejemplo clásico que se cuenta para mostrar lo escurridiza que puede ser esta forma de fuga. En un hospital se construyó un modelo para predecir qué pacientes de neumonía tenían alto riesgo, y el modelo aprendió, entre otras cosas, que los pacientes asmáticos tenían MENOS riesgo de morir. Es absurdo: el asma debería empeorar las cosas, no mejorarlas. Lo que pasaba es que a los asmáticos, por ser considerados de más riesgo, se les ingresaba directamente en cuidados intensivos y recibían una atención agresiva, así que acababan muriendo menos. La variable escondía el efecto del tratamiento, no la gravedad real. No era una fuga tan descarada como una columna que copia la respuesta, pero enseña lo mismo: una variable puede llevar dentro información que no estará disponible, o que significa lo contrario de lo que parece, cuando el modelo trabaje de verdad. Entender qué significa cada columna y de dónde sale es parte del oficio, no un detalle.

El arreglo de esta forma es conceptual, no de código: hay que examinar cada variable y preguntarse si estaría disponible en el momento de predecir de verdad. Las que no, fuera. No hay una función que lo haga por ti, porque requiere entender qué significa cada columna y cuándo se genera. Por eso un acierto sospechosamente alto es la señal para ir a mirar las variables una a una: casi siempre hay una que delata la respuesta.

Hay un truco de detección que usan los profesionales cuando sospechan de esta fuga: mirar qué variables pesan más en el modelo. Casi todos los modelos permiten preguntarles en qué se apoyan más para decidir, y si una sola variable domina de forma aplastante, con mucha más influencia que todas las demás juntas, eso es una bandera roja enorme. Un patrón real del mundo rara vez depende tan abrumadoramente de un único dato; cuando una variable lo explica casi todo, lo más probable es que esa variable sea la respuesta disfrazada. No es una prueba definitiva, pero sí la primera piedra que levantar: ve a esa variable que lo domina todo y pregúntate si existiría en el momento de predecir. Muchas fugas de la forma 1 se cazan exactamente así.

## Forma 2: el orden de operaciones que contamina el examen

La segunda forma es más sutil y más fácil de cometer sin tener ni idea de que la estás cometiendo, porque no está en los datos sino en el orden en que haces las cosas. Antes de entrenar, casi siempre preparas los datos: rellenas los huecos con la media de una columna, pones todas las variables en una escala parecida, cosas así. La trampa aparece cuando haces esos cálculos sobre todos los datos a la vez, antes de partir en entrenamiento y prueba. Porque entonces el cálculo (la media que usas para rellenar, el escalado que aplicas) ha mirado también los datos de prueba, y les ha pasado información de ellos al entrenamiento sin que te des cuenta.

Esta forma es más difícil de ver que la primera porque la fuga no vive en ninguna columna que puedas señalar: vive en un número intermedio que calculaste y luego usaste. La media con la que rellenaste no es un dato que tengas delante en la tabla; es un valor que salió de los datos y se aplicó a ellos, y por eso pasa desapercibido. No hay una columna sospechosa que mirar, solo un paso del proceso hecho en el momento equivocado. Esa invisibilidad es lo que la hace tan común: cometerla no deja rastro en los datos, solo en el orden de tu código, y el orden de tu código no suele ser lo primero que revisas cuando el número sale bien.

Un ejemplo lo deja claro. Supón que hay huecos en una columna de ingresos y decides rellenarlos con la media de esa columna. Si calculas esa media sobre todos los datos (entrenamiento más prueba) y luego partes, la media que has usado incluye los ingresos del conjunto de prueba. El conjunto de prueba ha dejado su huella en un valor que acaba metido en el entrenamiento: la media. Tu examen ya no es limpio, porque sus datos han influido en cómo se preparó lo que el modelo aprendió. Es una fuga pequeña, a veces imperceptible en el número, pero es una fuga, y en problemas donde el escalado o el relleno importan mucho puede inflar el resultado de forma seria.

La clave para entender por qué esto cuenta como fuga está en una distinción fina pero importante: hay operaciones que miran el dato de cada fila por separado, y operaciones que aprenden algo del conjunto entero. Convertir una fecha en día de la semana, o pasar euros a miles de euros, mira cada fila por su cuenta: da igual cuántas filas haya o cuáles sean las demás, el resultado de una fila no depende de las otras. Esas operaciones puedes hacerlas antes de partir sin problema, porque ninguna fila aprende nada de ninguna otra. Pero calcular una media para rellenar, o calcular el mínimo y el máximo para poner todo en una escala de cero a uno, o decidir qué variables quedarte según cómo se relacionan con la respuesta, son operaciones que aprenden del conjunto: su resultado depende de todas las filas a la vez. Esas son las peligrosas, porque si las dejas ver la prueba, la prueba se cuela en lo que aprenden.

Y aquí está lo que hace esta forma tan traicionera: todo el mundo prepara los datos antes de pensar en partirlos. Es el orden natural de trabajo: primero limpias y arreglas tu tabla, rellenas huecos, pones las cosas en escala, y cuando ya la tienes bonita, la partes para entrenar y probar. Ese orden intuitivo es justo el equivocado. El orden correcto se siente al revés: primero partes, con la tabla todavía en bruto, y solo después preparas, aprendiendo lo que haga falta (la media, la escala) exclusivamente del trozo de entrenamiento. Cuesta porque va contra la costumbre, y por eso esta fuga se comete tantísimo, incluso por gente que sabe perfectamente lo que es. No es un problema de conocimiento, es un problema de orden de los gestos.

El arreglo de esta forma sí es de orden, y es una regla que no admite excepciones: cualquier cosa que se aprenda de los datos (la media para rellenar huecos, los valores para escalar, qué variables seleccionar) se calcula usando solo el conjunto de entrenamiento, y luego se aplica tal cual al conjunto de prueba. Primero partes, después calculas con el entrenamiento, y por último aplicas al examen lo que calculaste. El examen recibe la preparación, pero nunca participa en decidirla. Si inviertes ese orden (calcular antes de partir), fuga garantizada.

## Lo que comparten las dos formas

Aunque se detecten y se arreglen distinto, las dos formas de fuga comparten tres cosas que conviene grabar. La primera: dan el mismo síntoma, un acierto irreal, demasiado bueno para ser verdad. La segunda: son silenciosas, no lanzan ningún error ni rompen nada, así que ninguna herramienta te avisa; el código corre perfecto y el número sale precioso. Y la tercera, la que las hace tan caras: el desastre no aparece en tu examen, aparece en producción, cuando ya has desplegado el modelo y alguien está tomando decisiones con él. Para cuando se nota, el daño ya está hecho.

Esa tercera característica es la que de verdad distingue a la fuga del resto de errores de medición, y conviene entender bien por qué. Cuando mides mal por una partición floja o por confundir sobreajuste con infraajuste, el número que obtienes suele ser al menos del orden correcto: no es exacto, pero no te miente a lo grande. La fuga es distinta: te regala un número que puede estar a veinte o treinta puntos de la realidad, y lo hace con total aplomo, sin ninguna señal de alarma. Es la diferencia entre un termómetro un poco descalibrado, que te dice treinta y siete cuando son treinta y siete y medio, y uno estropeado que te dice que estás perfectamente mientras tienes cuarenta de fiebre. El primero molesta; el segundo es peligroso, porque te hace confiar justo cuando no deberías.

Por eso la defensa contra la fuga no puede ser una herramienta que la detecte sola, porque no existe tal herramienta: una fuga no es un error de código, es un malentendido sobre qué significan tus datos y en qué orden los tocas, y eso ninguna máquina lo ve por ti. La única defensa es un hábito mental, el reflejo que llevas toda esta etapa afilando. Ante cada variable, preguntarte si existiría en el momento de predecir. Ante cada preparación de datos, preguntarte si la hiciste antes o después de partir. Y, sobre todo, ante cada número sospechosamente bueno, no relajarte sino tensarte, porque la alegría de un acierto altísimo es, casi siempre, la primera fase de un fracaso que todavía no ha dado la cara.

Por eso la fuga de datos es la prueba definitiva de que el adversario eres tú. Nadie te la mete: la cometes tú, al construir las variables o al ordenar los cálculos, y tu propia comprobación te aplaude por ello, porque el número sale genial. La única defensa es el reflejo que llevas toda esta etapa entrenando: cuando un resultado sea sospechosamente bueno, no lo celebres, desconfía. Ve a mirar las variables una a una preguntándote si alguna conoce ya la respuesta, y revisa el orden de tus cálculos preguntándote si el examen pudo colarse en la preparación. Casi siempre, detrás de un 99%, hay una de estas dos fugas esperando a hundir el proyecto en producción.

## Lo que ya sabes, y lo que viene

Con esto cierras la primera mitad del camino hacia una validación honesta. Ya sabes por qué debes desconfiar de tu propio resultado, cómo repartir los datos en tres montones para medir sin mirarte las respuestas, cómo reconocer un modelo que memoriza por la brecha entre sus dos aciertos, cómo medir con honestidad cuando no te sobran datos rotando el examen, por qué el tiempo obliga a cortar en vez de sortear, y cuáles son las dos formas en que la respuesta se cuela y lo infla todo. Tienes, en resumen, las herramientas para conseguir una medición en la que puedas confiar.

Pero conseguir un número honesto es solo la mitad del trabajo. Falta la otra mitad, que es igual de resbaladiza: aprender a leer bien esa cifra. Un acierto del 92%, aun medido con toda la honestidad del mundo, puede ser un modelo excelente o un desastre, según qué porcentaje de los casos sea de una clase y de otra, según qué error cueste más caro, y según contra qué lo compares. El mismo número puede significar cosas opuestas. Ahora que sabes medir sin engañarte, el siguiente paso es saber qué significa de verdad lo que has medido, porque un número honesto mal interpretado hace tanto daño como uno falso. Eso es lo que viene.