Ich möchte diesen Artikel mit folgendem Satz beginnen: Selbst, wenn alles gut gemacht wird, kann man von außen den guten Fall nicht vom schlechten Fall unterscheiden.
Dies gilt für viele Technologien, wo der Konsument nicht der Spezialist ist. Ich selbst habe das beim Hausbau als Kunde erlebt, der nichts von Tragwerksberechnungen oder Statik versteht. In diesem Fall ist das Problem jedoch noch eine Ebene höher gelagert, aber lassen Sie uns doch von vorne beginnen:
Automated Machine Learning ist ein Prozess bzw. ein Meta-Algorithmus, wobei die Anwendung von „herkömmlichen“ Machine Learning und Deep Learning Algorithmen (Random Forest, Decision Tree, Linear Regression, SVM, Neuronale Netze verschiedenster Art, uvm.) automatisiert wird, und dabei die gesamte Pipeline, also der Ablauf von den rohen, „echten“ Daten bis zum fertigen Modell erzeugt und optimiert wird (vgl. Wikipedia). Klingt toll, ist es auch!
Dieser sperrige Satz beinhaltet mehrere verschiedene essenzielle Schritte und wirft damit auch genau die Fragen auf, die ich hier behandeln möchte:
Was sind denn überhaupt meine rohen Daten?
In vielen meiner Vorträge habe ich schon über den Ablauf von Data Science Projekten gesprochen. Wobei ca. 75-90 Prozent der Arbeit eines Data Scientisten in (schmutziger 😊) Datenarbeit besteht. Die Daten der Kunden durcharbeiten, verstehen, aufbereiten, aggregieren und für den Algorithmus noch transformieren (insbesondere skalieren). Den allerletzten Schritt kann das AutoML in vielen Fällen mit optimieren. Der Algorithmus geht jedoch von einem singulären Datensatz (ich nenne das gerne ein einziges Arbeitsblatt, so wie in Excel) aus. Um erst mal von Log-Files, Texten, Bildern, Daten, Auswertungen, Datenquellen uvm. bis zu diesem singulären Datensatz zu kommen, sind viele einzelne Schritte nötig und vor allem Entscheidungen zu treffen. Was ist wichtig? Wie bereite ich das auf? Wie aggregiere ich? Welche Daten sind eher „schädlich“? (Ja das gibt es auch!) Welche Struktur oder Granularität muss ich wählen, damit der Algorithmus funktioniert?
Also schon mal ein ganz schön großer Rückschritt, denn diese "rohen" Daten in der Beschreibung sind ja gar nicht so roh. Und überhaupt: Der Großteil der Daten lässt sich ja gar nicht verbessern. Aber trotzdem, schauen wir weiter…
Welche Daten kann ich denn verwenden?
Dazu möchte ich auf ein gutes Beispiel zu AutoML eines großen Providers zurückgreifen. Es wird dabei der Stromverbrauch einer amerikanischen Großstadt täglich modelliert. Naja, was liegt da näher, als gleich mal ein paar Umweltdaten (also Temperatur und Niederschlag) in den Datensatz zu laden und dann den Verbrauch zu modellieren? Da wird mir jetzt schon ganz bange… und wie geht’s weiter?
Das Modell wird zumeist ein paar Datensätze (also so zwischen 20-30 Prozent) übriglassen, natürlich zufällig gezogen in dem Fall, damit das auch statistisch seine Richtigkeit hat. Bei diesem Vorgehen wird mir gerade noch übler.
Dann wird mit den 70 Prozent das Modell in 100en Varianten mit AutoML gerechnet (auch Zeitreihenmethoden vielleicht). Und siehe da, das Modell ist gut. Die Vorhersagen funktionieren auch, wie wunderbar. Dennoch scheitern wir aber an den folgenden zwei Dingen:
- Man kann nicht einfach zufällig die Testdaten bestimmen. Für Zeitreihen will man die Zukunft vorhersagen, die ist per Definition nicht zufällig, sondern liegt in der Zukunft. Also die 30 Prozent müssen auch die 30 Prozent in der Zukunft (am Ende der Datenreihe) sein. Und das ist nicht zufällig. Aber die Methoden haben es viel leichter, wenn Tage vorhergesagt werden müssen, für die der Vortag und der Folgetag bekannt ist.
- Diese Umweltdaten sind für die Zukunft noch gar nicht vorhanden. Oder kennen Sie die Temperatur von morgen und die exakte Regenmenge? Man könnte sagen: „Da nehme ich doch einfach die Vorhersage!“ Prognosedaten sind aber nicht dasselbe wie reale Daten, also falsch. Und was mit Vorhersagen für drei Monate oder noch weiter in der Zukunft? Wieviel wird es am 31.12.2021 regnen?
Diese Modelle sind nutzlos, weil sich keiner etwas dabei gedacht hat - oder vielleicht nicht genug nachgedacht hat. Da braucht es die Erfahrung, was man modellieren kann, was zur Vorhersage verwendbar ist und wie man das modellieren kann.
Was bedeutet „Auswahl der Modelle“?
In der Statistik gibt es einen sehr wichtigen Teil, der in meinem Studium "Mathematische Statistik" hieß und bedeutet hat, dass man sich mit der Entwicklung der Schätzmethoden und dem Unterschied der Methodiken zu Punkt- und Bereichsschätzer beschäftigt hat. Diese Teile des Studiums haben mir immer wieder vor Augen geführt, dass in den meisten Vorlesungen nur die Methoden, nicht jedoch die Voraussetzungen für deren Anwendung durchgearbeitet werden. Diese Voraussetzungen sind aber wesentlich für die Anwendbarkeit und die "Nicht-Verzerrtheit" (Unbiasedness) des Ergebnisses. Das ist ein etwas sperriger Begriff um zu beschreiben, das zu messen, was man auch messen will.
Das bedeutet auch, dass es Methoden (in der Liste der möglichen Kandidaten) gibt, die wir womöglich nicht anwenden wollen. Daher benötigen alle (!) AutoML-Lösungen ein Black- bzw. White-Listing von Methoden, um die Methodenwahl einzuschränken. Das wird aber oft nicht betont. Was am Ende herauskommt ist zwar eine Methode, die zwar „gut aussieht“, aber im echten Einsatz kläglich versagen wird (müssen).
Der zweite Teil bei der Methodenwahl ist die einfache und trotzdem verzwickte Frage nach:
Was bedeutet „die bessere Methode finden“?
Mit AutoML optimiert man die Methodenwahl immer nach einer Zielgröße. Doch die Wahl der Zielgröße ist nicht unwesentlich, hat dies doch ganz wesentliche Effekte auf die Güte der Vorhersage und deren Wirkung im Generellen.
Eine der Größen ist beispielsweise die „Accuracy“ für Vorhersagen von 0/1 (also bspw. im Setting für Predictive Maintenance oder Predictive Quality). Diese Accuracy misst die Fehler gegen die richtigen Vorhersagen in einem Test-Datensatz. Dabei spielen jedoch zwei wesentliche Bereiche eine Rolle: Es lässt außer Acht, ob die Fehler nur in einem Bereich (also bspw. nur Fehler bei Vorhersage der 0 - keine Probleme, oder 1 = Maschine hat ein Problem) hat oder ausgewogen ist. Der ausgewogene Fall ist der gewünschte, in manchen Fällen aber unerreichbar.
Es gibt dabei Fälle, in denen es sogar zu einer extremen Modellwahl kommen kann, weil es einfacher ist, immer "kein Problem mit der Maschine" zu sagen, weil "Probleme" so selten vorkommen, dass der Versuch, diese vorherzusagen viel schwieriger ist.
Es stellt sich also die Frage,
Warum sollte man dann überhaupt AutoML verwenden?
Wenn wir alle oben beschriebenen Probleme verantwortungsvoll behandelt haben, also einen sauberen Datensatz haben, die Optimierungskriterien gewählt und die Methodenwahl passend eingeschränkt haben. Dann und nur dann kann das AutoML für uns etwas ganz wesentliches leisten: Über einen sehr großen Parameterraum für verschiedenste Algorithmen den optimalen heraussuchen. Es wird für uns ggf. sogar tausende Varianten rechnen und vergleichen (darüber habe ich jetzt gar nichts gesagt, denn selbst da gibt es offene Fragen). Am Ende steht eine Methode mit bestimmten Parametern (aus der Hyperparameter-Optimierung, damit das hier auch noch steht 😉).
AutoML verhindert dabei Fehler beim Programmieren der Algorithmen und der Optimierung der Parameter. Es unterstützt bei der Feature-Auswahl und Transformation, es unterstützt den Data Scientisten bei der Arbeit, so wie es ein Akkuschrauber bei einem Tischler macht. Der Tischler selbst wird aber immer noch das Schrauben und die Einstellung des Drehmoments am Akkuschrauber vornehmen. Es ist ein richtig großartiges Werkzeug und in den richtigen Händen kann es Wunder bewirken. In den falschen Händen kann es das auch, aber genauso gut das Gegenteil bewirken. Wo wir beim ursprünglichen Beginn meines Beitrags wären:
Selbst, wenn alles gut gemacht wird, kann man von außen den guten Fall nicht vom schlechten Fall unterscheiden.
Ich werde über dieses Thema auch am SQL Saturday in Wien am 24. Jänner 2020 sprechen und dort einige Beispiele dazu bringen. Dann wird die Thematik ein wenig greifbarer und noch spannender. Dort zeige ich Ihnen auch die Möglichkeiten mit AutoML, denn diese sind trotz der Probleme zu genüge vorhanden. Vielleicht sehen wir uns ja dort!
Wenn Sie zu Data Science im Allgemeinen oder AutoML im Besonderen Fragen haben, freue ich mich auch auf Ihre Nachricht.
