Товары, покупатели и продавцы. Это основа любой торговой площадки «Клиент для клиента» (C2C). C2C - это модель, в которой конечные пользователи платформы являются клиентами. Они также могут использовать эту платформу как продавец и / или покупатель. Tokopedia, лидер рынка электронной коммерции C2C, из года в год демонстрирует значительный рост. Наша платформа упрощает пользователям поиск и получение желаемого мгновенно. Это также привлекает людей к открытию своего онлайн-бизнеса.

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

Проблемы с продуктом

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

Другая проблема - нарушение условий использования продукта (T&C). Был составлен некоторый набор правил относительно того, какие виды продуктов разрешено продавать с использованием нашей платформы, с учетом законов и постановлений Индонезии. Хотя правила специфичны, есть много продуктов, которые нарушают эти Условия. Наличие запрещенных товаров представляет опасность для наших клиентов и, тем более, для самого общества. Чтобы обеспечить чистую и безопасную среду для всех наших клиентов, нам необходимо регулярно проверять продукты, которые продаются на нашей платформе.

Сначала пойми, потом получше

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

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

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

Разобраться в продукте - непросто

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

Когда мы задаем простой вопрос, что это за продукт с идентификатором 123? Ответ зависит от времени, когда был задан вопрос. Предположим, мы загрузили продукт iPhone X на t0. Через некоторое время мы поняли, что это должен быть чехол для iPhone X. Затем мы изменили название, изображение, описание и цену на t1 и t2. Эти изменения могут происходить бесконечно до тех пор, пока этот продукт не будет удален в tn.

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

Время обработки также отличается от одного вывода к другому. Как правило, вывод по тексту выполняется быстрее, чем по изображению. Если мы будем обслуживать только ML API, он может хорошо справиться с обработкой текста, но может столкнуться с некоторыми таймаутами при прогнозировании изображения. Нам необходимо поддерживать запросы таким образом, чтобы пользователи могли запустить и забыть с API. Запустить и забыть - это механизм, когда пользователям просто нужно один раз нажать на API и позволить себе вернуть результаты после завершения вывода.

Другая проблема исходит от номера запроса. По крайней мере, есть три события, когда будут использоваться наши модели; когда пользователи добавляют продукт в первый раз, когда они редактируют продукт, и когда администратор продукта хочет провести очистку существующих продуктов. В совокупности эти события создают огромный спрос на Request Per Second (RPS), что делает слишком рискованным пропускать запрос через предполагаемый API, неуправляемый с точки зрения выполнения, поскольку мы можем потеряться, решая, какой из них содержит последнее состояние продукта.

Таким образом, мы думаем об экспериментальном шлюзе с задачами по выводу продукта:

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

Мы назвали шлюз Ганеша, и это обзор всего процесса.

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

Внутри Ganesha мы общаемся через очередь сообщений NSQ, чтобы достичь этого стиля выстрелил и забыл. Здесь три основных потребителя: Активный потребитель, Потребитель сборщика знаний и Потребитель средства проверки знаний.

Активный потребитель

Активный потребитель несет ответственность за подписку на событие изменения продукта из активных продуктов (добавление / редактирование темы), незанятых продуктов (расширенная тема) и распространение запроса в предполагаемые API. Вывод API будет обрабатывать каждый запрос с разным временем обработки. Результат будет опубликован в той же теме для подписки следующего потребителя.

Сборщик знаний Потребитель

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

Потребитель средства проверки знаний

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

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

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

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

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

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