Советы Даниэля! Как инженеры Google улучшили обучающий набор данных?

Сравнение времени, затрачиваемого на данные и модели в промышленности и научных кругах

Этот слайд из выступления Андрея Карпаты на Train AI действительно запал мне в душу! Он прекрасно отражает разницу между исследованиями в области глубокого обучения и реальным производством. Научные статьи почти полностью сосредоточены на новых и улучшенных моделях, а наборы данных обычно выбираются из небольшой коллекции общедоступных архивов. Но, с другой стороны, каждый реальный пользователь, с которым я контактировал, изо всех сил пытается внедрить глубокое обучение в реальные приложения и проводит большую часть своего времени, работая с обучающими данными.

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

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

Из-за нехватки места я не могу перечислить все выводы, сделанные мной при наблюдении за производственными системами. Но мы можем начать с примера с открытым исходным кодом и рассказать о похожей производственной модели. В прошлом году я создал простой пример распознавания речи для TensorFlow. Оказалось, что у меня нет готового набора данных, который я мог бы использовать для обучения модели из коробки. Благодаря щедрости многих добровольцев я собрал 60 000 аудиоклипов с односекундными фразами — еще раз спасибо команде AIY за помощь в запуске сайта Open Speech Recording. Используя эти данные, я построил набор моделей. К сожалению, хотя у этой модели есть определенные функции, показатель точности не так хорош, как я ожидал. Чтобы понять свои ограничения как дизайнера моделей, я начал соревноваться на Kaggle, используя тот же набор данных. Конкуренты работали намного лучше, чем моя простая модель, а несколько команд улучшили точность до более чем 91% при использовании различных подходов. Для меня это означает что-то принципиально неправильное с самими данными. На самом деле конкуренты нашли довольно много ошибок, таких как неправильные метки или обрезанный звук. Это побудило меня сосредоточиться на выпуске новых наборов данных и большего количества образцов для решения различных реальных проблем, с которыми они столкнулись.

Я просмотрел метрики ошибок в поисках наиболее распространенных проблем с моделью и обнаружил, что категория «другое» (т. е. речь была распознана, но соответствующий словарь отсутствует в ограниченном словаре модели) появляется чаще всего. Чтобы решить эту проблему, я увеличил количество захваченных слов, стремясь предоставить больше доступных обучающих данных.

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

Чтобы помочь другим пользователям использовать этот набор данных (и учиться на своих ошибках), я собрал все в документ Arxiv и обновил результаты точности. Самый важный вывод заключается в том, что без изменения модели или тестовых данных наивысший показатель точности улучшился более чем на 4% — с 85,4% до 89,7%. Это, безусловно, значительное улучшение, и отзывы действительно выше, когда люди используют эту модель в демонстрационном приложении на Android или Raspberry Pi. На мой взгляд, улучшение качества набора данных, несомненно, более очевидно, чем время, затраченное на настройку модели.

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

Это может показаться ерундой, но ваш первый шаг должен заключаться в случайном просмотре ваших тренировочных данных. Скопируйте часть файла на свой локальный компьютер и часами просматривайте его содержимое. Если вы планируете работать с изображениями, используйте средство поиска MacOS для прокрутки различных эскизов, чтобы быстро просмотреть тысячи изображений. Для аудио вы можете использовать функцию предварительного просмотра воспроизведения Finder или отображать случайные фрагменты в виде текста в терминале. Я не тратил достаточно времени на предварительный просмотр набора речевых данных, поэтому участники Kaggle обнаружили много проблем с данными.

Я нахожу этот процесс глупым, но я не жалею об этом. В конце концов, когда я делаю свою работу, я всегда нахожу что-то важное для данных, включая несбалансированное количество примеров по категориям, поврежденные данные (файлы PNG, помеченные расширением JPG), неправильную маркировку и даже неожиданные ассоциации. Том Уайт сделал несколько удивительных открытий во время тестирования ImageNet, когда понял, что этикетка «солнцезащитные очки» на самом деле относится к «конденсатору» — древнему устройству для концентрации солнечного света; «мусоровоз» означает изображение на главной странице; а «плащ» соответствует женский образ нежити. Ручная классификация Андреем изображений в ImageNet также дала мне очень важные идеи, в том числе о том, как различать разные типы собак, что до сих пор является непростой задачей даже для людей.

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

Не тратьте слишком много времени на выбор модели. Если вы занимаетесь классификацией изображений, выберите AutoML, если нет — воспользуйтесь библиотекой моделей TensorFlow или коллекцией примеров Fast.AI, которые предоставляют модели, действительно решающие вашу проблему. Другими словами, самое главное — как можно скорее начать итерацию, т. е. тестировать свою модель на реальных пользователях как можно раньше и чаще. Вы всегда можете улучшить модель и получить за счет этого лучшие результаты, но получение данных — это первый шаг. Глубокое обучение по-прежнему следует базовому вычислительному принципу «мусор на входе, мусор на выходе», поэтому даже самые качественные модели будут напрямую зависеть от качества обучающего набора данных. Выбрав модель и протестировав ее, вы сможете понять наличие этих недостатков и исправить их.

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

Существенное различие между работой по построению моделей для исследовательских и производственных сценариев заключается в том, что исследование обычно начинается с четко определенной постановки задачи, с другой стороны, практические прикладные требования существуют только в сознании пользователя. разработчиков со временем. Например, для Jetpac мы хотели иметь возможность отображать как можно больше хороших фотографий в нашем автоматизированном путеводителе по каждому городу. Поэтому мы начали просить оценщиков загрузить несколько фотографий, которые, по их мнению, были «хорошими». Однако в итоге мы получаем много улыбающихся портретов, и это то, что они подразумевают под словом «хорошо». Мы поместили это в макет продукта и проверили реакцию пользователей — оказалось, что они не были впечатлены и не нашли отклика. Чтобы решить эту проблему, мы скорректировали вопрос так: «Вызывает ли это фото людей желание пойти туда, где оно показано?» Это сделало наш контент лучше, но по-прежнему существовали огромные различия в том, как его понимали разные группы. Рабочие в Юго-Восточной Азии явно предпочитают фотографии со встреч — люди в больших отелях, одетые в формальную одежду и держащие бокалы с вином. Это явно понятное недоразумение, и целевая аудитория в США просто чувствует себя подавленной и не хочет идти после просмотра этих изображений. В конце концов, шесть членов команды Jetpac вручную оценили более 2 миллионов изображений, потому что мы лучше, чем кто-либо, знаем критерии.

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

Я обнаружил, что единственный способ гарантировать правильность решения проблемы — это смоделировать приложение — невозможно полагаться только на модель машинного обучения для зацикливания. Мы иногда называем этот метод «Волшебником страны Оз», потому что за кулисами также есть наставники. По-прежнему используя Jetpac в качестве примера, мы позволяем людям вручную выбирать фотографии для путеводителя (вместо обучения модели) и используем отзывы пользователей для корректировки критериев, которые мы используем для выбора изображений. Как только мы сможем надежно получить положительные отзывы от тестирования, мы сможем преобразовать полученные правила выбора фотографий в сценарий маркировки, который обрабатывает миллионы изображений из обучающей выборки. После этого кадры обучили модель, способную предсказывать качество миллиардов фотографий, но, в конце концов, ДНК этой окончательной модели была установлена ​​задолго до того, как мы разработали первоначальные ручные правила.

В Jetpac изображения, которые мы используем для обучения модели, имеют тот же источник (в основном из Facebook и Instagram), что и изображения, которые мы применяем в модели, но общая проблема, которую я обнаружил, заключается в том, что набор данных для обучения в значительной степени отличается от фактического. входной набор данных в производственных сценариях. Например, я часто вижу команды, которые хотят использовать изображения ImageNet для обучения моделей только для того, чтобы обнаружить, что результаты их моделирования просто не могут решить проблемы, с которыми сталкиваются дроны или роботы в реальных сценариях. Это происходит потому, что ImageNet — это в основном фотографии, сделанные людьми, и эти фотографии, как правило, имеют много общих характеристик. Например, люди снимают с помощью мобильного телефона или камеры, используют средний план, кадрируют снимок примерно на высоте головы, обычно снимают при дневном или искусственном освещении и указывают на объект, который находится в центре и на переднем плане. Напротив, роботы и дроны используют для кадрирования видеокамеры, в которых обычно используются объективы с высоким полем зрения, а место съемки может быть на земле или в воздухе.Условия освещения, как правило, плохие, и невозможно грамотно кадрировать какие-либо объекты. . Эти различия означают, что простое обучение модели на изображениях из ImageNet и передача результатов на дрон или робот никогда не достигнет ожидаемого уровня аналитической точности.

Обучающие данные также могут незначительно отличаться от того, что видит реальное приложение. Например, вы разрабатываете камеру, которая распознает диких животных, и обучаете ее наборам данных о животных со всего мира; если вы собираетесь использовать камеру только в джунглях Борнео, у изображений пингвинов в наборе данных мало шансов совпасть. изображения из реальной жизни; тогда, если бы данные для обучения включали фотографии Антарктиды, модель могла бы принять других животных за пингвинов. Чтобы уменьшить вероятность таких ошибок, заранее удаляйте такие изображения из набора данных.

Существует несколько способов калибровки результатов на основе существующих предварительных критериев (например, резкое снижение вероятности появления пингвинов в джунглях), но более удобным и эффективным способом является использование обучающей выборки, отражающей то, с чем на самом деле сталкивается продукт. Лучший подход, который я нашел, — это всегда использовать данные, полученные непосредственно из реальных приложений, что хорошо сочетается с подходом «Волшебник страны Оз», о котором я упоминал выше. Участников проекта следует попросить разработать метки для исходного набора данных, даже если начальное количество меток невелико, они, по крайней мере, отражают реальность и, как правило, достаточны для переноса обучения для начальных экспериментов.

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

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

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

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

Визуализация кластеризации, чтобы увидеть, как сеть анализирует обучающие данные, — один из моих любимых способов. TensorBoard обеспечивает хорошую поддержку этого метода анализа; хотя визуальная кластеризация часто используется для просмотра встраивания слов, я считаю, что она применима практически к любому уровню операции встраивания. Например, сети классификации изображений часто имеют предпоследний слой перед последним полностью подключенным или softmax-модулем, который можно использовать в качестве встраивания (таким образом работает простой пример переноса обучения, такой как TensorFlow For Poets). Это не строго встраивания, так как во время обучения нет конвейера, обеспечивающего идеальные пространственные свойства, которые можно ожидать в истинных слоях встраивания, но кластеризация их векторов дает интересные результаты.

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

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

Кластеризация может дать вам представление о том, что находится в вашем обучающем наборе, предоставляя те же преимущества, что и просто просмотр данных. Но нейронная сеть на самом деле классифицирует входные данные в соответствии со своим собственным обучением и пониманием, чтобы помочь вам изучить анализ. Как люди, мы очень хорошо замечаем аномалии невооруженным глазом, поэтому сочетание нашей интуиции и способности компьютера обрабатывать большие объемы входных данных обеспечивает хорошо масштабируемое решение для определения качества наборов данных. Здесь нет места для полного руководства по использованию Tensorboard для такого рода задач (эта статья достаточно длинная, спасибо, что остаетесь с читателем!), но если вы серьезно относитесь к улучшению своих показателей вывода, я настоятельно рекомендую ознакомиться с этим. инструмент.

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

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

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

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

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

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

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

Оригинальная ссылка:

https://petewarden.com/2018/05/28/why-you-need-to-improve-your-training-data-and-how-to-do-it/