Миллион запросов в секунду ломает привычную схему
В обычном проекте рекомендаций порядок работы понятен: собрали признаки, обучили модель ранжирования, поставили за API. На витрине маркетплейса в пиковый день эта схема упирается в физику.
Посчитайте бюджет: если на запрос отводится 8 миллисекунд, а запросов миллион с лишним в секунду, то любая операция, которая на одном запросе стоит лишнюю миллисекунду, стоит на потоке отдельного парка серверов. Тяжелая модель, вызванная на каждый показ, — это не вопрос оптимизации, это вопрос бюджета компании.
Два уровня вместо одного
Работа разделена на дешевую и дорогую части.
Первый уровень отбирает кандидатов: из миллионов позиций каталога остаются сотни. Он построен на предрассчитанных структурах и не требует тяжелых вычислений в момент запроса. Второй уровень ранжирует эти сотни моделью, которая уже может себе позволить быть умной, потому что работает на маленьком списке.
Стандартная для отрасли конструкция, но дьявол в границе: чем больше кандидатов пропускает первый уровень, тем выше качество и тем дороже второй. Эта граница подбиралась замерами на живом трафике; значения по умолчанию из библиотеки тут не годятся.
Признаки расходятся, и это самая дорогая ошибка
Классическая беда промышленного ML: модель обучалась на признаках, посчитанных пакетно по историческим данным, а в бою получает признаки, посчитанные на лету другим кодом. Формулы вроде бы одинаковые. На практике где-то другое округление, где-то другое окно агрегации, где-то по-разному обработан пропуск.
Модель при этом не падает. Она просто работает хуже, чем на тестах, и никто не понимает почему.
Лечится это одним: признак определяется в одном месте и оттуда используется и при обучении, и при выдаче. Плюс постоянное сравнение распределений: если признак в бою распределен иначе, чем на обучении, это авария, и обсуждать тут нечего.
Деградация вместо отказа
Под пиком система обязана выбирать, что отдать, а не падать. Порядок деградации задан заранее и утвержден бизнесом:
- Полная схема: отбор кандидатов плюс ранжирование моделью.
- При росте задержки — сокращение числа кандидатов на ранжирование.
- Дальше — упрощенная модель ранжирования.
- В крайнем случае — предрассчитанная выдача по категории.
Последний уровень выглядит примитивно, зато витрина показывает товары всегда. Пустая полка на главной в час пик стоит дороже, чем неоптимальная сортировка.
Плюс 11% — как это измерялось
Не сравнением «до и после»: на маркетплейсе неделя на неделю не приходится, и любое сравнение периодов ловит сезонность, промо и погоду. Прирост конверсии витрины измерен A/B-тестом на трафике, с контрольной группой, работающей на прежней схеме, и с проверкой значимости.
Это единственный способ говорить о влиянии на бизнес честно. Все прочие способы дают числа, которые разваливаются при первом вопросе финансового директора.
Холодный старт и свежие товары
Модель ранжирования любит то, о чем много данных, и поэтому системно недооценивает новинки. Если этому не мешать, витрина превращается в музей популярного, а новые продавцы не получают шанса.
В выдачу заложена доля исследования: часть позиций получает показы, чтобы по ним набралась статистика. Доля контролируется явно и является предметом бизнес-решения, а не побочным эффектом алгоритма.
Кеш решает больше, чем кажется
Значительная часть запросов на витрине повторяется: одна и та же категория, один и тот же популярный запрос, одна и та же группа пользователей с похожим профилем. Считать для них ранжирование заново каждый раз — это чистая трата бюджета.
Поэтому перед моделью стоит слой кеширования с коротким временем жизни записи. Короткое время принципиально: рекомендации обязаны реагировать на действия пользователя в текущей сессии, поэтому персональная часть выдачи из кеша исключена. Кешируется то, что общее, — и именно это снимает основную нагрузку в пик.
Что стоит спросить у подрядчика такой системы
- Какой бюджет задержки у вашего ранжирования и что происходит при его превышении.
- Где определяются признаки и как гарантируется, что обучение и бой считают их одинаково.
- Как измеряется эффект — A/B или сравнение периодов.
- Что показывает витрина, когда модель недоступна.
- Как обновляется модель и сколько времени занимает откат на предыдущую версию.
Последний вопрос особенно полезный: система, где откат модели занимает часы, будет ронять выручку при каждой неудачной выкатке.
Направления рядом — рекомендательные системы, эксплуатация ML и потоковые ML-системы.