一个音频算法工程师的项目失败后的反思和总结

  理论和实践

  领导把公司的一个重要研究项目(命名为顺耳风)交到了我手上--关键词唤醒系统,也就是当下最热门的热词唤醒。为了尽快的给客户演示,留给我的时间大约有三个月,刚开始我估算了一下,算法研究一个月,仿真一个月,后面调试差不多再有一个月基本就可以了。音频算法我这块以前研究过不少,有这块的相关经验。按道理是可以按时交付的。

  就这样,项目在我的调研中就开始了,开始的时候,调研了不少业内的开源的热词唤醒系统,再结合公司的平台(公司是跑的小系统,资源比较紧张,ram空间200k,主频只有120M左右)。所以,一定要选择那种资源占用少,效率高的算法。经过两周调研,我选中了一块比较小的开源热词唤醒系统,该算法算是仿真环境下最适合小系统上使用的了。接下来,就要测试一下该系统唤醒率怎么样了,由于该系统只要自带的特殊格式的音频文件才能测试,用该系统自带的音频格式测试,效果非常的好。识别率基本是100%。这样的效果让我对该算法充满了信心。慢慢都是正能量。

  接下来就需要把算法在pc机上进行仿真,这块的工作主要有把算法的底层改动能适应公司硬件平台需求,接口改动能够读取主流的音频格式。能否在pc机上仿真算法的效果。其实,这中间的工作量还挺大,足足花了我三周的时间去完成。等到完成了基本的仿真,确认基本效果ok之后,就开始了下一步的工作--把算法移植到芯片上。

  把算法移植到芯片上,这部分主要是接口的工作量比较大,是芯片的接口能够适配算法。这段时间花费了我三周的时间。等到基本移植完成之后,项目周期已经过去了三分之二。这时的我,有点着急了。破屋偏逢连阴雨,就在这快要结束的时刻,发现了几个比较严重的问题,一个是,针对热词唤醒,vad检测音频之后再启动特征提取,这时算法的效果就变差了。再者就是从麦克过来的音频有噪声,这样也会降低了识别率。这两个问题是非常的棘手。vad检测和算法的特征提取配合,这个需要反复的验证和调vad的参数和算法的流程,同时也需要在电脑上进行仿真,这样来回的仿真和单板的来回测试,花了差不多两周的时间,效果仍旧不是那么的好。不过,算是凑合着能演示吧,不管了,先把产品的demo做出来再说。另外一个麦克通路过来有噪声的问题,需要我拉着硬件的和数字的同事一起看。等到我和他们一起把这个问题解决时,产品周期已经到了。从我简单的测试效果来看,基本能用了吧。于是,就给老大说,已经完成了。为了快速的出去演示,老板也没有去仔细的测试,直接把东西拿到客户那边演示了。等到听到客户的反馈时,我那么侥幸的心情瞬间崩塌,产品远远没有达到要求。三个月的努力瞬间化为悔恨和懊恼,到底哪儿出了问题?

  哪儿出现了问题?

  该项目的失败,让我一直在问题自己这样一个问题,到底我在这里错在哪儿?从一个产品经理的角度来讲,我错在是时间估计太乐观,其实,后面和一个资深的算法工程师讨论过这个问题,他说的还是挺有一定有道理的。一个算法从理论到产品,一般要经过一年的时间去打磨,太快了会出事的。回顾一下自己的这个项目,就是后面的测试太少,客户的场景基本没有考虑的情况下,不出问题才怪呢。都怪我太匆忙。今后,这点一定要注意,项目评估时间的时候还是要留余量的。

  从一个软件开发人员的角度来考虑,最大的问题就是思维不够缜密,心存侥幸心里,对客户的的使用场景没有充分的去调研和测试。反复想一想,其实,这种事情不止一次发生在我身上了,自己没有经过测试充分的产品给测试人员,测试人员能会测试不出来问题吗?客户难道不会测试出来问题?做事情,千万不能心存侥幸,这个是血的教训啊。

  此岸和彼岸

  其实,每个翩翩少年,都藏着一颗用代码去改变世界的梦想,可是,当面临着现实的种种烦扰时,有太多的理由和困难让我们去放弃。在无数先贤人们构造的软件数字迷宫中,作为一个凡夫俗子的程序员更容易迷失方向,到底,怎么才能到达彼岸,哪儿又是彼岸呢?依稀还记得老子的一句话--图难于其易,为大于其细。天下难事必作于易,天下大事必作于细。当穿越软件的层层迷宫之后,我才有点幡然醒悟的觉决。算法的彼岸,就是客户的认同和满足,一切的产品,都应该以是否满足客户的需求去定义和开发。在这个此岸彼岸之间,就是这就是老子留给我的那句心决--难作于易,大作与细。

猜你喜欢

转载自www.cnblogs.com/dylancao/p/9901014.html