Statusbericht

August 2023

Jonas Opitz

1. DevOps für Team 4

Motivation

Bisher: kein offizielles Schema, wie Applikationen entwickelt, geteilt oder für die Produktion bereitstellt werden

  • Erschwerte Einarbeitung und Einbettung der Services
  • Mehr Wartungsaufwand durch fehlende Synchronisation der Tools

Lösung: Nix

Nix: eine Technologie, um alle Softwareentwicklungs- und Produktionsthemen unter einem Banner zu lösen.

  • Keine gleichzeitige Pflegung mehrerer Konfigurationen
  • Erleichterte Einarbeitung durch Entwicklungsumgebungen
  • Erhöhte Reproduzierbarkeit von KI-Ergebnissen

Arbeiten in diesem Sprint

  • Recherche alternativer Technologien zu Nix
  • Recherche und Ausarbeitung von Workflows und Tools innerhalb von Nix
  • Migration der bisher entstandenen Services zu Nix

2. Einbindung der Python-Kidra in die Z-API

Motivation

Auf Wunsch der IT: Bündelung aller bisher entstandenen Services (genannt Python-Kidra)

Arbeiten in diesem Sprint

Integration der Services

Hierfür war die Isolation der einzelnen Services durch Nix sehr hilfreich, weil dadurch Konflikte zwischen Services verhindert werden und gleichzeitig die Komplexität und Größe der Kidra niedrig gehalten wird.

Dokumentation der API

Um eine einheitliche Dokumentation mit möglichst wenig Aufwand zu ermöglichen, haben wir nach Empfehlung der IT alle Services mit OpenAPI Spezifikationen versehen. Diese können in den einzelnen Services erstellt werden und dann durch die Kidra an die Z-API weitergeleitet werden.

Hierdurch mussten die meisten Services von CherryPy auf ein neues Web-Service Framework, FastAPI, umgestellt werden.

Performanceoptimierung

Einige Services haben mehrere Minuten benötigt, um zu starten. Durch Optimierungen im Build-Prozess konnte dies auf wenige Sekunden reduziert werden.

Automatisches Testen

Um Bugs in der Produktion zu minimieren, können die einzelnen Services nun automatisch, anhand ihrer OpenAPI-Spezifikation, getestet werden.

3. Recherche: Topic Modeling für die Metadatenvorhersage

Motivation

Topic Modeling könnte in Zukunft eingesetzt werden, um Metadaten wie Schulfach, Bildungsstufe oder Ressourcentyp zu generieren.

Was diesen Ansatz von anderen unterscheidet ist dessen Erweiterbarkeit und Interpretierbarkeit. Außerdem lässt er sich anwenden auf hierarchische Strukturen, wie beispielsweise der Ressourcentype.

Blocker

Ein erster Prototyp ließe sich zwar ohne weiteres entwickeln, jedoch ist stark zu erwarten, das dieser nicht sehr aussagekräftig sein wird. Hierfür gibt es zwei Blocker.

Verfügbarkeit von Volltexten

Zum einen enthalten die aktuell verfügbaren Titel und Kurzbeschreibungen über deutlich weniger inhaltliche Information über die Materialien.

Zum anderen enthalten sie viele Informationen, die für das Topic Modeling ggf. irrelevant sind (z.B. über den Ressourcentyp, die Quelle, die Zielgruppe). Außerdem sind sie geschrieben um das Publikum zu motivieren, nicht um Inhalt zu vermitteln. Diese hierdurch resultierenden "Störsignale" können nicht ohne Weiteres maschinell herausgefiltert werden.

Verfügbarkeit eines überprüften Testdatensatzes

Es existiert aktuell kein Datensatz mit nur hochqualitativen (im Sinne der Metadaten) Materialien. Stattdessen haben einige Materialien fehlende, inkonsistente, oder sogar falsche Metadaten. Diese können maschinell nicht von qualitativ hochwertigen Materialien unterschieden werden, sodass diese fehlerbehafteten Zusammenhänge genau so von der Maschine erlernt werden, wie die korrekten. Dies reduziert die Qualität der KI-Ergebnisse und erschwert die Evaluierung dieser.