OODEval: Evaluating Large Language Models on Object-Oriented Design

Die Studie „OODEval" führt eine umfassende empirische Untersuchung von 29 großen Sprachmodellen in Bezug auf objektorientiertes Design durch, wobei sie einen neuen Benchmark und eine einheitliche Metrik einführt, um festzustellen, dass die Modelle zwar syntaktisch präzise sind, aber erhebliche semantische Mängel aufweisen und trotz starker Leistungen einzelner Modelle im Durchschnitt noch unter der Qualität menschlicher Designer bleiben.

Das Wesentliche

Stellen Sie sich vor, Sie haben einen sehr talentierten, aber noch jungen Assistenten, den Sie „Künstliche Intelligenz" nennen. Dieser Assistent ist fantastisch darin, Code zu schreiben, wie ein Koch, der Rezepte perfekt nachliest. Aber die Forscher aus China wollten wissen: Kann dieser Assistent auch das Rezept selbst erfinden?

Genau darum geht es in dieser Studie namens OODEval.

Hier ist die einfache Erklärung, was die Forscher getan haben und was sie herausgefunden haben, mit ein paar bildhaften Vergleichen:

1. Das Problem: Der fehlende Prüfstein

Bisher haben wir die KI nur auf kleine Aufgaben getestet, wie „Schreib mir eine Funktion, die 2 plus 2 berechnet". Das ist wie zu prüfen, ob ein Koch ein Ei kochen kann. Aber Software-Entwicklung ist mehr als das. Es geht darum, die große Struktur zu planen: Welche Zimmer braucht ein Haus? Wie hängen sie zusammen? Wer macht was? Das nennt man „Objektorientiertes Design" (OOD).

Das Problem war: Es gab keinen standardisierten Test, um zu sehen, ob die KI wirklich gut plant. Es fehlte ein Maßstab, wie ein Lineal für Architekten.

2. Die Lösung: Ein neuer Baukasten (OODEval)

Die Forscher haben sich etwas Cleveres ausgedacht:

• Der Test (OODEval): Sie haben 50 verschiedene Bauprojekte erstellt, von einfachen Hütten bis zu riesigen Wolkenkratzern. Jedes Projekt hatte eine Beschreibung (z. B. „Wir brauchen ein System für eine Bibliothek") und eine perfekte Lösung (den Bauplan).
• Der menschliche Vergleich (OODEval-Human): Um zu wissen, wie gut die KI wirklich ist, haben sie nicht nur die KI getestet, sondern auch 940 Studenten (die angehenden Architekten). Die Dozenten haben deren Pläne bewertet. So haben sie eine „menschliche Durchschnittsleistung" als Maßstab.
• Der neue Maßstab (CLUE): Früher hat man Pläne verglichen, indem man geschaut hat, ob die Wörter übereinstimmen. Das ist wie zu prüfen, ob zwei Bilder die gleiche Farbe haben, ohne auf die Form zu achten. Die Forscher haben einen neuen, intelligenten Scanner namens CLUE entwickelt. Dieser Scanner schaut nicht nur auf die Wörter, sondern versteht die Bedeutung und die Struktur. Er erkennt: „Ah, hier fehlt eine Treppe zwischen dem ersten und zweiten Stock", auch wenn die KI das Wort „Treppe" anders geschrieben hat.

3. Das Experiment: KI vs. Studenten

Die Forscher haben 29 verschiedene KI-Modelle (von kleinen bis zu riesigen) an diesen Tests teilnehmen lassen.

Was sie herausfanden:

• Die KI ist ein guter Kopierer, aber ein schlechter Planer: Die KI kann den Code (die Sprache) perfekt schreiben. Sie vergisst fast nie, wo ein Komma hin muss (syntaktische Korrektheit). Aber wenn es darum geht, was gebaut werden soll (die Semantik), macht sie Fehler.
  • Vergleich: Die KI kann einen Satz perfekt auf Deutsch schreiben, aber wenn man sie bittet, einen sinnvollen Roman zu planen, verliert sie den Faden.
• Wo sie hakt: Die KI ist gut darin, die Namen der Räume zu erfinden (Klassen), aber sie scheitert oft daran, zu sagen, was in diesen Räumen passiert (Methoden) und wie die Räume miteinander verbunden sind (Beziehungen).
• Der Vergleich mit Menschen:
  • Der durchschnittliche KI-Assistent ist noch deutlich schlechter als der durchschnittliche Student.
  • Aber die besten KI-Assistenten (wie Qwen3-Coder-30B) kommen fast an das Niveau des durchschnittlichen Studenten heran. Sie sind also schon sehr gut, aber noch nicht so gut wie die besten menschlichen Architekten.
• Größe zählt (aber nicht alles): Größere Modelle sind besser. Modelle, die speziell auf Programmieren trainiert wurden, sind besser als allgemeine Modelle. Und Modelle, die „Anweisungen" bekommen haben, wie sie sich verhalten sollen, schneiden viel besser ab.
  • Überraschung: Ein kleiner, lokaler KI-Modell (Gemma3-4B) war besser als ein riesiger, kostenpflichtiger Online-Dienst (GPT-4o Mini). Das zeigt: Man braucht nicht immer den größten Motor, um gut zu fahren.

4. Die häufigsten Fehler

Wenn die KI scheitert, tut sie es auf typische Weise:

• Sie vergisst ganze Räume (Klassen fehlen).
• Sie vergisst, wie die Räume verbunden sind (Türen fehlen).
• Sie halluziniert Dinge, die gar nicht in der Beschreibung standen.

5. Was bedeutet das für uns?

• Für die Technik: Wir müssen die KIs besser darin trainieren, komplexe Zusammenhänge zu verstehen, nicht nur Code zu tippen.
• Für die Schule: Da die KI jetzt schon so gut ist wie ein durchschnittlicher Student, können Schüler versuchen, Hausaufgaben mit KI zu machen. Lehrer müssen neue Wege finden, um zu prüfen, ob die Schüler wirklich verstehen, was sie tun (z. B. durch mündliche Prüfungen).
• Für die Zukunft: Die KI ist ein mächtiges Werkzeug, das uns helfen kann, Software zu entwerfen. Aber sie ist noch kein Ersatz für einen erfahrenen Architekten. Sie ist eher wie ein sehr schneller, aber manchmal etwas zerstreuter Praktikant, den man genau überwachen muss.

Zusammenfassend: Die Studie hat den ersten echten „Führerschein-Test" für KIs im Software-Design entwickelt. Das Ergebnis: Die KIs haben den Führerschein bestanden, aber sie brauchen noch etwas Übung, bevor sie allein komplexe Hochhäuser planen dürfen.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „OODEval: Evaluating Large Language Models on Object-Oriented Design" auf Deutsch:

1. Problemstellung

Trotz der rasanten Fortschritte von Large Language Models (LLMs) in der Softwareentwicklung konzentrieren sich bestehende Evaluierungen und Benchmarks fast ausschließlich auf Code-Level-Aufgaben (z. B. Code-Generierung, Fehlerbehebung). Die Fähigkeiten von LLMs im Bereich des Software-Designs, insbesondere bei der Objektorientierten Design (OOD)-Aufgabe (Übersetzung natürlichsprachlicher Anforderungen in UML-Klassendiagramme), wurden bisher kaum systematisch untersucht.

Es bestehen zwei Hauptlücken:

• Fehlende Benchmarks: Es gibt keine standardisierten, öffentlichen Datensätze für OOD-Aufgaben, die verschiedene Schwierigkeitsgrade abdecken und maschinell auswertbar sind.
• Fehlende Metriken: Herkömmliche Evaluierungsmetriken (wie BLEU oder reine Embedding-basierte Scores) erfassen weder die strukturelle Komplexität noch die semantische Korrektheit von Klassendiagrammen adäquat.

2. Methodik und Neuerungen

Das Paper stellt einen umfassenden Evaluierungsrahmen vor, der aus drei Hauptkomponenten besteht:

A. OODEval Benchmark

Ein manuell erstellter Datensatz mit 50 OOD-Aufgaben, die von Anforderungen bis zum Klassendiagramm reichen.

• Struktur: Die Aufgaben sind in drei Schwierigkeitsstufen unterteilt (einfach, moderat, schwer), basierend auf Metriken wie Anzahl der Klassen, Attribute, Methoden, Beziehungen und der Lesbarkeit der Anforderungen (Flesch-Kincaid Score).
• Format: Die Daten liegen als JSON (für automatische Verarbeitung) und PlantUML-Code (für Visualisierung) vor, um eine automatisierte Evaluierung zu ermöglichen.
• Vielfalt: Die Aufgaben decken 10 Domänen ab (z. B. öffentliche Dienste, Finanzen, Gesundheit).

B. OODEval-Human Dataset

Der erste menschlich bewertete OOD-Datensatz.

• Inhalt: 940 Lösungen von Studierenden (vier verschiedene Aufgaben), bewertet von Dozenten.
• Zweck: Dient als Ground Truth, um die Leistung von LLMs mit der menschlicher Studenten zu vergleichen und die Korrelation der neuen automatischen Metriken mit menschlichen Bewertungen zu validieren.
• Aufbereitung: Da die Originaldaten Bilder waren, wurden sie mittels Multimodaler LLMs (GPT-4o) in PlantUML konvertiert und anschließend manuell durch Experten auf Konsistenz geprüft.

C. CLUE Metrik (Class Likeness Unified Evaluation)

Eine neue Metrik-Suite zur automatisierten Bewertung der Korrektheit von Klassendiagrammen.

• Prinzip: CLUE vergleicht Kandidaten-Designs mit Referenz-Designs unter Berücksichtigung von Struktur und Semantik.
• Komponenten: Sie besteht aus fünf Metriken:
  1. clue: Gesamtscore.
  2. clue-class: Ähnlichkeit der Klassen.
  3. clue-attribute: Ähnlichkeit der Attribute.
  4. clue-method: Ähnlichkeit der Methoden.
  5. clue-relation: Ähnlichkeit der Beziehungen.
• Technik: CLUE nutzt CodeBERT für semantische Embeddings (zur Handhabung synonymischer Namen) und den Hungarian Algorithmus für das optimale Matching von Elementen (Klassen, Methoden, Beziehungen), um semantisch äquivalente, aber lexikalisch unterschiedliche Elemente zu erkennen.
• Validierung: Die Metrik zeigt eine starke positive Korrelation (Pearson-Koeffizient ~0,59) mit menschlichen Bewertungen, was sie deutlich überlegener als herkömmliche Metriken (BLEU, CodeBERTScore, NINHS) macht.

D. Empirische Studie

Die Autoren evaluierten 29 verschiedene LLMs (Open-Source, Closed-Source, Code-spezialisiert, General-Purpose, mit und ohne Reasoning-Fähigkeiten) auf dem OODEval-Benchmark.

3. Wichtige Ergebnisse

RQ1: Gesamtkorrektheit

• Syntax vs. Semantik: LLMs erzielen eine hohe syntaktische Korrektheit (Pass@1 > 80%, viele Modelle bei 100%), zeigen aber signifikante Defizite in der semantischen Korrektheit (CLUE-Scores sind oft >10% niedriger).
• Schwächen: Die Generierung von Methoden und Beziehungen (Relationships) ist die größte Schwäche, besonders bei komplexen Aufgaben. Die Generierung von Klassenamen und Attributen gelingt besser.
• Top-Modelle: Qwen3-Coder-30B erreicht die besten Gesamtergebnisse. Lokale Open-Source-Modelle (z. B. Gemma3-IT Serie, StarCoder2-15B) konkurrieren erfolgreich mit geschlossenen Cloud-Modellen wie GPT-4o-mini.

RQ2: Vergleich mit Menschen

• Durchschnitt: Die durchschnittliche Leistung von LLMs liegt deutlich unter dem Durchschnitt menschlicher Studenten.
• Spitzenleistung: Die besten LLMs (z. B. Qwen3-Coder-30B) nähern sich dem Durchschnitt menschlicher Studenten an, bleiben aber weit hinter der Leistung der besten menschlichen Studenten zurück (die fast 100% erreichen).

RQ3: Einflussfaktoren des Modells

• Parameter-Skala: Größere Modelle performen tendenziell besser.
• Code-Spezialisierung: Code-spezifische Modelle (z. B. CodeLlama, Qwen-Coder) übertreffen deutlich allgemeine Modelle.
• Instruction Tuning: Modelle mit Instruction-Tuning performen konsistent besser als ihre Basismodelle.
• Reasoning: Reasoning-fähige Modelle (wie DeepSeek-R1) zeigten in diesem spezifischen Szenario keinen klaren Vorteil gegenüber nicht-reasoning-Modellen.

RQ4: Einfluss der Aufgabenmerkmale

• Die Leistung sinkt mit steigender Anzahl von Klassen, Methoden und Beziehungen sowie mit steigendem Anteil an Generalisierungsbeziehungen (Vererbung).
• Geringere Lesbarkeit der Anforderungen (niedriger Flesch-Kincaid Score) verschlechtert die Ergebnisse.
• Die Anzahl der Attribute hat keinen signifikanten negativen Einfluss.

RQ5: Fehleranalyse

• Häufigste Fehler: Semantische Verzerrungen (86% der Fälle), gefolgt von Syntaxfehlern und Instruktionsfehlern.
• Spezifische Fehler: Fehlende Klassen, falsche oder fehlende Beziehungen, Auslassung von Methoden und Halluzinationen (Hinzufügen nicht geforderter Elemente).
• Robustheit: Modelle wie DeepSeek, GPT-Serie und Gemma3-IT Varianten zeigen eine sehr geringe Vielfalt an Fehlertypen und sind robuster.

4. Bedeutung und Implikationen

• Für die Forschung: Das Paper etabliert einen neuen Standard für die Evaluierung von LLMs im Software-Design. Es zeigt, dass Syntax allein nicht ausreicht und dass semantische Strukturierung (Methoden/Beziehungen) die größte Hürde darstellt.
• Für die Praxis:
  • Modellauswahl: Für lokale Bereitstellungen mit begrenzten Ressourcen wird Gemma3-4B-IT empfohlen (gutes Preis-Leistungs-Verhältnis, geringe Fehlerdiversität). Für maximale Leistung wird Qwen3-Coder-30B empfohlen. Für Cloud-Lösungen ist DeepSeek-R1 eine kosteneffiziente Alternative zu GPT-4.
  • Weiterentwicklung: Modelle sollten gezielt auf das Verständnis von Operationen und Beziehungen in Anforderungen trainiert werden.
• Für die Ausbildung: Da Spitzen-LLMs das Niveau durchschnittlicher Studenten erreichen, müssen Hochschulen neue Strategien entwickeln, um akademisches Fehlverhalten (AI-gestützte Cheating) zu verhindern (z. B. durch mündliche Prüfungen oder prozessorientierte Bewertungen). Gleichzeitig können KI-Tools als Lernwerkzeuge genutzt werden, wenn der Fokus auf kritischem Denken liegt.

Fazit

OODEval füllt eine kritische Lücke in der Software-Engineering-Forschung, indem es die ersten umfassenden Benchmarks und Metriken für die Bewertung von LLMs im objektorientierten Design bereitstellt. Die Studie zeigt, dass LLMs zwar syntaktisch präzise sind, aber bei der semantischen Tiefe des Designs (insbesondere Methoden und Beziehungen) noch erhebliche Fortschritte benötigen, um das Niveau menschlicher Experten zu erreichen.