Звук: RecSys по трекам, Python-рантайм и кодинг

Начать с implicit collaborative filtering: user-item матрица по прослушиваниям, likes/skips, ALS/BPR/item2item. Добавить popular/recency fallback, фильтры уже прослушанного и позже реранжирование с контекстом сессии.

Если есть только история прослушиваний, первый baseline - implicit feedback. События нужно взвесить: полное прослушивание сильнее короткого skip, like сильнее обычного play, повторные прослушивания можно логарифмировать. Дальше подойдут ALS, BPR, item-to-item co-occurrence или простой nearest-neighbor по item embeddings.

Для выдачи нужна генерация кандидатов: похожие треки, популярное в сегменте, свежее, editorial/business rules. После этого можно делать реранжирование: не повторять только что прослушанное, добавить diversity по артистам/жанрам, учитывать устройство, время дня, контекст сессии и skip history.

Cold start решается fallback-ами и content features: жанр, артист, аудио embeddings, текст/метаданные. Даже если первая версия коллаборативная, архитектура должна позволять позже добавить content-based кандидатов.

Offline: Recall@K, NDCG@K, HitRate, coverage/diversity по артистам и жанрам. Online: play-through rate, skip rate, likes, saves, listening time, session length, retention и guardrails по повторам/усталости.

Offline можно предсказывать held-out listens/likes/skips: Recall@K и HitRate показывают, попал ли нужный трек в рекомендации, NDCG учитывает позицию, coverage и diversity показывают, не схлопнулась ли выдача в популярные треки. Для музыки важны срезы по новым трекам, новым пользователям, жанрам и артистам.

Online-метрики должны отражать пользовательский опыт: доля дослушиваний, skip rate в первые секунды, likes, saves, добавления в плейлист, listening time, session length, возвраты в продукт. Guardrails: повторяемость, слишком узкая выдача, доля explicit/неподходящего контента, latency.

Нельзя смотреть только short-term clicks/plays: модель может начать крутить знакомые хиты, поднять первые прослушивания и ухудшить discovery или долгосрочное удержание.

Присваивание не копирует список, а добавляет новую ссылку на тот же объект. Shallow copy копирует внешний контейнер, но вложенные объекты остаются общими. Deep copy рекурсивно копирует вложенные объекты.

В Python переменная хранит ссылку на объект. Если написать b = a, где a - список, то a и b указывают на один и тот же список. Поэтому b.append(1) изменит объект, который виден и через a.

Shallow copy можно сделать через a.copy(), list(a) или a[:]. Она создает новый внешний список, но элементы внутри остаются теми же объектами. Если внутри лежит вложенный список, изменение вложенного списка будет видно в обеих копиях.

Deep copy из модуля copy рекурсивно копирует вложенные объекты. Она нужна для сложных структур, но может быть дорогой и не всегда желательной, если часть объектов должна оставаться общей.

Декоратор принимает функцию и возвращает новую функцию-обертку. Генераторная функция при вызове возвращает generator object; ее тело начинает выполняться только при next(), цикле или list(generator).

Декоратор - это обычная функция высшего порядка. Синтаксис @decorator примерно равен func = decorator(func). Обертка может логировать вызовы, проверять права, кешировать результат, менять аргументы или выполнять код до/после исходной функции. Для сохранения имени и docstring обычно используют functools.wraps.

Генераторная функция содержит yield. При вызове она не выполняет тело сразу, а возвращает generator object. Код внутри начнет выполняться, когда кто-то запросит следующий элемент: next(g), for, list(g). После каждого yield состояние функции сохраняется до следующего шага.

Поэтому принты до/после yield появляются в момент итерации, а не в момент создания генератора. Это часто спрашивают, чтобы проверить понимание lazy evaluation.

Смотреть состояние объекта, мутабельность, понятный lifecycle обработки, ошибки I/O, memory usage, idempotency, валидацию входа и то, не отдается ли наружу внутренняя изменяемая структура без копии.

В таком ревью сначала нужно понять lifecycle: когда файл читается, когда данные считаются обработанными, где меняется флаг состояния и можно ли вызвать методы в неправильном порядке. Если property возвращает внутренний DataFrame, внешний код может случайно изменить состояние объекта; иногда нужна копия или read-only контракт.

Дальше проверяются I/O и ошибки: существует ли путь, корректен ли encoding/separator, что происходит с пустым файлом, битым CSV, большим файлом, частичной записью. Если данные большие, чтение всего файла в память может быть проблемой; нужны chunks, streaming или явный лимит.

Еще важны имена методов и ответственность. Метод check не должен внезапно выполнять тяжелую обработку, если его название обещает только проверку. Ошибки лучше делать явными исключениями с понятным сообщением, а не неявным падением в середине пайплайна.