主页 > 航空安全 >聊聊我在Google无人车研究组的那些事 >
聊聊我在Google无人车研究组的那些事
聊聊我在Google无人车研究组的那些事

到 Google 无人车组全职工作已经有四个月了。写一下感想。

鉴于专案的高度机密性,很多话不能说,我唯一能透露的,就是两条:同事们都是强者,然后都非常努力。老闆不怎幺主动管,但大家都明白如果事情做不完就得加班,因为一个一个小发布的最后期限摆在那里。节奏很快,不像是在大公司里工作,反倒更像是在一个新创团队里忙碌。

这四个月感觉下来,Google[x] 实验室有几个很有趣的特点。其一是软硬体结合极其紧密,这一点从已有的报导里可以看出,不论是无人车 ,眼镜还是最近公布的气球无线网络及能测血糖的隐形眼镜 ,都是软硬结合的产品。这直接导致的结果,就是我们每天面对的问题和之前在学术圈时思考的完全不同。

在学术圈,问题的已知条件和数据集都是给定的,我们要做的就是像解数学题一样,钻进去找到更好的解法,并在已知的数据集上和前人对比证明其有效性。但在 Google[x] 则完全不同,大专案摆在这里,但已知条件、解决方案、使用何种硬体、如何分配资源,都是不确定的;唯一确定的,是要以最快的方式和最小的成本把它实现出来——让一辆车能安全地自行其道,同时生产成本又最少。

在这样的特定背景下,碰到一个难题,首先想的不是如何把它不计成本地解出来,而是问自己有没有必要解它,能不能绕开它而实现目标?事实证明,在这样高自由度的空间里寻找一个特定的解决方案,几乎总是能绕过学术界的难题,找到简单易行的实用方法。这就像要发明能在道路上移动的机器人,不是绞尽脑汁去研究人类两足的肌理,而是用容易控制又廉价的轮子代替;要设计飞机,不去模仿鸟类形态优美却机理複杂的扑翼,而是使用固定机翼加喷气动力。

其二是几乎没有专职的研究职位。所有人既是研究员 ,又是软体工程师 。基本上每个人负责一个具体的方向,对这个方向自主地分析现存的问题,并不断通过和同事讨论提出新方案,最后评估方案的效果。就算是组里的老闆(Manager),甚至是老闆的老闆,也要写程式查错误完成具体工作,唯一的不同点,是他们对系统有更整体的理解,遇到问题能帮忙找到下属找不到的角度。碰到许多任务同时需要完成的时候,能分清主次,弃卒保车,确保整个组的大方向正确。

对于从来没有碰到过的新问题,思考新思路和写程式开发是同时进行的,C++ 程式写完就直接上产品去测试看效果如何,不行就分析研究再换一种,如此快速迭代直到找到好方案为止,如果一两周里找不到好方案,那就认为这个问题是困难的,于是就要退一步思考,想办法绕开它。

因为这个原因,诸如「写程式和做研究的时间比例是多少」之类的问题就没有什幺意义,因为完全看需要解决的是什幺问题,写很多格式漂亮架构清晰的程式却不能解决问题没有意义,天马行空地思考不在实际数据上跑也没有意义,最重要的只是「解决问题」这四个字。

这种思路决定了研究风格是「具体问题具体分析」式的,有额外条件和额外资讯就尽量用上,不会花时间思考一般情况;「崇尚简单方案快速出结果」式的,而不会使用精巧複杂却不太直观的数学理论,也不会花几个月赌一个万能算法。这种研究方式的缺点显而易见,就是没有办法产生深远及本质的成果,但是既然目标是利用人类现有的技术,去完成一个举世瞩目的新系统和新产品,我想不出来有其它更好的推动方式了。

其三是组内资讯交流的极端重要性。学术界强调钻研问题,独立工

作和原创性成果;业界强调合作,共同解决问题。一个人,特别是刚进来的新人,对整个系统的组成没有深刻理解,也不去询问同事,老闆给一个问题就按自己的想法单干,结果发现三分之一工作和无人车目前急需解决的难点无关,三分之一工作已有人做出过类似工具,还有三分之一工作听起来很有道理,自成一说,但是在实际数据上一跑效果很差。这些情况

是完全可能的。按学术界的思路,这些工作都可以成为不同风格的学术文章,但在我们这里,全都是没有用的。

而充分交流讨论就能避免这类情况。有越多来自别人的资讯,就越能明确目标直入主题;越知道系统的优劣和目前的可用工具,就越能藉风使力,提高效率。有时候跨组间不经意的一两句对话,少则抵得上几小时或者几天的辛勤劳作,多则改变整个组的行进方向。无人车组里中国人非常非常少,因此英语的地位相应提高,实在是需要在业余时间多加训练才好。

对于这样一个开创性专案,虽然已经取得了重要的进展,但还是有很多棘手的具体问题需要解决,每一个细节都决定成败。并且,越接近最终目标就越为艰难,有时候为了有百分之一的效果提升,是不惜从头再来,将原来的工作全部推翻的。所以说这个专案最后是否成功,还要看全体同事的聪明才智和勤奋努力,及一点点捉摸不定的运气。

希望运气

在我们这边。

田渊栋 2014 年 1 月 23 日

上一篇: 下一篇:
相似文章