Привет! Меня зовут Ирина Кротова, я NLP-исследователь из компании MTS AI. Мы не понаслышке знаем, что сбор и разметка данных часто становятся “бутылочным горлышком" в проектах, связанных с машинным обучением. У нас в компании есть постоянная необходимость в разных видах разметки аудио, текста и изображений.

Более того, мы видим, что количество областей, где ещё можно применить ML, постоянно растёт, но при этом появление новой задачи совершенно не значит, что вместе с ней сами собой возникнут качественные данные для обучения.

С развитием нейросетей стало немного легче: меньше времени уходит на конструирование признаков (feature engineering), но для обучения и тестирования больших моделей требуются колоссальные объемы данных по сравнению с классическим ML. И даже при дообучении больших языковых моделей на более узкие задачи всё равно требуются размеченные данные, особенно в индустрии.

В области обработки естественного языка (Natural Language Processing, NLP) к общим сложностям добавляется ещё и тот фактор, что языковые ресурсы представлены неравномерно: если для китайского, арабского или английского языков легко найти готовые датасеты и решения, то для малоресурсных языков (low-resource languages) количество доступных данных и предобученных моделей существенно ниже.

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

Разметка текстовых данных — тема, в которой сложно охватить все аспекты за один раз, поэтому я разбила текст на несколько частей, которые буду выкладывать постепенно.

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

Зачем разбираться в аннотации данных?

Частая история: начинающий разработчик машинного обучения видит задачу и фокусируется в первую очередь на том, какой алгоритм выбрать и как добиться наилучшего качества работы модели.

Это логично, потому что большинство курсов по машинному обучению построены в первую очередь вокруг моделирования: как правильно поставить задачу, тренировать модель, оценивать качество её работы и искать баги. Датасет, как правило, просто существует, в лучшем случае требуя некоторой предобработки.

В академических исследованиях примерно та же история: если мы посмотрим на статьи по машинному обучению, то увидим, что учёные соревнуются на примерно одних и тех же стандартных бенчмарках (например, SuperGLUE) пытаясь улучшить подходы предшественников и достичь SOTA (state-of-the-art) решения.

В индустрии данные редко бывают статичными, так как мир постоянно меняется. Сегодня пользователей интересует чемпионат по футболу, а завтра — коронавирус. Требуются регулярное обновление как моделей, так и датасетов. Качество данных критически влияет на качество моделей, а процесс сбора и разметки датасетов содержит множество подводных камней. Andrej Karpathy, бывший директор Tesla AI, где команда in-house разметчиков в 2021 году насчитывала свыше тысячи сотрудников, писал в своём твиттере, что даже через четыре года процесс разметки данных не достиг идеала и требовал дальнейшей работы.

В идеальном мире на вопрос "Сколько нужно данных?" можно просто ответить: "Чем больше, тем лучше". И отправить размечаться всё, что есть, а потом получить с первого раза качественный результат и начать эксперименты с моделями.

В реальности получить качественную разметку не всегда просто, возникают сложности и ограничения:

• Бюджет. Независимо от того, есть ли in-house команда разметки в штате компании или же задания отдаются на краудсорсинговые платформы (Яндекс.Толока, Amazon Mechanical Turk), каждый эксперимент с разметкой требует бюджета. Для интереса можно попробовать рассчитать стоимость разметки данных в Mechanical Turk в калькуляторе. После подсчетов хочется снизить если не количество самой разметки, то хотя бы число неудачных попыток.

• Время. Нельзя записать 10 часов голоса для обучения модели меньше, чем за 10 часов. Чем более сложная задача для разметки, тем больше времени требуется для ее выполнения: отобрать изображения с пальмами проще, чем разметить данные, требующие профессиональной экспертизы (юридической, медицинской). В исследованиях часто бывает, что бюджета на разметку нет, и исследователь сам размечает некоторое количество данных, чтобы проверить какую-то гипотезу (например, для магистерского диплома). Это всё тоже увеличивает затраты на проект.

• Персональные данные. В индустрии датасеты иногда содержат пользовательские данные. Возникает вопрос: как разметить тексты, но при этом не нарушить конфиденциальность и закон? В таком случае требуется либо качественная анонимизация (вот как, например, это в общем виде делают в Google), либо доступ к in-house разметке. Последняя встречается в основном в крупных компаниях, у которых есть ресурсы для найма разметчиков в штат.

• Качество разметки. Далеко не факт, что получится хорошо разметить данные с первого раза. Тот, кто хоть раз пробовал делать разметку самостоятельно, знает, что процесс довольно монотонный и утомительный. В разметке возникают ошибки и из-за усталости разметчика, и из-за сложности или неоднозначности заданий, и из-за недобросовестности исполнителя (устал, нажал последние 50 примеров наугад). Приходится следить за качеством, менять задания, иногда даже целиком переформулировать задачу.

Для участника хакатона или соревнования, где данные предоставляют сами организаторы, это не очень важно. Но если посмотреть на жизненный цикл модели и датасета с высоты птичьего полёта, возникают вопросы:

• Как сократить количество ручной разметки?

• Как повысить её качество?

Как размечать меньше данных?

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

Получаем метки естественным путём

Возможно, вы — счастливый разработчик, в чьём проекте уже есть пользователи. Тогда ручная разметка и открытые датасеты — не единственный источник данных.

Пользователи приложения дают много обратной связи прямо в процессе взаимодействия и генерируют natural labels, "органические" метки.

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

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

Например, если пользователь пишет отзыв на книгу или фильм, и помимо публикации текста интерфейс позволяет поставить оценку или проставить теги, как на сайте GoodReads, а потом использовать эти данные для оценки тональности отзывов:

Метки можно получать, собирая фидбек от пользователей чат-бота. Его источником могут быть и прямые просьбы оценить взаимодействие, как в примере ниже, так и, например, то, как быстро и после каких реплик пользователь перестаёт общаться с чат-ботом или просит позвать оператора.

Важно учитывать контекст, чтобы сбор фидбека не был слишком навязчивым или неуместным, иначе можно получить обратную реакцию.

Например, бот создан для технической поддержки пользователей, у которых возникли проблемы с соединением. Если человеку, у которого только что сорвалось собеседование по зуму, прилетает анкета из десяти вопросов в стиле "как вам наш чат-бот?", шанс собрать полезные метки не очень высок.

В моей работе был проект, связанный с извлечением информации из юридических документов. Извлеченные сущности "подсвечивались" в интерфейсе прямо в тексте документа. В нашем случае юрист валидировал извлеченную из контрактов информацию перед тем, как окончательно сохранить результат в базу.

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

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

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

Weak supervision: используем обучение со слабым контролем

Основная идея этого метода в том, что эксперты при разметке данных опираются на разнообразные эвристики. Например:

• "Если предложение занимает три строки, то это сложное предложение из нескольких основ";

• "Если в отзыве встретилось слово "супер", то у товара самая высокая оценка";

• "Если в тексте страницы договора встречается слово "Арендодатель", то это договор аренды".

Один из самых популярных открытых библиотек для такого подхода — Snorkel, разработанный лабораторией Stanford AI. Про опыт его использования уже писал мой коллега Игорь Буянов.

Идея фреймворка крутится вокруг функций для разметки (LFs, labeling functions), которые пишутся как раз на основе эвристик, как в примерах выше. Можно придумать разметочные функции, используя существующие базы данных, выдачу других моделей (например, простых классификаторов), поиск по ключевым словам.

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

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

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

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

Генерируем себе данные

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

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

Back Translation

Один из простых способов получить перефразированные тексты — использовать машинный перевод.

Идея метода довольна простая:

1. Текст на исходном языке (L1) переводится на любой другой язык (L2).

2. Текст переводится обратно с языка L2 на L1.

3. Удаляем полученные дубликаты.

В чем может возникнуть проблема?

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

Например:

Или другой перевод с помощью Google Translate:

Такие предложения можно отфильтровать, посчитав близость между эмбеддингами (например, с помощью LaBSE) и удалив данные, превышающие порог, либо разметив подозрительные примеры вручную.

Но в любом случае задача "Являются ли эти два предложения близкими по смыслу?" на порядок легче для разметчика, чем задание "Перефразируйте этот текст разными способами".

ChatGPT

В 2023 году нельзя не упомянуть новые диалоговые модели, такие как LaMDA или ChatGPT. В сети уже сотни гайдов по написанию промтов к ChatGPT, и, конечно, можно использовать её для перефразирования текстов и генерации данных.

Простой пример использования ChatGPT для генерации реплик пользователя:

Это, конечно, далеко не все способы аугментации данных. Если хочется разобраться подробнее, особенно рекомендую обзор Steven Feng от 2021 года и его же выступление.

Используем активное обучение

Идея активного обучения состоит в том, чтобы выбирать для доразметки и дообучения модели те данные, которые с наибольшей вероятностью повысят качество модели.

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

Ещё один возможный подход, query-by-committee — использовать несколько похожих моделей (например, обученных на разных частях датасета) и отбирать те примеры, где между ними возникает наибольшая несогласованность (прямо как с разметчиками).

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

Тема активного обучения очень обширная, в первую очередь порекомендую классический обзор “Active Learning Literature Survey” (Settles 2010).

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

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