361132_es-ES

liliconcom

Fuga de datos

Hola

He leído varias publicaciones sobre la fuga de datos entre los grupos de prueba y de 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 valor faltante

 

2 en el caso de series de tiempo, evite la división aleatoria. Decida un punto de corte de tiempo y utilícelo para separar el conjunto de entrenamiento y prueba.

 

¿Algún comentario, sugerencia, lecturas útiles?

 

Felice

 

 

 

 

 

 

AnalíticaRe: fuga de datos

Mis 2 centavos:

Si tiene datos de series de tiempo, tiendo a pensar que su elemento 2 es el problema más grande a menos que esté haciendo mucha interpolación.Considere las fuentes de ruido en sus datos, si alguno de ellos ocurre en varias filas, o si las filas están vinculadas de alguna manera a las filas antes y después (monitoreando el nivel de un tanque a lo largo del tiempo, cuando el tanque tarda más de 1 fila en llegar 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 partes 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
• Use 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 consistan en 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 (más fácil, potencialmente aún expuestas al mismo riesgo )
• Utilizando los períodos identificados anteriormente, resuma cada una de esas ejecuciones en una sola fila, quizás usando promedios o desviaciones estándar de variables, o el explorador de datos funcionales de otros. (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, la validación y la prueba de las estadísticas de grupo representan expectativas mucho más razonables para el poder predictivo de los modelos.

Re: fuga de datos

Aquí está mi experiencia limitada.

El modelado es bastante complejo (elección del modelo correcto, preparación de datos, división de datos, ajuste de metadatos ...).

Un buen modelo robótico es independiente de la división, los metadatos, el tipo de modelo ...

Tanto la formación como el conjunto de pruebas deben ser representativos del proceso, pero no es necesario que el conjunto de pruebas sea tan completo. El entrenamiento / prueba es necesario para juzgar el resultado, como @ih ya mencionado.

Para dividir, la opción de estratificar se puede utilizar para controlar la división. Pero tanto para el modelado como para la división, necesita 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, solo esta prueba le da la respuesta, si no hay fugas. Pero, sinceramente, no me importarían las fugas, cuando puedo estar seguro de tener un buen modelo.

Re: fuga de datos

Me 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 tener validación y, si tiene suficientes datos, también un conjunto de datos de prueba por separado.Según mi experiencia, el sobreajuste es un problema menor con JMP de lo que podría ser, ya que varios de los otros parámetros de ajuste también ayudan a prevenirlo.Por ejemplo, con á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 nuevos datos.Creo que esto es especialmente importante para los datos de series de tiempo.

 

Las fugas son un tema completamente diferente, en mi opinión.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 para los clientes retenidos y faltará para aquellos que no retiene.En ese caso, el factor de las 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 las fugas se prevengan o detecten 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 fugas es una cuidadosa consideración de los factores y comprender 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.

 

Estoy interesado en escuchar lo que otros tienen que decir sobre esto.

Re: fuga de datos

Estimado @dale_lehman , sí tienes razón, lo mezclé, al menos formalmente, ya que pensaba solo en el objetivo general, tener un modelo bueno y robusto. Evitar fugas se define como un objetivo, no haber visto datos en el equipo de prueba. Encontré una explicación adicional aquí:

Fuga de datos en el aprendizaje automático. Cómo prevenir problemas que reducen el… | por Devin Soni:crown:| Hacia la ciencia de datos

Pero, ¿cómo hacer esto intencionalmente, cuando generalmente dividimos los conjuntos de entrenamiento y prueba al azar? Creo que en una categoría de modelo de proceso, el entrenamiento y el conjunto de pruebas provienen del mismo proceso. Al pensar en el pronóstico, puede ser diferente.

 

Re: fuga de datos

El artículo al que enlaza está muy confuso sobre la fuga de datos.Está mezclando la idea de rendimiento diferencial en el entrenamiento y los datos de validación / prueba (que está sobreajustado) con la falta de un límite claro entre los datos de entrenamiento y de prueba (que es una forma de pensar en las fugas).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.La fuga no explicaría eso; de hecho, si hay una fuga, también aparecería en los datos de entrenamiento.Además, si los datos de la prueba se seleccionan al azar, entonces debería producirse una fuga en los datos de entrenamiento siempre que estén en los datos de la prueba (y viceversa).Es el resultado 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 un tiempo aleatorio período ).La mayoría de los modelos de series de tiempo usarán datos pasados para pronosticar el futuro; la fuga sería si usara 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 evita el sobreajuste y las fugas en un modelo de serie temporal, se supone que el período de tiempo utilizado para construir el modelo es lo suficientemente similar al período que está tratando de pronosticar.Si los períodos no son similares (por ejemplo, si las fuerzas cambian y hacen que el modelo ya no sea relevante), entonces diría que el modelo no es muy bueno, pero no llamaría a eso fuga y probablemente tampoco lo llamaría sobreajuste.

Re: fuga de datos

Hola @ 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 perdidos, debes tener cuidado con eso. A veces, los datos que faltan son informativos y otras no. Además, la forma en que JMP imputa los valores podría no ser apropiada 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 la serie de tiempo, si realmente está usando una serie de tiempo para pronosticar y predecir eventos futuros en el tiempo, no creo que esté 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 para ver cuál se ajusta 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 guardar esas fórmulas a la tabla de datos y ver qué tan bien predicen los datos no utilizados. Tal vez podría usar un ajuste Y por X simple y mirar 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 prueba y entrenamiento. Luego, separo los datos de prueba en una tabla de datos completamente diferente para que los modelos que construyo no tengan posibilidad de usar 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 porción de validación de una plataforma, nuevamente dividiéndola 80/20 en entrenamiento / validación para reducir el sobreajuste. Después de generar varios modelos diferentes con diferentes plataformas, utilizo el conjunto de datos de prueba para ver qué modelo predice mejor los datos no utilizados / no vistos.

 

Espero que esto ayude,

DS

Re: fuga de datos

Este tutorial en Kaggle me pareció muy interesante.

Una vez más, se hace hincapié en evitar aplicar cualquier normalización e imputación de valores perdidos a los datos antes de dividirlos en el conjunto de entrenamiento y prueba.

 

https://www.kaggle.com/alexisbcook/data-leakage

 

Ciao Felice