361132_de-DE

liliconcom

Datenlecks

Hallo

Ich habe mehrere Beiträge über Datenlecks zwischen den Test- und Trainingsgruppen gelesen. Die häufigsten Vorschläge zur Vermeidung von Leckagen:

 

1 Teilen Sie die Datenbank vor der Normalisierung, Standardisierung und Imputation fehlender Werte in Trainings- und Testsätze auf

 

2 Vermeiden Sie bei Zeitreihen die zufällige Aufteilung. Legen Sie einen Zeitschnittpunkt fest und nutzen Sie ihn, um den Trainings- und Testsatz zu trennen.

 

Irgendwelche Kommentare, Vorschläge, nützliche Lektüre?

 

Felice

 

 

 

 

 

 

Datenmischung und -bereinigungBetreff: Datenleck

Hallo @FR60 ,

 

Leider kann ich nicht bestätigen, dass JMP dies für jede Plattform und unter allen Umständen tut.

 

Ich weiß, dass es in mehreren Modellierungsplattformen in JMP beim Abrufen des Schätzungsberichts oft einen für skalierte Schätzungen gibt. Das sieht man auch an der Fit Y by X-Plattform. Wenn Sie dort eine Linie, ein Polynom oder eine andere Funktion an die Daten anpassen, gibt JMP eine Formel zurück, in der die Anpassungsfunktion zentriert wird. Wenn die Anpassung also y=a*x+b*x^2 +c ist, ist die von JMP zurückgegebene Funktion tatsächlich y=a*(x-x0)+b*(x-x1)^2+c, wobei x0 und x1 sind Konstanten. Dies geschieht, es sei denn, Sie weisen ausdrücklich darauf hin, dass dies nicht der Fall sein soll.

 

Soweit ich weiß, geht JMP so vor, weil die Schätzungen für a, b und c genauer sind, wenn die Daten zentriert werden, als wenn sie nicht zentriert werden. Es würde mich nicht wundern, wenn JMP dies für jede Plattform tun würde, aber ich weiß es nicht. Sie kodieren alle Daten beim Generieren eines DOE. Selbst wenn Sie also Ihre tatsächlichen Werte im Back-End des Programms eingeben, werden kodierte Werte wie -1, 0, 1 für niedrige, mittlere und hohe Einstellungen im DOE verwendet . Dabei werden nicht die tatsächlichen Zahlen verwendet, die Sie möglicherweise eingeben.

 

Um eine umfassende Bestätigung zu diesem Thema zu erhalten, würde ich direkt an einen JMP-Mitarbeiter schreiben oder mit dem Systemingenieur sprechen, der Ihren Bereich unterstützt. Es wäre gut zu wissen, ob dies eine plattformabhängige Sache ist oder flächendeckend mit JMP erfolgt.

 

Danke!,

DS

Betreff: Datenleck

Hallo Diedrich

vielen Dank für deinen Kommentar.

In Bezug auf die Leckage bei Trainingstests wird in mehreren Blogs vorgeschlagen, die Daten aufzuteilen, bevor eine Datenvorverarbeitung durchgeführt wird. Wenn wir beispielsweise alle Prädiktoren zwischen 0 und 1 normalisieren möchten, sollten wir vorher die Daten aufteilen und dann die Min/Max-Werte berechnen, indem wir nur die Trainingsdaten verwenden, und dann mit diesen Werten auch die Validierungs- und Testdaten normalisieren. Das Gleiche gilt für andere ähnliche Arten der Datenverwaltung wie die Z-Standardisierung oder die Imputation fehlender Werte. Wenn die Kreuzvalidierung verwendet wird, muss natürlich eine kompliziertere Berechnung nach der gleichen oben beschriebenen Methodik durchgeführt werden.

Kommen wir nun zur Frage. In Ihrer Mail haben Sie geschrieben:

" Ich verstehe jetzt, warum es sinnvoll sein könnte, die Daten nach der Aufteilung zu standardisieren/normalisieren. Soweit ich weiß, macht JMP dies normalerweise ohnehin im Hintergrund während der Berechnungen und skaliert es dann einfach neu, wenn es in einen Bericht umgewandelt wird "

Bedeutet das, dass wir uns bei der Verwendung von JMP keine Gedanken über Lecks im Trainingstest machen müssen, da diese intern durch JMP-Algorithmen vermieden werden?

Wenn ja, ist das großartig für mich.

Können Sie das bitte bestätigen?

 

Danke Felice

Betreff: Datenleck

Hallo @FR60 ,

 

Ich kann mir vorstellen, dass diesbezüglich einige Verwirrung entstanden sein könnte. Es gibt zwei Arten von Spaltungen und Lecks, auf die Sie sich beziehen, als Sie auf den Artikel bei Kaggle verwiesen haben, und auch @dale_lehman habe dazu auch Stellung genommen.

 

Eine Aufteilung besteht darin, sicherzustellen, dass die zum Trainieren des Modells verwendeten Daten nicht auch Daten umfassen, die erst beim Ergebnis bekannt sind. Das wäre das „Target Leakage“, von dem Kaggle spricht. Das andere ist die „Train-Test-Kontamination“, bei der Sie sicherstellen möchten, dass die Testdaten nicht in die Trainings- oder Validierungssätze gelangen. Das zweite war das, auf das ich mich eher bezog – meine Datensätze enthalten normalerweise keine Spalten, die nach den Prädiktorvariablen bekannt sind, sodass ich mir über „Ziellecks“ normalerweise keine Sorgen mache, wohingegen der „Zugtest Kontamination“ ist.

 

Für JMP ist es vielleicht einfacher, sich die Datenaufteilungen entweder als zeilenweise Aufteilung == „Train-Test-Kontamination“ oder als spaltenweise Aufteilung == „Zielleckage“ vorzustellen. Abhängig von Ihrer Datenstruktur führen Sie möglicherweise nur eine oder beide Aktionen aus.

 

Ich verstehe jetzt, warum es sinnvoll sein könnte, die Daten nach der Aufteilung zu standardisieren/normalisieren. Soweit ich weiß, macht JMP dies normalerweise ohnehin im Hintergrund während der Berechnungen und skaliert es dann einfach neu, wenn es in einen Bericht umgewandelt wird.

 

Um auf Ihren ursprünglichen Beitrag zurückzukommen: Ich schätze, es hängt davon ab, wie Ihre Daten aufgeteilt werden müssen und wie sie strukturiert sind – ob sie zeitlich vertikal oder horizontal strukturiert sind. Dadurch kann bestimmt werden, ob Sie die Zeitdaten zeilenweise oder spaltenweise aufteilen. Aber ich würde eine ähnliche Logik anwenden, um zu entscheiden, wann die Zeitreihe gekürzt werden soll. Wenn es einen Zeitpunkt gibt, an dem Ergebnisergebnisse möglicherweise als Prädiktoren in das Modell eingespeist werden, müssen Sie auf jeden Fall vorher eine Kürzung vornehmen. Ich bin mir nicht sicher, wie Sie dies bei dem Problem der „Kontamination durch Zugtests“ richtig machen würden. Wenn Sie Prognosen oder Zeitreihenanalysen durchführen möchten, funktioniert JMP tatsächlich ziemlich gut, wenn alle Daten dafür verwendet werden. Sie können anhand historischer Zeitdaten entscheiden, wie viele Zeiträume Sie in der Zukunft vorhersagen möchten, und die Ausgabe verfügt über Konfidenzintervalle usw.

 

Gute Diskussion!,

DS

Betreff: Datenleck

Ein weiterer Beitrag zum Thema Datenlecks während der Datenvorverarbeitung.

 

https://machinelearningmastery.com/data-preparation-without-data-leakage/

Betreff: Datenleck

Ich fand dieses Tutorial in Kaggle sehr interessant.

Auch hier wird betont, dass keine Normalisierung und Imputation fehlender Werte auf Daten angewendet werden soll, bevor diese in Trainings- und Testdatensätze aufgeteilt werden.

 

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

 

Ciao Felice

 

Betreff: Datenleck

Hallo @FR60 ,

 

Meine Gedanken zu den spezifischen Punkten, die Sie ansprechen:

 

1. Wenn Sie die Daten standardisieren und/oder normalisieren möchten, wäre es meiner Meinung nach am besten, dies vor der Aufteilung des Datensatzes zu tun. Was die Imputation fehlender Werte betrifft, sollten Sie hier vorsichtig sein. Manchmal sind fehlende Daten informativ und manchmal nicht. Außerdem ist die Art und Weise, wie JMP die Werte imputiert, möglicherweise nicht für Ihre spezifischen Daten geeignet. Dadurch werden die fehlenden Daten möglicherweise falsch unterstellt und ein künstliches Verhalten in die Daten eingeführt, das das Modell falsch beeinflusst.

 

2. Was die Zeitreihen betrifft: Wenn Sie tatsächlich eine Zeitreihe verwenden, um zukünftige Ereignisse rechtzeitig vorherzusagen und vorherzusagen, würden Sie meiner Meinung nach den Datensatz nicht aufteilen – zumindest nicht mit den Zeitreihenplattformen in JMP , sie haben auf diesen Plattformen keine Validierungsspalte. Wenn Sie jedoch einen unabhängigen Datensatz haben möchten, um verschiedene Prognosemodelle zu vergleichen, um herauszufinden, welches am besten zu zukünftigen, ungenutzten Daten passt, dann würde ich den Datensatz irgendwann aufteilen und daraus Prognosemodelle erstellen und speichern Fügen Sie diese Formeln in die Datentabelle ein und sehen Sie, wie gut sie die nicht verwendeten Daten vorhersagen. Sie könnten vielleicht eine einfache Anpassung von Y nach .

 

Im Allgemeinen teile ich die Datentabelle jedoch im Verhältnis 80/20 in Trainings- und Testdatensätze auf. Anschließend trenne ich die Testdaten in eine völlig andere Datentabelle auf, sodass die von mir erstellten Modelle keine Chance haben, die Testdaten zu verwenden. Dies ist mehr als nur das bloße „Verstecken“ und „Ausschließen“ von Daten und schließt jede Möglichkeit aus, dass ein Algorithmus versehentlich die Testdaten verwendet. Mit der Datentabelle „Training“ erstelle ich dann entweder eine Validierungsspalte oder verwende einfach die Validierungsteiloption einer Plattform und teile sie wiederum 80/20 in Training/Validierung auf, um eine Überanpassung zu reduzieren. Nachdem ich mehrere verschiedene Modelle mit unterschiedlichen Plattformen generiert habe, verwende ich dann den Testdatensatz, um zu sehen, welches Modell die ungenutzten/unsichtbaren Daten am besten vorhersagt.

 

Hoffe das hilft,

DS

Betreff: Datenleck

Der Artikel, auf den Sie verlinken, ist sehr verwirrt über Datenlecks.Es verwechselt die Idee einer unterschiedlichen Leistung bei Trainings- und Validierungs-/Testdaten (was eine Überanpassung darstellt) mit dem Fehlen einer klaren Grenze zwischen Trainings- und Testdaten (was eine Möglichkeit ist, sich Leckagen vorzustellen).Die beiden Konzepte sind meines Erachtens unterschiedlich.Wenn Ihr Modell an die Trainingsdaten und nicht an die Testdaten angepasst ist, ist das ein Beispiel für eine Überanpassung.Leckage würde dies nicht erklären – tatsächlich würde eine Leckage auch in den Trainingsdaten auftauchen.Wenn die Testdaten außerdem zufällig ausgewählt werden, sollte es bei den Trainingsdaten immer dann zu Lecks kommen, wenn sie in den Testdaten vorhanden sind (und umgekehrt).Dies resultiert aus informativen Merkmalen in den Daten, die zur Vorhersage einer Reaktion verwendet werden, die jedoch zum Zeitpunkt der Vorhersage nicht bekannt waren.

 

Bei Zeitreihendaten ist die Sache etwas weniger klar, da die Testdaten keine zufällige Auswahl des gesamten Datensatzes wären (es könnte sich um eine zufällige Zeit handeln). Zeitraum ).Die meisten Zeitreihenmodelle verwenden vergangene Daten, um die Zukunft vorherzusagen. Wenn Sie spätere Daten verwenden würden, um frühere Daten vorherzusagen, käme es zu einem Verlust.Eine Überanpassung würde bedeuten, einen Zeitraum zu verwenden, um eine Teilmenge des Zeitraums vorherzusagen, der zum Erstellen des Modells verwendet wurde – das heißt, die Zeiträume nicht getrennt zu halten.Selbst wenn Überanpassung und Leckagen in einem Zeitreihenmodell vermieden werden, wird davon ausgegangen, dass der zur Erstellung des Modells verwendete Zeitraum dem Zeitraum, den Sie prognostizieren möchten, hinreichend ähnlich ist.Wenn die Perioden nicht ähnlich sind (z. B. wenn sich Kräfte ändern, die das Modell nicht mehr relevant machen), würde ich sagen, dass das Modell nicht sehr gut ist, aber ich würde das nicht als Leckage bezeichnen und wahrscheinlich auch nicht als Überanpassung.

Betreff: Datenleck

Liebling @dale_lehman , ja, Sie haben Recht, ich habe es verwechselt, zumindest formal, da ich nur über das Gesamtziel nachgedacht habe, ein gutes und robustes Modell zu haben. Das Vermeiden von Leckagen ist als Ziel definiert, nicht bereits Daten im Testsatz gesehen zu haben. Eine zusätzliche Erklärung habe ich hier gefunden:

Datenleck beim maschinellen Lernen. So verhindern Sie Probleme, die die... | von Devin Soni :crown: | Auf dem Weg zur Datenwissenschaft

Aber wie macht man das absichtlich, wenn wir Trainings- und Testsätze normalerweise zufällig aufteilen? Ich denke eher, dass in einer Prozessmodellkategorie das Training und der Testsatz beide aus demselben Prozess stammen. Wenn man über Prognosen nachdenkt, kann es anders sein.

 

Betreff: Datenleck

Ich frage mich, ob wir zwei Dinge verwechseln: Leckage und Überanpassung.Ich denke, sie sind ziemlich unterschiedlich.Überanpassung ist bei der Vorhersagemodellierung immer ein potenzielles Problem. Die übliche Methode, dies zu verhindern, besteht darin, eine Validierung durchzuführen und, wenn genügend Daten vorhanden sind, auch einen separaten Testdatensatz.Meiner Erfahrung nach stellt Überanpassung bei JMP weniger ein Problem dar, als es sonst der Fall wäre, da eine Reihe anderer Optimierungsparameter ebenfalls dazu beitragen, dies zu verhindern.Bei Entscheidungsbäumen hilft beispielsweise das Festlegen einer relativ hohen Mindestaufteilungsgröße dabei, eine Überanpassung zu vermeiden.Dennoch ist es eine gute Idee, über separate Testdaten zu verfügen, um zu bewerten, ob Ihr Modell in der Lage ist, realistische Vorhersagen für neue Daten zu erstellen.Ich denke, dass dies besonders wichtig für Zeitreihendaten ist.

 

Leckagen sind meiner Meinung nach ein ganz anderes Thema.Leckage ist ein falsch spezifiziertes Modell.Sie verwenden Faktoren, die nur zum gleichen Zeitpunkt bekannt wären wie das, was Sie vorhersagen möchten.Wenn Sie beispielsweise versuchen, die Kundenbindung vorherzusagen und einer Ihrer Faktoren die diesjährigen Käufe sind, dann verfügen Sie nur über Daten für behaltene Kunden und fehlen für diejenigen, die Sie nicht behalten.In diesem Fall kann der Faktor der diesjährigen Käufe die Kundenbindung perfekt vorhersagen, aber das ist kein brauchbares Modell.Das ist meiner Meinung nach Leckage.

 

Ich glaube nicht, dass Leckagen durch unterschiedliche Trainings-/Validierungs-/Testdatensätze verhindert oder erkannt werden.Sie können Lecks in jedem dieser drei Punkte feststellen: Ein perfektes Modell (oder nahezu perfekt) auf den Trainingsdaten würde ausreichen, um zu vermuten, dass ein Leck vorliegen könnte.Meiner Meinung nach besteht die beste Vermeidung von Leckagen darin, die Faktoren sorgfältig abzuwägen und zu verstehen, wie und wann sie gemessen werden.Wenn ein Modell zu gut erscheint, um wahr zu sein, liegt möglicherweise ein Leck vor (oder es könnte sich einfach um ein sehr gutes Modell handeln).Aber ich glaube nicht, dass diese Frage durch technische Hilfsmittel beantwortet werden kann.

 

Ich bin gespannt, was andere dazu sagen.

Betreff: Datenleck

Hier ist meine begrenzte Erfahrung.

Die Modellierung ist recht komplex (richtige Modellwahl, Datenaufbereitung, Datenaufteilung, Metadaten-Tuning ...).

Ein gutes, robustes Modell ist unabhängig von Aufteilung, Metadaten, Modelltyp ...

Sowohl das Training als auch der Testsatz müssen für den Prozess repräsentativ sein, der Testsatz muss jedoch nicht so umfassend sein. Zur Beurteilung des Ergebnisses ist ein Training/Test erforderlich @ich h schon erwähnt.

Bei der Aufteilung kann die Option „Schichten“ verwendet werden, um die Aufteilung zu steuern. Aber sowohl für die Modellierung als auch für die Aufteilung benötigen Sie Prozesskenntnisse, wie man es am besten macht.

Bei komplexen Modellen und wenn das Ergebnis entscheidend ist, habe ich versucht, verschiedene Modelle, verschiedene Metadaten und verschiedene Validierungsspalten zu testen. Wenn es keinen großen Unterschied gibt, gibt es kein Problem. Und das geht ganz einfach in JMP (Pro).

Am Ende gibt Ihnen nur dieser Test die Antwort, ob keine Undichtigkeit vorliegt. Aber ehrlich gesagt hätte ich nichts gegen Leckagen, wenn ich sicher sein kann, dass ich ein gutes Modell habe.

Betreff: Datenleck

Meine 2 Cent:

Wenn Sie Zeitreihendaten haben, denke ich, dass Punkt 2 das größere Problem ist, es sei denn, Sie führen viel Interpolation durch.Berücksichtigen Sie Rauschquellen in Ihren Daten, wenn diese über mehrere Zeilen hinweg auftreten oder wenn Zeilen in irgendeiner Weise mit den Zeilen davor und danach verknüpft sind (Überwachung eines Tankfüllstands über einen längeren Zeitraum, wenn mehr als eine Zeile erforderlich ist, bis der Tank erreicht ist). (z. B. ein neuer stationärer Zustand), dann können Sie die Daten nicht nach Zeilen aufteilen und erwarten, dass die Validierungs- oder Testsätze unabhängig vom Training sind.

 

Stattdessen könnten Sie erwägen, die Daten in größere Abschnitte zum Testen und Validieren aufzuteilen, zum Beispiel:

• Identifizieren Sie neue Zeiträume, in denen der Prozess eine „signifikante“ Änderung vornimmt, und behalten Sie die Dauer von Dauerläufen in derselben Gruppe bei (härter, aber besser), oder
• Verwenden Sie Zeiträume, die lang genug sind, damit Sie sicher sind, dass sie unterschiedliche Laufbedingungen darstellen, aber auch kurz genug, dass sie nicht aus mehr als einer Laufbedingung bestehen, und belassen Sie alle Zeilen in diesem Zeitraum in derselben Validierungsgruppe (einfacher, da sie möglicherweise immer noch demselben Risiko ausgesetzt sind). )
• Fassen Sie unter Verwendung der oben identifizierten Zeiträume jeden dieser Durchläufe in einer einzigen Zeile zusammen, möglicherweise unter Verwendung von Durchschnittswerten oder Standardabweichungen von Variablen oder dem Funktionsdaten-Explorer anderer. (am besten)

In beiden Fällen könnten Sie erwägen, Übergangszeiten zwischen Gruppen auszuschließen.

 

Meine persönliche Erfahrung: Seit ich mindestens eine dieser Methoden verwende, stellen Validierungs- und Testgruppenstatistiken viel vernünftigere Erwartungen an die Vorhersagekraft von Modellen dar.