Контрольный список того, что может пойти не так, и как это исправить

Маркировка данных для НЛП, как и полет на самолете, на первый взгляд кажется легким, но может пойти не так, как ни странно. Знание того, что может пойти не так и почему, - хорошие первые шаги к обнаружению и исправлению ошибок.

Маркировка данных для НЛП - это то, что на первый взгляд кажется простым, но может пойти не так, как ни странно, но и замечательно. Знание того, что может пойти не так и почему, - хорошие первые шаги к обнаружению и исправлению ошибок.

В LightTag мы создаем инструменты текстовых аннотаций и тесно сотрудничаем с нашими клиентами, чтобы понять, что происходит в их усилиях по аннотации и как наш продукт может помочь им получить помеченные данные быстрее и с более высоким качеством. В этом посте мы поделимся четырьмя типичными проблемами, которые возникают в аннотациях сущностей для НЛП, обсудим их первопричину и возможные решения.

Белое пространство

Возможно, наиболее частым источником разногласий аннотаторов является непоследовательная маркировка конечных и ведущих пробелов и знаков препинания. То есть один аннотатор может обозначить «Тал Перри», а другой - «Тал Перри», или «Тал Перри», или «Тал Перри». Эта проблема также появляется с конечной пунктуацией, например «Тал Перри».

При измерении согласия аннотаторов или выборе золотого источника аннотаций эти конфликты приводят к более низким оценкам согласия и неоднозначности в золотом наборе. Эти ошибки особенно неприятны, потому что аннотация концептуально верна, и человек не заметит разницы или не позаботится о ней.

Фактически, эта тонкость является основной причиной ошибок такого рода. Обычно ваших аннотаторов не волнует, как ваши алгоритмы вычисляют согласованность, и они не замечают или не обращают внимания на разницу между «Тал Перри» и «Тал Перри», если это явно не указано.

В этом отношении решение простое: ваш инструмент аннотации должен визуально указывать аннотаторам, когда они захватили конечные и ведущие пробелы, и позволять им решать, правильно ли это в соответствии с установленными вами руководящими принципами.

Вложенные аннотации

Другой распространенный источник разногласий - «Вложенные аннотации». Например, фраза «Президент США Дональд Трамп» может быть обозначена по-разному.

Причина такого рода ошибок является фундаментальной, язык по своей природе иерархичен, а не линейен, и поэтому линейные аннотации, такие как выделение промежутков, не всегда подходят идеально.

С точки зрения UX, простое решение - позволить аннотатору создавать вложенные аннотации, такие как Brat или аннотировать древовидные структуры. Хотя эти решения работают с точки зрения UX, они требуют последующих моделей, которые могут обрабатывать эти сложные нелинейные структуры как на входе, так и на выходе модели.

Среди нашей клиентской базы мы не наблюдали массового внедрения структурированных аннотаций за пределами лингвистического сообщества. В основном это связано с дополнительными моделями и инженерными сложностями, необходимыми для работы с ними. То, что мы обычно видим, - это проекты аннотаций, которые направляют свою команду к аннотированию с наилучшим возможным разрешением и применением постобработки для фиксации внутренней структуры на более позднем этапе.

Добавление новых типов сущностей на полпути

На ранних этапах проекта аннотации вы часто обнаруживаете, что вам нужны типы сущностей, которые не ожидались. Например, набор тегов для чат-бота по пицце может начинаться с тегов «Размер», «топпинг» и «напиток», прежде чем кто-то поймет, что вам также нужен тег «Гарнир» для захвата чесночного хлеба и куриных крылышек.

Простое добавление этих тегов и продолжение работы с документами, которые еще не помечены, представляет опасность для проекта. Новые теги будут отсутствовать во всех документах, аннотированных до того, как были добавлены новые теги. Это означает, что ваш тестовый набор будет неправильным для этих тегов, и ваши обучающие данные не будут содержать новых тегов, ведущих к модели, которая не будет захватить их.

Педантичное решение - начать все сначала и убедиться, что все теги записаны. Однако это очень расточительно: начинать заново каждый раз, когда вам нужен новый тег, - это нежелательное использование ресурсов. Хорошая золотая середина - начать все сначала, но использовать существующие аннотации как предварительные аннотации, которые отображаются для аннотатора. Например, инструмент текстовых аннотаций LightTag позволяет вам делать именно это, показывая предварительные аннотации аннотатора, которые они могут принять одним нажатием кнопки. Оттуда они могут сосредоточиться на добавлении новых тегов.

Длинные списки тегов

Один из надежных способов увеличить стоимость проекта и снизить качество данных - заставить ваших аннотаторов работать с очень длинными списками тегов. Известно, что ImageNet имеет 20 000 различных категорий, таких как Земляника, Воздушный шар и Собака. В тексте общая задача SeeDev 2019 определяет только 16 типов сущностей, показанных здесь, но вы можете видеть, как они быстро становятся подавляющими.

В процессе аннотации увеличение количества вариантов, которые аннотатор должен сделать, замедляет их выполнение и приводит к низкому качеству данных. Следует отметить, что на распределение аннотаций будет влиять порядок расположения тегов в UX аннотации. Это происходит из-за предвзятости доступности, когда нам намного легче распознавать концепции, которые являются главными (доступными в наших головах).

Imagenet с его 20 000 категорий является крайним примером этой проблемы, и стоит прочитать статью о том, как собирались аннотации. Их методология заключалась в разбиении задачи аннотации на более мелкие задачи, в которых каждая подзадача аннотатора аннотировала один экземпляр некоторого класса (а у других работников были отдельные задачи проверки). Это значительно снижает когнитивную нагрузку на аннотаторов, помогая им работать быстрее с меньшим количеством ошибок.

Заключение

Маркировка данных должна производиться быстро в масштабе и с высокой точностью, чтобы ни один из них не ставил под угрозу другой. Первым шагом в создании качественного конвейера аннотаций является предвидение общих проблем и их устранение. В этом посте были показаны четыре наиболее распространенных ошибки, которые возникают в проектах текстовых аннотаций, и то, как инструменты текстовых аннотаций, такие как LightTag, могут помочь их решить.

Об авторе

Тал Перри - основатель и генеральный директор LightTag The Text Annotation Tool for Teams. Он также является экспертом по машинному обучению в Google-разработчиках и, что наиболее важно, отцом Давида и партнером Марии.