A Benchmarking Framework for Model Datasets

Dieser Beitrag stellt einen Benchmarking-Framework und eine zugehörige Plattform vor, um Datensätze von Softwaremodellen systematisch auf Qualität, Repräsentativität und Eignung für spezifische Aufgaben zu bewerten und so die Vergleichbarkeit sowie Reproduzierbarkeit in der modellgetriebenen Entwicklung zu verbessern.

Das Wesentliche

Stellen Sie sich vor, Sie sind ein Koch, der ein neues, fantastisches Rezept für einen AI-gestützten Keks backen möchte. Aber bevor Sie den Ofen anstellen, müssen Sie Ihre Zutaten überprüfen.

Das Problem, das diese Wissenschaftler beschreiben, ist folgendes: Viele Forscher in der Welt der Softwareentwicklung (genannt "Model-Driven Engineering") versuchen, künstliche Intelligenz (KI) zu trainieren, damit sie Software-Modelle verstehen, verbessern oder sogar selbst erstellen kann. Dafür brauchen sie riesige Mengen an "Zutaten" – also Sammlungen von Software-Modellen.

Aber oft passiert Folgendes: Die Forscher sammeln diese Zutaten einfach so, wie sie sie finden. Manche sind frisch und perfekt, andere sind alt, verstaubt, doppelt vorhanden oder gar kaputt. Wenn man mit schlechten Zutaten kocht, schmeckt das Ergebnis (die KI) auch schlecht. Und weil jeder Forscher seine Zutaten anders gemischt hat, kann man die Ergebnisse nicht vergleichen. War der Kuchen schlecht, weil das Rezept (die KI) schlecht war, oder weil die Eier verdorben waren (die Daten)?

Die Lösung: Ein "Qualitäts-Check" für Daten

Die Autoren dieses Papiers haben eine Art "Super-Waage und Qualitäts-Prüfstand" entwickelt. Sie nennen es ein "Benchmarking-Framework".

Hier ist eine einfache Analogie, wie das funktioniert:

1. Der Markt (Die Datensätze)

Stellen Sie sich vor, die verschiedenen Datensätze sind wie verschiedene Obst- und Gemüsemärkte.

• Markt A (EA ModelSet): Hier gibt es viele verschiedene Früchte, aber einige sind nur Skizzen auf einem Zettel, andere sind echte Äpfel. Manche sind auf Spanisch beschriftet, andere auf Deutsch.
• Markt B (ModelSet): Hier gibt es riesige Kisten mit sehr kleinen, technischen Samen (Metamodelle). Alles ist sehr einheitlich, aber vielleicht zu technisch für einen normalen Kuchen.
• Markt C (AtlanMod Zoo): Ein kleiner, sehr sauberer Laden, in dem nur die besten, vom Gärtner sorgfältig ausgesuchten Samen liegen.

Bisher hat niemand wirklich genau geschaut, was genau in diesen Kisten ist. Die Forscher haben einfach hineingegriffen und gehofft, dass es passt.

2. Die Super-Waage (Das Framework)

Die Autoren haben eine Maschine gebaut, die diese Kisten durchläuft und sie nicht nur wiegt, sondern sie auch zerlegt und analysiert.

• Der Scanner (Parsing): Zuerst schaut die Maschine, ob die Kisten überhaupt geöffnet werden können. Sind die Deckel festgeklebt? Sind die Früchte verrottet? Die Maschine zählt: "90% der Äpfel sind gut, 5% haben einen kleinen Fleck, 5% sind total matschig."
• Der Namens-Checker (Lexical Quality): Sie liest die Etiketten. Sind die Früchte gut beschriftet? "Apfel" oder nur "Frucht 1"? Sind die Namen auf Englisch oder in 20 verschiedenen Sprachen gemischt? Das ist wichtig, wenn die KI lernen soll, Texte zu verstehen.
• Der Bauplan-Checker (Construct Coverage): Sie prüft, ob alle möglichen Zutaten da sind. Enthält die Kiste nur Äpfel, oder gibt es auch Birnen, Trauben und Bananen? Wenn eine KI lernen soll, alles zu erkennen, aber im Datensatz nur Äpfel sind, wird sie keine Bananen erkennen können.
• Der Struktur-Checker (Size & Shape): Wie groß sind die Früchte? Sind sie alle gleich groß, oder gibt es winzige Beeren und riesige Kürbisse? Wie sind sie verpackt? Liegen sie lose herum oder sind sie in einem perfekten Korb?

3. Der Bericht (Das Ergebnis)

Am Ende gibt die Maschine keinen einfachen "Gut/Schlecht"-Stempel ab. Stattdessen liefert sie einen detaillierten Rezept-Check.

• "Achtung: Dieser Datensatz hat viele verrottete Äpfel (Parsing-Fehler)."
• "Achtung: Hier sind die Namen auf 25 Sprachen gemischt – wenn Sie eine KI nur für Deutsch trainieren wollen, müssen Sie erst sortieren."
• "Gut: Hier sind alle Zutaten vorhanden, aber sie sind sehr klein."

Warum ist das so wichtig?

Stellen Sie sich vor, zwei Köche backen Kekse.

• Koch 1 sagt: "Meine Kekse waren super!"
• Koch 2 sagt: "Meine waren schlecht."

Ohne den Qualitäts-Check wissen wir nicht, ob Koch 1 ein besseres Rezept hatte oder ob er einfach bessere Eier hatte. Mit dem neuen Framework von Glaser, Burgueño und Bork können wir sagen: "Koch 1 hat hochwertige Eier verwendet, Koch 2 hatte verdorbene. Deshalb war Koch 1 besser, nicht sein Rezept."

Zusammengefasst:
Die Autoren haben eine Werkzeugkiste gebaut, mit der Forscher ihre Daten-Sammlungen genau untersuchen können, bevor sie ihre KI-Experimente starten. Sie machen die "Qualität der Zutaten" sichtbar, messbar und vergleichbar. Das hilft dabei, dass die Ergebnisse von KI-Forschern in der Softwarewelt endlich fair verglichen werden können und die KI am Ende wirklich gute Kekse (Software-Modelle) backt.

Das Tool ist wie ein Übersetzer und Prüfer in einem, der chaotische Daten-Sammlungen in eine klare, verständliche Sprache übersetzt, damit jeder weiß, womit er eigentlich arbeitet.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papiers „A Benchmarking Framework for Model Datasets" auf Deutsch:

1. Problemstellung

Im Bereich des modellgetriebenen Engineerings (MDE) und der Integration von Künstlicher Intelligenz (KI/LLMs) werden zunehmend Datensätze von Softwaremodellen (z. B. UML, ArchiMate, Ecore) zur Schulung und Evaluation von maschinellen Lernverfahren verwendet.
Das zentrale Problem besteht darin, dass diese Datensätze häufig ad hoc erstellt oder gesammelt werden, ohne dass ihre Qualität, Repräsentativität oder Eignung für spezifische Aufgaben systematisch bewertet wird. Dies führt zu:

• Fehlender Vergleichbarkeit von Forschungsergebnissen zwischen verschiedenen Studien.
• Undurchsichtiger Datenqualität (z. B. Vorhandensein von Duplikaten, „Dummy"-Modellen oder fehlerhaften Serialisierungen).
• Schlechter Reproduzierbarkeit und potenziellen Verzerrungen (Bias) in den Ergebnissen.
• Mangelnder Transparenz darüber, ob ein Datensatz für eine bestimmte Aufgabe (z. B. Klassifizierung, Vervollständigung) geeignet ist.

Es fehlt ein standardisierter Rahmen, um Datensätze selbst als „First-Class-Artefakte" zu bewerten, anstatt nur die darauf trainierten Modelle zu evaluieren.

2. Methodik und Framework

Die Autoren schlagen ein Benchmarking-Framework für Modelldatensätze vor, das den Datensatz selbst systematisch misst. Die Methodik basiert auf folgenden Säulen:

A. Metamodell für das Benchmarking

Ein sprachunabhängiges Metamodell definiert die Kernentitäten:

• Dataset: Die zentrale Einheit, die mit Artefakten (Modell-Dateien und Zusatzartefakte) verknüpft ist.
• Intermediate Representation (IR): Modelle werden in einen gemeinsamen, typisierten Graphen transformiert. Dies ermöglicht sprachunabhängige Analysen, da die spezifischen Serialisierungsformate (XMI, JSON, XML etc.) in eine einheitliche Struktur (Knoten und Kanten) überführt werden.
• Qualitätsdimensionen & Metriken: Das Framework definiert messbare Dimensionen, die in konkrete Maße (Measures) und Metriken unterteilt sind.
• Benchmark-Run & Profile: Ein Profil steuert die Konfiguration (Parser, Maße, Parameter) und gewährleistet die Reproduzierbarkeit.

B. Die vier Qualitätsdimensionen

Das Framework bewertet Datensätze anhand vier initialer Dimensionen:

1. Parsing (D1): Technische Robustheit. Wie viele Modelle lassen sich erfolgreich parsen? Gibt es Warnungen, übersprungene Elemente oder Fehler?
2. Lexikalische Qualität (D2): Analyse von Bezeichnungen (Labels). Untersucht werden Präsenz, Länge, Vielfalt (Diversity) und die verwendete natürliche Sprache der Elementnamen.
3. Konstrukt-Abdeckung (D3): Welche Elemente des zugrunde liegenden Metamodells (z. B. Ecore oder ArchiMate) kommen im Datensatz vor? Wie gleichmäßig sind sie verteilt?
4. Größe und Struktur (D4): Statistische Eigenschaften des Graphen (Anzahl Knoten/Kanten, Grad-Verteilung, Konnektivität, Tiefe der Hierarchie).

C. Die Plattform-Architektur

Die Implementierung ist als Pipeline mit vier Stufen konzipiert, die auf dem lokalen Dateisystem basiert (keine Datenbank, für einfache Portabilität):

1. Scan: Identifizierung von Kandidaten-Dateien, Filterung und Hash-basierte Duplikaterkennung.
2. Parse: Transformation der Modelle in die IR mittels pluggbarer Parser (unterstützt aktuell ArchiMate und Ecore). Protokollierung von Parsing-Ergebnissen (Erfolg/Teilweise/Fehler).
3. Measure: Berechnung der Metriken auf Modell- und Dataset-Ebene basierend auf der IR.
4. Report: Generierung von visualisierbaren Berichten (JSON, Web-UI) mit Histogrammen, Tabellen und Scores.

Die Plattform bietet sowohl eine CLI (für Batch-Verarbeitung) als auch eine Web-Oberfläche (für interaktive Exploration).

3. Schlüsselergebnisse (Evaluation)

Das Framework wurde auf drei repräsentativen öffentlichen Datensätzen getestet:

1. EA ModelSet: ArchiMate-Modelle (mined, heterogen).
2. ModelSet: Große Sammlung von UML/Ecore-Modellen (mined von GitHub).
3. AtlanMod Zoo: Kuratierte Sammlung von Ecore-Metamodellen.

Wichtige Erkenntnisse:

• Parsing: Alle Datensätze waren zu über 90 % erfolgreich parsbar. Allerdings zeigten die „mined"-Datensätze (EA ModelSet, ModelSet) mehr Warnungen (z. B. ungelöste Referenzen, inkonsistente Tool-Namenskonventionen) als die kuratierten Datensätze.
• Lexikalische Qualität: Es gab signifikante Unterschiede im Namensstil. Ecore-Datensätze nutzten kurze, technische Bezeichner (meist ein Wort), während ArchiMate-Modelle oft längere, phrasenartige Bezeichnungen enthielten. Die EA ModelSet-Daten waren zudem stark mehrsprachig, während die anderen überwiegend englisch waren.
• Konstrukt-Abdeckung: Während die Datensätze die meisten Konstrukt-Typen abdeckten, variierte die Nutzung stark. Ecore-Datensätze zeigten eine breitere Nutzung der Metamodell-Features pro Modell als ArchiMate-Modelle, die oft auf spezifische Sichtweisen beschränkt waren.
• Strukturelle Eigenschaften: ArchiMate-Modelle tendierten zu flachen, fragmentierten Graphen mit vielen isolierten Knoten (typisch für Enterprise-Architektur-Diagramme). Ecore-Modelle bildeten dichte, stark hierarchische und fast vollständig verbundene Graphen ab.

4. Hauptbeiträge

1. Konzeptueller Rahmen: Einführung eines Metamodells, das das Benchmarking von Modelldatensätzen als eigenständige Aufgabe definiert, unabhängig von der Bewertung der darauf trainierten KI-Modelle.
2. Technische Implementierung: Entwicklung einer offenen Plattform, die Modelle in eine sprachunabhängige Graphen-IR transformiert und quantitative Metriken berechnet.
3. Katalog von Metriken: Definition eines initialen Katalogs von Qualitätsdimensionen (Parsing, Lexikalisch, Konstrukt, Struktur), die als Standard für die Beschreibung von Datensätzen dienen können.
4. Empirische Validierung: Demonstration, dass das Framework in der Lage ist, reale, heterogene Datensätze zu analysieren und actionable Insights (z. B. zur Notwendigkeit von Sprachfilterung oder Datenbereinigung) zu liefern.

5. Bedeutung und Ausblick

Das Paper adressiert einen kritischen Engpass in der MDE- und KI-Forschung: Die mangelnde Vergleichbarkeit und Transparenz von Trainingsdaten.

• Für die Forschung: Es ermöglicht die Standardisierung von Berichten über Datensätze in wissenschaftlichen Publikationen, was die Reproduzierbarkeit und den Vergleich von Studien erheblich verbessert.
• Für die Praxis: Forscher und Entwickler können vor dem Einsatz eines Datensatzes dessen Eignung für spezifische Aufgaben (z. B. NLP vs. Graph-basierte Analyse) objektiv bewerten.
• Zukünftige Arbeit: Die Autoren planen die Erweiterung des Metamodells um weitere Sprachen (BPMN, Petri Nets), die Integration von Duplikatserkennung und die Untersuchung der Korrelation zwischen diesen Metriken und der Leistung von ML-Modellen.

Zusammenfassend stellt das vorgestellte Framework einen essenziellen Schritt hin zu einer wissenschaftlich fundierten, datenzentrierten Modellierung in der Ära der KI dar.