Fuite de donnéesSalut
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 Divisez la base de données en ensemble de formation et de test avant toute normalisation, standardisation et imputation de valeur manquante
2 en cas de séries chronologiques, évitez la répartition aléatoire. Décidez d’un délai et utilisez-le pour séparer l’ensemble de formation et de test.
Des commentaires, des suggestions, des lectures utiles ?
Félice
Mélange et nettoyage des donnéesRe : Fuite de donnéesSalut @FR60 ,
Malheureusement, je ne peux pas confirmer que JMP le fait pour chaque plateforme ou dans toutes les circonstances.
Je sais que sur plusieurs plates-formes de modélisation dans JMP, lorsque vous obtenez le rapport d'estimations, il y en a souvent un pour les estimations mises à l'échelle. Vous pouvez également le voir sur la plateforme Fit Y by X. Là, si vous ajustez une ligne, un polynôme ou toute autre fonction aux données, JMP renvoie une formule dans laquelle il centre la fonction d'ajustement. Ainsi, si l'ajustement est y=a*x+b*x^2 +c, la fonction renvoyée par JMP est en fait y=a*(x-x0)+b*(x-x1)^2+c, où x0 et x1 sont des constantes. Il le fait sauf si vous lui dites explicitement de ne pas le faire.
Je crois comprendre que JMP procède de cette façon, car les estimations de a, b et c sont plus précises lorsque les données sont centrées que lorsqu'elles ne sont pas centrées. Je ne serais pas surpris si JMP faisait cela pour chaque plateforme, mais je ne sais pas. Ils encodent toutes les données lors de la génération d'un DOE, donc même si vous entrez vos valeurs réelles, sur le back-end du programme, il utilise des valeurs codées telles que -1, 0, 1 pour les paramètres bas, moyens et élevés dans le DOE. . Il n’utilise pas réellement les chiffres réels que vous pourriez introduire.
Pour obtenir une confirmation complète sur le sujet, j'écrirais directement à un membre du personnel de JMP ou je parlerais avec l'ingénieur système qui prend en charge votre région. Il serait bon de savoir s'il s'agit d'une chose dépendante de la plate-forme ou si elle est effectuée de manière généralisée avec JMP.
Merci!,
DS
Re : Fuite de donnéesSalut Diedrich
Merci beaucoup pour votre commentaire.
À propos de la fuite des tests de formation, la suggestion rapportée dans plusieurs blogs est de diviser les données avant d'effectuer un prétraitement des données. Par exemple, si nous voulons normaliser tous les prédicteurs entre 0 et 1, nous devons avant de diviser les données, puis calculer le min/max en utilisant uniquement les données d'entraînement, puis normaliser avec ces valeurs les données de validation et de test également. Même histoire pour d'autres types similaires de gestion de données comme la normalisation z ou les imputations de valeurs manquantes. Bien sûr, si la validation croisée est utilisée, un calcul plus compliqué doit être mis en œuvre en suivant la même méthodologie indiquée ci-dessus.
Passons maintenant à la question. Dans votre courrier vous avez écrit :
" Je peux voir maintenant pourquoi il pourrait être important de standardiser/normaliser les données après la scission, c'est logique. Je crois comprendre que JMP le fait généralement en coulisses pendant les calculs, puis le redimensionne simplement lorsqu'il est transformé en rapport. "
Cela signifie qu'en utilisant JMP, nous n'avons pas à nous soucier des fuites lors des tests de formation, car elles sont évitées en interne par les algorithmes jmp ?
Si c'est le cas, c'est génial pour moi.
Pouvez-vous confirmer s'il vous plaît ?
Merci Félice
Re : Fuite de donnéesSalut @FR60 ,
Je peux voir où une certaine confusion a pu se produire à ce sujet. Il existe deux types de divisions et de fuites auxquelles vous faites référence, comme lorsque vous avez fait référence à l'article de Kaggle, et également @dale_lehman a également commenté cela.
L'une des divisions consiste à s'assurer que les données utilisées pour entraîner le modèle n'incluent pas également des données connues uniquement au moment du résultat. Ce serait la « fuite cible » dont parle Kaggle. L'autre est la "contamination du test de train", dans laquelle vous voulez vous assurer que les données de test ne se retrouvent pas dans les ensembles de formation ou de validation. Le deuxième était celui auquel je faisais davantage référence : mes ensembles de données ne contiennent généralement pas de colonnes connues après les variables prédictives, donc la "fuite cible" n'est pas courante pour moi, alors que le "test de train" contamination" est.
Pour JMP, il est peut-être plus facile de considérer les répartitions des données comme une répartition par ligne == « contamination par test de train » ou une répartition par colonne == « fuite cible ». En fonction de votre structure de données, vous pouvez en faire un seul ou les deux.
Je peux voir maintenant pourquoi il pourrait être important de standardiser/normaliser les données après la scission, c'est logique. Je crois comprendre que JMP le fait généralement en coulisses pendant les calculs, puis le redimensionne simplement lorsqu'il est transformé en rapport.
Pour en revenir à votre message d'origine, je suppose que cela dépend de la façon dont vos données doivent être divisées et de la façon dont elles sont structurées : sont-elles structurées verticalement dans le temps ou horizontalement. Cela peut déterminer si vous effectuez une répartition par ligne ou par colonne pour les données temporelles. Mais j’appliquerais des types de logique similaires pour décider quand couper la série chronologique. S'il arrive un moment où les résultats peuvent être intégrés au modèle en tant que prédicteurs, alors vous devez absolument réduire avant cela. Je ne sais pas comment vous procéderiez de la bonne manière pour le problème de la « contamination par les tests de train ». Si vous essayez d'effectuer des prévisions ou des analyses de séries chronologiques, JMP fonctionne plutôt bien en utilisant toutes les données nécessaires. Vous pouvez décider du nombre de périodes à prédire en fonction des données temporelles historiques, et la sortie a des intervalles de confiance, etc.
Bonne discussion !,
DS
Re : Fuite de donnéesUn autre article sur les fuites de données lors du pré-traitement des données.
https://machinelearningmastery.com/data-preparation-without-data-leakage/
Re : Fuite de donnéesJ'ai trouvé ce tutoriel dans Kaggle très intéressant.
Il est encore une fois souligné qu'il faut éviter d'appliquer toute normalisation et imputation de valeurs manquantes aux données avant de les diviser en ensemble de formation et de test.
https://www.kaggle.com/alexisbcook/data-leakage
Ciao Felice
Re : Fuite de donnéesSalut @FR60 ,
Mes réflexions sur les points spécifiques que vous évoquez :
1. Si vous souhaitez standardiser et/ou normaliser les données, je pense qu'il serait préférable de le faire avant de diviser l'ensemble de données. En ce qui concerne l’imputation des valeurs manquantes, vous devrez y faire attention. Parfois, les données manquantes sont informatives et parfois non. De plus, la manière dont JMP impute les valeurs peut ne pas être adaptée à vos données spécifiques. Cela pourrait imputer incorrectement les données manquantes et introduire un comportement artificiel dans les données qui influencerait incorrectement le modèle.
2. Pour les séries chronologiques, si vous utilisez réellement une série chronologique pour prévoir et prédire des é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 de JMP. , ils n'ont pas de colonne Validation sur ces plateformes. Mais si vous souhaitez disposer d'un ensemble de données indépendant pour comparer différents modèles de prévision afin de déterminer lequel correspond le mieux aux données futures inutilisées, alors oui, je diviserais l'ensemble de données à un moment donné et je l'utiliserais pour générer des modèles de prévision et économiser. ces formules au tableau de données et voyez dans quelle mesure elles prédisent les données inutilisées. Vous pouvez peut-être utiliser un simple Ajustement 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 laquelle a la plus petite somme de résidus ou quelque chose comme ça .
En général, cependant, ce que je fais, c'est diviser le tableau de données 80/20 en ensembles de données de formation et de test. Je sépare ensuite les données de test dans un tableau de données complètement différent afin que les modèles que je construis n'aient aucune chance d'utiliser les données de test. Cela va bien au-delà du simple « masquage » et « exclusion » des données et élimine toute possibilité qu'un algorithme utilise accidentellement les données de test. Avec la table de données définie "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éesL'article vers lequel vous créez un lien est très confus au sujet des fuites de données.Cela mélange l'idée de performances différentielles sur les données de formation et de validation/test (ce qui constitue un surajustement) avec l'absence de frontière claire entre les données de formation et de test (ce qui est une façon de penser aux fuites).Les deux concepts sont, je crois, distincts.Lorsque votre modèle s'adapte aux données d'entraînement et non aux données de test, il s'agit d'un exemple de surajustement.Les fuites n’en tiendraient pas compte ; en fait, s’il y avait une fuite, elles apparaîtraient également dans les données d’entraînement.De plus, si les données de test sont sélectionnées de manière aléatoire, des fuites devraient se produire dans les données d'entraînement chaque fois qu'elles se trouvent dans les données de test (et vice versa).Cela résulte du fait que les données contiennent des caractéristiques informatives qui sont utilisées pour prédire une réponse, mais qui ne pouvaient pas être connues au moment où la prédiction est effectuée.
Les choses sont un peu moins claires avec les données de séries chronologiques, puisque les données de test ne seraient pas une sélection aléatoire de l'ensemble des données (il pourrait s'agir d'une période aléatoire). période ).La plupart des modèles de séries chronologiques utiliseront des données passées pour prévoir l'avenir. Il y aurait une fuite 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 sans 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 utilisée pour construire 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 et 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 n'appellerais probablement pas cela non plus un surapprentissage.
Re : Fuite de donnéesCher @dale_lehman , oui vous avez raison, j'ai mélangé les choses, au moins formellement, car je pensais juste à l'objectif global, avoir un modèle bon et robuste. Éviter les fuites est défini comme un objectif, ne pas avoir déjà vu de 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 le… | par Devin Soni :couronne: | Vers la science des données
Mais comment faire cela intentionnellement, alors que nous divisons habituellement les ensembles de formation et de test de manière aléatoire ? Je pense plutôt que dans une catégorie de modèle de processus, la formation et l'ensemble de tests proviennent tous deux du même processus. Quand on pense aux prévisions, cela peut être différent.
Re : Fuite de donnéesJe me demande si nous confondons deux choses : les fuites et le surapprentissage.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'éviter est d'avoir une validation, et si vous disposez de suffisamment de données, également un ensemble de données de test distinct.D'après mon expérience, le surajustement pose moins de problèmes avec JMP qu'il ne pourrait l'être autrement, car un certain nombre d'autres paramètres de réglage contribuent également à l'éviter.Par exemple, avec les arbres de décision, la définition d’une taille de répartition minimale relativement élevée permettra d’éviter le surajustement.Il est néanmoins judicieux de disposer de données de test distinctes pour évaluer si votre modèle est capable de produire des prédictions réalistes sur de nouvelles données.Je pense que cela est particulièrement important pour les données de séries chronologiques.
Les fuites sont un problème totalement différent, à mon avis.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 sur les clients retenus et elles manqueront pour ceux que vous ne fidélisez 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 être une fuite.
Je ne pense pas que les fuites soient évitées ou détectées en disposant de différents ensembles de données de formation/validation/test.Vous pouvez détecter une fuite 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 il peut s’agir simplement d’un très bon modèle).Mais je ne pense pas que ce soit une question résolue par des dispositifs techniques.
Je suis intéressé d'entendre ce que d'autres ont à dire à ce sujet.
Re : Fuite de donnéesVoici 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 robot est indépendant du fractionnement, des métadonnées, du type de modèle...
La formation et l’ensemble de tests doivent être représentatifs du processus, mais l’ensemble de tests 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 la modélisation et le fractionnement, vous devez savoir 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 simple à faire dans JMP (Pro).
Au final, seul ce test vous donne la réponse, s'il n'y a pas de fuite. Mais honnêtement, les fuites ne me dérangeraient pas, quand je peux être sûr d'avoir un bon modèle.
Re : Fuite de donnéesMes 2 centimes :
Si vous disposez de données de séries chronologiques, j'ai tendance à penser que votre élément 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 atteigne). 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 pourriez envisager de diviser les données en tests et validation en morceaux plus grands, par exemple :
- Identifier de nouvelles périodes pendant lesquelles le processus apporte des changements « significatifs » et conserver la durée des exécutions en régime permanent 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 différentes conditions d'exécution, mais suffisamment courtes pour ne pas comprendre 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). )
- À l'aide des 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 d'autres. (meilleur)
Dans les deux cas, vous pourriez 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 des groupes de validation et de test représentent des attentes beaucoup plus raisonnables quant au pouvoir prédictif des modèles.
