Привет! Меня зовут Алексей Мельников, я продакт в KION (онлайн-кинотеатр от МТС Digital), занимаюсь фичами, связанными с искусственным интеллектом. 

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

Autoplay позволяет не бросать еще «теплого» зрителя во время просмотра и предлагать ему новый фильм сразу после окончания предыдущего. Система рекомендаций сама подбирает контент, наиболее похожий на тот, что смотрит зритель. Новый фильм запускается в автоматическом режиме при наступлении титров, если пользователь бездействует.

Когда начинаются титры – мы уводим их в pip в левый нижний угол экрана и на бэке показываем постер следующего похожего фильма. В правой нижней части экрана показываем кнопки Следующий фильм и Смотреть титры. И если пользователь бездействует n секунд (этот параметр настраивается) – включаем следующий похожий фильм. Как это выглядит – показываю ниже:

Почему мы внедрили эту фичу?

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

• мы созрели с точки зрения бэка и научились работать с i2i – item to item, подробно об этом ниже;

• мы боремся не только с конкурентами, но и за внимание зрителя, который в момент окончания фильма решает, чем ему заняться дальше. Поспать? Погулять? Или посмотреть еще один фильм? Autoplay как раз подталкивает зрителя к дальнейшему просмотру.

А что под капотом?

Об этом подробно рассказывает Глеб Волохов, ведущий ML-разработчик KION:

Для стабильной и надежной работы ML-решений в продакшене необходимы:

• полное версионирование моделей;

• возможность быстро откатиться до какой-то конкретной версии модели (например, предыдущей);

• контроль и хранение истории онлайн и оффлайн – метрик качества;

• полная повторяемость пайплайнов в любой момент времени;

• удобство и простота разработки для датасаентистов, а также их независимость от бэкенд разработчиков.

Также очень желательно максимально исключить человеческий фактор на всех этапах деплоя.

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

• MLFlow – центральный компонент, отвечающий за отслеживание экспериментов, метрик, регистрацию моделей, а также, после небольшой доработки, выступающий инициатором автоматической раскатки моделей;

• Gitlab репозиторий c dvc (mldatasets) – этот репозиторий используется для хранения датасетов для обучения и их версионирования;

• Vanga – микросервис для моделей, обеспечивающий унифицированное API для работы с моделями;

• MLTrainer – микросервис, который запускает модели учиться, принимает решение о раскатке и раскатывает новую версию модели в продакшен;

• Ailflow – распространенное решение для выстраивания etl-процессов, в нашем случае даги периодически собирают датасеты для обучения и складывают в соответствующий репозиторий, анализируют нужно ли какую-то из моделей поучить и в случае успеха инициируют запуск нашего MLTrainer;

• Telegram-чат – используется для информирования.

Остановимся на каждом из компонентов подробнее: 

MLFlow

В MLFlow используется бэкенд – postgres 14.0, хранилище для артефактов – S3. Для того, чтобы обеспечить дальнейшую автоматическую раскатку зарегистрированных в MLFlow моделей, на таблицу в БД postgres, отвечающую за регистрацию моделей, были повешены сигналы, которые отлавливаются специальным сервисом. В зависимости от того, в какое состояние с точки зрения MLFlow переходит зарегистрированная модель, – вешаются хуки.

Например, при переходе из состояния 'None' в состояние 'Staging' происходит валидация входных параметров и дальнейшая раскатка микросервиса, отвечающего за API к этой модели. При переходе в состояние 'Archived' модель прекращает свою работу в продакшен контуре. Все действия дублируются ботом в наш служебный чат. В том числе, если в процессе раскатки не прошла какая-то валидация, информация об ошибке будет отправлена в чатик, а модель будет автоматически возвращена в состояние 'None'.

Каждая модель оформляется в виде MLFlow-проекта и имеет два обязательных эндпоинта: train и test. Train – эндпоинт, необходимый для автоматического переобучения модели на новых данных. В качестве обязательных входных аргументов эндпоинт принимает версию датасета из репозитория mldatasets.

Это необходимо для  динамического влияния на версию данных, на которых мы хотим обучить нашу модель. Test – также принимает версию датасета и считает оффлайн-метрики, которые отслеживаются в MLFlow. Основываясь на метриках, наш автоматический тренер принимает решение, нужно ли новую версию модели выкатывать в продакшен. 

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

• в любой момент мы можем откатиться на предыдущую версию;

• в процессе трекинга наших экспериментов в MLFlow регистрируется и версия коммита, что позволяет на всех этапах отслеживать, что версия модели и версия кода консистентны;

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

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

Mldatasets

Mldatasets – это gitlab-репозиторий с dvc, для которого настроен в s3 bucket с expire – 30 дней. Для каждого проекта своя ветка, а датасеты собираются в него по расписанию дагами из airflow. Даги собирают данные из различных источников (clickhouse, mongo и так далее), предобрабатывают, агрегируют и помещают в нужную ветку. Так появляется единая точка входа для получения датасетов, они единообразны и уже предобработаны. Также получаем жесткую версионированность, что для нас критически важно.

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

Vanga

Это микросервис, обеспечивающий унифицированное API для взаимодействия с моделями. Микросервис написан на fastapi, обертка на модель подключается как сабмодуль, необходимая версия для каждой конкретной модели берется из MLFlow вместе с некоторой необходимой для раскатки мета-информацией. Например, можно задать вот что: назначение модели (как i2i), персонализацию витрины, включен или выключен режим автотренировки моделей.

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

Airflow

Бэкенд, который отдает для нашего кинотеатра рекомендации i2i забирает их из redis. Наполняется redis дагом, логика работы которого следующая:

• узнать, какие модели для i2i находятся в состоянии 'Production' с соответствующей мета-информацией (куда делать запрос);

• получить рекомендации от соответствующего экземпляра микросервиса Vanga;

• сохранить в Redis.

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

MLTrainer

Компонент, отвечающий за переобучение моделей, принятие решений о выкатке новой версии модели и перевод текущей версии в архив. Сервис развернут на собственных мощностях МТС Медиа, оборудованных видеокартами Nvidia Tesla V100.

MLTrainer запускает для модели эндпоинт train, затем test, собирает оффлайн метрики после текущего обучения и предыдущих N обучений активной модели, принимая решение нужно ли текущую версию модели перевести в 'Archived' и раскатить новую версию модели в продакшен. При проседании оффлайн метрик модель не катится в продакшен, а разработчик получает уведомление об этом с ссылкой на run в MLflow. 

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

Основной стек: MLFlow, Gitlab CI/CD, Fastapi, TensorFlow, Postgres, S3, Vuepress   

Каким был фидбэк от юзеров?

Занимательным. Например, мы обнаружили, что некоторые пользователи, смотрят нон-стопом фильмы на смартфонах. Как мы это выяснили? У нас после просмотра 3 фильмов подряд всплывает сообщение:

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

С точки зрения цифр мы получили следующие результаты:

После внедрения фичи мы увеличили один из наших ключевых показателей Total View Time Unique – количество минут смотрения в среднем на одного юзера. А еще мы увеличили среднюю длину сессии. 

При этом количество зрителей, которые досматривают рекомендованный контент, находится в пределах 30-40%.

Что дальше?

В будущем мы планируем протестировать гипотезу о том, что пользователю нужен выбор: несколько вариантов контента, которые он может смотреть.

Идея такая – давать ленту с контентом в виде рекомендаций похожих фильмов в момент появления титров. 

Кроме того мы планируем улучшать качество модели i2i и рекомендовать не только фильмы, но и сериалы.

Спасибо за внимание! Увидимся в KION!)