JwumaHoe schrijf je een annotatierubric die de realiteit overleeft
· 3 min leestijd · specification, quality
Deze vertaling is machinaal gemaakt en niet gecontroleerd door een moedertaalspreker. Bij twijfel geldt de Engelse versie. Laat het ons weten als iets niet klopt, dan corrigeren wij het. English
Een goede rubric besteedt het grootste deel van de lengte aan randgevallen in plaats van definities, omdat annotators zelden van mening verschillen over duidelijke gevallen. Vries het in wanneer een batch begint, zodat de standaard niet halverwege het project kan verschuiven, en behandel elke ambiguïteit die een annotator aangeeft als een defect in de rubric in plaats van een fout van de annotator.
Kort samengevat
- Annotator meningsverschillen concentreren zich bijna volledig in randgevallen.
- Een rubric moet worden bevroren wanneer een batch begint en daarna worden geversioneerd.
- Elk label moet herleidbaar zijn tot de rubricversie die het heeft geproduceerd.
- Aangegeven ambiguïteit is een defect in de rubric, geen fout van de annotator.
- Een rubric die halverwege een batch wordt gewijzigd, maakt vergelijking binnen die batch ongeldig.
Bent u zoiets aan het uitwerken?
Wij bespreken liever het probleem dan een offerte op volume.
Bekijk onze dienstenWaarom falen rubrics?
Bijna nooit omdat de definities verkeerd zijn. Ze falen omdat de definities prima zijn en de randgevallen ontbreken, waardoor twintig annotators onafhankelijk twintig verschillende antwoorden bedenken op dezelfde onbehandelde vraag.
Het meest voorkomende symptoom is overeenstemmingsscores die er over het algemeen acceptabel uitzien, terwijl een specifieke deel van de gegevens stilletjes waardeloos is. Geaggregeerde overeenstemming verbergt dit goed.
Hoeveel van de rubric moet randgevallen zijn?
Het grootste deel. Als je rubric voornamelijk uit definities bestaat met een kort gedeelte van voorbeelden aan het einde, is het een woordenlijst in plaats van een rubric.
De productieve manier om er een te schrijven is door een kleine pilotbatch uit te voeren met een ondergespecificeerde rubric, elk geval te verzamelen dat een annotator als ambigu aangeeft, en elk om te zetten in een expliciete regel. Het doel van de pilot is om de vragen te vinden, niet om gegevens te produceren.
Waarom de rubric bevriezen?
Omdat als de standaard halverwege de batch verschuift, werk dat correct is voltooid onder de oude definitie met terugwerkende kracht verkeerd wordt, en je niet uit de dataset kunt opmaken welke items onder welke versie zijn beoordeeld.
Bevriezen betekent dat de versie die van kracht is wanneer een batch opent, die batch beheerst. Verbeteringen gelden voor de volgende. Elk label draagt dan de versie die het heeft geproduceerd, wat een dataset controleerbaar maakt een jaar later wanneer iemand vraagt waarom twee vergelijkbare items verschillend zijn gelabeld.
Hoe moet aangegeven ambiguïteit worden behandeld?
Als een defectrapport over je rubric, wat het ook is. Een annotator die aangeeft in plaats van te raden, heeft precies het juiste gedaan en mag daar nooit voor worden gestraft.
Platforms die het aangeven bestraffen, krijgen minder meldingen en slechtere gegevens, omdat de ambiguïteit niet verdwijnt, maar stilletjes en inconsistent wordt opgelost waar niemand het kan zien.
Andere vragen
Wat maakt een annotatierubric goed?
Expliciete behandeling van randgevallen. Annotators verschillen zelden van mening over duidelijke voorbeelden, dus een rubric die voornamelijk uit definities en weinig randgevallen bestaat, zal inconsistente labels opleveren.
Moet een rubric halverwege een project worden gewijzigd?
Nee. Vries het in wanneer de batch begint, zodat de standaard niet kan verschuiven, en pas verbeteringen toe op de volgende batch. Anders wordt correct voltooid werk met terugwerkende kracht verkeerd.
Wat moet er gebeuren als een annotator een ambigu geval aangeeft?
Het moet worden behandeld als een defect in de rubric en expliciet worden opgelost. Het bestraffen van het aangeven duwt de ambiguïteit simpelweg ondergronds, waar het inconsistent wordt opgelost.