Häufige Fehler vermeiden
Alle Modelle sind falsch, aber manche Modelle sind nützlich.
– George E. P. Box
Das obige Zitat wird auch in diesem xkcd Comic schön veranschaulicht:
Ein Supervised Learning Modell versucht, den Zusammenhang zwischen Inputs und Outputs aus den gegebenen Datenpunkten abzuleiten. Was für ein Zusammenhang gelernt wird, wird vor allem durch den gewählten Modelltyp und seinen internen Optimierungsalgorithmus bestimmt. Man kann (und sollte) jedoch einiges tun, um sicherzustellen, dass das Ergebnis nicht offensichtlich falsch ist.
Was wollen wir?
Ein Modell, das …
- … genaue Vorhersagen trifft
- … für neue Datenpunkte
- … aus den richtigen Gründen
- … auch wenn sich die Welt ständig verändert.
Im Folgenden besprechen wir einige häufige Fallstricke und wie wir sie vermeiden können.
[Fehler #1] Irreführende Modellevaluierung
Vorhersagemodelle müssen evaluiert werden, d.h. ihre Performance muss mit einer geeigneten Evaluierungsmetrik quantifiziert werden. Dies ist notwendig, um realistisch abzuschätzen, wie nützlich ein Modell in der Praxis sein wird und mit wie vielen Vorhersagefehlern wir rechnen müssen.
Da man bei Supervised Learning Problemen die Ground Truth, also die echten Labels, kennt, kann man verschiedene Modelle objektiv bewerten und miteinander vergleichen.
Ist das Modell für die Aufgabe geeignet?
D.h. generiert das Modell zuverlässige Vorhersagen für neue Datenpunkte?
- Teile die verfügbaren Daten in einen Trainings- und einen Testteil auf, um abschätzen zu können, wie gut die Vorhersagen des Modells sein werden, wenn es später auf neue Datenpunkte angewendet wird, auf denen es nicht trainiert wurde.
- Quantifiziere die Güte der Modellvorhersagen auf dem Testset mit einer geeigneten Evaluierungsmetrik (je nach Problemtyp).
⇒ Sind manche Fehler schwerwiegender als andere (z.B. bei medizinischen Tests falsch positive vs. falsch negative Ergebnisse)?
⇒ Lege dich auf eine Metrik/KPI fest, anhand derer du unterschiedliche Modelle vergleichst und auswählst (evtl. unter Berücksichtigung zusätzlicher Einschränkungen wie Laufzeit).
Beim Evaluieren eines Modells kann man allerdings leicht ein zu optimistisches Bild zeichnen, weshalb man die Ergebnisse immer kritisch hinterfragen und die Performance eines Modells mit der einer Baseline vergleichen sollte. Der einfachste Vergleich wäre mit einem sehr dummen Modell, das immer den Mittelwert (→ Regression) bzw. die häufigste Klasse (→ Klassifikation) vorhersagt.
Evaluierungsmetriken bei unausgeglichenen Klassenverteilungen
Die Accuracy (Genauigkeit) ist ein sehr häufig verwendetes Evaluierungsmaß für Klassifikationsprobleme:
Accuracy: Anteil der Proben, die richtig klassifiziert wurden.
Unten sind die Entscheidungsgrenzen von zwei Modellen in einem Beispieldatensatz eingezeichnet, wobei die Farbe des Hintergrunds angibt, ob das Modell die blaue oder rote Klasse für einen Datenpunkt in diesem Bereich vorhersagt. Welches Modell hältst du für sinnvoller?
Bei unausgeglichenen Klassenverteilungen, wie in diesem Fall mit viel mehr Datenpunkten aus der blauen im Vergleich zur roten Klasse, ist die Accuracy eines Modells, das einfach immer die häufigste Klasse vorhersagt, schon sehr groß. Eine Accuracy von 90% mag zwar beeindruckend klingen, wenn man den Stakeholdern des Projekts von der Performance seines Modells berichtet, bedeutet jedoch nicht automatisch, dass das Modell tatsächlich in der Praxis nützlich ist, zumal uns bei realen Problemen oft die seltenere Klasse mehr interessiert, z.B. Menschen mit einer seltenen Krankheit oder Produkte, die einen Defekt aufweisen.
Eine aussagekräftigere Evaluierungsmetrik für Klassifikationsmodelle ist die Balanced Accuracy, mit der wir zwischen einem Modell, das tatsächlich etwas gelernt hat, und der ‘dummen Baseline’ unterscheiden können:
Balanced Accuracy: Zuerst wird für jede Klasse einzeln der Anteil der richtig klassifizierten Stichproben berechnet und dann der Durchschnitt dieser Werte gebildet.
[Fehler #2] Modell generalisiert nicht
Wir wollen ein Modell, das den ‘Input → Output’-Zusammenhang in den Daten erfasst und interpolieren kann, d.h. wir müssen prüfen:
Generiert das Modell zuverlässige Vorhersagen für neue Datenpunkte aus derselben Verteilung wie die der Trainingsdaten?
Wenn ja, garantiert dies zwar noch nicht, dass das Modell tatsächlich den echten kausalen Zusammenhang zwischen Inputs und Outputs gelernt hat und über den Trainingsbereich hinaus extrapolieren kann (dazu kommen wir im nächsten Abschnitt). Zumindest generiert das Modell aber zuverlässige Vorhersagen für neue Datenpunkte, die den Trainingsdaten ähnlich sind. Ist dies nicht gegeben, ist das Modell nicht nur falsch, sondern auch nutzlos.
Aber warum macht ein Modell überhaupt Fehler? Eine schlechte Performance auf dem Testset kann zwei Gründe haben: Overfitting oder Underfitting.
Diese beiden Fälle erfordern sehr unterschiedliche Ansätze, um die Modellperformance zu verbessern.
Da die meisten Datensätze sehr viele Inputvariablen haben, kann man das Modell in der Regel nicht einfach wie oben aufmalen, um zu sehen, ob es over- oder underfittet. Stattdessen muss man sich den mit einer aussagekräftigen Evaluierungsmetrik berechneten Fehler sowohl auf dem Trainings- als auch dem Testset anschauen um zu bestimmen, ob man es mit Overfitting oder Underfitting zu tun hat:
Overfitting: super Trainingsperformance, inakzeptabel auf den Testdaten
Underfitting: schlechte Trainings- UND Testperformance
Je nachdem, ob ein Modell over- oder underfittet, gibt es verschiedene Möglichkeiten die Performance zu verbessern. Eine perfekte Modellperformance ist jedoch unrealistisch, da manche Aufgaben einfach schwierig sind, zum Beispiel weil die Daten sehr verrauscht sind.
Schaue dir immer die Daten an! Gibt es ein Muster unter den falschen Vorhersagen, z.B. eine Diskrepanz zwischen der Performance für verschiedene Klassen?
[Fehler #3] Modell missbraucht Scheinkorrelationen
Selbst wenn ein Modell in der Lage ist, richtige Vorhersagen für neue Datenpunkte zu generieren, die den Trainingsdaten ähnlich sind, bedeutet dies nicht, dass das Modell tatsächlich den wahren kausalen Zusammenhang zwischen den Inputs und Outputs gelernt hat!
ML-Modelle machen es sich oft leicht und schummeln! Sie nutzen häufig Scheinkorrelationen, statt die wahren kausalen Zusammenhänge zu lernen. Dies macht sie anfällig für Adverserial Attacks und Daten-Drifts, die das Modell zwingen, zu extrapolieren statt zu interpolieren.
Eine richtige Vorhersage wird nicht immer aus den richtigen Gründen gemacht!
Die Grafik unten stammt aus einem Paper, in dem die Autoren festgestellt haben, dass ein vergleichsweise einfaches ML-Modell, das auf einem Standard-Bildklassifizierungsdatensatz trainiert wurde, für alle zehn Klassen im Datensatz schlecht abschnitt – bis auf die Klasse ‘Pferd’! Als sie den Datensatz genauer untersuchten und analysierten, warum das Modell eine bestimmte Klasse vorhersagt, d.h. welche Bildmerkmale in der Vorhersage verwendet wurden (angezeigt als Heatmap auf der rechten Seite), machten sie folgende Feststellung: Die meisten Bilder von Pferden im Datensatz stammten vom selben Fotografen und enthielten alle einen charakteristischen Copyright-Vermerk in der linken unteren Ecke.
Anhand dieses Artefaktes konnte das Modell mit hoher Genauigkeit Pferdebilder in diesem Datensatz identifizieren – und zwar sowohl im Trainings- als auch im Testset, das auch Bilder desselben Fotografen enthielt. Trotzdem hat das Modell natürlich nicht gelernt, was ein Pferd eigentlich ausmacht, und es kann nicht extrapolieren und andere Fotos von Pferden ohne diesen Copyright-Hinweis korrekt identifizieren. Andersrum könnte man nun auch ein Bild von einem anderen Tier mit einem solchen Copyright-Vermerk versehen und das Modell würde darauf dann irrtümlich ein Pferd erkennen. Man kann das Modell so also absichtlich austricksen, was man auch als “Adverserial Attack” bezeichnet.
Dies ist bei weitem nicht das einzige Beispiel, bei dem ein Modell “geschummelt” hat, indem es Scheinkorrelationen in den Trainingsdaten ausnutzte. Ein weiteres beliebtes Beispiel: Ein Datensatz mit Bildern von Hunden und Wölfen, bei dem alle Wölfe auf verschneitem Hintergrund und die Hunde auf Gras oder anderen nicht-weißen Hintergründen fotografiert wurden. Modelle, die auf so einem Datensatz trainiert werden, können eine gute Vorhersagegenauigkeit aufweisen, ohne dass sie die wahren kausalen Zusammenhang zwischen den Features und Labels erkannt haben.
Um solche Pannen rechtzeitig zu erkennen, ist es wichtig, das Modell zu interpretieren und seine Vorhersagen zu erklären (wie im oben genannten Paper), um zu sehen, ob das Modell zur Vorhersage die Features verwendet, die wir (oder ein Domänenexperte) erwartet hätten.
Adversarial Attacks: ML-Modelle absichtlich täuschen
Bei einem ‘feindlichen Angriff’ auf ein ML-Modell werden die Inputdaten subtil verändert, sodass ein Mensch diese Änderungen nicht bemerkt und immer noch zum richtigen Ergebnis kommt, aber das Modell seine Vorhersage ändert.
Während zum Beispiel ein ML-Modell das ‘Stop’-Schild auf dem linken Bild leicht erkennen kann, wird das Schild rechts aufgrund der strategisch platzierten, unscheinbar aussehenden Aufkleber (die ein Mensch einfach ignorieren würde) mit einem Geschwindigkeitsbegrenzungsschild verwechselt:
Der Grund dafür ist, dass das Modell nicht die wahren Merkmale gelernt hat, anhand derer Menschen ein Stoppschild als solches identifizieren, z.B. die achteckige Form und die vier weißen Buchstaben ‘STOP’ vor rotem Hintergrund. Stattdessen verlässt sich das Modell auf bedeutungslose Korrelationen, um das Stoppschild von anderen Schildern zu unterscheiden.
Da ein Convolutional Neural Network (CNN), die neuronale Netzarchitektur, die typischerweise für Bildklassifizierungsaufgaben verwendet wird, sich sehr auf lokale Muster fokussiert, lässt es sich leicht täuschen. Dies geschieht, indem man die globale Form von Objekten, welche Menschen zur Identifikation verwenden, intakt lässt, und die Bilder mit bestimmten Texturen oder anderen Hochfrequenzmustern überlagert, wodurch das Modell eine andere Klasse vorhersagt.
GenAI & Adversarial Prompts
Wegen ihrer Komplexität ist es besonders schwierig, den Output von generativen KI-Modellen (GenAI) wie ChatGPT zu kontrollieren. Diese Modelle können zwar in “Human-in-the-Loop” Szenarien sehr nützlich sein (z.B. um eine E-Mail oder Code-Schnipsel zu schreiben, die dann nochmal von einem Menschen überprüft werden), doch es ist schwer, die notwendigen Sicherheitsvorkehrungen zu treffen, damit der Chatbot nicht missbraucht werden kann.
Der ChatGPT-basierte Kundensupport-Chat eines Chevrolet-Autohändlers ist nur ein Beispiel von vielen frühen GenAI Anwendungen, die bestenfalls gemischte Ergebnisse lieferten:
Wie man robuste Kausalmodelle, die den wahren ‘Input → Output’-Zusammenhang in den Daten erfassen, findet, wird nach wie vor aktiv erforscht und ist weitaus schwieriger als ein Modell zu finden, das “nur” verallgemeinert und gute Vorhersagen für die Testdaten generiert.
[Fehler #4] Modell diskriminiert
Ein Modell, welches echte kausale Zusammenhänge zwischen den Variablen aufgegriffen hat, generiert zwar robustere Vorhersagen, doch es kann auch kausale Zusammenhänge in den historischen Daten geben, die ein Modell besser nicht lernen sollte. Wenn in der Vergangenheit Menschen aufgrund ihres Geschlechts oder ihrer Hautfarbe diskriminiert wurden, kann sich dies auch in den Trainingsdaten widerspiegeln und wir müssen zusätzliche Maßnahmen ergreifen, damit diese Muster nicht in unserem Modell weiterbestehen – obwohl es in der Vergangenheit vielleicht echte kausale Zusammenhänge waren.
Systematisch verzerrte Daten führen zu (stark) verzerrten Modellen
Im Folgenden sind einige Beispiele aufgeführt, bei denen Menschen mit den besten Absichten ein ML-Modell entwickelt haben, das problematische Dinge aus realen Daten gelernt hat.
de Vries, Terrance, et al. “Does object recognition work for everyone?” IEEE/CVF Conference on Computer Vision and Pattern Recognition Workshops. 2019.
Die oben genannten Probleme traten alle auf, weil die Daten nicht gleichmäßig verteilt waren:
- Tay hat viel mehr rassistische und hasserfüllte Kommentare und Tweets gesehen als neutrale oder wertschätzende Äußerungen.
- Der Bilddatensatz, auf dem Twitter sein Modell trainierte, enthielt mehr Bilder von weißen als von nicht-weißen Personen.
- Bei einer zufälligen Stichprobe von Fotos aus dem Internet wurden diese Bilder meist von Menschen aus Industrieländern hochgeladen, d.h. Bilder, die den Status Quo in Entwicklungsländern zeigen, sind unterrepräsentiert.
Noch problematischer als eine bloße Unterrepräsentation bestimmter Untergruppen (verzerrte Eingabeverteilung) ist ein Muster der systematischen Diskriminierung dieser Untergruppen in historischen Daten (diskriminierende Verschiebung der zugewiesenen Labels).
Zusammenfassend: Ein verzerrtes Modell kann sich auf zwei Arten negativ auf die Nutzer auswirken:
- Unverhältnismäßige Produktausfälle aufgrund unterrepräsentierter Stichproben. Beispielsweise funktionieren Spracherkennungsmodelle für Frauen oft weniger zuverlässig, weil sie mit mehr Daten von Männern trainiert wurden (z.B. transkribierte politische Reden).
- Schaden durch Benachteiligung / Verweigerung von Chancen aufgrund von in historischen Daten kodierten Stereotypen. Beispielsweise müssen Frauen höhere Kreditzinsen zahlen als Männer oder im Ausland geborene Personen gelten als weniger qualifiziert für eine Stelle, wenn ihre Lebensläufe von einem automatisierten Screening-Tool bewertet werden.
Wenn man Modelle mit Daten neu trainiert, die von Vorhersagen eines verzerrten Vorgängermodells beeinflusst wurden, können bestehende Vorurteile noch verstärkt werden. Wenn beispielsweise ein Lebenslauf-Screeningtool ein häufiges Merkmal (z.B. “hat die Stanford University besucht”) bei aktuellen Mitarbeitern erkennt, könnte es konsequent Lebensläufe mit diesem Merkmal empfehlen. Daraus resultiert, dass noch mehr Leute mit diesem Merkmal zu Vorstellungsgesprächen eingeladen und eingestellt werden, was die Dominanz dieses Merkmals in nachfolgenden Modellen, die auf diesen Mitarbeiterprofilen trainiert werden, weiter verstärkt.
Auf dem Weg zu fairen Modellen
Bevor wir diese Probleme beheben können, müssen wir uns ihrer erstmal bewusst werden. Daher ist es wichtig, die Performance eines Modells immer für jede (bekannte) Untergruppe in den Daten einzeln zu bewerten, um sicherzustellen, dass die Vorhersagefehler des Modells zufällig sind und das Modell nicht für einige Untergruppen (z.B. Frauen) systematisch schlechter funktioniert.
Außerdem ist grundsätzlich Vorsicht geboten, wenn wir Variablen in das Modell aufnehmen, die Attribute wie Geschlecht oder Herkunft kodieren. Zum Beispiel wird die Performance eines Modells zur Diagnose von Herzinfarkten durch die Einbeziehung von ‘Geschlecht’ als Merkmal höchstwahrscheinlich verbessert, da Männer und Frauen bei einem Herzinfarkt unterschiedliche Symptome zeigen. Andererseits sollte ein Modell, das jemandem eine Kreditwürdigkeit zuweist, bei dieser Entscheidung das Geschlecht der Person eher nicht berücksichtigen, da ansonsten die in historischen Daten kodierten Stereotypen weiterleben.
Das Geschlecht oder die Hautfarbe einer Person kann jedoch auch mit anderen Variablen wie beispielsweise Einkommen oder Wohngegend korreliert sein, sodass selbst Features, die auf den ersten Blick harmlos erscheinen, problematische Informationen an das Modell weitergeben können. In solchen Fällen sind zusätzliche Maßnahmen nötig, um zu vermeiden, dass das Modell diskriminiert.
Weitere Negativbeispiele findest du auf der Seite AI Incidence Database und in
Buch Empfehlung:
Weapons of Math Destruction von Cathy O’Neil (2016)
[Fehler #5] Daten & Konzept Drifts
Wir dürfen nie vergessen, dass sich die Welt permanent verändert und Modelle regelmäßig mit neuen Daten nachtrainiert werden müssen. Nur so können sie sich an diese geänderten Umstände anpassen.
ML versagt leise! D.h. auch wenn alle Vorhersagen falsch sind, stürzt das Programm nicht einfach mit einer Fehlermeldung ab.
→ Wir brauchen ein konstantes Monitoring, um Veränderungen zu erkennen, die zu einer Verschlechterung der Modellperformance führen!
Eins der größten Probleme in der Praxis: Daten und Konzept-Drifts:
Die Vorhersagegenauigkeit eines Modells lässt schnell nach, wenn die Daten im Produktivbetrieb von den Trainingsdaten abweichen. Dabei unterscheiden wir zwischen:
- Daten-Drift: Verteilung der gemessenen Werte einer oder mehrerer Variablen verändert sich. Dies kann entweder die Inputs \(X\) betreffen, dann nennt sich das Covariate Shift oder die Outputs \(y\), dann sprechen wir von Label Shift.
- Konzept-Drift: Input/Output Zusammenhang \(X \to y\) ändert sich, d.h. exakt die gleichen Inputs \(X\) resultieren plötzlich in einem anderen Output \(y\).
In beiden Fällen ändert sich etwas, das für unsere ML Anwendung wichtig ist, in der Welt. Wenn unsere gesammelten Daten diese Veränderung abbilden, spricht man von Daten-Drift. Wenn wir diese Veränderung nicht in unseren Inputdaten sehen können, handelt es sich um einen Konzept-Drift.
Beispiel: Anhand der Produktionsbedingungen inkl. der Größe des produzierten Teils (\(X\)) möchten wir vorhersagen ob das jeweilige Produkt in Ordnung oder Ausschuss ist (\(y\)):
- Daten-Drift: Der Hersteller produzierte früher nur kleine Teile, nun aber auch größere Teile.
- Konzept-Drift: Während früher 10% Ausschuss produziert wurden, wird nach einer Reparatur der Maschine bei gleichen Produktionsbedingungen (\(X\)) nur noch 5% Ausschuss (\(y\)) produziert.
Covarite Shifts können, ohne dass es einen Konzept-Drift gibt, zu Label Shifts führen, wenn die Inputvariable kausal mit der Outputvariable verbunden ist. Zum Beispiel wurde ein Modell, das Krebs (\(y\)) bei Patienten basierend auf dem Alter (\(x\)) vorhersagt, mit einem Datensatz trainiert, der größtenteils aus älteren Menschen besteht, die naturgemäß auch häufiger an Krebs erkranken. In der Praxis wird das Modell dann auf Patienten jeden Alters angewendet (Covariate Shift), also auch auf mehr junge Menschen, die seltener an Krebs erkranken (Label Shift).
Gründe für Drifts & Vorbeugende Maßnahmen
Daten- und Konzeptdrifts entstehen sowohl durch die Art wie die Daten gesammelt werden, als auch durch externe Ereignisse außerhalb unserer Kontrolle.
Diese Veränderungen können entweder graduell sein (z.B. Sprachen ändern sich schrittweise wenn neue Wörter geprägt werden; ein Kameraobjektiv staubt mit der Zeit ein), oder sie können als plötzlicher Schock auftreten (z.B. jemand reinigt das Kameraobjektiv; als die COVID-19-Pandemie ausbrach, wechselten plötzlich viele Menschen zum Online-Shopping, wodurch Systeme zur Erkennung von Kreditkartenbetrug erstmal irrtümlich Alarm schlugen).
Geändertes Datenschema
Viele Probleme entstehen intern und könnten vermieden werden, zum Beispiel:
- Die Benutzeroberfläche zur Datensammlung ändert sich, zum Beispiel wurde eine Größe zuvor in Metern erfasst und wird jetzt in Zentimetern erfasst.
- Die Sensor-Konfiguration ändert sich, beispielsweise wird in einer neuen Version eines Geräts ein anderer Sensor verwendet, der jedoch weiterhin Werte unter dem gleichen Variablennamen wie der alte Sensor aufzeichnet.
- Die als Inputs für das Modell verwendeten Features ändern sich, zum Beispiel werden zusätzliche erstellte Features eingeführt, jedoch wurde die Feature-Transformations-Pipeline nur im Trainingscode geändert, noch nicht im Produktionscode.
⇒ In diesen Fällen sollte idealerweise ein Fehler geworfen werden, zum Beispiel könnten wir einige Tests vor der Anwendung des Modells einbauen, um sicherzustellen, dass wir die erwartete Anzahl von Features erhalten, deren Datentypen (z.B. Text oder Zahlen) wie erwartet sind und die Werte grob im erwarteten Bereich für das jeweilige Feature liegen. Darüber hinaus müssen andere Teams im Unternehmen darüber informiert werden, dass ein ML-Modell auf ihren Daten basiert, damit sie das Data-Science-Team rechtzeitig über Änderungen informieren können.
Daten-Drifts
Daten-Drifts treten auf, wenn unser Modell Vorhersagen für Stichproben treffen muss, die sich von den Trainingsdaten unterscheiden. Das kann zum Beispiel daran liegen, dass bestimmte Bereiche der Trainingsdomäne unterrepräsentiert waren. Im Extremfall könnte das Modell sogar gezwungen sein, über die Trainingsdomäne hinaus zu extrapolieren. Dies könnte beispielsweise durch folgende Gründe verursacht werden:
- Veränderte Stichprobenauswahl, zum Beispiel wenn das Unternehmen kürzlich in ein anderes Land expandiert ist oder nach einer gezielten Marketingkampagne die Website von einer neuen Nutzergruppe besucht wird.
- Feindseliges Verhalten, zum Beispiel wenn Spammer ständig ihre Nachrichten anzupassen, um Spam-Filter zu umgehen. Vor zehn Jahren hätte ein Mensch eine Spam-Nachricht von heute auch als Spam erkannt (die Bedeutung von Spam hat sich also nicht geändert), aber diese ausgefeilteren Nachrichten waren damals nicht im Trainingsdatensatz enthalten. Das macht es für ML-Modelle schwierig, diese Muster zu erkennen.
⇒ Daten-Drifts können als Gelegenheit betrachtet werden, unseren Trainingsdatensatz zu erweitern und das Modell mit mehr Daten von unterrepräsentierten Untergruppen neu zu trainieren. Wie jedoch im vorherigen Abschnitt zu modellbasierter Diskriminierung erläutert wurde, bedeutet dies oft, dass diese unterrepräsentierten Untergruppen zunächst mit einem weniger effektiven Modell arbeiten müssen, beispielsweise eine Spracherkennungsfunktion, die bei Frauen schlechter funktioniert als bei Männern. Daher ist es wichtig, Untergruppen zu identifizieren, bei denen das Modell möglicherweise schlechtere Ergebnisse liefert, idealerweise mehr Daten aus diesen Gruppen zu sammeln oder zumindest beim Modelltraining und -evaluierung diesen Datenpunkten größere Beachtung zu schenken.
Konzept-Drifts
Konzept-Drifts treten auf, wenn externe Veränderungen oder Ereignisse eintreten, die wir nicht in unseren Daten erfasst haben oder die die Bedeutung unserer Daten verändern. Das bedeutet, dass genau dieselben Input Features plötzlich zu unterschiedlichen Outputs führen. Ein Grund kann sein, dass uns eine Variable fehlt, die einen direkten Einfluss auf den Output hat, zum Beispiel:
- Unser Prozess reagiert auf Temperatur und Luftfeuchtigkeit, aber wir haben nur die Temperatur aufgezeichnet und nicht die Luftfeuchtigkeit. Wenn sich also die Luftfeuchtigkeit ändert, führen dieselben Temperaturwerte zu unterschiedlichen Outputs. ⇒ Luftfeuchtigkeit zusätzlich als Input Feature im Modell aufnehmen.
- Saisonale Trends führen zu Veränderungen in der Beliebtheit von Sommer- gegenüber Winterkleidung. ⇒ Monat / Außentemperatur als zusätzliches Input Feature hinzufügen.
- Besondere Ereignisse, wie zum Beispiel wenn ein Prominenter unser Produkt in den sozialen Medien erwähnt oder Menschen aufgrund von Lockdowns während einer Pandemie ihr Verhalten ändern. ⇒ Obwohl es schwer sein kann, diese Ereignisse im Voraus zu prognostizieren, können wir, wenn sie eintreten, ein zusätzliches Feature wie ‘während des Lockdowns’ aufnehmen, um die in diesem Zeitraum gesammelten Daten von den übrigen zu unterscheiden.
- Degenerative Feedbackschleifen, d.h., die Existenz des Modells ändert das Verhalten der Benutzer, zum Beispiel veranlasst ein Empfehlungssystem Benutzer dazu, auf Videos zu klicken, nur weil sie empfohlen wurden. ⇒ Als zusätzliches Feature aufnehmen, ob das Video empfohlen wurde oder nicht, um herauszufinden, wie viel von “Benutzer hat auf Element geklickt” auf die Empfehlung zurückzuführen ist und wie viel auf das natürliche Verhalten des Benutzers.
Zusätzlich können Konzept-Drifts durch Ereignisse verursacht werden, die die Bedeutung der aufgezeichneten Daten ändern, zum Beispiel:
- Inflation: 1 Euro im Jahr 1990 hatte einen höheren Wert als 1 Euro heute. ⇒ Daten Inflationsbereinigen oder die Inflationsrate als zusätzliches Input Feature aufnehmen.
- Ein in Wasser getauchter Temperatursensor sammelt Kalkablagerungen, und nach einer Weile ist die Temperaturmessung nicht mehr genau. Zum Beispiel misst ein sauberer Sensor bei einer tatsächlichen Temperatur von 90 Grad die exakten 90 Grad, aber nachdem er einige Schichten Kalk angesammelt hat, misst er unter denselben Bedingungen nur noch 89 Grad. Während unser Output von der wahren Temperatur beeinflusst wird, haben wir nur Zugriff auf die Sensormessung für die Temperatur, die auch durch den Zustand des Sensors selbst bestimmt wird. ⇒ Versuche, die Kalkablagerung zu schätzen, zum Beispiel basierend auf der Anzahl der Tage seit der letzten Reinigung des Sensors (was auch bedeutet, dass solche Wartungsereignisse irgendwo erfasst werden müssen!).
⇒ Vor dem Training eines Modells sollten die Daten untersucht werden, um Fälle zu identifizieren, bei denen identische Inputs unterschiedliche Outputs ergeben. Wenn möglich, sollten zusätzliche Input Features aufgenommen werden, um diese Variationen zu berücksichtigen. Eine schlechte Performance des Modells auf dem Testdatensatz deutet häufig darauf hin, dass relevante Inputs fehlen, was die Anfälligkeit für zukünftige Konzept-Drifts erhöht. Selbst wenn die richtigen Variablen verwendet werden, um einen Konzept-Drift zu erfassen, kann häufiges Nachtrainieren der Modelle dennoch notwendig sein. Zum Beispiel können unterschiedliche Zustände des Konzepts ungleichmäßig in den Trainingsdaten vorhanden sein, was zu Daten-Drifts führen kann (z.B. mehr Daten, die im Winter gesammelt wurden als in den frühen Sommermonaten). Wenn es nicht möglich ist, Variablen einzubeziehen, die den Konzept-Drift abbilden, könnte es notwendig sein, Datenpunkte aus dem ursprünglichen Trainingsdatensatz zu entfernen, die nicht der neuen Input/Output-Beziehung entsprechen, bevor das Modell erneut trainiert wird.
Der beste Weg, Daten und Konzept-Drifts entgegenzuwirken, besteht darin, das Modell häufig mit neuen Daten zu trainieren. Dies kann entweder nach einem fixen Zeitplan erfolgen (z.B. jedes Wochenende, je nachdem, wie schnell sich die Daten ändern) oder wenn das Monitoringsystem Alarm schlägt, weil es Drifts in den Inputs oder eine verschlechterte Modellperformance festgestellt hat.