对峙概率，NHL Edge IQ 的一部分：在电视转播的比赛中实时预测对峙获胜者

对峙概率是全国冰球联盟 (NHL) 首次使用机器学习 (ML) 和人工智能进行高级统计。它使用实时球员和冰球跟踪 (PPT) 数据向观众展示在球被丢弃之前哪个球员可能会赢得争球，并让广播公司和观众有机会深入了解争球比赛的重要性以及玩家能力的差异。基于 10 年的历史数据，数十万次对峙被用于设计输入模型的 70 多个特征，以提供实时概率。广播公司现在可以讨论球员的关键争球胜利如何导致进球，或者由于球队的争球专家被排除在平局之外，赢得争球的机会如何减少。球迷们可以看到直观的实时预测，向他们展示比赛关键部分的重要性。

在这篇文章中，我们将重点关注对峙概率的 ML 模型是如何开发的，以及用于将该模型投入生产的服务。我们还分享了在构建对峙概率模型期间解决的关键技术挑战。

产品思路

想象以下场景：这是两支 NHL 球队之间的平局，将决定谁前进。我们在第三节比赛还剩 1 分 22 秒。来自对方球队的两名球员排成一列，在距离其中一个网最近的对峙中进行平局。边裁注意到一名防守球员进入争球圈，并因违规而让他们的球员退出争球。一个经验不足的防守球员进来代替他的平局。进攻方赢得争球，获得球权，并立即得分取得领先。比分在比赛的剩余分钟内保持不变，并决定谁前进。在最初的二人组改变之前，哪个球员更有利于赢得对峙？防守方球队赢得争球的概率因违反迫使其他球员参加平局而降低了多少？对峙概率是由 AWS 提供支持的最新 NHL Edge IQ 统计数据，现在可以回答这些问题。

当比赛中止时，争球概率会根据场上的球员、争球的位置和当前的比赛情况，预测谁将赢得即将到来的争球。在整个停赛期间都会生成预测，直到比赛时钟再次开始运行。预测发生在亚秒级的延迟时间，并且在参与对峙的球员发生变化时触发。

克服对峙概率的关键障碍

在实时广播中预测对峙概率可以分解为两个特定的子问题：

将对峙事件建模为 ML 问题，了解要求和限制，准备数据，设计数据信号，探索算法并确保结果的可靠性
从PPT事件流中检测比赛中的对峙事件，收集预测所需的参数，调用模型，并将结果提交给广播公司

在电视转播中实时预测球员赢得对决的概率有几个必须克服的技术挑战。其中包括确定预测具有大量不确定性的事件所需的特征和建模方法，以及确定如何使用流式 PPT 传感器数据来识别发生对峙的位置、涉及的球员以及每个球员的概率赢得对峙，都在数百毫秒之内。

为难以预测的事件构建 ML 模型

预测现场比赛中的对决获胜概率等事件是一项复杂的任务，需要大量高质量的历史数据和数据流功能。为了在如此丰富的数据环境中识别和理解重要信号，ML 模型的开发需要广泛的主题专业知识。这亚马逊机器学习解决方案实验室与 NHL 曲棍球和数据专家合作，从提高球迷体验的目标出发。通过不断听取 NHL 的专业知识和测试假设，AWS 的科学家设计了 100 多项与对峙事件相关的功能。特别是，该团队将此功能集分为以下三类之一：

有关球员表现的历史统计数据，例如球员在过去五个赛季中的争球次数和获胜次数、球员在之前比赛中的争球次数和获胜次数、球员在多个时间窗口内的胜率、以及对战中每位球员的正面交锋胜率
球员特征，如身高、体重、惯用手和联盟年限
可能影响球员表现的比赛中情境数据，例如比赛得分、比赛到该点所用的时间、争球的位置、每支球队的实力以及必须放置的球员他们先坚持对峙

AWS 的 ML 科学家将该问题视为二元分类问题：主队球员赢得对峙，或者客队球员赢得对峙。凭借来自超过 200,000 次历史交锋的数据，他们使用了轻型GBM 模型来预测参与对峙事件的两名球员中的哪一个可能获胜。

确定是否即将发生对峙以及涉及哪些球员

当哨声响起，比赛停止时，Face-off Probability 开始做出预测。但是，争球概率必须首先确定争球发生的地点以及每支球队的哪位球员参与争球。数据流在事件发生时指示事件，但不提供有关事件可能在未来何时发生的信息。因此，需要冰上球员的传感器数据来确定是否以及在哪里将发生对峙。

PPT 系统以高达每秒 60 个事件的速度为冰上运动员生成实时位置和速度。这些位置和速度用于确定在冰面上发生对峙的位置以及是否可能很快发生。通过了解球员与已知争球位置的距离以及球员的静止程度，Face-off Probability 能够确定可能发生争球以及参与争球的两名球员.

使用决策树模型确定接近争球位置的正确截止距离和静止球员的相应截止速度。借助 2020-2021 赛季的 PPT 数据，我们建立了一个模型，在给定每支球队到该位置的平均距离和球员速度的情况下，预测在指定位置发生争球的可能性。决策树为每个指标提供了截止点，我们将其作为基于规则的逻辑包含在流应用程序中。

在确定了正确的争球位置后，每支球队的争球球员是通过从每支球队中选择离已知位置最近的球员来计算的。这为应用程序提供了识别正确球员的灵活性，同时还能够适应新球员，如果当前球员因违规而被弃权，则必须进行对峙。为正确的玩家做出和更新预测是模型在广播中实时可用性的关键焦点，我们将在下一节中进一步描述。

模型开发和训练

为了开发该模型，我们使用了超过 200,000 个历史交锋数据点，以及与主题专家合作设计的定制工程特征集。我们研究了比赛中的情况、争球球员的历史表现、球员的特定特征以及争球球员的正面交锋表现等特征，包括本赛季和他们的事业。总的来说，这导致使用可用和衍生技术的组合创建了 100 多个特征。

为了评估不同的特征以及它们如何影响模型，我们在探索阶段进行了广泛的特征分析。我们混合使用了单变量测试和多变量测试。对于多变量测试，为了可解释性，我们使用了决策树可视化技术。为了评估统计显着性，我们使用 Chi 检验和 KS 检验来检验依赖性或分布差异。

我们探索了分类技术和模型，期望原始概率将被视为预测。我们在算法方面探索了最近邻、决策树、神经网络以及协同过滤，同时尝试了不同的采样策略（过滤、随机、分层和基于时间的采样），并评估了曲线下面积 (AUC) 和校准分布以及 Brier 分数损失。最后，我们发现 LightGBM 模型在经过良好校准的准确度指标上效果最佳。

为了评估模型的性能，我们使用了多种技术。我们使用了一个经过训练的模型从未接触过的测试集。此外，团队对结果进行了广泛的手动评估，查看边缘情况并试图了解模型看起来的细微差别，以确定为什么某个球员应该赢得或输掉一场对峙赛事。

借助从人工审核者那里收集的信息，我们会在需要时调整功能，或者在模型上运行迭代以查看模型的性能是否符合预期。

部署对峙概率以在国家电视广播期间实时使用

该项目的目标之一不仅仅是预测对决的获胜者，而是为以实时且具有成本效益的方式解决许多类似问题奠定基础。该目标有助于确定在最终架构中使用哪些组件。

第一个重要的组成部分是 Amazon Kinesis数据流，一种无服务器流数据服务，充当 PPT 数据提供者的具体实现和消费应用程序之间的解耦器，从而保护后者免受前者的破坏性更改。它还增强了扇出功能，能够连接多达 20 个并行消费者，并在所有消费者之间同时保持 70 毫秒的低延迟和每个分片 2MB/s 的相同吞吐量。

PPT 事件不会同时出现在所有玩家身上，而是为每个玩家以及游戏中的其他事件离散地到来。因此，要实现即将到来的对峙检测算法，应用程序需要保持一个状态。

架构的第二个重要组成部分是 Amazon Kinesis数据分析 Apache Flink. Apache Flink 是一个分布式流式、高吞吐量、低延迟的数据流引擎，它提供了一种使用 Data Stream API 的便捷方式，它支持开箱即用的状态处理功能、检查点和并行处理。这有助于加快开发速度并提供对低级例程和组件的访问，从而实现灵活的应用程序设计和实现。

Kinesis Data Analytics 为您的 Apache Flink 应用程序提供底层基础设施。它消除了在上部署和配置 Flink 集群的需要亚马逊弹性计算云（Amazon EC2）或 Kubernetes，从而降低了维护复杂性和成本。

第三个关键组成部分是亚马逊SageMaker. 虽然我们使用 SageMaker 来构建模型，但我们还需要在项目的早期阶段做出决定：评分应该在对峙检测应用程序本身内部实现并使实现复杂化，还是应该由对峙检测应用程序调用SageMaker 远程并由于网络通信而牺牲一些延迟？为了做出明智的决定，我们执行了一系列基准测试来验证 SageMaker 延迟和可扩展性，并验证负载下的平均延迟小于 100 毫秒，这在我们的预期之内。

确定了高层架构的主要部分后，我们开始着手对面检测应用程序的内部设计。下图描述了应用程序的计算模型。

对峙检测应用程序的计算模型可以建模为一个简单的有限状态机，其中每个传入消息将系统从一种状态转换到另一种状态，同时执行一些计算以及该转换。该应用程序维护几个数据结构来跟踪以下内容：

游戏状态的变化 – 比赛时钟的当前周期数、状态和值，以及得分
玩家状态的变化 – 如果球员当前在冰上或替补席上，场上的当前坐标和当前速度
球员个人对战数据的变化 – 一名球员对另一名球员的成功率，依此类推

该算法检查玩家的每个位置更新事件，以决定是否应进行对战预测以及是否应将结果提交给广播公司。考虑到每个玩家位置大约每 80 毫秒更新一次，并且玩家在游戏暂停期间的移动速度比在游戏期间慢得多，我们可以得出结论，两次更新之间的情况不会发生巨大变化。如果应用程序调用 SageMaker 进行预测，并在每次接收到新的位置更新事件并且满足所有条件时向广播公司发送预测，那么 SageMaker 和广播公司将因大量重复请求而不堪重负。

为了避免所有这些不必要的噪音，应用程序会跟踪已经进行预测的参数组合以及预测结果，并将它们缓存在内存中以避免对 SageMaker 的昂贵重复请求。此外，它会跟踪已发送给广播公司的预测，并确保仅发送新的预测或仅在必要时再次发送先前发送的预测。测试表明，这种方法将传出流量减少了 100 多倍。

我们使用的另一种优化技术是将对 SageMaker 的请求分组并并行异步执行它们。例如，如果我们需要从 SageMaker 获得预测的四种新的对峙参数组合，我们知道每个请求将花费不到 100 毫秒的时间。如果我们一个一个地同步执行每个请求，总响应时间将在 400 毫秒以下。但是，如果我们将所有四个请求分组，异步提交，并等待整个组的结果再继续前进，我们有效地并行化请求，总响应时间将低于 100 毫秒，就像只有一个请求一样。