Design und Data Science Architektur

Design (Refactoring)

Um den Code übersichtlicher zu machen und zu verbessern, wurde innerhalb des Projekts ein Refactoring-Prozess verwendet. Der Code wurde dabei in Funktionen und Dateien aufgeteilt. Das Resultat des Refactoring ist, dass der Code einerseits besser testbar und andererseits konfigurabel gemacht wurde. Durch Refactoring und Design Patterns wird der Code deutlich skalierbarer.

Data Science Architektur

  • Dashboard

Das Dashboard von Frunch Infinity wurde mittels Streamlit entwickelt. Die Bedienung des Dashboards ist sehr einfach und verzichtet auf unnötige Funktionen. In einer Sidebar ist der zu trainierende Datensatz auswählbar (derzeit lediglich Turbofan), ob es sich um ein Regressions -oder Klassifikations-task handelt (vorerst nur Regression), ein Button zum Anzeigen der letzten Trainingsergebnisse und ein weiterer Button zum Starten des Re-Training’s. Das Dashboard weist also durch seine minimalistischen Funktionen eine gewisse User-Freundlichkeit auf und die Möglichkeit die trainierten Modelle direkt und übersichtlich zu evaluieren. Der größte Nachteil des Dashboards ist derzeit, dass das Modell-Training mit PyCaret sehr lange dauert (ca. 8min). Dies ist natürlich schlecht für die User-Experience und daher muss die Performance innerhalb des Model-Monitoring implementiert werden.

  • Pipeline Ansatz

Derzeit verwenden wir im Projekt ledigleich eine sKlearn Pipeline, die die Daten für das anschließende Modell-Training aufbereitet. Möglich wäre auch die Implementierung einer Apache Airflow Pipeline um verschiedene Aufgaben innerhalb des Systems zu parallelisieren und dadurch die Performance zu steigern.

  • CI/CD Pipeline

Des weiteren haben wir eine Pipeline für CI/CD (.gitlab-ci.yaml) aufgesetzt, die zwei verschiendene Stages hat. In der test Stage haben wir zum einen den test-job implementiert, welcher die Unit-tests durchführt. Im Pages-job, welcher parallel läuft, wird neben den dependencies auch die Dokumentation mittels PDOC erstellt. Innerhalb der build stage wird ein Image vom Docker-File erstellt, dieses wird auf GitLab gespeichert und bei einem Release würde dann (wenn es eine deploy stage gäbe) die Applikation in einem docker container aufgebaut.

  • Model Performance

Wird das ML-Modell in der Streamlit-Applikation zum Re-Training getriggert, erscheint auf der UI ein Spinner, welcher eine sogenannte queue für ML-Jobs bereitstellt. Sobald das Training beendet ist, bekommt der User eine Benachrichtigung, dass die Trainingsresultate nun via Klick auf den “Letzte Trainingsergebnisse anzeigen” Button verfügbar sind. Dies verhindert zwar nicht die lange Wartezeit, verhindert allerdings, das der User die Seite verlässt und vermutet das die Applikation Fehler aufweist.

Zu der Data Science Architektur des Projekts kann abschließend gesagt werden, dass der CRISP-DM Zyklus in Verbindung mit kontinuierlicher Evaluation, Retraining und Monitoring recht gut passt. Allerdings muss das Segment des Monitoring deutlich stärker eingebunden werden um beispielsweise die Performance des Retrainings zu senken.