Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Всем привет! Меня зовут Нина, я работаю в команде платформы для продавцов AliExpress. Сегодня я расскажу о том, как совместно с коллегами из команды Knowledge Engineering мы адаптировали систему для загрузки товаров, чтобы всё работало в пару кликов. Поехали!
Введение
Наша цель – увеличить число малых и средних продавцов на площадке. У таких селлеров обычно немного ресурсов, а значит, им нужно дать самые простые инструменты для загрузки большого количества товаров. Тогда они смогут работать с маркетплейсом эффективнее, тратить меньше времени и зарабатывать больше.
Изначально у каждого продавца товары уже находятся в какой-то своей системе: Битрикс, 1С, Ecwid, Excel, может даже в самописном сервисе. Также у них есть свое дерево категорий и атрибутная модель товаров (набор их категорий и характеристик). При выходе на любой внешний маркетплейс продавец вынужден адаптировать контент под его формат и правила. Это очень затратно и требует много ручного труда.
Мы знаем эту проблему и хотим помочь решить ее, максимально сократив время от выхода на площадку до первой продажи. Но при чем здесь вообще ML?
Загрузка товаров: XML-фиды
Пару лет назад в AliExpress было принято решение использовать технологию XML. Продавцы загружали свои товары с помощью XML-фидов в сервисе AliExpress Assistant.
Основное отличие XML-фидов от Excel: при необходимости загрузить товары сразу во многих категориях (в Excel грузится одна категория за раз) поместить их можно в одном файле. Это серьезно облегчает и ускоряет процесс.
Впоследствии мы анализировали основные источники товаров и поняли, что XML-загрузка – самый популярный у продавцов способ добавления товаров. При всем этом мы получали большое количество обращений в поддержку – в основном у пользователей возникали вопросы по работе с сервисом AliExpress Assistant.
Эта программа была разработана еще китайскими инженерами до начала масштабной локализации продукта для российского рынка. Поэтому мы решили, во-первых, улучшить ее, сделав более удобной для продавцов, а во-вторых, получить полный контроль над ситуацией и создать полностью собственный инструмент.
Постановка задачи
Мы хотели не просто локализовать сервис любой ценой, а сделать действительно удобный продукт. Поэтому перед стартом разработки мы провели исследование того, как на разных ecommerce-сайтах продавцы загружают в систему товары.
В результате исследования мы поняли, что самый популярный способ адаптации контента продавца под требования каждой площадки – это интерфейс сопоставлений. То есть площадка дает набор полей, которые нужны ей, а продавец выбирает соответствующие значения из своего контента. На AliExpress представлено 5 800 категорий, и раньше сопоставления продавец должен был делать вручную. Логично, что в таком объеме легко запутаться, что провоцировало множество обращений в поддержку.
Представьте, что у продавца товары в 100 категориях, у каждой категории по пять характеристик, и в каждой характеристике еще по пять вариаций значений. В этом случае продавцу придется сделать 2 500 ручных сопоставлений и еще 100 сопоставлений для категорий.
Идеально – сделать все сопоставления автоматически. Чтобы продавец указал ссылку на фид с контентом, а всю остальную работу мы сделали за него. Мы поняли, что удобнее всего позволить продавцам просто прикладывать ссылку с фидом и нажимать кнопку «Загрузить» – и всё. Никаких ручных сопоставлений и выбора категорий товара, система должна сама анализировать названия товаров и размечать их в соответствии с разными категориями.
Другая важная тема – это SKU, вариации товара. На AliExpress продавец может создать карточку товара и в ней объединить различные вариации конкретного товара. Например, мы продаем одежду. У нее есть размер, цвет. Здесь товаром является одежда, а размер и цвет – его вариации:
Цена и остаток устанавливаются именно на вариацию товаров. Также именно они участвуют в поиске и фильтрации на витрине, поэтому очень важно корректно заполнять значения. Основные SKU-атрибуты, которые формируют вариации, – это цвет и размер. При этом у продавцов могут быть совершенно уникальные названия цветов (изумрудный, ромашковый, небесный) и обозначения размеров.
Нам нужно было научиться подбирать цвета и размеры автоматически. Нам это удалось: продавец больше не делает этого руками.
Старт работ
Одним из модулей системы для продавцов был так называемый Prediction-сервис. Он мог анализировать XML-фид с товарами и подсказывать список категорий для каждого из них. Далее продавец должен был вручную выбрать наиболее подходящую. При этом категории ранжировались по весам, первой шла наиболее вероятная.
Мы подумали, что есть смысл попробовать просто брать эту первую категорию и автоматически присваивать ее товарам. И если вдруг система ошиблась, человек сможет поправить ее вручную. Даже такая половинчатая автоматизация должна была значительно ускорить загрузку товаров.
Но просто взять и прикрутить этот сервис к новому продукту мы не могли: нужно было проверить, насколько точно он выдает рекомендации. С этой задачей мы пошли к коллегам из команды Knowledge Engineering, и оказалось, что как раз в данный момент для другого проекта они разрабатывают обновленную версию prediction-сервиса.
Собственно, первой пробой пера для нас стала интеграция с одним из наших партнерских сайтов. Качество работы нашего модуля для подбора категорий на этом ресурсе оказалось не на самом высоком уровне. Его хотелось улучшить – и это стало отличным поводом протестировать новый prediction-сервис. Получив обнадеживающие результаты, мы начали работать уже над созданием полноценного нового интерфейса для селлеров «AliExpress Россия».
Не всё так просто: первые проблемы
Уже на старте мы столкнулись с рядом сложностей. Одна из первых – технического характера, связанная с особенностями работы связки Python, FastAPI и Kubernetes. Последний периодически спрашивает сервис о том, жив ли он (т. н. healthcheck), но в первой реализации мы использовали асинхронные методы FastAPI как для ответа на упомянутый вопрос, так и для тяжелых и блокирующих вычислений. Таким образом, сервис во время последних просто не успевал переключиться между методами, а значит, и ответить, что он жив, – и тем самым мог быть «убит». Для таких тяжелых запросов нам пришлось менять логику, чтобы они не блокировали переключение между методами (корутинами).
Также выяснилось, что категоризировать товары только по названию не лучшая идея. Если продавец продает звонок, то он может быть как для велосипеда, так и для квартиры. Футболка может быть мужской, женской или детской. Более того, на ней может быть что-то нарисовано (ножницы).
Многие продавцы продают только футболки и различают их именно по принтам – и по ним же именуют товар. В итоге футболка с ножницами может называться «Ножницы» и ошибочно попасть в соответствующую категорию. Нужно было больше контекста. Чтобы сделать сервис точнее, мы стали учитывать еще и категорию, указанную в файле продавца.
После внесения некоторых правок нужно было провести более серьезное тестирование и понять, насколько точной получается наша система. К сожалению, на тот момент тестовых фидов у нас было не очень много. Анализ пришлось проводить на основе нескольких пользовательских фидов. Их прогнали через первую версию предиктора, его вторую версию, а затем показали результаты категорийным менеджерам компании, ведь именно они обладают эталонными знаниями о категориях на AliExpress.
В итоге мы получили список с вердиктом, посчитали точность первого и второго предикторов. Оказалось, что вся проделанная работа не принесла лучшую точность. Это было странно, и смириться с таким было трудно.
Начали разбираться и поняли два момента. Первый: нам попались очень специфические фиды для тестов. Условно туда попадали слишком нишевые магазины, которые могли продавать только стиральные машинки.
Второй: изначальная модель использовала картинки, потом к ней добавилась часть, анализирующая текст. Но она просто не работала! Система присваивала множеству разных товаров одну и ту же категорию: смартфоном для нее могла стать и бутылка, и джинсы. При этом за счет итерационного улучшения «картиночной» части модели в предикторе второй версии результат категоризации оказался не лучше.
Второй подход: исправление модели, улучшение датасета
На этом этапе пришлось заняться починкой текстовой части модели и ее дообучением. Всё это заняло какое-то время, и при дальнейших тестах оказалось, что использование только «починенной» текстовой модели дает лучший результат, чем ее комбинирование с картиночной.
Также мы сделали второй подход к измерениям. Как мы писали выше, первый подход к тестированию был не очень хорош с точки зрения входных данных. Теперь же мы заранее озаботились сбором большого количества разнообразных фидов с товарами. Этот датасет собирался вдумчиво, был куда более качественным (все категории внутри точно были верными, а товаров было много), так что мы назвали его Golden Dataset.
Сделанные улучшения позволили нам добиться уже действительно заметного роста точности категоризации – она превысила 90%. Теперь нам стало очевидно, что продукт работает. И пользователям он понравился: после анонса только за первую пару недель мы получили несколько сотен новых фидов! Это отличный результат, но работа на этом не заканчивается.
Планы: что еще будем улучшать
Уже в «боевом» режиме работы всплыли некоторые проблемы, которые мы будем решать. Одна из них: наша модель не способна предсказать категорию товара, если он новый и такой категории еще нет в нашей системе. Но она также и не может сказать: «Я не знаю», поэтому, встретив незнакомый товар, пытается найти для него категорию из числа известных.
Иногда товар попадает в список специальных категорий, для торговли в которых нужно специальное разрешение. Это интим-товары, ножи, еда, медоборудование, и если у продавца нет разрешения на продажу таких товаров, то система его заблокирует.
Это не очень приятно, и сейчас мы думаем над решением проблемы. Один из вариантов – в таких случаях показывать уведомление с просьбой подтвердить загрузку или вручную выбрать нужную категорию.
В планах также и улучшения UX, в том числе возможность использовать в нашей модели информацию о бренде товара и присваивать категории на его основе. Ну и хотелось бы все же вернуть в систему улучшенную «картиночную» модель классификации товаров – это должно еще больше повысить точность.
***
На сегодня всё, спасибо за внимание! Буду рада ответить на вопросы в комментариях!
