实际上，数据闭环并不是一个新的概念。在传统软件工程领域，数据闭环被用来作为改进用户体验的一种重要方式。相信大家都有过这样的经历，在使用软件时，屏幕上跳出一个弹窗，询问你“是否允许该软件收集你的数据”，如果你同意相关条例，那这些数据便会被用来改进用户体验。
当用户端软件捕捉到一个问题时，后台能抓取相应数据，然后由开发团队分析此问题后对软件做修复和完善，交由测试团队测试好新版本软件，之后会将新版本软件放在云端，并由用户更新到终端，这是软件工程中数据闭环的流程。
在自动驾驶场景中，问题数据通常是在试验车上收集，极少数车辆能实现在量产车上收集。收集后需要对数据做标注，然后工程师在云端用新的数据训练神经网络模型，重新训练后的模型通常会通过OTA的方式部署到车端。
一个完整的数据闭环通常包括数据采集、数据回流、数据处理、数据标注、模型训练、测试验证这几个环节。
Momenta数据闭环流程示意
以特斯拉为例，配置了自动驾驶硬件的车队采集通过规则及影子模式下的触发器筛选的数据，经过语义筛选后的数据被回传到云端。此后，工程师在云端用工具对数据做一些处理，再把处理好的数据放入数据集群，然后利用这些有效数据训练模型。模型训练好之后，工程师会把训练好的模型部署回车端做一系列的指标检测，经过验证的新模型会被部署到车端供驾驶员使用。
在这种模型下，会有新的数据源源不断被触发回传，从而形成循环。此时，一个完整的由数据驱动的迭代开发循环便形成了。
目前，采用数据闭环来驱动算法迭代，几乎已经被公认为是提升自动驾驶能力的必由之路。很多主机厂和自动驾驶Tier1都在搭建自己的数据闭环系统，甚至还专门设置了数据闭环架构师的职位。
数据闭环的意义是什么？数据闭环能够在量产车上落地的背景是什么？数据闭环在量产车上落地的过程中有哪些痛点以及如何应对？
接下来，本文将围绕这些话题逐一讨论。
01 数据闭环的意义
根据智驾科技MAXIEYE的介绍，“数据闭环对于产品的性能，不仅仅是某个功能的性能提高，还能以影子模式的形式验证新功能。同时根据数据触发的类别，对于系统的其他方面也可以帮助优化，比如radar/camera blockage 的检测，可以根据回传数据优化阈值。在性能层面，数据回传基本上可以优化所有的性能，比如AEB，LKA，ELK，ACC，TJA，NOA等。MAXIEYE已通过数据回传OTA不断升级AEB, ACC, TJA 等系统功能，而且预埋了新功能的影子模式。”
如今，各家公司纷纷打造自己的数据闭环系统，主要希望实现的效果包括提升corner case数据采集效率、提高模型的泛化能力以及驱动算法的迭代。
1.1 搜集corner case的数据
只要是L2及L2以上的产品，都需要具备持续进化的能力。要让自动驾驶系统持续地进化，就需要不断获得corner case的数据。而随着越来越多的corner case从“未知”转换成“已知”，通过数量有限、形式路线也有限的测试车辆挖掘出新的corner case的难度越来越大。
通过在场景覆盖度更广的量产车上部署数据采集系统，在遇到当前的自动驾驶系统处理地得不够好的情形时，触发数据回传，是一种比较好的获取corner case的方法。
例如，可以在搭载L2辅助驾驶的量产车上部署AEB系统，然后收集驾驶员猛踩刹车、猛踩油门、猛打转向、猛打方向盘等的数据，分析为什么驾驶员在做这些操作的时候AEB系统没有任何响应。针对AEB系统应对地不够好的问题做相应改进，提高AEB系统的能力。
1.2 提高模型的泛化能力
当前，高等级的辅助驾驶正在从高速向城市进军。要解决高速这样相对简单的场景，基本上，仅靠测试车采集的数据来训练模型就够了，而不是一定要回传量产车的数据；然而，城市场景的复杂度大幅提升了，而且不同城市的路况也有很多差异。例如，在广州，随处可见拉着货物的三轮车在道路上疾驰，而在上海就很少会见到这种情形。
因此，很多自动驾驶Tier1以及车企对场景打通的诉求很强烈——即车辆的辅助驾驶系统可妥善应对各主流城市的各种路况。因为车企无法限制用户的行驶范围，假如只针对很小的区域做好辅助驾驶功能，会大大缩小用户群的范围，这显然不是车企希望看到的。
要实现场景打通的目标，模型的泛化能力就需要大幅提高。要大幅提高模型的泛化能力，就要尽可能地把各种各样的场景对应的数据都采集到。而只有基于大规模真实人驾数据的乘用车辅助驾驶才有能力积累到足够规模和足够多样的数据。
1.3 驱动算法迭代
前文提到，基于深度学习的人工智能算法发展已经超过十年。这期间，随着模型的演进以及算力的发展，自动驾驶系统对大数据的消化成为可能。此外，自动驾驶系统要升级，感知、规划等环节都需要在能力上有相应的提升，而采用数据驱动，让算法持续不断地进化，是提升感知、规划等环节能力的一个高效的方式。
城市NOA——即城市内的点对点导航辅助功能是很多主机厂以及自动驾驶Tier1接下来的发力点，要实现点对点的导航辅助驾驶功能，感知系统的语义识别、障碍物识别、可行驶区域的识别都需要具备一定的精度，然而目前这一标准尚未实现。
目前主流的感知系统网络架构是基于BEV+Transformer模型，单纯依靠软件工程师或者算法架构师来优化，模型可以提升的空间不太多，而BEV+Transformer的架构可以容纳大量的数据，进而有望让模型效果得到提升。
在规划层面，数据驱动也可以发挥作用。特斯拉早先使用部分约束下的最优方案作为初值，然后采用递增的方式不断加入新的约束，再求解增加约束后的优化问题，最终得到规划问题的最优。特斯拉工程师针对此方法离线做了很多预生成，并在在线做了并行优化，这样每个候选路径的计算时间仍然长达1～5ms。而根据特斯拉在2022年9月30日的AI day上披露的内容，特斯拉的工程师现在使用了一套数据驱动的决策树生成模型来帮助自动驾驶系统快速生成规划路径。这个数据驱动的决策树生成模型使用特斯拉车队中人类驾驶员驾驶数据和无时间约束下的最优路径作为真值进行训练，能够在100us内生成一个候选规划路径，大大缩短了生成候选规划路径的时间。
综上可见，搭建好数据闭环系统是自动驾驶系统能力提升的一个重要方式。
02 数据闭环的背景
当前，许多量产车上都搭载了辅助驾驶系统，人们可以在量产车上采集数据，自动驾驶系统的路测里程超过1亿公里已非难事。此外，芯片算力进一步增强——例如英伟达的OrinX芯片算力可达254TOPS，因此大模型开始被应用于感知系统，自动驾驶系统对大数据的消化成为可能。另一方面云端技术较为成熟，自动驾驶开始慢慢进入数据驱动的时代。
MAXIEYE公司方面的解释是：“确切地来说，现在不仅仅是数据驱动，而是AI算法和数据共同驱动。AI算法解决的是学习效率的问题，数据解决的是学习内容的问题，算法和数据是共生关系。”
“基于深度学习的人工智能算法的发展已经超过了十年，在这十年间的早期阶段，监督学习是学术界和工业界的主流，而监督学习有一个致命的缺陷，就是需要大量的人工标注，这大大的限制了AI的进步空间，但在近几年，无监督和半监督学习算法慢慢地开始兴起，计算机可以通过自学习的方式不断地对数据进行清洗以及对算法进行自我迭代，因此，通过数据驱动的方式开发自动驾驶技术的条件已经成熟。”
长城沙龙智能化中心负责人杨继峰在一次演讲中提到：“从整车角度上，2022年完成了L2到L4的架构闭环和数据闭环，车端架构和云端架构的进一步统一。接下来的竞争是数据挖掘、数据的有效利用以及整个技术栈对数据的理解，以及如何在大规模的基础设施上平衡整个计算效率。”
03 数据闭环落地的痛点及对策
目前，大家关于数据闭环对于自动驾驶系统的意义已达成共识，数据闭环在量产车上的落地的时机也基本成熟。那么，各家的数据闭环实际落地的情况如何？我们如何去评判一家公司数据闭环系统搭建的效果呢？
笔者从智驾科技MAXIEYE了解到，对于自动驾驶Tier1来讲，技术上实现数据闭环其实不是难题，本质上看的是该Tier1的产品实力——是否能通过数据闭环赋能车厂。其次，数据闭环的效果还要看产品的迭代是否由数据闭环驱动，是否能基于回传数据实现软件及算法的优化，并定期通过OTA部署到终端。
当前，根据数据闭环能力的高低，自动驾驶Tier 1可划分为三类：第一种是已经实现规模化量产的数据闭环，第二种是通过采集车实现闭环，第三种是还没有实现数据闭环的能力。目前来看，第一种还属于少数派。
根据笔者和业内人士交流得到的信息，目前大部分公司的数据来源都是采集车。由于用户隐私、基础设施、成本等种种因素，在量产车上大规模采集数据用于自动驾驶系统的迭代升级尚未实现。有的公司尚未搭建好在量产车上采集数据用于数据闭环的流程，有的公司虽然搭建好了流程，也采集了一些数据，但尚未将数据很好地用起来。
据悉，少数公司会从量产车上采集一些数据，但业内人士反映目前采集这些数据主要是用来诊断当前的自动驾驶系统存在的故障等，而非用于深度学习模型的迭代。
也即是说，目前很少有公司真正实现了规模化量产的数据闭环——即用好从大规模量产车上采集的数据来实现自动驾驶系统能力的提升。那么，数据闭环的量产落地究竟有哪些痛点？针对这些痛点，有什么样的应对策略呢？
量产落地的实践中需要考虑的问题包括但不限于：如何保证数据采集和使用的合规性、数据确权问题如何解决、数据采集功能如何与自动驾驶系统共存、数据处理难度大、数据驱动的软件系统复杂度高、模型训练难度大等。
3.1 数据采集和使用的合规性问题
合规分为测绘合规和隐私合规：测绘合规主要涉及到采集国家地理信息时的合规，隐私合规主要涉及到采集用户隐私相关数据的合规。
测绘合规方面，近几年，国家对数据安全的管理趋严，出台了相关法律法规来对回传数据的范围进行限制。2022 年 “830 新规”之后，车辆在道路上采集的数据都属于测绘数据。企业要使用测绘数据，后续的数据加密、数据合规的环节必不可少。
首先，在道路上采集数据的时候，企业需要具备国家测绘资质，并且要做相应的备案，否则采集过程中会被国安等部门阻止。目前，国内总共有约30家机构具备相关资质，有的企业具备国家电子导航甲级资质，适用范围较广，在国内多个城市都可以采集，而有的企业具备乙级资质，适用范围就会更小，只能在特定的城市采集。
由于测绘资质很难获取，需要有长期的业务积累，并且，要保有测绘资质，企业就需要有相应的测绘业务。因此，主机厂以及自动驾驶Tier1一般会委托带有资质的供应商或单位，例如现在有些云厂商会帮助客户围绕数据的获取、加工、使用来设计一个合规方案。
采集到数据后，还需要在车端脱敏、加密，上云之后（一般来讲是私有云），还需要做一些合规工作，这一部分会由有资质的供应商或者单位来帮忙做测绘的合规。对于部分很敏感的数据，需要由图商来做采集，而且数据需要在脱敏之后存储在图商监管的服务器里。
另外，测绘的数据不得泄漏，尤其是不得将数据挪到国外，非中国国籍的人既不能获取测绘数据，也不能在公司内操作测绘数据。
一般来说，主机厂和自动驾驶Tier1会建立自己的数据中心，出于安全考虑，这些数据中心都比较封闭。主机厂和自动驾驶Tier1需要使用这些数据中心存储的数据来做一些训练、仿真等工作的时候，基于合规要求，需要将相关模型部署到数据中心来使用。
有业内专家表示，“测绘的合规流程太复杂，资质也很难获取，大家希望尽可能减少对高精地图的依赖，这是目前业界流行‘重感知轻地图’方案的一部分原因。但实际上，轻地图不一定就是‘更好’，因为有地图数据效果肯定比没有好。目前这个趋势不一定是最终的形态，也不一定是最好的，只是大家希望能做得更简单一点。”
隐私合规方面，企业在量产车上采集数据，需要用户授权。类似于用微信的时候，企业需要用户在一开始签署授权协议，并告知用户哪些数据会被采集，哪些使用行为会被记录。
目前在隐私合规方面，国家尚未出台特别具体的方案规定哪些数据可以采哪些不可以，而是仅有一个相对宽泛的条款来规定数据采集方“不得泄漏用户隐私”。
实际操作中，涉及到用户信息的数据需要做脱敏，例如车牌号需要隐去等。
3.2 数据确权问题
我们是否可以在车上采集自动驾驶行业需要的摄像头、激光或毫米波形成的数据呢？
魔视智能产品经理苏林飞介绍道：“按照中国的《个人信息保护法》相关规定，非法律允许的数据采集受到隐私保护。在德国，原德国联邦信息保护局有这样的规定，如果司机不是受害者，未经对方同意就记录其他司机的脸和车辆，是违反个人信息保护法的。也就是说，即使是车主记录别人信息也可能属于违法。但由于和新能源车伴生的自动驾驶行业很新，法律规定目前尚属空缺，所以我们按照基本法学理念推导，量产车采集的数据应该由车主所有。”
那车主使用自己的车辆采集的数据是否可以授权给其他单位使用呢？
目前并没有相关法律规定与约束。但是在其他行业，比如手机、互联网领域，是广泛允许的。
谁可以拿到车主上传的数据？
从汽车产业链分工看，2种主体可以拿到，第1种是无人车队运营公司，比如百度的无人驾驶出租车，第2种是主机厂。但由于前者规模较小，所以我们重点介绍后者。
由于主机厂离用户最近，所以最容易拿到用户上传的数据。在全球范围看，Tesla是在这方面做地最好的主机厂。
目前，主机厂很少对外开放数据，导致自动驾驶Tier1在帮助主机厂实现了主机厂定制的功能后，很难收集到用户在使用这些功能时的反馈数据，除非Tier1自己有很多测试车。那么，自动驾驶Tier1就难以根据用户反馈的数据对相关功能做后续的优化，数据闭环就难以实现。
魔视智能产品经理苏林飞告诉笔者：“我们在帮主机厂做完一个项目之后，假如主机厂不开放数据接口，我们就很难拿到用户的反馈数据，进而针对此车型进一步迭代产品性能。最后大部分自动驾驶系统供应商成为了以项目运作为核心的公司，进而随着产品性能的落后慢慢被淘汰。
更糟糕的是，由于自动驾驶系统源代码开源的趋势已经显现，有的主机厂会希望自己搭建数据闭环系统来实现自动驾驶的功能，因而也不愿意把数据分享给供应商。但主机厂这样做我认为并不合理，我认为从自动驾驶整体的生态来讲，最好还是大家各司其职，专业的人做专业的事。只是目前行业还处于比较早期的发展阶段，可能大家都会想要尝试，从而把握更大的主动权。”
某新能源主机厂专家表示：“以前主机厂不愿意把数据给供应商是没想明白供应商可以怎么回馈自己，可能给了数据之后对方也不知道要如何使用。但是现在，对于合作的供应商，比如给主机厂提供自动驾驶解决方案的，主机厂是可以开放数据使用权的。当然了，开放数据使用权的前提是合规，供应商在接收主机厂提供的数据以及在使用数据时都需要保证整个流程是合规的。”
对于主机厂来说，假如不把数据开放给供应商，那么就自己发掘这些数据的价值。早期的时候，大家都不太知道这些数据具体有什么价值，需要用起来才能慢慢发现价值。主机厂可以把数据先给供应商使用，同时自己留存一份，供应商发掘出数据的价值之后再回馈主机厂。
现在有的主机厂会要求供应商在sop之后仍能持续地帮助他们迭代软件，而供应商也可以以此为契机获得数据，如此一来主机厂和供应商可以实现双赢。当然了，站在主机厂的角度，目前这种方式仍然存在一些瑕疵，因为供应商很难保证迭代后效果一定会变好。主机厂也很难验证迭代效果，所以主机厂常常反向要求供应商开放中间结果（例如感知目标识别结果）数据的接口，这样主机厂就可以通过针对中间结果的统计指标来验证供应商的迭代效果。
目前，主要需要双方本着互相信任，真诚合作的心态，主机厂开放数据使用权给供应商，然后供应商定期更新软件，并且能看到相应的效果，这样合作就能持续下去。只是目前这个模式尚未被广泛接受，因为大家尚未看到明显的效果。
3.3 数据采集会占用系统资源
在量产车上采集数据会占用一些系统资源，比如计算、存储等。理论上，可以假设计算资源、网络带宽等都不受限制，但在实际落地过程中，如何保证采集数据不影响量产车上自动驾驶系统的正常运行，例如，如何不影响自动驾驶系统的延迟等，这是一个需要解决的问题。
当然了，有的公司会在自动驾驶系统不运行的时候再上传数据，这样就不存在资源占用的问题。但是也有业内人士认为，仅在自动驾驶系统不运行的时候上传数据就会限制数据的采集量，现阶段还是要尽可能多地采集数据。那么，在设计的时候，就需要考虑到采集数据等对自动驾驶系统运行的影响。
3.4 数据标注及后续处理的难度大
据估计，从量产车回传数据后，单车每日回传的数据量大概为百兆级。研发阶段，车辆总数可能只有几十辆或者几百辆。但是到了量产阶段，车辆数目的量级可以达到上万、几十万甚至更多。那么，量产阶段，整个车队日产生的数据量就是很大的数字。
急剧增加的数据量给存储空间以及数据处理的速度都带来了挑战。量产之后，数据处理的延迟需要和研发阶段保持在同一个量级。但如果底层的基础设施跟不上，数据处理的延迟就会随着数据量的增长而相应地增加，这样会极大地拖慢研发流程的进度。对于系统迭代来讲，这种效率的降低是不可接受的。
一位业界专家告诉笔者，“目前，我们还没有看到哪家公司具备处理量产车上回传的大规模数据的能力。即使是某家在数据闭环层面做得比较前沿的造车新势力，即便是每辆量产车每天只回传5分钟的数据，他们也难以应对这样的数据量，因为当前的存储设备、文件读取系统、计算工具等都还无法应对极大的数据量。”
要应对越来越大的数据量，底层的基础设施以及平台的设计都需要相应升级。
工程团队需要开发完善的数据访存SDK。由于视觉数据、雷达数据的文件尺寸都非常大，数据的访问、查询、跳转、解码过程都需要效率足够高，否则会大大拖慢研发进度。
车端数据回传到云端后，工程团队需要及时给大量数据做好标注。业界目前会借助预训练模型来做辅助标注，但是数据量很大时，标注仍然需要很大的工作量。
在做数据标注的时候，还需要确保标注结果的一致性。目前，业界尚未实现全自动数据标注，仍然需要人工完成一部分工作量。在人工操作的时候，如何在数据量极大的情况下，保证标注结果的一致性也是一大挑战。
此外，自动驾驶相关的数据不仅量大，而且种类庞杂，这也给数据处理增加了难度。数据类型按照来源划分包括车辆数据、位置数据、环境感知数据、应用数据、个人数据等等，按照格式划分包括结构化数据和非结构化数据，数据的服务类型又涵盖文件、对象等，如何统一标准，协调不同类型的存储、访问接口也是一大难题。
3.5 数据驱动的软件系统复杂度高
传统的V字型开发模式很难适用于数据闭环。而且，目前行业中还没有形成统一的面向高等级自动驾驶的软件开发平台及中间件。
某公司自动驾驶部门的技术专家告诉笔者，“以数据和深度学习模型驱动的自动驾驶功能迭代体系可以称之为软件2.0。在这样的模式下，整个体系，包括团队的构建、研发流程、测试方法、工具链都是围绕数据构建的。”
在软件1.0时代，每个人提交了什么代码，预期的效果都是很容易评估的。但是，在软件2.0时代，每个人贡献的部分对整体效果的影响的衡量难度变大了，而且也很难事先预期，因为大家相互交流的不再是清晰可见的代码，而是数据以及根据数据更新的模型。
在数据量很少的时候，例如我们之前做移动互联网应用的AI视觉算法，由于数据量很少，涉及的视觉模型工程师，大家基本上是Windows或Ubuntu的文件夹各自管理，团队成员互相之间直接用各种重新命名的文件夹来回传输，非常低效进行数据交换或合作。
但是涉及到自动驾驶任务时，我们面临的是几十万张图片，而且是几百人共同研发一个系统，每次改动涉及到的的模块可能都是上百乃至上千。如何评测每个模块的代码质量，如何检验各模块之间是否有冲突，这些都是较为复杂的任务。迄今为止，我认为这套系统仍较为糟糕，工程化部分还不够成熟。
到了软件2.0阶段，还需要应对的问题是：如何衡量新增的数据对特定的场景和对全局的影响分别是什么，如何避免基于新增数据重新训练的模型在一些特定任务上效果变好但总体上效果下降。要解决这些问题，我们需要做单元测试，来检验新增部分数据后，对我们希望解决的细分场景有没有帮助以及对全局有没有帮助。
举例来讲，假如针对某个特定的任务，原始的数据集是2000万张图片，然后新增500张图片，解决这个特定任务的能力提升了，但有时候这也同时意味着模型在应对全局任务时得分降低。
此外，针对视觉任务，除了根据指标来判断新增数据对模型的影响，我们还需要实际去看具体的影响是什么，这样才能知道优化是否符合预期。仅仅通过指标来看可能会出现虽然指标提升了但实际效果仍然不符合预期的情况。
我们还需要有一套基础设施，来保证每次做的更新是全局最优的。这套基础设施会涉及到数据的管理、训练的评测等。特斯拉在这个方面是走在行业前列的，它关于数据驱动的整条链路从一开始的设计上就是领先全行业而且从2019到2022年，不需要太大的改变就能支撑产品的迭代。
3.6 模型训练难度增加
解决了数据采集、存储、标注等问题后，后续的模型训练、功能迭代仍然是挑战。
训练量产车上回传的大量数据，需要有高效的文件传输系统，保证训练时不被I/O“卡脖子”。
同时，还要有充足的算力。提高算力的方式通常是打造多卡并行的集群，那么，如何在训练时保持高效的卡间通信来减少数据传输的延迟从而充分有效地利用每张卡的算力也是需要考虑的问题。
为应对模型训练对算力的需求，有主机厂专门打造了自己的智算中心。然而，打造智算中心的成本很高，对于中小企业来说，这几乎是一件不可能的事情。
尽管当前仍存在诸多痛点，但我们仍然可以预期，假以时日，目前存在的问题会被逐个解决。届时，数据闭环能在量产车上真正落地，在量产车上落地后采集的数据将反哺数据闭环系统，推动自动驾驶系统走向更高阶。
