无人驾驶的指标以及如何平衡短期与长期方案？

毫不夸张的说，这个问题算是业界一个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，他很可能没过几个月就开始否认公司文化，考虑离职了。

另外要注意，不是所有的漏洞都值得修复。工程师常常犯的错误就是看到漏洞就想修复。其实，一些无关紧要的漏洞完全可以置之不理。不要因为小漏洞而耽误了更重要的项目。团队的管理者需要制定一套体系，评估什么样的漏洞可以暂时忽略掉。