Подготовка датасета для офлайн-оценки рекомендательных моделей: практическое руководство и аудит с SplitLight

Почему абстрактного названия разбиения недостаточно для воспроизводимости

При тестировании алгоритмов машинного обучения исследователи и инженеры постоянно столкнуться с трудностями воспроизведения заявленных результатов. Когда цифры из научной статьи или отчёта соседней команды не сходятся с реальными тестами, в первую очередь принято искать ошибки в самой нейросетевой архитектуре, функции потерь (loss function) или логике сэмплирования негативных примеров. Однако на практике определяющее значение чаще имеет не структура модели, а то, каким образом были подготовлены и разделены данные перед запуском экспериментов.

Стандартное описание эксперимента в публикациях обычно ограничивается базовой формулировкой вроде «глобальное временное разбиение (Global Temporal Split) с квантилем 0,9». Такое определение указывает лишь на общий принцип, но совершенно не раскрывает деталей: применялись ли пороги N-core фильтрации, как обрабатывались действия пользователя с одинаковыми метками времени, удалялись ли последовательные повторы и какие именно объекты включались в целевую выборку. В результате два независимых эксперимента на одном и том же наборе данных фактически проверяют совершенно разные гипотезы и продуктовые сценарии.

Для обеспечения полной воспроизводимости необходимо точно фиксировать три компонента контрольного набора:

• Обучающую выборку (train set), используемую для настройки параметров модели.
• Входную историю (input history), доступную алгоритму на этапе инференса для формирования предсказаний.
• Целевые действия (target / ground truth), относительно которых рассчитываются метрики качества (NDCG, Recall и др.).

Даже в рамках базового схемы Global Temporal Split (GTS) можно выбрать разную логику таргетов: брать только следующее одиночное взаимодействие, все последующие действия пользователя после точки отсечки или полностью исключать cold-start сущности. Чтобы упорядочить этот процесс, исследователи из Sber AI Lab и института AIRI разработали специальный инструмент с открытым исходным кодом — SplitLight (представленный на SIGIR 2026). Я подробно изучил предложенный авторами подход и подготовил разбор ключевых проверок, которые следует выполнять каждому специалисту по Data Science до запуска обучения.

Анализ исходного датасета: на какие параметры обратить внимание

Подготовка логов взаимодействия существенно меняется в зависимости от предметной области (будь то музыкальный стриминг, электронная коммерция или сервис коротких видео). Инструмент SplitLight создавался не для навязывания единого «жесткого» стандарта, а для проведения объективной диагностики любой последовательности подготовки данных.

Базовые характеристики и влияние фильтрации

Стандартный первичный осмотр включает подсчёт количества уникальных пользователей, объектов (items), общего числа событий, плотности матрицы и распределения длины пользовательских историй. Крайне важно смотреть не только на средние значения, но и на медиану, а также квантили. В рекомендациях средняя длина истории часто искажается узкой группой сверхактивных пользователей или ботов, тогда как у подавляющей массы пользователей зарегистрировано всего по 2–3 действия.

Каждый этап предобрабтки — N-core отсечение, удаление коротких сессий или отсеивание редких товаров из каталога — существенно смещает итоговые распределения. Сравнение параметров до и после фильтрации дает понимание реального масштаб изменений: одна и та же 5-core фильтрация на разреженном датасете может отбросить до половины аудитории, а на плотном логе практически не повлияет на состав данных.

Временные свойства и проблема коллизий меток

Для последовательных (sequential) рекомендательных систем временная метка (timestamp) задаёт строгое хронологическое движение. При анализе следует отделять общий временной охват датасета (dataset timeframe) от реального периода активности конкретного пользователя (user lifetime). Датасет может собираться на протяжении десяти лет, но средний период присутствия одного пользователя в нём составит всего пара часов. Оценивать способность модели отслеживать долговременные тренды на таких данных бессмысленно.

Серьёзную проблему представляют коллизии временных меток — ситуации, когда несколько событий одного пользователя записаны с идентичным временем (из-за низкой точности логирования или пакетной отправки логов). При простой сортировке порядок этих событий становится случайным и зависит от системных особенностей хранения. Для последовательных моделей (таких как SASRec) это напрямую влияет и на точность обучения, и на корректность формирования тестовых таргетов.

График распределения событий по дням или месяцам дополнительно помогает выявить технические сбои логирования, сезонные пики и пропуски в сборе данных, которые могут исказить результаты временного разбиения.

Повторное потребление и последовательные повторы

Повторные взаимодействия (repeat consumption) характерны для музыкальных сервисов или сервисов заказа продуктов, но нетипичны для покупки крупной бытовой техники. Разработчикам важно разделять два паттерна:

• Общие повторные взаимодействия (пользователь вернулся к объекту спустя некоторое время).
• Последовательные повторы (consecutive repeats), когда один и тот же объект записан несколькими строками подряд.

Если в продукте логируются клики подряд или повторные прослушивания одной песни, оставлять такие дубли в таргете без анализа опасности не стоит. В противном случае тестовый таргет совпадёт с последним элементом входной истории, и модель начнёт показивать искусственно завышенные метрики, просто дублируя предыдущее действие.

Проверка данных после проведения разбиения

После разделения сырого лога на обучающую (train) и тестовую/валидационную выборки необходимо выполнить повторную диагностику сформированных сетов.

Габариты выборок и их временная структура

Статистики рассчитываются отдельно для train, input history и target. Это позволяет проверить, соответствует ли временной интервал между обучением и тестированием реальному графику переобучения модели в продакшене. Если модель в реальности обновляется ежедневно, а тестовый таргет отстоит от обучающей выборки на полгода, результаты оценки окажутся недостоверными.

Риск утечки данных во времени (temporal leakage)

Прямая утечка происходит при попадании одинаковых строк в train и test. Но существует и более скрытая форма: когда события из будущего (по отношению к тестовому таргету) попадают в обучающую выборку. Популярная схема разбиения leave-one-out (где для каждого пользователя в тест отправляется последнее действие) глобально перемешивает временные эпохи. В train попадают события других пользователей, совершенные намного позже оцениваемого момента. Модель фактически «заглядывает в будущее», вылавливая глобальные тренды популярности, что невозможно в продакшене.

Сценарий «холодного старта»

При разбиении в тестовую выборку неизбежно попадают «холодные» пользователи и объекты, которые полностью отсутствовали в train. Если сравнивать чистую коллаборативную фильтрацию (работающую только по ID) с гибридной моделью (использующей текстовые или визуальные эмбеддинги), доля новых объектов в тесте кардинально меняет баланс сил. Команда должна явно фиксировать процент холодного старта в валидационных данных.

Сдвиги распределений и временные разрывы

Иногда процедура отсечки создаёт искусственный сдвиг (distribution shift). Например, если пользователь совершал действия внутри сессии каждые 10 секунд, а выбранный таргет относится к следующему дню, временной разрыв (target time gap) резко увеличивается. В SplitLight для выявления таких несоответствий применяется статистический критерий Колмогорова—Смирнова, сравнивающий временные интервалы таргетов с базовым распределением исходного датасета.

Возможности фреймворка SplitLight

Чтобы не писать диагностические скрипты с нуля под каждый новый проект, разработчики объединили весь спектр проверок в открытую библиотеку SplitLight. Инструмент поддерживает работу в двух режимах:

1. Python API / Jupyter Notebooks — для автоматической интеграции в pipelines подготовки данных (MLOps).
2. Streamlit UI — удобный визуальный веб-интерфейс для быстрого аудита без написания кода.

Для работы требуется минимальная структура данных: идентификатор пользователя (user_id), идентификатор объекта (item_id) и метка времени (timestamp) в формате CSV или Parquet. На итоговом дашборде выводится сводный отчёт с алертами и подробные вкладки по временным графикам, cold-start сущностям и временным утечкам.

Практические результаты аудита шести известных датасетов

Авторы SplitLight провели масштабный аудит популярных публичных датасетов: MovieLens-1M, MovieLens-20M, Diginetica, Dressipi, Beauty и Zvuk. Исследование выявило ряд неожиданных фактов:

• MovieLens-1M и 20M: Несмотря на то, что датасет ML-20M охватывает более 20 лет сбора, медианное время активности отдельного пользователя составляет всего около 1 часа. При схеме GTS с квантилем q=0,9 тестовые таргеты растянулись на 76% всего временного периода датасета (несколько лет), что искажает сценарий оценки. Кроме того, в ML-1M свыше 53% событий имеют совпадения по временным меткам.
• Zvuk: Около 68% всех взаимодействий являются повторными, причем 21,5% — это последовательные повторы одной и той же композиции. При удалении прямых дублей медианный интервал между событиями вырос с 0,25 до 15 секунд.
• Diginetica: При разбиении leave-one-out временные диапазоны train и test пересекаются практически на 100%, а 89% таргетов подвержены временной утечке. В режиме GTS q=0,9 доля холодных пользователей составила 100%, превратив тест в чистую проверку cold-start.

Влияние вариантов предобработки на метрики рекомендательных моделей

Чтобы продемонстрировать практический эффект этих нюансов, была обучена популярная последовательная модель SASRec и замерена метрика качества NDCG@10 (усредненная по 5 запускам с разными случайными зернами):

• На датасете MovieLens-1M простая смена порядка элементов с одинаковыми временными метками привела к падению NDCG@10 с 0,1861 до 0,1685.
• На датасете Dressipi сохранение последовательных повторов формально подняло общий NDCG@10 с 0,1343 до 0,2168. Однако при отдельном расчёте метрики только на новых (неповторяющихся) таргетах показатель рухнул до 0,1225 — модель просто научилась повторять последнее действие пользователя.
• Включение холодных объектов в тестовый сет на Dressipi снизило итоговый NDCG@10 с 0,1343 до 0,0965.

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

Как правильно встроить аудит в исследовательский пайплайн

Я рекомендую придерживаться следующей последовательности при проведении экспериментов с рекомендательными моделями:

1. Анализ сырых данных: проверка временных рамок, коллизий меток и характера повторных взаимодействий.
2. Аудит после предобработки: фиксация объёма отброшенных пользователей и товаров после применения N-core фильтров.
3. Диагностика разбиения: проверка train/input/target выборок на предмет temporal leakage, доли холодных сущностей и смещения временных интервалов.
4. Документирование артефактов: сохранение не только финального значения NDCG/Recall, но и полного конфига предобработки.

В итоговом отчёте к эксперименту всегда следует сохранять параметры фильтрации, правила обработки коллизий, схему выделения таргета и процент cold-start элементов.

Ограничения инструмента и особенности применения

На текущем этапе фреймворк SplitLight работает исключительно с базовой тройкой user_id, item_id и timestamp. Внешние контекстные признаки, суммы покупок или типы событий (например, различие между кликом, добавлением в корзину и покупкой) пока требуют предварительного разделения вручную.

Итоги

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

Материалы и ссылки

Официальный научный материал проиллюстрирован в статье: «SplitLight: An Exploratory Toolkit for Recommender Systems Datasets and Splits» (конференция SIGIR 2026, DOI: 10.1145/3805712.3808631), авторы: Анна Володкевич, Дмитрий Аникин, Данил Гусак, Антон Кленицкий, Евгений Фролов, Алексей Васильев.

Источник: habr.com