Bootstrapping Labels via ___ Supervision & Human-In-The-Loop

eugeneyan

Начать здесь Статьи Выступления Прототипирование Об авторе

Бутстрэппинг меток через ___-обучение и Human-In-The-Loop

[ teardown machinelearning ] · 12 мин чтения

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

Тогда их придётся собирать. Сбор обучающих меток — редко обсуждаемое искусство. Представьте, что вы мониторите соцсети на нежелательный контент: как получить метки для тонких концептов вроде дезинформации о COVID-19, терроризма или кибербуллинга? Или представьте, что вам нужно разметить корпус книжных отзывов по тому, говорят ли они о качестве, цене или стиле письма — с чего начать?

В этой статье мы обсудим полу-, активное и слабое обучение и рассмотрим примеры двух последних подходов из DoorDash, Facebook, Google и Apple.

Полу-обучение с учителем: генерация псевдо-меток

При полу-обучении с учителем мы комбинируем небольшое количество размеченных вручную данных с большим объёмом неразмеченных данных в процессе обучения. Вот пошаговый процесс:

Обучить высокоточную модель на размеченных данных. Сделать предсказания на неразмеченных данных. Отобрать наиболее уверенные предсказания как псевдо-метки и добавить их к обучающим данным. Обучить новую модель на метках и псевдо-метках. Повторять, пока не наберётся достаточно высокоуверенных псевдо-меток.

Мне не попадались статьи о применении полу-обучения в индустрии. Тем не менее, оно часто используется на соревнованиях Kaggle (например, псевдо-метки из тестового датасета добавляются как обучающие данные). Вот пример решения, занявшего 4-е место с применением полу-обучения для тегирования аудио. (Также см. статью Google о том, как злоумышленники могут «отравить» неразмеченные примеры и заставить модели, обученные через полу-обучение, ошибаться в классификации.)

Активное обучение: поиск примеров для human-in-the-loop

При активном обучении мы отбираем наиболее «интересные» неразмеченные примеры для разметки через human-in-the-loop (HITL). Один из способов их идентификации — uncertainty sampling, при котором выбираются примеры с максимальной неопределённостью в предсказаниях модели. Например, если модель — бинарный классификатор, uncertainty sampling выбирает примеры, для которых предсказанная вероятность близка к 0.5. Query-by-committee расширяет uncertainty sampling несколькими моделями: примеры, по которым модели расходятся, считаются наиболее информативными и выбираются.

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

У точки A максимальная неопределённость, у B — сочетание неопределённости и information density (источник)

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

Workflow активного обучения в DoorDash: автоматические шаги выделены зелёным, HITL-шаги — красным (источник)

Затем к стартовым данным применялась аугментация данных: находились неразмеченные примеры, близкие к размеченным (по edit distance и косинусной близости эмбеддингов), и добавлялись в обучающую выборку. Также использовалась случайная текстовая аугментация — варьировался порядок предложений в описании пункта и случайно удалялась информация (например, категории меню). При обучении использовалось соотношение 100 синтетических примеров на один размеченный.

Для каждой группы атрибутов (например, региональная кухня, вкус) обучались однослойные многоклассовые LSTM с FastText word embeddings. На вход подавались названия пунктов, категории меню и полнотекстовые описания. Они также пробовали multi-task модели, но те показали себя хуже — сэмплирование не сохраняло реальное распределение тегов, а данных было слишком мало для обучения только на размеченных. Тем не менее, по мере накопления размеченных данных производительность multi-task моделей улучшалась.

Для отбора большего числа примеров на аннотирование они ориентировались на precision и recall. Для улучшения precision выбирались примеры, похожие на те, где предсказание модели расходилось с меткой аннотатора. Для улучшения recall модель предсказывала на неразмеченных данных, и выбирались примеры с низкой уверенностью. Отобранные примеры отправлялись на Mechanical Turk для первого прохода; более неоднозначные — профессиональным аннотаторам для второго прохода.

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

Facebook добавил к активному обучению поиск по похожести в качестве фильтра (Similarity Search for Efficient Active Learning and Search, или SEALS). Они отметили, что данные часто сильно перекошены — релевантна лишь малая доля (например, 1 из 1 000 или меньше). Поэтому перед активным обучением они применяют nearest neighbors к положительным меткам. Использование nearest neighbors как фильтра уменьшает число рассматриваемых неразмеченных примеров и повышает эффективность аннотирования.

Они проверили это на датасетах ImageNet и OpenImages. На ImageNet SEALS показал результаты, сопоставимые с базовыми подходами с полным supervision (то есть с полной разметкой), при всего 2 000 меток на концепт — лишь 5% от общего числа кандидатов на аннотирование. На OpenImages им удалось сопоставить активное обучение, рассматривая лишь часть данных.

Nearest neighbors обеспечил сопоставимую с активным обучением производительность при 2–15% данных (источник)

Слабое обучение: быстро получить много меток более низкого качества

Слабое обучение комбинирует знания из нескольких источников данных, чтобы быстро и эффективно получить много меток, хотя и более низкого качества. Источники включают labeling functions, формализующие эвристики через regex или агрегированную статистику (data programming), а также готовые ресурсы — базы знаний, альтернативные датасеты или предобученные модели. Хотя метки от слабого обучения могут быть менее точными, чем размеченные вручную, их качества достаточно для приличной производительности.

Google рассказали, как они применили слабое обучение через Snorkel DryBell. Система использует labeling functions, которые принимают точки данных и либо возвращают метку, либо воздерживаются. Labeling functions могут операционализировать эвристики об источнике или содержании данных. Они также могут опираться на внутренние модели (например, разработанные внутри topic models, named-entity recognizers) или графы (например, пользовательские графы или графы сущностей для извлечения меток). Вот пример шаблона labeling function.

Шаблон labeling function на C++ (источник)

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

Вот обзор Snorkel DryBell. Разработчики пишут labeling functions на основе эвристик, существующих моделей (например, внутренние NLP- и topic-модели) или ресурсов организации (например, графы знаний). Snorkel DryBell применяет эти функции к неразмеченным примерам, затем их выход и сами функции подаются в генеративную модель. Модель комбинирует их и возвращает вероятностные метки для использования в продакшен-системах.

Обзор Snorkel DryBell, выделенный синими пунктирными линиями (источник)

Система использовалась в двух кейсах: классификация тем и классификация продуктов. Для классификации тем разработчик написал 10 labeling functions с эвристиками на основе связанного URL (URL-based), кастомных моделей named-entity recognition (NER-tagger-based) и внутренних topic models (topic model-based). Для классификации продуктов использовалось восемь функций на основе ключевых слов в контенте (keyword-based), переводов ключевых слов на 10 языков через граф знаний (graph-based) и семантических моделей для отсева контента, не связанного с интересующими категориями продуктов (model-based).

В обоих кейсах Snorkel DryBell имел более высокую предсказанную точность, чем модели, обученные напрямую на небольшом размеченном вручную dev-сете (который также использовался для формулирования labeling functions, подбора гиперпараметров и т.д.). Чтобы сравняться с производительностью Snorkel DryBell, потребовалось бы 80 000 размеченных вручную примеров для классификации тем и 12 000 — для классификации продуктов.

Apple также представила похожую систему (Overton). Когда создаются новые признаки или выявляются качественные баги, инженеры могут добавить дополнительный supervision через data programming или другие эвристики. Также отслеживается lineage каждого источника информации. Они отметили, что есть продакшен-системы вообще без традиционных размеченных обучающих данных, что важно для приложений, чувствительных к приватности.

Есть и другие примеры слабого обучения в индустрии: бутстрэппинг conversational-агентов в IBM и слабое обучение на несбалансированных задачах извлечения в Intel. Facebook также рассказал о диалоговом обучении с human-in-the-loop.

Также критично: инструкции по разметке и креативное мышление

Недооценённый аспект сбора размеченных данных — определение инструкций по разметке. Хотя такие задачи, как разметка порнографии или языка ненависти, могут быть относительно прямолинейны, как определить инструкции для дезинформации о COVID-19? Она может смешивать правду о COVID-19 с ложью о вакцинах или быть нюансированной сарказмом. Даже Tesla, у которой одна из самых продвинутых систем разметки данных для поддержки Autopilot, не решила все проблемы.

Даже спустя 4 года я так и не «решил» воркфлоу разметки. Разметка, QA, финальный QA, авто-разметка, поиск ошибок, балансировка разнообразия, документация и версионирование, обучение людей, эскалации, чистка данных, статистика throughput и качества, eval-сеты + категоризация и boosting, ... — Andrej Karpathy (@karpathy) 8 июля 2021

DoorDash поделились советами по разработке хороших инструкций для тегов:

Сделать теги взаимоисключающими (без пересечений): это позволяет аннотаторам переходить дальше, если у примера уже есть тег, и снижает объём разметки. Разделить таксономию на верхнем уровне по различным атрибутам (например, региональная кухня, вкус и т.д.): это позволяет распараллеливать задачи аннотирования. Обеспечить наличие тега «Другое» на каждом уровне: это позволит позже пересмотреть «Другое» и улучшить гранулярность (вместо прохода по всем тегам). Сделать теги объективными: теги вроде «популярный» или «удобный» субъективны и могут меняться со временем.

Также полезно мыслить шире, чем HITL-разметка или полу-/активное/слабое обучение. Попробуйте креативно искать метки в пользовательских данных. Если мы хотим разметить книги по различным атрибутам по их содержанию (например, Россия, Fae и т.д.), посмотрите, как пользователи организуют свои книжные полки на GoodReads. Названия этих полок можно использовать как weak-метки для затравки тегов.

Альтернативно — можно начать с подходов, не требующих пользовательских данных. Как построить семантический поиск без меток взаимодействия пользователей? Один из вариантов — начать с лексических подходов, таких как BM25 или того, что доступно в ElasticSearch или Solr. После запуска можно собирать данные о пользовательских взаимодействиях (например, клики, покупки) по результатам поиска, и использовать их как метки для моделей семантического поиска.

Другие подходы для рассмотрения: краудсорсинг от пользователей (например, лайки/дизлайки рекомендаций или результатов поиска), генерация синтетических данных (например, VAEs, GANs), label propagation через графы или transfer learning с использованием моделей, обученных на других задачах.

Как бутстрэпить метки на разных стадиях зрелости

Получение меток для систем машинного обучения — скорее искусство, чем наука. Не существует прямолинейного пошагового рецепта; всё зависит от назначения (например, у пользовательских меток требования выше, чем у внутренних) и типа данных (например, события возможного мошенничества, диалоги чат-бота, видео для self-driving). Тем не менее, вот примерная эвристика — когда какой подход применять в зависимости от зрелости ML-систем.

На самой ранней стадии можно применять слабое обучение. Сюда входят labeling functions на основе keyword-based regex, статистических агрегаций, графов знаний, сегментации пользователей и т.д. При необходимости можно применять HITL для верификации меток, прежде чем использовать высокоуверенные метки для обучения моделей.

С наличием стартовых данных можно перейти к полу-обучению. Можно обучить высокоточную модель для предсказаний на неразмеченных примерах, затем добавить псевдо-метки с наивысшей уверенностью в обучающую выборку. Или попробовать активное обучение (например, nearest neighbors + uncertainty sampling/information density) для выявления меток с наибольшей неопределённостью для HITL перед добавлением в датасет.

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

Также учитывайте зрелость самих меток. Даже в зрелых ML-системах метки нельзя использовать сразу — они могут меняться со временем. Например, покупка, засчитанная как конверсия, может быть возвращена в течение 14-дневного окна возврата, а изначально легитимная транзакция может оказаться мошеннической. Использование преждевременных или некорректных меток ведёт к порочным петлям обратной связи: модель учится на неверных метках и делает ошибки предсказания, которые усугубляют ошибки ground truth.

Пропустил ли я какие-то ключевые техники бутстрэппинга меток? Напишите мне и расскажите!

Многие статьи и туториалы по машинному обучению стартуют с размеченных датасетов. Но что, если меток нет? Как их собрать? Здесь мы обсуждаем полу-обучение, активное обучение и слабое обучение для бутстрэппинга меток для вашей ML-системы. https://t.co/RvsgXCFlIK — Eugene Yan (@eugeneyan) 4 августа 2021

Спасибо Lim Wen Qing и Nihit Desai за указание на отличные ресурсы. Также спасибо Nihit Desai и Samuel Flender за обратную связь.

Если статья оказалась полезной, цитируйте её так:

Yan, Ziyou. (Aug 2021). Bootstrapping Labels via ___ Supervision & Human-In-The-Loop. eugeneyan.com. https://eugeneyan.com/writing/bootstrapping-data-labels/.

или

@article{yan2021labeling, title = {Bootstrapping Labels via ___ Supervision & Human-In-The-Loop}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2021}, month = {Aug}, url = {https://eugeneyan.com/writing/bootstrapping-data-labels/} }

К 11 800+ читателям, получающим обновления по машинному обучению, RecSys, LLM и инженерии.