Правила написання анотації, якими насправді слідують анотатори
Дізнайтеся, як написати чіткі, ефективні рекомендації щодо анотації для наборів даних машинного навчання — структуру, просту мову, дерева рішень, оброблені приклади і документацію щодо крайових випадків.
Більшість анонімних робіт не збереглися
Правила анотації не спрацьовують з однієї з трьох причин: вони надто нечіткі, щоб дати послідовні рішення, надто довгі, щоб їх було уважно прочитано, або надто абстрактні, щоб застосувати їх до реальних прикладів. Результатом є велика незгода між анотатором, дороге судження і шумні тренувальні дані.
Писання рекомендацій, яких анотатори фактично дотримуються, є навичкою письма - зокрема, навичкою написання інструкцій, які є однозначними, пропорційними і ілюстрованими правильними прикладами.
Структурний підхід
Добре структурований документ з рекомендаціями щодо анотації має передбачуваний шаблон. Анотатори, які читали багато рекомендацій, навчаються керувати цією структурою; відхилення від неї додає когнітивний навантаження.
| Section | Purpose |
|---|---|
| Overview | The task in two to three sentences: what is being labelled, and why |
| Label schema | The complete list of possible labels with definitions |
| Decision procedure | Step-by-step instructions for applying each label |
| Worked examples | Fully annotated examples for each label, including borderline cases |
| Edge cases | Specific scenarios that require special handling, with guidance |
| Frequently asked questions (FAQ) | Answers to questions from annotator calibration sessions |
Визначає, які функції виконуються
Визначення міток повинні бути необхідними і достатніми — вони повинні включати кожен випадок, до якого застосовується мітка, і виключати кожен випадок, до якого вона не застосовується.
** Слабке визначення (надто широке): **
- “Позначте як ПОСИВНИЙ будь- який текст, який виражає хороші почуття.” *
Це не вдається, тому що «хороше відчуття» є суб’єктивним, включає іронію і не відрізняє настрої до продукту від настроїв до неповязаних тем.
Сильне визначення:
“Позначте як ПОВІДОМЛЕНО, коли автор явно виражає задоволення, схвалення або похвалу за продукт або послугу, описані в огляді, використовуючи мову, яка вказує на справжню позитивну оцінку.”
Ключовий словник для написання визначення:
| Phrase | Usage |
|---|---|
| ”applies when” | Introduces the condition for using a label |
| ”does not apply when” | Introduces exclusion criteria |
| ”regardless of” | Signals that a factor should be ignored |
| ”even if” | Introduces a condition that does not change the label |
| ”in cases where X and Y both apply, prefer X” | Resolves label conflicts |
Дерева рішень
Для завдань з більш ніж двома мітками або мітками з перетинаючимися умовами дерево рішень зменшує кількість помилок більше, ніж сам текст.
Добре сформовано дерево рішень для анотації:
- Використовує так/ні питання, а не відкриті
- Є детермінованим — кожен шлях веде до точно однієї мітки
- Обробляє ** розрив рівності ** явно
- Вказує на точне збігнення з обробленими прикладами
Приклад структури:
Does the text contain a direct comparison to a competitor?
→ YES: Does it claim superiority?
→ YES: label as COMPARATIVE_POSITIVE
→ NO: label as COMPARATIVE_NEUTRAL
→ NO: Does it describe a product feature?
→ YES: label as FEATURE_DESCRIPTION
→ NO: label as OTHERНайбільш поширений вид — звичайний плющ
Більшість рекомендацій включають занадто мало прикладів і не включають достатньо межових. Анотатори погоджуються на чітко визначених випадках без прикладів. Їм потрібні рекомендації щодо країв — випадків, коли дві позначки здаються однаково застосовними.
Для кожної мітки включити:
- Один чіткий позитивний приклад — “Це позначка, і ось чому.”
- Один чітко негативний приклад — “Це НЕ мітка, хоча вона може на неї схожа.”
- Один граничний приклад — *“Це близько до X і Y. Ми називаємо його X, тому що…”
Приклад межі є найціннішим. Він документує рішення комітету по важкому випадку і запобігає анотаторам від розділення на одних і тих же випадках неодноразово.
Принципи мови простих інструкцій
Інструкції повинні бути зрозумілі для анотаторов з різними рівнями експертизи. Застосуйте ці принципи:
- ** Використовуйте активний голос для інструкцій. ** * “Позначте речення” * не * “Речення має бути позначене.” *
- ** Використовуйте короткі речення. ** Намагайтеся не використовувати більше 25 слів на одне речення інструкції.
- ** Визначте терміни при першому вживанні. ** Не приймайте, що анотатори мають спільний словник.
- ** Уникайте подвійних від’ єктів. ** * « Не позначати як від’ єкт, якщо … » * складніше обробляти, ніж * « Позначати як від’ єкт, лише якщо … » *
- ** Використовуйте послідовну термінологію. ** Якщо ви називаєте щось « діапазоном », називайте його « діапазоном » повністю — не змінюйте його на « сегмент » або « ділянку тексту »
Адміністративний центр — смт
Розділ краю випадків передбачає найпоширеніші джерела незгодні. Його побудовано на основі питань, які виникають під час сеансів калібрування анотаторів.
Форматувати кожен регістр краю як:
** Країнний випадок: ** [Опис сценарію] ** Настанови: ** [Ясна інструкція] ** Приклад: ** [Конкретний приклад з правильною міткою] ** Обґрунтування: ** [Коротке пояснення, чому було обрано цей підхід]
Приклади анотації Guideline Sentences
- “Позначте як ENTAILMENT, коли гіпотезу можна логічно вивести з попередження — тобто, якщо попередження істинне, гіпотеза також повинна бути істинною.”
-
- “Не застосовуйте мітку ШКОДЛИВО до гіпотетичних сценаріїв, описаних у вигаданому контексті; зарезервуйте її для вмісту, який може спричинити шкоду у реальному світі.” *
-
- “Якщо анотатор не впевнений, що робити з НЕЙТРАЛЬНИМ і НЕГАТИВНИМ, краще використовувати НЕЙТРАЛЬНИЙ — це завдання спрямоване на виявлення хибно негативних результатів, а не хибно позитивних.” *
- “Цей приклад обговорювався під час калібрування і був класифікований як BORDERLINE_ POSITIVE; анотатори не повинні витрачати більше 30 секунд на випадки, які здаються схожі — застосовуйте BORDERLINE_ POSITIVE і йдіть далі.”
- “Наступний приклад ілюструє поширену помилку: анотатори часто позначають сатиричну похвалу як ПОСІТИВНУ, але сатира не відображає справжніх почуттів і повинна бути позначена як ІРОНІЧНА.”
Випробовувати свої здібності
Перед тим, як розгорнути рекомендації для повного набору анотацій, запустіть сеанс калібрування з трьома- п’ ятьма анотацій на спільному вибірці з 50- 100 елементів. Обчислити каппу Коена. Будь-яка вимірність з kappa нижче 0,6 сигналізує про проблему визначення або інструкції, а не проблему анотатора.
Перегляньте рекомендації — не навчання анотатників — і запустіть калібрування знову.
Заборона на використання англійської мови: для не-англомовних користувачів
Написання ефективних рекомендацій щодо анотації є надзвичайно складним завданням. Це не просто опис того, що потрібно анотувати; це передавання інформації таким чином, щоб її було легко зрозуміти, незалежно від чогось першої мови або рівня професійного володіння англійською. Багато розробників, які вивчають нюанси технічного спілкування, мають освіту, де точна термінологія і формальне формулювання менш підкреслені, що може призвести до правил, які є занадто неясними, надто складними або просто заплутаними. Розглянемо звичайний сценарій: запит на витягнення, який описує зміни до набору даних класифікації зображень. У рекомендації може бути сказано щось на зразок: « Переконайтеся, що всі зображення правильно позначено відповідною семантичної категорією ». Хоча це технічно коректне речення, у ньому бракує важливого контексту для людини, англійська мова якої не повністю розвинена у професійному середовищі.
Ключовим є перейти від абстрактних термінів і засновати ваші інструкції на конкретних прикладах і доступній мові. Задумайтеся про те, як ви поясните завдання колегі — комусь, хто може покладатися на візуальні підказки і чіткі пояснення, а не відразу зрозуміти кожну дрібницю у словнику. Наприклад, замість « забезпечити точне мітки », спробуйте: « Під час класифікації зображень, будь ласка, оберіть * найкращу * категорію зі спадного меню. Якщо зображення не вписується в одну категорію, оберіть найближчий варіант — ми обговоримо це з вами пізніше.» Цей підхід використовує простіші структури речень і підкреслює дії, які можна виконати. Зверніть особливу увагу на дієслова; «забезпечити» можна замінити більш прямими інструкціями, такими як «вибрати» або «вибрати»
Крім того, передбачити потенційні нерозуміння, пов’ язані з англійськими ідіомами або фразами, які часто використовуються у документації з розробки програмного забезпечення. Такі терміни, як «краєвий випадок», «надійність» або «регресійне тестування» можуть бути особливо викликом для носіїв, які не є рідними. Не приймайте за звичне; замість цього надайте чіткі визначення. Наприклад, «країнний випадок це ситуація, яка може не траплятися часто, але все ж може викликати проблеми, якщо система не підготовлена. Уявіть собі рідкісний сценарій — можливо, зображення з незвичайним освітленням або дуже маленький об’ єкт, який частково затемнено. » Ви можете навіть додати до цих пояснень візуальні засоби, діаграми, які чітко ілюструють цю концепцію. Пам’ятайте, ясність і повторення - ваші друзі тут.
Нарешті, використовуйте канали Slack для прямого спілкування. Розробник може приватно повідомити старшому анотатору в Slack: «Я не впевнений, як позначити це зображення — воно частково затемнене листям. Чи краще вибрати « дерево » чи « рослинність »?» Цей негайний зворотній зв’ язок є безцінним для роз’ яснення очікувань і вирішення будь- яких мовленнєвих бар’ єрів, які можуть виникнути. Заохочуйте анотаторів ставити питання — * завжди * — і створіть підтримуюче середовище, де вони відчуватимуть себе комфортно, шукаючи пояснення без страху судження. Документування цих типових сценаріїв у самих рекомендаціях, з ілюстративними прикладами, може значно поліпшити розуміння і, в кінцевому рахунку, підвищити якість анотації.