Как устроена архитектура факторов ранжирования в рантайме поиска Ozon

31.01.2026 • Хабр

Инженер поиска Ozon описывает, как в рантайме вычисляются факторы ранжирования и как сервис o2-midway меняет порядок товаров в выдаче. Главная идея: факторы оформлены как DAG и поставляются через метасервис, чтобы быстрее экспериментировать и безопаснее выкатывать модели.

В поиске Ozon используется больше тысячи факторов ранжирования; новые факторы появляются ежедневно.
Сервис o2-midway получает товары от нижестоящих сервисов и перед ответом клиенту пересчитывает их порядок, включая скоры ML-моделей на каждый поисковый запрос.
Зависимости факторов представлены как направленный ациклический граф (DAG): для любой сортировки достаточно вычислить нужный подграф, а сам граф строится на старте приложения.
Добавление фактора в o2-midway описывается декларативно через input/output, а детали вычисления берёт на себя инфраструктура графа.
Проблема релиза для типовых факторов решается сервисом feature-meta 1-store: он хранит метаописания факторов и позволяет автоматически добавлять их в граф.
Для защиты продакшена описаны ревизии факторов для окружений и проверки новых моделей в ml-pipeline (перформанс и качество), отчёты сравнения с baseline и последующая раскатка через продакшен.

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

На что обратить внимание: В тексте кэши упоминаются, но не рассматриваются, поэтому акцент сделан на вычислениях в момент запроса. Для типовых факторов и формул используется метаописание и валидация: при несовпадении зависимостей формула может быть отклонена ещё на этапе добавления в ревизию. Процесс продвижения модели в продакшен подразумевает точку контроля через отчёты, UI и отдельную раскатку с тестированием.

Коротко

В тексте полезно различие «базовые» и «производные» факторы: часть признаков берётся из свойств, часть вычисляется поверх них и меняется быстрее.
Ранжирующая функция здесь — это правило сортировки по одному скору; в ML-варианте скор трактуется как вероятность действия (например, покупки) по целям модели.
Валидация формул и зависимостей до выката снижает риск «сломать граф»: пример с отсутствующим входным фактором показывает, где ловятся ошибки конфигурации.
Появляется контур безопасности для новых моделей: отдельные проверки перформанса и качества помогают отсекать варианты, которые могут ухудшить работу сервиса.
Отдельного внимания заслуживает согласование ролей: ML-инженер готовит модель и отчёт, а добавление в продакшен проходит через контролируемый шаг и ревизии.

FAQ

Зачем это важно: почему в поиске Ozon выстроили архитектуру факторов ранжирования вокруг графа зависимостей и отдельного метасервиса с ревизиями?

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

Что в статье называется фактором ранжирования и «ранжирующей функцией», и как это связывается с поисковой выдачей товаров по запросу пользователя?

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

Как feature-meta-store и ревизии помогают избежать проблем при добавлении новых формул и ML-моделей, и где именно проверяется корректность зависимостей?

Сервис хранит метаописания факторов и ревизии для окружений, а корректность формул проверяется при добавлении: если зависимость отсутствует в ревизии, возвращается ошибка.

PubMag