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

Привет, Хабр! Меня зовут Алексей Васильев, я тимлид команды «Рекомендательные системы и персонализация» Sber AI Lab — Центра практического искусственного интеллекта Сбера. Мы занимаемся исследованиями в области рекомендаций, разрабатываем новые модели и, конечно, сравниваем свои результаты с результатами коллег и других исследователей. И регулярно сталкиваемся с ситуацией, когда результаты, заявленные в научной статье или полученные от другой команды, не удаётся воспроизвести, хотя ключевые параметры пайплайна полностью совпадают. В этой статье мы с Анной Володкевич, исследователем из нашей команды, расскажем про свой опыт анализа таких расхождений, на основе которого разработали фреймворк SplitLight.

Когда результаты научной статьи или успех другой команды не удаётся воспроизвести, обычно начинают с поиска багов в реализации модели: смотрят архитектуру, функцию потерь, способ сэмплирования негативных примеров. Хотя часть несоответствий обусловлена именно этим, наш практический опыт показывает, что процедура подготовки данных зачастую сильнее влияет на итоговый результат сравнения рекомендательных моделей. Например, формулировка из статьи «датасет Zvuk, global temporal split с квантилем 0,9» не сообщает, какие фильтры и агрегации применяли, как обрабатывали события с одинаковыми временными метками и повторные взаимодействия, удаляли ли холодные объекты, какие данные передавали модели на вход и по каким событиям рассчитывали метрики. Поэтому два пайплайна с одним датасетом и одинаковым названием разбиения могут оценивать разные постановки задачи. Это затрудняет воспроизведение экспериментов и сравнение результатов между работами.

Вместе с коллегами из института AIRI мы задались вопросом, на какие параметры пайплайна предобработки данных стоит обращать особое внимание, и какие свойства данных и результатов разбиения на обучающую, валидационную и тестовую выборку нужно проверять перед запуском обучения, чтобы повысить воспроизводимость результатов. Постепенно из этих проверок сложился чек-лист, а затем и SplitLight — open-source-инструмент для анализа датасетов, результатов предобработки и разбиений данных для обучения рекомендательных систем. В июле 2026 года мы также опубликовали статью «SplitLight: An Exploratory Toolkit for Recommender Systems Datasets and Splits» и представили SplitLight на конференции SIGIR 2026 (A*). Здесь мы сначала разберём сам чек-лист, а затем покажем, как особенности предобработки и разбиения данных могут повлиять на оценку качества рекомендательных систем.

Почему одного названия разбиения данных недостаточно

Для проведения экспериментов нам обычно нужно разбить данные (split) на обучающую, валидационную и тестовую выборку. В описаниях экспериментов, как правило, указывают тип разбиения и несколько параметров: например, глобальное разбиение по времени, квантиль q = 0,9. По такой записи можно понять общий принцип, но точный пайплайн разбиения данных остаётся неясным.

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

• обучающую выборку;

• входную историю (input), доступную модели на этапе применения (inference) для теста и валидации;

• таргеты (target) или ground truth-объекты для теста и валидации.

Рассмотрим глобальное разбиение по времени (Global Temporal Split, далее — GTS). В качестве таргета можно использовать одно событие — например, первое или последнее событие пользователя, — либо все события после временной отсечки. Предшествующие события можно передать модели как входную историю или отбросить. Пользователей и объекты, отсутствующие в обучающей выборке, можно сохранить или отфильтровать. Каждый из этих вариантов по-прежнему относится к глобальному разбиению по времени, хотя режимы оценки заметно различаются. Поэтому валидационный и тестовую выборку удобно хранить как пары «входная история — таргет». Входная история содержит события, известные модели в момент предсказания. Таргет содержит события, по которым рассчитывается метрика. Такая структура сразу показывает, какие данные были доступны модели и какие взаимодействия она должна была предсказать. Мы подробнее рассматривали разные варианты реализации разбиений для рекомендательных систем в другой нашей работе, «Time to Split: Exploring Data Splitting Strategies for Offline Evaluation of Sequential Recommenders».

Что проверить в исходных данных

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

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

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

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

Сравнение исходных и предобработанных данных позволяет увидеть реальный эффект от применённых фильтраций и агрегаций. Такой отчёт обычно информативнее, чем фраза «мы применили 5-core фильтрацию», поскольку одна и та же настройка по-разному влияет на датасеты с разной плотностью и структурой.

Временные свойства

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

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

Коллизии временных меток возникают, когда несколько событий одного пользователя имеют одинаковое время. При недостаточной точности логирования их реальный порядок восстановить невозможно. В результате последовательность может зависеть от исходного расположения строк или особенностей сортировки. Для последовательных моделей такая неоднозначность способна повлиять и на обучение, и на формирование таргетов.

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

Повторные взаимодействия (repeat consumption)

Степень выраженности повторных взаимодействий (repeated interactions) сильно зависит от домена. В музыке, видео и регулярных покупках пользователи естественным образом возвращаются к одним и тем же объектам. В других датасетах высокая доля повторов может возникать из-за повторной отправки событий или особенностей агрегации логов.

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

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

Что проверить после разбиения

Размер и временная структура выборок

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

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

Утечка данных по времени (temporal leakage)

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

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

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

Холодный старт

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

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

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

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

Разбиение может формировать таргеты, свойства которых заметно отличаются от остальных взаимодействий в датасете. Один из примеров — временной интервал между последним событием входной истории и таргетом. Если внутри сессии пользователь совершает действия каждые несколько секунд, а валидационные или тестовые таргеты относятся к следующей пользовательской сессии (как часто происходит, когда в качестве таргета используют первый объект после глобальной временной отсечки), то мы оцениваем модель в более сложных и не соответствующих реальным паттернам поведения пользователя условиях.

Такие сдвиги можно оценить, сравнив временные интервалы до таргетов (target time gaps) и позиции таргетов с референсными распределениями исходных или предобработанных данных. В SplitLight для этого мы используем статистику Колмогорова—Смирнова.

Как появился SplitLight

При работе с новыми датасетами и чужими экспериментальными артефактами нам приходилось снова собирать одни и те же статистики, строить временные графики и проверять результаты разбиения. Мы объединили этот код в SplitLight, чтобы использовать единый набор диагностик в разных проектах.

Инструмент работает в двух сценариях. Python API и Jupyter notebooks подходят для подробного анализа и интеграции в экспериментальный пайплайн. Streamlit UI рассчитан на быстрый аудит, сравнение разбиений и изучение распределений в no-code режиме.

Минимальная схема содержит поля user_id, item_id и timestamp. SplitLight умеет анализировать исходные и предобработанные данные, а также train, validation_input, validation_target, test_input и test_target. Поддерживаются CSV и Parquet. В репозитории SplitLight доступны инструкции по запуску, демонстрационные Jupyter notebooks, CLI-утилиты и конфигурации экспериментов.

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

Что показал аудит популярных датасетов

Мы применили SplitLight к Beauty, Diginetica, Dressipi, MovieLens-1M, MovieLens-20M и Zvuk. Эти датасеты различаются по масштабу, временной динамике и характеру пользовательских взаимодействий.

MovieLens-1M охватывает около 2,8 года, а MovieLens-20M — более 20 лет. При этом медианный период активности пользователя в обоих датасетах близок к одному часу. Для значительной части пользователей оценки собраны в течение короткой сессии, поэтому общий временной охват плохо описывает продолжительность индивидуальных историй. Diginetica и Dressipi также содержат короткие истории, но для сессионных данных электронной коммерции это ожидаемая структура.

В ML-1M около 53% взаимодействий содержат повторяющиеся внутри пользовательской истории временные метки, а в Beauty их доля составляет примерно 39%. В этих датасетах порядок заметной части событий неоднозначен. У Zvuk выражена другая особенность: около 68% взаимодействий являются повторными, из них 21,5% — последовательными повторами. После удаления последовательных повторов медианный интервал между событиями вырос с 0,25 до 15 секунд.

Анализ готовых разбиений также показал несколько важных эффектов. В ML-1M стандартное GTS с q = 0,9 сформировало выборку таргетов, охватывающую около 76% полного временного охвата датасета, или несколько лет, что плохо соответствует реальному сценарию применения моделей. Для Diginetica при leave-one-out периоды обучающей выборки и данных для оценки пересекались полностью, а около 89% таргетов были затронуты утечкой данных по времени. При GTS с q = 0,9 доля холодных пользователей составила 100% для Diginetica и Dressipi и 82,6% для ML-20M, поэтому эти варианты разбиения в значительной степени оценивали режим холодного старта для пользователей.

Как эти решения отражаются на метриках

Для иллюстрации мы обучили SASRec и рассчитали NDCG@10, усреднив результаты пяти запусков с разными сидами. Базовая предобработка включала 5-core-фильтрацию и удаление последовательных повторов; затем мы по отдельности меняли порядок событий с одинаковыми временными метками, обработку последовательных повторов и правила обработки холодных объектов. Использовали leave-one-out и GTS с q = 0,9, выбирая последнее взаимодействие как таргет (last-item target). Полные конфигурации предобработки, разбиений и обучения опубликованы в репозитории.

В ML-1M изменение порядка событий с одинаковыми временными метками снизило NDCG@10 с 0,1861 до 0,1685. На Dressipi сохранение последовательных повторов повысило общую метрику с 0,1343 до 0,2168, однако на таргетах, не являющихся последовательными повторами (non-consecutive targets), она упала и составила 0,1225, то есть модель обучилась предсказывать повтор последнего взаимодействия, что обычно не интересно в реальном использовании. При сохранении холодных объектов в данных для оценки результат на том же датасете снизился с 0,1343 до 0,0965. В проведённых экспериментах изменение порядка событий, обработки повторов или правил обработки холодных объектов заметно меняло метрику без изменений архитектуры SASRec. Эти параметры стоит указывать вместе с названием разбиения, особенно при сравнении результатов между работами.

Как включить анализ в экспериментальный пайплайн

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

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

Вместе с результатами эксперимента мы рекомендуем сохранять:

• параметры фильтров и агрегаций, объём удалённых данных;

• правила обработки повторов и коллизий временных меток;

• правила формирования входной истории и таргетов;

• правила обработки холодных пользователей и объектов;

• основные статистики итоговых выборок.

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

Ограничения

Текущая версия SplitLight ориентирована на логи взаимодействий, содержащие пользователя, объект и временную метку. Дополнительные признаки, рейтинги, суммы, контекст и разные типы взаимодействий пока не анализируются. Например, просмотр, добавление в корзину и покупка будут рассматриваться одинаково, если заранее не разделить их при подготовке данных.

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

Заключение

При сравнении рекомендательных моделей важен весь путь от исходного лога взаимодействия до данных, непосредственно идущих в модель и участвующих в подсчёте метрик. Фильтрация, порядок событий, обработка повторов, правила обработки холодных объектов и устройство разбиения определяют состав данных и условия, в которых рассчитывается метрика.

Мы используем SplitLight перед обучением моделей и при подготовке экспериментальных отчётов, чтобы избежать ошибок, задокументировать, как именно были выполнены предобработка и разбиение и убедиться, что результаты соответствуют ожидаемым. Проект опубликован под MIT License. Будем рады обратной связи и звезде на GitHub, если наша методология анализа и инструмент оказались полезны!

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

GitHub: monkey0head/SplitLight

Статья SplitLight: An Exploratory Toolkit for Recommender Systems Datasets and Splits (SIGIR 2026): DOI 10.1145/3805712.3808631

Авторы: Анна Володкевич, Дмитрий Аникин, Данил Гусак, Антон Кленицкий, Евгений Фролов, Алексей Васильев.