人工智慧產品經理系列（八）工程化實踐能力

AI工程化的概念實際上在中國沒太多人提及，而我通過調研大量文獻後發現產品經理更需要系統的理解和掌握AI工程化的流程和實踐能力，因為相比於技術，他們每天要學習各種國外頂級期刊的論文，要掌握最新的框架和語言，但產品經理需要的是積累工程化的經驗，並逐漸形成自己的一套「打法」，包括看待問題的視角、切入點。在數據少的時候如何做冷啟動訓練模型的經驗；通過混合部署和異構計算節省計算資源從而節省整個公司的成本；在做模型校驗尤其是離線學習、增量學習、在線學習時如何能快速找到指標進行評價和量化泛化效果，當某一個業務場景下的模型訓練好後是否可以考慮在其他場景中進行移植，儘管遷移學習（transfer learning）或者叫progressive (continual) learning仍然有一些實現上的困難，但至少也會為企業提升效率，節省開支。本篇文章從三個關鍵階段介紹一下我理解的AI工程化的系統思維框架，每個人理解的工程化以及在每個不同業務類型公司中工程化的流程一定是不同的，但至少你可以參考這樣的思維模式進行自己的修鍊。

需求定義的工程化

技術體系的構建離不開需求，而需求離不開行業理解和商業模式的價值觀導向，某些技術經理看到了國外最新的技術框架就想拿來用到自己的體系中，總是忽略ROI，甚至缺乏Vision，當然並不是所有的技術經理都這樣，只是出發點不同，看問題的視角不同，經歷不同而已。

產品經理需要關注行業，感興趣的可以參考我的系列文章第二篇《懂行業的產品經理才不會被AI淘汰》。比如做機器人的智能交互，涉及到了自然語言理解、交互語義理解、對話策略生成以及通過知識圖譜進行在不同的場景下進行意圖搜索等等。產品經理要對這些核心的關鍵業務需求進行定義，技術就可以有導向性的進行框架設計和技術調研,而且在描述需求的時候要回歸場景，場景描述的越詳細，越周全，技術才會找到最適合的方案去解決。例如在電商平台中，由於不同的人群，不同的行業關注的重心截然不同，產品經理要結合實際場景提出「千人千面」的需求，即針對不同人有不同的排序模型，因為個性化的特徵在不同場景中的權重是不同的。產品提出了這樣的需求，技術就會去找解決方案，比如可以通過向量化召回泛化能力、排序特徵、排序模型精準度等方面進行深度學習的優化和改良，並通過多場景的聯合優化最終實現產品設計的目標。其實，無論技術經理還是產品經理如果都可以站在需求本質以及行業視角看待問題，無論以任何手段和方式解決問題都會實現協同最終幫助產品走向成功的。

演算法實現的工程化

需求定義清楚了，接下來就需要演算法工程師發揮才智了，但是通常演算法能力的發揮需要強大的計算能力和底層系統架構的支撐，這涉及到了軟硬體的協同並進。

公司的產品總監有些時候也要對搭建類似的架構成本負責，至少要對數量級和搭建成本有理解，因為完善的實時計算平台、機器學習平台通常需要動輒千萬的GPU引擎投入，而且為了更快速的驗證演算法以及做模型訓練還需要構建深度學習訓練平台為了實現端到端的日誌治理、特徵提取、模型訓練和自動化服務部署等流程，產品人員要對以上流程至少有概念上的認知，這些流程也是工程化實踐的關鍵環節，要對人員投入、部署周期、以及關鍵節點的核心價值有深入的理解和預判，否則沒法跟演算法團隊達成一致並深入溝通。而這些投入都是需要精確的計算ROI的，例如採取GPU和CPU異構計算就是在某種程度上節省了公司的成本達到效率最高化。

以上說的這些工程化流程都是隨著公司業務的不斷擴大以及對演算法需求的提升循序漸進的，而演算法需求牽引著公司系統架構的不斷升級。例如從一開始的離線模型到在線模型再到深度學習模型，最終實現在線深度學習過程，都是伴隨著成本投入逐步提升的，產品經理要判斷不同時期的產品需求，而不是技術越先進越好。

量化及衡量標準的工程化

產品經理要通過量化定義以及衡量尺度的把控，實現聯合收益最大化,而不是此消彼長。在工程實踐中經常遇到某種場景，即通過某一個指標召回率的提升就判定某個演算法模型的成功與否，但同時因為缺乏全局化的考慮，形成了拆東牆補西牆的局面，現實的AI工程場景中類似的局面還有很多，即由於缺乏協同量化衡量標準，演算法對於產品的整體目標來說並沒有實質性的改變卻同時提升了成本投入，那麼這樣的結果就是需要產品經理來負責的，所以在產品定義階段、演算法測試、校驗階段就需要投入精力從多維度量化衡量標準。只有多維度衡量標準的提出，才會推動演算法團隊進行改良，例如在互聯網廣告、電商以及競技遊戲AI的領域中必須通過多智能體的強化學習才能實現雙向連通並達到效果最優。對於多智體協同感興趣的可以通過理解Lotka-Volterra模型作為切入點進一步學習。

微信公眾號：

特總侃AI：pmaihome

推薦閱讀：