🤖 AI

OLAF: Towards Robust LLM-Based Annotation Framework in Empirical Software Engineering

Dieses Positionspapier schlägt OLAF vor, ein konzeptionelles Framework, das die LLM-basierte Annotation in der empirischen Softwaretechnik als einen rigorosen Messprozess behandelt, indem es Schlüsselkonstrukte wie Zuverlässigkeit, Kalibrierung und Drift definiert, um Transparenz und Reproduzierbarkeit zu erhöhen.

Ursprüngliche Autoren: Mia Mohammad Imran, Tarannum Shaila Zaman

Veröffentlicht 2026-01-27

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Mia Mohammad Imran, Tarannum Shaila Zaman

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

Stellen Sie sich vor, Sie versuchen, eine riesige Bibliothek mit unordentlichen, handgeschriebenen Notizen zu organisieren. Früher hätten Sie ein Team von menschlichen Bibliothekaren eingestellt, die jede Notiz lesen, entscheiden, in welche Kategorie sie gehört (wie zum Beispiel „Fehlerbericht“, „Feature-Anfrage“ oder „Spam“), und dann ein Etikett darauf schreiben. Das ist langsam, teuer und manchmal sind sich zwei Bibliothekare über dieselbe Notiz uneinig.

Jetzt stellen Sie sich vor, Sie stellen einen superintelligenten Roboter ein (eine KI oder ein Large Language Model), um die Kennzeichnung für Sie zu übernehmen. Es ist schnell und günstig. Aber hier liegt das Problem: Macht der Roboter wirklich einen guten Job oder rät er nur?

Dieses Paper mit dem Titel OLAF argumentiert, dass wir aufhören müssen, diese Roboter wie magische Black Boxes zu behandeln, die einfach nur „die Arbeit erledigen“. Stattdessen müssen wir sie wie wissenschaftliche Messinstrumente behandeln, genau wie ein Thermometer oder eine Waage. Wenn Sie eine Waage benutzen, um Zutaten für einen Kuchen abzuwiegen, müssen Sie wissen, ob die Waage genau ist, ob sie im Laufe der Zeit ungenau wird und ob sie jedes Mal das gleiche Ergebnis liefert, wenn Sie sie benutzen.

Hier ist die Aufschlüsselung der Ideen des Papers unter Verwendung einfacher Analogien:

1. Das Problem: Die „Magische Box“-Falle

Derzeit nutzen viele Forscher KI, um Daten zu kennzeichnen, aber sie sagen uns nicht, wie sie das gemacht haben.

Die Analogie: Stellen Sie sich vor, ein Bäcker sagt: „Ich habe einen speziellen Ofen benutzt, um dieses Brot zu backen.“ Aber er sagt Ihnen nicht, welche Temperatur, welche Zeit oder welche Marke der Ofen war. Wenn Sie versuchen, dasselbe Brot zu backen, könnte es verbrannt oder roh herauskommen.
Die Realität: Forscher vergessen oft, kleine Details zu erwähnen, wie die exakten Wörter, die sie in die KI eingegeben haben (den „Prompt“), die spezifische Version der KI oder die verwendeten Einstellungen. Da dies fehlt, kann niemand sonst ihr Experiment wiederholen, um zu sehen, ob er die gleichen Ergebnisse erzielt.

2. Die Lösung: OLAF (Das „Qualitätskontroll“-Framework)

Die Autoren schlagen ein neues Framework namens OLAF vor. Betrachten Sie OLAF als eine Checkliste für die Qualitätskontrolle, die Sie verwenden müssen, bevor Sie den Labels des Roboters vertrauen können. Es behandelt die KI nicht als Arbeiter, sondern als ein Messinstrument, das kalibriert werden muss.

OLAF fordert Sie auf, sechs spezifische Dinge (Konstrukte) zu prüfen:

Reliabilität (Der „Konsistenz“-Check): Wenn Sie den Roboter bitten, dieselbe Notiz fünfmal zu kennzeichnen, gibt er dann immer die gleiche Antwort? Oder schwankt er?
Konsens (Der „Gruppenumarmungs“-Check): Wenn Sie drei verschiedene Roboter verwenden, stimmen sie alle bei der Kennzeichnung überein? Wenn sie alle „Bug“ sagen, ist das ein starkes Signal. Wenn sie uneinig sind, könnte die Aufgabe zu verwirrend sein.
Aggregation (Das „Abstimmungssystem“): Wie kombinieren Sie die Antworten? Nehmen Sie einfach die Mehrheitsentscheidung? Oder verwenden Sie eine ausgeklügelte mathematische Formel, um herauszufinden, welcher Roboter am zuverlässigsten ist?
Transparenz (Der „Beleg“-Check): Haben Sie alles aufgeschrieben? Den Namen des Roboters, die Versionsnummer, die exakten Wörter, die Sie eingegeben haben? Oh ohne diesen „Beleg“ ist die Arbeit für andere wertlos.
Kalibrierung (Der „Konfidenz“-Check): Wenn der Roboter sagt: „Ich bin mir zu 99 % sicher, dass dies ein Bug ist“, ist er dann tatsächlich in 99 % der Fälle richtig? Oder ist er einfach nur übermäßig selbstbewusst? Dies prüft, ob das Vertrauen des Roboters mit der Realität übereinstimmt.
Drift (Der „Verschiebung der Torpfosten“-Check): KI-Modelle verändern sich im Laufe der Zeit. Ein Roboter, der heute perfekt funktioniert, könnte nächsten Monat anders agieren, weil das Unternehmen seine Software aktualisiert hat. OLAF prüft, ob sich das Verhalten des Roboters unerwartet verändert hat („gedriftet“ ist).

3. Wie man den Roboter benutzt (Die sechs Konfigurationen)

Das Paper erklärt auch, dass Sie den Roboter nicht immer alles machen lassen müssen. Es schlägt sechs Wege vor, wie man Menschen und Roboter mischt, wie verschiedene Rezepte:

Human-in-the-Loop: Der Roboter macht die erste Durchgang, aber ein Mensch überprüft diejenigen, bei denen sich der Roboter unsicher ist. (Wie ein Schüler, der Hausaufgaben macht, und ein Lehrer, der die schwierigen Teile bewertet).
Model-in-the-Loop: Der Roboter schlägt eine Antwort vor, und ein anderer Roboter oder ein Mensch überprüft sie.
Verifier-in-the-Loop: Ein zweiter Roboter fungiert als „Schiedsrichter“, um zu prüfen, ob die Antwort des ersten Roboters gut ist, bevor ein Mensch sie sieht.
Filter: Der Roboter wirft den offensichtlichen Müll (wie Spam-E-Mails) schnell weg, sodass Menschen nur das Wichtige betrachten müssen.
Judge: Der Roboter fungiert als Schiedsrichter und bewertet die Arbeit anderer KIs basierend auf einem Satz von Regeln.
Annotator: Der Roboter erledigt den gesamten Job allein. (Das ist schnell, aber riskant, wenn der Roboter einen Fehler macht).

4. Der Haken (Einschränkungen)

Die Autoren geben zu, dass dies noch keine perfekte Lösung ist.

Die Analogie: Man kann einem Thermometer nicht voll vertrauen, wenn man nicht weiß, wie es gebaut wurde oder ob die Fabrik das Design jede Woche ändert.
Die Realität: Viele populäre KI-Modelle (wie die von großen Tech-Unternehmen) sind „Black Boxes“. Wir kennen nicht deren Trainingsdaten, und sie können sich ändern, ohne es zu melden. OLAF versucht zu messen, wie stabil sie sind, aber es kann nicht garantieren, dass sie sich morgen nicht ändern werden.

Zusammenfassung

Das Paper sagt: „Hören Sie auf, die KI-Kennzeichnung als Magie zu behandeln. Fangen Sie an, sie wie eine Wissenschaft zu behandeln.“

Wenn Sie KI verwenden wollen, um Daten im Software Engineering zu kennzeichnen, benötigen Sie ein Framework (OLAF), das Sie dazu zwingt zu prüfen, ob die KI konsistent ist, ob sie ehrlich bezüglich ihres Vertrauens ist und ob Sie genau aufgeschrieben haben, wie Sie sie verwendet haben. Ohne dies sind Ihre Forschungsergebnisse möglicherweise unzuverlässig, wie ein Kuchen, der mit einem nicht gemessenen Ofen gebacken wurde.

Technisches Resümee: OLAF – Hin zu einem robusten LLM-basierten Annotations-Framework in der empirischen Softwaretechnik

Problemstellung
Die empirische Softwaretechnik (Empirical Software Engineering, ESE) stützt sich zunehmend auf Large Language Models (LLMs), um Annotationsaufgaben wie das Labeln von Bug-Reports, die Klassifizierung von Commit-Intents oder die Identifizierung von selbstzugegebenem technischem Schulden (Self-Admitted Technical Debt) zu automatisieren oder zu unterstützen. Die methodische Strenheit dieser Praktiken ist jedoch noch unzureichend entwickelt. Aktuelle Studien behandeln die LLM-basierte Annotation oft als rein automatisierte Aktivität statt als einen Messprozess, was zu mehreren kritischen Lücken führt:

Mangelnde Standardisierung: Es gibt keine standardisierten Maße für Zuverlässigkeit, Kalibrierung oder Drift in LLM-basierten Annotationsstudien.
Fragmentierte Berichterstattung: Wesentliche Konfigurationsdetails (z. B. Prompt-Templates, Decoding-Parameter, Modellversionen) werden häufig ausgelassen, was die Reproduzierbarkeit behindert.
Konfigurationssensitivität: Geringfügige Änderungen in Prompts, Temperature-Einstellungen oder Modell-Updates können die Ergebnisse drastisch verändern (ein Phänomen, das als „Prompt Drift“ oder „LLM Hacking“ bezeichnet wird), doch diese Sensitivitäten werden selten quantifiziert.
Undefinierte Konstrukte: Abstrakte Konzepte wie „Label-Genauigkeit“ (Label Accuracy) lassen eine formale operationale Definition vermissen, die sie mit messbaren Verfahren verknüpft, was die Konstrukt-, interne und externe Validität gefährdet.

Methodik und Framework (OLAF)
Das Paper schlägt das Operationalization for LLM-based Annotation Framework (OLAF) vor. Anstatt einen neuen Algorithmus oder ein spezifisches experimentelles Ergebnis anzubieten, ist OLAF ein konzeptionelles Framework, das darauf ausgelegt ist, die LLM-Annotation als einen messbaren, auditierbaren Prozess zu behandeln. Es operationalisiert die Annotation durch sechs Schlüsselkonstrukte und ordnet diese spezifischen Metriken und Berichtsschwerpunkten zu (zusammengefasst in Tabelle 1 des Papers):

Annotator Reliability (Annotatoren-Zuverlässigkeit): Misst die Übereinstimmung zwischen einzelnen Annotatoren (Mensch oder Modell) unter Verwendung von Chance-korrigierten Statistiken (z. B. Cohens $\kappa$ , Gwets AC1, Krippendorffs $\alpha$ ).
Consensus (Konsens): Spiegelt die Übereinstimmung auf Gruppenebene wider, um zu bestimmen, ob Annotatoren zu einem gemeinsamen Urteil gelangen oder ob die Aufgabe eine inhärente Ambiguität aufweist.
Aggregation (Aggregation): Definiert Methoden zur Kombination mehrerer Annotatoren zu einem einzelnen Label, wobei insbesondere zwischen probabilistischer Aggregation (z. B. Dawid–Skene, GLAD, MACE) und Mehrheitsentscheidung (Majority Voting) unterschieden wird.
Transparency (Transparenz): Verlangt eine vollständige Dokumentation von Modell-Identifikatoren, Parametern, Prompts und Einstellungen (gemäß Praktiken wie Datasheets und Model Cards), um die Reproduzierbarkeit zu gewährleisten.
Calibration (Kalibrierung): Bewertet die Korrektheit vorhergesagter Wahrscheinlichkeiten durch den Vergleich von Konfidenz-Scores mit der empirischen Genauigkeit unter Verwendung von Metriken wie dem Expected Calibration Error (ECE) und dem Brier-Score.
Drift (Drift): Erfasst die Verhaltensstabilität, indem gemessen wird, wie stark sich das Modellverhalten unter Variationen von Prompt oder Kontext verändert, quantifiziert über Aktivierungsdistanzen (L2, Cosine), Output-Verteilungsmetriken (Jensen-Shannon-Divergenz) oder Prompt-Sensitivitätsindizes (POSIX).

Das Framework kategorisiert zudem sechs gängige Annotations-Workflows (Tabelle 2), um den Kontext zu verdeutlichen, in dem diese Metriken Anwendung finden:

Human-in-the-Loop (HitL)
LLM/Model-in-the-Loop (MitL)
Verifier-in-the-Loop (VitL)
LLM-as-a-Pre-screen-Filter
LLM-as-a-Judge (LLMaaJ)
LLM-as-an-Annotator

Zentrale Beiträge

Konzeptioneller Wandel: Das Paper argumentiert dafür, die LLM-Annotation von einer Automatisierungsaufgabe zu einem Messprozess umzudefinieren, der dieselbe Validierungsstrenge erfordert wie traditionelle Code-Metriken.
Operationale Definitionen: Es liefert den ersten strukturierten Satz operationaler Definitionen für Zuverlässigkeit, Konsens, Drift und Kalibrierung, die speziell auf die LLM-basierte Annotation in der Softwaretechnik zugeschnitten sind.
Leitlinien für die Praxis: Die Autoren stellen konkrete Leitlinien für Forscher bereit, darunter:
- Die explizite Angabe der Annotationskonfiguration (z. B. HitL vs. LLM-as-an-Annotator).
- Die Dokumentation vollständiger Modell- und Prompt-Details.
- Die Auswahl geeigneter Aggregationsmethoden basierend auf der beobachteten Übereinstimmung.
- Die Implementierung von Drift-Tracking mittels fester Kalibrierungs-Subsets (z. B. Re-Annotation von 50–100 Experten-gelabelten Items, wenn Parameter geändert werden).
Ressourcenbereitstellung: Die Autoren haben eine Begleitwebsite (se-llm-annotation-olaf.github.io) mit detaillierten Leitlinien und Beispielen erstellt.

Ergebnisse und Behauptungen
Als Position Paper präsentiert OLAF keine neuen experimentellen Daten oder empirischen Ergebnisse zur Validierung der Wirksamkeit des Frameworks. Stattdessen sind seine „Ergebnisse“ die Synthese bestehender Literatur (unter Zitierung von Arbeiten wie Ahmed et al., Baumann etä., Wagner et al. etc.), um den aktuellen Mangel an Stringenz aufzuzeigen.

Das Paper behauptet:

Aktuelle LLM-Annotationspraktiken sind für sicherheitskritische oder Compliance-sensible Umgebungen unzureichend, da es an definierten Metriken für Zuverlässigkeit und Kalibrierung mangelt.
Die vorgeschlagenen sechs Konstrukte bieten eine notwendige Grundlage für reproduzierbare Forschung, indem sie es Forschern ermöglichen, die für ihre spezifische Aufgabe relevanten Dimensionen auszuwählen (z. B. benötigen deterministische Aufgaben möglicherweise nicht alle sechs Dimensionen).
Das Framework erkennt Einschränkungen an, insbesondere hinsichtlich proprietärer Modelle (z. B. GPT, Claude), bei denen Trainingsdaten und Update-Zyklen opak sind, was macht „eingeschränkte Stabilität“ (constrained stability) zum realistischen Ziel statt deterministischen Verhaltens.

Bedeutung
Die Bedeutung von OLAF liegt in seinem Potenzial, die methodischen Standards der empirischen Softwaretechnik anzuheben. Durch die Bereitstellung eines strukturierten Vokabulars und eines Messansatzes zielt es darauf ab:

Diskussionen über die Validität von LLM-generierten Labels zu fördern.
Zukünftige empirische Arbeiten transparenter und reproduzierbarer zu machen.
Zu verhindern, dass die „Black Box“-Natur der LLM-Annotation die Validität von SE-Forschungsergebnissen untergräbt.

Die Autoren positionieren OLAF als einen ersten Schritt, wobei zukünftige Arbeiten geplant sind, um die Auswirkungen des Frameworks auf die Reproduzierbarkeit empirisch zu evaluieren und SE-spezifische operationale Beispiele zu entwickeln.