Der Teufel steckt im Detail: Datenlecks
In diesem Blogbeitrag gehe ich davon aus, dass Sie wissen, was ein Datenleck ist, und werde eine Perspektive zur Lösung dieses Problems für einen Anwendungsfall aufzeigen, der mir häufig begegnet. Um Sie an das Thema zu erinnern, werde ich aus Wikipedia zitieren .
In der Statistik und beim maschinellen Lernen bezeichnet Leckage (auch als Datenleckage oder Zielleckage bekannt) die Verwendung von Informationen beim Training des Modells, von denen man nicht erwarten würde, dass sie zum Zeitpunkt der Vorhersage verfügbar sind, was dazu führt, dass die Vorhersageergebnisse (Metriken) den Nutzen des Modells überschätzen, wenn es in einer Produktionsumgebung ausgeführt wird.
Sie haben also Ihr maschinelles Lernmodell trainiert und einen Blick auf die Leistungskennzahlen geworfen. Sie liegen nahe bei
Und wenn Sie immer noch Ihr selbstbewusstes Lächeln behalten wollen, ist es an der Zeit, Ihre Strategie zur Datenaufteilung zu überdenken, um Datenverluste zu vermeiden.
Ich stoße sehr oft auf diese Art von Datenlecks, insbesondere wenn ich an datengesteuerten Problemen für IoT-Geräte arbeite. Bei solchen Problemen gibt es in der Regel mehrere Datenpunkte, die von mehreren IoT-Geräten oder sozusagen Entitäten gesammelt werden. Anders ausgedrückt: In dem Datensatz gibt es viele Datenpunkte, die mit jeder Entität verbunden sind. Von nun an bezeichnen wir die IoT-Geräte als Entitäten, da dies die granularste Detailstufe ist, mit der die Datenpunkte verknüpft werden können.
Nehmen wir einen Anwendungsfall als Beispiel und gehen wir davon aus, dass wir an einem Problem der prädiktiven Batteriewartung für ein IoT-Gerät arbeiten und das Ziel unseres maschinellen Lernmodells darin besteht, den Batteriestatus des Geräts anhand der vom Gerät erfassten täglichen Ereigniszählungen zu schätzen. Jeder Datenpunkt in diesem Beispiel umfasst tägliche Ereigniszählungen, gerätespezifische Daten und auch kumulative Ereignisdaten über die Zeit.
Nicht gut: Nur zufällige Aufteilung
Die Erstellung getrennter Datensätze für Training und Test ist ein Teil des Standardverfahrens für die Modellierung von maschinellem Lernen. Im Allgemeinen wird die Methode der zufälligen Aufteilung bevorzugt, bei der die Daten zunächst gemischt und dann aufgeteilt werden. Die Idee dahinter ist, dass die Datenverteilung in beiden Datensätzen (Training und Test) repräsentiert wird, so dass die zufällige Aufteilung in den meisten Fällen funktioniert. In diesem Fall ist die zufällige Aufteilung allein zur Erstellung von Trainings- und Testdatensätzen jedoch keine gute Wahl. Der Grund dafür ist, dass jeder Datenpunkt mit hoher Wahrscheinlichkeit Merkmale einer Entität enthält und die Datenpunkte einer Entität einander ähnlich sind. Wenn die Datenpunkte einer Entität in den Trainings- und Testdatensätzen enthalten sind, muss das Modell keine Vermutungen anstellen, um zu verallgemeinern, und kann sich stattdessen an diese Entitätsmerkmale erinnern.
Um auf den obigen Anwendungsfall zurückzukommen: Funktionen wie gerätespezifische Daten und kumulative Daten führen dazu, dass sich das Modell an die Entität erinnert, wenn es sowohl für Trainings- als auch für Testdatensätze verwendet wird, wodurch es zu Datenverlusten kommt.
Besser: Entitywise Split & Random Split:
Wenn wir nur eine zufällige Aufteilung verwenden, kann dies zu einem Datenleck führen. Um dies zu vermeiden, teilen Sie den Datensatz zunächst nach Entität auf. Ordnen Sie zunächst eine Entität nach dem Zufallsprinzip dem Trainings- oder Testdatensatz zu. Nehmen Sie dann die Datenpunkte der Entität nur in den Datensatz auf, dem die Entität zugewiesen wurde. Lassen Sie nicht zu, dass sowohl der Trainings- als auch der Testdatensatz Datenpunkte der gleichen Entität enthalten.
Eine Entität hier können wir als device_id oder sogar eine granularere Entität wie battery_id deklarieren, da die kumulativen Daten für ein bestimmtes Gerät bei jedem Batteriewechsel zurückgesetzt werden.
Wie Sie die Entität für Ihr Problem identifizieren:
Dies ist der wichtigste Punkt und es gibt keine einfache Antwort. Sie müssen das Problem verstehen, das Sie zu lösen versuchen, und sicherstellen, dass dieses Problem mit dem Ziel Ihres Modells übereinstimmt. Ich werde Ihnen im Folgenden einige Beispiele nennen, um zu verdeutlichen, wie.
Anwendungsfall: Vorausschauende Wartung
Bei meinem Kunden Salto Clay, einem Hersteller von intelligenten Schlössern, habe ich ein Modell für maschinelles Lernen entwickelt, um abzuschätzen, ob ein intelligentes Schloss Kunden an der Tür abweisen würde, weil die Batterie schwach ist und es nicht möglich war, den verbleibenden Batteriestand abzulesen. Ein intelligentes Schloss ist ein netzwerkfähiges Gerät, mit dem Benutzer ihre Schlüssel zurücklassen und Türen mit Mobiltelefonen, Tags und Fingerabdrücken ver- und entriegeln können. Das ursprüngliche Ziel bei meinem Kunden war:
Für das Training eines maschinellen Lernmodells, das auf diesem Datensatz basiert, müssen die Daten in Trainings- und Testdatensätze aufgeteilt werden. Wenn ich die Datenpunkte einfach nach dem Zufallsprinzip aufteile, führt dies zu einem Datenleck, denn dann gibt es sowohl in den Trainings- als auch in den Testdatensätzen Datenpunkte von demselben Smart Lock, der Entität. Ich sollte einen klügeren Aufteilungsansatz verfolgen und sicherstellen, dass die Trainings- und Testdatensätze keine Smart Lock-Datenpunkte gemeinsam haben. Denn gemäß der ursprünglichen Zieldefinition oben sind Smart Locks die Entitäten.
Die Aufteilung von Datenpunkten durch intelligente Schlösser als Entitäten ist in der Tat eine Verbesserung und verhindert bis zu einem gewissen Grad Datenverluste. Dennoch ist dies nicht die beste Lösung, da ein Smart Lock als Entität zu allgemein ist, um die Funktionen abzudecken, die von der Batterielaufzeit abhängen. Es ist also notwendig, die Entität genauer zu definieren, wie z.B. die
Eine Sache noch! Bei dieser Art von Problem und einem Datensatz mit mehreren Datenpunkten für jede Entität ist es nicht ratsam, einen rollierenden Datensatz zu erstellen und eine Kreuzvalidierung wie bei Zeitreihenproblemen zu verwenden, da eine einfache Rollierung kumulative Daten, die sich im Laufe der Zeit zurücksetzen, nicht eliminiert. Es ist nicht notwendig, eine Kreuzvalidierung über die Zeit durchzuführen, da wir spätere Datenpunkte, die für eine Batterie gesammelt wurden, für die Schätzung der zuvor verwendeten Batterien verwenden können und umgekehrt. Die zeitliche Reihenfolge spielt also keine Rolle, solange die Datenpunkte der Einheit entweder im Trainings- oder im Testdatensatz landen.
Anwendungsfall: Entdeckung von Kunden
Bei meinem früheren Kunden, einem Strom-/Gasversorger, gab es ein Ziel Welche Heizquelle haben die Kunden? und der Datensatz bestand aus täglichen Datenpunkten des Strom-/Gasverbrauchs und wohnungsspezifischen Daten, z.B. Gebäudealter und -typ.
Wenn die Datenpunkte zufällig den Trainings- und Testdatensätzen zugewiesen werden, kommt es zu Datenverlusten und die Leistungskennzahlen sind hoch. Denn das Modell erinnert sich an gebäudespezifische Daten, anstatt eine fundierte Vermutung anzustellen. Am besten definieren wir unsere Entität als Wohnung und weisen die Datenpunkte einer Wohnung entweder dem Trainings- oder dem Testdatensatz zu.
Verfasst von
Erdem Başeğmez
Unsere Ideen
Weitere Blogs
Contact