Введение:

Путь поискового запроса через инженерный стек электронной коммерции можно в целом разделить на следующие этапы: этап обработки текста поискового запроса, этап поиска, когда релевантные продукты извлекаются из индексатора, и последний, но не менее важный этап, этап повторного ранжирования продукта, на котором Механизм ранжирования машинного обучения пересортирует продукты в первую очередь на основе комбинации ключевых показателей эффективности, таких как рейтинг кликов, рейтинг добавления в корзину, уровень оформления заказа и т. д. Основное внимание в этом посте будет уделено первому этапу, т. е. обработке текста запроса через службу понимания запросов ( КУС). Я хотел бы обсудить приложения и работу QUS в поиске электронной коммерции. QUS — один из наиболее важных сервисов, необходимых для разрешения запроса пользователя и определения ключевого поискового намерения. Среди множества сервисов машинного обучения (ML), работающих с инженерным стеком в любой компании электронной коммерции, QUS обычно первым удерживает крепость и выступает в качестве базовой службы ML на этапе предварительного поиска.

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

Поисковый запрос в электронной коммерции может содержать множество подсказок, которые помогут нам найти результаты, соответствующие намерениям пользователя. Запрос типа «черные джинсы levi для мужчин» состоит из ненормализованного названия бренда «levi», пола «мужской», типа товара «джинсы», цвета «черный» и категории таксономии верхнего уровня запрос может быть Одежда и аксессуары. Цель QUS — найти эти атрибуты, нормализовать их (levi => Levi Strauss & Co, mens => Men и т. д.) и отправить эту информацию в конечную точку поиска для получения соответствующих результатов. QUS будет состоять из множества подсервисов, таких как сервис классификации категорий запросов, сервис тегирования запросов, сервис нормализации атрибутов и т. д. выходные данные QUS можно в дальнейшем использовать для релаксации путем перезаписи. Этот процесс известен как релаксация запроса. Кроме того, мы также можем расширить запрос (расширение запроса), где мы можем показать результаты пользователей, которые почти аналогичны поисковому запросу, например. если пользователь ищет «светло-голубая футболка», мы можем расширить набор результатов, где цвет может быть светло-голубым, синим или фиолетовым. Кроме того, в случае запросов, чувствительных к брендам, результат может быть расширен до почти аналогичных брендов, чтобы предоставить пользователям доступ к доступным альтернативам в вашем инвентаре.

Общие проблемы

QUS поможет вывести поиск за рамки необработанного соответствия ключевому слову. В мире без QUSмогут возникнуть следующие проблемы, если мы зависим от чистого поиска SOLR

  1. Неверная категоризация товаров: запросы типа "херши какао-порошок", относящиеся к категории "Бакалея", могут найти модные товары, поскольку в них есть слово "порошок".
  2. Поиск Чувствительность:

Такие запросы, как «деревянный офисный стол» и «деревянный офисный стол», «костюмы на Хэллоуин для девочек» и «костюмы на Хэллоуин для девочек» могут давать разные результаты, хотя цель поиска у них одинаковая.

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

3. Нет ослабления запросов: слишком узкие запросы в большинстве случаев остаются неразрешенными. «Флисовые простыни размера «queen-size» могут возвращать одеяла — запрос следует смягчить до «простыни размера «queen-size».

4. Поиск без учета цены. Еще одной функцией QUS является извлечение информации о цене из запроса. Это можно сделать либо с помощью набора регулярных выражений, либо с помощью tagger + normalizer.

5. Неразрешенные варианты брендов. Для таких запросов, как «кока-кола, шесть упаковок» и «кока-кола, шесть упаковок», результаты могут отличаться.

Фазы поиска

Мы можем разделить процесс поиска электронной коммерции на два этапа.

Почтовый поиск:

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

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

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

Корректор орфографии

Обнаружение намерений

Классификаторы запросов

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

Классификатор типа продукта (PT): обычно таксономии носят иерархический характер, например. В категории одежды и аксессуаров верхнего уровня у вас будут рубашки на уровне 2 и мужчины/женщины/дети на уровне 3, формальные/повседневные на уровне 4 и т. д. Из-за шума в содержании каталога и семантических проблем в структуре каталога (почти аналогичные категории листьев в разделе разные L1, например, чай может быть в продуктовом магазине, а также в офисе > кладовая), обычно лучше классифицировать запрос по плоской иерархии Типы продуктов, например в контексте последнего запроса PT будет просто «Рубашки», если запрос — зарядное устройство для iphone 9, PT будет «Зарядные устройства для телефонов».

Теггер запросов

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

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

  1. уточнение поиска в фасетной манере
  2. разрешение запросов с длинным хвостом
  3. переписывание запросов и смягчение запросов
  4. продвижение продукта/рекомендация
Architecture: Bidirectional LSTM-CRF Models for Sequence Tagging
Tutorial : https://guillaumegenthial.github.io/sequence-tagging-with-tensorflow.html

Атрибуты тега

Вообще говоря, существует два типа атрибутов, а именно глобальные и локальные. Локальные атрибуты очень специфичны для определенных конечных категорий, например. атрибуты для Home›Furniture›Table будут иметь ключи/значения атрибута, такие как

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

Напротив, есть другие наборы атрибутов, которые являются глобальными по своей природе, т. е. они не сосредоточены на какой-либо конкретной категории, например. размер можно найти в одежде, в мебели, бытовой технике и т. д. Хотя значения этих атрибутов могут быть специфичными для категории, например. размер в одежде может принимать такие значения, как XS, S, M, L и т. д., в то время как размер в бытовой технике ›Категория микроволновых печей может иметь действительные значения размера, такие как компактный, средний, семейный размер и т. д. Они присутствуют в разных категориях или, по крайней мере, в группе категорий. Для обнаружения этих атрибутов лучше использовать тегировщик. В приведенной ниже таблице содержится то, что мы называем глобальными атрибутами.

Нормализация атрибутов

Как только тегировщик обнаружит упоминание в запросе и пометит отдельные токены, следующим шагом будет нормализация этих токенов. Для типов атрибутов, таких как цвет, нормализация довольно проста, например. {красный, светло-красный, розовый, .. и т. д.} можно сопоставить с одним цветовым семейством с нормализованным именем RED, аналогично и для цены мы можем создать стандартизированное наименование, используя набор регулярных выражений. С помощью нормализации мы стремимся стандартизировать пару ключ/значение атрибута по отношению к значениям в каталоге. Здесь предварительное требование состоит в том, чтобы продукты в каталоге имели канонизированные значения атрибутов, например. все мужские рубашки будут иметь атрибут размера, сопоставленный только с предопределенными значениями {XS, S, M, L, Xl, XXL ..}. Теперь, когда мы обнаруживаем атрибут размера в запросе, таком как «мужская маленькая клетчатая рубашка», следующим шагом будет нормализация токена размера «маленький» к нормализованному значению атрибута в каталоге «S». Это помогло бы нам либо сделать фасетный запрос к SOLR, либо увеличить количество продуктов при поиске, где атрибут размера равен «S», тем самым повысив качество поиска.

Числовые атрибуты, такие как цена, количество (например, 1 галлон молока), возраст (игрушки для детей 8–12 лет), можно обрабатывать с помощью регулярных выражений. Как только мы определяем категорию и тип продукта запроса, мы можем применить набор регулярных выражений, применимых только к этим категориям и PT, для извлечения числовых атрибутов, например. для запроса типа «2 галлона цельного молока» категорией может быть «Бакалея › Молоко › Цельное молоко», а PT может быть «Молоко». Как только мы узнаем эти значения, мы можем применить набор регулярных выражений, созданный исключительно для обработки количества продуктов/молока. /нормализация суммы. Следующий набор запросов имеет значение атрибута цены равное 20, которое можно легко извлечь с помощью пары регулярных выражений.

а. «футболки до 20 лет»

б. “тройники до 20 долларов”

в. “тройники до 20 долларов”

д. “тройники до 20 долларов США”

Общая нормализация атрибутов может быть достигнута с использованием следующих подходов

  1. Методы на основе регулярных выражений
  2. Методы на основе правил

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

б. Можно создать таблицу, подобную sql, в которой каждый ненормализованный атрибут сопоставляется с его нормализованным вариантом

в. Простой поиск в таблице может привести к получению нормализованных значений атрибутов.

3. Подход на основе классификации:

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

б. Но последний подход предоставит нам помеченный набор данных для работы, т. е. значения атрибутов, сопоставленные с их каноническими версиями.

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

д. Подход, основанный на связывании сущностей

я. Связывание сущностей — полезная тема, о которой я планирую написать в отдельном посте. Но чтобы представить суть идеи, Связывание сущностей — это процесс обнаружения строк упоминаний в тексте, которые могут соответствовать именам сущностей (например, тегирование находит упоминания и помечает их ключами атрибутов, такими как Бренд, Размер и т. д.), а затем пытается сопоставить их с сущности в базе знаний. Этот метод может быть полезен при поиске брендов в запросе, а также в названии и описании продукта.

ii. Хотя существуют нейронные архитектуры, которые могут обнаруживать строку упоминания, а затем связывать упоминание с наиболее подходящим объектом-кандидатом, в следующем разделе мы обсудим очень похожий подход, основанный на модели.

Нормализация бренда на основе связи сущностей

Допустим, у нас есть строка упоминания, помеченная как Brand в поисковом запросе. Задачу связывания сущностей можно разбить на два этапа: создание кандидатов и ранжирование кандидатов. Генерация кандидатов означает выборку нормализованных кандидатов-брендов, которые синтаксически или семантически похожи на строку упоминания, например, для поискового запроса «пожарная машина paw-patrol» тегировщик сгенерирует упоминание для бренда как «paw-patrol». а на этапе генерации кандидатов можно найти набор синтаксически похожих брендов из каталога для категории Игрушки. Традиционно для генерации кандидатов использовался подход, основанный на поиске информации, такой как BM25, вариант TF-IDF для измерения сходства между строкой упоминания и брендами-кандидатами и их описанием. Получив набор кандидатов, мы можем ранжировать их на этапе Рейтинг кандидатов.

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

В Learning Dense Representations for Entity Retrieval авторы используют архитектуру модели, аналогичную архитектуре сходства предложений, чтобы поместить описание сущности и представления описания упоминаний рядом друг с другом в одной и той же области. Кроме того, такой подход весьма предпочтителен, поскольку представления бренда могут быть предварительно вычислены, и поскольку в этой архитектуре нет прямого взаимодействия между кодировщиками на каждой стороне, мы можем просто вычислить контекстно-зависимое представление строки упоминания и взять скалярное произведение. между ним и предварительно рассчитанными представлениями бренда. Это обеспечивает эффективное извлечение, но ограничивает набор допустимых сетевых структур. Изображение из упомянутой публикации показывает, как можно использовать компоненты из строки запроса и описания объекта для поиска сходства между ними.

Разрешение бренда в шумном каталоге

Может случиться так, что в каталоге не нормированы названия брендов. В этом случае какой-то бренд, например. Coca-Cola может упоминаться разными продуктами в каталоге, используя разные варианты, например. кока-кола, кока-кола, кока-кола, кока + кола и т. д. Здесь мы не можем нормализовать бренд в запросе, так как названия брендов в каталоге не нормализованы. Таким образом, вместо того, чтобы канонизировать бренд в запросе, мы должны стремиться получать продукты, которые относятся к любому варианту искомого бренда.

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

  1. Проанализируйте каталог, чтобы создать сопоставление типа продукта: список доступных брендов

а. Например. кофеварка: [блэк декер, блэк энд декер, блэк энд декер, блэк + декер, мистер Кофе, Кеуриг, …..]

2. Используйте классификатор типа продукта, чтобы получить запрос PT.

3. Используйте тегировщик запросов, чтобы пометить токен/токены как B-BR и I-BR.

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

а. Триграмма-Жаккара

б. Левенштейн Редактировать расстояние

в. Яро Винклер

д. ФуззиВуззи

Пример:

Для такого запроса, как «кофеварка black n decker», предполагаемым типом продукта может быть «Кофеварка», а строка с упоминанием бренда может быть «black n decker». Поиск в PT на карте списка брендов может вернуть список допустимых вариантов брендов в каталоге для PT «Кофеварка» как [black decker, black & decker, black and decker, black + decker, Mr. Coffee, Keurig, …]. Теперь, используя расстояние редактирования от 1 до 2, мы можем найти бренды-кандидаты из списка брендов, сопоставленные с кофеваркой типа продукта, как [черный палубный, черный и палубный, черный и палубный, черный + палубный]. Позже Solr сможет продвигать все эти бренды, получая результаты по этому запросу. При таком подходе нам даже не нужно нормализовать бренды в каталоге, так как мы можем повысить все варианты за один раз.

Соединение точек

Как только QUS получает все ключевые сведения из запроса, результаты передаются в SOLR. Предварительным условием является то, что каталог индексируется с отдельными измерениями для категории, бренда, типа продукта и т. д. Для поиска мы можем использовать схему на основе веса, в которой для прогнозируемых категорий, типов продуктов, брендов и т. д. предоставляется повышение на основе более высокого веса. Для таких атрибутов, как категория и PT мы можем даже сделать фасетный поисковый вызов, добавляя повышения для предсказанного бренда, линейки продуктов, размера и т. д. Кроме того, мы также можем добавить смягченный вторичный запрос к основному запросу, чтобы отзыв был высоким. Это поможет в разрешении запросов с длинным хвостом и запросов с нулевым результатом. Уровень ранжирования продуктов может позаботиться о том, чтобы упорядочить дополнительные результаты упрощенного запроса по отношению к продуктам, возвращенным из основного запроса. Более продвинутые методы, такие как создание отдельной службы оптимизации для прогнозирования веса атрибутов, которые должны быть повышены на основе пользовательского запроса, могут еще больше повысить релевантность возвращаемых результатов, например. для запроса одежды алгоритм прогнозирования веса SOLR может предоставить больше весов для бренда и цены, чем для стиля / рисунка.

Следуйте за мной на smashinggradient.com