Data Science in der Praxis: Häufige Fehler und Vorgehen

In diesem Artikel gehen wir auf die Besonderheiten von Data Science in der Praxis ein. Wir konzentrieren uns auf die technischen Unterschiede, häufige Fehler und Herausforderungen. Dabei lassen wird die sozialen und kommunikativen Aspekte außen vor. Weiterhin zeigen wir auf, mit welchem Leitfaden wir im Data & AI Team der codecentric Data-Science-Projekte erfolgreich umsetzen. 

Data Science ist in der deutschen Firmenlandschaft angekommen. Mehr und mehr Unternehmen sehen bei der Flut an Informationen im digitalen Zeitalter die Notwendigkeit von datengetriebenen Entscheidungen. Weiterhin kursieren im Jahr 2019 auf LinkedIn bis zu 56% mehr Stellenanzeigen für Data Scientists als im Jahr 2018 . 

Die Projekte in diesem Umfeld reichen von reinen Datenexplorationen bis hin zu der festen Integration von Machine Learning in die Unternehmensprozesse und datengetriebenen Produkte. Blicken wird in den Kundenservice können wir mithilfe von einer explorativen Datenanalyse Erkenntnisse über die Anzahl an Tickets und deren Themen erhalten. Für die Integration von Machine Learning in den Kundenservice-Prozess können wir ein System entwickeln, das die Tickets automatisiert anhand des Textes klassifiziert und anschließend der zugehörigen Fachabteilung zuordnet.

Die große Frage hierbei ist, mit welchen Methoden Data-Science-Projekte erfolgreich durchgeführt werden. Grundsätzlich sind Data-Science-Projekte stark volatil und benötigen ein exploratives Vorgehen. Weiterhin werden die Erkenntnisse über die Daten sukzessive gewonnen, wodurch die Planung eines Projekt deutlich erschwert wird. Diese Eigenschaften zeigen, dass ein Wasserfallmodell spezifisches Vorgehen nicht für Data-Science-Projekte funktionieren kann. Ein agiler Rahmen ist zwangsweise notwendig um Data-Science-Projekte erfolgreich umzusetzen.

Data Science: Projekt-Dimensionen

Dimensionen von Data Science Projekte: Data, Model und Code

Grundsätzlich gibt es die drei Dimensionen Data, Model und Code,  die bei der Entwicklung von Data-Science-Projekten aufeinander treffen

• Data: Daten werden von diversen produktiven Systemen erzeugt und müssen abgespeichert werden, um sie anschließend weiterzuverarbeiten. Weiterhin spielen Faktoren wie die Menge, die Größe und die Geschwindigkeit der produzierten Daten eine wichtige Rolle für die Technologieauswahl.
• Model: Das Modell wird anhand der Daten trainiert. Hierbei wird ausgehend von der Problemstellung die Methodik bzw. der Algorithmus gewählt. 
• Code: Software muss hier sowohl für die Modellentwicklung als auch für das Modelldeployment geschrieben werden. 

Das bedeutet, dass Veränderungen einer Dimension zu Wechselwirkungen auf einer anderen Dimensionen führen können. Beispielsweise führt die Modifikation der Datenerzeugung an einem produktiven System dazu, dass die sich Verteilung der Daten ändern kann. Implizit wirkt sich das auf die Vorhersagekraft des Modells aus. Eine Möglichkeit dieses Problem zu beheben ist das erneute Trainieren des Modells mit den neuen Daten. 

Ein konkretes Beispiel, das wir schon erlebt haben, und ebenfalls die Wechselwirkung zwischen den Dimensionen verdeutlicht, liegt an der Untersagung des Gesetzgebers bei der Verwendung spezifischer Kundendaten. In dem Projekt hat dies dazu geführt, dass wir spezifische Felder nicht mehr für die Vorhersage nutzen könnten. Dieses Phänomen haben wir in der Bankenbranche erlebt. Zusammengefasst haben sich die gesetzlichen Richtlinien auf Datenvorbereitung, Modelltraining und Anpassung der produktiven Umgebung ausgewirkt.

Neben den drei Dimensionen Data, Model und Code bildet die Infrastruktur eine weitere Achse. Es müssen unterschiedliche Infrastrukturen für Datenspeicherung, Datenverarbeitung, Modelltraining, Modelldeployment und Modellmonitoring betrachtet werden. Je nach der Betriebsstrategie eines Unternehmens, ob On-Premise, Cloud oder Multi-Cloud, sehen die Anforderungen an die Infrastruktur der jeweiligen Komponenten sehr unterschiedlich aus.

Häufige Fehler bei Data-Science-Projekten

Nachdem wir uns die Dimensionen der Projekte etwas näher angeschaut haben, widmen wir uns den häufigen Fehlern, die in der Praxis durchlebt werden.

Zu konkrete Planung

Gerade zu Beginn eines Projekts werden diversen Aufgaben bzw. Tasks gesammelt und geplant. Unserer Erfahrung nach kann sich die Definition und die Zeitschätzung der Tasks als sehr schwierig und zeitaufwändig gestalten. Daten kennenzulernen benötigt Zeit. Mit der Definition von spezifischen Tasks wird mehr Zeit in Anspruch genommen als nötig. Besser wäre hier, einfache Wochenziele festzulegen und anhand dieser Erkenntnisse die nächsten Schritte zu planen. Wenn sich beispielsweise das Projekt im Status der Datenqualitätsuntersuchung befindet, kann sich das Team eine Woche Zeit nehmen, um hier Erkenntnisse zu sammeln. Am Ende der Woche werden die Erkenntnisse zusammengefasst und anschließend gemeinsam über die nächsten Schritte entschieden.

Fehlendes Domänenwissen

Mit der Statistik können die Korrelationen berechnet werden. Eine klassische Fehlerquelle ist, dass die Kausalität mit den Korrelationen innerhalb der Daten erklärt werden kann. Die Korrelation beschreibt den Zusammenhang zwischen zwei Variablen. Die Kausalität beschreibt die Ursache und Wirkung. Eine Kausalität nicht immer unbedingt mit der Korrelation erklärt werden. Wie absurd Korrelationen sein können, zeigt der Blog Spurious Correlations von Tyler Vigen .

Beispiel für Korrelation != Kausalität (Quelle: https://tylervigen.com/spurious-correlations)

Das Diagramm vergleicht die Auftritte von Nicolas Cage in diversen Filmen mit der Anzahl von Personen, die beim Sturz in ein Schwimmbecken ertrunken sind. Ohne die genaue Bedeutung der Merkmale würden wir diese Korrelation als sinnvoll betrachten und eine Wechselwirkung für möglich halten. Gerade an dieser Stelle ist es wichtig, die Korrelationen mit spezifischen Domänenwissen zu prüfen und zu untersuchen, um daraus den realen Wert zu bestimmen. 

Oftmals können die Daten nicht ohne spezifische Domänenwissen erklärt werden. Für Data Scientists braucht es oftmals sehr viel Zeit, die Daten ordnungsgemäß zu interpretieren, während der Fachmann oft die Zusammenhänge kennt. Aus diesem Grund sehen wir es als essentiell an, dass ein Fachmann Bestandteil des Projektteams ist, um das Expertenwissen zugänglicher für den Data Scientist zu haben.

Zu wenig Aufmerksamkeit für Datenschutz

Bei jedem Projekt gilt es, die Sensibilität der Daten und den damit verbundenen Datenschutz (https://dsgvo-gesetz.de/ ) zu berücksichtigen. In der Vergangenheit musste ein Projekt angehalten werde, weil nicht klar, ob die Verarbeitung der kundenspezifischen und personenbezogenen Daten noch erlaubt war. Meistens sind in den Projektteams wenig bis überhaupt keine Datenschutzexperten vorhanden. Dennoch finden sich diese Experten im Unternehmenskontext. Für das Projektteam und den Projekterfolg ist der schnelle Kontakt zu den entsprechenden Personen sehr wichtig, um bei Problemen und Rückfragen einen Projektstopp zu verhindern. Weiterhin kann es anhand unserer Projekterfahrung sehr sinnvoll sein, dass in den ersten Wochen des Projekts ein Datenschutzbeauftragter als festes Bestandteil in das Team mit aufgenommen wird und somit nicht nur als ein externer Ansprechpartner fungiert.

Kein sichtbarer Return on Investment für Stakeholder

Ein klassisches Problem in Unternehmen, die das erste Mal mit Data Science experimentieren ist, dass für die Stakeholder kein direkt sichtbarer Return on Investment entsteht. Dies passiert meist, wenn sich das Projektteam mit der Modellentwicklung zu intensiv beschäftigt und die Inbetriebnahme des Modells nicht im Unternehmenskontext berücksichtigt wird. Um das zu vermeiden, versuchen wir gemeinsam mit dem Kunden im ersten Schritt ein sehr simples Baseline-Modell zu trainieren. Die Performance dieses Modells gilt es in den kommenden Wochen innerhalb des Projekts zu schlagen und zu verbessern. Der Vorteil ist, dass wir nach diesem Schritt das Modell an Entwickler-Team übergeben können, das sich mit der Integration und dem Deployment auseinandersetzt. Dadurch kann an der Modellentwicklung und dem Modelldeployment gleichzeitig gearbeitet werden, wodurch das Projekt schneller in das produktive Umfeld gelangt und dadurch effizienter im Unternehmenskontext integriert werden kann.

Aus eigener Erfahrung lohnt es sich, im Vorfeld die Fakten und Aspekte aufzuzählen und zu sammeln, die mit der Verbesserung einer Vorhersage beeinflusst werden. Gemeinsam mit den Entscheidungsträger kann auf dieser Grundlage der Return On Investment (ROI) sowie der Pain on Invest besser eingeschätzt werden. Beispielsweise ist es sehr ungewiss, ob die Zeitersparnis eines Tages pro Monat für den Aufwand eines Vier-Personenjahre-Projekts gerechtfertigt und der Return on Investment hoch genug ist, um diese Risiko einzugehen.

Manuelle Versionierung von Daten und Modellen

Manuelle Änderungen an Daten gefährden die Reproduzierbarkeit der Experimente, die von den Data Scientists ausgeführt werden. Das hat den Nachteil, dass man nicht unbedingt nachvollziehen kann, warum ein Modell besser funktioniert als ein anderes, trotz des gleichen Algorithmus. Während das Versionieren von Code mit bspw. git bereits zum Entwickleralltag gehört, entstehen aktuell neue Tools wie DVC um Daten zu versionieren. Wenn sich das Projektteam vergrößert, ermöglicht Datenversionierung, dass sich neue Teammitglieder direkt ohne größeren Aufwand Zugang zu den Daten verschaffen können. Projekte ohne Datenversionierung neigen oft dazu, technische Schulden zu entwickeln, da die Daten an unterschiedlichen Orten abgelegt werden und komplexe Strukturen entwickeln. Gerade durch automatisierte Versionierung werden die technische Schulden im Kontext auf das Datenmanagement reduziert und das Projektumfeld effizienter gestaltet.

Wie setze ich Data-Science-Projekte erfolgreich um? 

Die aufgezeigten Fehler haben wir in unserer langjährigen Erfahrung bei der Umsetzung von Data-Science-Projekten innerhalb der codecentric gesammelt. Durch den Erfahrungsaustausch zentrieren wir unser Wissen und vermitteln unseren Kunden in Trainings und Workshops unsere Learnings zur Umsetzung von Data-Science-Projekten. 

Datenprojekte sind je nach Unternehmensorganisation, -struktur und Anwendungsfall sehr unterschiedlich. Im Data & AI Team haben wir aus unserer Projekterfahrung ein vierstufiges Phasenmodell abgeleitet, das auch den Wissenstands eines Unternehmens bei der Umsetzung von Data-Science-Projekten berücksichtigt:

Die Phasen: Enablement, Proof of Concept, Minimum Viable Product und Professionalisation im Verhältnis zum ROI und Zeit

1. Enablement-Phase: Beim Enablement geht es darum, Mitarbeiter für Data-Science-Projekte auszubilden. Hierzu gehört die Vermittlung von Data Science, Machine Learning und Deep Learning. Als codecentric haben wir ein Artificial Intelligence Bootcamp entwickelt, das mit Hilfe einer eigenen Lern-Plattform praktisches Wissen zu Machine Learning und Deep Learning kostenfrei vermittelt. Weiterhin bieten wir mit dem Format Brown Paper Bag Lunch kostenfreie Vor-Ort-Vorträge für Firmen im Bereich Data Science & Data Engineering an. Über Trainings und Workshop vermitteln wir technische Deep Dives zu bestimmten AI Themen an, wie beispielsweise End-2-End vom Keras TensorFlow-Modell zur Produktion oder Deep Learning mit Keras und TensorFlow . Weiterhin entwickeln wir aktuell ein kompaktes Training um Agile Coaches und Projektmanager für Data Science Projekte vorzubereiten. 
2. Proof-of-Concept-Phase: In der PoC-Phase bestimmen wir die Machbarkeit und Realisierung eines Business Case anhand der im Unternehmen vorhandenen Daten. Dazu führen wir explorative Datenanalyse durch, lernen die Daten kennen und erfassen, ob eine bestimmte Fragestellung durch die Daten beantwortet werden kann. Am Ende der PoC-Phasen stellen wir dem Entscheidungsträger die gewonnenen Informationen vor und zeigen, welche Schritte notwendig sind, um ein mögliches Produkt zu entwickeln.
3. Minimum-Viable-Product-Phase: Gestaltet sich die PoC-Phase erfolgreich, kann mit der eigentlichen Produktentwicklung innerhalb der MVP-Phase begonnen werden. Hierbei steht sowohl die Modellentwicklung als auch die Inbetriebnahme des Modells im Vordergrund. Die MVP-Phase betrachten wir als abgeschlossen, wenn ein Modell mit entsprechender Softwarequalität in den Unternehmenskontext integriert wird.
4. Professionalisierung: Nachdem der MVP abgeschlossen ist und die ersten Modelle im Unternehmenskontext angekommen sind, geht es um die Professionalisierung der System. Wir bezeichnen dies als Machine Learning in Production. Der Fokus in dieser Phase liegt auf der Entwicklung eines robusten Systems, das die Modellentwicklung und die Modell-Inbetriebnahme semi-automatisiert. Für die Modellentwicklung bedeutet dies, dass Modelle mit neuen Datenbeständen automatisiert trainiert werden können. Weiterhin werden Metriken gesammelt und zentral zur Verfügung gestellt. Innerhalb der Inbetriebnahme des Modells werden CI/CD-Konzepte implementiert, welche die produktive Umgebung sowie die Predictions überwachen und kontrollieren. Ein weiterer Teil dieser Phase ist die Konzeptionierung einer Data Feedback Loop. Die Data Feedback Loop hat den Zweck, anhand von bestimmten Qualitätskriterien die Produktionsdaten in neue Trainings- und Test-Datenbeständen aufzuteilen.

Die Phasen bilden den Lifecycle von Data-Science-Projekten ab und werden sequentiell durchlaufen. Die Abbildung (oben) stellt die Phasen ins Verhältnis zu der Zeit und dem Return On Investment (ROI). Die Enablement- und POC-Phasen sind als reines Investment für die Entscheidungsträger zu betrachten. Nach Abschluss der MVP-Phase kann das entwickelte System bereits in den Unternehmenskontext und in die Prozesse integriert werden. Der höchste ROI wird in der Professionalisierung erzielt, da die entwickelten Modelle in einer robusten produktiven Anwendung zum Einsatz kommen und automatisiert datengetriebene Entscheidungen in den Anwendungen durchführen. 

Weiterhin müssen der Softwarequalität- und der Automatisierungsgrad mit dem Eintreten der Professionalisierungs-Phase verbessert werden. Während in der PoC- und MVP-Phase Daten/Modelle teilweise noch manuell verarbeitet und trainiert werden, wird in der Professionalisierung-Phase stark auf Automatismus gedrängt. Modelle sollen automatisiert mit neuen Datenbeständen trainiert werden und verbesserte Modellversionen schneller im produktiven Umfeld ankommen. Weiterhin ist es zu erwarten, dass Softwarequalität und -testing erst ab der Professionalisierung-Phase von Bedeutung sind. 

Für Unternehmen, die am Anfang der Implementierung von Data Science in der Organisation stehen, vermitteln wir durch die Enablement-Phase die Best Practices aus der Industrie und schaffen einen Überblick für die Mitarbeiter in der Data-Science-Projektwelt.

Für Unternehmen, die sich bereits mit Data Science stärker beschäftigen, empfehlen wir die Phasen ab der PoC-Phase sequentiell zu durchlaufen. In der Vergangenheit hatten wir auch schon Projekte, bei denen wir in der PoC-Phase festgestellt haben, dass die Daten nicht zur Realisierung des Business Case passen. In einem solchen Fall schauen wir uns die Datensituation genauer mit dem Kunden an und zeigen ihm auf, welche weiteren Schritte notwendig sind bzw. wären, um mit einem Datenprojekt anzufangen. 

Ab der MVP-Phase sehen wir Tooling für die automatisierte Daten- und Modellverwaltung als notwendig an, um die Geschwindigkeit des Projekts aufrechtzuhalten und mehr Struktur innerhalb der Projekte zu ermöglichen. Weiterhin werden technische Schulden reduziert und der Experimentierfähigkeit keine Grenzen gesetzt.

Fazit

Data-Science-Projekte haben ihre speziellen Eigenschaften, die neue Herausforderungen in dem Vorgehen und zwischen IT, Engineering und Fachbereichen offenbaren. Die drei Dimensionen Data, Model und Code führen dazu, dass die Projekte komplex werden. Ein durchdachtes Staffing im Projekt, die Nähe zu Fachbereichen und Datenschutzbeauftragten sowie das geeignete Tooling für die automatisierte Daten- und Modellverwaltung führen dazu, die Risiken zu minimieren und heben die Geschwindigkeit des Projekts an. Weiterhin haben wir durch die strukturierte Herangehensweise mithilfe der Phasen die beste Erfahrung bei der Umsetzung der individuellen Data-Science-Projekte gemacht.