Автор данной статьи – Симон Рольфес. Симон сыграл 288 матчей в Бундеслиге в качестве центрального полузащитника, забил 41 гол, и провёл 26 матчей за сборную Германии. На данный момент он работает спортивным директором в леверкузенском «Байер 04», где помогает с развитием состава первой команды, отдела скаутинга, а также занимается молодёжным развитием в клубе. Симон еженедельно пишет статьи для Bundesliga.com про последние продвинутые статистические данные по матчам, предоставляемые Amazon Web Services (Bundesliga Match Facts powered by AWS). Он представляет свою экспертизу как бывший игрок, капитан и телевизионный эксперт, чтобы подчеркнуть воздействие продвинутой статистики и машинного обучения на мир футбола. В этой статье Симон анализирует важность некоторых новых статистических данных (в Bundesliga Match Facts powered by AWS), которые фанаты смогут наблюдать в течение сезона 2021/22. Далее команда The AWS Professional Services погружается в детали технологии AWS, стоящей за этой продвинутой статистикой.
Разработка Bundesliga Match Fact Passing Profile
Пасы – одно из самых распространенных действий на поле. Проще говоря, пас – это передача мяча от одного игрока другому игроку своей команды. «Проще» - это слово, ежедневно используемое каждым тренером, когда речь заходит о пасах: «Будь проще». Тем не менее, глядя на эффект, который пас может оказать на матч, всё не так просто.
Рассмотрим такой пример: в сезоне Бундеслиги 2020/21 в среднем в матче выполнялось 917 передач. Рекорды сезона по наибольшему и наименьшему количеству совершенных передач были установлены в одном матче, когда в 26 туре Арминия Билефельд принимала РБ Лейпциг. Арминия сделала 152 передачи, тогда как Лейпциг – 865. В традиционной футбольной аналитике количество совершенных передач зачастую является индикатором доминирования команды. Учитывая приведенные данные, вы можете быть удивлены, что Лейпциг выиграл с минимальным преимуществом – 1:0.
Или же возьмём индивидуальные показатели игроков: в сезоне 2020/21 среднестатистический футболист Бундеслиги совершил 86% точных передач, но индивидуальные цифры разнятся от 22% до 100%. Если наивысший процент точности реально отражает доминирование, то что если игрок с 22% каждым точным пасом выводил нападающего на ударную позицию, идеально отрезая по несколько защитников соперника? И что нам говорит статистика в 100% точных передач, если это защитник, отдающий мяч горизонтально другому защитнику, потому что он не способен находить напарников по команде передачей вперёд? Опять же, горизонтальные передачи тоже могут быть отличным инструментом в атаке, открывая зоны за счёт перевода мяча на противоположный фланг.
Итак, существуют мириады типов передач, используемых по огромному количеству причин. Что тогда делает пас особенным, и как игроки используют пасы в разных ситуациях для продвижения мяча?
Именно это раскрывает новый Bundesliga Match Fact Passing Profile, предоставляя в режиме реального времени инсайты/информацию по способностям всех игроков и команд в Бундеслиге пасовать. Модели машинного обучения (далее - МО), обученные на Amazon SageMaker, проанализировали около 2 миллионов пасов из предыдущих сезонов Бундеслиги, чтобы построить алгоритм, способный просчитать сложность каждого паса в любой момент времени. Для начала просчитываются 26 характеристик паса для каждой передачи в AWS Glue. Эти особенности паса, разработанные в сотрудничестве с группой экспертов, включают в себя дистанцию до получателя, количество защищающихся игроков между пасующим и адресатом, давление, под которым находится отдающий, и многое другое. Затем эти данные вносятся для обучения МО в SageMaker, чтобы просчитывать влияние каждой характеристики на вероятность успеха передачи.
После того, как модель обучена, она способна проводить оценку сложности для каждой передачи, которую она видит. Эти уровни сложности в дальнейшем могут использоваться самыми разными способами. Например, они могут быть собраны по каждому игроку для составления профиля передач, показывающего, какие решения принимают игроки для паса. Ставят ли они в приоритет атакующий пас? Ищут ли они безопасный вариант, пасуя мяч назад? Или же они ищут открывания для дальней передачи. Всё это охватывается в «профиле передач» Match Fact (Match Fact «Passing Profile»), который демонстрирует направление передач и оценку сложности по каждому по каждому игроку в прямом эфире по телевизору или в приложении Бундеслиги.
В следующем разделе команда AWS Professional Services, работавшая с Бундеслигой над созданием Match Facts, объясняет, как эта продвинутая статистика воплощалась в жизнь.
Как это работает?
Построение модели МО, способной предсказывать трудность совершаемой передачи, требовала от нас создания обширного набора данных, наполненной как точными, так и неточными пасами из прошлого. Насколько много известно об успешных пасах (например, получатель, местонахождение, где мяч контролировался, длительность и расстояние паса), настолько же мало мы знаем о неуспешных пасах, просто потому, что они не доходят до намеченной цели. Поэтому мы применили подход, предложенный Анцером и Бауером (возможно речь о Габриеле Анцере и Паскале Бауэре и об этой статье ) для определения предназначаемого получателя неуспешного паса, используя траекторию полета мяча и модель движения, чтобы мы могли добавить эти вводные в наш набор данных передач.
Определение цели назначения
Мяч должен подчиняться законам физики, хоть иногда так и не кажется. Мы можем использовать гравитацию, сопротивление воздуха и катящееся сопротивление для отображения траектории паса. С физической моделью, предложенной Спирменом и Басье (2017) (возможно речь о Уильяме Спирмене и Остине Т. Басье и об их статье) мы можем использовать первые 0.4 секунды после того, как пас был отдан, для отображения всей траектории мяча. Физическая модель на следующей иллюстрации оценивает траекторию, основываясь на промежутке времени в 0.4 секунды. Этот просчитанный путь отмечен на картинке оранжевым (прим.ред. – это дословный перевод, на картинке же просчитанный путь отмечен черным). В этом примере игрок под номером 11 из синей команды пытается начать атаку пасом на игрока под номером 32, который делает забегание по правому флангу. Для оценки нашей физической модели мы можем сравнить предполагаемую траекторию мяча с фактической, предоставленной отслеживающими/трекинговыми данными, отмеченной черным (прим.ред. – так же дословный перевод, на картинке фактический путь отмечен оранжевым). Сравнение обеих траекторий показывает, что предполагаемая траектория достаточно близка к реальности. Однако данная модель не учитывает силу сопротивления после касания мяча с полем (в зависимости от погодных условий) и не учитывает крученые мячи, т.к. эта информация недоступна в рамках отслеживающих / трекинговых данных.
После того, как траектория мяча смоделирована, мы знаем, где он предположительно должен приземлиться. Следующий шаг – просчитать, кто может достичь мяча. Это делается моделью движения. Эта модель движения оценивает зону, в которой может оказаться игрок за определенный временной отрезок, и во многом основана на скорости и направлении движения игрока. Модель сравнивает данные о движении игроков за предыдущие три сезона Бундеслиги для понимания, как игроки двигаются. Результаты могут быть визуализированы в виде четырёх кругов вокруг каждого игрока, представляя зоны, которые они достичь в течение 0.5,1,1.5 и 2 секунд.
Потенциальное движение каждого игрока просчитывается и сопоставляется с предполагаемым местом приземления мяча. Предполагая, что мяч может контролироваться, когда он находится на высоте ниже полутора метров высоты, мы можем сделать оценочную догадку, который из игроков может первым оказаться на мяче. Теперь, для оценки предназначенного адресата отданной передачи, мы совмещаем модель траектории мяча с моделью движения. Если мы отобразим траекторию неудачного паса, мы можем использовать нашу модель движения для определения игрока, который первым может добраться до мяча. Этот игрок вероятнее всего и является адресатом, которому был предназначен пас. Затем мы можем использовать эту информацию, чтобы добавлять актуальные/релевантные пункты данных (таких как адресат, зона, в которой мяч контролировался, длительность и дистанция паса) для неудачных передач в наш набор данных.
Трудность передач
Мы можем использовать МО для оценки трудности каждого паса. Мы используем набор данных, содержащий 2 миллиона пасов из предыдущих сезонов Бундеслиги, для обучения контролируемой модели МО, просчитывающей вероятность выполнения паса для каждого из этих пасов. Это просчитывается за счет нахождения паттернов/шаблонов в отдельных характеристиках, доступных в момент совершения передачи. Эти характеристики были разработаны в сотрудничестве с группой футбольных экспертов для понимания релевантных аспектов, воздействующих на трудность передачи. Алгоритм МО определяет, какие характеристики имеют воздействие, а какие являются незначительными. Результаты алгоритма используются моделью для предсказания вероятности успешной передачи.
Профиль передач и эффективность
Мы можем использовать данную модель передач или xPass (ожидаемые пасы) для оценки профиля передач игрока и эффективность его пасов. Профиль передач состоит из решений игрока при передачах. Ищет ли игрок короткие или средние передачи, отдаёт налево или направо, и насколько сложны пасы, которые игрок пытается отдать? Мы можем использовать модель xPass, чтобы оценить, насколько эффективен игрок в принятии решений при передачах и впоследствии оценивать его воздействие на игру.
Профиль передач отображается в двух видах во время прямых трансляций. График слева (первый график) отображает направление, в котором игрок предпочитает развивать игру в текущем матче, включая главное направление передач и раздачу пасов до данного момента времени. График справа (второй график) показывает дополнительную статистику, которая дополняет направление передач такими данными, как количество попыток трудных передач, включая процент успеха и соотношение коротких и длинных передач.
Эта статистика дополнительно раскрывается в конце первого и начале второго тайма, используя формат графического сравнения. В этом шаблоне сравнения два игрока могут сравниваться в их профилях передач, демонстрируя разницу в принимаемых решениях так же, как и в проценте точности.
Вдобавок к профилям передач фанаты также могут изучать эффективность передач среди игроков Бундеслиги. В разделе статистики в приложении Бундеслиги пользователи могут видеть эффективность игроков через сравнение их фактически совершенных пасов по отношению к ожидаемым совершенным пасам (по модели xPass). Это предоставляет гораздо более объективный взгляд на способность игроков пасовать в сравнении с обычной статистикой по количеству передач и проценту точности.
В этом обзоре сложность паса рассматривается в перспективе. Например, допустим у нас есть два игрока, и оба выполняют по две передачи. Игрок А выполняет два сложных паса с ожидаемой вероятностью успеха в 40%. Игрок Б отдает две простых передачи с ожидаемой вероятностью успеха в 95%. Оценка обоих игроков при помощи старых метрик приведёт к результату, где оба игрока выполнили по 2 передачи с точностью 100%. С новой моделью xPass мы на самом деле видим, что от игрока А ожидалось 0.8 выполненных передач (40%+40%), тогда как фактически он сделал 2 передачи, что в оценке эффективности составит 2-0.8=1.2 передач. Соответсвующий овер-перформанс (соответственно он превышает ожидаемый результат) на 1.2 передач. Игрок Б выполняет два паса с вероятностью успеха в 95%, соответственно ожидаемый от него результат – 1.9 передач. Фактически сделано 2 передачи. Э то даёт овер-перформанс из 2-1.9=0.1 передач. Игрок Б исполняет примерно так, как и ожидается, тогда как игрок А выдаёт топ исполнение.
Давайте рассмотрим на примере двух игроков, играющих на одной и той же позиции (правый защитник), Ларс Бендер (Байер 04 Леверкузен) и Штефан Ляйнер (Боруссия Мёнхенгладбах) в 23 туре сезона 2020/21. Глядя исключительно на точность передач кажется, что Бендер явно превосходит Ляйнера, выполнив около 90% точных передач. Ляйнер же выполнил только 60% своих передач и похоже сильно отстаёт. Однако, если рассмотреть поподробнее, мы обнаруживаем, что Ляйнер около 80% своих передач делает вперёд. С другой стороны, у Бендера только 15% передач идут вперёд, и, похоже, что для него в приоритете безопасные пасы назад. Видеть рискованное поведение и атакующие намерения у игроков было невозможно ранее со стандартными метриками.
Профиль передач и эффективности позволяет нам проводить такие сравнения между игроками, какие ранее не представлялись возможными. Это позволяет видеть нам, какие игроки обладают исключительными способностями передач и какие игроки не могут найти товарищей по команде.
Обучение модели профиля передач
Модель профиля передач – лишь верхушка айсберга; в закулисье мы должны положиться на несколько важных операций, таких как продолжающееся обучение, постоянные улучшения в модели, постоянное развертывание новых моделей, наблюдение (мониторинг) за моделью, отслеживание метаданных, происхождение/родословная модели и развертка на множество учетных записей. Для решения этих особенностей индустриализации моделей МО, мы создали конвейеры обучения и развертывания. Кроме того, в предвкушении будущего развития дополнительных Match Facts, мы также посвятили время разработке многоразовых конвейеров обучения и развертывания моделей. Эти общие конвейеры разработаны и реализованы при помощи AWS Cloud Development Kit (платформа разработки ПО с открытым исходным кодом, далее – AWS CDK). Шаблонизация этих конвейеров гарантирует последовательную разработку новых Match Facts, сокращая объём усилий и времени на реализацию/продажу.
Наша архитектура учитывает все три этапа: разработку, постановку и производство. Учитывая экспериментальный характер обучения модели, фактический конвейер обучения находится в нашей среде разработки. Это позволяет нашим Data- и МО-инженерам свободно работать и экспериментировать с новыми особенностями/фичами и анализом.
После того, как команда тестирует новую модель и остаётся удовлетворена результатами, мы переводим модель из стадии разработки в стадию постановки через цепочку одобрений (пулл-реквесты) на BitBucket (аналог GitHub) . После дальнейшего тестирования на этапе постановки мы проводим аналогичный процесс от постановки до производства, чтобы новая модель была доступна для дальнейшей настройки/живой настройки.
Для непрерывности рабочего процесса мы используем AWS Step Functions (сервис для координации компонентов приложений через визуализацию рабочих процессов), где все этапы определяются при помощи AWS CDK. AWS CDK генерирует шаблон AWS CloudFormation, содержащий определения конечного состояния для библиотеки сервиса (дословно – конечного автомата) Step Functions на языке Amazon States Language.
Использование AWS CDK и Step Functions позволяет нам создавать одинаковые экземпляры базового обучающего конвейера для разных Match Facts. Данная настройка является гибкой и адаптируемой под различные требования конкретных Match Facts. Например, мы можем регулировать параметры на конкретном этапе, таком как заложение основ алгоритма МО. Мы также можем добавить, убрать и регулировать новые этапы без необходимости вмешательства в корневую структуру обучающего конвейера. Таким образом, наши data-ученые/data-исследователи могут фокусироваться на создании наилучших моделей Match Facts, не будучи обременёнными созданием инфраструктуры и обслуживанием операций.
У нас есть два основных рабочих процесса (конечных автомата) для любого образца обучающего конвейера модели Match Fact: первый – конвейер по предварительной обработке данных и второй – конвейер для фактического обучения. Эта настройка позволяет избегать запуска предварительной обработки тысяч матчей при каждом обучении новой модели. Соответственно, мы можем экспериментировать с разными параметрами обучения модели, экономя время и деньги на предварительной обработке данных. И, наоборот, можем экспериментировать с созданием новых фич/фишек без необходимости немедленно тратиться на обучение модели сразу же.
Следующая диаграмма показывает, как работает конвейер по предварительной обработке данных:
Конечные автоматы состоят из разных работ в AWS Glue, функций в AWS Lambda, и работ в SageMaker для предоставления сквозной гибкости нашим data-учёным/data-исследователям. Процесс предварительной обработки отвечает за предварительную обработку данных, где определенная функция Lambda (шаг 1)динамически извлекает данные по матчу из сохранённой информации, которые затем подаются на обработку в AWS Glue (шаг 2), где обрабатывается извлечение особенностей из полученных необработанных данных по матчу. С позиционной природой данных по матчу, у нас есть много данных, нуждающихся в предварительной обработке перед обучением. Благодаря картографической/позиционной функции в Step Functions, мы можем запускать процессы в AWS Glue параллельно, что позволяет нам сэкономить время на предварительной обработке. В итоге AWS Glue сохраняет обработанные данные по матчу в Amazon Simple Storage Service (сокр. - Amazon S3), для использования конечным автоматом обучения модели.
Следующая диаграмма иллюстрирует наш конвейер обучения:
Рабочий процесс обучающего конвейера начинается с одиночной задачи AWS Glue (шаг 3), которая объединяет все обработанные данные матча с предыдущего этапа, затем перемешивает и распределяет их по трём наборам данных: обучение, проверка и тестирование.
Наборы данных обучения и проверки используются для тренировки и поиска наилучших гиперпараметров для модели, применяя автоматическую регулировку/настройку модели SageMaker (шаг 4). Тестирование данных используется нашими data-учеными/data-исследователями для оценки и анализа результатов и метрик модели; например, для обнаружения проблем в нашем обучении, таких как недо- или переоснащение. Результат работ SageMaker по регулировке/настройке – модель с гиперпараметрами, обладающими наилучшей производительностью/эффективностью.
После того, как мы произвели наилучшую модель, мы используем несколько функций Lambda (шаг 5) для очистки вывода данных и запускаем процесс верификации и регистрации новой модели в SageMaker Model Registry (Реестр моделей SageMaker)(шаг 7). Это позволяет нам продвигать аналогичные успешно верифицированные и протестированные модели в другие инфраструктуры, такие как постановка и производство, параллельно находясь в условном состоянии, в котором можно развёртывать или обновлять соответствующие конечные точки модели SageMaker(шаг 6).
Мы обучаем модели в одной учетной записи (разработке) и разворачиваем их на разных учетных записях, т.к. далее нет нужды переучивать модели. Конвейер развёртывания (развёртки) (см. следующую диаграмму) позволяет нам перемещать обученную модель МО на другие учетные записи и (данный конвейер) управляется SageMaker Model Registry и кастомными конвейерами BitBucket.
Для управленческих целей, мы определили процесс ручного утверждения с помощью пулл-реквестов, которые могут быть утверждены владельцами продуктов. После того, пулл-реквест утверждён на BitBucket (шаг 8), мы выполняем кросс-аккаунтовую развёртку/развёртку на перекрестных учетных записях, используя SageMaker Model Registry для желаемой модели в целевой инфраструктуре, такой как постановка или производство (шаг 9). Это позволяет нам иметь единый истинный след с последовательной моделью, протестированной вначале, и доступной для отслеживания до первоначального запуска. Это также обеспечивает процесс утверждения для новых моделей, вне зависимости от того, когда мы хотим запустить новую модель, например, в живую производственную среду.
С вышеупомянутой архитектурой обучения и развёртки, в Passing Profile Match Fact (в Профиле Передач Match Fact) «воспиталось»/«взрастилось» более быстрое модифицирование, исправление багов, интеграция успешных экспериментов в другие среды/инфраструктуры, и сниженные операционные расходы и расходы на разработку.
ИТОГ
В этой статье мы продемонстрировали, как Профиль Передач Match Fact Бундеслиги делает возможным объективное сравнение сложности передач/пасов. Мы использовали исторические данные около 2 миллионов передач для построения модели МО на SageMaker, которая высчитывает сложность передачи. Модель основана на 26 факторах, таких как покрываемая мячом дистанция или давление, под которым находится отдающий (для большей информации о давлении/прессинге, ознакомьтесь с Match Fact Most Pressed Player). Мы показали, как построить многоразовый контейнер для обучения моделей и способствовать развёртке мульти- (много-) и кросс-(перекрестно-) аккаунтных моделей МО одним нажатием кнопки.
Профиль передач (Passing Profile) будет на дисплее трансляций Бундеслиги и приложения Бундеслиги с 11 сентября 2021 года. Мы надеемся, Вы насладитесь инсайтами, которыми Вас обеспечит эта продвинутая статистика. Узнайте больше о партнерстве между AWS и Бундеслигой по ссылке!
Об авторах
Симон Рольфес сыграл 288 матчей в Бундеслиге в качестве центрального полузащитника, забил 41 гол, и провёл 26 матчей за сборную Германии. На данный момент он работает спортивным директором в «Байер 04 Леверкузен», где он наблюдает и помогает с развитием состава первой команды, отдела скаутинга и молодёжным развитием в клубе. Также Симон еженедельно пишет статьи для Bundesliga.com про последние Bundesliga Match Facts powered by AWS
Люк Фигдор – старший специалист по спортивным технологиям в команде AWS Professional Services. Он работает с игроками, клубами, лигами и медиакомпаниями, такими как Бундеслига или Формула-1, чтобы помочь им рассказывать истории, основанные на данных, используемых машинным обучением. В своё свободное время он любит изучать всё, что связано с разумом и пересечениями между психологией, экономикой и искусственным интеллектом.
Габриель Анцер – ведущий data-исследователь/data-ученый в Sportec Solutions AG, дочернем предприятии Федерации Футбола Германии. Он работает над извлечением интересных идей из футбольных данных, используя искусственный интеллект и машинное обучение как для фанатов, так и для клубов. Образование Габриеля – Математика и Машинное обучение, но он дополнительно получает докторскую в Спортивной Аналитике в Тюбингенском Университете и работает над получением тренерской футбольной лицензии.
Габриэлла Эрнандес Лариос - data-исследователь/data-ученый в AWS Professional Services. Она работает с клиентами в разных сферах, открывая для них мощь искусственного интеллекта и машинного обучения для достижения результатов в бизнесе. Габриэлла любит футбол и в свободное время любит пробежки, плавание, йогу, кроссфит и пеший туризм.
Якуб Михалчик - data-исследователь/data-ученый в Sportec Solutions AG. Несколько лет назад он предпочел футболу изучение математики, придя к заключению, что в футболе он недостаточно хорош. Теперь он совмещает обе свои страсти (оба своих увлечения) в своей профессиональной карьере, применяя методы машинного обучения для получения лучших инсайтов/идей в этой прекрасной игре. В своё свободное время он всё ещё наслаждается игрой в футбол 7х7, смотрит криминальные драмы и слушает музыку из кино.
Мурат Экси – full-stack технолог (технолог полного цикла звучит, как работник завода, а не IT-специалист) в AWS Professional Services. Он работал с разными сферами, включая финансы, спорт и медиа, игровая индустрия, производственная промышленность и автомобилестроение, везде ускоряя достижение результатов в бизнесе с помощью разработки приложений, безопасности (имеется в виду цифровой), Интернета вещей (IoT), аналитики, DevOps, и инфраструктуры. Вне работы он любит путешествовать по миру, изучать новые языки, организовывая локальные мероприятия для предпринимателей и владельцев бизнеса в Стокгольме. Также недавно начал брать уроки пилотирования.
Перевод: Ален Туранов
Сотрудничество
По вопросам сотрудничества можете заполнить форму обратной связи или связаться с нашим представителем.