毫不夸张的说,这个问题算是业界一个million-dollarquestion。搞懂这个问题很难,即使搞懂了,也很难在团队实施。我在这里举几个例子,只能起到抛砖引玉的效果,具体还是要看各位读者团队的具体需求。
首先,一定要避开指标的误区。在书中2.7.4一节中我们提到,很多团队因为误用指标,导致团队研发方向发生偏移,迟迟无法交付。
比如,一些团队的指标与他们的适用场景(ODD)毫无关系,只是照搬美国车辆管理局规定的指标。
美国车辆管理局每年11月都会要求各个无人驾驶公司上交两份年度报告:驾驶里程数(mileage)以及人类安全驾驶员的介入次数(disengagements)。有了这两个数据,就会用里程除以介入次数,得到每次介入间隔的里程数。这个指标越高的公司就会被认为是无人驾驶技术开发最成熟的公司。
如此衡量无人驾驶开发进度虽然简单直接,但无疑有严重弊端。
首先,各个公司测试场景完全不同,所在城市也不同。有的只在高速路测试,有的在郊区街道测试,有的在拥堵的市中心测试,所以在相同的测试时间里,因为车速完全不同,路况不同,里程数就会有天壤之别。
何况,市中心的场景更为复杂,虽然车速和郊区相比慢很多,但市中心才是无人驾驶技术真正的战场。Cruise公司曾表示,在旧金山市区驾驶会遇到的困难场景是郊区驾驶的46倍。在高速路上,一个小时就可以轻松积累65英里。而在闹市区,一个小时可能只能积累5英里。如果只是为了炫耀里程数,无人驾驶公司会可以选择一些好开的高速路。而这样做不利于无人车学习新场景、新技能。
团队的管理者但凡用点心思,也会为团队另外制定一套指标。美国车辆管理局规定的指标其实只不过是给外行人看的,内行还是要看深层的指标。
因为缺少行业规范,各个团队在此会出现重大分歧。但基本可以分为两个流派。
一个流派属于漏洞派,即bug-driven,只看介入。如果没有漏洞,就假设无人驾驶已经趋于完美了。这样的团队不但会注重解决路上的介入,还会通过其他各种测试方法挖掘潜在的介入。
如果驾驶开始变得过于顺利,介入变得太少了,就适当扩张适用场景(ODD),引入适量更多的漏洞。经过团队一段时间的努力,解决部分漏洞之后,再开始新一轮的ODD扩张,如此循环往复。直到ODD达到可以落地的预期效果。
在书中,我们举了几个指标的实例,比如计算临近触碰,将临近触碰也视为漏洞。
另外,我们可以将里程数分解为每辆车平均里程、每个城市的里程、驾驶时长。从而将各个指标细分,而不是单纯只看一个指标。
书中还提到利用“初次场景”(first-timescenario)来衡量驾驶技术的generalizability,即普遍适应性。这些都属于漏洞派的指标。
这一流派的工作流程简单直接,往往立竿见影,适合刚刚起步的团队。
然而,这样做的缺点也显而易见。因为团队只看重漏洞,而不去寻根溯源,所以团队每天都会被无穷无尽的漏洞纠缠,形成恶性循环。好的时候,遇到的漏洞少,团队能放松两天,而其他时候,漏洞会扎堆出现,导致团队十分被动。
另一个流派书中没有提到,即“过程派”。这一流派注重的是技术本身的质量与成熟程度,而不关注驾驶结果。
过程派的团队会衡量每一个组成部分的指标,而不注重端到端的结果。比如,识别公交车的精确率与召回率是否都在提升?什么情况下会受影响?无人车定位的速度是否在逐步提升?规划的路径偏离的程度有多大?仿真与路测之间还有多少差距?
这一流派在行业内是少数,适合技术相对成熟的团队,或是不注重做demo、不急着筹钱的团队。
这一流派的指标的优点是,bug可以真正从根本上解决,技术的研发往往为长远目标考虑,禁得起时间的考验,团队不至于陷于被动的境地。
而这一流派的缺点是,由于过于注重底层技术的质量,导致最终的驾驶体验得不到快速提升,研发周期往往过于漫长。
其实,比较理想的方式是将两个流派结合,让团队内不同级别、不同职能的人去负责不同的流派。
比如,可以让工程师们专心提升底层技术的质量,让公司高层关注端到端的漏洞。如果两个流派发生分歧,就要权衡团队各方面的利弊,做出共同的决策。这便引出我们下一个来自读者的问题。
问题2:长期方案与短期方案如何平衡?
这个问题大概做软件开发的人会经常遇到,即,针对一个棘手的问题,有一个long-term解决方案,可以从根本上解决问题,但往往要花上好几个月的时间才能做好。为了解燃眉之急,我们是否要花一个星期的时间先做一个hack,把问题盖住再说?
无人驾驶的研发更是如此。每开发一个新的模型都需要几个月的时间,每增加一个新的驾驶技能都需要几个月时间的精心调试。因此,毫不夸张地讲,长期方案或短期方案这一问题几乎每天都会遇到。如果拿不出一套解决问题的体系,真的会患上选择困难症,团队内只剩下吵架。
其实,决策方案无外乎要包含以下几点。记住了这套方案,大部分的决策问题都可以迎刃而解。
首先,一定要回归团队在当下的首要目标。看看你的决策是否顺应团队的首要目标。有时候,虽然长期方案看上去光鲜亮丽,但并不是团队当下最重要的目标。
比如,最近无人车在某个左转弯经常需要介入。这个左转弯的问题虽然很值得探索,但是团队当下的首要目标是攻克右转弯。如果有必要,可以考虑采取短期方案先将左转弯的问题盖住,等右转弯做好之后再回头来做左转弯。
其次,要考虑成本。这里的成本不只是指研发所需要的成本,而是指如果给某方案投入成本,是否会对团队的其他目标造成负面影响。比如,完成一个短期方案需要一个团队几个小时的时间,看上去算不上艰巨的任务,但这个团队已经有了非常重要的项目,这时不应该用这些“噪音”去影响他们的进度。
最后,还要考虑“人”的因素。规定都是人制定的,也是由人来执行的。很多主观因素也必须要考虑。比如,某工程师的行事风格向来谨小慎微,如果要求他做一个hack,来解决短期问题,那么他多半是不会同意的。如果经常命令这位工程师去做hack,他很可能没过几个月就开始否认公司文化,考虑离职了。
另外要注意,不是所有的漏洞都值得修复。工程师常常犯的错误就是看到漏洞就想修复。其实,一些无关紧要的漏洞完全可以置之不理。不要因为小漏洞而耽误了更重要的项目。团队的管理者需要制定一套体系,评估什么样的漏洞可以暂时忽略掉。
全部0条评论
快来发表一下你的评论吧 !