наука о данных с использованием платформы машинного обучения с низким кодом | Действующий ИИ

Как предсказать отток игроков с помощью ChatGPT

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

Введение

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

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

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

Для решения этих проблем появились платформы машинного обучения с малым кодом и без кода с целью упростить процессы машинного обучения и науки о данных, тем самым уменьшая потребность в обширных знаниях в области кодирования. Примеры таких платформ включают Einblick, KNIME, Dataiku, Alteryx и Akkio.

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

Остальная часть этой статьи организована следующим образом:

  1. "Платформа"
  2. Набор данных
  3. Исследовательский анализ данных
  4. Обучение модели классификации
  5. Улучшение производительности модели
  6. Создание новых функций
  7. Обучение новой (надеюсь, улучшенной) модели классификации
  8. Внедрение модели в производство
  9. Выводы

Платформа

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

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

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

Основная библиотека с открытым исходным кодом доступна на GitHub и состоит из нескольких известных и надежных фреймворков, таких как AutoGluon и scikit-learn, которые также являются открытыми и свободно доступными. Это не отличается от других связанных платформ, которые также используют преимущества существующих решений с открытым исходным кодом.

Однако возникает вопрос: зачем вообще использовать такие платформы, если большинство инструментов уже доступны и бесплатны?

Основная причина заключается в том, что эти инструменты требуют знания языков программирования, таких как Python, поэтому любой, кто не знаком с программированием в целом, может столкнуться с трудностями или невозможностью их использования. Следовательно, эти платформы стремятся предоставить все функции в форме графического пользовательского интерфейса (GUI), а не в виде набора программных команд.

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

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

Набор данных

Набор данных, предоставленный игровой компанией, использующей платформу, можно просмотреть здесь, и с ним связана лицензия CC BY-SA-4, позволяющая обмениваться и адаптировать при условии предоставления соответствующего кредита. Он имеет в общей сложности 789 879 строк (выборок), что весьма существенно и должно помочь уменьшить такие эффекты, как переобучение модели.

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

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

Значение каждой функции следующее:

  • Churn: «1», если игрок не играл в игру более 2 недель, «0» в противном случае
  • ServerTime: временная метка сервера, когда уровень был сыгран
  • EndType: причина, по которой уровень закончился (в основном «Победа», если игрок выиграл игру, и «Проигрыш», если игрок проиграл игру)
  • LevelType: тип уровня
  • Level: номер уровня
  • SubLevel: номер подуровня
  • Variant: вариант уровня
  • Levelversion: версия уровня
  • NextCar: не используется (включено, чтобы увидеть, как платформа обрабатывает функции, имеющие только одну метку, как будет показано ниже)
  • AddMoves: доступны дополнительные ходы
  • DoubleMana: не используется (включен, чтобы увидеть, как платформа обрабатывает функции, имеющие только одну метку, как будет показано ниже)
  • StartMoves: количество доступных ходов в начале уровня
  • ExtraMoves: куплены дополнительные ходы
  • UsedMoves: ходы, используемые игроком
  • UsedChangeCar: не используется (включено, чтобы увидеть, как платформа обрабатывает функции, имеющие только одну метку, как будет показано ниже)
  • WatchedVideo: просмотрено ли видео, дающее дополнительные ходы
  • BuyMoreMoves: Сколько раз игрок покупал больше ходов
  • PlayTime: время прохождения уровня
  • Scores: счет, набранный игроком
  • UsedCoins: общее количество монет, использованных на уровне
  • MaxLevel: максимальный уровень, достигнутый игроком
  • Platform: тип устройства
  • UserID: ID игрока
  • RollingLosses: количество последовательных поражений игрока

Исследовательский анализ данных

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

Начнем с проверки основных причин завершения уровней:

На изображении выше мы видим, что основная причина окончания уровня (обозначенная EndType) связана с проигрышем игрока (63,6%) по сравнению с 35,2% игроков, выигравших игру. Мы также видим, что столбец UsedChangeCar кажется бесполезным, поскольку он содержит одно и то же значение для всех строк.

Очень важным наблюдением является то, что наше целевое значение сильно несбалансировано: только 63 выборки из первых 10 000 строк (т. е. 0,6% данных) имеют значение оттока, равное 1 (т. е. игрок ушёл). Это необходимо иметь в виду, потому что вполне вероятно, что наши модели могут быть очень легко искажены, чтобы предсказать только значение 0 для Churn. Причина в том, что модель может достигать очень хороших значений для некоторых показателей, таких как точность; в этом случае, если фиктивная модель просто выбирает наиболее распространенный класс, она будет правильной в 99,4% случаев! Приглашаю вас прочитать об этом подробнее в двух замечательных статьях Baptiste Rocca и Jason Brownlee.

К сожалению, Actable AI пока не предлагает никакого способа обработки несбалансированных данных, например, с помощью Synthetic Minority Oversampling Technique (SMOTE) или с использованием весов классов или других стратегий выборки. Это означает, что нам нужно быть осторожными, когда дело доходит до метрики, выбранной для оптимизации. Как упоминалось выше, точность не будет лучшим выбором, учитывая, что высокая скорость может быть достигнута, даже если образцы одного класса никогда не маркируются правильно.

Другим полезным типом анализа является корреляция между функциями, особенно функциями-предикторами, с целевыми функциями. Это можно сделать с помощью инструмента Корреляционный анализ, результаты которого можно посмотреть прямо на платформе Actable AI здесь:

На приведенной выше диаграмме синие столбцы указывают на положительную корреляцию объекта с Churn, когда значение равно 1, а оранжевые столбцы указывают на отрицательную корреляцию признаков. Следует отметить, что корреляция находится между -1 и 1, где положительные значения означают, что обе характеристики имеют тенденцию изменяться в одном и том же направлении (например, обе увеличиваются или обе уменьшаются), тогда как отрицательная корреляция просто указывает на то, что когда одна из характеристик увеличивается или уменьшается , другой делает наоборот. Таким образом, величина корреляции (без учета отрицательного знака) является, пожалуй, самым важным моментом.

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

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

Обучение модели классификации

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

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

В платформе Actable AI необходимо установить ряд параметров, мой выбор показан ниже:

Также можно выбрать метрику для оптимизации моделей. Я использовал Площадь под кривой рабочих характеристик приемника (AUC ROC), поскольку она гораздо менее чувствительна к проблеме дисбаланса классов, обсуждавшейся ранее. Значения варьируются от 0 до 1 (последнее значение является высшим баллом).

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

Первая отображаемая метрика — это метрика оптимизации со значением 0,675:

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

Этот результат также подчеркивает важность понимания результатов; обычно мы были бы очень довольны точностью 0,997 (т.е. 99,7%). Однако это во многом связано с крайне несбалансированным характером набора данных, как обсуждалось ранее, поэтому этому не следует придавать большого значения. Между тем, такие оценки, как точность и полнота, по умолчанию основаны на пороге 0,5, что может быть не самым подходящим для нашего приложения.

Также показаны ROC и кривые точности-отзыва, которые снова ясно показывают, что производительность немного плохая:

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

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

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

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

Мы также могли бы взглянуть на оценочные вероятности каждого класса (в данном случае 1 или 0), которые используются для получения прогнозируемого класса (по умолчанию класс с наибольшей вероятностью назначается как прогнозируемый класс):

Объяснимый ИИ становится все более важным для понимания поведения модели, поэтому такие инструменты, как ценности Шепли, становятся все более популярными. Эти значения представляют вклад функции в вероятность прогнозируемого класса. Например, в первой строке мы видим, что значение RollingLosses, равное 36, снижает вероятность прогнозируемого класса (класса 0, т. е. того, что человек продолжит играть в игру) для этого игрока.

И наоборот, это означает, что вероятность другого класса (класса 1, то есть того, что игрок сбрасывает) увеличивается. Это имеет смысл, поскольку более высокие значения RollingLosses указывают на то, что игрок последовательно проиграл много уровней и, таким образом, с большей вероятностью прекратит играть из-за разочарования. С другой стороны, низкие значения RollingLosses обычно повышают вероятность отрицательного класса (т. е. того, что игрок не перестанет играть).

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

Улучшение производительности модели

На этом этапе мы можем попытаться улучшить производительность модели. Возможно, один из самых простых способов — выбрать опцию Оптимизировать по качеству и посмотреть, как далеко мы сможем продвинуться. Этот параметр настраивает несколько параметров, которые, как известно, обычно улучшают производительность за счет потенциально более медленного времени обучения. Были получены следующие результаты (которые вы также можете посмотреть здесь):

Снова сосредоточившись на метрике ROC AUC, производительность улучшилась с 0,675 до 0,709. Это довольно приятный прирост для такого простого изменения, хотя все еще далеко от идеала. Есть ли что-то еще, что мы можем сделать для дальнейшего повышения производительности?

Создание новых функций

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

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

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

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

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

Учитывая недавние достижения в области больших языковых моделей (LLM) (например, вы, возможно, слышали о ChatGPT…), и учитывая, что процесс разработки функций может быть немного сложным для неопытных пользователей, мне было любопытно узнать, могут ли LLM может быть вообще полезно для предоставления идей о том, какие функции могут быть созданы. Я сделал именно это со следующим выводом:

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

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

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

Чтобы гарантировать точное вычисление предполагаемого вывода, рекомендуется вручную проверить подмножество результатов, чтобы убедиться, что желаемый вывод вычисляется правильно. Это можно легко сделать, проверив таблицу, которая отображается после запуска запроса в SQL Lab, интерфейсе Actable AI для написания и запуска кода SQL.

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

SELECT 
    *,
    SUM("PlayTime") OVER UserLevelWindow AS "time_spent_on_level",
    (a."Max_Level" - a."Min_Level") AS "levels_completed_in_lastVariantdays",
    COALESCE(CAST("total_wins_in_lastUsedMovesdays" AS DECIMAL)/NULLIF("total_losses_in_lastUsedMovesdays", 0), 0.0) AS "win_to_lose_ratio_in_lastUsedMovesdays",
    COALESCE(SUM("UsedCoins") OVER User1DayWindow, 0) AS "UsedCoins_in_lastChurndays",
    COALESCE(SUM("UsedCoins") OVER User7DayWindow, 0) AS "UsedCoins_in_lastVariantdays",
    COALESCE(SUM("UsedCoins") OVER User14DayWindow, 0) AS "UsedCoins_in_lastUsedMovesdays",
    COALESCE(SUM("ExtraMoves") OVER User1DayWindow, 0) AS "ExtraMoves_in_lastChurndays",
    COALESCE(SUM("ExtraMoves") OVER User7DayWindow, 0) AS "ExtraMoves_in_lastVariantdays",
    COALESCE(SUM("ExtraMoves") OVER User14DayWindow, 0) AS "ExtraMoves_in_lastUsedMovesdays",
    AVG("RollingLosses") OVER User7DayWindow AS "RollingLosses_mean_lastVariantdays",
    AVG("MaxLevel") OVER PastWindow AS "MaxLevel_mean"
FROM (
    SELECT
        *,
        MAX("Level") OVER User7DayWindow AS "Max_Level",
        MIN("Level") OVER User7DayWindow AS "Min_Level",
        SUM(CASE WHEN "EndType" = 'Lose' THEN 1 ELSE 0 END) OVER User14DayWindow AS "total_losses_in_lastUsedMovesdays",
        SUM(CASE WHEN "EndType" = 'Win' THEN 1 ELSE 0 END) OVER User14DayWindow AS "total_wins_in_lastUsedMovesdays",
        SUM("PlayTime") OVER User7DayWindow AS "PlayTime_cumulVariantdays",
        SUM("RollingLosses") OVER User7DayWindow AS "RollingLosses_cumulVariantdays",
        SUM("PlayTime") OVER UserPastWindow AS "PlayTime_cumul"
    FROM "game_data_levels"
    WINDOW
        User7DayWindow AS (
            PARTITION BY "UserID"
            ORDER BY "ServerTime"
            RANGE BETWEEN INTERVAL '7' DAY PRECEDING AND CURRENT ROW
        ),
        User14DayWindow AS (
            PARTITION BY "UserID"
            ORDER BY "ServerTime"
            RANGE BETWEEN INTERVAL '14' DAY PRECEDING AND CURRENT ROW
        ),
        UserPastWindow AS (
        PARTITION BY "UserID"
        ORDER BY "ServerTime"
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
        )
) AS a
WINDOW
    UserLevelWindow AS (
        PARTITION BY "UserID", "Level"
        ORDER BY "ServerTime"
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ),
    PastWindow AS (
        ORDER BY "ServerTime"
        ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
    ),
    User1DayWindow AS (
        PARTITION BY "UserID" 
        ORDER BY "ServerTime" 
        RANGE BETWEEN INTERVAL '1' DAY PRECEDING AND CURRENT ROW
    ),
    User7DayWindow AS (
        PARTITION BY "UserID"
        ORDER BY "ServerTime"
        RANGE BETWEEN INTERVAL '7' DAY PRECEDING AND CURRENT ROW
    ),
    User14DayWindow AS (
        PARTITION BY "UserID"
        ORDER BY "ServerTime"
        RANGE BETWEEN INTERVAL '14' DAY PRECEDING AND CURRENT ROW
    )
ORDER BY "ServerTime";

В этом коде создаются «окна» для определения диапазона времени для рассмотрения, например, последний день, последняя неделя или последние две недели. Записи, попадающие в этот диапазон, будут затем использоваться во время вычислений функций, которые в основном предназначены для предоставления некоторого исторического контекста относительно пути игрока в игре. Полный список возможностей выглядит следующим образом:

  • time_spend_on_level: время, потраченное пользователем на прохождение уровня. Показывает уровень сложности.
  • levels_completed_in_last_7_days: количество уровней, пройденных пользователем за последние 7 дней (1 неделя). Дает представление о сложности уровня, настойчивости и погружении в игру.
  • total_wins_in_last_14_days: общее количество раз, когда пользователь выиграл уровень
  • total_losses_in_last_14_days: общее количество раз, когда пользователь терял уровень
  • win_to_lose_ratio_in_last_14_days: Отношение количества побед к количеству поражений (total_wins_in_last_14_days/total_losses_in_last_14_days)
  • UsedCoins_in_last_1_days: количество использованных монет за предыдущий день. Показывает сложность уровня и готовность игрока тратить внутриигровую валюту.
  • UsedCoins_in_last_7_days: количество использованных монет за предыдущие 7 дней (1 неделя)
  • UsedCoins_in_last_14_days: количество использованных монет за предыдущие 14 дней (2 недели)
  • ExtraMoves_in_last_1_days: Количество дополнительных ходов, использованных пользователем за предыдущий день. Показывает уровень сложности.
  • ExtraMoves_in_last_7_days: количество дополнительных ходов, использованных пользователем за предыдущие 7 дней (1 неделя).
  • ExtraMoves_in_last_14_days: количество дополнительных ходов, использованных пользователем за предыдущие 14 дней (2 недели).
  • RollingLosses_mean_last_7_days: среднее совокупное количество потерь пользователя за последние 7 дней (1 неделя). Показывает уровень сложности.
  • MaxLevel_mean: среднее значение максимального уровня, достигнутого всеми пользователями.
  • Max_Level: Максимальный уровень, достигнутый игроком за последние 7 дней (1 неделя). В сочетании с MaxLevel_mean он показывает прогресс игрока по сравнению с другими игроками.
  • Min_Level: минимальный уровень, сыгранный пользователем за последние 7 дней (1 неделя).
  • PlayTime_cumul_7_days: общее время игры пользователя за последние 7 дней (1 неделя). Дает указание на погружение игрока в игру.
  • PlayTime_cumul: общее время воспроизведения пользователем (с момента первой доступной записи)
  • RollingLosses_cumul_7_days: общее количество прокручивающихся потерь за последние 7 дней (1 неделя). Дает представление об уровне сложности.

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

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

Обучение новой (надеюсь, улучшенной) модели классификации

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

Значение ROC AUC, равное 0,918, значительно улучшено по сравнению с исходным значением 0,675. Это даже лучше, чем оптимизированная по качеству модель (0,709)! Это демонстрирует важность понимания ваших данных и создания новых функций, способных предоставить более подробную информацию.

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

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

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

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

Обучение модели, оптимизированной по качеству, с тем же ограничением по времени, что и раньше, не улучшило производительность. Однако это, возможно, понятно, поскольку используется большее количество функций, поэтому для оптимизации может потребоваться больше времени. Как видно здесь, увеличение лимита времени до 6 часов действительно повышает производительность до 0,923 (в пересчете на AUC):

Следует также отметить, что некоторые показатели, такие как точность и полнота, все еще довольно плохи. Однако это связано с тем, что предполагается порог классификации 0,5, что может быть неоптимальным. Хотя пороговое значение можно изменить, щелкнув кривые, AUC не зависит от порогового значения и может дать более полную картину производительности. Как упоминалось ранее, AUC особенно полезен при использовании в качестве метрики оптимизации при обучении на несбалансированных наборах данных, как в данном случае.

Производительность с точки зрения AUC обученных моделей можно резюмировать следующим образом:

┌─────────────────────────────────────────────────────────┬───────────┐
│                         Model                           │ AUC (ROC) │
├─────────────────────────────────────────────────────────┼───────────┤
│ Original features                                       │     0.675 │
│ Original features + optim. for quality                  │     0.709 │
│ Engineered features                                     │     0.918 │
│ Engineered features + optim. for quality + longer time  │     0.923 │
└─────────────────────────────────────────────────────────┴───────────┘

Развертывание модели в производстве

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

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

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

Выводы

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

Был рассмотрен весь конвейер обработки, от EDA до обучения модели и разработки признаков. Было обеспечено обсуждение интерпретации результатов и способов их улучшения, чтобы перейти от значения 0,675 к значению 0,923 (где 1,0 — максимальное значение).

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

Что касается платформы Actable AI, я, конечно, могу быть немного предвзятым, но я думаю, что она помогает упростить некоторые из наиболее утомительных процессов, которые должны выполнять специалисты по данным и специалистам по машинному обучению, со следующими желательными аспектами:

  • Библиотека Core ML имеет открытый исходный код, поэтому ее безопасность может быть проверена любым человеком, обладающим хорошими знаниями в области программирования. Его также может использовать любой, кто знает Python.
  • Для тех, кто не знает Python или не знаком с кодированием, графический интерфейс предлагает способ использовать ряд аналитических данных и визуализаций без особых усилий.
  • Начать пользоваться платформой несложно (она не перегружает пользователя слишком большим количеством технической информации, которая может отговорить менее осведомленных людей от ее использования)
  • Уровень бесплатного пользования позволяет запускать аналитику общедоступных наборов данных.
  • Доступно огромное количество инструментов (помимо классификации, рассмотренной в этой статье)

Тем не менее, есть несколько недостатков, хотя некоторые аспекты можно было бы улучшить, например:

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

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

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

Что вы думаете об этой статье? Пожалуйста, не стесняйтесь публиковать заметки, комментарии или сообщения прямо на LinkedIn!

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

На момент написания этой статьи автор был специалистом по данным с Actable AI.