Precision, Recall, F1-Score, oder doch Mean-Squared Error - wie bewerte ich eigentlich meine Maschine Learning Algorithmen? In diesem Artikel möchte ich mit euch einen anderen Blickwinkel diskutieren und die Frage aufwerfen ob nicht schon vor der Auswahl des Problems Metriken aus dem Business ausschlaggebend für die Auswahl des Use-Cases sein sollten, bevor wir uns mit Data Science oder Maschine Learning Fragestellungen befassen. Denn während sich Research mit dem Verbessern der Modelperformance auf Benchmark Daten befasst, soll in der Industrie vor allem ein Mehrwert für das Unternehmen oder deren Kunden geschaffen werden und ist es nicht optimal, wenn wir diese Verbesserung am Ende messen können?
Im weiteren Verlauf des Blogs möchte ich darauf eingehen:
1. Wieso es eine gute Idee ist den Prozess zuerst zu verstehen und messbar zu machen, bevor ein Machine Learning Projekt gestartet wird.
2. Warum Lösungen schnellstmöglich in einem produktiven Szenario getestet werden sollten, um den Mehrwert für das Unternehmen zu adressieren.
Bei der Anwendung von Data Science im Unternehmen, muss neben der Güte des Modells auch der Einfluss auf das Business bewertet werden werden. Nicht immer ist diese Verbindung eindeutig bzw. der Zusammenhang direkt. Manchmal spielen weitere Faktoren eine Rolle z.B.: Antwortzeit bei Suchmaschinen eine oder bei Vorhersagen zur Entscheidungsunterstützung wie der Nutzer die Vorhersage verarbeiten kann. Deshalb ist es oftmals nicht genug ein Modell isoliert zu betrachten, sondern es sollte in dem kompletten Kontext des Geschäftsprozesses betrachtet werden.
Beispielproblemstellung in der Produktion
Ich möchte es genauer Anhand eines Beispiels der Produktion erläutern: Ein Unternehmen stellt fest, dass sich die Kosten durch zu spät gelieferte Aufträge erhöhen. Durch Just-in-time oder Just-in-sequence Lieferungen in der Produktion und damit verbundene Lieferverträge entstehen für das Unternehmen bei Verzögerungen enorme kosten. Das Unternehmen möchte die Anzahl der zu spät gelieferten Aufträge bzw. dadurch entstandene Kosten verringern. Eine erste Idee ist, durch Predictive Maintenance die Ausfallzeiten verringert werden.
Würde man sich jetzt direkt für diesen Lösungsansatz entscheiden, geht meiner Meinung nach nun aber einiges Verloren: Das Team wird zwar ein Verständnis für die Ausfälle in der Produktion Entwickeln, aber kein Verständnis für das gesamte Problem der Verspätungen bzw. den Herstellungsprozess. Damit ist es in der Lösungsfindung bereits eingeschränkt. Das Unternehmen lernt wenig über den Prozess, dabei es ist evtl. gar nicht bekannt ob Maschinenausfälle verantwortlich für die meisten Verzögerungen sind oder andere Faktoren wie Lieferengpässe oder eine unzureichende Planung. Besser wäre es hier also, erstmal den Prozess Messbar zu machen und aufzuzeigen, wodurch Verspätungen entstehen. Eine zu frühe Festlegung auf einen Lösungsweg und nicht messbare Prozesse tragen vermutlich dazu bei, dass es viele der Data Science Projekte nicht aus einer Sandkastenumgebung herausschaffen.
Schaffung von Prozessverständnis und Quantifizierung der Prozessqualität
Um die Lösungsfindung besser zu gestalten, sollte zu Beginn eines Projektes ein gemeinsames Verständnis von dem Prozess und Problemquellen in diesem geschaffen werden. In dieser Phase sollte auch überlegt werden durch welche Kennzahlen der Prozess gemessen werden kann. Dabei sollte ein Set von Kennzahlen entworfen werden, welche die Qualität des Prozesses beschreiben. Basierend auf diesen Kennzahlen kann dann bewertet werden, wo die derzeitige Lösung steht und wo das größte Potential für Verbesserungen ist.
”Measurement is the first step that leads to control and eventually to improvement. If you can't measure something, you can't understand it. If you can't understand it, you can't control it. If you can't control it, you can't improve it. (H. James Harrington)”
Wenn Potential für Verbesserungen erkannt werden, können Stellschrauben erarbeitet werden, durch welche eine Verbesserung erreicht werden kann. Aus den Stellschrauben können Lösungswege abgeleitet und nach Potential und Machbarkeit priorisiert werden. Im Beispiel der Produktion könnten z.B. folgende Informationen gesammelt werden: 1) Verspätung des Auftrags
2) Verzögerung durch Ausfälle
3) Verzögerung durch fehlendes Personal
4) Verzögerung durch fehlendes Material
5) Stückzahl pro Stunde
6) Verzögerung bei Start in Minuten
7) Verzögerung durch Rüstzeit
8) Ausschussanteil
Vom POC zu einem Praxistest
Ist nun die Entscheidung für einen Lösungsweg gefallen und die Daten sind vorhanden, kann dieser in ein Data Science Problem überführt werden und es kann mit der Entwicklung eines POCs begonnen werden. Ziel dabei sollte es sein die Methoden mit einfachen Baseline Lösungen zu vergleichen und die Machbarkeit festzustellen, gibt es hier erste Erfolge sollte die Methode möglichst schnell in einer produktionsnahen Umgebung getestet werden. Dafür ist es wichtig, frühzeitig ein Deployment Scenario zu entwickeln. Dabei hilft es, wenn das Unternehmen einheitliche Lösungen für das Betreiben von Machine Learning Methoden (MLOps) bereitstellt.
Für eine Bewertung der Lösung ist es also nötig die Vorhersagen im Rahmen von einem Test oder Pilot in dem Prozess zu testen. Dieser Test ermöglicht neues über den Prozess zu lernen, die Methoden zu verbessern und zu bewerten, ob sich durch die Vorhersage ein Mehrwert generieren lässt. Das ist vor allem nötig, wenn die Vorhersage nur indirekt die Metrik bzw. den Prozess beeinflusst. Verschiedene Ergebnisse eines Praxistests sind unter anderem:
Unzureichende Daten-Qualität/Menge: Reichen Datenqualität oder Menge nicht aus, kann es sinnvoll sein zuerst weitere Daten zu sammeln. Fehlen z.B. durch Saisonalität Informationen, sollten weitere Daten gesammelt werden, bis Daten alle Periode der Saisonalität abdecken.
Unzureichende Modellgenauigkeit: Kann das Problem umformuliert werden kann, weitere Datenquellen hinzugenommen werden oder gibt es noch andere Methoden, die eine angestrebte Genauigkeit erzielen können. Trifft keiner der Punkte zu, sollte das Projekt an dieser Stelle nicht weiterverfolgt werden.
Problemstellung nicht ausreichend: Die derzeitige Problemstellung reicht nicht aus, um einen Mehrwert zu erzielen. Ein Beispiel wäre: Bisher wurde der Materialbedarf 24 Stunden im Voraus vorhergesagt, für eine Reaktion muss die Vorhersage allerdings 48 Stunden vorher verfügbar sein.
Unzureichende Verarbeitung der Vorhersage: Ist der Prozess nicht wie erwartet? Fehlt der richtige Umgang mit den Vorhersagen oder fehlt das Vertrauen in die Vorhersage? Je nach Problem gibt es verschiedene Ansätze: Anpassen des Problems, Schulung der Mitarbeiter, Modelerklärbarkeit für ein höheres Vertrauen.
Verbesserung der Metrik: Der Ansatz führt im Test zu einer Verbesserung. Der Test kann also ausgeweitet werden bzw. das finale Deployment kann vorbereitet werden. Dabei ist auch eine Entscheidung zu treffen, ob eine Weiterentwicklung des Modelles noch vielversprechend ist oder ob es sinnvoller ist andere Projekte anzugehen.
Zusammenfassung
Data Science Projekte sind experimentell. Es wird öfter vorkommen, dass ein Projekt nicht den Erwartungen gerecht wird. Durch die Entwicklung der Kennzahlen, Beginen der Datenaufbereitung und das gesteigerte Prozessverständnis, schaffen auch gescheiterte Data Science Projekte einen Mehrwert für das Unternehmen. Nach dem Projekt bleiben die Kennzahlen und das Prozessverständnis, die es ermöglichen manuell gegen Trends gegenzusteuern. Außerdem bleibt die eine Datengrundlage und ML Ops Infrastruktur die als Ausgangspunkt für weitere Analysen oder Use-Cases dienen kann. Mich würde eure Meinung dazu interessieren, wie geht ihr Data Science Projekte an? Wie bewertet ihr deren Mehrwert?
Comments