¿Validación cruzada en inglés simple?

¿Cómo describiría la validación cruzada a alguien sin antecedentes de análisis de datos?

Considere la siguiente situación:

Quiero tomar el metro para ir a mi oficina. Mi plan es tomar mi auto, estacionarme en el metro y luego tomar el tren para ir a mi oficina. Mi objetivo es tomar el tren a las 8.15 am todos los días para poder llegar a mi oficina a tiempo. Necesito decidir lo siguiente: (a) la hora a la que necesito salir de mi casa y (b) la ruta que tomaré para conducir a la estación.

En el ejemplo anterior, tengo dos parámetros (es decir, la hora de salida de casa y la ruta para tomar la estación) y necesito elegir estos parámetros para que llegue a la estación a las 8.15 a.m.

Para resolver el problema anterior, puedo probar diferentes conjuntos de 'parámetros' (es decir, una combinación diferente de horas de salida y ruta) los lunes, miércoles y viernes, para ver qué combinación es la 'mejor'. La idea es que una vez que haya identificado la mejor combinación, pueda usarla todos los días para lograr mi objetivo.

Problema de sobreajuste

El problema con el enfoque anterior es que puedo sobreajustar, lo que esencialmente significa que la mejor combinación que identifico puede, en cierto sentido, ser exclusiva de lunes, miércoles y viernes, y esa combinación puede no funcionar para el martes y el jueves. El sobreajuste puede suceder si en mi búsqueda de la mejor combinación de horarios y rutas exploto algún aspecto de la situación del tráfico los lunes / miércoles / viernes que no ocurre los martes y jueves.

Una solución para el sobreajuste: validación cruzada

La validación cruzada es una solución para el sobreajuste. La idea es que una vez que hemos identificado nuestra mejor combinación de parámetros (en nuestro caso, tiempo y ruta) probamos el rendimiento de ese conjunto de parámetros en un contexto diferente. Por lo tanto, es posible que también queramos probar el martes y el jueves para asegurarnos de que nuestras elecciones funcionen también para esos días.

Extendiendo la analogía a las estadísticas

En estadística, tenemos un problema similar. A menudo usamos un conjunto limitado de datos para estimar los parámetros desconocidos que no conocemos. Si sobreajustamos, nuestras estimaciones de parámetros funcionarán muy bien para los datos existentes, pero no tanto para cuando los usemos en otro contexto. Por lo tanto, la validación cruzada ayuda a evitar el problema anterior de sobreajuste al demostrarnos cierta seguridad de que las estimaciones de los parámetros no son exclusivas de los datos que utilizamos para estimarlas.

Por supuesto, la validación cruzada no es perfecta. Volviendo a nuestro ejemplo del metro, puede suceder que incluso después de la validación cruzada, nuestra mejor opción de parámetros no funcione un mes después debido a varios problemas (p. Ej., Construcción, cambios en el volumen de tráfico con el tiempo, etc.).

Creo que esto se describe mejor con la siguiente imagen (en este caso, que muestra la validación cruzada k-fold):

La validación cruzada es una técnica utilizada para proteger contra el sobreajuste en un modelo predictivo, particularmente en un caso donde la cantidad de datos puede ser limitada. En la validación cruzada, realiza un número fijo de pliegues (o particiones) de los datos, ejecuta el análisis en cada pliegue y luego promedia la estimación de error general.

"Evite aprender de memoria sus datos de entrenamiento asegurándose de que el modelo entrenado funcione bien con datos independientes".

Digamos que investigas algún proceso; ha reunido algunos datos que lo describen y ha creado un modelo (ya sea estadístico o ML, no importa). Pero ahora, ¿cómo juzgar si está bien? Probablemente se ajusta sospechosamente bien a los datos sobre los que se construyó, por lo que nadie creerá que su modelo es tan espléndido como cree.
La primera idea es separar un subconjunto de sus datos y usarlo para probar la construcción del modelo por su método en el resto de los datos. Ahora el resultado es definitivamente libre de sobreajuste, sin embargo (especialmente para conjuntos pequeños) podría haber sido (des) afortunado y dibujar (menos) casos más simples para probar, lo que hace que sea (más difícil) más fácil de predecir ... También su precisión / la estimación de error / bondad es inútil para la comparación / optimización del modelo, ya que probablemente no sepa nada sobre su distribución.
En caso de duda, use la fuerza bruta, así que simplemente repita el proceso anterior, reúna algunas estimaciones de precisión / error / bondad y promedie - y así obtendrá la validación cruzada. Entre una mejor estimación, también obtendrá un histograma, por lo que podrá aproximar la distribución o realizar algunas pruebas no paramétricas.
Y esto es todo; Los detalles de la división del tren de pruebas son la razón de los diferentes tipos de CV, pero a excepción de los casos raros y las pequeñas diferencias de resistencia, son bastante equivalentes. De hecho, es una gran ventaja, porque lo convierte en un método a prueba de balas; Es muy difícil engañarlo.

Como no tiene acceso a los datos de la prueba en el momento de la capacitación, y desea que su modelo tenga un buen desempeño en los datos de prueba no vistos, "finge" que tiene acceso a algunos datos de prueba submuestreando repetidamente una pequeña parte de sus datos de entrenamiento, mantenga este conjunto mientras entrena el modelo y luego trate el conjunto extendido como un proxy de los datos de prueba (y elija los parámetros del modelo que brinden el mejor rendimiento en los datos retenidos). Espera que al muestrear aleatoriamente varios subconjuntos de los datos de entrenamiento, pueda hacer que se vean como los datos de la prueba (en el sentido de comportamiento promedio) y, por lo tanto, los parámetros del modelo aprendidos también serán buenos para los datos de la prueba (es decir, su modelo generaliza bien para datos invisibles).