У нас нет поддержки подобных фичей. В первую очередь потому, что никогда не было подобных запросов (feature request) от пользователей. Для yandex/google подобное имеет смысл, т.к. поиск это единственный и основной продукт, а для ecommerce, на мой взгляд, это совершенно невостребованно.
В текущей версии персонализация поисковой выдачи есть только для залогиненных покупателей – т.к. ML фичи опираются на пользовательскую активность в прошлом. Смена устройства не влияет на наличие статистики по пользователю, но операционную систему устройства можно использовать как ML фичу. Разумеется не так, что "если зашёл с айфона, то цены выше", а просто предоставить модели решать, что делать. Например на web версии покупатели склонны дольше рассматривать товары на большом экране. Когда мы закончим с самыми перспективными фичами персонализации из беклога, посмотрим как можно распространять статистику на незалогиненных покупателей.
Про смысловой поиск: в Lucene 9 появилась реализация ANN алгоритма — HNSW (хотя судя по док-ии буквы H там пока нет). Мы её попробовали в тестовом режиме и убедились, что на семпле нашего индекса всё работает, действительно можно найти близкие по смыслу запроса товары. Но в проде у нас пока ничего на эту тему нет, т.к. O2 ещё живёт на Lucene 8. DSSM сейчас есть только в L2 ранжировании.
Про аннотационные признаки: в проде сейчас ничего на эту тему нет. Есть желание затащить в документ ключевые поисковые запросы для товара (с их статистикой) и, возможно, отзывы. Коллеги из поиска Mail рассказывали, что в своё время получили какие-то профиты от обогащения документа текстами из близких по смыслу документов. Пайплайны доставки фичей у нас один — DS команда готовит признаки на хадупе, дальше они либо попадают в документы при индексации (если храним эти признаки в индексе), либо через кафку заливаются в L2 feature store (redis).
Вы тоже пишете о web версии — там действительно происходит перерисовка странице при клике. Эту проблему мы приняли и будем исправлять. В приложениях (ios, android) можно выбрать несколько брендов из полного списка, в конце нужно нажимать кнопку Применить, — моргания не будет.
У меня нет хорошего ответа, но я прокомментирую ситуацию, чтобы вопрос не повис в воздухе:
Проблема с постоянной перерисовкой фильтров при выборе нескольких значений действительно существует на web версии (в приложениях виджет фильтра обновляется быстро и никого не расстраивает). В ходе разбора этого вопроса я обнаружил, что мы усугубили ситуацию несколько месяцев назад - раньше не было перерисовки всей страницы. Мы не сможем сейчас всё бросить и побежать это чинить, т.к. проблема не выглядит блокирующей, но постараемся всё исправить в этом году.
Все фильтры должны работать по логике ИЛИ (boolean OR). Мне известна обратная ситуация, когда тематика фильтра такова, что в нём хочется ожидать AND логики, но срабатывает стандартная OR. Пришлите пожалуйста конкретные примеры, это поможет разобраться действительно ли есть проблема или где-то недопонимание.
В Ozon есть общие фильтры (бренд, цена, продавец и т.д., их немного) и категорийные. За "продумывание" что где в первую очередь показывать исторически отвечают люди от бизнес-юнитов, на основе понимания предметной области и статистики использования. Совсем недавно мы начали пробовать переложить эту задачу на ML, посмотрим удастся ли машинам отобрать рабочие места :)
Много вопросов разной тематики смешалось, отвечу по порядку:
Про корректность сортировок и пагинации: влияние несинхронного обновления индексов на серверах o2-base на консистентность минимальна, т.к. один раз получив ответ от движка, мы сразу кешируем наперёд несколько страниц. Этот трюк в своё время заметно нарастил нам hit rate кешей. Но в вопросе есть уточнение про большие оффсеты. Это верное замечание — когда мы подбираемся к концу окна LTR рескоринга (сейчас это 2000й документ, т.е. примерно 55 страниц) пагинация на границе перестаёт быть консистентной, т.к. ML ранжирование заканчивается. Но это только в сортировке по популярности, в других сортировках такой проблемы нет. В целом мы об этом не переживаем, т.к. настоящие покупатели так далеко выдачу не скроллят.
Как устроен анализатор: мы используем jmorphy и доделываем его под себя. У нас есть синонимы, специальные правила и морфология, всё как обычно. Контент селлеры заполняют неидеально, это правда. В этом направлении мы тоже копаем, т.к. от качества контента зависят целевые метрики поиска.
Про тестирование ранжирования: сейчас мы опираемся только на метрики, оффлайн и онлайн. Специальных тестов на искуственных примерах у нас нет. Про чёрный ящик: интерпретация работы ML это сложная тема. У нас есть внутренний инструмент Explainer поискового ранжирования — он для товаров в выдаче показывает значения фичей и финальные скоры, можно разобраться как повлияли разные факторы и сделать выводы. Сейчас делаем упрощенную версию Explainer для селлеров, чтобы они могли анализировать выдачу и предпринимать какие-то действия для продвижения своих товаров.
Вопрос содержит две части: почему для ebay подходит elastic, и почему мы решили уйти с elastic на o2.
На вторую часть мне ответить проще. Некоторые причины я уже назвал в статье — отделение фазы L2 ранжирования от фазы поиска и L1 ранжирования, желание уметь оптимизироваться на любых уровнях и иметь доступ к коду. Даже во времена elastic мы использовали собственный fork, т.е. необходимость тюнить стандартные компоненты у нас была давно.
Что такого необычного именно в поиске Ozon? Один из примеров — определение геодоступности для товаров в выдаче: товары лежат на разных складах, которые подключены к разным логистическим провайдерам (Ozon Логистика, СДЭК, Почта России и т.д.), у каждого провайдера своя зона покрытия. В момент исполнения поискового запроса нужно определять какие товары доступны покупателю, а какие нет. Другой пример — необходимость при определённых условиях объединять разные товары в одну плитку (например iphone 12 red в вариантах 64gb и 128gb индексируются как отдельные документы, но на выдаче объединяются в одну карточку).
На первую часть вопроса мне ответить сложнее, т.к. мне неизвестна внутренняя кухня ebay. Я вообще до появления этого комментария считал, что ebay живёт на собственном решении, т.к. в их статьях (пример) об elastic упоминаний нет. Учитывая, что ebay основан в 1995, позволю себе предположить, что они долгое время использовали не elastic (появился после 2010). Если переход на elastic и правда произошёл, то причин можно придумать множество, вплоть до банальных — были сложности с собственным поиском и CTO принял волевое решение. В общем, фантазировать не буду.
Ушло некоторое время, чтобы разобраться. Нужный товар в выдаче есть (у меня в районе 15й позиции). Основной вопрос - почему же он не на первом месте.
Занятно, что L1 ранжирование (текстовая релевантность) даёт этому товару самый высокий score. Т.е. ML всё испортил :D. Основная проблема в том, что по запросу очень мало статистики, и модель начала смотреть на общие характеристики: цену (она у данного товара одна из самых высоких по запросу), отзывы, скорость доставки. В сумме накопилось достаточно, чтобы опустить его вниз.
У нас в беклоге есть задача, связанная с ранжированием непопулярных запросов. Для них общая LTR модель работает не очень хорошо, и нужно либо обучать отдельную модель, либо придумывать другие трюки. Данную задачу мы уже несколько раз откладывали, т.к. она влияет лишь на малый процент трафика, но теперь появился новый спортивный интерес.
Если будут ещё интересные примеры, можно присылать мне в телеграм.
Kubernetes в Ozon появился несколько лет назад. Большинство прикладных сервисов (как например search-api) переехали в него сразу в рамках программы реновации. Инфраструктурные сервисы (как например elastic) обычно живут вне кубера, их администрируют специальные люди, разработчики доступов не имеют.
Поисковый движок не похож на типичный прикладной сервис из-за высоких нагрузок и довольно большой инсталляции (сейчас мы самые большие в инфраструктуре Ozon). Базовый поиск и мастер живут на собственных железках без соседей. Иногда нам задают вопрос "зачем вам вообще кубер?". Ответ банальный — выгоднее использовать стандартные механизмы (пока они нас устраивают), поддерживаемые командой платформы, и не тратить силы на инфру и CI/CD.
Мы облажались с текстовым анализатором, будем исправлять.
У нас нет поддержки подобных фичей. В первую очередь потому, что никогда не было подобных запросов (feature request) от пользователей. Для yandex/google подобное имеет смысл, т.к. поиск это единственный и основной продукт, а для ecommerce, на мой взгляд, это совершенно невостребованно.
За счёт чего Tantivy в два раза обгоняет Lucene?
В текущей версии персонализация поисковой выдачи есть только для залогиненных покупателей – т.к. ML фичи опираются на пользовательскую активность в прошлом. Смена устройства не влияет на наличие статистики по пользователю, но операционную систему устройства можно использовать как ML фичу. Разумеется не так, что "если зашёл с айфона, то цены выше", а просто предоставить модели решать, что делать. Например на web версии покупатели склонны дольше рассматривать товары на большом экране.
Когда мы закончим с самыми перспективными фичами персонализации из беклога, посмотрим как можно распространять статистику на незалогиненных покупателей.
Про смысловой поиск: в Lucene 9 появилась реализация ANN алгоритма — HNSW (хотя судя по док-ии буквы H там пока нет). Мы её попробовали в тестовом режиме и убедились, что на семпле нашего индекса всё работает, действительно можно найти близкие по смыслу запроса товары. Но в проде у нас пока ничего на эту тему нет, т.к. O2 ещё живёт на Lucene 8. DSSM сейчас есть только в L2 ранжировании.
Про аннотационные признаки: в проде сейчас ничего на эту тему нет. Есть желание затащить в документ ключевые поисковые запросы для товара (с их статистикой) и, возможно, отзывы. Коллеги из поиска Mail рассказывали, что в своё время получили какие-то профиты от обогащения документа текстами из близких по смыслу документов. Пайплайны доставки фичей у нас один — DS команда готовит признаки на хадупе, дальше они либо попадают в документы при индексации (если храним эти признаки в индексе), либо через кафку заливаются в L2 feature store (redis).
<ответил не в тред, пришлось удалить комментарий>
Вы тоже пишете о web версии — там действительно происходит перерисовка странице при клике. Эту проблему мы приняли и будем исправлять. В приложениях (ios, android) можно выбрать несколько брендов из полного списка, в конце нужно нажимать кнопку Применить, — моргания не будет.
Фильтр "Высокий рейтинг" сортирует по взвешенной сумме отзывов на товар. Формула напоминает рейтинг IMDB для фильмов, пример можно посмотреть тут: https://stackoverflow.com/questions/1411199/what-is-a-better-way-to-sort-by-a-5-star-rating/1411268#1411268. По ситуации, где товары с 4 звездами находятся выше товаров с 5 звездами — пришлите пожалуйста пример, разберемся и ответим.
У меня нет хорошего ответа, но я прокомментирую ситуацию, чтобы вопрос не повис в воздухе:
Проблема с постоянной перерисовкой фильтров при выборе нескольких значений действительно существует на web версии (в приложениях виджет фильтра обновляется быстро и никого не расстраивает). В ходе разбора этого вопроса я обнаружил, что мы усугубили ситуацию несколько месяцев назад - раньше не было перерисовки всей страницы. Мы не сможем сейчас всё бросить и побежать это чинить, т.к. проблема не выглядит блокирующей, но постараемся всё исправить в этом году.
Все фильтры должны работать по логике ИЛИ (boolean OR). Мне известна обратная ситуация, когда тематика фильтра такова, что в нём хочется ожидать AND логики, но срабатывает стандартная OR. Пришлите пожалуйста конкретные примеры, это поможет разобраться действительно ли есть проблема или где-то недопонимание.
В Ozon есть общие фильтры (бренд, цена, продавец и т.д., их немного) и категорийные. За "продумывание" что где в первую очередь показывать исторически отвечают люди от бизнес-юнитов, на основе понимания предметной области и статистики использования. Совсем недавно мы начали пробовать переложить эту задачу на ML, посмотрим удастся ли машинам отобрать рабочие места :)
Много вопросов разной тематики смешалось, отвечу по порядку:
Про корректность сортировок и пагинации: влияние несинхронного обновления индексов на серверах o2-base на консистентность минимальна, т.к. один раз получив ответ от движка, мы сразу кешируем наперёд несколько страниц. Этот трюк в своё время заметно нарастил нам hit rate кешей. Но в вопросе есть уточнение про большие оффсеты. Это верное замечание — когда мы подбираемся к концу окна LTR рескоринга (сейчас это 2000й документ, т.е. примерно 55 страниц) пагинация на границе перестаёт быть консистентной, т.к. ML ранжирование заканчивается. Но это только в сортировке по популярности, в других сортировках такой проблемы нет. В целом мы об этом не переживаем, т.к. настоящие покупатели так далеко выдачу не скроллят.
Как устроен анализатор: мы используем jmorphy и доделываем его под себя. У нас есть синонимы, специальные правила и морфология, всё как обычно. Контент селлеры заполняют неидеально, это правда. В этом направлении мы тоже копаем, т.к. от качества контента зависят целевые метрики поиска.
Про тестирование ранжирования: сейчас мы опираемся только на метрики, оффлайн и онлайн. Специальных тестов на искуственных примерах у нас нет. Про чёрный ящик: интерпретация работы ML это сложная тема. У нас есть внутренний инструмент Explainer поискового ранжирования — он для товаров в выдаче показывает значения фичей и финальные скоры, можно разобраться как повлияли разные факторы и сделать выводы. Сейчас делаем упрощенную версию Explainer для селлеров, чтобы они могли анализировать выдачу и предпринимать какие-то действия для продвижения своих товаров.
Вопрос содержит две части: почему для ebay подходит elastic, и почему мы решили уйти с elastic на o2.
На вторую часть мне ответить проще. Некоторые причины я уже назвал в статье — отделение фазы L2 ранжирования от фазы поиска и L1 ранжирования, желание уметь оптимизироваться на любых уровнях и иметь доступ к коду. Даже во времена elastic мы использовали собственный fork, т.е. необходимость тюнить стандартные компоненты у нас была давно.
Что такого необычного именно в поиске Ozon? Один из примеров — определение геодоступности для товаров в выдаче: товары лежат на разных складах, которые подключены к разным логистическим провайдерам (Ozon Логистика, СДЭК, Почта России и т.д.), у каждого провайдера своя зона покрытия. В момент исполнения поискового запроса нужно определять какие товары доступны покупателю, а какие нет. Другой пример — необходимость при определённых условиях объединять разные товары в одну плитку (например iphone 12 red в вариантах 64gb и 128gb индексируются как отдельные документы, но на выдаче объединяются в одну карточку).
На первую часть вопроса мне ответить сложнее, т.к. мне неизвестна внутренняя кухня ebay. Я вообще до появления этого комментария считал, что ebay живёт на собственном решении, т.к. в их статьях (пример) об elastic упоминаний нет. Учитывая, что ebay основан в 1995, позволю себе предположить, что они долгое время использовали не elastic (появился после 2010). Если переход на elastic и правда произошёл, то причин можно придумать множество, вплоть до банальных — были сложности с собственным поиском и CTO принял волевое решение. В общем, фантазировать не буду.
Ушло некоторое время, чтобы разобраться. Нужный товар в выдаче есть (у меня в районе 15й позиции). Основной вопрос - почему же он не на первом месте.
Занятно, что L1 ранжирование (текстовая релевантность) даёт этому товару самый высокий score. Т.е. ML всё испортил :D. Основная проблема в том, что по запросу очень мало статистики, и модель начала смотреть на общие характеристики: цену (она у данного товара одна из самых высоких по запросу), отзывы, скорость доставки. В сумме накопилось достаточно, чтобы опустить его вниз.
У нас в беклоге есть задача, связанная с ранжированием непопулярных запросов. Для них общая LTR модель работает не очень хорошо, и нужно либо обучать отдельную модель, либо придумывать другие трюки. Данную задачу мы уже несколько раз откладывали, т.к. она влияет лишь на малый процент трафика, но теперь появился новый спортивный интерес.
Если будут ещё интересные примеры, можно присылать мне в телеграм.
Kubernetes в Ozon появился несколько лет назад. Большинство прикладных сервисов (как например search-api) переехали в него сразу в рамках программы реновации. Инфраструктурные сервисы (как например elastic) обычно живут вне кубера, их администрируют специальные люди, разработчики доступов не имеют.
Поисковый движок не похож на типичный прикладной сервис из-за высоких нагрузок и довольно большой инсталляции (сейчас мы самые большие в инфраструктуре Ozon). Базовый поиск и мастер живут на собственных железках без соседей. Иногда нам задают вопрос "зачем вам вообще кубер?". Ответ банальный — выгоднее использовать стандартные механизмы (пока они нас устраивают), поддерживаемые командой платформы, и не тратить силы на инфру и CI/CD.