Software Engineering für Data Science

Data Science Entwickler und Teams profitieren langfristig durch die Einführung von Konventionen und Standards.

Data Science-, KI/ML-Projekte brauchen Software Engineering

Künstliche Intelligenz (KI), maschinelles Lernen (ML) und Data Science (DS) sind die Schlagworte in der Informationstechnologie (IT)-Branche. Die Mehrheit der Unternehmen bewegt sich von der Proof of Concept (POC)-Phase zur Produktion und Monetarisierung von KI/ML/DS-Lösungen. Aufgrund der Art der Arbeit, die in die Projekte involviert ist, unterscheiden sich Teamzusammensetzung, Qualifikationsanforderungen und die Kernentwicklung von KI/ML/DS etwas von der traditionellen Softwareentwicklung. Die Einbeziehung von Datenexploration, Data Engineering, Experimenten und spezialisierten Tools wie Jupyter-Notebook trägt zur Komplexität bei.

Wenn Sie sich vom Experiment zur Produktion und Monetarisierung bewegen, ist es wichtig, die KI/ML-Projekte aus der Perspektive des Software-Engineering zu betrachten. Der Denkprozess ist in der Branche nicht neu. Pioniere der Branche, wie Google und Microsoft, haben bereits Forschungsergebnisse und Sichtweisen diskutiert und veröffentlicht.

Aufgrund des zunehmenden Bewusstseins-Hypes und der geschäftlichen Bedeutung erhält die KI/ML-Komponente größere Aufmerksamkeit in allen IT-Projekten. Sobald der sehr wissenschaftliche Prozess der Modellbildung abgeschlossen ist, wird sie zu einer Teilkomponente in einem IT-System des Unternehmens bzw. Organisation. Und ein ganzer Satz von IT-Systemkomponenten wird Teil der umfassenderen Lösung. Dies ist der Punkt, an dem Software Engineering AI/ML verbindet.

Vom Notebook zum verteilbaren Code

Data Scientists lieben es, die Modelle in Notebooks zu erstellen. Meistens wird ein Notebook und die dazugehörigen Artefakte zu einer Ansammlung von CSV und DataFrames, welche durch Code und Plots zusammengehalten werden.

Verschiedene IT-Rollen werden dies aus einer anderen Perspektive sehen. Codierungsstandards, hartcodierte Werte, Mangel an wiederverwendbaren Funktionen, absolute Null-Dokumentation und fehlende Nachvollziehbarkeit. Wenn ein Unternehmen in Richtung Reife im KI/ML/DS-Bereich marschiert, ist es unerlässlich, eine Software-Engineering-Praxis festzulegen. Die Frage ist, welche Persona dafür verantwortlich sein sollte, Data Scientist, Data Engineer oder Machine Learning Engineer?

Was sind die High-Level-Fokusbereiche und Checkpunkte, um die Schwachstellen zu reduzieren oder zu beseitigen?

  • Sauberer und wartungsfreundlicher Code
  • Testgetriebene Entwicklung
  • Versionskontrollierte Artefakte
  • Datentechnik und Pipelines
  • Best Practices für API-Design und -Einsatz
  • Do's und Don'ts von Open Source
  • Fortlaufende Integration/Lieferung
  • Geistiges Eigentum und KI/ML
  • Regulatorische Herausforderungen

Frühere Publikationen

Eine der bemerkenswertesten Arbeiten ist die von Google-Ingenieuren mit dem Titel "Hidden Technical Debt in Machine Learning System" . Der Artikel wurde im Jahr 2015 auf der NIPS-Konferenz veröffentlicht. Das Papier von Microsoft-Ingenieuren aus dem Jahr 2019 ist eine der anderen bemerkenswerten Arbeiten auf diesem Gebiet. Das Papier trägt den Titel "Software engineering for machine learning: a case study". Das Papier "The emerging role of data scientists on software development teams", ist ebenfalls eine bemerkenswerte Arbeit, die das Thema diskutiert. Die meisten dieser Arbeiten waren Teil von akademischen und begrenzten Unternehmensdiskussionen. Um interessierten Unternehmen nachhaltige Unterstützung zu bieten, veröffentlichte Gartner das Whitepaper "Preparing and Architecting for Machine Learning" mit professionellen Ratschlägen.

Solider Code braucht Regeln

'Code wird öfter gelesen, als er geschrieben wird' ist eines der berühmten Sprichwörter unter Software-Ingenieuren. Wenn wir Code schreiben, unabhängig von der Zielsetzung (Data Science oder nicht), der Sprache (R, Python oder Scala) oder der Art des Projekts, macht ein klar strukturierter Code das Leben des Entwicklers einfach. Wie mansich selbst oder sein Team zu einer Clean-Code-Armada bringt, ist eine anspruchsvolle Aufgabe. Hier kommt die Bedeutung von Coding-Standards ins Spiel. Ein gut definierter Standard, ein angepasster Coding-Standard, dem ein Team von Ingenieuren und Datenwissenschaftlern folgt, stellt immer sicher, dass wartbare Software-Artefakte erstellt werden.

Kodierungsstandards

Coding-Standards sind mit Leitfäden vereinbarte Best Practices, die eine Gruppe von Entwicklern zu befolgen beschlossen hat. Der vereinbarte Leitfaden sagt, wie der Code geschrieben werden muss, damit der Projektcode für alle Entwickler konsistent ist. Alle reifen Softwareentwicklungs- und Produktteams erstellen und pflegen immer einen solchen Standard als Referenz. Seit dem Beginn der Multi-Technologie- und Multi-Sprachen-Entwicklung ist es eher eine Anforderung, da die Leute zwischen den Sprachen wechseln. Der Data Scientist nutzt die explorative (visuelle) und entwicklungsbegleitende Unterstützung in Notebooks und ähnlichen Technologien. In dieser Welt liegt der Fokus mehr auf dem "Modell" als auf dem Code, bis es zur Bereitstellung kommt.

Python und PEP8

Der Ptyhonista im Allgemeinen würde gerne dem PEP-8-Codierungsstandard folgen. Als Guido van Rossum Python schuf, war die Lesbarkeit eines der grundlegenden Designprinzipien. Im Allgemeinen gilt Python-Code als lesbar. Aber die Einfachheit und die mächtigen "Batterien" können es schwer machen, einfachen Code zu lesen. PEP-8 existiert, um die Lesbarkeit von Python-Code zu verbessern. In den meisten Fällen erstellen erfahrene Python-Entwickler eine eigene Python-Anleitung für die Teams. Zu den Schwerpunkten (im Allgemeinen) gehören:

  • Namenskonventionen
  • Code-Layout
  • Einrückung
  • Kommentare
  • Ausdrücke und Anweisungen
  • Allgemeine Programmierempfehlungen

Dies ist guter Startpunkt für eigene Anpassungen. Für die Data Science-Projekte und Software-Projekte im Allgemeinen gibt es noch ein paar weitere Fälle zu behandeln. Die Mehrheit der Python-basierten Projekte verwendet jetzt Python3.X. Das sogenannte "Type Hinting" ist eine der kritischen Funktionen in P3.x. Es wird grundsätzlich empfohlen, Teil der Kodierungsrichtlinien zu sein. Eines der typischen Patterns und Anti-Patterns in Data-Science-Projekten ist die Verwendung und der Missbrauch von Lambda-Funktionen. Die meiste Zeit unterstützen Lambdas den Debug-Prozess in der Produktion. Die Verwendung von Lambdas in Bezug auf Data Frame Manipulationen und den Zweck der Nachvollziehbarkeit und des Debuggens sollte erzwungen werden.

Framework-gesteuerte Muster, wie Pandas und andere Frameworks, bedürfen allerding der Aufmerksamkeit. Eines der Beispiele ist die Verwendung von SQL-Datentypen in der to_sql-API. Meistens wird ein langes Wörterbuch direkt innerhalb von to_sql getippt. Eine Variable kann dieses Muster der Einfachheit halber verwalten, eine Überspezifizierung der Datentypen ist eine einmalige Anforderung.

Ein guter Ausgangspunkt, um den Python-Codierungsstandard Ihres Teams zu erstellen, ist der Python Coding Guide von Google.

R und Code Style Guide

Bevor die "sexieste" Berufsbezeichnung "Data Science" aufkam, war R die bevorzugte Programmiersprache für Statistiker, Data Miner und ML-Forscher. Vor dieser Zeit gab es eine signifikante Akzeptanz und Verbreitung von R in Unternehmen. Da es in der Natur der Sache liegt, dass Nicht-Software-Profis den Code schreiben, wurde der Kodierungsstandard nicht weithin durchgesetzt. Dennoch, als dann eine unternehmensweite Einführung begann, waren einige Standards vorhanden. Die drei Standards sind der Tidyverse Style Guide und der Google R Style Guide. Wenn Sie sich stark auf RShiny-Anwendungen verlassen, ist es zu empfehlen, sich mit dem UI/UX-Team abzustimmen, bevor man das entsprechende Standarddokument erstellt.

IDE und Notebooks

Im Software-Engineering dient eine IDE immer als virtueller Assistent zur Einhaltung von Coding-Standards. Aber das Notebook ist nicht mit der IDE-Umgebung vergleichbar. Wenn Sie Data Scientist und ML-Ingenieure onboarden, ist es ratsam, eine Orientierung über die Coding-Standards zu beweisen. Sie sollten sowohl teamspezifische Best Practices als auch wiederverwendbare Komponenten einbeziehen.

Die meiste Zeit werden die meisten Notebooks sicherlich mit prozeduralem Code gefüllt sein (keine Funktionsklassen, etc.). Der Code kann mehrmals wiederholt werden; die explorative Datenanalyse ist ein typischer Fall dafür. Es ist allerdings besser, wiederverwendbare Funktionen zu erstellen. Dadurch werden Copy-Paste-Fehler und "Haarspaltereien" in einer hochgradig iterativen Modellierungsumgebung vermieden. Langfristig können Sie damit eine gute Sammlung oder Bibliothek erstellen, die im gesamten Unternehmen verwendet werden kann.

Werkzeuge

Es gibt einige ausgezeichnete Tools, die bei der Formatierung und Überprüfung der Codierungsstandards helfen. Flake8 ist so ein Tool, und viele Entwickler verwenden es zusammen mit VSCode. Wenn Sie mit R und RStudio kodieren, empfiehlt sich "lintr" zu installieren, damit stellen Sie sicher, dass der Editor für eine statische Code-Analyse konfiguriert ist.

Auch Testen will gelernt sein

Testgetriebene Entwicklung (TDD) ist in der Software-Engineering-Praxis sehr beliebt. Wenn es um Data Science/Machine Learning-Projekte geht, schrumpft es auf Validierung und Kreuzvalidierung. Im besten Fall handelt es sich um A/B-Tests des Modells. ML-Modelle werden im heutigen Szenario zu einem Teil der legeren IT-Systemkomponenten. Es ist also höchste Zeit für Unternehmen, über TDD in Data Science- und Machine Learning-Projekten nachzudenken.

TDD ist eine Software-Engineering-Praxis, bei der ein Unit-Test geschrieben werden muss, bevor der Code validiert werden soll. Wir werden hier nicht das Was und Wie der testgetriebenen Entwicklung im Software Engineering diskutieren. Zu diesem Thema gibt es eine Fülle von Ressourcen. Unser Hauptaugenmerk liegt auf der Diskussion, wie man den Testhorizont in DS/ML-Projekten über Kreuzvalidierung und Testdaten hinaus erweitern kann.

Code-Lebenszyklus in der Data Science

Data-Science-Projekte haben feste Phasen, die vom Geschäftsverständnis bis zur Operationalisierung des Modells reichen. Jede dieser Phasen führt zu verschiedenen Ergebnissen und ist von mehreren Tools oder Plattformen abhängig. Kurz gesagt, sind Datenverständnis und -analyse (oder explorative Datenanalyse), Feature-Auswahl und -Entwicklung, Modellbildung und Modell-Operationalisierung die wichtigsten Phasen. Die Explorationsphase endet im Wesentlichen damit, dass einige Tests in den Eingabedaten durchgeführt werden (ohne sie explizit als Test zu bezeichnen). Der einzige Test, der danach durchgeführt wird, ist die Validierung/der Test mit Holdout-Daten. Der Code aus dem Feature-Engineering zur Modellerstellung wird immer im Modell-Operationalisierungsteil wiederverwendet. Dies ist die wichtigste Phase, in der Ihr AiOps-Team (DevOps für KI/ML) mit Ihnen interagieren wird. Die Verfügbarkeit von Testfällen wird das Leben von AiOps und die Validierung von Deployments reibungslos gestalten.

Wo soll getestet werden und was soll getestet werden?

Fast jeder Schritt im Machine Learning/Data Science-Prozess ist ein Kandidat für das Schreiben von Testfällen. Aber es gibt bestimmte Bereiche, in denen das Schreiben von Testfällen erwünscht ist. Zu den Phasen, in denen Testfälle erforderlich sind, gehören:

  • Explorative Datenanalyse
  • Datenvorverarbeitung
  • Feature Engineering
  • Daten-Pipelines
  • Modell und Modell-Pipelines
  • Deployment-Skripte und APIs

In der Machbarkeitsstudie zur Anwendung von ML/DS auf Daten (kein Proof of Concept) und in reinen explorativen Datenanalysephasen können Testfälle/TDD ignoriert werden. In dieser Phase ist TDD eine Extravaganz und beeinträchtigt die Lieferzeiten.

TDD und explorative Datenanalyse

Das Schreiben von Testfällen ist in dieser Phase nicht zwingend erforderlich. Meistens können wir die Datentypen, die Eigenschaften der Attribute und die statistischen Eigenschaften der Daten überprüfen. Diese Phase trägt wesentlich zum Aufbau von Datenpipelines bei. Diese Pipelines sind offensichtliche Ziele für Testfälle. Wenn Sie das Gefühl haben, dass Sie die Datenexploration in festen Intervallen wiederholen werden, ist es besser, wiederverwendbare Code-Artefakte zu erstellen. Und wiederverwendbare Artefakte sind Kandidaten für Testfälle! Denken Sie daran: Wenn die explorative Datenanalyse das einzige Ziel ist, lohnt es sich nicht, in die Erstellung von Testfällen zu investieren.

Datenvorverarbeitung

Funktionen zur Datenvorverarbeitung sind ausgezeichnete Kandidaten für Testfälle, und es ist eine Notwendigkeit. Lassen Sie uns einige Anwendungsszenarien untersuchen, um unser Argument zu begründen. Als Data Scientist oder Data Engineer mag man dies als mühsamen Aufwand empfinden. Aber ein Testfall wird Ihnen helfen, die Überraschungen, die manchmal auf Sie warten, zu minimieren.

Feature-Engineering

Das Ziehen der Daten aus den Quellsystemen in einen Data Frame und das Erstellen neuer Features ist ein Standardprozess. Es wird empfohlen, den für das Feature Engineering generierten Code zu testen. Wir werden denselben Code in der Produktion wiederholen/wiederverwenden. Genau dieser Schritt macht den Code zu einem Kandidaten für das Schreiben von Testskripten. Wenn der Code für das Deployment bereit ist, könnte man einen schnellen Test durchführen, um sicherzustellen, dass die Pipeline in der Produktionslinie wie erwartet läuft. Lassen Sie uns dies anhand eines Beispiels für einen Anwendungsfall untersuchen. Im Allgemeinen wird ein Data Scientist/Data Engineer eine Utility-Funktion schreiben. Diese Funktion wird Teil der Produktionspipeline sein. In diesem Szenario lohnt es sich, Zeit in das Schreiben von Testfällen zu investieren.

Daten-Pipelines

Datenpipelines sind ein integraler Bestandteil von Machine Learning-Workflows. Datenextraktion, Datenvalidierung und Datenaufbereitung sind drei Prozesse auf höchster Ebene. Je nach den beteiligten Quellsystemen und Transformationen sollten sie umfassende Testfälle entwerfen. Diese Testfälle können das Testen der Zeit für die Durchführung von Datenextraktionen, die Sicherstellung der Datentypen und -attribute sowie der Ausgabeattribute und -typen beinhalten. Für dieses Szenario sollte man das Schreiben einer angemessenen Anzahl von Testfällen einplanen.

Modell und Modell-Pipeline

Die Lehrbuchanweisung für das Testen von Modellen ist die Verwendung von Validierungs- und Testdatensätzen. Die Metriken wurden auf der Grundlage des Problemtyps ausgewählt, und die Projektziele bleiben Standardprozesse. Überlegen Sie nur kurz, was wäre, wenn unser Modell zufällige Vorhersagen macht! Ein solcher Test ist sowohl bei überwachten als auch bei unüberwachten Modellen nützlich. Sie können einen Dummy-Klassifikator oder eine Verdrängerklasse schreiben, um das Verhalten zu imitieren.  Wenn Sie sich nicht wohl dabei fühlen, einen solchen zu schreiben, ist sklearn hier, um Ihr Leben zu retten. Das sklearn stellt einen Dummy-Klassifikator und eine Regressionsklasse zur Verfügung. Für das Clustering wird es knifflig, ggf. müssen Sie eventuell einen eigenen Cluster-Assigner erstellen.

Einer der wichtigsten Testfälle, der benötigt und nie diskutiert wird, ist die Vorhersagekonsistenz. Die Intuition hinter der Vorhersagekonsistenz ist, dass für ein gegebenes Modell, wenn Sie eine Eingabe beliebig oft übergeben, es das gleiche Ergebnis liefern sollte. Unabhängig vom Modelltyp sollte dies gelten, vielleicht ist Reinforcement Learning ein Ausnahmeszenario. Wenn Sie in einer regulatorischen Umgebung arbeiten, ist dieser Testfall eine Notwendigkeit. Manchmal kann dieser Test einige Überraschungen aufdecken!

Der letzte, aber aufstrebende Bereich sind kontradiktorische Testfälle. Da KI/ML Teil fast jedes IT-Systems sein wird, werden die nächsten Cyber-Angriffe in Form von adversarialer ML erfolgen.  Zu den Auswirkungen eines solchen adversen Angriffs gehört die Vergiftung Ihrer automatisierten Trainingspipelines, ohne dass die Einstellungen zur Erkennung von Modellabweichungen Alarm schlagen. Adversarial Machine Learning war bereits in den frühen 2010er Jahren ein Thema. Nach der extremen Popularität von Deep Learning wurde es zu einem aktiven Diskussionsthema. Unabhängig von Deep Learning oder traditionellem Machine Learning können adversarische Angriffe Ihr KI/ML-System gefährden. Bereiten Sie sich darauf vor, die Auswirkungen von adversen Angriffen auf Ihre Modelle zu testen.

Die Machine Learning-Frameworks und -Plattformen bieten Pipeline-APIs. Die sklearn-Pipeline und Azure Pipeline API's sind Beispiele. Testfälle zur Sicherstellung der nahtlosen Integration und des erwarteten Verhaltens sind eine gute Praxis. Wenn Sie AIOps für die Bereitstellung verwenden, stellen die Testfälle sicher, dass die Bereitstellung gut verläuft.

Testen von Modellimplementierungen

Die Bereitstellung von Modellen ist ein sich entwickelnder Bereich in KI/ML-Projekten. Das Erstellen einer Flask-API, um die Leistung von Containern und einer Container-Orchestrierungsplattform zu nutzen, ist Teil der Technologielandschaft.  Wenn eine API involviert ist, sollten wir Testfälle für die API in Betracht ziehen. Unabhängig davon, ob wir ein Container- oder ein Container-Orchestrierungssystem haben, ist es erwünscht - dieselbe Philosophie für die Batch- und Ad-hoc-Inferenzsysteme.

Die praktische Einführung und Umsetzung solcher Software Engineering-Standards in einem vielfältigen, qualifizierten Machine Learning-, Data Science-Team ist nicht einfach. Möglicherweise muss man die Hürde des Widerstands überwinden, indem man sehr geduldig agiert.

Ihr Kommentar zum Artikel

"Software Engineering für Data Science"

Wir freuen uns über Ihren Kommentar und antworten so schnell es geht!

Das Angebot von "HECKER CONSULTING" richtet sich ausschließlich an Unternehmen und Behörden (iSv § 14 BGB). Verbraucher (§ 13 BGB) sind vom Vertragsschluss ausgeschlossen. Mit Absendung der Anfrage bestätigt der Anfragende, dass er nicht als Verbraucher, sondern in gewerblicher Tätigkeit handelt. § 312i Abs. 1 S. 1 Nr. 1-3 und S. 2 BGB (Pflichten im elektronischen Geschäftsverkehr) finden keine Anwendung.

Vielen Dank, Ihr Kommentar wurde empfangen!
Beim Absenden des Formulars ist etwas schief gelaufen.
Unsere Beratungs-Leistungen für Das Thema

Software Engineering

Wir erweitern ständig unser Beratungsportfolio. Über 300 Beratungsleistungen haben wir für Sie im Programm. Selbstverständlich lassen sich die einzelnen Themen kombinieren. So erhalten Sie genau die Beratung, die Sie wünschen und brauchen

Mehr IT-, Online-, Digital-Beratungsleistungen anzeigen >>
Mehr IT-, Online-, Digital-Beratungsleistungen anzeigen >>

Kontaktanfrage

Das Angebot von "HECKER CONSULTING" richtet sich ausschließlich an Unternehmen und Behörden (iSv § 14 BGB). Verbraucher (§ 13 BGB) sind vom Vertragsschluss ausgeschlossen. Mit Absendung der Anfrage bestätigt der Anfragende, dass er nicht als Verbraucher, sondern in gewerblicher Tätigkeit handelt. § 312i Abs. 1 S. 1 Nr. 1-3 und S. 2 BGB (Pflichten im elektronischen Geschäftsverkehr) finden keine Anwendung.

Vielen Dank, Ihre Nachricht wurde empfangen!
Beim Absenden des Formulars ist etwas schief gelaufen.
WEITERE INFORMATIONEN AUS UNSEREM BLOG ZUM THEMA

Software Engineering

Aktuelle und interessante Themen und Beiträge für Sie zusammengetragen und aufbereitet.

Mehr IT-, Online-, Digital-Neuigkeiten anzeigen >>
Nach oben