Как стать автором
Обновить

Realtime-матчинг: находим матчи за считанные минуты вместо 24 часов

Время на прочтение11 мин
Количество просмотров11K
Всего голосов 42: ↑42 и ↓0+42
Комментарии8

Комментарии 8

Давайте лучше обсудим внедрение проплаченных товаров в выдачу поиска, особенно в режиме сортировки по цене, когда вам среди 100-рублёвых товаров каждый третий за 1000? И если в браузере, хотя бы блокировщик можно настроить на скрытие таких карточек, то в мобильном приложении проще открыть другой магазин.

Насколько пользователю выгодно пользоватся магазином, который хочет впарить товар подороже с выгодой только для себя?

А по делу, как быстро сматчить одинаковые товары? Просто посмотреть в выдачу, там у вас постоянно одно и тоже очень близко друг к другу, непонятно, зачем нужно сканировать всю базу 24 часа или даже несколько минут, хотя бы в выдаче у себя же поищите и запишите обратно в базу.

Если по делу, то идея взять поисковую выдачу конечно хорошая)
Но под собой это тоже поиск похожих товаров через, например, Apache Lucene. И это выступает как один из источников пар для финальной модели матчинга. А как показывает практика, то при использовании других алгоритмов поиска товаров (knn на картинках, графовый поиск на товарах, где ребро -- наличие матча, и т.д.) мы приносим очень много дополнительных пар.

Лучше использовать специальные решения: Milvus, Pinecone, Qdrant для подбора кандидатов на основе ANN.

А почему это лучше?
Мы смотрели в сторону этих инструментов, но их использование означает деплой и дальнейшую поддержку, своих сил это потребует сильно больше.

если вам будет интересно, в будущем сделаем серию технических туториалов по тому, как завести систему realtime-матчинга самому (маякните в комментариях :))

интересно!

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

Можете пояснить, как задача классификации трансформировалась в задачу регрессии? Теперь вместо бинарного таргета (матч/не матч) новая модель предсказывает скор предыдущей модели? Или я не совсем поняла?

Мне кажется, тут прямо бросается metric learning на датасете из размеченных данных и результатов-скоров предыдущей модели.

И еще вопрос, используется ли как-то фидбек от пользователя (возможно, от предыдущей модели). Что вот из всего набора матчей он кликнул и перешел на такой-то товар?

И спасибо, было очень интересно прочитать)

Раньше датасет у нас состоял из 0/1 и мы учили бинарную классификацию с LogLoss. Во время инференса использовали predict_proba, получали скоры, на которых могли строить калибровочные модели или просто отсекать по порогу. Теперь датасет состоял из 0/1 а также чисел p \ in (0, 1) -- ответов от "большой" модели. И финальный бустинг уже обучался на регрессию минимизировать MSE.

Ты имеешь в виду завести сетку с metric learning подходом? Это интересная мысль, просто бустинг заводится в разы легче :) Но идеи с сетками держим в голове!

Фидбэк от пользователя не используется конкретно в задаче матчинга, не очень понимаю, как он может помочь здесь.

Рад, что было интересно!

На go уже переписываете или только собираетесь?

Только начинаем, там довольно много работы.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий