Agile Implementierung einer wissenschaftlichen Studie zur qualitativen Evaluation von Suchmodellen

Um KI-gesteuerte Suchtechnologien zu verbessern, wurde eine mehrstufige Studie durchgeführt und die Qualität der entwickelten Technologie getestet. Dieser Artikel beschreibt den Studienaufbau und die agile Umsetzung.

Innerhalb des Konsortiums rund um das Service-Meister-Projekt arbeiten Krohne Messtechnik, inovex und die BHT – Berliner Hochschule für Technik zusammen bei der Entwicklung von KI-gesteuerten Suchtechnologien. Im Kontext dieses Projekts entstand der Use Case zur Durchführung einer mehrstufigen Studie zur Überprüfung der Qualität der entwickelten Suchtechnologien. Es wurde ein eigenes Web Frontend entwickelt und für den effizienten Ablauf der Studie implementiert. Dieses Web Frontend nutzt realistische Daten aus dem Service-Meister Umfeld. Die technische Grundlage für die Studie ist ein FastAPI RESTful Backend und eine Flutter Cross-Platform App.

Konzept

Nachfolgend wird das Studiendesign und eine Liste von Anforderung vorgestellt, die aus einem Studienkonzept hervorgegangen sind. Zielsetzung ist eine quantitative Bewertung, ob die implementierte Suche gut passende Ergebnisse liefert. Folgende Fragestellung soll durch die Studie beantwortet werden:

„Wie unterstützen Dich die gezeigten Service-Berichte bei der Problemlösung?“

Zusätzlich soll eine Vergleichbarkeit zwischen den verschiedenen Suchtechnologien ermöglicht werden. Es werden drei statistische Hypothesentests auf der Basis des Wilcoxon-Vorzeichen-Rang-Tests angewendet. Dabei ergeben sich die Messpunkte aus dem Vergleich einer n-Suche vs. m-Suche.

Wobei gilt:  {n, m} ∈ {Schlagwort-Suche, Synonym-Suche, BHT Modell}

Teilnehmer:innen-Zuordnung 

Within-Subjects – Wiederholte Messung aller Varianten durch den/die gleiche:n Teilnehmer:in.

Mehrstufig

Durch einen agilen Ansatz sind wir in der Lage, die Qualität der Studie stufenweise zu verbessern (siehe Abbildung 1). Die Erkenntnisse aus der Pilotstudie wurden genutzt, um Probleme im Ablauf frühzeitig zu erkennen und das Design anzupassen.

Abbildung 1: Mehrstufiger Studienaufbau

Design

• Format: digital
• 18 Schritte
• 30 Teilnehmer:innen
• ca. 15 min

Ein:e Teilnehmer:in wird zufällig auf eine bestimmte Version der Studie gemappt. Die Versionen unterscheiden sich in der Zuordnung von Problembeschreibung und Suchtechnologie. Somit wird sichergestellt, dass jede:r Teilnehmer:in die Ergebnisse aller Suchtechnologien bewerten muss. Zusätzlich wird durch die Verwendung von Versionen eine ausgewogene Gewichtung zwischen Teilnehmer:innen und Suchtechnologien erzeugt.

Datenerfassung

Eine anonyme, aber eindeutige Erfassung der Teilnehmer:innen und deren Fortschritts ist unerlässlich für das Version-Mapping und die Durchführung der Studie ohne Unterbrechungen. Hierfür wurden folgende Mechanismen verwendet:

• Erstellen eines Teilnehmer:innen-Pseudonyms nach einem vorgegebenen Schema (z. B. ABCDEF89)
• Systematischer Ablauf während der Analyse der Fragestellung des Bewertungs-Kontextes (siehe Abbildung 2)

Abbildung 2: Systematischer Ablauf

Der systematische Ablauf beschreibt in wenigen Schritten alle Ebenen der Teilnehmer:innen-Interaktion. Im ersten Schritt der Studie erhält der/die Teilnehmer:in eine Problembeschreibung. Die Problembeschreibung wird im zweiten Schritt gegen die Fragestellung aus dem Konzept analysiert und abschließend bewertet. Es folgt eine neue Problembeschreibung und der Zyklus wiederholt sich. Der Zyklus endet sobald alle Problembeschreibungen durch den/die Teilnehmer:in bearbeitet wurden.

Anforderungen

In der Vorbereitung der Studie wurde ein systematischer Ablauf vorgestellt. Der Ablauf verbindet die Teilnehmer:innen-Interaktion aus einem Frontend mit den Suchtechnologien aus dem Backend.  Für die Durchführung einer Studie ergeben sich folgende Mindestanforderungen an unser Web Frontend (siehe Abbildung 3).

Abbildung 3: Anforderungen an die Studie

Die Studie sollte aus Sicht der Teilnehmer:innen einfach durchzuführen sein. Ein Ansatz dafür ist, die Teilnehmer:innen schrittweise an die Studie heranzuführen. Im ersten Schritt soll ein Onboarding alle Teilnehmer:innen fachlich abholen und den Sinn und Zweck der Studie erläutern. Teil des Onboardings ist auch eine technische Einweisung, welche alle technischen Fragen zur Studie vorab klärt.

Zum Beispiel.:

• Wie lautet die URL zur Studie?
• Wo finde ich die Zugangsdaten zur Authentifizierung?
• Was geschieht mit meinen persönlichen Daten?

Im zweiten Schritt wird vorbereitend auf die Studie das Studiendesign vorgestellt. Alle Teilnehmer:innen sollten einmal den Ablauf der Studie sehen und verstehen. Als Nächstes folgen der Beginn und das Ende der Studie durch den/die Teilnehmer:in.

Onboarding → Initiale E-Mail an alle Teilnehmer:innen mit technischer Einweisung

Tutorial → Initiale Anzeige im Web Frontend zeigt ein Video-Tutorial

Start/Ende  → Web Frontend leitet den Teilnehmer schrittweise durch die Studie

Die Bewertung ist das zentrale Element der Studie. Wobei die Fragestellung der Zielsetzung durch den/die Teilnehmer:in beantwortet wird. Hierfür wurde ein  Dialog erstellt, der nach jeder Problembeschreibung angezeigt wird. Dieser Dialog beinhaltet zwei Varianten für die Bewertung durch den/die Teilnehmer:in (siehe Abbildung 4).

1. Eins-Fünf Likert-Skala
2. Optionale Freitexteingabe

Abbildung 4: Bewertungs-Dialog

Am Ende steht die Auswertung der Ergebnisse durch das Team, für die Studienteilnehmer:innen ergeben sich keine weiteren Aufgaben. In der Auswertung werden die oben genannten Hypothesen überprüft und veröffentlicht. Siehe hierfür die folgenden Blog-Posts.

Tech-Stack

Frontend:  Flutter, Nginx

Backend:  FastAPI, Elasticsearch, MySQL in Google Cloud

Umgebung: Kubernetes, Docker, inovex-cloud

Die Studie konnte durch den existierenden Technologie-Stack implementiert, deployt und durchgeführt werden (siehe Abbildung 5).

Abbildung 5: Tech-Stack

Flutter

Flutter ist ein Open-Source-Framework von Google für plattformübergreifende Anwendungen aus einer einzigen Codebasis.

Wir setzen Flutter bereits im Android- und iOS-Kontext ein. Neben den genannten Plattformen unterstützt Flutter seit 2021 auch die Plattform Web. Für die Studie wurde Flutter als Frontend-Lösung evaluiert.

Die Studie muss technisch an das gleiche Service-Ticket Backend angebunden werden wie die bereits existierende Mobile App. Daraus ergibt sich die naheliegende Idee, die Mobile App um die Plattform Web zu erweitern.

FastAPI

FastAPI ist ein Backend Framework für hohe Leistung, welches leicht zu erlernen, schnell zu programmieren und produktionsreif ist.

Die Vorteile von FastAPI gegenüber anderen Frameworks sind neben der Performance und der Developer Experience:

• Offene Standards, kein Bedarf, Erweiterungen einzubinden (bspw. Swagger)
• Automatische Serialisierung
• Support für Datenvalidierung
• Support für Dependency Injection

Elasticsearch

Die Elastic Search Platform ist ein Datenspeicher, eine Suchmaschine und eine Analyse-Lösung, mit der Daten aller Art – von Textdaten über numerische Daten und Geodaten bis hin zu strukturierten und unstrukturierten Daten – durchsucht werden können.

Alle Serviceberichte sind in Elasticsearch indiziert. Ein FastAPI-Backend bietet einen RESTful Zugriff auf die API. Diese suchen dann über verschiedene Suchtechnologien die Ergebnisse als Dokumente aus Elasticsearch zurück.

MySQL

MySQL ist ein relationales Datenbankmanagementsystem. Es ist unter Open-Source-Lizenz frei verfügbar. Mithilfe des Datenbankmanagementsystems lassen sich relationale Datenbanken, die die Daten in Tabellen, bestehend aus Zeilen und Spalten, speichern, erstellen, verwalten und betreiben.

Wir verwenden MySQL als Datenspeicher für Service-Berichte aus dem Umfeld von Krohne Messtechnik.

Kubernetes

Kubernetes (K8s) ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen.

Umsetzung

Aus den Anforderungen wurde abgeleitet, dass ein Web Frontend die passende Lösung als Format für die Studie ist. Durch Verwendung von Flutter als Cross-Platform Framework im App-Kontext waren wir in der Lage, Synergien in der Umsetzung für ein Web Frontend zu nutzen. Als Basis existierte bereits eine Flutter App, die alle nötigen Endpunkte verwendet. Die Herausforderung bestand darin, die Struktur an die zusätzlichen Anforderungen anzupassen. Die bestehende Architektur unter Verwendung von MobX für das State-Management blieb von den Änderungen unberührt. Durch die Verwendung einer einzigen Codebase ist es möglich, bereits implementierte Services plattformübergreifend zu nutzen. Die UI des Web Frontends wurde durch den oben genannten Ablauf vorgegeben. Das Web Frontend führt die Teilnehmer:innen durch die einzelnen Schritte der Studie und erfasst dabei die Bewertung der Teilnehmer:innen (siehe Abbildung 6).

Abbildung 6: Studienverlauf für eine:n Teilnehmer:in

Zu Beginn muss sich jede:r Teilnehmer:in im Web Frontend anmelden. Die Zugangsdaten hat jede:r Teilnehmer:in bereits im Onboarding erhalten. Es folgt eine Registrierung, bei der jede:r Teilnehmer:in ein individuelles  Pseudonym festlegen muss (siehe Absatz: Datenerfassung). Folgend kann der/die Teilnehmer:in die Studie durchlaufen. Es wurde vorab festgelegt, dass für jede:n Teilnehmer:in 18 Problembeschreibungen bereitgestellt werden. Zu jeder Problemstellung erhält ein:e Teilnehmer:in eine ungewisse Anzahl von Service-Berichten. Die Problembeschreibungen und Service-Berichte werden nacheinander durch den/die Teilnehmer:in analysiert und bewertet. Dieser sich wiederholende Prozess endet, nachdem ein:e Teilnehmer:in die Fragestellung für alle 18 Problemstellungen bewertet hat.

Zusammenfassung

Nach und während der Implementierung des Frontends haben wir die Anforderungen gegen die Umsetzung evaluiert. Dabei sollte immer die Studie selbst im Vordergrund stehen. Erkenntnisse sollen schnell in die nächste Stufe einfließen und die Qualität der Studie stets verbessern. Es folgen die abschließenden Erkenntnisse aus der Vorbereitung und Umsetzung der Studie.

Hat das Web Frontend alle Anforderungen der Studie erfüllt?

Alle Anforderungen konnten durch neue Prozesse und den gegebenen Tech-Stack umgesetzt werden. Wichtig zu erwähnen ist, dass sich die Definition eines Use Cases innerhalb der Implementierung grundlegend geändert hat. Die Plattform wurde ursprünglich nicht im Rahmen eines Use Case betrachtet, sondern als eine Funktionalität. Die Struktur der Implementierung wurde angepasst, sodass die Plattform selbst zum Use Case wurde (siehe Abbildung 7).

Abbildung 7: Struktur der Implementierung

Welchen Einfluss hatte das Hinzufügen von Suchtechnologien auf das Web Frontend?

Das Web Frontend anzupassen, hat keinen Einfluss auf die Anzahl der verwendeten Suchtechnologien. Die Auswahl von Version zu Teilnehmer:in und die verwendeten Suchtechnologien hatten keine Auswirkung auf den Studienverlauf.

Was sind die Erkenntnisse bei der Vorbereitung und Durchführung der Studie?

1. Recherche zur Durchführung einer effektiven Studie ist unerlässlich.
2. Bewertungsgrundlage muss sorgfältig eingegrenzt werden.
3. Hilfestellung für die Teilnehmer:innen sollten essentieller Bestandteil des Onboarding-Prozesses sein.
4. Der Zeithorizont für die Studie muss mit dem/der Teilnehmer:in vorab abgestimmt sein
5. Agile Analyse von KPIs und Messpunkten ist hilfreich für die Steigerung der Qualität einer Studie.
6. Studienkonzept und -design sollten zwischen den Stufen immer wieder hinterfragt werden.
7. Der gewählte Tech-Stack hat sich für dieses Projekt und für unser Team bewährt.

Wurde die Studie erfolgreich durchgeführt?

Die Studie startete im Sommer 2022 mit der ersten Stufe der Pilotstudie und soll im Frühjahr 2023 enden.

Weiterführende Links:

1. Service-Meister bei inovex
2. Inhaltsextraktion und logische Strukturerkennung in PDF-Dokumenten
3. Automatisch generierte Synonyme für bessere Suchergebnisse
4. Finetuning a ResNet for a Content-Based Image Retrieval Task
5. Building a Contextual Assistant with Rasa and Flutter