一名算法工程師項目失敗后的感悟

領導把公司的一個重要研究項目（命名為順耳風）交到了我手上－－關鍵詞喚醒系統(tǒng)，也就是當下最熱門的熱詞喚醒。為了盡快的給客戶演示，留給我的時間大約有三個月，剛開始我估算了一下，算法研究一個月，仿真一個月，后面調試差不多再有一個月基本就可以了。音頻算法我這塊以前研究過不少，有這塊的相關經(jīng)驗。按道理是可以按時交付的。

就這樣，項目在我的調研中就開始了，開始的時候，調研了不少業(yè)內的開源的熱詞喚醒系統(tǒng)，再結合公司的平臺（公司是跑的小系統(tǒng)，資源比較緊張，ram空間200k，主頻只有120M左右）。所以，一定要選擇那種資源占用少，效率高的算法。經(jīng)過兩周調研，我選中了一塊比較小的開源熱詞喚醒系統(tǒng)，該算法算是仿真環(huán)境下最適合小系統(tǒng)上使用的了。接下來，就要測試一下該系統(tǒng)喚醒率怎么樣了，由于該系統(tǒng)只要自帶的特殊格式的音頻文件才能測試，用該系統(tǒng)自帶的音頻格式測試，效果非常的好。識別率基本是100%。這樣的效果讓我對該算法充滿了信心。慢慢都是正能量。

接下來就需要把算法在pc機上進行仿真，這塊的工作主要有把算法的底層改動能適應公司硬件平臺需求，接口改動能夠讀取主流的音頻格式。能否在pc機上仿真算法的效果。其實，這中間的工作量還挺大，足足花了我三周的時間去完成。等到完成了基本的仿真，確認基本效果ok之后，就開始了下一步的工作－－把算法移植到芯片上。

把算法移植到芯片上，這部分主要是接口的工作量比較大，是芯片的接口能夠適配算法。這段時間花費了我三周的時間。等到基本移植完成之后，項目周期已經(jīng)過去了三分之二。這時的我，有點著急了。破屋偏逢連陰雨，就在這快要結束的時刻，發(fā)現(xiàn)了幾個比較嚴重的問題，一個是，針對熱詞喚醒，vad檢測音頻之后再啟動特征提取，這時算法的效果就變差了。再者就是從麥克過來的音頻有噪聲，這樣也會降低了識別率。這兩個問題是非常的棘手。vad檢測和算法的特征提取配合，這個需要反復的驗證和調vad的參數(shù)和算法的流程，同時也需要在電腦上進行仿真，這樣來回的仿真和單板的來回測試，花了差不多兩周的時間，效果仍舊不是那么的好。不過，算是湊合著能演示吧，不管了，先把產品的demo做出來再說。另外一個麥克通路過來有噪聲的問題，需要我拉著硬件的和數(shù)字的同事一起看。等到我和他們一起把這個問題解決時，產品周期已經(jīng)到了。從我簡單的測試效果來看，基本能用了吧。于是，就給老大說，已經(jīng)完成了。為了快速的出去演示，老板也沒有去仔細的測試，直接把東西拿到客戶那邊演示了。等到聽到客戶的反饋時，我那么僥幸的心情瞬間崩塌，產品遠遠沒有達到要求。三個月的努力瞬間化為悔恨和懊惱，到底哪兒出了問題？

哪兒出現(xiàn)了問題？

該項目的失敗，讓我一直在問題自己這樣一個問題，到底我在這里錯在哪兒？從一個產品經(jīng)理的角度來講，我錯在是時間估計太樂觀，其實，后面和一個資深的算法工程師討論過這個問題，他說的還是挺有一定有道理的。一個算法從理論到產品，一般要經(jīng)過一年的時間去打磨，太快了會出事的。回顧一下自己的這個項目，就是后面的測試太少，客戶的場景基本沒有考慮的情況下，不出問題才怪呢。都怪我太匆忙。今后，這點一定要注意，項目評估時間的時候還是要留余量的。

從一個軟件開發(fā)人員的角度來考慮，最大的問題就是思維不夠縝密，心存僥幸心里，對客戶的的使用場景沒有充分的去調研和測試。反復想一想，其實，這種事情不止一次發(fā)生在我身上了，自己沒有經(jīng)過測試充分的產品給測試人員，測試人員能會測試不出來問題嗎？客戶難道不會測試出來問題？做事情，千萬不能心存僥幸，這個是血的教訓啊。

此岸和彼岸

其實，每個翩翩少年，都藏著一顆用代碼去改變世界的夢想，可是，當面臨著現(xiàn)實的種種煩擾時，有太多的理由和困難讓我們去放棄。在無數(shù)先賢人們構造的軟件數(shù)字迷宮中，作為一個凡夫俗子的程序員更容易迷失方向，到底，怎么才能到達彼岸，哪兒又是彼岸呢？依稀還記得老子的一句話－－圖難于其易，為大于其細。天下難事必作于易，天下大事必作于細。當穿越軟件的層層迷宮之后，我才有點幡然醒悟的覺決。算法的彼岸，就是客戶的認同和滿足，一切的產品，都應該以是否滿足客戶的需求去定義和開發(fā)。在這個此岸彼岸之間，就是這就是老子留給我的那句心決－－難作于易，大作與細。