Печальная правда исследований RL в рекомендациях

Одна из самых частых фраз, которые я вижу в статьях на эту тему, звучит примерно так:
"To perform evaluation of RL methods, a straightforward way is to evaluate the learned policy through online A/B test, which, however, could be prohibitively expensive and may hurt user experiences".

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

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

Да, может быть, для какой-то отладки и быстрой проверки симулятор не помешает (а сделать его это уже боль), но в огромном количестве статей проверка на симуляторе является окончательной проверкой метода, и это полная печаль.

Я понимаю, что не у всех есть настоящий сервис с пользователями. Но печальная правда состоит в том, что если вы не можете протестировать рекомендательный RL-метод в реальной среде, то вам нужно рассмотреть вопрос смены темы исследования 😄

А что делать, если у вас всё-таки есть сервис, но вы боитесь выкатить в прод плохую модель?
1) Тестируйте на маленькой выборке
2) Тестируйте ансамбль вашей модели и текущего продакшна, постепенно увеличивая вес новой модели

Картинка из того же мета-обзора.

@knowledge_accumulator