Проектирование системы

• Сначала простое работающее решение, потом критика, потом полное. Сложная система, спроектированная с нуля, не работает и не чинится заплатками.
• Целеполагание нельзя пропускать. Грубую ошибку здесь не вытащит никакая модель ниже — а пропустить его хочется всегда.
• Размер каталога определяет архитектуру. До 75 000 кандидатов воронка не нужна вовсе, и отказ от неё — правильное решение, а не упрощение.
• Редкое целевое событие меряют прокси не из упрямства. Поймать тот же относительный эффект на конверсии 0.5% вместо 40% стоит в 133 раза больше трафика.

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

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

Сформулируйте ключевых акторов — чаще всего это пользователь, айтем и контекст. Затем придумайте идеи для кандидатогенерации и признаков:

• для каждого актора по отдельности — три ячейки;
• для каждой пары акторов — ещё три.

Получается сетка 3 + 3, которая почти всегда покрывает всё существенное. И её же удобно проговаривать вслух как структуру ответа — интервьюер видит систему, а не перечисление.

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

Технические. Каталог на точке — чаще всего до 3000 айтемов, хорошо структурирован. Пользователей десятки миллионов, запросов — сотни в секунду. Бюджет ответа с учётом предзагрузок — до 300 мс. Товары становятся доступны и недоступны мгновенно, и они портятся, поэтому новинки должны появляться в выдаче быстро.

Полезно назвать самому, не дожидаясь вопроса.

• Пользователь может долго собирать корзину. Тогда действия внутри сессии становятся важны — особенно для тех, про кого мы знаем меньше. Значит, нужен рантайм-контур для пользовательской части.
• Решения против каннибализации потребуют полноценного общего слоя признаков.
• Рост каталога потребует выноса кандидатогенерации и признаков в отдельные сервисы.

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

Эксперимент: сплит пользовательский; ключевая метрика — интегральный оборот; вспомогательные — маржа и конверсия поверхности; антагонисты — оборот по категориям (не перекосили ли выдачу) и конверсия по позициям (не сломали ли верх).

1. Выделяем список базовых метрик с правдоподобным долгосрочным эффектом: просмотр сериалов (у них лучше удержание), дискавери и разнообразие потребляемого, частота использования.
2. Строим из них десяток комбинаций-кандидатов.
3. Ретроспективно понимаем, какие из них лучше показывают долгосрочный эффект — сопоставлением похожих пользователей или скорректированными корреляциями. Можно и модель обучить, но нужна интерпретируемость.
4. Проверяем на золотом наборе прошлых экспериментов — тех A/B, у которых долгосрочный исход уже известен.

Четвёртый пункт — тот, который обычно забывают назвать, а он и есть настоящая валидация: без него прокси остаётся гипотезой.

Это главное отличие кейса, и оно меняет постановку. У автора свои интересы и ожидания: авторы рассчитывают на показы, их отсутствие вызывает жалобы. Система перестаёт быть двусторонней «пользователь — айтем» и становится трёхсторонней.

Типичные подходы: встроенный в модель item exploration, PID-контроллеры для стабилизации объёма показов, явные квоты.

И следствие, о котором забывают: авторам платят за показы, значит начинается фрод — крутят ботов, накручивают CTR. В хорошей системе таргет антифрод-aware, как и целевая метрика, а команды работают тесно.

1. Какая бизнес-метрика? И сразу — насколько часто происходит целевое событие. Если оно редкое, разговор про прокси начинается здесь, а не в конце.
2. Размер каталога и число пользователей? От этого зависит, нужна ли воронка вообще.
3. Есть ли у пользователя интент? Лента и поиск — разные задачи, хотя формально одна.
4. Бюджет ответа? 50 мс и 300 мс — это разные архитектуры.
5. Кто известен: пользователи, айтемы, оба? Отсюда, какой холодный старт критичен.
6. Есть ли третья сторона — авторы, продавцы, рекламодатели? Это меняет постановку целиком.
7. Какие фильтрации обязательны? Легальные ограничения проектируются с самого начала, а не прикручиваются.

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

Если из всего этого стоит унести одну мысль, то такую: в рекомендациях почти каждое техническое решение выводится из ограничения, а не из моды. Воронка — из бюджета задержки. Факторизация — из разреженности. Двухбашенность — из числа кандидатов. Стохастичность выдачи — из потребности мерить. Хороший ответ на собеседовании отличается от плохого не набором названий, а тем, называет ли человек ограничение прежде решения.

Дальше — повторение по вопросам, виджеты и разбор открытого кода реальной ленты, где всё это видно в работающем виде.