Вступление

При онлайн-доставке еды, заказывая еду, клиенты полагаются на предоставленную информацию, которая обычно ограничивается названием и подробным описанием блюда, изображением и вегетарианским ли блюдом. Чтобы еще больше улучшить процесс заказа еды, дополнительная информация о блюде может помочь покупателю в принятии решения, например, какие ингредиенты включены в блюдо или как оно приготовлено. Обработка этой дополнительной информации обычно требует нетривиальных ручных усилий. С изображениями продуктов питания были выполнены многочисленные работы на основе глубокого обучения, которые мы подробно обсуждаем в соответствующем разделе работы. Мы заметили, что существуют существующие модели, которые предоставляют информацию об ингредиентах с учетом изображения блюда, но проблема заключается в распределении данных. Этот документ объясняет различия в ингредиентах в разных регионах и странах, что подразумевает трудности с использованием предварительно обученных моделей в разных кухнях. Следовательно, существует потребность в обработке данных на основе наблюдаемых блюд, характерных для страны, в которой работает бизнес. Существующая работа может помочь с общим подходом, но мы должны курировать наши собственные наборы данных с изображениями и ингредиентами и с учетом имеющихся наборов данных рецептов природы. - Извлечение ингредиентов из самого рецепта из множества источников является сложной задачей. В этом блоге мы пытаемся решить эту проблему, характерную для индийской кухни, и вклад этого блога можно резюмировать следующим образом:
- Система сбора ингредиентов для извлечения информации об ингредиентах из текстовых данных рецептов.
- Достижение Оценка 0,41 F1 для предсказания ингредиентов в нашем наборе данных, что примерно в 5 раз меньше по сравнению с набором данных, используемым в обратной кулинарной бумаге.

Набор данных

Учитывая актуальность и важность ингредиентов, удивительно, что не так много наборов данных об индийских блюдах с изображениями и ингредиентами общедоступны. Насколько нам известно, набор данных IIITD CulinaryDB - единственный набор данных с отображением ингредиентов и блюд, но без изображений. Существуют и другие более крупные наборы данных, такие как Recipe1M + и Food101, но они не имеют высокого индекса для индийских блюд. Поэтому мы готовим набор данных, ориентированных на индийскую еду, с изображениями. Наш набор данных содержит для каждого блюда его изображение, рецепт и ингредиенты, использованные для его приготовления. Далее мы обсудим методы и задачи, которые мы решили во время сбора и подготовки данных.

Сбор и очистка данных

Помимо прямого использования IIITD CulinaryDB, мы также извлекли текстовые данные с веб-сайтов, посвященных индийской кухне. Мы передаем этот
через специально созданный конвейер, который извлекает ключевые атрибуты из необработанных данных.
Поскольку данные были собраны из нескольких разрозненных источников, требуется значительный объем обработки. К ним относятся (но не ограничиваются) обработка специальных символов, нерелевантных фраз, чисел, регистра и т. Д. Например. «Chicken Bar-Be-Que» преобразовано в «шашлык из курицы», «Palak Namakpara - Diwali Special» преобразовано в «palak» намакпара ». Набор правил для обработки этих и других случаев был разработан методом проб, ошибок и итераций. Дублирование данных было еще одной проблемой, с которой нам пришлось столкнуться. В нашем случае были удалены только точные дубликаты, у которых название блюда и набор ингредиентов совпадали. Однако, поскольку одно и то же блюдо может иметь разные стили приготовления с использованием разных наборов ингредиентов, мы решили оставить случаи, когда названия блюд были одинаковыми, но список ингредиентов был другим.
Чтобы собрать изображения для блюд, мы снова воспользовались Интернетом и поисковыми системами. Мы создали многопоточного бота на основе Selenium, который использовал названия блюд для получения соответствующих изображений. Этим методом были собраны изображения для 62К блюд.

Сбор ингредиентов

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

Следующим шагом было создание высококачественного словаря ингредиентов, который, по сути, служит классами, которые будут предсказаны в нашем классификаторе с несколькими этикетками. Чтобы создать этот словарь, мы прибегли к ингредиентам, перечисленным в наборе данных IIITD CulinaryDB, а также к поиску веб-сайтов, ориентированных на ингредиенты. Поскольку данные поступали из разных источников, мы применили различные методы обработки текста для их очистки. Даже после обширной постобработки мы увидели, что у нас по-прежнему слишком много отдельных ингредиентов. Однако мы заметили, что это произошло из-за нескольких «перекрывающихся» ингредиентов, например, хлебных булочек, черного хлеба, булочек из черного хлеба. Мы сделали дизайн, а также сделали прагматичный выбор, чтобы оставить только «базовые» ингредиенты. Для этого мы использовали кластеризацию K-средних. Перед кластеризацией мы лемматизировали ингредиенты, чтобы обеспечить единообразие между токенами, например Leaf, leaves - ›leaf.
Мы сгруппировали по векторным представлениям ингредиентов, поступающих из векторизатора TF-IDF с uni-, bi- и триграммы. Векторизатор TF-IDF создает векторные представления текстовых документов в зависимости от того, насколько слово релевантно документу в коллекции документов. Мы повторили этап кластеризации, завершившийся 325 кластерами. Чтобы создать метки для каждого кластера, мы проанализировали n-граммы каждого ингредиента в кластере и выбрали n-грамм, ближайший к центроиду кластера, в качестве метки для этого кластера. Результаты кластеризации вместе с присвоенными метками можно увидеть на рисунке 2.

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

Обширная итеративная обработка текста завершилась лемматизацией всех токенов, извлечением некоторого количества единиц измерения (например, столовая ложка, чашка и т. Д.). Мы также отмечаем, что наши стоп-слова включали основные ингредиенты, такие как соль, сахар и т. Д. Наконец, мы извлекли ингредиенты из оставшегося текста, используя словарь ингредиентов, созданный ранее. На рисунке 4 показан конечный результат после сбора ингредиентов.

Обратная модель приготовления

В этом разделе мы кратко объясняем модель создания рецепта, которая принимает изображение блюда в качестве входных данных и выводит инструкции рецепта. Эта модель разделена на две основные части: первая предсказывает ингредиенты на основе встраивания изображений, как показано на рисунке 5.a, а вторая - рецепт предсказания, исходя из комбинированного встраивания изображения и встраивания ингредиентов. Идея разделения проблемы на две части заключается в том, что создание рецепта из изображения может выиграть от промежуточного шага, предсказывающего ингредиенты, а затем объединенная информация изображения и ингредиентов поможет в предсказании рецепта. Сначала изображения извлекаются с помощью кодировщика ResNet-50. Он поступает в декодер ингредиентов, который представляет собой модель на основе преобразователя, которая предсказывает ингредиенты в виде последовательности. Преобразователь обрабатывает ингредиенты как список и предсказывает таким же образом до конца последовательности, пока не будет обнаружен токен eos. При таком дизайне модель штрафует за порядок ингредиентов, но поскольку конечная цель состоит в том, чтобы просто получить набор ингредиентов, выходы на разных временных шагах агрегируются с использованием операции max-pool. Кроме того, чтобы гарантировать, что ингредиенты предсказываются только один раз без повторения, для всех ранее выбранных ингредиентов предварительная активация выставляется на -∞. Модель обучается путем минимизации бинарной кросс-энтропии между объединенным выходом и основной истиной.
Вторая часть модели состоит в создании рецепта с использованием предсказанных ингредиентов, а также входного изображения. Прогнозируемые ингредиенты кодируются для создания встраиваемых ингредиентов, которые затем подаются на блоки трансформаторов. Были опробованы три разные стратегии, а именно объединение, независимая и последовательная, чтобы объединить вложения изображений и ингредиентов. Судя по эксперименту, конкатенация вложений показала наилучшие результаты в основном из-за гибкости, позволяющей придавать важность одной модальности по сравнению с другой.
Мы позаимствовали первую часть этой модели для нашего варианта использования. В следующих разделах мы обсудим нашу стратегию обучения, а также производительность модели в нашем наборе данных.

Эксперименты и оценка

Все эксперименты проводились на наборе данных 62K, описанном выше. Мы разделили это на 54027 обучающих, 6759 проверочных и 6740 тестовых образцов. Как отмечалось ранее, окончательный словарь ингредиентов (после кластеризации) содержит 325 уникальных ингредиентов.

Мы использовали общедоступную реализацию модели обратной варки PyTorch и обучили ее с помощью нашего набора данных на 4-ядерной машине Linux с 61 ГБ памяти и графическим процессором Nvidia Tesla K80. Мы обучили модели с помощью оптимизатора Adam, отслеживая потерю валидации.

Наряду с обучением модели обратной кулинарии в нашем наборе данных, мы экспериментировали с включением встраиваемых элементов на основе названия блюда. Эти 128-мерные вложения были изучены отдельно с использованием модели Word2Vec с пропуском грамма на блюдах, заказанных на нашей платформе. Эти вложения затем были объединены с встраиваемыми изображениями с 512 измерениями и прошли через одномерную свертку, чтобы уменьшить размерность с 640 до 512, а затем поданы в декодер ингредиентов, как показано на рисунке 5.b.

Мы оценили модели с точки зрения F1-балла, рассчитанного для накопленного количества истинных положительных результатов (TP), ложных отрицательных результатов (FN) и ложных положительных результатов (FP) по набору тестовых данных из 6740 образцов. В таблице 1 показаны оценки F1 различных вариантов. Мы экспериментировали с ResNet-18 и ResNet-50 в качестве кодировщика изображений, в котором вариант ResNet-50 работал немного лучше. Модель с включенными встраиваемыми названиями блюд не улучшила производительность варианта ResNet-50.

Мы отмечаем, что нам удалось достичь F1-балла 0,41 с примерно в 5 раз меньшим набором данных по сравнению с данными, используемыми в модели обратной кулинарии, где авторы достигли F1-балла 0,49.

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