💻 computer science

Guidelines for Empirical Studies in Software Engineering involving Large Language Models

Dieses Paper stellt eine von 22 Forschern erarbeitete Taxonomie von sieben Studientypen sowie acht Richtlinien vor, die Software-Ingenieuren helfen, empirische Studien mit Large Language Models durch transparente Berichterstattung, Validierung und Reproduzierbarkeit zu gestalten.

Ursprüngliche Autoren: Sebastian Baltes, Florian Angermeir, Chetan Arora, Marvin Muñoz Barón, Chunyang Chen, Lukas Böhme, Fabio Calefato, Neil Ernst, Davide Falessi, Brian Fitzgerald, Davide Fucci, Junda He, Christoph Treud

Veröffentlicht 2026-03-04

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Sebastian Baltes, Florian Angermeir, Chetan Arora, Marvin Muñoz Barón, Chunyang Chen, Lukas Böhme, Fabio Calefato, Neil Ernst, Davide Falessi, Brian Fitzgerald, Davide Fucci, Junda He, Christoph Treude, Marcos Kalinowski, Stefano Lambiase, Daniel Russo, Mircea Lungu, Cristina Martinez Montes, Lutz Prechelt, Paul Ralph, Rijnard van Tonder, Stefan Wagner

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stell dir vor, Software-Engineering-Forscher sind wie Architekten, die neue Gebäude entwerfen, und die Künstliche Intelligenz (KI), speziell die großen Sprachmodelle (LLMs), ist ihr neuer, super-schneller, aber etwas chaotischer Baumeister.

Dieses Papier ist im Grunde eine neue Bauvorschrift für alle Architekten, die mit diesem neuen Baumeister arbeiten.

Das Problem: Der chaotische Baumeister

Früher haben Forscher ihre Experimente mit menschlichen Arbeitern oder alten, statischen Maschinen durchgeführt. Wenn man den Plan zweimal abhakte, kam das gleiche Ergebnis heraus.

Der neue Baumeister (die KI) ist anders:

Er ist nicht deterministisch: Wenn du ihm heute sagst „Baue eine Tür", baut er vielleicht eine Holztür. Wenn du es morgen sagst, baut er eine Glastür. Selbst mit dem exakt gleichen Befehl kann er jedes Mal etwas anderes bauen.
Er vergisst seine Vergangenheit: Die KI-Modelle werden ständig aktualisiert. Ein Modell, das heute „GPT-4" heißt, ist morgen vielleicht schon eine andere Version, ohne dass man es merkt.
Niemand kennt sein Gehirn: Wir wissen oft nicht genau, was er gelernt hat oder wie er denkt.

Das führt zu einem riesigen Problem: Wie kann ein anderer Forscher das Experiment wiederholen und prüfen, ob das Ergebnis stimmt, wenn der Baumeister jedes Mal anders arbeitet und niemand weiß, welche Version genau benutzt wurde?

Die Lösung: Ein neuer Bauplan (Die Richtlinien)

Ein Team aus 22 Experten hat sich zusammengesetzt und einen Leitfaden erstellt, damit die Forschung wieder seriös und überprüfbar bleibt. Sie haben dafür erst einmal alle möglichen Szenarien sortiert (eine „Taxonomie"), wie die KI eingesetzt wird:

Der KI als Assistent: Die KI hilft beim Sortieren von Daten oder Bewerten von Code (wie ein digitaler Gehilfe).
Der KI als Richter: Die KI bewertet, ob Software gut ist (wie ein digitaler Gutachter).
Der KI als Schauspieler: Die KI spielt menschliche Nutzer vor, um Tests durchzuführen (wie ein digitaler Statist).
Der KI als Werkzeug: Forscher bauen neue Programme, die die KI enthalten.

Für all diese Szenarien gibt es nun 8 goldene Regeln, die Forscher befolgen müssen. Hier sind sie in einfacher Sprache:

Sei ehrlich (Die „Wer hat was gemacht?"-Regel):
- Metapher: Wenn du ein Gericht kochst, musst du auf dem Teller schreiben, welche Zutaten du benutzt hast.
- Regel: Du musst im Papier klar sagen: „Ich habe KI benutzt, um X zu tun." Nicht verstecken!
Nenne die genaue Version (Die „Rezept-Regel"):
- Metapher: „Mehl" reicht nicht. Du musst sagen: „Mehl Type 405, Marke X, vom 12. Januar."
- Regel: Nenne das exakte Modell, die Version, das Datum und alle Einstellungen (wie die „Temperatur" der KI). Ohne das kann niemand dein Experiment nachkochen.
Zeige die ganze Maschine (Die „Motorhaube"-Regel):
- Metapher: Es reicht nicht zu sagen „Ich habe einen Motor benutzt". Zeige, wie der Motor mit dem Getriebe und den Rädern verbunden ist.
- Regel: Beschreibe nicht nur die KI, sondern wie sie in dein Programm eingebaut ist. Welche Daten fließen wo hin?
Zeig die Anweisungen (Die „Prompt"-Regel):
- Metapher: Wenn du einem Koch sagst „Mach was Leckeres", ist das zu vage. Du musst das genaue Rezept zeigen.
- Regel: Veröffentliche die exakten Befehle (Prompts), die du der KI gegeben hast. Wie hast du sie formuliert? Wie hast du sie verbessert?
Lass einen Menschen nachprüfen (Die „Chef-Koch"-Regel):
- Metapher: Ein Koch kann sich irren. Der Küchenchef muss probieren.
- Regel: Wenn die KI etwas bewertet (z. B. „Ist dieser Code gut?"), lass einen echten Menschen das Ergebnis prüfen. Vertraue nicht blind auf die KI.
Vergleich mit einem offenen Modell (Die „Testkandidat"-Regel):
- Metapher: Wenn du behauptest, dein neues Auto sei schneller als alle anderen, musst du es auch gegen ein bekanntes, offenes Modell (wie einen VW Golf) testen, nicht nur gegen ein geheimes Formel-1-Auto.
- Regel: Wenn du ein teures, geschlossenes KI-Modell nutzt, vergleiche es auch mit einem kostenlosen, offenen Modell, damit andere es nachbauen können.
Benutze gute Messlatten (Die „Lineal"-Regel):
- Metapher: Du kannst die Länge eines Hauses nicht mit einer Waage messen.
- Regel: Benutze sinnvolle Messmethoden, die wirklich das messen, was du behauptest. Erkläre, warum dein Lineal das richtige ist.
Sag die Schwächen (Die „Fehlerliste"-Regel):
- Metapher: Kein Haus ist perfekt. Sag, wo die Wackelstelle ist.
- Regel: Sei offen darüber, wo deine Forschung hinkt (z. B. „Die KI war vielleicht voreingenommen" oder „Wir haben nicht genug Geld für viele Tests").

Warum ist das wichtig?

Ohne diese Regeln wäre die Software-Forschung wie ein Zauberkünstler, der seine Tricks nicht verrät. Jeder könnte behaupten, er habe etwas Neues erfunden, aber niemand könnte es überprüfen.

Mit diesen Regeln wird die Forschung wieder transparent, überprüfbar und vertrauenswürdig. Es ist wie ein gemeinsames Regelwerk für alle Architekten auf der Welt, damit wir sicherstellen können, dass die Gebäude, die wir mit KI bauen, wirklich stabil sind und nicht einfach nur auf Sand stehen.

Das Papier ist also im Grunde ein Versprechen an die Wissenschaftsgemeinschaft: „Wir nutzen diese mächtige neue Technologie, aber wir werden sie nicht im Dunkeln einsetzen. Wir werden alles offenlegen, damit wir gemeinsam weiterlernen können."

Titel und Kontext

Titel: Guidelines for Empirical Studies in Software Engineering involving Large Language Models (Leitlinien für empirische Studien im Software Engineering, die Large Language Models einbeziehen)
Autoren: Sebastian Baltes et al. (22 Co-Autoren aus dem Bereich Software Engineering und Empirische Forschung)
Zielgruppe: Software-Engineering-Forscher, Entwickler von LLM-Tools und Gutachter von wissenschaftlichen Publikationen.

1. Problemstellung

Seit der Veröffentlichung von ChatGPT im November 2022 haben Large Language Models (LLMs) die Software Engineering (SE)-Forschung und -Praxis durchdrungen. Dennoch ist die Reproduzierbarkeit und Replizierbarkeit empirischer Studien, die LLMs nutzen, stark gefährdet. Drei Hauptmerkmale von LLMs erschweren dies:

Inhärente Nicht-Determiniertheit: Kleine Änderungen in Eingaben oder Parametern (z. B. Temperatur) führen zu signifikant unterschiedlichen Ergebnissen.
Intransparente und sich schnell entwickelnde Modelle: Kommerzielle Modelle ändern sich oft ohne Versions-IDs, und Trainingsdaten sowie Feinabstimmungsdetails („Fine-Tuning") bleiben oft geheim.
Empfindlichkeit gegenüber Prompts: Die Art und Weise, wie Prompts formuliert werden, kann die Genauigkeit um mehrere Prozentpunkte verschieben.

Bisherige Leitlinien für empirische Studien (z. B. ACM SIGSOFT Empirical Standards) adressieren diese LLM-spezifischen Herausforderungen nicht ausreichend. Es fehlte an einem umfassenden, von der Gemeinschaft entwickelten Rahmenwerk, um die Validität und Vergleichbarkeit von SE-Studien mit LLMs zu gewährleisten.

2. Methodik

Das Papier basiert auf einer kollaborativen Initiative von 22 Forschern, initiiert auf dem ISERN-Meeting 2024. Der Prozess folgte etablierten Traditionen zur Entwicklung von Reporting-Leitlinien (ähnlich wie CONSORT für klinische Studien):

Iterative Entwicklung: Bi-wöchentliche Meetings zur Definition der Struktur, Erweiterung der Taxonomie und Verfeinerung der Leitlinien.
Peer-Review-Phasen: Mehrstufige interne und externe Reviews durch Experten für empirisches SE.
Konsensbildung: Alle Autoren mussten den gesamten Leitfaden lesen und sich hinter alle Empfehlungen stellen, nicht nur hinter ihre eigenen Beiträge.
Beispielanalyse: Systematische Suche nach relevanten Studien (innerhalb und außerhalb von SE) zur Veranschaulichung der Punkte.
Lebendige Ressource: Die Leitlinien werden online unter llm-guidelines.org als „Living Resource" gepflegt.

3. Schlüsselbeiträge

A. Taxonomie von 7 Studientypen

Um die Empfehlungen zu kontextualisieren, wurde eine Taxonomie von sieben Arten der LLM-Beteiligung in der empirischen Forschung erstellt:

LLMs als Annotatoren (S1): Automatisierte Kodierung qualitativer Daten (z. B. Interviewtranskripte).
LLMs als Richter (S2): Bewertung von Software-Artefakten (z. B. Code-Qualität, Anforderungsqualität).
LLMs für Synthese (S3): Integration von Informationen aus mehreren Quellen oder Generierung synthetischer Daten (z. B. synthetische Anforderungen).
LLMs als Subjekte (S4): Simulation menschlichen Verhaltens in Umfragen oder Experimenten.
Studium der LLM-Nutzung (S5): Analyse, wie Softwareingenieure LLM-Tools in der Praxis nutzen.
LLMs für neue SE-Tools (S6): Entwicklung und Evaluation neuer Tools, die LLMs integrieren (z. B. Agenten-Systeme).
Benchmarking von LLMs (S7): Evaluierung der Leistung von LLMs auf standardisierten Aufgaben (z. B. Code-Generierung).

B. Acht Leitlinien (Guidelines)

Das Kernstück des Papiers sind acht Leitlinien, die zwischen Pflichtanforderungen (must) und empfohlenen Praktiken (should) unterscheiden. Jede Leitlinie ist mit einer Begründung, konkreten Empfehlungen, Beispielen und Hinweisen für Gutachter versehen.

G1: Deklaration von LLM-Nutzung und Rolle:
- Pflicht: Offenlegung der Verwendung, des spezifischen Modells, der Rolle (z. B. Annotator) und des Einsatzortes im Forschungsprozess.
G2: Bericht über Modellversion, Konfiguration und Anpassungen:
- Pflicht: Exakte Versionsnummer, Datum des Experiments, Konfigurationsparameter (Temperatur, Seed, Top-p) und Details zu Fine-Tuning (Ziel, Datensatz, Hyperparameter). Bei quantisierten Modellen muss die Quantisierungsebene angegeben werden.
G3: Bericht über die Tool-Architektur jenseits des Modells:
- Pflicht: Beschreibung der gesamten Architektur (Pre-/Post-Processing, Agenten-Rollen, Datenbanken, Retrieval-Mechanismen). Bei Agenten-Systemen müssen Interaktionspfade und Tool-Calls dokumentiert werden.
G4: Offenlegung von Prompts, deren Entwicklung und Interaktions-Logs:
- Pflicht: Veröffentlichung aller Prompts (oder Templates mit Beispielen) und Entwicklungsgeschichte. Bei SaaS-Modellen sollten vollständige Interaktions-Logs (Prompt + Response) als Supplement bereitgestellt werden, um Nicht-Determiniertheit zu adressieren.
G5: Validierung von LLM-Ausgaben durch Menschen:
- Pflicht: Wenn keine Referenzdatensätze existieren, müssen LLM-Ergebnisse durch menschliche Validierung überprüft werden. Es müssen Inter-Rater-Übereinstimmung (z. B. Krippendorff's $\alpha$ ) und Messinstrumente berichtet werden.
G6: Verwendung eines Open-Source-LLM als Baseline:
- Empfehlung: Bei Nutzung kommerzieller Modelle sollte ein Open-Weight-Modell als Baseline dienen, um die Reproduzierbarkeit zu sichern. Ein vollständiges Replikationspaket ist erforderlich.
G7: Verwendung geeigneter Baselines, Benchmarks und Metriken:
- Pflicht: Begründung der gewählten Metriken und Benchmarks (Konstruktvalidität). Due to Nicht-Determiniertheit müssen Experimente wiederholt werden; Ergebnisse sind als Verteilung (Deskriptive Statistik) und mit inferenzstatistischen Tests zu berichten.
G8: Bericht über Limitationen und Minderungsstrategien:
- Pflicht: Transparente Darstellung von Validitätsbedrohungen (Interne/Externe Validität, Zuverlässigkeit, Reproduzierbarkeit) und spezifischen Minderungsstrategien (z. B. Triangulation, Sensitivitätsanalysen, Kostenberichterstattung).

C. Werkzeuge für Autoren und Gutachter

Anwendbarkeitsmatrix: Eine Tabelle, die zeigt, welche Leitlinien für welche Studientypen als „must" oder „should" gelten.
Reporting-Checkliste: Eine detaillierte Checkliste (inspiriert von CONSORT), die nach Abschnitten eines Papers (Einleitung, Methoden, Ergebnisse, etc.) gegliedert ist und die zu erfüllenden Punkte auflistet.

4. Ergebnisse und Erkenntnisse

Das Papier stellt keine neuen empirischen Daten dar, sondern synthetisiert den aktuellen Forschungsstand zu LLMs in der SE-Forschung. Die Hauptergebnisse sind die identifizierten Lücken in der aktuellen Berichterstattung:

Viele Studien berichten unzureichend über Modellversionen und Konfigurationen, was Replikationen unmöglich macht.
Die Validität von LLMs als „Richter" oder „Annotatoren" wird oft ohne menschliche Validierung oder ohne Angabe von Übereinstimmungsmetriken behauptet.
Es besteht ein Mangel an Transparenz bezüglich der Prompt-Entwicklung und der Architektur von Agenten-Systemen.
Die Leitlinien zeigen auf, dass reine Metriken (wie BLEU oder Pass@k) oft nicht ausreichen, um die Qualität von SE-Artefakten zu messen, und menschliche Validierung essenziell ist.

5. Bedeutung und Ausblick

Diese Leitlinien sind von zentraler Bedeutung für die Zukunft der Software Engineering-Forschung:

Standardisierung: Sie schaffen einen gemeinsamen Nenner für die Berichterstattung, was den Vergleich von Studien und den kumulativen Erkenntnisgewinn ermöglicht.
Vertrauenswürdigkeit: Durch die Forderung nach Offenlegung von Prompts, Versionen und Architekturen wird die Glaubwürdigkeit von LLM-basierten Ergebnissen erhöht.
Ethik und Nachhaltigkeit: Die Leitlinien adressieren wichtige Aspekte wie Datenschutz, Bias, Urheberrecht und den ökologischen Fußabdruck (Energieverbrauch) von LLM-Experimenten.
Lebendige Ressource: Da sich LLM-Technologie schnell entwickelt, wird das Dokument als dynamische Ressource gepflegt, die von der Community weiterentwickelt werden kann.

Zusammenfassend bietet das Papier einen notwendigen und umfassenden Rahmen, um die Reproduzierbarkeitskrise in der LLM-basierten Software Engineering-Forschung zu adressieren und wissenschaftliche Rigorosität sicherzustellen.