Фундаментальная проблема сопоставления заключается в том, что не существует единого источника истины. Существуют миллиарды продуктов, и нет абсолютной структуры, определяющей, как продукты должны быть идентифицированы в разных магазинах. 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.