Фундаментальная проблема сопоставления заключается в том, что не существует единого источника истины. Существуют миллиарды продуктов, и нет абсолютной структуры, определяющей, как продукты должны быть идентифицированы в разных магазинах. UPC (универсальный код продукта) полезен, но большинство сайтов электронной коммерции не отображают его на страницах отображения своих продуктов. Это подводит нас к следующей проблеме, которая заключается в глубине информации о товарах в разных магазинах. Не у каждого магазина есть правильно оформленные названия, UPC или GTIN, MPN (номер детали производителя) и другие подробные атрибуты, помогающие в сопоставлении. Другой ключевой проблемой является масштаб. У нас есть более 1,5 миллиарда записей о продуктах, и для выявления соответствия данный документ (запись о продукте) необходимо сравнить во всех магазинах.

Например, рассмотрим следующий пример: подбор мужских кроссовок Nike Revolution 3 на Amazon, JCPenney и Zappos.

Скриншот списка товаров с Amazon

Скриншот списка продуктов от JCPenny

Скриншот списка продуктов от Zappos

Названия продуктов на Amazon и JCPenney более похожи по сравнению с Zappos, где в названии не указывается информация о поле и типе продукта. Основные изображения товаров в магазинах также различаются. Таким образом, даже по изображениям машине сложно определить, что эти продукты одинаковы. В этом случае никакой отдельный сигнал не может помочь нам с уверенностью сопоставить эти записи в разных магазинах. Кроме того, для точного соответствия нам потребуется более глубокая информация на уровне варианта, такая как цвет, размер, ширина и пол. Существует также дополнительная проблема отсутствия стандартизированных атрибутов — например, черный цвет представлен как BLK.

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

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

Сигналы сопоставления

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

  • Классификация
  • Заголовок
  • СКП
  • MPN
  • Бренд
  • Изображение
  • Атрибуты варианта

Мы также обрабатываем текст заголовка и описания, чтобы извлечь дополнительные данные о продукте, такие как «размер: 32 ГБ» (из названия) и «размер дисплея: 5,5 дюйма» (из описания). Эти атрибуты также помогают нам в сопоставлении.

Соответствие продукта

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

Как только потенциальные пары совпадений сгенерированы, мы выполняем поиск объединения для создания групп совпадений. Обычно на этом этапе все похожие товары находятся в заданной группе соответствия. Используя автономные алгоритмы, мы генерируем ограничения Must Link (ML) и Cannot Link (CL) между записями продуктов. ML генерируются в случаях, когда сходство документа продукта велико, а CL помогает нам исключить неправильные совпадения. Эти ограничения генерируются на уровне категории, и все они используются в качестве сигналов нашим точным сопоставителем, который генерирует окончательный набор групп соответствия. . В основном мы используем RocksDb и Scalding для сопоставления. Практически все происходит на стадии редуктора. Самое приятное то, что мы можем запустить это полностью за несколько часов.

Качество сопоставления

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

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

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

Первоначально опубликовано на Indix.