Создание новой поисковой платформы

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

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

Отправная точка

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

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

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

Ценовая маркировка

Нашим главным улучшением стало введение ценников на рекламу.

Имея огромный автомобильный инвентарь, содержащий более 1,5 миллионов объявлений, мы могли использовать исторические данные для прогнозирования цен на новые объявления на нашей платформе. В рамках одного из первых проектов по работе с большими данными в mobile.de нам нужно было не только обучить саму модель, но и спроектировать и построить инфраструктуру для обучения и использования модели.

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

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

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

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

Чтобы предотвратить простои при обновлении, мы используем «сине-зеленую» стратегию развертывания. Служба оценщика содержит множество настраиваемых функций ETL для преобразования тела JSON в формат, принятый моделью машинного обучения.

После оптимизации время прогнозирования цены сократилось до 2–5 мс на рекламу.

На заключительном этапе оцененная цена записывается в базу данных и индексируется в Elasticsearch, что позволяет пользователям видеть ценники на странице результатов поиска и фильтровать по ним.

Теперь на странице результатов поиска с сортировкой по цене пользователи видят, что некоторые из первых (самых дешевых) автомобилей на самом деле не являются лучшими предложениями, но по более высокой цене у нас есть отличное предложение. На этом этапе у вас может возникнуть блестящая идея - давайте просто отсортируем все объявления по ценовому рейтингу и готово! Лучшее решение для поиска! - или нет?

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

Некоторые списки могут быть отличным соотношением цены и качества, но это не то, что нужно пользователю. Никто, ищущий лимузин, не станет покупать автомобиль Mini или Smart только потому, что это хорошее предложение. Хорошая рекомендательная система должна учитывать не только то, что она рекомендует, но и кому. Ценовой рейтинг важен, но это только один из аспектов, на котором должна строиться окончательная рекомендация.

Сбор информации о пользователях

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

Например, если пользователь провел 10 минут на нашей платформе, и мы получили следующее распределение для предпочитаемых им марок автомобилей: 50% BMW и 50% Audi и предпочтительные цвета автомобилей: 80% красный и 20% зеленый. С этого момента мы можем принять определенные предпочтения в отношении производителя и цвета, поэтому мы можем взвесить эти параметры в запросе Elasticsearch, чтобы предоставить больше автомобилей, соответствующих вкусу пользователя.

Пользовательские настройки применяются к запросу через Запрос оценки эластичной функции.

"functions": [
      {
          "filter": { "match": { "color": "RED" } },
          "weight": 3
      }
]

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

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

Повторный рейтинг набора результатов

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

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

В качестве меры качества ранжирования мы используем так называемую дисконтированную совокупную прибыль (DCG). Основная идея проста: каждому элементу в наборе результатов поиска присваивается оценка релевантности; общая сумма оценок релевантности набора результатов дает представление об актуальности набора - содержит ли он более или менее релевантную информацию по сравнению с другими наборами результатов? Мы используем нормализованный DCG для измерения релевантности каждого набора. В этой модели оценка каждого элемента нормализована по его положению, поэтому чем более релевантен каждый результат, тем выше его NDCG. Ранжирование завершено, когда все элементы отсортированы по релевантности.

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

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

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

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

Тестирование модели LTR в первой итерации показало, что использование моделей Learn-To-Rank увеличивает время отклика примерно на 30–40%, увеличивая p50 с 22 до 34 мс и p99 с 41 до 56, что является важным, но приемлемым значением.

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

Общая картина

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

Когда создается или редактируется новый листинг, мы рассчитываем его «рекомендованную» цену и добавляем соответствующий ценник, который затем индексируется в Elasticsearch.

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

В результате Elasticsearch возвращает наиболее релевантные объявления, отсортированные по наибольшей вероятности клика. Затем результаты отправляются во внешний интерфейс для представления.

Резюме

Описанное здесь решение еще не окончательно, но это важная веха в развитии нашей новой поисковой платформы на mobile.de.

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

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

Рекомендуемая литература: Для получения дополнительной информации о том, как мы улучшаем рекомендации по автомобилям на сайте mobile.de, см. Глубокое обучение для рекомендательных систем.