Контролен списък с неща, които могат да се объркат и как да ги поправите

Етикетирането на данни за НЛП, подобно на летенето на самолет, е нещо, което изглежда лесно на пръв поглед, но може леко да се обърка по странни и прекрасни начини. Да знаете какво може да се обърка и защо са добри първи стъпки за откриване и коригиране на грешките.

Етикетирането на данни за НЛП е нещо, което изглежда лесно на пръв поглед, но може леко да се обърка по странни и прекрасни начини. Да знаете какво може да се обърка и защо са добри първи стъпки за откриване и коригиране на грешките.

В LightTag създаваме „инструменти за анотиране на текст“ и работим в тясно сътрудничество с нашите клиенти, за да разберем какво се случва в техните усилия за анотиране и как нашият продукт може да им помогне да получат етикетирани данни по-бързо и с по-високо качество. В тази публикация ще споделим четири често срещани проблема, които възникват в анотациите на субекти за НЛП, ще обсъдим тяхната първопричина и възможните решения.

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

Може би най-често срещаният източник на несъгласие с анотаторите е непоследователното етикетиране на крайни и водещи бели интервали и пунктуация. Това означава, че единият анотатор може да обозначи „Тал Пери“, а другият ще обозначи „Тал Пери“ или „Тал Пери“ или „Тал Пери“. Този проблем се появява и със завършващи препинателни знаци като „Тал Пери“.

Когато се измерва съгласието на анотатора или се взема решение за златен източник на анотация, тези конфликти водят до по-ниски резултати за съгласие и неяснота в златния набор. Тези грешки са особено разочароващи, тъй като анотацията е концептуално правилна и човек наистина не би забелязал или се интересува от разликата.

Всъщност тази тънкост е основната причина за този вид грешки. Обикновено вашите анотатори не се интересуват от това как вашите алгоритми изчисляват съгласието и няма да забележат или да се интересуват от разликата между „Тал Пери“ „Тал Пери“, освен ако изрично не бъде казано да го направи.

В това отношение решението е просто, вашият инструмент за анотиране трябва визуално да показва на анотаторите, когато са уловили завършващи и водещи бели интервали и да им позволи да решат дали това е правилно според насоките, които сте задали.

Анотации за влагане

Друг често срещан източник на несъгласие са „Вложените анотации“. Например фразата „Президентът на Съединените щати Доналд Тръмп“ може да бъде обозначена по няколко различни начина.

Причината за този вид грешка е фундаментална, езикът е йерархичен по природа, а не линеен, така че линейните анотации, като подчертаване на интервали, не винаги пасват идеално.

От гледна точка на UX, просто решение е да позволите на анотатора да създава вложени анотации, като например в „Brat“ или „анотиране на дървовидни структури“. Докато тези решения работят от UX гледна точка, те изискват модели надолу по веригата, които могат да се справят с тези сложни, нелинейни структури както във входа, така и в изхода на модела.

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

Добавяне на нови типове обекти по средата

В ранните етапи на проект за анотация често ще откриете, че имате нужда от типове обекти, които не са били очаквани. Например, наборът от тагове за чатбот за пица може да започне с таговете „Размер“, „заливка“ и „напитка“, преди някой да разбере, че имате нужда и от таг „Гаринира“, за да заснемете чеснов хляб и пилешки крилца.

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

Педантичното решение е да започнете отначало и да сте сигурни, че всички етикети са уловени. Това обаче е много разточително, започването отначало всеки път, когато имате нужда от нов етикет, е по-малко от желаното използване на ресурси. Добра среда е да започнете отначало, но да използвате съществуващите анотации като „предварителни анотации“, които се показват на анотатора. Например, „инструментът за текстови анотации“ на LightTag ви позволява да правите точно това, показвайки предварителни анотации на анотатора, които те могат да приемат с едно натискане на бутон. Оттам те могат да се съсредоточат върху добавянето на нови тагове.

Дълги списъци с етикети

Един сигурен начин да увеличите разходите по проекта и да понижите качеството на данните е да принудите вашите анотатори да работят с много дълги списъци от тагове. Известно е, че ImageNet има 20 000 различни категории като ягоди, балон с горещ въздух и куче. В текст споделената задача SeeDev 2019 дефинира „само“ 16 „типа обекти“, показани тук, но можете да видите как те бързо стават непосилни.

В процеса на анотиране увеличаването на броя на изборите, които анотаторът трябва да направи, ги забавя и води до лошо качество на данните. Трябва да се отбележи, че разпределението на анотациите ще бъде повлияно от това как са подредени таговете в UX на анотациите. Това се дължи на „пристрастието към наличността“, при което за нас е много по-лесно да разпознаем концепции, които са на първо място (Налични в главите ни).

Imagenet със своите 20 000 категории е изключителен пример за този проблем и си струва да прочетете „доклада за това как са събрани анотациите“. Тяхната методология се състоеше от разбиване на задача за анотиране на по-малки задачи, при което всяка подзадача анотатор ще анотира един екземпляр от някакъв клас (а други работници ще имат отделни задачи за валидиране). Това значително намалява когнитивното натоварване на анотатора, като им помага да работят по-бързо с по-малко грешки.

Заключение

Етикетирането на данни трябва да се извършва бързо в мащаб и с висока точност, без нито едно от тях да компрометира другото. Първата стъпка в създаването на качествен тръбопровод за анотации е предвиждането на общи проблеми и приспособяването към тях. Тази публикация показа четири от най-често срещаните грешки, които възникват в проектите за текстови пояснения, и как „инструментите за текстови пояснения като LightTag“ могат да помогнат за разрешаването им.

За автора

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