La probabilidad cara a cara es la Liga Nacional de Hockey (NHL) primera estadística avanzada que utiliza aprendizaje automático (ML) e inteligencia artificial. Utiliza datos de seguimiento de jugador y disco (PPT) en tiempo real para mostrar a los espectadores qué jugador es probable que gane un enfrentamiento antes de que se caiga el disco, y brinda a los locutores y espectadores la oportunidad de profundizar en la importancia de los partidos de enfrentamiento. y las diferencias en las habilidades de los jugadores. Con base en 10 años de datos históricos, se usaron cientos de miles de confrontaciones para diseñar más de 70 características que se incorporaron al modelo para proporcionar probabilidades en tiempo real. Los locutores ahora pueden discutir cómo una victoria clave de un jugador en un saque neutral condujo a un gol o cómo disminuyen las posibilidades de ganar un saque neutral cuando el especialista en saque neutral de un equipo queda excluido de un empate. Los fanáticos pueden ver predicciones visuales en tiempo real que les muestran la importancia de una parte clave del juego.

En esta publicación, nos enfocamos en cómo se desarrolló el modelo ML para Face-off Probability y los servicios utilizados para poner el modelo en producción. También compartimos los principales desafíos técnicos que se resolvieron durante la construcción del modelo Face-off Probability.

Cómo funciona

Imagine el siguiente escenario: es un juego empatado entre dos equipos de la NHL que determinará quién avanza. Estamos en el tercer período con 1:22 segundos por jugar. Dos jugadores de equipos opuestos se alinean para sacar el empate en el saque neutral más cercano a una de las redes. El juez de línea nota que un jugador defensivo está invadiendo el círculo de saque neutral y exonera a su jugador del saque neutral debido a la violación. Un jugador defensivo menos experimentado entra para tomar el sorteo como su reemplazo. El equipo atacante gana el saque neutral, obtiene la posesión del disco e inmediatamente anota para tomar la delantera. El marcador se mantiene durante el minuto restante del juego y decide quién avanza. ¿Qué jugador era el favorito para ganar el enfrentamiento antes de que se cambiara el dúo inicial? ¿Cuánto disminuyó la probabilidad del equipo defensivo de ganar el saque neutral por la violación que obligó a un jugador diferente a tomar el empate? Face-off Probability, la estadística NHL Edge IQ más reciente con tecnología de AWS, ahora puede responder estas preguntas.

Cuando hay una detención en el juego, Face-off Probability genera predicciones sobre quién ganará el próximo enfrentamiento en función de los jugadores en el hielo, la ubicación del enfrentamiento y la situación actual del juego. Los pronósticos se generan a lo largo de la parada hasta que el reloj del partido vuelve a correr. Las predicciones ocurren con una latencia de menos de un segundo y se activan cada vez que hay un cambio en los jugadores involucrados en el enfrentamiento.

Superar obstáculos clave para la probabilidad de enfrentamiento

La predicción de la probabilidad de cara a cara en transmisiones en tiempo real se puede dividir en dos subproblemas específicos:

• Modelar el evento de confrontación como un problema de ML, comprender los requisitos y limitaciones, preparar los datos, diseñar las señales de datos, explorar algoritmos y garantizar la confiabilidad de los resultados.
• Detectar un evento de enfrentamiento durante el juego a partir de una secuencia de eventos PPT, recopilar los parámetros necesarios para la predicción, llamar al modelo y enviar los resultados a las emisoras.

Predecir la probabilidad de que un jugador gane un enfrentamiento en tiempo real en una transmisión televisada tiene varios desafíos técnicos que debieron superarse. Estos incluyeron determinar las características requeridas y los métodos de modelado para predecir un evento que tiene una gran cantidad de incertidumbre, y determinar cómo usar la transmisión de datos del sensor PPT para identificar dónde se produce un enfrentamiento, los jugadores involucrados y la probabilidad de que cada jugador ganando el enfrentamiento, todo en cientos de milisegundos.

Creación de un modelo de ML para eventos difíciles de predecir

Predecir eventos como las probabilidades de ganar un enfrentamiento durante un juego en vivo es una tarea compleja que requiere una cantidad significativa de datos históricos de calidad y capacidades de transmisión de datos. Para identificar y comprender las señales importantes en un entorno de datos tan rico, el desarrollo de modelos ML requiere una amplia experiencia en la materia. los Laboratorio de soluciones de aprendizaje automático de Amazon se asoció con expertos en datos y hockey de la NHL para trabajar hacia atrás desde su objetivo de mejorar la experiencia de sus fanáticos. Al escuchar continuamente la experiencia de NHL y probar hipótesis, los científicos de AWS diseñaron más de 100 características que se correlacionan con el evento de enfrentamiento. En particular, el equipo clasificó este conjunto de características en una de tres categorías:

• Estadísticas históricas sobre el rendimiento de los jugadores, como la cantidad de enfrentamientos neutrales que un jugador ha realizado y ganado en las últimas cinco temporadas, la cantidad de enfrentamientos neutrales que el jugador ha realizado y ganado en juegos anteriores, los porcentajes de victorias de un jugador en varias ventanas de tiempo, y el porcentaje de victorias cara a cara de cada jugador en el enfrentamiento
• Características de los jugadores, como altura, peso, habilidad manual y años en la liga.
• Datos situacionales en el juego que pueden afectar el rendimiento de un jugador, como el puntaje del juego, el tiempo transcurrido en el juego hasta ese momento, dónde se ubica el saque neutral, la fuerza de cada equipo y qué jugador tiene que poner su palo hacia abajo para el enfrentamiento primero

Los científicos de ML de AWS consideraron el problema como un problema de clasificación binaria: el jugador local gana el enfrentamiento o el jugador visitante gana el enfrentamiento. Con datos de más de 200,000 enfrentamientos históricos, utilizaron un LuzGBM modelo para predecir cuál de los dos jugadores involucrados en un evento de cara a cara es probable que gane.

Determinar si está a punto de ocurrir un saque neutral y qué jugadores están involucrados

Cuando suena un silbato y se detiene el juego, Face-off Probability comienza a hacer predicciones. Sin embargo, Face-off Probability tiene que determinar primero dónde ocurre el saque neutral y qué jugador de cada equipo está involucrado en el enfrentamiento. El flujo de datos indica eventos a medida que ocurren, pero no brinda información sobre cuándo es probable que ocurra un evento en el futuro. Como tal, se necesitan los datos de los sensores de los jugadores en el hielo para determinar si y dónde está a punto de ocurrir un enfrentamiento.

El sistema PPT produce ubicaciones y velocidades en tiempo real para los jugadores en el hielo hasta 60 eventos por segundo. Estas ubicaciones y velocidades se usaron para determinar dónde está ocurriendo el enfrentamiento en el hielo y si es probable que suceda pronto. Al saber qué tan cerca están los jugadores de las ubicaciones conocidas de enfrentamiento y qué tan inmóviles estaban los jugadores, Face-off Probability pudo determinar que era probable que ocurriera un enfrentamiento y los dos jugadores que estarían involucrados en el enfrentamiento. .

La determinación de la distancia de corte correcta para la proximidad a una ubicación de enfrentamiento y la velocidad de corte correspondiente para jugadores estacionarios se logró mediante un modelo de árbol de decisión. Con los datos de PPT de la temporada 2020-2021, construimos un modelo para predecir la probabilidad de que ocurra un enfrentamiento en un lugar específico dada la distancia promedio de cada equipo al lugar y las velocidades de los jugadores. El árbol de decisiones proporcionó los límites para cada métrica, que incluimos como lógica basada en reglas en la aplicación de transmisión.

Con la ubicación correcta del saque neutral determinada, el jugador de cada equipo que realiza el saque neutral se calculó tomando al jugador más cercano a la ubicación conocida de cada equipo. Esto brindó a la aplicación la flexibilidad para identificar a los jugadores correctos y, al mismo tiempo, poder ajustarse a un nuevo jugador que tiene que hacer un saque neutral si un jugador actual es suspendido debido a una infracción. Hacer y actualizar la predicción para el jugador correcto fue un enfoque clave para la usabilidad en tiempo real del modelo en las transmisiones, que describimos más adelante en la siguiente sección.

Desarrollo y entrenamiento de modelos.

Para desarrollar el modelo, utilizamos más de 200,000 100 puntos de datos históricos de confrontación, junto con el conjunto de características de ingeniería personalizadas diseñadas trabajando con los expertos en la materia. Examinamos características como situaciones en el juego, rendimiento histórico de los jugadores que realizan el saque neutral, características específicas de los jugadores y actuaciones cara a cara de los jugadores que realizan el saque neutral, tanto en la temporada actual como para su carreras En conjunto, esto resultó en más de XNUMX características creadas usando una combinación de técnicas disponibles y derivadas.

Para evaluar las diferentes características y cómo podrían influir en el modelo, llevamos a cabo un extenso análisis de características como parte de la fase exploratoria. Utilizamos una combinación de pruebas univariadas y pruebas multivariadas. Para las pruebas multivariadas, para la interpretabilidad, utilizamos técnicas de visualización de árboles de decisión. Para evaluar la significación estadística, utilizamos las pruebas Chi Test y KS para probar las diferencias de dependencia o distribución.

Exploramos técnicas y modelos de clasificación con la expectativa de que las probabilidades brutas fueran tratadas como predicciones. Exploramos los vecinos más cercanos, los árboles de decisión, las redes neuronales y también el filtrado colaborativo en términos de algoritmos, mientras probamos diferentes estrategias de muestreo (muestreo de filtrado, aleatorio, estratificado y basado en el tiempo) y evaluamos el rendimiento en el área bajo la curva (AUC) y distribución de la calibración junto con la pérdida de puntuación de Brier. Al final, descubrimos que el modelo LightGBM funcionaba mejor con métricas de precisión bien calibradas.

Para evaluar el rendimiento de los modelos, utilizamos múltiples técnicas. Usamos un conjunto de prueba al que el modelo entrenado nunca estuvo expuesto. Además, los equipos realizaron extensas evaluaciones manuales de los resultados, analizando casos extremos y tratando de comprender los matices de cómo se veía el modelo para determinar por qué un determinado jugador debería haber ganado o perdido un evento de enfrentamiento.

Con la información recopilada de los revisores manuales, ajustaríamos las funciones cuando fuera necesario o ejecutaríamos iteraciones en el modelo para ver si el rendimiento del modelo era el esperado.

Implementación de Face-off Probability para uso en tiempo real durante las transmisiones de televisión nacional

Uno de los objetivos del proyecto no era solo predecir el ganador del enfrentamiento, sino construir una base para resolver una serie de problemas similares en tiempo real y de manera rentable. Ese objetivo ayudó a determinar qué componentes usar en la arquitectura final.

El primer componente importante es Secuencias de datos de Amazon Kinesis, un servicio de transmisión de datos sin servidor que actúa como un desacoplador entre la implementación específica del proveedor de datos PPT y las aplicaciones de consumo, protegiendo así a estas últimas de los cambios disruptivos en las primeras. También ha mejorado la función de distribución, que brinda la capacidad de conectar hasta 20 consumidores paralelos y mantener una latencia baja de 70 milisegundos y el mismo rendimiento de 2 MB/s por fragmento entre todos ellos simultáneamente.

Los eventos de PPT no se presentan para todos los jugadores a la vez, sino que llegan de forma discreta para cada jugador, así como para otros eventos del juego. Por lo tanto, para implementar el próximo algoritmo de detección de cara a cara, la aplicación debe mantener un estado.

El segundo componente importante de la arquitectura es Análisis de datos de Amazon Kinesis para Apache Flink. Apache Flink es un motor de flujo de datos de transmisión distribuida, alto rendimiento y baja latencia que proporciona una manera conveniente y fácil de usar la API de flujo de datos, y admite funciones de procesamiento con estado, puntos de control y procesamiento paralelo listos para usar. Esto ayuda a acelerar el desarrollo y brinda acceso a rutinas y componentes de bajo nivel, lo que permite un diseño e implementación flexibles de las aplicaciones.

Kinesis Data Analytics proporciona la infraestructura subyacente para sus aplicaciones Apache Flink. Elimina la necesidad de implementar y configurar un clúster Flink en Nube informática elástica de Amazon (Amazon EC2) o Kubernetes, lo que reduce la complejidad y los costes de mantenimiento.

El tercer componente crucial es Amazon SageMaker. Aunque usamos SageMaker para crear un modelo, también necesitábamos tomar una decisión en las primeras etapas del proyecto: ¿debería implementarse la puntuación dentro de la propia aplicación de detección de enfrentamientos y complicar la implementación, o debería llamar la aplicación de detección de enfrentamientos? SageMaker de forma remota y sacrificar algo de latencia debido a la comunicación a través de la red? Para tomar una decisión informada, realizamos una serie de puntos de referencia para verificar la latencia y la escalabilidad de SageMaker, y validamos que la latencia promedio era inferior a 100 milisegundos bajo carga, lo cual estaba dentro de nuestras expectativas.

Con las partes principales de la arquitectura de alto nivel decididas, comenzamos a trabajar en el diseño interno de la aplicación de detección de enfrentamientos. En el siguiente diagrama se muestra un modelo de cálculo de la aplicación.

El modelo de cómputo de la aplicación de detección de cara a cara se puede modelar como una máquina de estado finito simple, donde cada mensaje entrante hace que el sistema pase de un estado a otro mientras realiza algunos cálculos junto con esa transición. La aplicación mantiene varias estructuras de datos para realizar un seguimiento de lo siguiente:

• Cambios en el estado del juego – El número del período actual, el estado y el valor del reloj del juego y la puntuación
• Cambios en el estado del jugador – Si el jugador está actualmente en el hielo o en el banquillo, las coordenadas actuales en el campo y la velocidad actual
• Cambios en las estadísticas personales de enfrentamiento del jugador – La tasa de éxito de un jugador frente a otro, etc.

El algoritmo verifica cada evento de actualización de ubicación de un jugador para decidir si se debe hacer una predicción de cara a cara y si el resultado debe enviarse a las emisoras. Teniendo en cuenta que la ubicación de cada jugador se actualiza aproximadamente cada 80 milisegundos y que los jugadores se mueven mucho más lento durante las pausas del juego que durante el juego, podemos concluir que la situación entre dos actualizaciones no cambia drásticamente. Si la aplicación llamara a SageMaker para obtener predicciones y enviara predicciones a las emisoras cada vez que se recibiera un nuevo evento de actualización de ubicación y se cumplieran todas las condiciones, SageMaker y las emisoras se verían abrumados con una cantidad de solicitudes duplicadas.

Para evitar todo este ruido innecesario, la aplicación realiza un seguimiento de una combinación de parámetros para los que ya se realizaron predicciones, junto con el resultado de la predicción, y los almacena en caché en la memoria para evitar costosas solicitudes duplicadas a SageMaker. Además, realiza un seguimiento de las predicciones que ya se enviaron a las emisoras y se asegura de que solo se envíen nuevas predicciones o que las enviadas anteriormente se envíen de nuevo solo si es necesario. Las pruebas mostraron que este enfoque reduce la cantidad de tráfico saliente en más de 100 veces.

Otra técnica de optimización que usamos fue agrupar solicitudes a SageMaker y ejecutarlas de forma asincrónica en paralelo. Por ejemplo, si tenemos cuatro nuevas combinaciones de parámetros de confrontación para los que necesitamos obtener predicciones de SageMaker, sabemos que cada solicitud tardará menos de 100 milisegundos. Si realizamos cada solicitud de forma síncrona una por una, el tiempo de respuesta total será inferior a 400 milisegundos. Pero si agrupamos las cuatro solicitudes, las enviamos de forma asíncrona y esperamos el resultado de todo el grupo antes de seguir adelante, paralelizamos las solicitudes de manera efectiva y el tiempo de respuesta total será inferior a 100 milisegundos, al igual que para una sola solicitud.

Resumen

NHL Edge IQ, con tecnología de AWS, acerca a los fanáticos a la acción con análisis avanzados y nuevas estadísticas de ML. En esta publicación, mostramos información sobre la construcción y el despliegue del nuevo modelo de probabilidad de confrontación, la primera estadística de ML en el aire para la NHL. Asegúrese de estar atento a las probabilidades generadas por Face-off Probability en los próximos juegos de la NHL.

Para encontrar ejemplos completos de cómo crear trabajos de capacitación personalizados para SageMaker, visite Traiga su propio modelo de capacitación completa con SageMaker mediante la creación de un contenedor personalizado. Para ejemplos de uso Kinesis amazónica para la transmisión, consulte Aprendizaje del desarrollo de Amazon Kinesis.

Para obtener más información sobre la asociación entre AWS y la NHL, visite NHL innova con los servicios en la nube de AWS. Si desea colaborar con expertos para llevar soluciones ML a su organización, comuníquese con el Laboratorio de soluciones de Amazon ML.

Acerca de los autores

Ryan Gillespie es un científico de datos sénior de los servicios profesionales de AWS. Tiene una Maestría en Ciencias de la Universidad Northwestern y una Maestría en Administración de Empresas de la Universidad de Toronto. Tiene experiencia previa en las industrias minorista y minera.

Yash Shah es Gerente de Ciencias en el Laboratorio de soluciones de aprendizaje automático de Amazon. Él y su equipo de científicos aplicados e ingenieros de aprendizaje automático trabajan en una variedad de casos de uso de aprendizaje automático de la salud, los deportes, la automoción y la fabricación.

Alejandro Egórov es Arquitecto Principal de Streaming, especializado en tecnologías de streaming. Ayuda a las organizaciones a diseñar y construir plataformas para procesar y analizar datos de transmisión en tiempo real.

Miguel RomeroCalvo es científico aplicado en la Laboratorio de soluciones de Amazon ML donde se asocia con equipos internos de AWS y clientes estratégicos para acelerar su negocio a través de ML y adopción de la nube.

erick martinez es Arquitecto Sr. de Aplicaciones de Medios con más de 25 años de experiencia, con un enfoque en Medios y Entretenimiento. Tiene experiencia en todos los aspectos del ciclo de vida del desarrollo de sistemas, desde el descubrimiento, la recopilación de requisitos, el diseño, la implementación, las pruebas, el despliegue y la operación.