Рекомендательные системы
Коллаборативная/контентная/гибридная фильтрация, матричная факторизация, cold start, генерация кандидатов и ранжирование, two-tower, NDCG, position bias и петли обратной связи.
11 вопросов
JuniorТеорияОчень частоКоллаборативная, контентная и гибридная фильтрация — какие данные нужны каждой?
Коллаборативная, контентная и гибридная фильтрация — какие данные нужны каждой?
Коллаборативной фильтрации нужна только матрица взаимодействий — она советует понравившееся похожим пользователям и ломается на новых пользователях и товарах. Контентной нужны признаки и профиль — она покрывает новые товары, но не выходит за известный вкус. Гибрид смешивает оба.
Типичные ошибки
- ✗Считать, что коллаборативная фильтрация проскорит новый товар без взаимодействий
- ✗Думать, что контентная фильтрация открывает вкус за пределами истории пользователя
- ✗Воспринимать гибрид как переключатель-запасной вариант, а не как смесь двух сигналов
Уточняющие вопросы
- →Какой подход вы бы запустили первым для каталога, обновляющегося еженедельно, и почему?
- →Как гибрид меняет веса двух сигналов по мере накопления взаимодействий пользователя?
JuniorТеорияОчень частоКакие три вида cold start бывают и какое практическое решение есть для каждого?
Какие три вида cold start бывают и какое практическое решение есть для каждого?
Новый пользователь — истории нет, отдаём популярное или интересы с онбординга. Новый товар — взаимодействий нет, скорим его по контентным признакам. Новая система — матрицы нет, стартуем на контентных правилах. Все три ломают коллаборативную фильтрацию, а не контентные сигналы.
Типичные ошибки
- ✗Верить, что матричная факторизация даст пригодный вектор товару без взаимодействий
- ✗Лечить cold start подбором гиперпараметров вместо другого источника сигнала
- ✗Забывать про cold start системы при запуске с пустым логом взаимодействий
Уточняющие вопросы
- →Как оценить решение cold start, если затронутые пользователи — крошечная доля?
- →Какой бюджет исследования вы дадите совсем новым товарам и на какой срок?
JuniorТеорияЧастоМетрики ранжирования NDCG@k, MAP, recall@k и hit-rate — что поощряет каждая?
Метрики ранжирования NDCG@k, MAP, recall@k и hit-rate — что поощряет каждая?
Recall@k поощряет попадание релевантных в топ-k, порядок не важен. Hit-rate спрашивает лишь, попал ли туда один. MAP усредняет точность в каждом попадании, порядок уже важен. NDCG добавляет градуированную релевантность и позиционную скидку, потому она и стандарт ранжирования.
Типичные ошибки
- ✗Считать recall@k чувствительным к порядку
- ✗Полагать, что метки релевантности обязательно бинарные, а градуированный gain недоступен
- ✗Подавать hit-rate так, будто он измеряет, сколько релевантных товаров найдено
Уточняющие вопросы
- →Когда для оценки генератора кандидатов вы предпочтёте recall@k, а не NDCG?
- →Как выбор k связан с числом слотов, которые реально показывает интерфейс?
MiddleТеорияЧастоЧто означают латентные факторы и как метод alternating least squares работает с кликами?
Что означают латентные факторы и как метод alternating least squares работает с кликами?
Латентные факторы — выученные координаты без заданного смысла, векторы пользователя и товара, чьё скалярное произведение предсказывает близость. У неявной обратной связи нет настоящих негативов, ненаблюдаемая ячейка — негатив с низкой уверенностью, а клик — взвешенный позитив.
Типичные ошибки
- ✗Читать отдельное латентное измерение как конкретный жанр или атрибут
- ✗Считать ненаблюдаемую ячейку уверенным отказом, а не слабым свидетельством
- ✗Полностью выбрасывать ненаблюдаемые ячейки, из-за чего модель видит одни позитивы
Уточняющие вопросы
- →Как должен расти вес уверенности с ростом числа кликов пользователя по одному товару?
- →Почему alternating least squares здесь параллелится лучше градиентного спуска?
MiddleТеорияЧастоПочему в two-tower модели поиска кандидатов башни держат раздельно и что при этом теряется?
Почему в two-tower модели поиска кандидатов башни держат раздельно и что при этом теряется?
Башни держат раздельно, чтобы эмбеддинги товаров считались офлайн и складывались в индекс приближённого поиска соседей, а на запрос работала только башня пользователя. Плата — отсутствие кросс-признаков пользователь-товар, поэтому видимые ранкеру взаимодействия здесь невидимы.
Типичные ошибки
- ✗Верить, что итоговое скалярное произведение возвращает кросс-признаки пользователь-товар
- ✗Скорить весь каталог на запросе вместо обращения к индексу соседей
- ✗Ждать, что two-tower поиск кандидатов заменит стадию ранжирования
Уточняющие вопросы
- →Насколько может устареть офлайн-индекс товаров, прежде чем качество заметно просядет?
- →Как добывать сложные негативы для лосса поиска кандидатов помимо in-batch негативов?
SeniorДизайнЧастоВы отвечаете за главную ленту маркетплейса с пятьюдесятью миллионами товаров и пятью миллионами пользователей в день. Лента обязана вернуть тридцать ранжированных товаров в бюджете 150 мс от запроса до ответа, а модель ранжирования, которую хочет выкатить команда, — тяжёлая сеть с кросс-признаками стоимостью около одной миллисекунды на проскоренный товар. Спроектируйте систему как две стадии — генератор кандидатов на приближённом поиске соседей и следом этот ранкер. Объясните, почему одна стадия не укладывается в бюджет, сколько товаров каждая стадия передаёт дальше, какую долю бюджета задержки вы даёте каждой, какое семейство моделей подходит каждой стадии и как вы не дадите двум стадиям оптимизироваться друг против друга.
Вы отвечаете за главную ленту маркетплейса с пятьюдесятью миллионами товаров и пятью миллионами пользователей в день. Лента обязана вернуть тридцать ранжированных товаров в бюджете 150 мс от запроса до ответа, а модель ранжирования, которую хочет выкатить команда, — тяжёлая сеть с кросс-признаками стоимостью около одной миллисекунды на проскоренный товар. Спроектируйте систему как две стадии — генератор кандидатов на приближённом поиске соседей и следом этот ранкер. Объясните, почему одна стадия не укладывается в бюджет, сколько товаров каждая стадия передаёт дальше, какую долю бюджета задержки вы даёте каждой, какое семейство моделей подходит каждой стадии и как вы не дадите двум стадиям оптимизироваться друг против друга.
Одна стадия не работает — тяжёлый ранкер не осилит пятьдесят миллионов товаров, а дешёвая модель не даст качества ранжирования. Поиск кандидатов сужает каталог до сотен позиций за десятки миллисекунд через индекс соседей по two-tower эмбеддингам, ранкер тратит остаток бюджета.
Типичные ошибки
- ✗Задавать размер списка кандидатов, не сверяя его со стоимостью ранкера на товар
- ✗Считать, что одна дешёвая модель и просканирует каталог, и хорошо отранжирует
- ✗Учить стадию поиска на распределении, которого ранкер никогда не получает
Уточняющие вопросы
- →Как понять, что узким местом по качеству стал поиск кандидатов, а не ранкер?
- →Что меняется в этом дизайне, если бюджет задержки урезан со 150 мс до 50 мс?
MiddleДизайнИногдаВаша лента маркетплейса ранжирует чисто по предсказанному click-through rate. Мерчандайзинг сообщает, что верхние двадцать слотов заняты тремя крупными продавцами и одной категорией, мелкие продавцы уходят с площадки, а пользователи называют ленту однообразной — при этом сам click-through rate на историческом максимуме. Вам нужно спроектировать целевую функцию ранжирования на замену чистому предсказанному click-through rate. Определите, что вы оптимизируете на самом деле, как в целевую функцию входят разнообразие и показы продавцов, чем вы отказываетесь жертвовать и как до полной раскатки вы проверите, что размен оправдан.
Ваша лента маркетплейса ранжирует чисто по предсказанному click-through rate. Мерчандайзинг сообщает, что верхние двадцать слотов заняты тремя крупными продавцами и одной категорией, мелкие продавцы уходят с площадки, а пользователи называют ленту однообразной — при этом сам click-through rate на историческом максимуме. Вам нужно спроектировать целевую функцию ранжирования на замену чистому предсказанному click-through rate. Определите, что вы оптимизируете на самом деле, как в целевую функцию входят разнообразие и показы продавцов, чем вы отказываетесь жертвовать и как до полной раскатки вы проверите, что размен оправдан.
Оптимизируем долгосрочную ценность, а не клики на показ — релевантность плюс слагаемое за разнообразие и ограничение на показы продавцов в переранжировании. Порогом релевантности жертвовать нельзя. Проверка — A/B-тест по удержанию пользователей и продавцов, ведь клики он и тратит.
Типичные ошибки
- ✗Оптимизировать прокси на показ, когда бизнес-цель — долгосрочное удержание
- ✗Навешивать разнообразие пост-фильтром вместо включения его в целевую функцию
- ✗Читать эксперимент по той самой метрике, которую этот размен сознательно тратит
Уточняющие вопросы
- →Как задать вес слагаемого за разнообразие, не подкручивая его вручную вечно?
- →Какая защитная метрика остановит раскатку, даже если удержание выглядит хорошо?
MiddleДебаггингИногдаОфлайн NDCG вырос, а онлайн click-through rate упал — почините этот скрипт оценки.
Офлайн NDCG вырос, а онлайн click-through rate упал — почините этот скрипт оценки.
Скрипт скорит весь лог, включая обучающие строки, режет выборку случайно, и будущие сессии утекают назад, и доверяет логированным кликам, хотя видели только показанное старым ранкером. Нужно резать по времени, скорить отложенные сессии и перевзвешивать клики обратной пропенсити.
Открыть задачу →Типичные ошибки
- ✗Резать логи взаимодействий случайно вместо разбиения по времени
- ✗Считать метрику на строках, на которых модель обучалась
- ✗Считать логированные клики несмещёнными метками релевантности
Уточняющие вопросы
- →Как построить контрфактическую оценку, лучше предсказывающую онлайн-прирост?
- →Какой из трёх изъянов, по-вашему, сильнее всего завышает офлайн NDCG?
MiddleТеорияИногдаПочему клик на первой позиции — слабое свидетельство релевантности и как разсместить логи?
Почему клик на первой позиции — слабое свидетельство релевантности и как разсместить логи?
Первая позиция притягивает больше внимания, её клики отражают показ не меньше релевантности, а обучение на сырых кликах повторяет вчерашнее ранжирование. Дебиасинг — оценить вероятность просмотра позиции и взвесить клик обратной величиной, измеренной на рандомизированных слотах.
Типичные ошибки
- ✗Считать, что позиционный сдвиг усредняется при достаточном числе сессий
- ✗Взвешивать клики по позиции вместо обратной вероятности просмотра
- ✗Оценивать пропенсити по тем же логам, которые породил продовый ранкер
Уточняющие вопросы
- →Каким должен быть бюджет рандомизированных слотов, чтобы оценки пропенсити стабилизировались?
- →Как взвешивание обратной пропенсити меняет разброс офлайн-оценки?
SeniorДизайнИногдаЧерез полгода после запуска ваш рекомендатель выдаёт примерно двести товаров из каталога в четыреста тысяч. Всё это время он еженедельно переобучался на собственных логах кликов. Показы почти целиком приходятся на эти двести товаров, новый ассортимент почти никогда не всплывает, продавцы непоказываемых товаров уходят, и при этом любая офлайн-метрика по этим логам выглядит отлично и идеально стабильно. Выручка не падает, а стоит на месте, поэтому руководство не одобрит изменение с измеримой потерей краткосрочной выручки. Спроектируйте, как вы разорвёте петлю — откуда берётся исследование, как вы ограничиваете его цену и как докажете, что петля разорвана по-настоящему, а не просто расшатана на неделю.
Через полгода после запуска ваш рекомендатель выдаёт примерно двести товаров из каталога в четыреста тысяч. Всё это время он еженедельно переобучался на собственных логах кликов. Показы почти целиком приходятся на эти двести товаров, новый ассортимент почти никогда не всплывает, продавцы непоказываемых товаров уходят, и при этом любая офлайн-метрика по этим логам выглядит отлично и идеально стабильно. Выручка не падает, а стоит на месте, поэтому руководство не одобрит изменение с измеримой потерей краткосрочной выручки. Спроектируйте, как вы разорвёте петлю — откуда берётся исследование, как вы ограничиваете его цену и как докажете, что петля разорвана по-настоящему, а не просто расшатана на неделю.
В логах только то, что модель показала, поэтому переобучение само себя подтверждает. Разрывает её доля рандомизированных показов, чьи пропенсити логируют и перевзвешивают ими обучение, делая непоказанное оцениваемым. Долю ограничивают, а покрытие каталога читают против холдбэка.
Типичные ошибки
- ✗Доверять офлайн-метрикам, посчитанным по логам, которые породила сама модель
- ✗Добавлять исследование, не логируя порождаемые им пропенсити
- ✗Судить об успехе по одной выручке, пока покрытие каталога остаётся схлопнутым
Уточняющие вопросы
- →Какая доля рандомизированных показов удержит потерю выручки в пределах единиц процентов?
- →Как долго покрытие должно держаться после остановки исследования, чтобы счесть петлю разорванной?
JuniorТеорияРедкоКоллаборативная фильтрация kNN по пользователям или по товарам — что масштабируется?
Коллаборативная фильтрация kNN по пользователям или по товарам — что масштабируется?
Масштабируется item-based kNN. Товаров меньше и они стабильнее пользователей, поэтому таблицу соседей товар-товар считают офлайн и переиспользуют днями, тогда как векторы пользователей меняются каждой сессией. Обычный выбор меры — косинусная близость по центрированным векторам.
Типичные ошибки
- ✗Считать, что юзер-юзер и товар-товар стоят одинаково, раз матрица одна и та же
- ✗Брать сырые счётчики без центрирования, из-за чего активные пользователи доминируют в близости
- ✗Пересчитывать соседей на каждый запрос вместо выдачи из заранее посчитанной таблицы
Уточняющие вопросы
- →Как популярность товара искажает близость товар-товар и как её задемпфировать?
- →При каком размере каталога вариант по пользователям становится дешевле?
