AutoNLP ist eine Webanwendung zur Automatisierung des Trainings von NLP-Modellen für typische Aufgaben wie Named Entity Recognition oder Textklassifikation. Die Anwendung wurde von Timo Neuhaus im Rahmen seiner Masterarbeit End-to-End-Automatisierung des Machine Learning Workflows für Natural Language Processing entwickelt.

Zur Erweiterung der Anwendung es eine Reihe von möglichen Themen.

Abschluss- und Projektarbeiten zu AutoNLP

• End-to-End-Automatisierung des Machine Learning Workflows für Natural Language Processing (Timo Neuhaus)
  In dieser Masterarbeit wurde AutoNLP entwickelt und der Tasktyp Token Classification implementiert. Damit lässt sich das Training von Entitätserkennung automatisieren.
• Implementierung des Tasktyps Textklassifikation im Paket TagFlip-AutoNLP (Kevin Fitkau)
  In dieser Bachelorarbeit wurde der Tasktyp Textklassifikation ergänzt.
• Integration der Textannotation in AutoNLP
  Für die Verwaltung von Trainingsdaten soll die Annotation von Texten in AutoNLP integriert werden.
• Testautomation
  Aktuell ist nur ein kleiner Teil der Anwendung durch Testfälle abgedeckt. Im Rahmen einer Projektarbeit könnten verschiedene Arten von Testfällen (Unit-Tests, End-to-End-Tests) umgesetzt und automatisiert werden.

Die Fachhochschule Südwestfalen baut aktuell einen Cluster für Lehre in den Bereichen KI und Data Science auf. Dabei sind eine Reihe von Aufgaben für Abschlussarbeiten zu vergeben.

Aufgabenstellungen für Abschlussarbeiten

• Monitoring des Clusters
  Der Cluster wird im Lehrbetrieb genutzt. Daher ist ein Monitoring erforderlich, das die Auslastung und die Verfügbarkeit des Clusters überwacht und bei Bedarf Alarm schlägt.

• Benutzerverwaltung
  Die Anmeldung an den Cluster erfolgt über eine Keycloak-Instanz, die ein Single-Sign-On mit der Campus-Kennung der FH Südwestfalen ermöglicht. Innerhalb von Kubernetes werden aktuell alle Benutzer auf eine Unix-Userid abgebildet, da die Benutzer innerhalb der Nodes des Clusters nicht bekannt sind. Mithilfe von FreeIPA soll eine Benutzerverwaltung aufgebaut werden, die die Benutzer innerhalb des Clusters verwaltet und eine Synchronisation mit der Keycloak-Instanz ermöglicht.

• Dashboard für den Cluster
  Die Benutzer des Clusters sollen über ein Dashboard einen Überblick über die Auslastung des Clusters erhalten. Dazu sollen die Daten aus dem Monitoring-System und aus Kubernetes zusammengeführt werden. Das Dashboard soll als Web-Anwendung realisiert werden.

• MLFlow
  Die Benutzer des Clusters sollen ihre Experimente über MLFlow verwalten können. Dazu soll eine Instanz von MLFlow auf dem Cluster installiert werden.

Weitere mögliche Themen finden finden Sie auch im GitHub Projekt zum Aufbau des Clusters.

Problemstellung

nbgrader ist ein beliebtes Werkzeug für die Erstellung von bearbeitbaren und automatisch bewertbaren Jupyter Notebooks. Es wird von vielen Universitäten und Hochschulen eingesetzt, um die Abgabe von Aufgaben zu vereinfachen und die Bewertung zu automatisieren (siehe auch das zugehörige GitHub Repository). Leider ist nbgrader nicht für den Einsatz in der Cloud (in unserem Fall ein auf Kubernetes laufender Jupyterhub) und auch nicht für den direkten Einsatz in oder mit einer Moodle Platform wie unserem elearning-Portal geeignet.

Ziele

In dieser Arbeit sollen nbgrader und daran anknüpfende Komponenten angepasst werden, sodass:

1. Studenten, Kurse, Tutoren und Aufgaben in Form von Notebooks, die auf Moodle hinterlegt sind, nach nbgrader bzw. unserem Jupyterhub synchronisiert werden.
2. Studenten, welche sich über Moodle auf einem Jupyterhub anmelden, reibungslos zu den Aufgaben geleiten werden und die Aufgaben über die JupyterLab- bzw. Notebook-GUI direkt abgeben können.
3. Von nbgrader bewertete Aufgaben nach Moodle zurückgespielt werden, um dort Punkte zu hinterlegen.

Arbeitspakete und Roadmap

In einem ersten Schritt gilt es, sich mit den Technologien und Softwarekomponenten vertraut zu machen. Hierzu zählt: Grundlegens Verständnis über die Architektur von Jupyterhub, ngbrader und Moodle (vorzugsweise die LTI 1.3 API)

Letztendlich soll ein vertikaler Prototyp entstehen, um den Prozess darzustellen, der in der Einleitung skizziert wurde. Grobe Planung des Projektes:

• 1. Recherchieren Sie zu den folgenden Themen:
  • 1.1 Welche Informationen können über ein externes Tool in einem Moodle-Kurs via LTI abgefragt werden?
  • 1.2 Wie können diese Informationen (sicher und Seiteneffekt frei) in eine nbgrader-Installation übertragen werden.
• 2. Testen Sie die Moodle API mit Postman oder ähnlichem
• 3. Bauen Sie Ihre Erkenntnisse in den Authentifizierungsprozess unseres Jupyterhubs ein. (Hierfür haben wir eine dev-Instanz)
• 4. Erstellen Sie ein Konzept für die Synchronisation mit nbgrader. Hier einige Requirements:
  • 4.1 Ein Student darf nach dem Login über Moodle nur seine eigenen Aufgaben sehen und natürlich auch keinen Zugang zu den Grading-Funktion von nbgrader erhalten.
  • 4.2 Ein Dozent der in Moodle hinterlegt ist sollte die Aufgaben auf möglichst einfache Weise bewerten können. Die wahrscheinlich beste Variante ist hierfür ein eigenes Image zur verfügung zu stellen, welches für Studenten nicht sichtbar ist.
  • 4.3 Bisher wird für die Synchronisation der Aufgaben aus Moodle ein nbgitpuller verwendet, dies bedingt die Nutzung von Github. Dies ist erstmal kein Problem, es kann jedoch sein, dass hierfür auch die Dateiverwaltung von Moodle geeignet sein könnte. Recherchieren Sie, ob dies möglich oder sinnvoll wäre.

An dieser Stelle können zusätzliche Anforderungen entstehen, da nbgrader womöglich an einigen Stellen angepasst werden muss. Zum Beispiel ist es denkbar, dass die dateibasierte Datenspeicherung von nbgrader gegen eine Datenbank ausgetauscht werden muss. Ein ähnliches Projekt existiert bereits unter dem Namen ngshare, verwendet allerdings trotzdem Dateibäume und SQlite. Auch ist die Integration mit dem nbgrader-Frontend wie Formgrader nicht ausgereift.

• 5. Prototypische Umsetzung des Konzeptes und Deployment auf unserer dev-Instanz
• 6. Erweiterung/Anpassung der GUI-Elemente von nbgrader. Speziell für unseren Use-Case sollten sowohl Studenten als auch Dozenten so wenig Zeit auf einer Kommandozeile verbringen wie möglich.

Natürlich stehen Sie bei dieser Arbeit nicht alleine im Wald, sondern erhalten stets Unterstützung, speziell wenn es um die Integration der einzelnen Komponenten oder das Deployment geht.

Alternative ist auch denkbar, einzelne Positionen als horizontale Prototypen zu erstellen. Hierzu eignen sich insbesondere Punkt 6 sowie ausgewählte Komponenten unter Punkt 5, wenn diese sich gut trennen lassen.

Was sollten Sie mitbrigen?

• Keine Angst vor komplexen Softwaresystemen
• Hohe Motivation sich in die relativ umfangreiche Archtiekltur einzuarbeiten
• Gute Kenntisse in Python
• Kenntnisse von Docker oder Kubernetes sind von Vorteil aber nicht notwendig
• Gegebenfalls sehr gute Datenbankkenntnisse

Was bekommen Sie von dieser Arbeit?

• Einblicke in den Livebetrieb verteilter Softwaresysteme
• Erfahrung über die Integration und Herstellung von Interoperabilität verschiedener Services
• Das System, das Sie (weiter-)entwickeln wird an unserer Hochschule eingesetzt und bereichert unseren Lehrbetrieb langfristig

Organisatorisches

Es ist möglich, Teile dieser Arbeit als eigene Prototypen umzusetzen. Je nach Umfang gerne auch als Team.

Ihr(e) Ansprechpartner:

Christian Gawron
gawron.christian@fh-swf.de

Max Kuhmichel
kuhmichel.max@fh-swf.de