От Джереми Шаму, Хорди Мас, инженеры-менеджеры, Виктор Кодина, специалист по данным, и Саша Веррье, инженер по данным.

Введение

Adevinta начала путь машинного обучения (ML) много лет назад, когда еще была частью Schibsted. Инициативы по машинному обучению были реализованы как на наших торговых площадках, так и в глобальных командах. Со временем мы вложили средства в обучение наших людей, создали возможности для ускорения разработки решений машинного обучения и внедрили методы управления данными.

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

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

  • кластер Kubernetes (см. статью), который мы используем для запуска наших сервисов прогнозирования
  • собственная экспериментальная платформа под названием Houston
  • Юникрон (Common Runtime Environment), который позволяет выполнять распределенное выполнение обучающих заданий.
  • брокер конфиденциальности для управления запросами на снятие и удаление конфиденциальности от пользователей

В этой статье мы сосредоточимся на опыте двух команд: Personalization, которая создает рекомендательные системы (RS), обслуживающие 800 миллионов рекомендаций в месяц, и Cognition, команда, которая специализируется на распознавании изображений, обрабатывая 220 миллионов изображений в месяц.

Общие знания

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

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

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

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

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

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

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

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

Соблюдение правил конфиденциальности

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

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

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

Регулирование GDPR также запрещает различным сайтам обмениваться личными данными, а также создавать модели ML без соответствующей правовой основы. При создании объявлений пользователи загружают данные (например, заголовок, изображения…), которые затем используются торговой площадкой для улучшения своих продуктов. Проблема в том, что пользователи обычно не дают согласия на другие торговые площадки, и мы, как обработчики данных, не можем изменить это соглашение, а это означает, что любое решение, построенное на основе этих данных, должно быть доставлено только на ту торговую площадку, с которой поступают данные. . В результате, когда мы строим модели машинного обучения, нам необходимо обучать модели с конкретными данными для каждого рынка в каждой стране.

Есть несколько решений этой проблемы:

  • Создание конвейера, который автоматизирует наш процесс построения моделей, чтобы иметь возможность легко создавать модели, поскольку нам нужно создавать разные модели для каждого рынка и варианта использования.
  • Использование синтетических наборов данных для обучения наших моделей глубокого обучения. Например, вместо того, чтобы использовать реальные изображения автомобилей, чтобы найти автомобильный номер или даже прочитать его, мы считаем, что можем создавать эти изображения из 3D-моделей автомобилей.
  • Использование наборов данных с открытым исходным кодом для построения моделей, доступных в Интернете, с учетом того, что не все наборы данных разрешены для коммерческого использования.

Сложность поля

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

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

Точно так же экосистема машинного обучения все еще развивается, и найти правильный инструмент может быть непросто. Инженерам необходимо постоянно адаптировать, тестировать, давать сбои и часто заменять инфраструктуру. Несколько лет назад Spark работал на кластерах Hadoop, и Луиджи был главным организатором. Теперь Spark работает на Kubernetes, а Argo намного проще настроить для большинства конвейеров. Между тем, разные компании запустили десятки других оркестраторов с другими возможностями (например, MLFlow, Kubeflow и т. д.). Этот конкретный пример можно распространить на все остальные аспекты продуктов машинного обучения, как описано здесь.

Разрыв между оффлайн и онлайн алгоритмическими оценками

Прогнозирование ценности для бизнеса, которую будет иметь алгоритмическое усовершенствование, может быть сложной задачей. Часто значительные алгоритмические улучшения, основанные на показателях точности в автономном режиме, не превращаются в более высокую ценность для бизнеса в соответствии с результатами онлайн-тестирования A/B. Это в основном из-за существующего разрыва между двумя настройками оценки.

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

С другой стороны, при A/B-тестировании бизнес-показатели рассчитываются на основе того, как алгоритмы работают в онлайн-среде, и поэтому они ближе к прогнозированию фактического влияния на бизнес. Здесь основным ограничением является продолжительность эксперимента, так как на завершение каждого эксперимента и анализ результатов уходят недели.

Чтобы преодолеть разрыв между офлайн- и онлайн-метриками, команда персонализации работает над двумя разными направлениями:

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

В будущем мы планируем изучить новые методы для получения объективных оценок показателей и использовать методы обучения с подкреплением для имитации A/B-тестирования в автономном режиме.

Изучение предметной области

Обучение системам рекомендаций по строительству

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

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

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

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

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

Обучение моделям визуального распознавания

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

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

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

Будущее направление

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

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

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