Los tres montones: aprender, elegir, examinar

Ya tienes la sospecha instalada: medir el acierto sobre los datos con los que aprendiste no vale, porque es corregir el examen con las soluciones delante. La solución salta a la vista en cuanto la nombras. Si el problema es que el modelo examina con las mismas preguntas que estudió, apártale unas cuantas preguntas antes de que empiece a estudiar, guárdalas en un cajón y úsalas solo al final para ponerle el examen de verdad. Esa idea tan simple es la base de toda la validación honesta, y tiene un nombre: partir los datos.

La versión más conocida de esta idea parte los datos en dos montones: uno para entrenar y otro para probar. Funciona, y es mejor que no partir nada. Pero esconde un agujero que arruina muchos proyectos sin que nadie se dé cuenta, y para taparlo hace falta un tercer montón. Entender por qué hacen falta tres y no dos es lo que separa una medición que de verdad es honesta de una que solo lo parece. Vamos por partes, porque el matiz importa.

## El primer reparto: dos montones

Imagina que tienes 1.000 ejemplos con los que trabajar. Antes de empezar, barajas y apartas, por ejemplo, 200 a un cajón cerrado. Con los 800 restantes entrenas tu modelo: que aprenda todo lo que quiera de ellos. Cuando ya ha aprendido, abres el cajón, le pones delante los 200 que nunca vio y mides cuánto acierta. Como esos 200 son nuevos para él, el acierto que saques es una estimación honesta de lo bien que funcionará con datos que lleguen en el futuro. A los 800 se les llama conjunto de entrenamiento (los datos de los que aprende) y a los 200, conjunto de prueba o conjunto de test (los que examinan).

La proporción habitual es apartar entre un 20% y un 30% para la prueba. Ni mucho ni poco: si apartas demasiados, al modelo le quedan pocos ejemplos para aprender y sale peor; si apartas demasiado pocos, el examen tiene tan pocas preguntas que la nota depende de la suerte de cuáles tocaron. Y una regla que no se negocia: el reparto se hace al principio del todo, antes de mirar nada, y el conjunto de prueba se guarda como se guarda un sobre lacrado. No se abre para echar un vistazo, no se usa para ajustar, no se consulta «solo un momento». Se abre una vez, al final.

Esa disciplina del sobre lacrado parece exagerada hasta que entiendes lo fácil que es romperla sin querer. Imagina que abres la prueba, miras cómo va tu modelo, ves que falla en cierto tipo de casos y vuelves atrás a cambiar algo para que esos casos salgan mejor. Parece lo más razonable del mundo: has encontrado un fallo y lo arreglas. Pero acabas de usar la prueba para tomar una decisión sobre tu modelo, y por tanto ya no es un examen limpio. Si repites eso unas cuantas veces, tu modelo va cada vez mejor sobre la prueba, no porque mejore de verdad, sino porque lo has ido moldeando a la medida de esos ejemplos concretos. El sobre lacrado existe precisamente para que no puedas caer en esa tentación: si no lo abres hasta el final, no puedes dejar que te influya.

Conviene también entender por qué el reparto se hace barajando y no cortando por donde estén los datos. Los datos suelen venir ordenados por algo: por fecha de entrada, por identificador, por la categoría a la que pertenecen. Si cortaras el 20% final sin barajar, podrías llevarte a la prueba un trozo que no se parece al resto (todos los clientes de una región, todos los pedidos de un mismo mes, todos los casos de una misma clase), y entonces tu examen mediría algo distinto de lo que entrenaste. Barajar antes de cortar reparte los distintos tipos de ejemplo de forma pareja entre los montones, de modo que entrenamiento y prueba se parezcan y la comparación sea justa. Hay una excepción importante a esto, los datos con fecha, que verás más adelante y que lo cambia todo; pero para datos sin un orden que signifique algo, barajar es lo correcto.

## El agujero: ¿y si usas la prueba para elegir?

Aquí llega el matiz que casi nunca se explica bien, y es el corazón de la lección. Cuando construyes un modelo, rara vez haces uno solo. Pruebas varios: un árbol poco profundo y otro más profundo, un modelo y otro distinto, una variante con unas variables y otra con otras. Para cada uno quieres saber cuál va mejor, así que mides su acierto y te quedas con el que más acierta. Hasta aquí, razonable. El problema es sobre qué datos los mides.

Supón que mides todas esas variantes sobre el conjunto de prueba, el sobre lacrado, y eliges la que mejor sale. Acabas de romper el lacre. En el momento en que usas la prueba para decidir cuál es tu mejor modelo, la prueba deja de ser un examen limpio, porque has usado sus respuestas para tomar una decisión. Elegir la variante que mejor va sobre esos 200 ejemplos es, en pequeño, otra forma de ajustarte a esos 200 ejemplos. El modelo que elijas irá fenomenal sobre esa prueba concreta, no porque sea el mejor en general, sino porque es el que mejor encajó con las casualidades de esos 200. Y ya no te queda ningún examen limpio con el que comprobar si de verdad es bueno.

Es un error sutil porque no se parece a mirar las respuestas: nadie te dio la solución de cada ejemplo. Pero el efecto es el mismo. Cada vez que una decisión tuya se apoya en el resultado sobre un conjunto de datos, ese conjunto queda contaminado para medir, porque has dejado que influya en lo que construyes. Probar diez modelos sobre la prueba y quedarte con el mejor es como lanzar diez monedas y quedarte con la que salió cara: parece que has encontrado la buena, pero solo has encontrado la que tuvo suerte esa vez.

Vale la pena desarrollar esa analogía de las monedas, porque explica el mecanismo exacto. Supón que lanzas una sola moneda justa diez veces y cuentas las caras. A veces saldrán cuatro, a veces seis, de vez en cuando ocho. Si lanzas una única moneda y sale ocho de diez, podrías pensar que está trucada. Pero ahora imagina que lanzas cien monedas, todas justas, diez veces cada una, y te quedas con la que más caras sacó. Esa moneda ganadora habrá sacado nueve o diez caras casi seguro, no porque sea especial, sino porque, probando tantas, alguna tenía que tener suerte. Si te quedas con esa y proclamas que está trucada, te has engañado: la elegiste precisamente por su racha de suerte. Con los modelos pasa igual. Probar muchas variantes sobre un mismo conjunto y quedarte con la mejor hace que la ganadora lo sea, en parte, por haber encajado con las casualidades de ese conjunto. Y cuantas más variantes pruebes, más grande es ese efecto de suerte, igual que cuantas más monedas lances más extrema será la racha de la ganadora.

Por eso el daño de usar la prueba para elegir crece con el número de cosas que decides mirándola. Si solo comparas dos modelos, la contaminación es pequeña. Si pruebas veinte configuraciones distintas de un modelo y te quedas con la mejor sobre la prueba, la contaminación es seria: has dado veinte oportunidades a la suerte de inflar tu resultado. Y en un proyecto real tomas muchas más de veinte decisiones mirando resultados: qué variables incluir, cómo prepararlas, qué modelo usar, con qué ajustes. Todas esas decisiones, si se toman mirando la prueba, la van gastando poco a poco hasta dejarla inservible como examen honesto.

## La solución: tres montones

La forma de tener siempre un examen limpio al final es apartar un montón más. En vez de dos, se parte en tres: entrenamiento, validación y prueba. Cada uno tiene un trabajo distinto y no se mezclan. El de entrenamiento es para que el modelo aprenda. El de validación es para elegir entre tus variantes: pruebas el árbol poco profundo y el profundo sobre la validación, comparas y te quedas con el mejor. Y el de prueba, el sobre lacrado, no se toca hasta que ya has decidido tu modelo definitivo y no vas a cambiar nada más. Entonces, y solo entonces, lo abres y mides una vez. Ese número final es honesto porque la prueba nunca intervino en ninguna de tus decisiones.

La diferencia entre validación y prueba es exactamente la diferencia entre elegir y examinar. Con la validación eliges: la miras muchas veces, comparas opciones, te apoyas en ella para decidir. Precisamente por eso la validación también acaba un poco contaminada, porque la has usado para elegir, igual que antes se contaminaba la prueba. La diferencia es que eso no importa, porque el papel de la validación es ayudarte a elegir, no darte el número final. El número final lo da la prueba, que ha permanecido intacta mientras tú elegías con la validación. Tres montones, tres trabajos, y un examen que llega virgen al final.

Una forma de recordar quién hace qué es pensar en una oposición con tribunal. El montón de entrenamiento son los libros con los que estudias: los lees cuanto quieras, para eso están. El montón de validación son los exámenes de prueba que haces en casa para ver por dónde flojeas y decidir qué repasar: los repites muchas veces y te ayudan a elegir en qué centrarte, aunque de tanto hacerlos acabes conociéndolos. Y el montón de prueba es el examen oficial del tribunal: lo haces una sola vez, cuando ya has decidido que estás listo, y su nota es la que cuenta de verdad precisamente porque no lo habías visto antes. A nadie se le ocurriría presentarse diciendo que ya conoce las preguntas del tribunal; eso invalidaría la nota. Con los datos es idéntico: la nota del examen final solo vale si el examen llegó sin que lo hubieras tocado.

## Cómo se parte en código

La herramienta estándar para repartir se llama train_test_split, y vive en la librería scikit-learn, el conjunto de herramientas de modelado que usarás a diario. Hace una cosa muy concreta: baraja los ejemplos y los corta en dos trozos del tamaño que le pidas. Le pasas tus entradas y tu respuesta, le dices qué proporción quieres apartar, y te devuelve los dos trozos ya separados. Para conseguir tres montones se aplica dos veces: primero apartas la prueba del resto, y después partes ese resto en entrenamiento y validación.

1from sklearn.model_selection import train_test_split
2
3# Primero aparto la prueba (20%) del resto (80%)
4X_resto, X_test, y_resto, y_test = train_test_split(
5    X, y, test_size=0.2, random_state=42)
6
7# Despues parto el resto en entrenamiento (60%) y validacion (20%)
8# 0.25 del 80% restante es un 20% del total
9X_tr, X_val, y_tr, y_val = train_test_split(
10    X_resto, y_resto, test_size=0.25, random_state=42)

Merece la pena detenerse en ese random_state, porque es un detalle pequeño que evita mucho dolor de cabeza. Barajar es una operación con azar: cada vez que barajas, el reparto sale distinto. Si dejas que ese azar sea libre, dos ejecuciones del mismo código darán montones distintos, y por tanto números de acierto distintos, aunque no hayas cambiado nada del modelo. Eso hace imposible comparar: si pruebas una variante y el número sube, no sabrás si subió porque la variante es mejor o porque esta vez el reparto fue más amable. Al fijar random_state con un número concreto, le dices al azar que use siempre la misma semilla, de modo que el barajado salga idéntico cada vez. El número que elijas da igual; lo que importa es que sea fijo. A partir de ahí, cualquier cambio en el resultado es responsabilidad tuya, no de la suerte, y eso es lo que te deja comparar con sentido.

## Cuándo tres y cuándo bastan dos

La regla práctica es sencilla: necesitas los tres montones siempre que vayas a tomar alguna decisión mirando los resultados. Si vas a comparar varios modelos, o a ajustar algún valor del modelo probando opciones, o a elegir qué variables usar, todas esas son decisiones que gastan un montón, así que ese montón tiene que ser la validación, y la prueba queda aparte para el final. Si, en cambio, ya tienes decidido de antemano exactamente qué modelo vas a usar y no vas a elegir nada, no necesitas validación: entrenas con un montón y examinas con el otro. En la práctica, casi siempre eliges algo, así que casi siempre quieres tres.

Un apunte sobre cuándo entrenar el modelo definitivo con todo junto. Una vez has elegido tu modelo con la validación y lo has examinado con la prueba, para ponerlo de verdad en marcha conviene reentrenarlo usando todos los datos disponibles, incluidos los que habías apartado para validar y probar. ¿Por qué, si eso parece volver a mezclarlo todo? Porque a esas alturas ya no vas a medir nada más: el número honesto ya lo tienes, salió de la prueba. Reentrenar con todo solo busca que el modelo que despliegas aprenda del máximo de ejemplos posibles, para que sea lo mejor que puede ser. Primero mides con los montones separados para saber qué esperar; después, ya con el veredicto en la mano, aprovechas todos los datos para el modelo que de verdad se usará.

Partir en tres tiene un coste evidente, y conviene nombrarlo porque es el que abre la siguiente puerta: gastas datos. De cada ejemplo que apartas para validar o para probar, el modelo no aprende. Con 10.000 ejemplos no pasa nada, sobran para los tres montones. Pero cuando tienes pocos datos, apartar un 40% para validación y prueba significa dejar al modelo con muy poco para aprender, y encima la validación y la prueba tienen tan pocos ejemplos que su nota depende mucho de qué ejemplos cayeron en cada montón. Ese problema (medir honestamente cuando no te sobran datos) tiene su propia solución, y es lo siguiente que verás.

Ya sabes repartir los datos para medir sin engañarte. Pero todavía no has visto, con detalle, qué es exactamente eso contra lo que la validación te protege: ese modelo que va perfecto sobre lo que estudió y mal sobre lo nuevo. Tiene nombre, tiene una señal inequívoca para reconocerlo y tiene un mando con el que se controla. Es lo siguiente.