Есть ли опыт с рекомендательными моделями

Что проверяют

Был ли у вас настоящий опыт и какой именно: вы строили модель, готовили для неё данные или только читали про коллаборативную фильтрацию. Следом просят рассказать, как оценивали качество и чем подтвердили эффект, а у data engineer ещё и как рекомендации доезжали до продакшена.

Как отвечать

Стройте ответ вокруг одного проекта и честно называйте свою роль. Каркас:

• задача: что рекомендовали и где. Похожие товары, персональная лента, рассылка, от этого зависят данные и метрики;
• данные: чаще всего неявный фидбек, то есть просмотры, клики, покупки. Матрица сильно разрежена, отдельная проблема это холодный старт новых пользователей и товаров;
• подход: бейзлайн на популярном, затем item-based коллаборативная фильтрация или матричная факторизация (ALS из библиотеки implicit), контентные признаки для холодного старта. В продовых системах обычно два этапа: генерация кандидатов и ранжирование, например CatBoost с ранжирующей функцией потерь;
• оценка: офлайн Recall@K, NDCG@K, покрытие каталога, разбиение по времени, а не случайное. Эффект подтверждает только A/B-тест по бизнес-метрике: CTR, конверсия, выручка на пользователя;
• инфраструктура, если вы data engineer: сбор событий, пайплайн признаков на Spark под Airflow, частота пересчёта, задержка отдачи.

Цифры приводите только свои и объясняйте, откуда они: какая метрика, на какой отложенной выборке, подтвердил ли рост A/B-тест. Процент без источника выглядит придуманным.

Если опыта нет, скажите прямо и покажите, что тема для вас не пустая: пет-проект на MovieLens, сравнение ALS с бейзлайном по популярности, что оказалось сложнее, чем ожидали.

Где спотыкаются

Делят данные случайно, а не по времени. Модель видит будущее, офлайн-метрики красивые, а в A/B-тесте эффекта нет.

Не сравнивают с бейзлайном по популярности. Сложная модель, которая его не обыгрывает, встречается чаще, чем кажется, и интервьюер обязательно об этом спросит.

Приписывают себе всю систему. На вопросах о гиперпараметрах ALS или выборе функции потерь data engineer, который готовил данные, быстро теряется, поэтому границы своей роли лучше обозначить сразу.