Введение для введения

Эта статья и проект были сделаны для финала машинного обучения пару месяцев назад. Там много объяснений бейсбола и того, как работает Statcast — это нужно моему профессору. Проект также является спин-оффом моего питч-грейдера, о котором я писал здесь.

Поскольку над этим работали в более короткие сроки, результат оказался скорее доказательством концепции, но все же хотелось поделиться этим и опубликовать в Интернете!

Введение

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

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

Проблема

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

Например, если бы «Хьюстон Астрос» шли к своему ближайшему Райану Прессли, чтобы закончить игру, какие подачи Прессли бросил бы против нападающих соперника, чтобы получить наилучшие результаты? В качестве альтернативы, если Прессли не лучший вариант против будущих нападающих, кого еще можно использовать в КПЗ?

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

Данные и предварительная обработка

MLB — одна из немногих, если не единственная лига, у которой есть общедоступный набор данных со многими показателями, собранными во время игр. Эти цифры можно найти и загрузить на Baseball Savant, приборной панели лиги и хранилище указанной статистики. Чтобы упростить процесс сбора и обработки данных, использовалась функция statcast из пакета Python baseball_scraper. Было собрано около 700 000 подач за сезон 2022 года, каждая из которых имеет показатели подачи (например, скорость, вертикальное/горизонтальное движение, скорость вращения), показатели попадания (например, угол запуска, скорость выхода, угол распыления) и контекстуальные переменные (иннинг, мячи). , забастовки).

Чтобы оценить качество поля или события по непрерывной количественной шкале (вместо качественного значения (страйк-аут, базовое попадание и т. д.), будут использоваться значения пробега. Значения пробега — это количество проходов в конкретном событии. стоит в среднем за весь сезон. Это рассчитывается путем группировки событий в более общие категории, а затем с помощью столбца «delta_run_exp» в журнале полей Savant, чтобы найти среднее изменение количества пробегов в этих категориях. Категории событий были сгруппированы по типы отбитых мячей (флай, наземные мячи, линейные удары, хлопающие мячи) и неотбитые мячи (многочисленные типы ударов, мячей). за аут) стоит меньше всего.

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

Методология

Первоначально планировалось обучить модель для каждого уникального нападающего и провести подачу питчера через эту модель, чтобы полностью понять сильные и слабые стороны нападающих и соответствующим образом спланировать игру. Однако после первоначальных экспериментов возникли проблемы с размером выборки, поскольку нападающие видели около 1000 полей в течение всего сезона (Риз Хоскинс из Филлис возглавил лигу с 1601). Кроме того, меньший размер выборки каждого исполнителя означал, что нельзя было использовать более мощные ансамбли.

Кластеризация нападающих

Чтобы решить эту проблему, нападающие были объединены в более крупные группы в зависимости от их результатов на разных полях, рук питчера и местоположения. Для каждого нападающего было рассчитано среднее значение пробега по полям в зонах 1–9, типам подачи (быстрые мячи, разбивающие мячи, вне скорости) и в разных подсчетах (четный, питчер / нападающий вперед, 2-страйк), разделенный вверх, противостоя правым и левым питчерам.

После того, как эти данные были рассчитаны, была использована кластеризация K-средних для поиска более общих групп попаданий. Были использованы четыре K-средних (R/LHP против R/LHH) для определения типов нападающих в различных сценариях сопоставления. Группы были созданы путем рекурсивного тестирования различных «n_clusters» и поиска кластеров с наивысшим показателем силуэта. Это создало девять подгрупп из всех матчей сезона 2022 года, и если бы модель была обучена на каждой из этих групп, не было бы проблем с размером выборки, и для моделирования матчей можно было бы использовать более крупные и мощные модели. задача. У каждого нападающего будет две группы, одна против питчеров-левш и правшей соответственно.

Выбор модели

Группа из одного из девяти кластеров (один из кластеров RvR) была выбрана для выбора модели и перекрестной проверки, чтобы решить, какая из них лучше всего подходит. Были выбраны следующие характеристики:

  • release_speed: скорость подачи мяча в милях в час.
  • release_spin_rate: скорость вращения мяча в оборотах в минуту.
  • release_extension: расширение питчера при подаче вперед, в футах
  • spin_axis: ось, по которой вращается мяч, в градусах
  • pfx_x/pfx_z: вертикальное и горизонтальное перемещение поля в футах.
  • release_pos_x/release_pos_z: координаты точки выпуска питчера, в футах.
  • мячи/удары: категориальные данные закодированы
  • R/L: средний показатель пробега нападающих соперников на 100 бросков против L/RHP (в зависимости от матча)
  • зона: местоположение высоты тона, закодировано
  • rv (переменная ответа): запустить значения

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

Значения масштабировались с использованием объектов StandardScaler и Pipeline, а затем тестировались в моделях Linear, Ridge, Random Forest, Decision Tree и XGBoost. Для Random Forest, Decision Tree и XGBoost перекрестная проверка была выполнена для гиперпараметра max_depth с использованием GridSearchCV. Для создания модели использовался обучающий набор из 75% строк, а оставшиеся использовались для тестирования. Несмотря на то, что Random Forest превзошел XGBoost на тестовом наборе, XGBoost был выбранной моделью, поскольку для обучения требовалось намного меньше времени, а разница между оценкой R2 не казалась значительной.

Неудивительно, что линейные модели оказались хуже, поскольку между некоторыми переменными, такими как вращение и векторы движения, нет линейной зависимости. Дерево решений, вероятно, превосходит обучающие данные даже при масштабировании. С этим борется случайный лес, который усредняет результаты нескольких деревьев решений, которые также улавливают потенциальный шум; то же самое можно сказать и о модели XGBoost. Хотя существует опасность того, что XGBoost является алгоритмом «черного ящика» и вызывает или подразумевает корреляцию между переменными там, где ее нет, это не слишком беспокоило из-за аналогичных результатов, которые он показал со случайным лесом.

Что касается, казалось бы, низких показателей R2, это не должно быть большой проблемой, поскольку этот проект, по сути, становится оценщиком питча, который сегментирован между различными типами нападающих. Объединяя матчи в подгруппы, он в некоторой степени исключает отдельного нападающего из уравнения. Оценка R2 около 0,1 / 0,11 означает, что то, что бросает питчер, составляет всего десять процентов от результата подачи, который кажется правдой при визуальном тесте. Есть и другие переменные, такие как нападающий, факторы ветра и парковки, а также защита, которые влияют на результат события. Кроме того, хотя точные прогнозы для каждого шага не идеальны, цель этого проекта состоит в том, чтобы ранжировать различные варианты шагов, а не найти точный результат.

Реализация

В интересах экономии времени были реализованы только три группы RvR. Конвейерный объект масштабатора и модели XGBoost был создан и перекрестно проверен с помощью GridSearchCV, просматривая «max_depths» от 5 до 15. Затем эти модели были сохранены в виде файлов .sav с использованием пакета Pickle для легкого доступа в будущем, будь то исследование или тест. Это сохраняет настроенные параметры, а также StandardScaler, чтобы упростить предварительную обработку, необходимую для прогнозирования значений с помощью этих моделей в любом наборе данных.

Наиболее важными характеристиками при определении эффективности подачи была сама подача, начиная с движения (pfx_x/z) и скорости. Угол выброса и удлинение кувшина не так важны.

Результаты и анализ

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

По словам Райана Прессли (RHP) и Трэвиса д'Арно, которые не встречались в сезоне 2022 года, выбираются питчер и нападающий. Показатели Прессли усредняются для каждого броска, который он бросает (быстрый мяч, слайдер, крученый мяч, чейнджап), и извлекается среднее значение пробега д'Арно против RHP и групп.

Подача Прессли прогнозируется в каждой зоне (1–9) и подсчитывается каждое попадание мяча (12 комбинаций) с помощью модели RvR Group 2 (к которой принадлежит д’Арно). В результате было предсказано 432 значения пробега потенциальных вариантов подачи.

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

Предлагаются пять лучших комбинаций шаг-местоположение с ожидаемым значением пробега (xrv) для каждой. xRV+ поля, которое показывает, как значение пробега этого поля сравнивается со средним значением матча, равное 100. XRV+, равное 110, означает, что поле в десять раз лучше, чем среднее значение подачи, брошенное во всех матчах группы 2 RvR. Глядя на это, матч Райана Прессли против Трэвиса д'Арно очень благоприятен, особенно если Прессли работает в основном со своими разбивающими мячами (слайдеры, крученые мячи).

С другой стороны, если питчер низкого качества, такой как Джерис Фамилия (6,09 заработанного среднего пробега против 2,98 у Прессли), встречается с д'Арно, прогнозируемые результаты не выглядят такими хорошими, независимо от типа подачи. Таким образом, если у менеджера есть и Прессли, и Фамилия, которые могут встретиться с д'Арно в КПЗ, то нетрудно предположить, что Прессли будет вариантом. Глядя на значения xrv+, Pressley, вероятно, получит на 10% лучшие результаты, чем Familia. Кроме того, с точки зрения проверки работоспособности, это приятно видеть.

Заключительные мысли, будущая работа

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

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

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

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

Наконец, будет проверена перекрестная проверка других гиперпараметров, таких как n_estimators. Запуск GridSearchCV с несколькими параметрами может занять несколько часов для каждой модели, и в интересах временной шкалы этого проекта была перекрестная проверка только max_depth.