大模型真能解决一切吗?关于知识驱动自动驾驶的一些思考

人工智能 智能汽车
今年是自动驾驶非常卷的一年。无论是工业界还是学术界,都不断有新技术新发现新思想「涌现」出来。

本文经自动驾驶之心公众号授权转载,转载请联系出处。

上个星期受邀在外面做了一次关于「知识驱动自动驾驶」的讲座,刚好借这个机会把之前我和团队的一些学术上的思考整理凝练了一下。感觉里面一些内容还是挺值得拿出来分享&讨论的,所以开这么个帖子把其中一些关键的内容分享出来。其一是年底作为一个阶段性整理回顾一下我们团队的一些工作;其二则是能够以此出发阐述一下我对自动驾驶未来发展的一些看法;其三则是希望能从这些内容出发,引起一些回归学术本源的讨论。那么话不多说,进入正题。

注1:因为这个是用Slides改的Post,所以可能内容会有些零碎和割裂,大家多多包涵。如果后续大家感兴趣的话我再专门写一些逻辑链更完善的纯文章。

今年是自动驾驶非常卷的一年。无论是工业界还是学术界,都不断有新技术新发现新思想「涌现」出来。一方面,关于自动驾驶的研究正逐渐趋同——无论是之前做感知、决策、规控的同事,都想拿大模型来试一试;但另一方面,任何新技术的出现都将意味着格局的重新洗牌,大家又回到了同一起跑线上开始。如果从趋势上来说,我认为2023年自动驾驶包括但不限于以下的一下演进:

首先,传统的感知正在向认知转变:如同深度学习时代的CV领域早期,以图像分类、目标检测、语义分割等任务为主。其本质是通过下游任务来(我最近很认同的一句话:评价方式引导发展方向。)来让整个系统具备「智能」的表现。然而,能够很好完成这些视觉任务的模型,真的是「智能」的模型吗?从行为主义上来说,大量工作确实能够很好地完成这些任务,甚至其性能可以达到甚至超过人类水平,体现出了智能的行为。但诸如一些对抗攻击在内的工作让我们发现:原来这些SOTA在对抗样本面前是如此的不堪一击,这里真正意义上的「人工智能」还很遥远。于是在2010年前后,CV界逐渐有一波热潮开始探索「认知」,包括一些更加神奇的任务、以及引入了文本等其他模态的数据,来完成Image Captioning,Grounding,VQA甚至是Scene Graph这种复杂结构支持下的复杂任务。还记得好像是16年左右,有些好事者分析过当时的顶会标题,如果带着「semantic」这个词,中稿几率大大提升。可见学术界对于「认知」、「语义」、「理解」、「知识」等等这些概念的追捧。而现在,我深刻感觉到自动驾驶也在经历这个类似的时刻。前两年自动驾驶感知方向,大家关注的还都是检测、分割之类的经典任务。而近期大家的关注点开始向更加「Fancy」的方向倾斜,例如大家开始注意到自动驾驶场景的描述(Captioning)、问答(VQA)等与「理解」密不可分的任务。

第二,大家期待的端到端自动驾驶,正在以一种知识驱动的方式到来:我个人认为,端到端自动驾驶还是可以再细分为两种。一种是如2023年CVPR Best Paper之一的UniAD一样,由多个模块的级联实现。其整体构型属于一种能够损失传导的Multi-Task Learning:通过将多个模块级联+每个模块的损失作为约束,使得各个模块在训练过程中朝着「整体最优」的方向进行,有更大的可能在整体优化过程中找到端到端的流形空间。另一类则是完全端到端,从训练端即实现data-in、policy(control)-out。这个过程和人类驾驶行为相似:以眼睛作为视觉输入信号,直接作用在方向盘和刹车油们踏板上。但这种端到端最大的挑战在于如何实现持续学习?这种直接端到端变相地扩大了模型的搜索空间,需要用更多的数据、更大的模型、更强的算力才能防止系统过拟合在特定的场景中。

第三,大模型的出现为自动驾驶打开了更多的研究机会。尤其是大模型在海量开放领域数据训练所获得的通用感知能力具备很强的泛化性,甚至具有解决自动驾驶场景各种Corner Case的能力。现在逐渐有一种声音(以工业界为主),就是很多人认为大模型将会是实现端到端的一种可能。但我感觉不能简单地将大模型与端到端划等号,甚至大模型到底能否被用来进行自动驾驶,也是一个需要考虑的问题。但大模型真的能解决一切问题吗?有朝一日我们能否见到由大模型控制的自动驾驶系统?我其实是比较悲观的,因为大模型存在太多太多问题了。与其期待教会大模型直接开车,还不如多关注一下大模型在AI Agent和具身智能方面的进展。

我和我的团队目前所研究的方向我们管他叫「知识驱动自动驾驶」,这也是这篇文章主要的话题:重新思考自动驾驶——从知识驱动到数据驱动。

首先介绍一下背景,现在的自动驾驶系统仍然存在诸多挑战。

图片

比如长尾难例问题一直困扰着高阶自动驾驶在开放场景的应用。

例如,如左图所示,当我们从零构建一个自动驾驶系统的感知模块。冷启动的算法期初无法分辨工程车辆。但识别到桩桶,可能会让自动驾驶系统误以为在修路。最终,错误的感知做出错误的决策。

为了解决长尾难例,我们可以增加数据采集的覆盖性。例如通过采集更多的工程车辆并标注成车来提高车辆样本的数量。随着数据的增加,我们可能确实能够handle这种装满交通锥的工程车辆的识别问题。但如果样本是右边这张图呢?总会有无穷无尽的corner case的出现,甚至很多corner case在直到发生之前,我们都难以想象的。

图片

这张图来源于ISO 21448 SOTIF关于自动驾驶预期功能安全的标准。横轴分为安全、不安全;纵轴分为已知、未知。

对于Safe-known的绿色区域,是算法能够解决的问题。而Unsafe是指我们算法仍然无法解决的问题。我们希望调整算法,通过更好的学习,来让很多Unsafe的场景变得Safe。另一方面,为了压缩Unknown的区域,我们可以通过进行更多的路测来提高数据覆盖度。但「提高覆盖度」这件事是有边际效应的,在没有外部知识参与的情况下,我们总会有无穷无尽的Out-of-distribution的场景,也就是一些偶发的Corner Case,导致整个系统的失效。

而自动驾驶不同于其他很多领域,是存在木桶效应的。所以如何解决这些甚至在设计算法时都未曾考虑到的场景将会是至关重要的。例如如果一个目标检测系统从设计上只考虑了人、车、非机动车。那他可能就无法区分地上的桩桶和塑料袋。所以后来出现的一些针对开放词表目标检测的研究,或者像Tesla针对Occupancy的研究,都试图想从感知问题的定义上,让他有足够大的解空间,才能覆盖尽可能多的解。

图片

我们可以说,现在绝大多数自动驾驶系统,都是基于这样数据驱动的模式构建的。与此也伴生出了像数据闭环等重量级的中间件:就是通过反复的路测、数据采集、数据标注、模型训练,再进行路测,重新采集数据训练模型,循环往复不断进行。通过将这些流程制度化来降低成本。但从本质上仍然未解决问题。

为什么?因为除了无穷无尽的corner case以外,还有很关键的一个因素:现有的很多系统都是基于优化的方法。而优化就存在一个问题,遗忘灾难。所有优化的本质就是当我们找不到一个全局最优解的情况下,只能妥协地达成一个局部最优解。这就意味着那些经常出现的common case才会主导因素,而偶尔发生的corner case甚至要被当做是异常的离群点忽略掉,从而才能使整个系统处于一个低熵的稳定状态。反过头来,如果太关注corner case,当模型capacity不够大的时候,有可能反而让common case变得更差。按下葫芦起了瓢的效果。而这与自动驾驶系统追求安全的事实是相反的。

图片

所以我们能够总结出数据驱动自动驾驶系统的不可能三角:想要一个又安全又便宜的自动驾驶系统,那一定效率不高(例如扫地机器人?);想要便宜高效,那一定很不安全(横冲直撞那效率可杠杠的);又安全又高效那一定非常贵。

尽管数据驱动不可以三者兼得,但人类却能在这三者之间找到平衡。

图片

所以我们需要分析为什么人类这么厉害?

2022年LeCun在他的一项关于通用人工智能的工作中开篇即提了这样两个问题:1. 为什么一个人类青少年能够在大约20分钟的练习里就可以学会基本的车辆驾驶技能?2. 而为什么人类能够在遇到一些之前从来没见过的场景时仍然能做出正确的反应和决策?

其实这里面的关键因素就在于知识和推理的运用。例如上图里那5张图很多人都见过:数据通过打标签成为信息,而后融会贯通从知识逐渐变成智慧。

如果将自动驾驶系统与之相对应,我大概认为。之前的数据驱动自动驾驶仅仅能运用数据和信息,难以挖掘信息之间的关联性。因为关联性才决定了是否具备举一反三的能力。所以我们觉得,现在正是一个好的时机,从知识驱动自动驾驶的视角出发,探索AD2.0。(当然,AD2.0这个概念不是我们提的,是Wayve等一些公司题的)。

图片

总的来说,现阶段我认为,自动驾驶的第一性原理是知识

如何直接和间接地利用好人类的知识,跨域的知识,通用的知识,来处理好各种各样的问题,来让自动驾驶系统有更高的泛化性、Robust,是我们团队一直以来的研究方向,也是这篇文章的主题。

那接下来就介绍一下我认为什么是知识驱动的自动驾驶。

图片

我们宏观上可以把自动驾驶系统分成三个大类。

规则驱动的方法是由人类通过观察真实场景,融入自己的思考之后将其抽象成一些可解释可执行的规则。这种方法能够很好地反应驾驶场景的本质。但由于规则编写本身是一件复杂,互相牵制的事情。完全由人工来进行则难以规模化。

而数据驱动的方法则是试图建立从输入到输出的映射关系。在这个过程中,通过将驾驶场景转换到压缩的表征空间来尽可能提取。因为有一个说法是压缩即智能。但这个空间很有可能因为下游任务的限制,overfit到了任务空间而不是真正的理解了交通场景。Data-driven更像是一种行为主义(behaviorism),只是体现了智能行为,但并不是真的理解了场景,所以性能存在边界。

而知识驱动的自动驾驶首先需要具备场景理解的能力,归纳出通用的一般性规律,再进而推演到真实的理解空间中。但由于「知识」这个概念就像「智能」一样很难定义,所以我们只能从行为主义的角度来观察如何才能实现知识驱动自动驾驶。

图片

我们认为,知识驱动自动驾驶的三个关键特征是:泛化性、可解释性终身学习的能力。

想要实现知识驱动自动驾驶并落地,可能需要满足这三个特征。

首先来说说泛化性

图片

如前面所述,由于数据驱动的方法在面对out-of-domain问题时难以解决。例如我们很难在任务设计时就考虑路上有飞机迫降这种极端的cornercase。

图片

而知识驱动的方法通过大量在Open Domain数据上预训练所获得的通用知识,使得我们有可能对out-of-distribution的数据进行理解。

图片

泛化性是解决Unknown的关键,能把工程师从处理Corner Case的重复性劳动中解放的希望。我们用这张图来解释一下。上面一排指场景空间,下面一排是驾驶能力的空间。

对于Single Domain的数据驱动方法来说,我们从场景空间中采集数据并训练模型,学会其到驾驶能力空间的映射,同时对该domain产生一些泛化性的外溢,举个不严谨的例子:只用高速公路数据训练的模型,在高架上可能同样适用。但对于domain外的泛化性还是较弱。例如只用高速数据训练的模型,在梧桐区(上海某个开车停车都很费劲的开放街道)就不能用了。

于是大家从数据采集的角度入手,增加数据覆盖率,并将各种数据混合到一起,形成了Multiple Domain的数据。然后得到的模型不但能够处理各自domain的能力,还具备了一些初步的泛化性。例如收集了晴天、雨天数据训练的模型,在阴天可能仍然能用。然而这种数据采集也只是解锁了一些不同的场景,对于非常偶然出现的corner case,仍然不能像人一样从场景理解的角度出发来给出正确的分析和解释。

而第三列表示的是知识驱动的方法。如果我们有一种方法能够挖掘到海量不同domain的数据内在的关联,具备一些初步的通用理解能力,那就有可能对偶尔出现的场景如同人类一样实现举一反三。实现最终的泛化能力。

所以说,泛化性不但是自动驾驶领域研究关注的重点,也会是知识驱动的一个特性和体现

图片图片图片

再来说说第二点,可解释性。为什么可解释性重要?

  1. 首先,它可以作为「理解」和「知识」的佐证:可解释是智能的充分不必要条件。可以联想到图灵测试。
  2. 第二,一个完全的黑盒只能通过数据驱动来训练,又走回了老路。所以完全端到端,我个人反而是不太相信的。
  3. 第三,对解释的反思能够更直接地修正模型:非梯度方法。例如当我们让模型自己反思哪里做错了,如果能解释出个所以然来,说明模型具备了很强的能力。
  4. 第四,我们认为可解释性是实现Life-long Learning的一种显式的方式和先决条件。

例如我们尝试利用大模型来描述一下之前的场景,我们发现一旦操作变得可解释,那这些决策就会变得可信且合理起来。(这个是比较早的尝试,当时用的LLaMA-Adapter实现图片描述,用GPT3.5试试做决策和判断)

图片

第三点,Life-long Learning。

为什么Life-long Learning非常重要?因为从机器人或者具身智能的角度出发,一个Agent的脑中其实蕴含了对真实环境的建模。而Life-long Learning的能力决定了这个脑中世界和真实世界的差异程度。

像是现在的数据驱动方法,由于人工框定的任务限制了它施展能力的范围,导致其只能用「管中窥豹」的方式来建模世界,最终只能成为一个井底之蛙,认为的世界就和别人让他看到的世界一样。

而参考人类的思维方式,经验只会随着年龄不断积累。新司机可以通过积累经验成为老司机。并且很多驾驶经验并不来源于驾驶本身,而是从很多其他领域持续学习得来经验。

而Life-long Learning也是将整个系统落地上车的决定性因素。在这里插一句,我感觉像之前特斯拉展示的End-to-end的一些方法看起来很fancy,但实操起来会有很多挑战。最大的挑战是,在缺乏对中间过程的supervise的情况下,如何对规模庞大的模型实现持续学习/终身学习?所以可能UniAD这种中间可以插入supervise的方法举例落地会更现实一些。(除非World Model真的实现,后面再细聊

在介绍完知识驱动自动驾驶基本定义之后,再来聊一下最近出现的LLM是否对知识驱动自动驾驶能有所帮助。

其实一直以来我的一个思想是:知识驱动是第一性原理,但LLM不是。LLM只是在现阶段能够实现体现出知识运用能力的一种工具,它虽然具备基础的通用理解能力,但不见得所有事情都要靠LLM。让LLM开车并不是一个长久的方向。

图片

首先来统一一下术语。

我们发现工业界引入「大模型」这个概念的时候发生了大量的术语混淆。难道「大号的模型」就是大模型吗?比如像SAM算大模型吗?BEV算法属于大模型吗?甚至一些人在到处讲,Transformer就是大模型。

但从学术上,LLM其实是有着明确的指向的。

图片图片

(下面这段关于LLM的整理不是很严谨,请批判性阅读)

并不是用了transformer或者数据量大就是LLM,应该是采用LLM或者VLM架构且在大规模数据上进行训练,并且跟随scaling law出现了涌现的现象,才是我们讨论的LLM

想要解释清楚LLM发展的来龙去脉需要比较长的篇幅,也不是本文要讲的重点。所以这里就简要概述一下。

早期的大模型,是在Transformer之后出现的如BERT、ELMo、GPT等在内的语言模型。其本质就是一个语言模型,用来建模一句话的发生概率。其训练方式是输入第1到t-1个token,预测第t个token应该是什么。并且在那个时候利用海量纯文本数据,通过随机对一些词进行mask,或者对两句话交换顺序等各种各样的下游任务,迫使模型能够更好地理解一句话内包含的语义。那个时候是NLP的黄金时代,因为大模型通过海量的数据获得了基本的语言理解能力,使得很多任务都利用大模型实现了突破。

而后大模型也面临一个life-long learning的问题。之前很多大模型还是以研究为主,直到后来出现了一些工作,发现大模型是可以随着堆料性能不断增加的。这就刺激到了工业界。工业界就喜欢这种力大砖飞的模式,因为每一分钱的投入都有可以计算的预期收益。然后就掀起了现在大模型研究的热潮。随后又出现了In-Cotext Learning, Chain-of-Thought等等各种技术,甚至催生了提示词工程这个行业。

时至今日,大模型的范式基本是统一的,首先就一个参数量巨大的Foundation Model,再利用部分和任务相关的数据进行Instruct-tuning。像ChatGPT就是在GPT这个Foundation Model中用少量高质量的对话数据对齐的能够对话的模型。后面这个过程通常不被称为是训练而是对齐,我个人感觉可能是因为,Foundation Model已经具备了很强的能力,而少量的Instruction-tuning只是为了向大模型展示任务需要,让大模型的表现对齐到人类预期的行为之上。

解释一下大模型的一个有趣的现象,就是可以通过In-context-learning实现few-shot来完成一些任务。而我们也可以通过SFT来将这些能力内化到大模型内部。

近期出现了大量的LLM+AD的工作,这里快速介绍一下,不是本文的重点。

图片

LanguageMPC利用LLM进行了细粒度的决策,通过将场景结构化成文本送入大模型,来和环境进行交互。通过接了一个具体的行为控制模块实现具体的驾驶行为的输出。其主要是利用了大模型对场景进行编码的能力。

图片

DriveGPT4则是试图引入一个带有视觉的VLM,实现对输入视频的理解,并且能够根据prompt完成一些QA任务。包括生成控制信号等等。

图片

↑这篇工作则同样是利用大模型来处理控制的工作。通过将场景向量化表征,并且通过一些数据对大模型进行了SFT使其变成了能够输出控制信号的大模型。

和上面这些LLM+AD的工作区分开,下面这页Slides才是我想表达的重点:

图片

这些LLM+AD的工作真的能解决一切问题吗?我不认为。

我觉得大模型尽管能展现出generalization和interpretability。但仍然存在诸多问题:

  1. 幻觉:因为LLM的训练方式导致其必然会输出一些文本。直接影响安全性和正确性。
  2. 响应速率低下:影响实时性,最终导致安全和效率都会受损。
  3. 对齐税:朝着自动驾驶任务SFT,反而会丧失一部分通用性和泛化性。
  4. 并且SFT成本高,难以通过SFT的方式实现Life-long Learning。

其实一直以来我的一个思考是:知识驱动是第一性原理,但LLM不是。LLM只是在现阶段能够实现体现出知识运用能力的一种工具,它虽然具备基础的通用理解能力,但不见得所有事情都要靠LLM。让LLM开车并不是一个好主意。所以我们需要的是借助LLM的能力,而不是all in在LLM上,让LLM成为一个万能的工具。

受到最近一些Multi-agent和Embodied AI研究的启发,我们认为,LLM可以作为一个CPU,利用好它的generalization和interpretability,配合memory实现life-long learning,结合外部的专家系统、Retrieval Augmented Generation技术来解决幻觉问题,共同构建成一个Driver Agent。

所以接下来介绍一个我心目中的知识驱动自动驾驶的架构

图片

让我们先跳出LLM的制约,从认知的角度先来讨论一个通用的知识驱动的框架。它更像是一种Embodied AI的架构在AD的应用。

上图展示了一种利用Agent来操作工具、进行规划,并结合Memory机制最终产生Action的架构。这个架构和人类认识世界和做决策的框架是类似的。

更进一步,我们认为其实知识驱动的自动驾驶也可以利用这样的框架进行(如上图下部分)。其核心是Driver Agent,通过对环境进行Observe,并从Memory中Query一些过往的经验,最终综合做出决策,并利用决策的执行情况作为修正信号来修正Memory。

图片

我们再进一步将其对应到自动驾驶场景中。首先我们利用场景理解系统来进行场景表征。并且基于这些表征进行决策。在决策过程中将会有过去的经验参与。如果决策是正确的,则会将其作为经验的一部分积累到记忆模块中。如果决策发生了错误,则也会要求系统能够反思错误,并将纠正好的正确经验重新加回到记忆系统中。整个系统不断迭代。最终记忆就成为了知识的一种表现。

图片

在整个系统中,我们可以让LLM参与到部分工作,但是并不是仅仅依赖LLM,于是我们构建了这样的系统。这篇叫做DiLu: A Knowledge-driven Approach to Autonomous Driving with Large Language Models。(To the best of our knowledge, 这篇应该算是非常早期探索LLM+Agent+AD的工作了,还有我们另一篇工作Drive Like A Human可能是第一篇探索大模型是否能和自动驾驶相结合的工作。)

整个系统包括了Reasoning、Reflection、Memory三个模块。首先在Memory模块中保存了一些驾驶经验行为。本质上是一个向量数据库。其中Key是场景的语义向量化表征(相似场景vector相似,不同场景vector不相似)。而Value则保存了这个场景曾经做出的决策,以自然语言文本来描述的。

在推理模块中,我们首先对环境进行编码,利用这个编码从记忆模块中query相似场景。并将这个信息作为prompt,和当前场景一起输入到大模型中。也就是说,此时大模型既输入了当前场景的描述,又输入了记忆中相似场景和当时所作出的决策作为共同信息,并且最终给出一个决策意见。我们将这个决策转换成Environment的控制信号,控制一个在虚拟环境中的车辆进行驾驶。

在驾驶过程中,我们可以知道这个决策是否正确。如果决策正确,我们会将这里的场景表征向量作为key,决策说明作为value来更新记忆模块中的经验。另一方面,如果决策出错,例如发生了碰撞或者其他危险行为,我们会借助大模型进行自我反思,并将整个反思过程一起加入到记忆模块中。

从这里就能看出之前我们提到的三个特性:generalization、interpretability、life-long learning的重要性。首先,泛化能力保证了对各种out-of-domain的场景的通用理解能力。而我们利用可解释的信息作为记忆系统,一方面能够追溯所有做出的决策,另一方面也能够用人类能够理解的方式来完成反思等复杂的内容。另外,也正是因为经验是以自然语言定义的可解释的文本,而这些文本常常是放之四海皆准的信息,不随domain变化而产生太大的漂移的。而整个经验库是在不断积累的,从而实现一个Life-long Learning。

还有就是这篇文章的Reasoning模块和Reflection模块,具体细节我就不介绍了,可以看看论文。

图片图片

这里有一个缩时演示的视频。我们采用了Highway Env作为仿真环境,每一步都是由大模型参与进行决策并交给仿真器来执行的。

图片这只是张图片动不了的,视频请点下面的链接

视频请点击链接:DiLu: A Knowledge-Driven Approach to Autonomous Driving with Large Language Mode_哔哩哔哩_bilibili

Slides后面有一些实验分析,这里我就不具体展开了不然文章篇幅太长了。(写到现在已经快1w字了)。一句话总结就是我们有这样几个发现:

  1. Memory机制真有用,这种类似于RAG(Retrieval Augmented Generation)的方法能够在不SFT模型的情况下,实现Continuous Learning的功能(但Life-long Learning还没试过,主要是Highway Env太toy了)。
  2. 真有泛化性:我们用Domain A的场景得到的Memory,直接在Domain B中用,发现
  3. 真有可解释性:Memory中的key是场景表征向量,value可就是纯文本啊。无论决策做对了还是做错了都是一目了然的,甚至可以reflect来修正记忆。

这里我们展示了反思模块的一些能力。例如这里进行了一个错误的决策。

图片

此时我们让大模型分别针对碰撞原因、其中的经验教训进行解释,并产生一份revised decision。我们会将整个这些文本都作为经验保存到记忆模块中。

图片图片

这篇工作作为一个非常初步的工作,其所选择的环境、能进行的决策空间等等非常有限,属于一个早期的toy性质的研究。所以也留下了很多Open Problems:

  1. 场景理解:Key该如何构建?
  2. 记忆该如何表征:显式地用自然文本?图像?还是隐式的representation?
  3. 是记答案?还是记「决策过程」?
  4. 进一步从人类思考的视角出发,如何与System I(快系统)和System II(慢系统)相结合?

另外再提一个我觉得很有意思的工作Agent-Driver([2311.10813] A Language Agent for Autonomous Driving (arxiv.org)),也是采用了Agent而非教大模型开车的模式。不过当时做Slides的时候忘记介绍了,后面有机会再补上。

除了DiLu以外,再介绍一些我们认为和Knowledge-driven相关的工作。其中部分工作也是我们团队正在进行的。

图片

首先,畅想一下未来,我们认为未来的自动驾驶系统有可能发展成这个样子。这张图来自于我们最近的一篇Survey(说是Survey,但其实也包含了我们很多思考):Towards Knowledge-driven Autonomous Driving。

一方面从真实世界中提取信息积累常识知识。另一方面利用真实世界的数据,构建高质量的虚拟的仿真引擎。并通过在仿真引擎中积累交互知识。反复重复这个过程实现life-long learning。

图片

所以这就引发了三个探索的方向,我们认为是目前学术界比较火热的方向(换句话说:很卷的方向):自动驾驶的Foundation Model(完成场景理解、辅助决策)、知识驱动的Autonomous Driver Agent(Memory机制、RAG)、高一致性的仿真引擎。

图片

首先是我们该如何利用Foundation Model?这可能依赖于通用大模型的理解能力,也需要一些利用大模型针对自动驾驶追至领域SFT的探索。

但我觉得大模型在这个环节的参与可能体现在场景理解和Decision Making上。因为这些功能充分体现了大模型处理out-of-distribution问题的能力,以及宏观决策能力。并且由于不是直接将方向盘交给大模型,所以能够从一定程度上缓解幻觉的问题。

图片

另一块我觉得非常有趣且有潜力的方向就是世界模型。

世界模型早在2018年甚至更早就被已提出,其架构的本质是利用下一帧预测来让模型理解整个世界。我觉得世界模型的一个应用点在于场景理解:因为能正确预测出下一帧的样子,说明中间的vector包含了对整个场景的编码表征。

图片

基于世界模型的思路,Wayve提出了GAIA-1,可能是第一个自动驾驶领域的世界模型。

图片

还有国内一家叫做极佳科技和清华大学合作推出的DriveDreamer。我们跟他们交流比较多,不过目前看来不得不屈服于市场:用World Model来生成数据卖。

图片

DriveDreamer主要是支持多种prompt输入,包括文本、参考图像、HDMap和3D Box与对应的action。而后由模型在这些信号进行控制的情况下输出未来帧的视频。

图片

还有上个月刚公开的ADriver-I则是利用VLM进行图像生成的工作。有种把世界模型和LLM相结合的感觉。

第二个值得重点关注的方向就是仿真。

自动驾驶的仿真引擎并不算一个很新的topic。其实目前也有很多仿真引擎被广泛应用,例如Carla、VTD等等。但这些仿真引擎仍然存在诸多问题。比如传感器仿真不够逼真、交通流很多也是基于规则或者机理模型,导致难以进行端到端的闭环仿真测试。

所以其实我们团队过去两年中花了大量的精力在构建一个高质量的端到端闭环仿真引擎。

图片

为了获得高一致性的仿真传感器数据,我们采用了神经渲染的思路。这种方法能够用自动化的方法高质量地对场景和物体进行三维重建。

图片

我们构建了名为OASim的基于神经渲染的自动驾驶仿真器(将会在近期开源)。

它能够进行相机、激光雷达等在内的传感器仿真。并且由于我们的技术路线不同于NeRF的体渲染,而是采用了SDF-based的表面渲染,使得我们能够同时重建好形状和外观,甚至可以用来进行数据生成并帮助感知模型训练。

图片本来是段Demo的录屏的,后面有机会开源的时候再release图片

所以我们打通了从重建,到泛化,再到生成的整个链路。甚至我们可以仿真生成激光雷达的数据:

图片图片

第三点,就是将Agent与自动驾驶相结合,也是我们DiLu的后续研究方向。并不是简单地教大模型开车,而是利用大模型的通用理解能力,通过各种外部工具,务实地实现自动驾驶。不能为了用LLM而用。

目前我们在探索闭环评测,因为我觉得只在开环数据集上进行训练和评测已经略显疲态。尽管有一些基于仿真引擎做闭环训练的工作已经出现,但评测终究是开环的。我们目前正在尝试构建一套基于全功能Agent的pipeline,实现自动驾驶的incremental learning甚至是life-long learning。

最后再介绍一些我觉得和Knowledge-driven AD相关,但可能还需要一些时间才能看到的工作和方向。

图片

首先:小大模型的上车,比如一些1B的模型可能已经具备了在边端推理(甚至训练)的能力。以及一些线性Transformer的工作,如果真有一天能够上车就有趣了。因为现在大模型动辄规模这么大还是因为其本质是个通用模型。但如果我们只需要通用模型在某个子领域的一小部分能力,是不是不需要这么大也可以了?

第二,最近的一个概念:Superalignment。就是我们是否有空了能用小尺寸的大模型来supervise大尺寸的大模型。因为相比用小模型生成合适的语料喂给大模型来训练,可能用小模型来为大模型的训练提供supervise可能是个更容易的任务。OpenAI可能会用它来取代RLHF等简单任务中的人力,但仔细想想,这是不是下一代的「影子模式」?

第三,直接在世界模型中训练AD算法:其实这才是我觉得World Model的本质啊。一个能够建模整个世界的模型,一定能够完美地理解世界,也能够用来将自己对世界的理解拿来supervise自动驾驶算法本身?

第四,重建即感知:这也是最开始入坑多模态传感器融合感知时候的思考。即:其实无论多模态传感器融合、环视相机融合还是什么融合算法,其实本质就是在做「对齐」。这些算法的目标就是把各种不同位置不同模态的数据对齐到一个Unified Space。然后后面的算法再从这个Unified Space出发。其实仔细想想,无论是Pillar、Voxel,还是后来的BEV,和Occupancy,其本质都是一个一个用来对其的Unified Space。既然space这么多,究竟哪个Space最好?通常意义上来说,我们期待学习一种从输入空间到流形空间(关于流形空间很多年前我有过一个回答大家可以看看:求简要介绍一下流形学习的基本思想?)的映射。那么什么空间是最标准的对齐空间呢?我觉得就是3D空间啊。不同模态的传感器,都对齐到同一的3D空间。其实这件事本质就是做三维重建了。。。所以我觉得冥冥之中,「三维重建」和「场景理解」这两件事情总有一天会合二为一。重建即感知。

写到这里,这篇文章基本就结束了。可能废话有些多,主要都是我最近一段时间的思考,和我们团队的一些努力。最后回顾一下主旨

  1. LLM+AD的出现,意味着大家意识到了这是一个从数据驱动到知识驱动的时机
  2. 知识驱动可能有三个特性和目标:泛化性、可解释性、持续学习
  3. 我个人认为,没必要非要追求用LLM实现端到端的自动驾驶。因为大模型存在幻觉、推理速度慢等非常多的问题。我们应该利用的是LLM的知识运用能力、推理能力,并从Agent的角度出发,探索出一种能够利用LLM但不依赖LLM的架构,渐进式地构建新一代的自动驾驶系统。
责任编辑:张燕妮 来源: 自动驾驶之心
相关推荐

2019-12-02 10:23:49

人工智能机器学习技术

2020-10-22 15:35:35

自动驾驶美团人工智能

2017-12-21 07:54:07

2018-02-25 05:45:35

2012-12-19 09:36:49

测试自动化测试

2023-09-22 11:56:57

模型驾驶

2018-01-05 14:23:36

计算机负载均衡存储

2018-01-17 09:15:52

负载均衡算法

2023-11-08 10:14:02

模型学习

2020-09-11 10:55:10

useState组件前端

2024-03-07 10:29:43

端到端自动驾驶

2021-06-10 10:02:19

优化缓存性能

2021-02-28 09:47:54

软件架构软件开发软件设计

2021-02-19 23:08:27

软件测试软件开发

2018-11-23 11:17:24

负载均衡分布式系统架构

2020-01-09 08:42:23

自动驾驶AI人工智能

2024-04-15 11:40:37

自动驾驶端到端

2020-08-20 10:16:56

Golang错误处理数据

2020-10-14 08:04:28

JavaScrip

2021-05-28 07:12:59

Python闭包函数
点赞
收藏

51CTO技术栈公众号