首页/文章/ 详情

自动驾驶测试的4大“显眼包”:LogSim/WorldSim/SIL/HIL,终于分清了

6月前浏览715


大家好呀,我是李慢慢。

最近工作中,总是要跟各种各样的新手/外部门的同事反复解释什么是logsim,什么是HIL,和worldsim有啥区别,和SIL是什么关系,搞得我也很头大,于是写了这篇文章,下次再来问我,我就发这个文章给ta看。真省事。

搞自动驾驶相关的小伙伴,不管是做仿真的、做产品设计的,还是做算法开发的,大概都有过这样的崩溃瞬间:

1)开会时别人聊LogSim和WorldSim聊得热火朝天,你在旁边假装点头,心里疯狂OS“这俩到底啥区别?”;

2)被问“SIL和HIL哪个先做”,嘴巴张了半天,蹦不出一句完整的话;

3)尤其是初次接触这些词汇的新手,更是听得云里雾里,甚至有人把LogSim当成SIL的“亲戚”,把WorldSim和HIL混为一谈,场面尴尬到能用脚抠出三室一厅。

其实真不怪我们笨,主要是这四个“选手”名字太像,又总被绑在一起说,乍一看就像孪生四兄弟,难辨真假。今天咱就放下专业术语的“架子”,用最接地气、最诙谐的方式,把这四位“大佬”的底细扒得明明白白,看完保证你再也不闹笑话,开会发言都能挺直腰板!

先划重点:

LogSim和WorldSim是“场景界的俩极端”,LogSim靠“回忆”过日子,WorldSim靠“脑补”造世界;

SIL和HIL是“测试界的上下级”,SIL在电脑里“纸上谈兵”,HIL连真硬件都搬来“实战演练”。

两者不是一回事,但经常组队干活,就像奶茶里的珍珠和芋圆,虽然不一样,搭在一起才够味。

第一组:场景界的“真假美猴王”——LogSim vs WorldSim

先给这俩定个性:它们俩的核心任务,都是给自动驾驶的“大脑”(算法)搭“练车场”,但一个是“实景回放”,一个是“虚构剧本”,差别大到离谱。

LogSim:老实人实锤,只搬“真实录像”的“回放员”

LogSim这名字,拆开来念就好懂:Log是“日志”,就是实车跑在路上时,传感器录下的所有数据(比如路上有多少车、行人走得多快、红绿灯怎么变);Sim是“仿真”,说白了就是把这些日志数据“回放”一遍,让算法再“走一遍”真实的路。

咱举个通俗的例子:LogSim就像你开车时,行车记录仪录下了全程,事后你把录像调出来,再看一遍自己当时怎么开的、路上发生了啥。只不过这里的“观众”,是自动驾驶算法;“目的”,是让算法看看“真实世界里,我上次遇到这种情况,处理得对不对”。

它的优点很明显:真实、靠谱、不掺水。毕竟数据都是实车跑出来的,路上的突发 情况(比如行人突然横穿马路、电动车逆行、前车突然急刹)、复杂路况(比如暴雨天、大雾天、堵车),都是最真实的场景,没有一点“虚构”成分。比如路测时遇到需要人工接管的危险情况,这些“惊险瞬间”都会被LogSim记录下来,后续用来迭代算法,帮算法“吸取教训”,下次再遇到就不会慌了。

但缺点也很致命:死板、不灵活,不能“改剧本”。录下来的数据是啥样,回放就是啥样,你想改改“如果当时行人走得再快一点,算法 会怎么处理”?不行!想加个“路上突然出现一只小狗”的场景?也不行!它就像个老实巴交的回放员,只负责照搬录像,多一句废话、多一个动作都没有,主打一个“原汁原味”,也主打一个“墨守成规”。

WorldSim:脑洞达人,靠“脑补”造世界的“编剧+导演”

和LogSim的“老实”相反,WorldSim就是个“脑洞大开的造梦师”。World是“世界”,Sim是“仿真”,意思就是它不依赖任何真实路测数据,全靠人工预设参数,“编”出一个虚拟的驾驶世界。

还是举例子:WorldSim就像你玩赛车游戏,游戏里的赛道、车辆、行人、红绿灯,都是游戏开发者编的,不是真实世界里的路;你可以设置“路上只有一辆车”,也可以设置“堵车堵到怀疑人生”;可以设置“晴天”,也可以设置“暴雨+大雾”,甚至可以设置“外星人横穿马路”(虽然现实中不会有,但仿真里能用来测试算法的极限)。

它的优点正好和LogSim互补:灵活、任性、想咋改就咋改。算法需要练什么场景,就编什么场景;哪里练得不好,就反复调整场景参数,直到算法练会为止。比如要测试算法的自动紧急制动(AEB)功能,就可以用WorldSim预设“前车突然急刹”的场景,反复测试,直到算法能100%反应过来,而且还能调整前车的速度、距离,测试各种极端情况。

缺点也很直接:不够真实,有点“纸上谈兵”。毕竟是人工编的场景,再逼真,也比不上真实世界里的“混乱”——真实路上的行人不会按你的预设走路,电动车不会按你的参数逆行,总有各种意想不到的突发 情况,这些都是WorldSim编不出来的。而且WorldSim有个“小前提”:默认算法的“眼睛”(感知)是正常工作的,不用测试感知的准确性,只专注于算法的决策和控制能力,这点和LogSim的“全真实回放”差别很大。

总结一下LogSim和WorldSim:LogSim是“真实但死板的回放机”,WorldSim是“灵活但虚构的造梦机”;一个帮算法“复盘过去”,一个帮算法“演练未来”;实际工作中,两者往往一起用——先用WorldSim让算法“打基础”,练会各种常规场景,再用LogSim让算法“见世面”,适应真实世界的混乱,缺一不可。现在是不是觉得,这俩“显眼包”的区别,比奶茶和咖啡还明显?

第二组:测试界的“上下级”——SIL vs HIL

如果说LogSim和WorldSim是“练车场”,那SIL和HIL就是“考试环节”——它们的核心任务,是测试自动驾驶的“大脑+手脚”(算法+硬件)好不好使,能不能应对各种情况。但两者的“考试难度”天差地别,一个是“笔试”,一个是“实操”,而且必须先过笔试,才能进实操。

先澄清一个最常见的误区:很多人把SIL和LogSim、WorldSim搞混,觉得“SIL就是用WorldSim测试”“LogSim属于HIL”,其实大错特错!SIL和HIL是“测试方式”,LogSim和WorldSim是“测试场景”——不管是SIL还是HIL,都可以用LogSim的场景,也可以用WorldSim的场景,就像不管是笔试还是实操,都可以考“基础题”,也可以考“难题”,场景是“考题”,测试方式是“考试形式”,别再弄混啦!

SIL(Software-in-the-Loop):软件在环,电脑里的“纸上谈兵”选手

翻译一下:Software是“软件”(就是自动驾驶的算法代码),Loop是“闭环”,合起来就是“让算法软件在一个虚拟的闭环里跑测试”。说白了,就是所有测试都在电脑上完成,没有任何真实的硬件——不用实车,不用控制器(ECU),不用传感器,就靠一台电脑,装着算法代码和仿真场景(LogSim或WorldSim),让它们“自己玩”,然后看算法的表现。

类比一下:SIL就像你想考驾照,还没摸过真实的车,先在电脑上玩“驾考模拟器”,熟悉方向盘、刹车、油门的操作,看看自己能不能顺利通过科目二、科目三。模拟器里的赛道(场景),可以是真实考场的复刻(类似LogSim),也可以是随便编的赛道(类似WorldSim);你操作的“方向盘”“刹车”,都是电脑上的虚拟按钮(类似算法代码),全程不用碰真实的车。

它的核心作用,是“筛错”——把算法里最基础、最明显的错误先筛掉,比如算法分不清红绿灯、不会转弯、遇到障碍物不知道避让,这些低级错误,在SIL阶段就解决掉,不用等到后续用真实硬件测试,节省时间和成本。而且SIL测试成本极低,只要有电脑就能搞,还能一次性跑上千个场景,效率超高,堪称“算法的入门考官”。

缺点也很明显:太“虚拟”,脱离现实。它只测试算法代码好不好使,不考虑真实硬件的“脾气”——比如真实的控制器(ECU)运行速度会不会跟不上算法?传感器传输数据会不会有延迟?这些问题,SIL测试完全测不出来,毕竟它连真实硬件都没有,就像你在模拟器上开得再溜,真正摸车时,还是会紧张、会出错一样。

HIL(Hardware-in-the-Loop):硬件在环,搬来真家伙的“实战演练”大佬

HIL比SIL高一个级别,也更“硬核”——翻译一下:Hardware是“硬件”(比如自动驾驶的控制器ECU、传感器、执行器),Loop是“闭环”,合起来就是“让真实的硬件,和虚拟的场景闭环联动,做实战测试”。

简单说,HIL就是把自动驾驶的“手脚”(真实硬件)搬过来,和电脑里的“大脑”(算法)、“练车场”(场景)连在一起,模拟真实开车的场景,让它们一起“干活”。比如,把真实的ECU(相当于自动驾驶的“大脑中枢”)连接到电脑上,电脑里运行LogSim或WorldSim的场景,场景里的红绿灯、障碍物信息,会传输给真实的ECU,ECU再发出指令,控制虚拟的车辆(或真实的执行器)做出反应,整个过程和真实开车几乎一模一样,只不过车辆和道路是虚拟的,“大脑”是真实的。

类比一下:HIL就像你考驾照时,教练坐在副驾,你开着真实的车,在真实的考场里练车——你(算法)操作方向盘、刹车(真实硬件),考场(场景)是真实的,教练(测试系统)在旁边看着你,一旦出错,就及时指出来。而且HIL还能模拟各种极端情况,比如高速爆胎、突发暴雨,这些情况在真实路上测试太危险,在HIL里就能放心测,既安全又高效。

它的核心作用,是“验证”——验证算法和真实硬件能不能“好好配合”,能不能应对真实世界的复杂情况。比如,ECU运行算法时会不会卡顿?传感器传输数据有延迟时,算法能不能及时反应?这些问题,只有HIL能测出来,毕竟它用的是真实的硬件,和实际装车后的情况几乎一致。而且HIL测试是自动驾驶落地前的“关键一关”,过不了HIL,就别想实车路测,更别想量产。

缺点也很实在:贵、复杂。一套完整的HIL测试系统,动辄几百万、上千万,不是一般公司能承受的;而且搭建起来很复杂,需要专业的工程师调试,测试效率也比SIL低(毕竟要联动真实硬件,不能像电脑那样快速批量测试),堪称“自动驾驶测试界的奢侈品”。

终极总结:一张表分清4大“显眼包”,再也不混淆

怕大家记不住,咱直接上“懒人总结表”,一看就懂,收藏起来,开会忘了就偷偷瞄一眼:

选手名称      
身份定位      
核心特点      
通俗类比      
LogSim      
场景界·真实派      
实车数据回放,真实但死板,不能改场景      
行车记录仪回放录像      
WorldSim      
场景界·虚构派      
人工预设场景,灵活但不真实,可随意改      
赛车游戏里的虚构赛道      
SIL      
测试界·入门级      
全电脑测试,只测算法,成本低、效率高      
电脑上玩驾考模拟器      
HIL      
测试界·进阶级      
真实硬件+虚拟场景,实战测试,贵且复杂      
真实硬件+虚拟考场练车      

最后补一句:别再乱搭CP啦!

再澄清一个最容易犯的错误:LogSim≠SIL,WorldSim≠HIL!它们的正确搭配是:

  1. 1. SIL测试(电脑上):可以用LogSim的真实场景,也可以用WorldSim的虚构场景,核心是“没有真实硬件”;
  2. 2. HIL测试(有真实硬件):也可以用LogSim的真实场景,也可以用WorldSim的虚构场景,核心是“有真实硬件,联动测试”;
  3. 3. LogSim和WorldSim:可以单独用,也可以一起用,比如先用WorldSim让算法练基础,再用LogSim让算法适应真实场景;
  4. 4. SIL和HIL:必须先做SIL,再做HIL,就像先考笔试,再考实操,一步都不能少,而且两者都过了,才能进入下一步的实车路测,最终实现自动驾驶落地。

所以,我们在说某种测试方法时,可以说LogSim-SIL,LogSim-HIL,也可以说WorldSim-SIL,或者WorldSim-HIL,这样描述,才能精准的表达一种测试方法。备注,要是能带上开环or闭环这样的字样,就更完美啦,关于开闭环,稍微有点复杂,我们后面再介绍哦。

看到这里,相信你再也不会把这四个“显眼包”搞混了吧?其实自动驾驶仿真没那么神秘,说白了就是“给自动驾驶算法找地方练手、找地方考试”,LogSim和WorldSim是练车场,SIL和HIL是考试环节,各司其职,又相互配合,一起帮自动驾驶“从新手变成老司机”。

当然啦,咱们今天聊的LogSim、WorldSim、SIL、HIL,只是自动驾驶仿真领域最基础、最常见的“入门款”。除了这四位“显眼包”,还有不少“同门师兄弟”——比如场景转换常用的log2world,还有DIL、VIL等其他测试方法,每一种都有自己的专长,也有各自的局限。自动驾驶软件质量的守护,从来不是靠某一种工具、某一个方法就能完成的,更需要每一位从业者满怀敬畏之心,不盲从、不片面,学会取长补短,把每一种工具的优势用到位,把每一处细节的漏洞堵严实,才能守住软件质量的底线,让自动驾驶真正变得安全、可靠

看到这里,相信你再也不会把这四个“显眼包”搞混了吧?以后再有人问你这四个词的区别,直接把这篇文章甩给他,或者用咱今天说的类比,通俗易懂地讲一遍,保证对方对你刮目相看!如果还有啥不懂的,评论区留言,咱再接着唠~

以上。

   

关于自动驾驶仿真的定义


 
   

PanoSim与Autoware联合仿真-如何构建自动驾驶远程接管系统


 
   

跨越“仿真到实车”的鸿沟:如何构建端到端高置信度验证体系?


 


来源:车路漫漫
自动驾驶游戏控制
著作权归作者所有,欢迎分享,未经许可,不得转载
首次发布时间:2026-02-05
最近编辑:6月前
李慢慢
硕士 自动驾驶仿真工程师一枚
获赞 14粉丝 93文章 320课程 0
点赞
收藏
作者推荐

洞见 | 搞智驾这7年,绝大多数的数据闭环都是伪闭环

转载一篇来自知乎的高赞文作者知乎-李众力万字长文,建议先收藏原文如下,略有改动2025 年年底了,我也来回答一下(上面这个问题)。先说结论:据我能接触到的一圈国内玩家,大家嘴里的“数据闭环”,绝大多数还是各个算法团队内部的“小闭环”,离当年 PPT 里畅想的那种“数据直接解决问题”的大闭环,还有好几层台阶。先简单说下我自己的背景(方便大家判断我是不是在瞎说)我从事自动驾驶行业大概 7 年多了,从最早那种“开完车工程师拎着硬盘,从工控机上拔下来,抱着去机房拷数据”的年代一路干到现在。这几年主要在一家互联网大厂的物流无人车项目里,从封闭园区到高速公路再到城市公开道路,从载人到拉货都有涉及,负责整车的数据体系和质量体系搭建,带团队做的事情大致包括:设计并落地一整套触发器(Trigger)体系:从车端实时触发,到云端历史数据挖掘、仿真评价,做到代码级统一;搭建从“线上问题发现 → 自动分发 → 数据挖掘 → 训练 / 仿真验证 → 上线回归 → 指标追踪”的闭环平台;把多模态大模型(LLM + VLM)嵌进来,做问题自动分类、自动路由到对应团队,以及辅助研发 / 测试写 Trigger 规则;把“每一次急刹车、每一次接管、每一次奇怪行为”都结构化、可计算,减少拍脑袋和微 信群里吵架。日常工作基本就是跟各种 log、Trigger、标注平台、仿真平台、QA 流程和一堆诡异 bug 打交道,是一个比较典型的“数据闭环 + 质量体系”视角。下面所有观点,都是站在这个视角下的个人经验,不代表任何公司官方意见。一、先对齐一下:什么叫“真的数据闭环”?我心目中“真闭环”,至少要满足以下两层:1. 问题发现自动化不是靠“司机吐槽 + 群里截图 + 领导试驾骂了一句”触发,而是系统能从海量运行数据里自动发现异常行为:急刹、急打方向、蛇形行驶、异常接管激增;某些路段/路口的安全指标或体验指标显著变差;难得一见的安全边缘场景(险撞、鬼探头、复杂博弈)。问题到方案的路径是“可重复、可量化”的简单讲就是: 一个线上问题 → 自动被归类、建成数据集 → 自动进训练 / 仿真 → 产出候选方案 → 自动评估效果人主要做的是定义目标 & 拍板,而不是从 0 到 1 手工搬砖。2. 解决效果可量化、可复盘新版本上线后,系统要能持续回答三件事:这个问题的发生频率有没有下去?有没有引入新的负面问题?(典型:安全好了体验全崩)这次数据、算力、开发投入,值不值?一句话概括: 真正的数据闭环,是“问题会自己长脚走完从『被发现』到『被解决并被验证』的路径”,人是设计规则和做决策的,不是不断重复体力劳动的。二、现实里大多数厂商在做什么?比较诚实的说法:今天很多所谓“数据闭环”,其实是“数据驱动的研发流程 + 一些自动化工具”,而且大多局限在单个算法团队的小视角。一个典型流水线大概是:线上触发 / 抽取各模块(感知 / 预测 / 规划 / 控制……)各自定义一些 Trigger,捞“疑似有问题”的包;清洗 & 标注离线脚本过滤脏数据;扔给标注平台做 2D/3D/语义/地图各类标注;好一点的有自动 / 半自动标注。训练 / 回归算法选一堆 case 训练,离线回归集跑指标;有条件的多加一步仿真 / 重放。上线 & 监控A/B、灰度,上线;继续靠新一轮 Trigger+人工发现问题。这一套当然也算“闭环”,但更多是模块级、算法视角的小闭环,离“系统级的闭环”差得不少。三、为什么说“还没真闭”?几个典型断点1. 起点是“被动闭环”,不是“自动发现问题”现在大量问题还是这样来的:司机反馈:某个路口老出事;运营/客户投诉:体验太差;领导试驾了一圈觉得某段路不对劲;测试同学肉眼刷录像刷出来的坏 case。然后才反推:“我们加个 trigger 把这种情况捞上来吧。”这其实是问题驱动数据,而不是数据自动发现问题。理想状态是:安全 / 体验 /效率等指标被持续量化;某个区域、某个版本、某个车型某项指标异常偏离,系统自动报警;自动聚类对应数据包,把相似问题聚成“问题簇”。这一块目前能做得比较好的厂并不多,大多数还是停留在“若干 Trigger + 一些报表”。2. 归因困难:只知道“有坑”,但不知道“谁填坑”同一个现象背后,往往是高度耦合的组合原因:感知偶发漏检 → 预测轨迹偏差 → 规划保守 → 控制多次点刹;地图拓扑错误 → 规划路径不合理;标定漂 / 传感器轻微移位 → 融合结果整体偏。没有成体系的诊断工具,就容易变成:每个团队都说“不是我,是他”;或者大家各改一点,谁也说不清到底哪步真正解决了问题。现实里,很多地方还是靠有经验工程师肉眼跳 N 个界面,一点点分析,离“数据自己定位问题”远得很。3. 数据到“方案”的链路,停在了“数据到模型”很多团队的闭环,其实可以概括成: 数据 → 标注 → 训练 → 离线指标涨了 → 上线但是:解决了哪个线上“真实问题”?这次改动的经验,以后能不能自动复用?这次投入算下来值不值?要么没人追,要么追得很粗。大多数只是在“技术指标”的层面闭环,不是在“问题 / 业务”的层面闭环。4. “自愈”的程度非常有限PPT 里常见的一条线: 线上问题 → 自动收集 → 自动标注 → 自动训练 → 自动评估 → 自动上线现实里更像:自动收集:有一部分自动,但经常被各种异常打断;自动标注:有预标,但人力复核仍然是大头;自动训练:流水线是自动的,但选数据、配配置很多手动;自动评估:离线指标自动,仿真和线上表现难以完全自动;自动上线:真到“上路要负责”这一步,大家都不敢真全自动。所以现在很多所谓“闭环平台”,本质是一个高度自动化的工厂生产线,而不是一个可以自我决策的“自愈系统”。5. 组织结构天然把闭环“拆成几节”还有一个被低估的问题:组织结构本身就是断点。感知、预测、规划、控制、地图、云平台,各有各的 OKR;Tier1、整车厂、云服务商,各有各的边界;数据安全、合规、成本,随时可以卡你。于是:每个团队内部都能画出一条“还挺漂亮”的小闭环;拼在一起,从系统角度看,就是一堆多边形战士。 四、我自己在做的一套数据闭环实践上面说的是行业横截面,下面讲讲我自己这几年在做的一整套实践。不敢说“完美闭环”,但我自认为无论是理念还是落地程度,在国内自动驾驶里算比较激进的那一拨:我们是真把“数据当产品、指标当第一公民”来设计的。整体思路可以概括成一句话: 从“体感指标”出发,用 Trigger 把世界离散成 token,再用 LLM 做分类和路由,最后用统一代码把“发现”和“验证”串起来。1. 从“体感指标”出发:先把真实世界的“痛”量化出来我们做的是物流无人车,乘客不在车里,但客户和路人是有“体感”的:急刹、急转、蛇形、频繁停、莫名其妙慢,都会投诉。所以我们从数据上传设计的第一天起,就把一批绝对真实、用户有感的体感指标当作“第一公民”:急刹车次数(按不同等级划分严重度);接管次数(包括现场接管、远程接管、异常切人工);大幅转向、频繁修正方向;一些“体验上明显不对”的行为(比如场景不复杂却极度保守)。要求很简单也很残酷: 所有的接管、所有的急刹,必须 100% 被记录下来。不靠人工挑“看起来像问题”的,而是完整如实记录现象。在云端,这些体感行为会沉淀成类似:每万公里急刹车率(按不同等级分桶);不同道路类型 / 场景下的接管率;不同版本 / 不同区域的体感指标对比。没有这一层客观、全面的统计,后面讲什么闭环,基本都是 PPT。同时,我们也彻底放弃那套“拷盘式”数据上传方式,而是做得更像互联网埋点:不是把原始传感器数据一股脑上传;而是按事件上报:事件发生时间;当前驾驶模式(自动 / 远程 / 人工);若干关键环境信息:道路类型(高速 / 城快 / 主干 / 支路 / 园区路 / 场地);周围障碍物的数量级;是否处于路口 / 汇入 / 会车等关键场景。这样做的目的是:把“真实世界发生了什么”先说清楚,至于原因之后再慢慢分析。2. 车端 Trigger:高召回 + 极低开销的 micro log / mini log 机制我们的车上只有一颗 Orin X,要跑完整套 L4 算法,算力压榨得非常狠,所以车端有几个硬约束:Trigger 必须实时,但极其轻量;优先保证高召回,而不是一开始就追求高精度——宁可多报,不能漏报。车端一旦发生:接管;急刹车;大幅转向;或者其他体感明显不好的动作;就由一个高召回 Trigger,将前后若干秒的数据打包成一段micro log,加入上传队列。micro log 是一段很小的“问题线索”日志切片:带上关键状态、姿态、部分中间结果;体积很小,但足够做第一轮判断。micro log 上传到云端之后,还会再过一遍云端规则 / 模型管线:用更复杂的规则判断“这是不是一个真正意义上的急刹车 / 异常事件”;比如要求连续若干帧减速度超过阈值、持续时间达标、场景符合要求等。通过这一步,我们从“高召回的疑似事件”,筛出客观可信的指标事件。被认定为严重急刹车等一级指标的事件,会触发下一步: 给这一小段时间下发更大粒度数据的上传任务(mini log)。mini log 里会包含:更多中间结果(比如感知/预测/规划的细致输出);一小段压缩后的视频(十几秒,几 MB 量级),人能看清,又不会压垮带宽和存储。3. 按团队定制“拉更细数据”:解决问题而不是“只记 KPI”mini log 到了云端,还要解决一个关键问题: “这个问题具体应该扔给哪个团队?扔过去之后,他们到底需要什么数据?”我们先用一拨人工问题分发团队做初分:看 mini log + 短视频,大概分一下:感知 / 规控 / 地图 / 硬件 / 其他;人工分发结果本身,会被记录下来,用于给后面的 LLM 分类做训练数据。一个重要的设计是: 不是简单地给各团队“记 KPI”,而是根据分发结果,再给各团队定制上传他们真正需要的数据。典型比如:分到规控团队:再下发任务,让车上传规划轨迹、约束、代价函数等更细的中间结果;分到感知团队:下发任务拉原始传感器数据,或者更高分辨率/码率的视频,用于重放和训练;分到硬件 / 底盘团队:多拉完整的 CAN 报文、电源状态、温度、电机、传感器健康状态等。也就是说: 第一层触发只上传非常轻量的“问题线索”,确认这个线索值钱之后,再有选择地拉重数据上来,避免一开始就“云端无限吞吐原始数据”的浪费。4. 代码级统一:车端挖掘 / 云端挖掘 / 仿真验证用“同一段代码”这一点是我个人非常看重、也觉得很多团队没做到的: 我们把车端数据挖掘、云端历史数据挖掘、仿真验证评价做到了Trigger 逻辑代码级统一。什么意思?定义“什么叫一个问题”的那段逻辑(Trigger),既可以在车上实时跑,也可以在云上跑全量历史数据;同一段 Trigger 逻辑,也可以直接在仿真 / 重放的验证集上跑,用来评估新版本是否改善了这个问题。好处很直接:一套规则,从“线上发现问题”到“仿真里验证问题是否被修复”,完整走一圈;中间没有“语义断层”和“实现偏差”;真正做到: 同一段代码定义的问题 → 挖训练 / 验证数据 → 改算法 →再用同一段代码去验证“这个问题在线上和仿真里是不是都变好了”。在我看来,这一层才能称得上是真正的“从发现到验证”的闭环。很多团队只是在“数据采集”和“模型训练”之间画了一条线,就说完成数据闭环,其实差了这一大块。五、问题自动分发:把 Trigger 体系当成领域专用 tokenizer + classifier再往下一层,就是怎么把“问题线索”自动、可靠地分发到对应团队。我们做了一套比较“学术味”的设计,本质上是: 在多模态时序日志上,构建一个领域专用 tokenizer + classifier 的两阶段架构:前半段是特征工程,后半段是时序分类。1. Trigger = 领域专用的时序 tokenizer / 特征工程线上所有的数据流(传感器、状态机、控制指令、报文……),都会被各种 Trigger 扫一遍:每个 Trigger 都可以看作一个领域专用 tokenizer:在原始连续时序信号上,识别出某类“事件片段”;把它编码成一个离散 token:发生时间 + 事件类型 + 若干关键属性。这本质上就是特征工程:把“车速、加速度、障碍物尺寸、预测轨迹、控制指令”等底层数值,映射成“障碍物尺寸突变”“预测线跳变”“因某障碍物急刹车”这样的高层语义事件。 最终得到的是一串多模态时序事件序列,可以类比成: 从波形到音素 / subword 的过程 —— 先切分,后建模。2. 文本化:把这些 token 对齐到 LLM 的词表空间为了让通用大模型(LLM)能直接利用这些结构化事件,我们会把上述时序 token 再做一次文本化映射:把某段 micro/mini log 对应的 Trigger 序列,转写成一段 LLM 易于理解的“事件时间线”;比如: 第 3 秒:前方某障碍物的感知尺寸出现明显跳变,疑似距离估计不稳定;第 5 秒:同一障碍物的预测轨迹发生明显跳动;第 10 秒:车辆因为该障碍物触发了紧急制动事件。从模型视角看,这一步就是把我们自定义的 token 序列,投射到通用 LLM 的词表空间里,完成一次语义对齐。3. LLM = 时序事件序列 classifier在这个表示之上,我们把 LLM 当成一个时序事件序列的 classifier 来用:输入:一段“车辆从正常驾驶到急刹的文本时间线”;输出:对这次事件的主导原因归因(感知估计波动 / 预测不稳定 / 规划博弈失败 / 控制执行异常 / 底盘异常……);建议的责任域 / 团队路由(感知 / 规控 / 地图 / 硬件 / 其他)。用机器学习的话说,就是很标准的: feature engineering(Trigger + 文本化) → sequence classification(LLM)的流水线。Trigger 把原始高维、多模态、长时序信号压成“抽象 token 序列”,LLM 在这串 token 上建模时序依赖,做判别。4. 用真实“改派行为”做弱监督,形成 online 学习闭环更关键的是,我们不是拍脑袋觉得“分类应该挺准”,而是用真实的研发“改派行为”做弱监督标签,形成一个在线学习闭环:所有自动分发出去的问题,都会挂在统一的问题管理系统;我们只统计研发真实有回复的问题:如果研发回复时,并没有修改自动分发的团队 / 子模块 → 记为一次命中;如果研发回复时,把问题从“感知问题”改成“规控问题” → 记为一个 bad case。所有 bad case 会自动回流到 LLM 的分类知识库,用来更新分类边界。从 ML 视角看,就是: 用研发“改派”作为弱监督标签,在真实线上分布下做 continual learning,让 classifier 在真实业务分布下越用越准。六、Trigger 框架统一:Python + 大模型,让“写规则”变成大众技能前面说了,我们做到了“车端挖掘 / 云端挖掘 / 仿真验证用一套 Trigger 代码”。这里补充一个实现细节,也是我非常在意的一点: 所有 Trigger 逻辑统一用纯 Python 实现,并且跨平台可跑。为什么这么做?因为这直接决定:Trigger 上手门槛有多高;有多少非算法的同学(测试、运营、QA)也能参与写规则;有多少经验能从“嘴上说说”变成“代码”。我们做了几件事:1. 统一 Trigger 框架与接口不管跑在车端、云端历史数据挖掘,还是仿真评价,写 Trigger 面对的是同一套 Python 接口和运行模型;只要会一点 Python,测试 / 数据 / 运营同学都能写自己的“问题触发器”。2. 写好大模型“看得懂”的文档和示例给 Trigger 框架写了结构化、示例丰富的文档,让 LLM 能理解“Trigger 怎么写、输入输出是什么”;然后做一个小工具:研发 / 测试只需要用自然语言描述“想监控什么现象”;LLM 根据文档 + 示例,生成一段可跑的 Trigger 代码,人再微调。3. 更多、更细的 Trigger → 更“密”的标签当写 Trigger 不再是某几个资深算法的特权,而是: “懂业务 + 一点 Python + LLM 辅助”就能上手自然结果就是:Trigger 的数量和覆盖度急剧增加;每一帧数据上被打的标签越来越多维度(体感行为、场景属性、算法中间状态……);这反过来进一步提升:LLM 做问题分类 / 根因分析的输入质量;自动数据挖掘和构建训练 / 仿真数据集的效率。本质上,我们是用“Python Trigger 框架 + LLM”,把过去散落在脑子和会议里的经验,逐步固化成一个可协同维护、可演进的“规则代码库”,并直接挂在数据闭环的主链路上。4. 量产环境中的解耦:挖数 Trigger 当“配置”,脚本跑在车端沙箱里现实里还有一个非常关键、但容易被忽略的工程问题: 量产环境的版本更新是非常慢的同一时间路上可能跑着一堆不同版本,但数据挖掘的需求却是高度实时、强时效性的。举个特别常见的例子:某个城市突然下大雪,就这几天;你必须在有限的时间窗口里,把雪天的数据赶紧挖上来;不可能等一个“带新 Trigger 的版本”完整上线全网。为了解决这个矛盾,我们在设计里把“数据挖掘 Trigger”和“线上算法版本”彻底解耦:1. 挖数 Trigger 在车端更像是规则标签的组合,是“配置”而不是固化在主代码里;算法同学如果有新增的挖掘需求,不需要等主版本发版;云端可以下发一份“挖掘配置”(哪类 trigger、什么场景、什么条件组合),车辆收到后按配置执行挖掘逻辑。2. 在车辆行驶过程中,可以下发挖数脚本,这些脚本跑在车端沙箱环境中,由于性能限制,我们只在车辆不再执行自动驾驶任务的时候执行脚本,沙箱环境与正式线上算法解耦,不会影响主流程安全和实时性;允许我们针对某一段时间 / 某一类场景,快速上线一段挖掘逻辑,比如“只在雪天 + 城市主干路 + 车速 30km/h 以下时挖某类数据”。3. 挖数行为在云端可控:不是“开了就忘”,而是动态启停。在量产环境中,数据挖掘绝对不可能无限制,我们会在云端对挖掘策略做动态控制:一旦某个挖掘任务的数据量“够了”(覆盖了必要的场景和分布),云端会自动下发关闭 / 降采样的指令;这样可以避免:大量重复、无意义的数据;不必要的带宽、存储成本浪费。整体来看,这一套机制保证了:1)挖数能力不跟随主版本节奏慢吞吞走,可以相对灵活地应对突发场景(例如极端天气);2)同时又不破坏量产环境的稳定性,安全、实时的主算法和“更激进的挖数逻辑”严格隔离;3)挖数本身也在闭环:数据够了就自动收手,不做无意义堆量。七、区分“世界标签”和“算法标签”,以及向量检索的正确用法有了这么多标签,还有一个经常被忽略但非常重要的点:要把“客观物理世界的标签”和“算法中间结果标签”严格区分。1. 世界标签 vs 算法标签:两条不同的轴我们体系里维护两类标签:第一类:客观物理世界 / 场景标签(world-level)不依赖当前算法好坏,尽量接近“世界本身”:天气:晴 / 阴 / 雨 / 雾 / 夜间等;场景:高速 / 城市快速 / 主干 / 支路 / 园区 / 停车场;道路结构:有无遮挡路口 / 十字 / T 字 / 环岛 / 无路口;交通参与者:行人、非机动车、机动车的大致数量区间;车速、流量、车道数等。用于支撑更精细的筛选和分布分析,比如:“只看雨天、城市支路、车速 <30 km/h 的急刹车”;“只看有弱势交通参与者、且在路口附近的接管”。第二类:算法中间结果 / 表现标签(model-level) 强依赖算法实现:感知的检测框是否抖、尺寸是否异常变化;预测轨迹是否短时间大幅跳变;规划是否频繁重规划、是否在安全约束边缘抖动;控制是否出现“油门刹车来回切”的不稳定模式。更适合作为归因与调参的特征,而不是描述世界本身。这两类如果不分,就容易变成: 你以为在看“现实世界的难度分布”,实际上是在看“当前算法在哪些地方表现得更差”。2. “全靠向量检索”的伪闭环:为什么不适合做粗筛还有一个常见误区: “把原始数据丢给一个模型做 embedding,再用以图搜图 / 向量最近邻检索,就能搞定数据挖掘。”这类方法当然有用,但绝对不是主力入口,尤其面对海量存量数据时问题很大:未筛选的全量数据做向量检索:召回太大、成本太高;embedding 语义受训练分布影响很大,“看起来相似其实不相干”的情况很多;你真正想要的长尾场景很容易被淹没。更合理的姿势是:向量检索做精筛,不做粗筛。我们的做法:先用结构化标签规则,把 80%–90% 的无效数据筛掉比如想挖“老奶奶过马路”的场景,即便感知里没有“老奶奶”这个类别,也可以先用规则过滤一遍:必须在路口附近;车辆有明显减速甚至短暂停车;周围存在近距离行人目标。先把高速、畅通路段全扔掉,再往下看。在规则过滤后的子集上,用向量检索补做语义级细筛此时数据量已大幅缩小;模型可以在这个子集中进一步区分:老年人 vs 年轻人、独自 vs 有人陪同、慢速穿越 vs 停顿再走等;整体效率更高,算力浪费更少。总结一句: 向量检索是精细手术刀,不是砍树的斧子。对存量数据,一定要先靠结构化标签缩小空间,再让 embedding 去“挑刺”。八、生成式 / 仿真数据:用得上,但不能拿来“自嗨”最后讲讲最近很火的“生成式数据 / 仿真数据”,以及它在这套体系里的位置。我们团队也有比较成熟的仿真数据生产能力(包括基于高斯表征的场景生成等),但内部有个共识:生成式数据是用来补长尾训练短板的手段, 不是用来替代真实评测的万灵药。1. 生成数据主要用在“现实里很难凑齐”的长尾场景在训练层面,我们重点把生成式数据投到:现实中很难大量遇到、但又很关键的场景,比如: 路上的锥桶、临时围挡; 路面坑洼、塌陷、突出结构; 某些复合稀有工况。目的很简单:扩大模型在这些长尾 case 上的“见世面”; 给模型一个“这类东西可能出现”的先验; 在真实数据不够丰富时,把召回先拉起来一点。但最终用于评测和放行的评测集,我们仍然坚持只用真实数据。 因为你永远无法证明自己“完全模拟了真实世界”,只能让真实世界来兜底。2. 只看“召回涨了”是不够的:误检的副作用常被忽视以感知为例,生成式数据拉召回,很容易引入另一个风险:在已有评测集上,召回率确实能看到在涨; 但在未知分布 / 新场景里,误检可能在悄悄恶化。更麻烦的是,现实流程里:增量标注几乎都优先关注漏检(FN); 误检(FP)很难在评测集中完全覆盖: 你不可能预先知道模型将来会“哪里莫名其妙多出框”,也就无法在所有潜在位置都画一遍真值。于是就容易出现一种错觉:评测集上召回涨了,FP 指标表面看着也还好, 大家都很开心, 但真实线上有些区域模型已经开始“到处乱看东西”。3. 我们的做法:版本间逐帧全量 diff,不先争真值,先看差异模式我们在这块的策略是: 对两个版本,在同一批数据上的逐帧全量差分,系统性监控副作用。具体步骤:选一批有代表性的真实评测集;用版本 A 和版本 B 分别跑一遍,拿到两套感知结果;对结果做逐帧、逐目标的全量比对,标记所有“不一致”的地方。一个关键点是: 只要两个版本在某一帧某位置给出的结果不一样,那么就一定是“有一个错,或者两个都错”。至于谁对谁错,我们可以先不急着判断。在“不争真值”的前提下,我们先做的是差异模式分析:给差异打维度标签:距离段(0–20m、20–40m……);方位(前 / 侧 / 后);类别维度:是多了目标,还是少了目标;对这些维度做统计和排序:看哪些距离段 / 类别 / 方位,在新版本下“差异特别多”。接着再结合人工抽查、可视化检查:哪些差异是“召回真正变好”;哪些是“误检开始泛滥”。如果在某些维度新版本的误检明显爆炸,那么在我们这边,即便研发同学拿着召回曲线说“涨了很多”, QA 这边这关也是不会放行的。工程实践里,“涨多少”不是唯一指标,“涨得干不干净”同样重要。尾声:从 Data-Driven 到 Bug-Driven,再到真正的数据驱动写了这么多“数据闭环 / 数据驱动”,如果让我给现在这套东西起一个更诚实的名字,我反而会叫它: Bug-Driven 开发体系。听上去一点也不“高大上”,甚至有点土,但这几年实践下来,真正在一线推动车辆迭代往前走的,往往就是一个个具体的 bug:某个路口总是左转犹豫;某段路总是在鬼畜急刹;某种障碍物在某种光照下经常漏检 / 误检。我们搭建的所有数据体系,本质上就是: 更快、更准、更系统地发现这些 bug,量化这些 bug,跟踪这些 bug 的出现与消失。如果说现在这套体系还有什么让我不敢说“已经跑顺了”的,那卡口已经不在“发现问题”这一侧,而是在: “谁来解决问题、怎么解决问题”这一侧。哪怕我能:把问题发现得再多、分类再精细、优先级排得再合理,真正能“动手解决”的,始终是团队里那几拨研发同学。人的带宽是刚性的,长尾问题也不是一朝一夕能搞定的:对感知来说,解决一个问题往往还是:采集数据 → 标注真值 → 训练 → 回归 → 上线;标注这件事尽管业界都在宣传什么自动标注率,但从标注公司生意的景气程度就能看出来:人工标注依然是非常硬的一环。仿真验证这边,也绕不开那句老话: 仿真结果到底能不能代表真实世界?你说完全能,自己都不会信;你说完全不能,又很难支撑大规模自动化验证。这些都是当下整条数据闭环链路里普遍存在的问题:问题可以被越来越精准地“抬上手术台”,但做手术的人、手术刀的效率、术后评估体系,还远远没有那么优雅。好消息是,最近这两年有两个方向,我觉得是值得乐观一点的:1. 端到端 / 模仿学习类架构的兴起在端到端视角下,“标签”更多直接对齐人类驾驶员的行为表现:中间结果的对错、模块边界的划分没那么重要;可以更直接地用“人类怎么开”去约束整体行为。这在某种程度上绕开了很多“中间真值极难标”的问题,也给“真值标注”找到了一个更自然的出口。闭环仿真 / 世界模型的快速发展大家频繁讨论的世界模型,本质上就是想把: 在仿真里充分暴露问题、充分迭代把这一环做得更接近真实世界。一些头部玩家公开说他们有非常大的工程投入砸在最后的验证环节上,本质也是在强调:如果闭环仿真这一环不做扎实,前面的“数据闭环”很难给真正的安全感。我自己的判断是: 如果未来我们能够真正降低解决一个 bug 的边际成本,让端到端 / 世界模型类的方法在验证和安全约束上更可控,再叠加这几年在 Trigger 体系、标签体系、自动分类、代码统一这些工程实践上的积累,那么大家这些年挂在嘴边的“Data-Driven”,才有可能从口号,变成一套能持续跑、能算账、能规模化复 制的基础设施。到那时候,“数据闭环”大概就不会再被拿来当卖点讲,就像今天没人再把 CI/CD 当成卖点一样——没有,大家才会觉得奇怪。来源:车路漫漫

未登录
还没有评论
课程
培训
服务
行家
VIP会员 学习计划 福利任务
下载APP
联系我们
帮助与反馈