Привет! Меня зовут Иван Елфимов, я Developer Advocate в Островке. В прошлом месяце мы опубликовали пост о том, чем занимаются ML-инженеры в Островке. В этот раз рассказываем про Machine Learning (ML) и Data Science (DS) с точки зрения продукта.

Команда Data Science появилась в Островке в 2014 году, задолго до расцвета больших языковых моделей. За это время она успела сделать десятки проектов с computer vision, NLP и сложными классическими моделями.

Ажиотаж вокруг языковых моделей заставил многих из нас забыть, что Data Science — это не только трансформеры (General Pretrained Transformers, GPT). Мы используем картинки, текстовые и табличные данные для построения моделей, которые работают в реальном времени или обрабатывают статистические данные. Они помогают нам подбирать лучшие отели для вашего следующего путешествия.

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

Загадка №1

Бронирование начинается с поиска. На скриншоте — главная страница https://ostrovok.ru. Сколько здесь DS-продуктов?

Саджест направлений

Когда я ввожу «Мос» в форме поиска, я, скорее всего, имею в виду «Москва». Так же и на английском: «Mos» скорее всего означает «Moscow». Но может быть и так, что я имел в виду «Московский вокзал».

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

Саджест направлений — это один из тех примеров, когда для DS-продукта не нужна модель и достаточно пары эвристик. Когда вы ставите курсор в поисковую строку, мы предлагаем самые популярные направления. А после ввода запроса мы показываем список, отсортированный на основе B-tree с учётом того, что пользователь искал раньше.

Загадка №2

Нажимаем «Найти», началась загрузка. Сколько DS-продуктов успело поработать, пока мы искали отель?

Вот вам небольшая подсказка: мы ещё не раз вернёмся к ранжированию, потому что поиск — это одна из самых больших составляющих Островка.

Офлайн-ранжирование поисковой выдачи

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

Офлайн-ранжирование помогает нам понять, в каком порядке и каких поставщиков спрашивать про доступные номера. У наших поставщиков разный уровень технологичности. Кто-то живёт с кодовой базой и инфраструктурой из 90-х, кто-то — на острие технологий. Кто-то оперативно обновляет данные о своей доступности и инвентаре в целом, а кто-то работает через третьих лиц и может передавать нам данные о номерах с задержкой. Если мы знаем, что поставщик медленно отвечает и не предлагает что-то стоящее, то мы можем подвинуть его на вторую или третью страницу результатов поиска, чтобы сделать запрос в фоне.

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

Поиск отеля целиком можно описать как «найти самое классное». Классно — это когда есть баланс между привлекательностью и стоимостью объекта размещения. По нашему опыту, с подборкой «самого классного» лучше всего справляется классическая CatBoost модель, которую мы тренируем на 10 млн пользовательских сессий за последние 30 дней и 1000 регионов, в каждом из которых до 5000 отелей. Мы учитываем количество отзывов, рейтинг, звёздность, интересные удобства, как отель себя показывал в прошлом, не слишком ли превышает цена отеля среднюю по региону.

Dynamic Cache TTL

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

Для сокращения времени и количества запросов мы используем кэширование. Но просто взять и закэшировать запросы всех пользователей и ответы поставщиков не получится, потому что мы обрабатываем до 100 GiB в минуту.

У нас есть модель, которая говорит, сколько хранить информацию от поставщика в кэше. Модель обучена по принципу supervised learning на основе исторических данных поставщиков.

Look-to-book optimization

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

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

Мы часто настраиваем модели и проверяем, как они работают. Успехом можно считать увеличение конверсии на 3-4%.

Look-to-book optimization — это модель, которая определяет, с какой вероятностью отдельно взятый поиск превратится в бронирование. Это классическая модель, которая учитывает историю бронирований и параметры пользователя, поставщика и отеля.

Другой неочевидный параметр, который учитывается в look-to-book optimization — это победа на репрайсе (reprice). Подробно про репрайс — в следующем разделе.

Мы планируем использовать Look-to-book optimization в связке с Dynamic Cache TTL, чтобы прогревать кэши и ускорять поиск.

Ценообразование

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

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

Может получиться так, что мы найдём номер, который был лучше запрошенного, а цена — такая же. Например, был номер «Стандарт, двухместная кровать» за 5000 руб., а нашли «Люкс, двухместная кровать» за те же 5000 руб. Я думаю, что многие из нас не откажутся от такого изменения.

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

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

Загадка №3

Страница загрузилась, появились варианты отелей. Сколько DS-продуктов на этой странице?

Онлайн-ранжирование поисковой выдачи

В основе онлайн-ранжирования — point-wise подход. Это когда мы рассчитываем некоторый параметр и сортируем по нему.

После «большого» поиска мы делаем повторное point-wise или точечное ранжирование «маленькой» выборки в 100-200 отелей. На маленькой выборке мы можем сравнить больше параметров и подвинуть лучший отель выше.

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

Ранжирование по программам лояльности

Программы лояльности бывают не только для пользователей, но и для владельцев объектов размещения. Для пользователей у нас есть GURU, а для объектов размещения — Top Stays.

Мы уверены в отелях Top Stays, потому что у них высокий рейтинг, много отзывов и бронирований.

С одной стороны, мы хотим показывать отели с наибольшей скидкой для пользователя, а с другой — лучшие объекты размещения. Баланс между программами лояльности ищем с помощью линейной регрессии. Наша задача предсказать количество просмотров: сколько отель получает просмотров сейчас и сколько мог бы получить, находясь выше в списке.

Выбор картинки отеля

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

Наша CV (Computer Vision) модель понимает, что изображено на фото. После распознавания мы скорим (scoring) и сортируем фотографии.

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

Загадка №4

С поисковой выдачей закончили. Давайте перейдем на страницу отеля. И пока что посмотрим только на верхнюю часть страницы. Сколько здесь DS-продуктов?

Матчинг отелей от разных поставщиков в единый метаотель

У Островка 230 поставщиков и 100 000 прямых контрактов с отелями. Многие поставщики отправляют информацию об отелях в неудобном для нас формате. Например, координаты одного и того же отеля могут быть немного разными. Кто-то вообще называет один и тот же отель по-разному. Если мы запишем информацию как есть, то растёт вероятность инцидента, когда гость заезжает не в тот отель.

Данные отелей обрабатываются в три шага: поиск ближайших соседей, фильтрация ненужных пар и классификация.

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

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

Другой пример. Некоторые поставщики могут дословно переводить названия объектов размещения на русский язык. «A box on the street is free» переводят как «Коробка на улице бесплатная». Или «Be Happy on the street Greedy» становится «Будь счастлив на улице, Жадный». В таких ситуациях автоматический матчинг не срабатывает и названия разбирает команда редакторов.

Подборка отзывов об отеле

Отзывы помогают нашим пользователям принять решение, бронировать или нет. Мы собрали отзывы из нескольких источников и привели их к единому формату. Все 50 миллионов отзывов переводит на 20 языков продукта небольшая LLM.

Мы планируем сделать подборку отзывов умнее и выдавать самый релевантный для пользователя отзыв. Релевантность планируем определять по истории просмотров и бронирования отелей.

Загадка №5

Спускаемся ниже по странице к блоку номеров. И давайте в последний раз сыграем:  сколько здесь DS-продуктов?

Матчинг комнат

В случае отелей мы объединяем несколько экземпляров одного и того же отеля от разных поставщиков в один «метаотель». На уровне комнат происходит примерно то же самое. 

Одна и та же комната в одном и том же отеле, но от разных поставщиков может быть с разными фото и описаниями.

Мы используем мультимодальную модель с несколькими шагами, чтобы убрать дубли и сделать одну «метакомнату» для каждого типа комнат.

Распознавание объектов на фото комнаты

Поставщик присылает нам описание номера и фото, и иногда они не совпадают. Мы используем Computer Vision (CV), чтобы показать только подтверждённую информацию о комнате.

После распознавания объектов мы совмещаем описание от поставщика с нашими тегами — и получается список параметров комнаты.

Про частые итерации и проверки гипотез

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

Новый DS-продукт может пройти через 3-4-5 итераций перед тем, как даст ожидаемые результаты. А может вовсе не дать результатов.

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

Не всегда всё идёт гладко

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

Бывало, что на самый верх поисковой выдачи всплывал какой-нибудь один совсем плохой отель. Из-за большого количества расчётов довольно сложно проверять, как работают модели в реальном времени. Аналогично фотографиям отеля и комнат, наши аккаунт-менеджеры могут периодически проверять, что, например, отель, участвующий в программе Top Stays, действительно появляется в начале списков.

Продолжение — во второй части

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

Подписывайтесь на телеграм-канал «Ostrovok! Tech», чтобы быть в курсе новых статей!

Перед тем как уйти, предлагаем вам сыграть в матчинг. Есть 6 отелей с похожими названиями от разных поставщиков. Напишите в комментариях, в какие 4 метаотеля можно их объединить. Например, «Отель 1», «Hotel 1» и «Отель 2» можно было бы объединить в 2 метаотеля: «Отель 1» и «Отель 2». Теперь ваша очередь, попробуйте объединить эти отели:

1. Jinjiang Inn Liaocheng Coach Station, 15 Jianshe Rd . W

2. Hotel Ilkay, Hudavendigar Street No: 44-46

3. Jinjiang Inn, 266 Hengshan Rd, Kunshan Shi, Suzhou Shi, Jiangsu Sheng, China, 215301

4. Jinjiang Inn Shanghai Railway Station, 500 Hutai Rd, Zhabei, Shanghai, China

5. Ilkay Hotel, Hudavendigar Street 28-30 - 34210

6. JJ INNS - SHANGHAI TRAIN STATION, China, 上海市No.500 Hutai Road 邮政编码: 200065