¿Por qué solo tres particiones? (entrenamiento, validación, prueba)

Cuando intenta ajustar modelos a un gran conjunto de datos, el consejo común es dividir los datos en tres partes: el conjunto de datos de capacitación, validación y prueba.

Esto se debe a que los modelos generalmente tienen tres "niveles" de parámetros: el primer "parámetro" es la clase de modelo (por ejemplo, SVM, red neuronal, bosque aleatorio), el segundo conjunto de parámetros son los parámetros de "regularización" o "hiperparámetros" ( por ejemplo, coeficiente de penalización de lazo, elección del núcleo, estructura de la red neuronal) y el tercer conjunto son los que generalmente se consideran los "parámetros" (por ejemplo, coeficientes para las covariables).

Dada una clase de modelo y una selección de hiperparámetros, uno selecciona los parámetros eligiendo los parámetros que minimizan el error en el conjunto de entrenamiento. Dada una clase de modelo, uno ajusta los hiperparámetros al minimizar el error en el conjunto de validación. Uno selecciona la clase de modelo por rendimiento en el conjunto de prueba.

Pero, ¿por qué no más particiones? A menudo, uno puede dividir los hiperparámetros en dos grupos, y usar una "validación 1" para el primero y "validación 2" para el segundo. O incluso se podría tratar el tamaño de los datos de entrenamiento / datos de validación divididos como un hiperparámetro para ajustar.

¿Es esto ya una práctica común en algunas aplicaciones? ¿Existe algún trabajo teórico sobre la partición óptima de datos?

machine-learning model-selection data-mining

— charles.y.zheng
fuente

Respuestas:

Primero, creo que te equivocas acerca de lo que hacen las tres particiones. No realiza ninguna elección en función de los datos de prueba. Sus algoritmos ajustan sus parámetros en función de los datos de entrenamiento. Luego los ejecuta en los datos de validación para comparar sus algoritmos (y sus parámetros entrenados) y decidir sobre un ganador. Luego ejecuta el ganador en los datos de su prueba para obtener un pronóstico de qué tan bien funcionará en el mundo real.

No se validan los datos de entrenamiento porque eso se adaptaría demasiado a sus modelos. No se detiene en el puntaje del ganador del paso de validación porque ha estado ajustando iterativamente las cosas para obtener un ganador en el paso de validación, por lo que necesita una prueba independiente (a la que no se ha estado ajustando específicamente) para darle un idea de qué tan bien lo harás fuera de la arena actual.

En segundo lugar, creo que un factor limitante aquí es la cantidad de datos que tiene. La mayoría de las veces, ni siquiera queremos dividir los datos en particiones fijas, por lo tanto, CV.

— Wayne
fuente

El problema conceptual que tuve es que si estás comparando suficientes modelos, estás ajustando efectivamente los datos de validación cuando "decides un ganador" usando los datos de validación. Por lo tanto, todavía puede ser un punto en la partición de los datos de validación.

— charles.y.zheng

Creo que la capa de validación de entrenamiento y la capa de prueba de validación tienen diferentes propósitos en algún sentido, y que eventualmente tendrá que comparar modelos en un conjunto de validación común si va a declarar un ganador. Así que no estoy seguro de que las capas adicionales ayuden. (Aunque mi conocimiento no es lo suficientemente profundo como para saberlo realmente). Lo más parecido a su sugerencia es cómo se llevó a cabo la competencia de Netflix. Creo que usaron conjuntos de pruebas parciales para evitar que los equipos suban el gradiente del conjunto de pruebas, pero creo que es diferente.

— Wayne

@ user10882, su comentario no es correcto, ni tampoco Firebugs. Tanto los (1) parámetros del modelo (pesos, umbrales) como (2) los llamados parámetros "hiper" (número de capas ocultas, número de árboles de decisión), pueden tener una interpretación y una sensación muy diferentes, pero todos son parámetros que distinguen entre diferentes modelos . Use los datos de entrenamiento para optimizarlos a todos, use los datos de validación para evitar el ajuste excesivo y use la validación cruzada para asegurarse de que sus resultados sean estables. Los datos de prueba solo sirven para especificar el rendimiento esperado de su modelo, no lo use para aceptarlo / rechazarlo.

— Ytsen de Boer

n

$n$

@YtsendeBoer: bastante justo: si usa algo como una parada temprana basada en la validación, acepto que los límites se desdibujan, al menos en términos del procedimiento de optimización. Sin embargo, en mi opinión, esto no fusiona completamente el concepto de "hiperparámetro" con el de uno normal. Todavía hay muchas situaciones en las que son tratados de manera diferente, y también pienso en ellos de manera diferente en términos de sus roles en la definición de un modelo. De todos modos, espero que esta discusión haya sido útil para otros para ilustrar las (sutiles) diferencias y similitudes entre estos conceptos =).

— Ruben van Bergen el

Esta es una pregunta interesante, y descubrí que es útil con la respuesta de @Wayne.

Según tengo entendido, dividir el conjunto de datos en una partición diferente depende del propósito del autor y del requisito del modelo en la aplicación del mundo real.

Normalmente tenemos dos conjuntos de datos: entrenamiento y pruebas. El entrenamiento se usa para encontrar los parámetros de los modelos, o para ajustarlos. La prueba se utiliza para evaluar el rendimiento del modelo en datos no vistos (o datos del mundo real).

Si solo hacemos un paso en la capacitación, es obvio que hay una capacitación y un proceso de prueba (o validación).

Sin embargo, de esta manera, puede plantear el problema de sobreajuste cuando el modelo se entrena con un conjunto de datos, una vez. Esto puede conducir a la inestabilidad del modelo en el problema del mundo real. Una forma de resolver este problema es validar de forma cruzada (CV) el modelo en el conjunto de datos de entrenamiento. Eso significa que dividimos el conjunto de datos de entrenamiento en diferentes pliegues, mantenemos un pliegue para probar el modelo que está entrenado con otros pliegues. El ganador es ahora el que da la pérdida mínima (en función de nuestra propia función objetivo) en todo el proceso de CV. Al hacer esto, podemos asegurarnos de minimizar la posibilidad de un ajuste excesivo en el proceso de entrenamiento y seleccionar al ganador adecuado. El conjunto de prueba se utiliza nuevamente para evaluar al ganador en los datos invisibles.

— Dao Vu Hoang
fuente