Fuga de datosHola
He leído varias publicaciones sobre la fuga de datos entre los grupos de prueba y entrenamiento. Las sugerencias comunes para evitar fugas:
1 Divida la base de datos en el conjunto de entrenamiento y prueba antes de cualquier normalización, estandarización e imputación de valores faltantes.
2 en el caso de series temporales, evite la división aleatoria. Decida un punto de corte de tiempo y utilícelo para separar el conjunto de entrenamiento y de prueba.
¿Algún comentario, sugerencia, lecturas útiles?
Felice
Combinación y limpieza de datosRe: Fuga de datosHola @FR60 ,
Lamentablemente, no puedo confirmar que JMP haga eso en todas las plataformas o en todas las circunstancias.
Sé que en varias plataformas de modelado en JMP, cuando obtienes el informe de estimaciones, suele haber uno para estimaciones escaladas. También puedes ver esto en la plataforma Fit Y by X. Allí, si ajusta una línea, un polinomio o cualquier función a los datos, JMP devuelve una fórmula donde centra la función de ajuste. Entonces, si el ajuste es y=a*x+b*x^2 +c, la función que devuelve JMP es en realidad y=a*(x-x0)+b*(x-x1)^2+c, donde x0 y x1 son constantes. Hace esto a menos que usted le indique explícitamente que no lo haga.
Tengo entendido que JMP lo hace de esta manera porque las estimaciones para a, b y c son más precisas cuando se centran los datos que cuando no se centran. No me sorprendería que JMP hiciera esto para todas las plataformas, pero no lo sé. Codifican todos los datos al generar un DOE, por lo que incluso si ingresa sus valores reales, en la parte posterior del programa, utiliza valores codificados como -1, 0, 1 para configuraciones baja, media y alta en el DOE. . En realidad, no utiliza los números reales que podrías ingresar.
Para obtener una confirmación completa sobre el tema, le escribiría directamente a un miembro del personal de JMP o hablaría con el ingeniero de sistemas que brinda soporte en su área. Sería bueno saber si esto depende de la plataforma o si se hace de forma generalizada con JMP.
¡Gracias!,
DS
Re: Fuga de datosHola Diedrich
muchas gracias por tu comentario.
Acerca de la filtración de las pruebas de entrenamiento, la sugerencia reportada en varios blogs es dividir los datos antes de realizar cualquier preprocesamiento. Por ejemplo, si queremos normalizar todos los predictores entre 0 y 1, primero debemos dividir los datos y luego calcular el mínimo/máximo usando solo los datos de entrenamiento y luego normalizar con esos valores los datos de validación y prueba también. Lo mismo ocurre con otros tipos similares de gestión de datos, como la estandarización z o las imputaciones de valores faltantes. Por supuesto, si se utiliza la validación cruzada, es necesario implementar un cálculo más complicado siguiendo la misma metodología informada anteriormente.
Ahora pasemos a la pregunta. En tu correo escribiste:
" Ahora puedo ver por qué podría ser importante estandarizar/normalizar los datos después de la división, tiene sentido. Tengo entendido que JMP normalmente hace esto detrás de escena durante los cálculos de todos modos y luego simplemente lo vuelve a escalar para cuando se convierta en un informe. "
¿Esto significa que al usar JMP no necesitamos preocuparnos por la fuga de la prueba de entrenamiento porque los algoritmos jmp lo evitan internamente?
Si es así, esto es genial para mí.
¿Puedes confirmarlo?
gracias felicia
Re: Fuga de datosHola @FR60 ,
Puedo ver dónde podría haber surgido cierta confusión con respecto a esto. Hay dos tipos de divisiones y fugas a las que te refieres, como cuando hiciste referencia al artículo de Kaggle, y también @dale_lehman comentó sobre esto también.
Una división es asegurarse de que los datos utilizados para entrenar el modelo no incluyan también datos conocidos sólo en el resultado. Esa sería la "fuga de objetivo" de la que habla Kaggle. La otra es la "contaminación de la prueba del tren", donde desea asegurarse de que los datos de la prueba no lleguen a los conjuntos de entrenamiento o validación. El segundo era al que me refería más: mis conjuntos de datos normalmente no contienen columnas que se conocen después de las variables predictoras, por lo que no es común que me preocupe por la "fuga de objetivo", mientras que la "prueba de tren" contaminación" es.
Para JMP, tal vez sea más fácil pensar en las divisiones de datos como una división por filas == "contaminación de prueba de tren" versus una división por columnas == "fuga objetivo". Dependiendo de su estructura de datos, es posible que esté haciendo solo uno o ambos.
Ahora puedo ver por qué podría ser importante estandarizar/normalizar los datos después de la división, tiene sentido. Tengo entendido que JMP normalmente hace esto detrás de escena durante los cálculos de todos modos y luego simplemente lo vuelve a escalar para cuando se convierta en un informe.
Volviendo a su publicación original, supongo que depende de cómo deben dividirse sus datos y cómo están estructurados: si están estructurados verticalmente en el tiempo u horizontalmente. Esto podría determinar si realiza una división por filas o por columnas para los datos de tiempo. Pero aplicaría tipos similares de lógica para decidir cuándo cortar la serie temporal. Si hay un momento en el que los resultados pueden introducirse en el modelo como predictores, entonces definitivamente es necesario realizar cortes antes de esa fecha. No estoy seguro de cómo haría esto de la manera correcta para el problema de la "contaminación de la prueba del tren". Si está intentando realizar pronósticos o análisis de series de tiempo, JMP realmente funciona bastante bien utilizando todos los datos para eso. Usted puede decidir cuántos períodos predecir hacia adelante en función de los datos de tiempo históricos, y la salida tiene intervalos de confianza, etc.
¡Buen debate!,
DS
Re: Fuga de datosOtra publicación sobre fuga de datos durante el preprocesamiento de datos.
https://machinelearningmastery.com/preparación-de-datos-sin-fuga-de-datos/
Re: Fuga de datosEste tutorial en Kaggle me ha parecido muy interesante.
Nuevamente se hace hincapié en evitar aplicar cualquier normalización e imputación de valores faltantes a los datos antes de dividirlos en el conjunto de entrenamiento y prueba.
https://www.kaggle.com/alexisbcook/data-leakage
Felice
Re: Fuga de datosHola @FR60 ,
Mis pensamientos sobre los puntos específicos que mencionas:
1. Si va a estandarizar y/o normalizar los datos, creo que sería mejor hacerlo antes de dividir el conjunto de datos. En cuanto a la imputación de valores faltantes, deberá tener cuidado al respecto. A veces los datos que faltan son informativos y otras no. Además, la forma en que JMP imputa los valores puede no ser adecuada para sus datos específicos. Podría imputar incorrectamente los datos faltantes e introducir un comportamiento artificial en los datos que influirá incorrectamente en el modelo.
2. Para las series de tiempo, si realmente estás usando una serie de tiempo para pronosticar y predecir eventos futuros en el tiempo, no creo que estés dividiendo el conjunto de datos, al menos no con las plataformas de series de tiempo en JMP. , no tienen una columna de Validación en esas plataformas. Pero, si quisiera tener un conjunto de datos independiente para comparar diferentes modelos de pronóstico y ver cuál se adapta mejor a los datos futuros no utilizados, entonces sí, dividiría el conjunto de datos en algún momento y lo usaría para generar modelos de pronóstico y guardarlos. esas fórmulas a la tabla de datos y vea qué tan bien predicen los datos no utilizados. Tal vez podría usar un simple Ajuste Y por X y observar el valor R^2 para ver qué modelo predice mejor el resultado, o mirar los residuos entre los datos reales y modelados para ver cuál tiene la suma más pequeña de residuos o algo así. .
Sin embargo, en general, lo que hago es dividir la tabla de datos 80/20 en conjuntos de datos de entrenamiento y de prueba. Luego separo los datos de prueba en una tabla de datos completamente diferente para que los modelos que construyo no tengan posibilidad de utilizar los datos de prueba. Esto es más que simplemente "ocultar" y "excluir" datos y elimina cualquier posibilidad de que un algoritmo utilice accidentalmente los datos de prueba. Con la tabla de datos del conjunto de "entrenamiento", luego creo una columna de validación o simplemente uso la opción de parte de validación de una plataforma, dividiéndola nuevamente 80/20 en entrenamiento/validación para reducir el sobreajuste. Después de generar varios modelos diferentes con diferentes plataformas, uso el conjunto de datos de prueba para ver qué modelo predice mejor los datos no utilizados o no vistos.
Espero que esto ayude,
DS
Re: Fuga de datosEl artículo al que enlaza es muy confuso sobre la fuga de datos.Está mezclando la idea de rendimiento diferencial en los datos de entrenamiento y validación/prueba (lo cual es un sobreajuste) con la falta de un límite claro entre los datos de entrenamiento y de prueba (que es una forma de pensar en la fuga).Los dos conceptos son, creo, distintos.Cuando su modelo se ajusta a los datos de entrenamiento y no a los datos de prueba, es un ejemplo de sobreajuste.Las fugas no tendrían en cuenta eso; de hecho, si hay fugas, también aparecerían en los datos de entrenamiento.Además, si los datos de prueba se seleccionan al azar, entonces deberían producirse fugas en los datos de entrenamiento siempre que estén en los datos de prueba (y viceversa).Resulta de tener características informativas en los datos que se utilizan para predecir una respuesta, pero que no se pueden conocer cuando se realiza la predicción.
Las cosas son un poco menos claras con los datos de series de tiempo, ya que los datos de prueba no serían una selección aleatoria de todo el conjunto de datos (podría ser una selección de tiempo aleatoria). período ).La mayoría de los modelos de series de tiempo utilizarán datos pasados para pronosticar el futuro; la fuga se produciría si se utilizaran datos posteriores para pronosticar datos anteriores.El sobreajuste sería utilizar un período de tiempo para pronosticar un subconjunto del período de tiempo utilizado para construir el modelo, es decir, no mantener los períodos de tiempo separados.Incluso si se evitan el sobreajuste y las fugas en un modelo de series de tiempo, se supone que el período de tiempo utilizado para construir el modelo es suficientemente similar al período que se intenta pronosticar.Si los períodos no son similares (por ejemplo, si cambian las fuerzas que hacen que el modelo ya no sea relevante), entonces diría que el modelo no es muy bueno, pero no lo llamaría fuga y probablemente tampoco lo llamaría sobreajuste.
Re: Fuga de datosEstimado @dale_lehman Sí, tienes razón, lo mezclé, al menos formalmente, porque pensaba solo en el objetivo general: tener un modelo bueno y sólido. Evitar fugas se define como un objetivo, no haber visto ya datos en el conjunto de prueba. Encontré alguna explicación adicional aquí:
Fuga de datos en el aprendizaje automático. Cómo prevenir problemas que reducen la... | por Devin Soni :corona: | Hacia la ciencia de datos
Pero, ¿cómo hacer esto intencionalmente, cuando normalmente dividimos los conjuntos de entrenamiento y prueba al azar? Pienso más en una categoría de modelo de proceso, el entrenamiento y el conjunto de pruebas provienen del mismo proceso. Cuando se piensa en el pronóstico, puede ser diferente.
Re: Fuga de datosMe pregunto si estamos confundiendo dos cosas: fugas y sobreajuste.Creo que son bastante diferentes.El sobreajuste es siempre un problema potencial con el modelado predictivo y la forma habitual de evitarlo es contar con validación y, si se tienen suficientes datos, también con un conjunto de datos de prueba independiente.Según mi experiencia, el sobreajuste es un problema menor con JMP de lo que podría ser de otro modo, ya que varios otros parámetros de ajuste también ayudan a prevenirlo.Por ejemplo, con los árboles de decisión, establecer un tamaño de división mínimo relativamente alto ayudará a evitar el sobreajuste.Aún así, es una buena idea tener datos de prueba separados para evaluar si su modelo es capaz de producir predicciones realistas sobre datos nuevos.Creo que esto es especialmente importante para los datos de series temporales.
En mi opinión, las fugas son un tema completamente diferente.La fuga es un modelo mal especificado.Está utilizando factores que solo se conocerían al mismo tiempo que lo que está tratando de predecir.Por ejemplo, si está tratando de predecir la retención de clientes y uno de sus factores son las compras de este año, entonces solo tendrá datos de los clientes retenidos y faltarán los de aquellos que no retenga.En ese caso, el factor de compras de este año predecirá perfectamente la retención de clientes, pero ese no es un modelo útil.Eso es lo que creo que es la fuga.
No creo que se prevengan o detecten fugas al tener diferentes conjuntos de datos de entrenamiento/validación/prueba.Puede detectar fugas en cualquiera de esos 3: un modelo perfecto (o casi) en los datos de entrenamiento sería suficiente para sospechar que podría haber fugas.Creo que la mejor prevención de las fugas es una consideración cuidadosa de los factores y la comprensión de cómo y cuándo se miden.Si un modelo parece demasiado bueno para ser verdad, entonces podría deberse a una fuga (o podría ser simplemente un modelo muy bueno).Pero no creo que sea una pregunta respondida por ningún dispositivo técnico.
Me interesa escuchar lo que otros tienen que decir sobre esto.
Re: Fuga de datosAquí está mi experiencia limitada.
El modelado es bastante complejo (elección correcta del modelo, preparación de datos, división de datos, ajuste de metadatos...).
Un buen modelo robotizado es independiente de la división, los metadatos, el tipo de modelo...
Tanto el conjunto de capacitación como el de prueba deben ser representativos del proceso, pero el conjunto de prueba no necesita ser tan completo. Es necesario realizar entrenamiento/prueba para juzgar el resultado, ya que @ih ya mencionado.
Para dividir, la opción estratificar se puede utilizar para controlar la división. Pero para ambos, modelar y dividir, es necesario que el proceso sepa cómo hacerlo mejor.
Para modelos complejos, y cuando el resultado es crítico, intenté probar diferentes modelos, diferentes metadatos y diferentes columnas de validación. Cuando no hay una diferencia importante, no hay problema. Y esto es bastante fácil de hacer en JMP (Pro).
Al final, sólo esta prueba le dará la respuesta: si no hay fugas. Pero, sinceramente, no me importaría que se filtraran, cuando puedo estar seguro de que tengo un buen modelo.
Re: Fuga de datosMis 2 centavos:
Si tiene datos de series de tiempo, tiendo a pensar que el elemento 2 es el problema más importante, a menos que esté haciendo mucha interpolación.Considere las fuentes de ruido en sus datos, si alguna de ellas ocurre en varias filas, o si las filas están de alguna manera vinculadas a las filas anteriores y posteriores (monitoreando el nivel de un tanque a lo largo del tiempo, cuando se necesita más de 1 fila para que el tanque llegue a un nuevo estado estable, por ejemplo), entonces no puede dividir los datos por fila y esperar que los conjuntos de validación o prueba sean independientes del entrenamiento.
En su lugar, podría considerar dividir los datos en pruebas y validación en porciones más grandes, por ejemplo:
- Identificar nuevos períodos en los que el proceso realiza algún cambio "significativo" y mantener la duración de las ejecuciones en estado estable en el mismo grupo (más difícil pero mejor), o
- Utilice períodos lo suficientemente largos como para estar seguro de que representan diferentes condiciones de ejecución, pero lo suficientemente cortos como para que no consten de más de una condición de ejecución, y mantenga todas las filas de ese período en el mismo grupo de validación (es más fácil, aún potencialmente expuesto al mismo riesgo). )
- Utilizando los períodos identificados anteriormente, resuma cada una de esas ejecuciones en una sola fila, tal vez usando promedios o desviaciones estándar de variables, o el explorador de datos funcionales de otras. (mejor)
En cualquier caso, podría considerar excluir los períodos de transición entre grupos.
Mi experiencia personal: desde que comencé a utilizar al menos uno de estos métodos, las estadísticas de grupo de validación y prueba representan expectativas mucho más razonables para el poder predictivo de los modelos.
