🤖 AI

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

Deze position paper stelt OLAF voor, een conceptueel kader dat LLM-gebaseerde annotatie in empirische software engineering behandelt als een rigoureus meetproces door kernconstructen zoals betrouwbaarheid, kalibratie en drift te definiëren om transparantie en reproduceerbaarheid te vergroten.

Oorspronkelijke auteurs: Mia Mohammad Imran, Tarannum Shaila Zaman

Gepubliceerd 2026-01-27

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Mia Mohammad Imran, Tarannum Shaila Zaman

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een enorme bibliotheek met slordige, handgeschreven aantekeningen probeert te organiseren. In het verleden zou je een team van menselijke bibliothecarissen hebben ingehuurd om elke aantekening te lezen, te beslissen in welke categorie deze thuishoort (zoals "Bug Report", "Feature Request" of "Spam") en er een label op te schrijven. Dit is traag, duur en soms zijn twee bibliothecarissen het oneens over dezelfde aantekening.

Stel je nu voor dat je een super slimme robot inhuurt (een AI of Large Language Model) om het labelen voor je te doen. Het is snel en goedkoop. Maar hier is het probleem: Doet de robot eigenlijk zijn werk goed, of is hij gewoon aan het gokken?

Dit artikel, getiteld OLAF, betoogt dat we moeten stoppen met deze robots te behandelen als magische zwarte dozen die gewoon "het werk doen". In plaats daarvan moeten we ze behandelen als wetenschappelijke meetinstrumenten, net zoals een thermometer of een weegschaal. Als je een weegschaal gebruikt om ingrediënten voor een taart af te wegen, moet je weten of de weegschaal nauwkeurig is, of hij in de loop van de tijd afwijkt en of hij elke keer dat je hem gebruikt hetzelfde resultaat geeft.

Hier is de uitsplitsing van de ideeën uit het artikel met behulp van eenvoudige analogieën:

1. Het Probleem: De "Magische Doos" Valstrik

Op dit moment gebruiken veel onderzoekers AI om gegevens te labelen, maar vertellen ze ons niet hoe ze dat hebben gedaan.

De Analogie: Stel je voor dat een bakker zegt: "Ik heb een speciale oven gebruikt om dit brood te bakken." Maar hij vertelt je niet de temperatuur, de tijd of het merk van de oven. Als je probeert hetzelfde brood te bakken, kan het er aangebrand of juist rauw uitkomen.
De Realiteit: Onderzoekers vergeten vaak kleine details te vermelden, zoals de exacte woorden die ze in de AI typen (de "prompt"), de specifieke versie van de AI of de instellingen die ze gebruikten. Hierdoor kan niemand anders hun experiment herhalen om te zien of ze dezelfde resultaten krijgen.

2. De Oplossing: OLAF (Het "Kwaliteitscontrole" Framework)

De auteurs stellen een nieuw framework voor genaamd OLAF. Zie OLAF als een checklist voor kwaliteitscontrole die je moet gebruiken voordat je de labels van de robot vertrouwt. Het behandelt de AI niet als een werknemer, maar als een meetinstrument dat gekalibreerd moet worden.

OLAF vra� wet je om zes specifieke zaken te controleren (Constructen):

Betrouwbaarheid (De "Consistentie" Check): Als je de robot vijf keer dezelfde aantekening laat labelen, geeft hij dan steeds hetzelfde antwoord? Of wisselt hij van mening?
Consensus (De "Groepsknuffel" Check): Als je drie verschillende robots gebruikt, zijn ze het dan allemaal eens over het label? Als ze allemaal "Bug" zeggen, is dat een sterk signaal. Als ze het oneens zijn, is de taak misschien te verwarrend.
Aggregatie (Het "Stemmechanisme"): Hoe combineer je de antwoorden? Neem je gewoon de meerderheid van de stemmen? Of gebruik je een geavanceerde wiskundige formule om te bepalen welke robot het meest betrouwbaar is?
Transparantie (De "Bonnen" Check): Heb je alles opgeschreven? De naam van de robot, het versienummer, de exacte woorden die je hebt getypt? Zonder deze "bon" is het werk nutteloos voor anderen.
Kalibratie (De "Zelfvertrouwen" Check): Als de robot zegt: "Ik weet voor 99% zeker dat dit een bug is," is hij dan ook daadwerkelijk 99% van de tijd juist? Of is hij gewoon overmoedig? Dit controleert of het zelfvertrouwen van de robot overeenkomt met de realiteit.
Drift (De "Veranderende Doelpalen" Check): AI-modellen veranderen in de loop van de tijd. Een robot die vandaag perfect werkt, kan er volgende maand heel anders uitzien omdat het bedrijf de software heeft bijgewerkt. OLAF controleert of het gedrag van de robot is "gedrift" of onverwacht is veranderd.

3. Hoe je de Robot te Gebruiken (De Zes Configuraties)

Het artikel legt ook uit dat je de robot niet altijd alles zelf moet laten doen. Het suggereert zes manieren om mensen en robots te mengen, als verschillende recepten:

Human-in-the-Loop: De robot doet de eerste ronde, maar een mens controleert de onderdelen waar de robot niet zeker van is. (Als een leerling huiswerk maakt, en een leraar de moeilijke delen nakijkt).
Model-in-the-Loop: De robot stelt een antwoord voor, en een andere robot of een mens controleert dit.
Verifier-in-the-Loop: Een tweede robot fungeert als een "scheidsrechter" om te controleren of het antwoord van de eerste robot goed is voordat een mens het te zien krijgt.
Filter: De robot gooit de overduidelijke troep (zoals spam-e-mails) snel weg, zodat mensen alleen naar de belangrijke zaken hoeven te kijken.
Judge: De robot fungeert als een scheidsrechter die het werk van andere AI's beoordeelt op basis van een set regels.
Annotator: De robot doet het hele werk alleen. (Dit is snel, maar riskant als de robot een fout maakt).

4. De Addertjes onder het Gras (Beperkingen)

De auteurs geven toe dat dit nog geen perfecte oplossing is.

De Analogie: Je kunt een thermometer niet volledig vertrouwen als je niet weet hoe deze is gemaakt of als de fabriek elke week het ontwerp verandert.
De Realiteit: Veel populaire AI-modellen (zoals die van grote techbedrijven) zijn "black boxes". We weten niet wat hun trainingsdata is, en ze kunnen veranderen zonder dat we het weten. OLAF probeert te meten hoe stabiel ze zijn, maar kan niet garanderen dat ze morgen niet veranderen.

Samenvatting

Het artikel zegt: "Stop met het behandelen van AI-labeling als magie. Begin het te behandelen als wetenschap."

Als je AI wilt gebruiken om gegevens te labelen in software engineering, heb je een framework nodig (OLAF) dat je dwingt om te controleren of de AI consistent is, of hij eerlijk is over zijn zelfvertrouwen, en of je precies hebt opgeschreven hoe je hem hebt gebruikt. Zonder dit zijn je onderzoeksresultaten onbetrouwbaar, net als een taart gemaakt met een ongemeten oven.

Technische Samenvatting: OLAF – Naar een robuust raamwerk voor LLM-gebaseerde annotatie in Empirical Software Engineering

Probleemstelling
Empirical Software Engineering (ESE) vertrouwt steeds vaker op Large Language Models (LLM's) om annotatietaken te automatiseren of te ondersteunen, zoals het labelen van bugrapporten, het classificeren van commit-intenties of het identificeren van self-admitted technical debt. De methodologische strengheid van deze praktijken is echter nog onvoldoende ontwikkeld. Huidige studies behandelen LLM-gebaseerde annotatie vaak als een puur automatische activiteit in plaats van een meetproces, wat leidt tot verschillende kritieke tekortkomingen:

Gebrek aan standaardisatie: Er zijn geen gestandaardiseerde maten voor betrouwbaarheid, kalibratie of drift in LLM-annotatiestudies.
Gefragmenteerde rapportage: Essentiële configuratiedetails (bijv. prompt-templates, decoding-parameters, modelversies) worden frequent weggelaten, wat reproduceerbaarheid belemmert.
Configuratiesensitiviteit: Kleine wijzigingen in prompts, temperatuurinstellingen of modelupdates kunnen de uitkomsten drastisch veranderen (een fenomeen dat wordt aangeduid als "prompt drift" of "LLM hacking"), maar deze sensitiviteiten worden zelden gekwantificeerd.
Ongedefinieerde constructen: Abstracte concepten zoals "label nauwkeurigheid" missen formele operationele definities die ze koppelen aan meetbare procedures, wat de construct-, interne en externe validiteit bedreigt.

Methodologie en Raamwerk (OLAF)
Het artikel stelt het Operationalization for LLM-based Annotation Framework (OLAF) voor. In plaats van een nieuw algoritme of een specifiek experimenteel resultaat aan te bieden, is OLAF een conceptueel raamwerk dat is ontworpen om LLM-annotatie te behandelen als een meetbaar, auditeerbaar proces. Het operationaliseert annotatie via zes kernconstructen en koppelt deze aan specifieke metrieken en rapportagefocuspunten (samengevat in Tabel 1 van het artikel):

Annotator Betrouwbaarheid (Annotator Reliability): Meet de overeenstemming tussen individuele annotatoren (mens of model) met behulp van kans-gecorrigeerde statistieken (bijv. Cohen's $\kappa$ , Gwet's AC1, Krippendorff's $\alpha$ ).
Consensus: Weerspiegelt groepsniveau-overeenstemming om te bepalen of annotatoren convergeren naar een gedeeld oordeel of dat de taak inherente ambiguïteit bevat.
Aggregatie (Aggregation): Definieert methoden voor het combineren van meerdere annotatoren tot één enkel label, waarbij specifiek onderscheid wordt gemaakt tussen probabilistische aggregatie (bijv. Dawid–Skene, GLAD, MACE) en meerderheidsstemming (majority voting).
Transparantie: Verplicht volledige documentatie van modelidentificaties, parameters, prompts en instellingen (volgens praktijken zoals Datasheets en Model Cards) om reproduceerbaarheid te waarborgen.
Kalibratie (Calibration): Evalueert de correctheid van voorspelde waarschijnlijkheden door geconfidence scores te vergelijken met empirische nauwkeurigheid met behulp van metrieken zoals Expected Calibration Error (ECE) en de Brier Score.
Drift: Legt gedragsstabiliteit vast door te meten hoeveel het gedrag van het model verandert onder variaties in prompt of context, gekwantificeerd via activatieafstanden (L2, cosinus), outputdistributie-metrieken (Jensen-Shannon divergentie) of prompt-sensitiviteitsindices (POSIX).

Het raamwerk categoriseert ook zes veelvoorkomende annotatiewerkstromen (Tabel 2) om te contextualiseren waar deze metrieken van toepassing zijn:

Human-in-the-Loop (HitH)
LLM/Model-in-the-Loop (MitL)
Verifier-in-the-Loop (VitL)
LLM-als-een-pre-screen-filter
LLM-als-een-rechter (LLM-as-a-Judge, LLMaaJ)
LLM-als-een-annotator

Belangrijkste Bijdragen

Conceptuele Verschuiving: Het artikel pleit voor het herconceptualiseren van LLM-annotatie van een automatiseringstaak naar een meetproces, dat dezelfde validatiestrengheid vereist als traditionele codemetrieken.
Operationele Definities: Het biedt de eerste gestructureerde set operationele definities voor betrouwbaarheid, consensus, drift en kalibratie, specifiek afgestemd op LLM-gebaseerde annotatie in SE.
Richtlijnen voor de Praktijk: De auteurs bieden concrete richtlijnen voor onderzoekers, waaronder:
- Het expliciet verklaren van de annotatieconfiguratie (bijv. HitH vs. LLM-als-een-annotator).
- Het documenteren van volledige model- en promptdetails.
- Het selecteren van geschikte aggregatiemethoden op basis van geobserveerde overeenstemming.
- Het implementeren van drift-tracking met behulp van vaste kalibratiesubsets (bijv. het opnieuw annoteren van 50–100 door experts gelabelde items wanneer parameters veranderen).
Informatievoorziening: De auteurs hebben een begeleidende website opgezet (se-llm-annotation-olaf.github.io) met gedetailleerde richtlijnen en voorbeelden.

Resultaten en Claims
Als position paper presenteert OLAF geen nieuwe experimentele data of empirische resultaten die de effectiviteit van het raamwerk valideren. In plaats daarvan zijn de "resultaten" de synthese van de bestaande literatuur (verwijzend naar werken door Ahmed et al., Baumann et al., Wagner et al., etc.) om de huidige mate van gebrek aan strengheid aan te tonen.

Het artikel claimt dat:

Huidige LLM-annotatiepraktijken onvoldoende zijn voor veiligheidskritische of compliance-gevoelige omgevingen vanwege ongedefinieerde betrouwbaarheid en kalibratie.
De voorgestelde zes constructen een noodzakelijke basis bieden voor reproduceerbaar onderzoek, waardoor onderzoekers dimensies kunnen selecteren die relevant zijn voor hun specifieke taak (bijv. deterministische taken vereisen mogelijk niet alle zes de dimensies).
Het raamwerk rekening houdt met beperkingen, met name met betrekking tot propriëtaire modellen (bijv. GPT, Claude) waarbij trainingsdata en update-schema's opaak zijn, waardoor "beperkte stabiliteit" (constrained stability) het realistische doel is in plaats van deterministisch gedrag.

Significantie
De significantie van OLAF ligt in het potentieel om de methodologische standaarden van Empirical Software Engineering te verhogen. Door een gestructureerde vocabulaire en meetaanpak te bieden, beoogt het:

Methodologische discussies te stimuleren over de validiteit van door LLM gegenereerde labels.
Toekomstig empirisch werk transparanter en reproduceerbaarder te maken.
Te voorkomen dat het "black box"-karakter van LLM-annotatie de validiteit van SE-onderzoeksbevindingen ondermijnt.

De auteurs positioneren OLAF als een eerste stap, waarbij toekomstig werk gepland is om de impact van het raamwerk op reproduceerbaarheid empirisch te evalueren en om SE-specifieke operationele voorbeelden te ontwikkelen.