Здравствуйте! Рад, что было полезно) Отвечая на ваши вопросы:
1. Выборка для обучения и валидации делится по пользователям. Мы агрегируем логи за нужный период и группируем по каждому пользователю, а затем начинаем процесс генерации вектора (подсчет g-, u-, s-, p- частей, основываясь на всех предыдущих сессиях и текущих показах/кликах). Прямо перед началом этого процесса мы и делим выборку случайным образом в отношении 4:1, проставляя каждому пользователю тэг train/test, с которым его вектора позже записываются в таблицу.
Изначально делили действительно просто по времени, оставляя последнюю неделю для валидации, но решили, что по пользователям делить будет наиболее честно и не давать модели возможность для переобучения.
2. Думали в эту сторону, но это было бы сложнее поддерживать, как минимум из-за learning_rate: непонятно, как его подбирать при расчете на то, что данные будут бесконечными. При до-обучении модели в реалтайме, нужно следить, чтобы не проседал лосс, и в случае чего быть готовым подменить ее моделькой с другим конфигом, но дообученной на тех же датасетах. А еще если данные будут плохие (например, что-то поменяется в логах или в методе их сборки), то тоже придется модель срочно менять на другую.
В общем, решили, что пока слишком много мороки и реализовали более простой вариант :)
3. Да, vowpal может работать как контекстуальный бандит, на вики действительно большой раздел посвящен описанию разных режимов его работы. У нас проводился эксперимент по обучению бандита, но пока до внедрения таких моделей в продакшен не доходили руки, к сожалению. Надеемся, что в 2021 реализуем эту инициативу, кролик имеет довольно мощный набор инструментов для RL :)
Наши модели vowpal-wabbit используются не совсем для заполнения полки рекомендаций, а для их ранжирования. То есть другой моделью отбираются несколько товаров, которые могут показываться в полке, а vowpal-wabbit скорит каждый из этих товаров и апишка отбирает топ N из них для отображения пользователю.
Python в явном виде остался только в процессе сбора датасетов, но в обучении и валидации он практически не используется, да. На питоне написан только код запуска процессов обучения и валидации в Airflow.
1. Выборка для обучения и валидации делится по пользователям. Мы агрегируем логи за нужный период и группируем по каждому пользователю, а затем начинаем процесс генерации вектора (подсчет g-, u-, s-, p- частей, основываясь на всех предыдущих сессиях и текущих показах/кликах). Прямо перед началом этого процесса мы и делим выборку случайным образом в отношении 4:1, проставляя каждому пользователю тэг train/test, с которым его вектора позже записываются в таблицу.
Изначально делили действительно просто по времени, оставляя последнюю неделю для валидации, но решили, что по пользователям делить будет наиболее честно и не давать модели возможность для переобучения.
2. Думали в эту сторону, но это было бы сложнее поддерживать, как минимум из-за learning_rate: непонятно, как его подбирать при расчете на то, что данные будут бесконечными. При до-обучении модели в реалтайме, нужно следить, чтобы не проседал лосс, и в случае чего быть готовым подменить ее моделькой с другим конфигом, но дообученной на тех же датасетах. А еще если данные будут плохие (например, что-то поменяется в логах или в методе их сборки), то тоже придется модель срочно менять на другую.
В общем, решили, что пока слишком много мороки и реализовали более простой вариант :)
3. Да, vowpal может работать как контекстуальный бандит, на вики действительно большой раздел посвящен описанию разных режимов его работы. У нас проводился эксперимент по обучению бандита, но пока до внедрения таких моделей в продакшен не доходили руки, к сожалению. Надеемся, что в 2021 реализуем эту инициативу, кролик имеет довольно мощный набор инструментов для RL :)