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

Авторы: Шицзин Яо, Дапенг Ли, Шон Чен

Вступление

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

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

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

Обнаружение удобств

От типовых к индивидуальным решениям

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

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

Несмотря на то, что служба API способна обнаруживать определенные удобства, предсказанные метки слишком расплывчаты. В компании по совместному использованию жилья, такой как Airbnb, знание того, что посуда присутствует на картинке, не говорит нам ничего, кроме типа комнаты. Точно так же нам не поможет знание того, что на картинке есть таблица. Мы не знаем, что это за стол и для чего его можно использовать. Наша актуальная цель - понять, обеспечивают ли обнаруженные удобства удобство для гостей. Могут ли гости готовить в этом доме? У них есть особая посуда, которую они хотят? Есть ли у них обеденный стол приличного размера, чтобы вместить достаточно людей, если это семейная поездка? Более желательный результат обнаружения удобств будет выглядеть примерно так, как показано ниже.

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

Помимо стороннего API, проекты с открытым исходным кодом, такие как Tensorflow Detection Model Zoo и Detectron Model Zoo, также предлагают коллекцию бесплатных предварительно обученных моделей обнаружения объектов с использованием различных наборов данных общедоступных изображений и различных архитектур моделей. Мы протестировали различные предварительно обученные модели из Модельных зоопарков. Точно так же результаты также не соответствовали нашему требованию. Точность была значительно ниже, и некоторые предсказанные метки были просто далекими.

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

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

Определение таксономии

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

Не имея предыдущего опыта, мы решили начать с того, над чем люди работали раньше, надеясь найти какой-нибудь намек. Мы обнаружили, что Open Image Dataset V4 предлагает огромное количество данных изображений. Он включал около 9 миллионов изображений, которые были аннотированы метками уровня изображения, ограничивающими рамками объектов (BB) и визуальными связями. В частности, аннотации BB охватывают богатый набор из 600 классов объектов. Эти классы образуют иерархическую структуру и охватывают широкий спектр объектов. На самом высоком уровне они включали Животное, Одежда, Транспортное средство, Еда, Строительство , Оборудование, Инструмент и набор предметов домашнего обихода, например Мебель, Техника и Товары для дома. . Наша цель состояла в том, чтобы найти классы объектов, относящиеся к удобствам, и отфильтровать остальные.

Мы вручную проверили 600 классов и выбрали около 40 классов, соответствующих нашему варианту использования. Как правило, это были важные удобства на кухне, ванной, и спальне, например газовая плита, духовка. , холодильник, ванна, душ, полотенце, кровать, подушка и т. д. Open Image Dataset V4 сэкономил нам много времени. Если бы мы начали с нуля, построение одной разумной таксономии заняло бы у нас много времени.

Создание набора данных изображения

После определения таксономии следующим шагом будет сбор данных изображения на ее основе. Open Image Dataset V4 содержал 14,6 млн BB, аннотированных в 1,7 млн ​​изображений. В идеале мы могли бы получить из него большое количество образцов изображений, поскольку наша таксономия была в основном подмножеством полных 600 классов. Однако, углубившись в данные, мы обнаружили, что 600 классов объектов сильно разбалансированы. У некоторых классов были миллионы экземпляров, а у других - всего несколько.

40 интересующих нас классов в основном попали в меньшинство (справа) в распределении меток классов, показанном выше. В результате у нас осталось всего 100 тыс. Экземпляров объектов, аннотированных примерно из 50 тыс. Изображений - примерно 3% от всего набора данных. Мы значительно переоценили объем имеющихся данных!

Современные модели обнаружения объектов почти полностью основаны на глубоком обучении, а это означает, что для хорошей работы им требуется много обучающих данных. Общее практическое правило состоит в том, что несколько тысяч образцов изображений на класс могут обеспечить достойную производительность модели. 50 тыс. Изображений, аннотированных 40 классами объектов, подразумевали в среднем 1,2 тыс. Изображений на класс, что было достаточно, но не очень хорошо. Поэтому мы решили добавить некоторые внутренние данные и объединить их с общедоступными данными. Чтобы убедиться, что внутренний набор данных включает богатые, разнообразные и равномерно распределенные классы удобств, мы выбрали 10 000 изображений для спальни, ванной, кухни и гостиная каждая и дополнительные изображения размером 1 КБ для сцен на открытом воздухе, таких как бассейн, вид и другие для каждого.

Создание аннотаций

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

В этом проекте мы выбрали службу маркировки данных Google, в которой нам очень понравились три вещи: 1) поддержка до 100 классов объектов для маркировки, 2) приятный и чистый пользовательский интерфейс, с помощью которого мы могли отслеживать ход работы по маркировке, и 3) обратная связь. и нам постоянно присылали вопросы по мере продвижения работы по маркировке. В результате мы смогли сделать расплывчатые инструкции четкими и устранить крайние случаи на протяжении всего процесса.

Одна из важных стратегий заключалась в отправке небольших пакетов данных, прежде чем наращивать объемы данных. Таким образом, вы получаете возможность исправить инструкции по маркировке и снабдить большую часть ваших данных аннотациями в улучшенной версии. По нашему опыту, мы обнаружили, что некоторые удобства были повсеместными и менее полезными (например, шторы, окна) в этих небольших партиях результатов. Мы удалили их соответственно и уточнили нашу таксономию с 40 классов до 30. После этого мы полностью аннотировали наши данные примерно за две недели.

Модельное обучение

Объединив помеченные 43 тыс. Внутренних изображений и 32 тыс. Общедоступных изображений, мы получили 75 тыс. Изображений, аннотированных 30 настраиваемыми объектами удобств. Пришло время построить модель!

Мы попробовали два пути построения модели. Один из путей заключался в использовании API обнаружения объектов Tensorflow - создание tfrecords на основе данных аннотированного изображения, использование model_main.py для начала обучения и работает Tensorboard для отслеживания прогресса обучения. Было много онлайн-руководств о том, как это сделать. Здесь мы опускаем большую часть деталей и цитируем только наш любимый.

В частности, мы выбрали две предварительно обученные модели для точной настройки: ssd_mobilenet_v2 и fasten_rcnn_inception_resnet_v2. ssd_mobilenet_v2 был быстрым, но с меньшей точностью, а Fast_rcnn_inception_resnet_v2 был противоположным. Чтобы настроить эталонный тест, мы проверили точность обеих предварительно обученных моделей на 10% удерживаемых данных (7,5 тыс. Изображений с 30 классами объектов) перед точной настройкой. В качестве показателя мы используем среднее значение средней точности (mAP), которое является стандартом для оценки модели обнаружения объектов. Он измеряет среднюю точность (AUC кривой точность-отзыв) модели по всем классам объектов и находится в диапазоне от 0 до 1. Более подробная информация объясняется здесь .

ssd_mobilenet_v2 достиг mAP 14%, а Fast_rcnn_inception_resnet_v2 достиг mAP 27 %. Внимательный читатель может обнаружить, что результаты наших тестов для этих двух предварительно обученных моделей были намного ниже, чем указанные на веб-сайте mAP: 36% для ssd_mobilenet_v2 и 54% для fast_rcnn_inception_resnet_v2. Это было правильно. В нашем тестовом наборе было всего 30 классов, все из которых были меньшинством в наборе данных, где была обучена предварительно обученная модель. Снижение точности для предварительно обученных моделей было связано с изменением распределения классов между обучающими и тестовыми наборами.

Чтобы начать обучение на нашем наборе данных, мы заморозили параметры в слоях извлечения признаков и сделали обучаемыми только полностью связанные слои. Первоначальная скорость обучения по умолчанию была 8e-4 для ssd_mobilenet_v2 и 6e-5 для Fast_rcnn_inception_resnet_v2. Поскольку мы выполняли переносное обучение, мы снизили скорость обучения до 10% от значений по умолчанию. Обоснованием было то, что мы не хотели делать слишком большое обновление градиента, чтобы «уничтожить» то, что уже было изучено в предварительно обученных весах модели. Мы также уменьшили количество шагов обучения с 10M до 1M и масштабировали соответствующие параметры затухания в графике скорости обучения. Что касается вычислительных ресурсов, для обучения использовался экземпляр AWS p2.xlarge с одноядерным графическим процессором Tesla K80.

При обучении ssd_mobilenet_v2 функция потерь вначале очень быстро уменьшалась. Однако после 100 тыс. Шагов (5 дней) улучшение стало незначительным, и функция потерь начала колебаться. Неуверенные, имеет ли смысл продолжать тренировку, мы прекратили тренировку через 5 дней, потому что прогресс в любом случае был слишком медленным. Точность модели (mAP) увеличилась с 14% до 20%.

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

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

Другой способ построения модели - использование автоматизированного инструмента самообслуживания. Мы попробовали Google AutoML Vision. Удивительно, но результаты были очень впечатляющими. Просто загрузив 75 тысяч аннотированных изображений и нажав несколько кнопок, мы смогли обучить модель обнаружения объектов за 3 дня. Мы выбрали более высокую точность в меню самообслуживания, поэтому обучение длилось дольше, чем обычно.

Оценка модели

Мы решили использовать модель, обученную AutoML. Модель достигла mAP около 68% на основе нашей автономной оценки при 10% удерживаемых данных (7,5 тыс. Изображений). Результат значительно выше всех показателей, которые мы видели до сих пор. Некоторые классы показали особенно хорошие результаты, такие как Туалет, Бассейн и Кровать, и все они достигли 90% + средняя точность. Худшими показателями были классы крыльцо, винный шкаф и джакузи. Мы обнаружили, что средняя точность каждого класса объектов сильно коррелировала с его распространенностью в обучающих данных. Следовательно, увеличение обучающих выборок для этих классов меньшинств, вероятно, значительно улучшит производительность этих категорий.

В нашей автономной оценке мы также обнаружили, что mAP весьма чувствителен к разделению на обучение и тест. Другое разделение из-за простой статистической случайности может привести к смещению на 2–3%. Основная нестабильность mAP исходила от классов меньшинств, где размер выборки был очень маленьким. Мы рекомендуем использовать медианное значение AP всех классов для смягчения этой проблемы.

Развертывание модели и онлайн-обслуживание

Развертывание модели в AutoML также было чрезвычайно простым - всего одним щелчком мыши. После развертывания модель была превращена в онлайн-сервис, которым люди могли легко пользоваться через REST API или несколько строк кода Python. Количество запросов в секунду (QPS) может варьироваться в зависимости от количества часов развернутого узла. Однако большим недостатком AutoML было то, что вы не могли загрузить созданную вами исходную модель. Это была потенциальная проблема, и мы решили вернуться к ней в будущем.

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

Как видите, наша модель значительно более конкретна и обеспечивает гораздо более широкий охват этих 30 классов объектов. Более количественное сравнение нашей модели и сторонней модели в этой демонстрации требует некоторых внимательных размышлений. Во-первых, наша таксономия отличается от сторонней модели. При вычислении mAP мы должны учитывать только пересечение двух наборов классов. Во-вторых, сторонний API показывает только частичные результаты, поскольку любые прогнозы с достоверной оценкой менее 0,5 были бы отфильтрованы и не наблюдались бы нами. Это в основном обрезает правую часть кривой точность-отзыв их результатов, где отзыв высокий (а порог низкий), и, таким образом, снижает mAP их результатов. Чтобы провести честное сравнение, мы должны усечь наши результаты, удалив также обнаружения с оценкой менее 0,5. После обработки мы подсчитали, что «усеченное» mAP для нашей модели составило 46% и 18% для них. Действительно отрадно видеть, что наша модель может значительно превзойти по производительности стороннюю модель от ведущего в отрасли поставщика. Сравнение также демонстрирует, насколько важны предметно-ориентированные данные в мире компьютерного зрения.

За пределами обнаружения удобств

Обнаружение объектов в широком диапазоне

В дополнение к обнаружению удобств, обнаружение объектов с более широким охватом является еще одной важной областью, в которую мы инвестируем. Например, Airbnb использует множество сторонних онлайн-платформ для рекламы объявлений. Чтобы предоставлять легитимную рекламу, мы должны убедиться, что отображаемые фотографии не представляют чрезмерной угрозы конфиденциальности или безопасности для нашего сообщества. Используя обнаружение объектов с широким охватом, мы можем выполнять необходимую модерацию контента, чтобы такие вещи, как оружие, большие человеческие лица и т. Д., Не подвергались воздействию без защиты. В настоящее время для этого мы используем сервис Google Vision. Мы также создаем настраиваемую систему обнаружения под названием Telescope, которая при необходимости может выполнять действия с изображениями с дополнительными опасными объектами.

Контроль качества изображения

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

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

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

Заключение

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

  1. В эпоху глубокого обучения данные становятся намного важнее модели. Чтобы решить проблему как специалист по данным, вы, вероятно, потратите 90% своего времени на сбор и анализ больших объемов данных.
  2. Будьте изобретательны при сборе данных и не изобретайте велосипед. По возможности используйте общедоступные данные сообщества открытого исходного кода и при необходимости интегрируйте их с вашими личными данными.
  3. Пока не произойдет прорыв в алгоритмах неконтролируемого обучения, получение высококачественных меток для ваших данных почти всегда является наиболее важным шагом для контролируемой модели. Пометка ваших данных также часто является наиболее трудоемким процессом, поскольку между организациями может потребоваться много усилий по координации. Планируйте заранее и с умом выбирайте поставщика аннотаций.
  4. Использование хорошего инструмента машинного обучения может значительно ускорить обучение и развертывание вашей модели, что ускоряет предоставление вашей модели как услуги.
  5. Будьте непредубежденными. Не бойтесь начать с простого решения, даже если это обычный сторонний API. Это может не решить вашу бизнес-проблему сразу, но, скорее всего, приведет к успешному решению когда-нибудь позже.

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

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

Эта работа ведется в сотрудничестве со многими командами по экспериментам с продуктами. Мы хотели бы поблагодарить Юйци Чжэн, Сяньцзюнь Чжана, Ичжэн Ляо, Роберта Чанга, Цзин Ся , Дэвид Стауб, Рен Догерти, Юаньпей Цао, Чжэньи Ли, Рунцзе Чжан , Мишель Ду и Бо Цзэн за множество ценных экспериментальных испытаний продукта. Мы также хотели бы поблагодарить разработчиков библиотек с открытым исходным кодом, таких как Tensorflow Object Detection API, Open Images Dataset V4 (теперь V5) и Cartucho. Наконец, мы благодарим Сяохана Цзэна за его корректуру и Рида Андерсона за постоянную поддержку этого проекта.