1. 程式人生 > >一個音頻算法工程師的項目失敗後的反思和總結

一個音頻算法工程師的項目失敗後的反思和總結

適配 過去 來看 資源 天下難事 夢想 必作於易 失敗 軟件開發

  理論和實踐

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

  就這樣,項目在我的調研中就開始了,開始的時候,調研了不少業內的開源的熱詞喚醒系統,再結合公司的平臺(公司是跑的小系統,資源比較緊張,ram空間200k,主頻只有120M左右)。所以,一定要選擇那種資源占用少,效率高的算法。經過兩周調研,我選中了一塊比較小的開源熱詞喚醒系統,該算法算是仿真環境下最適合小系統上使用的了。接下來,就要測試一下該系統喚醒率怎麽樣了,由於該系統只要自帶的特殊格式的音頻文件才能測試,用該系統自帶的音頻格式測試,效果非常的好。識別率基本

是100%。這樣的效果讓我對該算法充滿了信心。慢慢都是正能量。

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

  把算法移植到芯片上,這部分主要是接口的工作量比較大,是芯片的接口能夠適配算法。這段時間花費了我三周的時間。等到基本移植完成之後,項目周期已經過去了三分之二。這時的我,有點著急了。破屋偏逢連陰雨,就在這快要結束的時刻,發現了幾個比較嚴重的問題,一個是,針對熱詞喚醒,vad檢測音頻之後再啟動特征提取,這時算法的效果就變差了。再者就是從麥克過來的音頻有噪聲,這樣也會降低了識別率。這兩個問題是非常的棘手。vad檢測和算法的特征提取配合,這個需要反復的驗證和調vad

的參數和算法的流程,同時也需要在電腦上進行仿真,這樣來回的仿真和單板的來回測試,花了差不多兩周的時間,效果仍舊不是那麽的好。不過,算是湊合著能演示吧,不管了,先把產品的demo做出來再說。另外一個麥克通路過來有噪聲的問題,需要我拉著硬件的和數字的同事一起看。等到我和他們一起把這個問題解決時,產品周期已經到了。從我簡單的測試效果來看,基本能用了吧。於是,就給老大說,已經完成了。為了快速的出去演示,老板也沒有去仔細的測試,直接把東西拿到客戶那邊演示了。等到聽到客戶的反饋時,我那麽僥幸的心情瞬間崩塌,產品遠遠沒有達到要求。三個月的努力瞬間化為悔恨和懊惱,到底哪兒出了問題?

  哪兒出現了問題?

  該項目的失敗,讓我一直在問題自己這樣一個問題,到底我在這裏錯在哪兒?從一個產品經理的角度來講,我錯在是時間估計太樂觀,其實,後面和一個資深的算法工程師討論過這個問題,他說的還是挺有一定有道理的。一個算法從理論到產品,一般要經

過一年的時間去打磨,太快了會出事的。回顧一下自己的這個項目,就是後面的測試太少,客戶的場景基本沒有考慮的情況下,不出問題才怪呢。都怪我太匆忙。今後,這點一定要註意,項目評估時間的時候還是要留余量的。

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

  此岸和彼岸

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

一個音頻算法工程師的項目失敗後的反思和總結