JwumaJak napisać rubrykę adnotacji, która przetrwa kontakt z rzeczywistością
· 2 min czytania · specification, quality
To tłumaczenie zostało wykonane maszynowo i nie zostało sprawdzone przez native speakera. W razie wątpliwości obowiązuje wersja angielska. Napisz nam, jeśli coś brzmi błędnie, a poprawimy. English
Dobra rubryka poświęca większość swojej długości przypadkom brzegowym, a nie definicjom, ponieważ adnotatorzy rzadko nie zgadzają się co do oczywistych przypadków. Zamroź ją, gdy partia się rozpoczyna, aby standard nie mógł się zmieniać w trakcie projektu, i traktuj każdą niejasność zgłoszoną przez adnotatora jako wadę rubryki, a nie błąd adnotatora.
W skrócie
- Nieporozumienia adnotatorów koncentrują się prawie wyłącznie na przypadkach brzegowych.
- Rubryka powinna być zamrożona, gdy partia się rozpoczyna, a następnie wersjonowana.
- Każda etykieta powinna być możliwa do prześledzenia do wersji rubryki, która ją wyprodukowała.
- Zgłoszona niejasność to wada rubryki, a nie błąd adnotatora.
- Rubryka zmieniona w trakcie partii unieważnia porównanie w tej partii.
Planujesz podobny projekt?
Wolimy rozmawiać o problemie niż wyceniać sam wolumen.
Zobacz nasze możliwościDlaczego rubryki zawodzą?
Prawie nigdy dlatego, że definicje są błędne. Zawodzą, ponieważ definicje są w porządku, a przypadki brzegowe są nieobecne, więc dwudziestu adnotatorów niezależnie wymyśla dwadzieścia różnych odpowiedzi na to samo niezaadresowane pytanie.
Najczęstszym objawem są wyniki zgodności, które wyglądają akceptowalnie ogólnie, podczas gdy konkretna część danych jest cicho bezwartościowa. Zbiorcza zgodność dobrze to ukrywa.
Ile rubryki powinno dotyczyć przypadków brzegowych?
Większość. Jeśli twoja rubryka składa się głównie z definicji z krótką sekcją przykładów na końcu, jest to raczej słownik niż rubryka.
Produktywnym sposobem na napisanie jej jest przeprowadzenie małej partii pilotażowej z niedospecyfikowaną rubryką, zebranie każdego przypadku, który adnotator zgłasza jako niejasny, i przekształcenie każdego z nich w wyraźną zasadę. Celem pilotażu jest znalezienie pytań, a nie produkcja danych.
Dlaczego zamrozić rubrykę?
Ponieważ jeśli standard zmienia się w trakcie partii, praca wykonana poprawnie według starej definicji staje się retrospektywnie błędna i nie można stwierdzić z zestawu danych, które elementy były oceniane według której wersji.
Zamrożenie oznacza, że wersja obowiązująca w momencie otwarcia partii rządzi tą partią. Ulepszenia mają zastosowanie do następnej. Każda etykieta wtedy nosi wersję, która ją wyprodukowała, co sprawia, że zestaw danych jest audytowalny rok później, gdy ktoś pyta, dlaczego dwa podobne elementy są oznaczone inaczej.
Jak należy postępować z zgłoszoną niejasnością?
Jako raport o wadzie twojej rubryki, czym właśnie jest. Adnotator, który zgłasza zamiast zgadywać, postępuje dokładnie właściwie i nigdy nie powinien być za to karany.
Platformy, które karzą za zgłaszanie, otrzymują mniej zgłoszeń i gorsze dane, ponieważ niejasność nie znika, tylko zostaje rozwiązana po cichu i niespójnie tam, gdzie nikt tego nie widzi.
Inne pytania
Co sprawia, że rubryka adnotacji jest dobra?
Wyraźne traktowanie przypadków brzegowych. Adnotatorzy rzadko nie zgadzają się co do jasnych przykładów, więc rubryka, która składa się głównie z definicji i niewielu przypadków brzegowych, będzie produkować niespójne etykiety.
Czy rubryka powinna być zmieniana w trakcie projektu?
Nie. Zamroź ją, gdy partia się rozpoczyna, aby standard nie mógł się zmieniać, i zastosuj ulepszenia do następnej partii. W przeciwnym razie poprawnie wykonana praca staje się retrospektywnie błędna.
Co powinno się stać, gdy adnotator zgłasza niejasny przypadek?
Powinno to być traktowane jako wada rubryki i rozwiązane wyraźnie. Karanie za zgłaszanie po prostu spycha niejasność pod ziemię, gdzie jest rozwiązywana niespójnie.