361132_fr-FR

liliconcom

Fuite de données

salut

J'ai lu plusieurs articles sur les fuites de données entre les groupes de test et de formation. Les suggestions courantes pour éviter les fuites:

 

1 Diviser la base de données en ensemble de formation et de test avant toute normalisation, standardisation et imputation des valeurs manquantes

 

2 en cas de séries chronologiques, éviter la répartition aléatoire. Décidez d'un point de coupure de temps et utilisez-le pour séparer l'ensemble d'entraînement et de test.

 

Des commentaires, suggestions, lectures utiles?

 

Felice

 

 

 

 

 

 

AnalytiqueRe: fuite de données

Mes 2 cents:

Si vous avez des données de séries chronologiques, j'ai tendance à penser que votre point 2 est le plus gros problème à moins que vous ne fassiez beaucoup d'interpolation.Tenez compte des sources de bruit dans vos données, si l'une d'entre elles se produit sur plusieurs lignes, ou si les lignes sont liées d'une manière ou d'une autre aux lignes avant et après (surveillance du niveau d'un réservoir au fil du temps, lorsqu'il faut plus d'une ligne pour que le réservoir se trouve un nouvel état stable, par exemple), vous ne pouvez pas diviser les données par ligne et vous attendre à ce que les ensembles de validation ou de test soient indépendants de la formation.

 

Au lieu de cela, vous pouvez envisager de diviser les données en tests et en validation en plus gros morceaux, par exemple:

• Identifier de nouvelles périodes où le processus apporte un changement `` significatif '' et conserver la durée des cycles à l'état d'équilibre dans le même groupe (plus difficile mais meilleur), ou
• Utilisez des périodes suffisamment longues pour que vous soyez sûr qu'elles représentent des conditions d'exécution différentes, mais suffisamment courtes pour qu'elles ne comportent pas plus d'une condition d'exécution, et conservez toutes les lignes de cette période dans le même groupe de validation (plus facile, potentiellement toujours exposé au même risque )
• En utilisant les périodes identifiées ci-dessus, résumez chacune de ces exécutions sur une seule ligne, peut-être en utilisant des moyennes ou des écarts-types de variables, ou l'explorateur de données fonctionnelles des autres. (meilleur)

Dans les deux cas, vous pouvez envisager d'exclure les périodes de transition entre les groupes.

 

Mon expérience personnelle: depuis que j'ai commencé à utiliser au moins une de ces méthodes, les statistiques de groupe de validation et de test représentent des attentes beaucoup plus raisonnables quant au pouvoir prédictif des modèles.

Re: fuite de données

Voici mon expérience limitée.

La modélisation est assez complexe (bon choix de modèle, préparation des données, fractionnement des données, réglage des métadonnées ...).

Un bon modèle Robost est indépendant du fractionnement, des métadonnées, du type de modèle ...

La formation et l'ensemble de test doivent être représentatifs du processus, mais l'ensemble de test n'a pas besoin d'être aussi complet. Une formation / un test est nécessaire pour juger du résultat, car @ih déjà mentionné.

Pour le fractionnement, l'option de stratification peut être utilisée pour contrôler le fractionnement. Mais pour les deux, la modélisation et le fractionnement, vous avez besoin que le processus sache comment le faire au mieux.

Pour les modèles complexes, et lorsque le résultat est critique, j'ai essayé de tester différents modèles, différentes métadonnées et différentes colonnes de validation. Lorsqu'il n'y a pas de différence majeure, il n'y a pas de problème. Et cela est assez facile à faire dans JMP (Pro).

À la fin, seul ce test vous donne la réponse, s'il n'y a pas de fuite. Mais honnêtement, cela ne me dérangerait pas les fuites, quand je peux être sûr d'avoir un bon modèle.

Re: fuite de données

Je me demande si nous confondons deux choses: les fuites et le surajustement.Je pense qu'ils sont assez différents.Le surajustement est toujours un problème potentiel avec la modélisation prédictive, et le moyen habituel de l'empêcher est d'avoir une validation, et si vous avez suffisamment de données, également un ensemble de données de test séparé.D'après mon expérience, le surajustement est moins un problème avec JMP qu'il ne le serait autrement, car un certain nombre d'autres paramètres de réglage aident également à l'éviter.Par exemple, avec les arbres de décision, la définition d'une taille de division minimale relativement élevée aidera à éviter le surajustement.Il est néanmoins judicieux de disposer de données de test séparées pour évaluer si votre modèle est capable de produire des prédictions réalistes sur de nouvelles données.Je pense que c'est particulièrement important pour les données de séries chronologiques.

 

À mon avis, les fuites sont une question entièrement différente.La fuite est un modèle mal spécifié.Vous utilisez des facteurs qui ne seraient connus qu'en même temps que ce que vous essayez de prédire.Par exemple, si vous essayez de prédire la fidélisation des clients et que l'un de vos facteurs est les achats de cette année, vous n'aurez que des données pour les clients retenus et il en manquera pour ceux que vous ne retenez pas.Dans ce cas, le facteur des achats de cette année prédira parfaitement la fidélisation de la clientèle, mais ce n'est pas un modèle utile.C'est ce que je pense des fuites.

 

Je ne pense pas que les fuites soient évitées ou détectées en ayant différents ensembles de données de formation / validation / test.Vous pouvez détecter des fuites dans l'un de ces 3: un modèle parfait (ou presque) sur les données d'entraînement suffirait à soupçonner qu'il pourrait y avoir une fuite.Je pense que la meilleure prévention des fuites consiste à examiner attentivement les facteurs et à comprendre comment et quand ils sont mesurés.Si un modèle semble trop beau pour être vrai, cela peut être dû à une fuite (ou, ce pourrait simplement être un très bon modèle).Mais je ne pense pas que ce soit une question à laquelle répond aucun appareil technique.

 

Je suis intéressé d'entendre ce que les autres ont à dire à ce sujet.

Re: fuite de données

chère @dale_lehman , oui vous avez raison, je l'ai mélangé, du moins formellement, en pensant à l'objectif global, pour avoir un modèle bon et robuste. Éviter les fuites est défini comme un objectif, ne pas avoir déjà vu des données dans l'ensemble de test. J'ai trouvé quelques explications supplémentaires ici:

Fuite de données dans l'apprentissage automatique. Comment éviter les problèmes qui réduisent… | par Devin Soni:crown:| Vers la science des données

Mais comment faire cela intentionnellement, alors que nous divisons généralement les ensembles d'entraînement et de test de manière aléatoire? Je pense plus que dans une catégorie de modèle de processus, la formation et l'ensemble de test proviennent tous deux du même processus. Quand on pense aux prévisions, cela peut être différent.

 

Re: fuite de données

L'article auquel vous créez un lien est très confus au sujet des fuites de données.Il mélange l'idée de performances différentielles sur les données d'entraînement et de validation / test (ce qui est surajustement) avec l'absence de frontière claire entre les données d'entraînement et de test (ce qui est une façon de penser aux fuites).Les deux concepts sont, je crois, distincts.Lorsque votre modèle correspond aux données d'entraînement et non aux données de test, c'est un exemple de surajustement.Une fuite ne rendrait pas compte de cela - en fait, s'il y a une fuite, elle apparaîtra également dans les données d'entraînement.En outre, si les données de test sont sélectionnées au hasard, une fuite devrait se produire dans les données d'apprentissage chaque fois qu'elles se trouvent dans les données de test (et vice versa).Il résulte de la présence de caractéristiques informatives dans les données qui sont utilisées pour prédire une réponse, mais qui ne pouvaient pas être connues au moment de la prédiction.

 

Les choses sont un peu moins claires avec les données de séries chronologiques, car les données de test ne seraient pas une sélection aléatoire de l'ensemble de données (il pourrait s'agir d'un moment aléatoire point final ).La plupart des modèles de séries chronologiques utiliseront des données passées pour prévoir le futur - une fuite se produirait si vous utilisiez des données ultérieures pour prévoir des données antérieures.Le surajustement consisterait à utiliser une période de temps pour prévoir un sous-ensemble de la période de temps utilisée pour construire le modèle - c'est-à-dire ne pas séparer les périodes de temps.Même si le surajustement et les fuites sont évités dans un modèle de série chronologique, on suppose que la période de temps utilisée pour créer le modèle est suffisamment similaire à la période que vous essayez de prévoir.Si les périodes ne sont pas similaires (par exemple, si les forces changent qui rendent le modèle plus pertinent), alors je dirais que le modèle n'est pas très bon, mais je n'appellerais pas cela une fuite et je n'appellerais probablement pas cela de surajustement non plus.

Re: fuite de données

salut @ FR60 ,

 

Mes réflexions sur les points spécifiques que vous soulevez:

 

1. Si vous envisagez de normaliser et / ou de normaliser les données, je pense qu'il serait préférable de le faire avant de fractionner l'ensemble de données. Quant à l'imputation des valeurs manquantes, vous devrez faire attention à ce sujet. Parfois, les données manquantes sont informatives et parfois non. En outre, la manière dont JMP impute les valeurs peut ne pas être appropriée pour vos données spécifiques. Cela pourrait imputer les données manquantes de manière incorrecte et introduire un comportement artificiel dans les données qui influencerait le modèle de manière incorrecte.

 

2. Pour la série chronologique, si vous utilisez vraiment une série chronologique pour prévoir et prédire les événements futurs dans le temps, je ne pense pas que vous diviseriez l'ensemble de données - du moins pas avec les plates-formes de séries chronologiques dans JMP , ils n'ont pas de colonne Validation dans ces plates-formes. Mais, si vous vouliez avoir un ensemble de données indépendant sur lequel comparer différents modèles de prévision pour voir lequel correspond le mieux aux données futures non utilisées, alors oui, je diviserais l'ensemble de données à un moment donné et l'utiliserais pour générer des modèles de prévision et enregistrer ces formules dans la table de données et voir à quel point elles prédisent les données inutilisées. Vous pouvez peut-être utiliser un simple Ajuster Y par X et regarder la valeur R ^ 2 pour voir quel modèle prédit le mieux le résultat, ou regarder les résidus entre les données réelles et modélisées pour voir lequel a la plus petite somme de résidus ou quelque chose comme ça .

 

En général, cependant, je divise la table de données 80/20 en ensembles de données d'entraînement et de test. Je sépare ensuite les données de test dans une table de données complètement différente afin que les modèles que je construis n'aient aucune chance d'utiliser les données de test. Ceci est plus que simplement "cacher" et "exclure" des données et élimine toute possibilité qu'un algorithme utilise accidentellement les données de test. Avec la table de données d'ensemble «formation», je crée ensuite une colonne de validation ou j'utilise simplement l'option de partie validation d'une plate-forme, en la divisant à nouveau 80/20 en formation / validation afin de réduire le surajustement. Après avoir généré plusieurs modèles différents avec différentes plates-formes, j'utilise ensuite l'ensemble de données de test pour voir quel modèle prédit le mieux les données inutilisées / invisibles.

 

J'espère que cela t'aides,

DS

Re: fuite de données

J'ai trouvé ce tutoriel dans Kaggle très intéressant.

On insiste à nouveau pour éviter d'appliquer toute normalisation et imputation des valeurs manquantes aux données avant de les diviser en ensemble d'apprentissage et de test.

 

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

 

Ciao Felice