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

　　理论和实践

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

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

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

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

　　哪儿出现了问题？

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

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

　　此岸和彼岸

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