亚马逊AWS官方博客
加快创新步伐：F1 如何运用 AWS 上的无服务器机器学习提升洞见能力
2020年，F1方程式赛车迎来了自己的70岁生日，同时也是世界上将运动技能与工程技术实力全面结合的极少数顶尖运动之一。技术一直在F1中扮演着核心角色，规则与工具的演变也早已融入F1运动的血液当中。正是这种不断进取、不断探索的精神，令全球赛车迷们痴狂不已，关注自己热爱的车手与车队如何以十分之一秒为单位超越对手、夺取胜利。
经过多年发现，赛车的进站时间已经从1分钟以下缩短至2秒左右，赛车在转变与制动时车手将体验高在5个G的加速度影响，极速高达375公里/小时，赛事覆盖全球22个国家/地区。没有任何一项运动，能够在不断发展与接纳新技术方面与F1相比肩。但F1在追求创新方面永不止步，同时也在努力通过创新成果为超过10亿粉丝创造前所未有的观赛体验，通过数据与分析之力帮助观众更好地了解赛道内外发生的一切，并将驾驶员及车队做出的瞬时决策直接传递给观众。
每辆赛车上安装有300个传感器，每秒从赛车上传输至维修站的数据点多达110万个。这一切，都让粉丝的体验从被动观看转化为实时参与，从而加快人们对于赛事动态的反应速度。F1还使用云原生技术（例如通过Amazon SageMaker创建、并托管在AWS Lambda上的机器学习模型）以确定驾驶员的表现以及是否已经将汽车推至物理极限。结果就是，各团队能够预测超车或者进站计划给比赛结果造成的影响。另外，F1主办方还可以通过广播合作伙伴与数字平台与全球粉丝即时分享这些重要见解。
本文深入探讨了Amazon机器学习解决方案实验室（ML Solutions Lab）与专业服务团队如何同F1携手合作，共同动用AWS技术构建起实时比赛策略预测应用程序，快速生成进站决策并据此规划赛车的竞技战术。本文还将讨论如何将竞赛策略转换为应用逻辑，并立足多团队并行基础找到反推方案。最后，大家还可以了解无服务器架构如何在全球范围内以最低延迟提供机器学习预测，以及如何踏上您自己的机器学习探索之旅。
入站还是不入站——这是个问题
对车迷来说，赛场上来自10支车队的20名车手往往令人感到应接不暇。但在另一方面，每位驾驶员与工程师却对自己当前执行的比赛策略有着非常清晰的认识，并通过精确执行力争在比赛中脱颖而出。某些冒险之举是精心计算的结果，也有一些则是疯狂的赌注——而这一切与运气相关的判断都将给比赛结果造成巨大影响，甚至在几秒钟之内给观众们带来天翻地覆的心态与观看体验。F1也希望能够更加公开透明，让粉丝们了解赛场上的种种策略是如何制定出来的，并据此跟踪策略在比赛中引发的影响。
轮胎状况是影响赛车性能的一大关键因素。如果坚持使用同一套轮胎，驾驶员根本无法正常完成比赛，更不用说冲击领奖台了。各F1车队可以在多种轮胎材质做出选择，借此平衡性能与耐用性两大相互冲突的指标。较软的轮胎材质拥有更好的抓地力与物理极限，但磨损速度也更快；与之对应，较硬的轮胎材质耐久性更好，但会限制转弯极速与牵引力水平。另外，车手与车队可以自由决定进站的时间与频率，但赛事规则要求每位车手在每轮分站赛内至少要进站一次。
更换新的轮胎可以显著提高车辆性能，增加驾驶员们超越对手的机会。但这也要付出代价——每次进站的平均时耗约为20秒。很明显，精心规划并执行进站策略，往往会成为决定比赛走向的巨大优势。
想象一下两名驾驶员之间的对抗：驾驶员1与驾驶员2。驾驶员1目前暂时领先并努力捍卫自己的优势位置，驾驶员2虽然速度更快，但经过几次尝试发现很难成功超车。考虑到两位驾驶员都至少需要更换一次轮胎，那么驾驶员2可能会选择先进站以发挥自身性能优势。通过提前进站，驾驶员2占据了上风，凭借更新的轮胎压制住轮胎性能不断退化的驾驶员1并快速缩小赛车间距离。只要驾驶员2能够在驾驶员1进站之前再次将其咬住，那么当驾驶员1被迫进站时，超车即可轻松完成。这种策略，在F1运动中被称为undercut。
虽然这种战术看似浅显易懂，但车队有时候也会采取相反的策略，即overcut。驾驶员2可能会努力将自己的汽车开到极限，坚持到驾驶员1首先进站，这是在赌驾驶员1的轮胎磨损得更快。这里的基本思路是，驾驶员1进站后，驾驶员2可以放肆提速并建立起更大的距离优势。只要执行得当，那么先进站者即使在后发时逐渐缩小差距，最终也很难成功完成超车——这相当于是把领先者与追逐者的位置对调了过来。二者之间的缠斗往往需要跑完多圈才能分出胜负。当然，在实际比赛中由于无数复杂因素的影响，我们几乎不可能提前判断各车队策略之间到底谁更有效。换言之，即使是最死忠的F1赛车粉丝，也能从数据分析当中获得更多乐趣与启发。
F1与AWS合作建立起新的F1洞见项目，希望通过反推需求的方式构建起机器学习模型，用于跟踪进站策略并改善观看体验。
反推需求
AWS以客户为出发点，反推观看者们的实际需求，即根据粉丝们的价值主张设计观看体验与内容。反推需求的具体过程分为三个部分：使用以客户为中心的语言宏观描述基本思路，整理观众以及内部相关各方可能提出的常见问题，最终以视觉效果形式传达思路与答案。在权衡一种思路的优缺点时，最重要的是勾勒出所有可能的经验性结果。具体执行方式可以采用白板草图、工作流程图或者线框图等。下面来看入站策略场景下的基本思路：
以这样的概念图为基础，相关各方能够根据一组不同的结果与目标（图形应用、应用开发、机器学习模型等）进行调整，并通过一组小型用户团队进行测试以验证能否得到预期结果。此外，团队还可以借此将工作量拆分成多个单元，从而实现并行处理——例如整理出多个不同的图形线框（图形）、数据集合（运营）、将竞赛逻辑转换为应用逻辑（开发团队）以及建立机器学习模型（机器学习小组）等等。
反推需求模式帮助我们在起步阶段就建立起清晰的愿景。我们与F1的广播合作伙伴就消息类型与格式快速达成一致，并由图形创作者制作一段视频作为屏幕图形设计团队的概念验证参考。
我们使用Amazon SageMaker notebooks进行了探索性分析，并对上传至Amazon S3的各类时间、轮胎与气候数据进行可视化，从算法角度了解比赛的整体态势。我们确定了车队曾在以往的比赛中使用过哪些策略，因此因素最终决定比赛结果，同时无休止地循环以了解我们可以为机器学习模型提取哪些历史特征、以及如何在现场比赛中即时提取到相同的特征。
在从各种来源提取数据并完成初步清洗之后，我们开始执行机器学习任务。在启动机器学习项目时，我们几乎无法提前确定可以实现的最佳结果。为了快速推进实验与迭代，我们为其设置了两项关键性能指标（KPI）：
- 业务KPI——将进度传达给所有相关各方，例如在一定范围内提出预测百分比。
- 技术KPI——用于优化模型，例如均方根误差。
大家可以使用这些KPI、技术要求以及设定的输出格式快速推进特征工程与各类算法实验，从而优化预测误差。
架构实现
在设计应用程序的整体架构时，我们也需要满足多种要求，而且不少要求乍看起来似乎相互矛盾。通过使用云原生AWS服务，我们得以专注于真正重要的工作，降低维护开销并最终实现业务目标。最后，按实际资源使用量计费的机制也让我们能够始终保持相对较低的运营成本。
架构概述
下图所示，为这套架构的细节情况：
在赛道上捕捉到信号之后，数据会首先通过F1主办方基础设施进行传递，而后可通过HTTP从AWS云处调用。其中Amazon API Gateway充当应用程序入口点，而应用程序则以函数形式托管在Lambda之内，并由函数负责实现竞赛逻辑。当函数接收到传入消息时，它会更新存储在Amazon DynamoDB中的竞赛状态（例如各位车手的位置变动）。更新完成之后，函数会评估是否需要触发预测。如果需要，则使用Amazon SageMaker中训练完成的模型执行预测。预测结果将以响应形式被传回至F1主办方基础设施，并最后进入广播中心以供赛事主办方使用。最重要的是，我们要求整个过程要在500毫秒以内完成。
选择正确的工具
我们面临的第一个挑战在于，我们事先并不知道哪种方法真正具有可行性，特别是在对延迟时长提出严苛要求的前提之下。我们需要选择一套工具，保证我们能够快速完成原型设计、验证与试验，并让我们得以从概念验证阶段迅速过渡至可用于生产的应用程序。在这方面，我们使用到AWS提供的多种无服务器产品，包括Lambda, API Gateway, DynamoDB, Amazon CloudWatch以及S3。我们在Lambda上托管一套原型，其运营成本为零；当我们对结果感到满意时，则可使用一套简单脚本将应用程序转入生产环境。整个过程不需要分神于基础设施配置，因为Lambda会根据请求率自动对资源进行规模伸缩。在比赛结束之后，无需手动操作，多余的资源即会被释放。由于预测以实时方式进行，因此基础设施必须拥有极高的可用性。从传统角度看，构建这样一套基础设施往往需要一整个由专业系统工程师组成的高水平团队。但现在，Lambda接管了一切，能够为任意应用程序提供高可用性基础设施。
在应用程序从赛场上接收到消息时，单一消息的内容永远不会直接触发预测。例如，一位驾驶员的位置变化并不能充分体现赛道的整体情况。预测需要更为综合的信息，包括赛道之前以及当下的全面情况，因此我们需要使用数据库来存储并管理比赛状态。DynamoDB是一款关键工具，我们用它存储比赛状态、计算数据、当前正在监控的策略以及机器学习模型。无论表中的行数如何，DynamoDB都能提供以毫秒为单位的性能，且不会带来任何运营开销。我们不必花时间精简及管理数据库集群，也无需分神于保证正常运行时间等运营任务。
为了实现从原型设计到生产的自动化迭代，我们使用了CI/CD工具（包括AWS CodePipeline与AWS CodeBuild）以隔离环境，并在代码准备就绪后再将其转移至生产环境。我们使用AWS CloudFormation实现了所谓基础设施即代码（IaC）方案，借此置备环境并建立起可预测的部署体系。
我们只在现场比赛或测试期间大量使用资源，借此控制实际使用的资源量。为了避免为冗余的预留空间支付太多成本，我们以往还需要手动启动及停止各类组件。但现在，我们使用的服务提供按实际使用量付费的模式，账单中只涉及我们使用的确切存储容量，并通过调用次数确定计算资源费用。而这一切，都被托管在Lambda之上，从而替代了以往将模型托管在SageMaker上的方法。关于在Lambda上托管模型的更多详细信息，请参阅本篇博文。
准确率与性能
在运行机器学习模型方面，我们要求其具备与预期相符的准确率与运行时性能。为了保证准确率，我们需要使用能够实现快速测试、实验与迭代的工具。而在模型训练方面，我们选择了Amazon SageMaker，其内置XGBoost算法属于梯度提升树算法的一种流行、高效开源实现方案。我们认真分析了赛车数据与模型预测，以提取出赛车数据中的可用特征。在完成模型与输入特征的优化设计之后，我们使用Amazon SageMaker中的训练作业通过历史赛事数据进行模型训练。在这套体系当中，资源的供应与撤销能够自动进行，保证数据科学家只需要专注于模型优化工作。此外，SageMaker还允许用户控制实例类型以及用于训练的实例数量，为涉及大型数据集的训练场景提供有力支持。
算法的训练时长相对较为宽松，而推理过程则往往要求实时完成。F1为全球数亿观众提供直播节目，而对于这样一种以毫秒为单位的运动项目，即使是几秒前的数据也可能无法反映赛场上的当前状况。为了满足响应时间需求，我们将在Amazon SageMaker中训练完成的模型加载至Lambda托管的应用程序当中，并通过函数代码执行推理。由于模型始终保持加载状态且毗邻正在运行的代码，所以我们可以将调用开销降至最低。我们还使用内置的XGBoost开源算法训练模型，同时配合附带的开源软件包将模型转换为更小、性能更高的格式，从而提高推理速度并缩小部署规模。由于我们将应用程序与模型托管在Lambda当中，因此能够灵活地扩展基础设施，并在无需操作干预的前提下轻松适应赛事期间不断变化的预测需求。
工具与服务的实际选择，对于项目能否成功至关重要。AWS提供的服务选项兼顾广度与深度，能够帮助我们结合实际需求及运营模式选择最合适的工具。无服务器技术则把我们从基础设施维护工作中解放出来，让我们专注于执行其他更为重要的任务。
结果
入站策略洞见项目于2019年3月17日在2019 F1赛季澳大利亚大奖赛上首次亮相。为了充分展现入站策略洞见项目提供的视觉效果，我们又在3月31日将其引入巴林大奖赛。此轮比赛是2019赛季最激动人心的比赛之一，同时也让梅赛德斯车队的undercut策略拥有了闪亮的展示舞台。以下短片为汉密尔顿在提前一圈进站之后，利用新的轮胎快速追赶维特尔，并尝试在维特尔第十四圈进站时将其超越的片段。
通过视频，我们可以清楚看到汉密尔顿如何成功执行undercut策略。屏幕上的图形给观众们留下深深悬念，同时也帮助粉丝们深刻了解赛场上正在发生的一切。这款应用程序成功凭借通过历史数据训练出的机器学习模型，在500毫秒之内对追车时间间隔与成功超车概率做出实时预测。
总结
F1赛事在技术创新方面拥有悠久历史，但在海量数据的收集方面，如今我们才刚刚踏出第一步。当前，每辆赛车中的300多个传感器每秒可产生110万个数据点。本文介绍了AWS专业服务团队与F1共同使用这些数据，并配合机器学习与分析技术帮助粉丝们获取洞见、更好地理解赛场形势。多支团队就此建立起共识，并通过反推需求以明确最终目标。这样顺畅和谐的并行工作体系，最终极大加快了项目进度并消除了种种瓶颈。
与其他企业一样，F1主办方也希望在混乱中理清脉络，而我们使用的高级服务与应用的基本原理也将适用于各个行业。您可以使用Lambda进行应用程序托管，使用DynamoDB存储数据，并使用Amazon SageMaker进行模型训练，保证开发人员与数据科学家能够专注于更重要的工作。您不必耗费时间建立并维护基础设施，也不必担心正常运行时间与成本。相反，您将真正把精力集中在如何把业务知识转换为应用逻辑，并进行实验与快速迭代方面。
无论是有意推出个性化产品的网站开发商、希望高效运行的工厂、还是希望努力提高产量的农场，通过对来自业务中的数据进行收集与分析，您都将对下一步发展与扩张方向建立起更明晰的认知。AWS专业服务将随时为您的团队提供专业技能与经验指导，帮助您顺利达成业务愿景。关于更多详细信息，请参阅AWS专业服务，或通过您的客户经理咨询相关事宜。
关于作者
Luuk Figdor，AWS专业服务团队数据科学家。他与各行各业的客户合作，帮助他们使用机器学习技术讲好科技带动产业的故事。在业余时间，他喜欢研究思维与心理学、经济学以及人工智能之间的交汇点。
Andrey Syschikov，AWS专业服务团队全栈技术员。他帮助客户在基于云的创新应用程序当中将灵感转化为现实。尽管很少休假，但在罕见的业余时间中，他喜欢听有声读物、弹钢琴和远足。