三步法完成AI產品需求分析

筆者通過分析ToB影像類AI產品的需求，闡釋了自己的工作經驗所得。

筆者希望能和大家一起探討如何完成ToB影像類AI產品的需求分析，文中內容僅表示筆者在實際工作中的產品需求分析習慣，歡迎大家交流。

產品的需求分析算是產品經理的必修課，只有理解透需求，才能避免後期產品設計的出錯，對於ToB的AI影像類產品，筆者一般遵循以下的分析套路。

一、業務需求分析

如果不看市場分析，那麼業務需求分析應該是產品經理進入產品規劃的第一步。

尤其是ToB類的產品，只有摸透使用者的業務需求，做出來的產品才能更加貼合使用者，讓使用者欲罷不能地買單，這一塊分析筆者一般從以下幾個核心點去收集使用者資料。

1. 業務需求背景

首先，需要弄清楚當前需求所處的業務背景，這點筆者一般還是非常關注的。

收集業務需求背景不僅是為了弄清楚使用者為什麼要做產品，即當前業務狀態出現了什麼瓶頸需要採用AI技術來解決；其次弄清楚業務需求背景還有利於收集行業屬性，從而為後期的競品分析做準備。

2. 業務場景

眾所周知，目前計算機視覺雖然取得了很大的進步，但是依然存在很多的瓶頸，比如攝像頭角度，光照、陰影、遮擋等依然影響著結果準確率。因此在需求調研的時候，一定要梳理清楚使用者是想在什麼場景下使用影像識別技術。

筆者以物流行業舉例，暫不考慮攝像頭，頻寬、伺服器等硬體本身的情況，只考慮場景和對應場景的演算法應用：

安防場景：在安防場景下檢測倉庫下的人體，識別人體屬性。存在的難點是物流倉庫一般架設的安防攝像頭高度比其他場景的高度要高很多，所拍攝的場景覆蓋範圍廣，即使不考慮遮擋，拍攝的目標也會相對小很多，這時候所帶來的檢測難度就會相對增加，甚至會出現小目標檢測的難題，如果這個時候還需要識別人體屬性（如服飾等）將更加困難；

固定攝像頭場景：有時候需要根據業務需求來考慮整體解決方案，其中重要的一環就是攝像頭架設方案，至少需要考慮攝像頭架設角度，垂直距離，水平距離，才能獲得清晰的圖片，有利於演算法檢測和識別；

特殊的業務場景：手機拍攝和安檢機；手機拍攝之所以特殊是因為手機採集的照片因為不同的人使用不同的手機型號，拍攝的圖片解析度不一致，同時待識別目標被拍攝的角度也不一致，其中解析度不一致引起的耗時和併發量問題，還可以通過增加伺服器、介面限流甚至是資料壓縮的方式來解決，但是角度不一致會對演算法本身準確率產生影響，要麼誤檢更高，要麼漏檢更多；安檢機特殊在它所成像的結果不同，給演算法研究就會產生困難，相同的目標在安檢機下成像的結果可能只剩下形狀和顏色兩個特徵，要想完成識別難度就會增加；目標在安檢機下的影像如下圖（圖片來源於網路，僅用於文章說明）。

小結：

AI技術和場景應該是相輔相成的，成熟度高的AI技術應該是業務場景找技術，成熟低的AI技術更多的應該是技術找場景，為什麼？

因為需要約束場景，才能滿足技術的可行性。

3. 業務需求

瞭解業務背景和業務場景後，進一步的核心就是了解業務需求，簡單理解就是使用者要AI檢測或識別什麼目標，這關係到演算法需求中是演算法會採用視訊識別還是圖片識別。

AI無法滿足覆蓋所有待識別目標，一味地擴大檢測識別範圍，所帶來的問題至少包含兩個方面：一個方面是訓練資料量的獲取，另一個方面是最終識別效果的難保證。

這些都會制約著演算法，這也是當前商品識別最大的幾個難點（還包括相似sku的問題）。因此梳理業務需求有助於演算法的正常開展和後續的推廣，以OCR票 據識別為例說明如何對接業務需求。

業務方提的需求一般是“我們要識別某某票 據”，AI產品就需要分析業務需求，儘可能轉為為AI演算法需求：

• 確定待識別的票 據型別，火車票->（紅色的？藍色的）、發票->（印刷體發票？手寫體發票？）
• 確定待識別內容，包括兩個方面，第一是票 據本身的內容，如數字、不同種類的語言；第二是明確待識別的欄位資訊，如火車票需要識別姓名、日期、價格、座位型別、始發站和終到站等。

4. 業務價值

經過上述諸多分析後，終於弄清楚了在哪做，需要做什麼了。那麼，接下來就是需要分析值不值得做了，業務價值分析是衡量產品是否值得投入的重要條件，也是後續做定價策略的評估條件，最重要的是給老闆彙報需要的。

從AI產品側可以直接和間接分析，直接分析就是該服務提供後使用者每天會產生多少的使用量，畢竟現在最常用的定價策略就是按照呼叫量來評估的；間接分析就是使用者呼叫AI服務產生了哪些業務價值，可以是節省了人力成本，提升了稽核效率，提升了點選率等。

當然，最好的方式是要量化分析，數字才能給老闆直觀的說服力。

5. 業務流程

上述所有的內容都分析清楚後，在沒跟老闆彙報前作為AI產品基本就可以評估出這件事是否能夠開展下去了，如果確定是要開展的，那梳理業務流程就必不可少了。

首先，與使用者對接梳理業務當前的系統流程，重點可以關注原系統在哪一步上傳圖片，上傳圖片後在哪一步是如何稽核的。有了這兩點資訊基本可以明確AI識別服務應該在什麼時間開始呼叫，原系統獲取AI識別資訊後，如何優化後續步驟了。

這裡不給出具體的業務流程，案例可以參考看下 《利用AI技術，實現線上線下互動引流》 中描述的業務邏輯。

二、演算法需求分析

通常筆者在跟演算法溝通需求的時候，演算法常問的有以下幾點：

• 在什麼場景下做；
• 需要識別什麼；
• 使用者接受的成本是多少；
• 產品的效能要求是多少（準確率和耗時）；
• 雲端還是本地端。

結合上述五點AI產品經理就需要反推演算法需求：

1. 演算法問：“在什麼場景下做”

產品需要描述清楚業務場景，如果是在業務方現有的硬體方案上擴充，演算法需求中要包括圖片成像的條件，圖片的解析度。最好的方式就是獲取當前條件下的圖片給演算法，一圖勝萬言。

在這一步，演算法會評估當前的硬體條件是否可以滿足識別的要求；如果不滿足，AI產品經理就需要做以下兩步：

1. （跟演算法商量，讓演算法給出硬體部署引數，包括攝像頭架設角度、攝像頭架設高度，攝像頭型號要求，其他的要求（如補光等）；
2. 跟業務方商量，如果要做AI方案需要重新部署硬體，業務方是否接受，業務方可能就需要評估下施工和硬體成本了。

2. 演算法問：“需要識別什麼內容”

這一步以OCR為例，可以參照上述業務需求描述中的內容；擴充下，演算法需求分析不僅要告訴演算法需要識別的內容，還需要告訴演算法需要返回的內容，比如返回目標框的座標資訊，目標的置信度，目標的數量等。

3. 演算法問：“使用者接受的成本是多少”

這點一般是出現在需要重新部署硬體方案的前提下，因為演算法評估硬體引數，一般都是綜合考慮的，如果要求是低成本的，演算法一般就需要犧牲一些效能採用輕量級的模型等。

4.  演算法問：“產品的效能要求是多少”

通常演算法期望獲得是使用者想要的準確率和耗時，AI產品需要做的是跟使用者確認這個數值。一般有的使用者會自己先做好充分調研，然後會告訴產品他期望的指標是多少。

但是很多傳統企業都是第一次接入AI，通常並不清楚這個指標能達到多少。AI產品跟演算法和使用者先約定一個指標，方便工作試點，後續根據使用者反饋可以收集錯誤樣本快速進行產品迭代。

5. 演算法問：“雲端還是本地端”

這點關係演算法的模型方案和硬體成本，也關係產品設計是API介面還是SDK服務。

舉例：根據業務需求描述的待識別內容，演算法需要評估是採用視訊還是圖片來分析，如果是視訊分析同時還要部署雲端，則網路頻寬成本將非常高。這時候演算法要評估是否可以採用圖片分析，最低的幀率是多少，採用什麼量級的模型，架構需要評估網路部署方案，是否可以在本地加入視訊伺服器做預處理，多少時間傳輸一次合適等。

產品在此過程中起到專案推動的作用，協調內部技術和使用者。

小結：

將上述的內容結合業務需求分析一般就可以給演算法提需求了，最後跟演算法明確輸出演算法方案的時間。

附：演算法需求分析需要AI產品在演算法和使用者之間不斷溝通確認各種資訊（有時候會很拉扯，因為使用者在接入AI之前也無法預估自己的期望）。

三、產品需求分析

AI產品需要打破傳統GUI的侷限，AI產品對外提供的產品形態不僅可以包括前後端GUI的完整系統，還可以是API介面和SDK的形式；

1. API、SDK類

在之前的文章 《如何做一款SDK產品》 中對SDK產品做了些簡單描述，本文從API的形式去描述，產品需求文件中需要包括介面的輸入、輸出、演算法準確率、誤檢率、漏檢率、介面耗時效能和演算法約束規則。

以圖片識別為例，產品需要定義好的核心欄位包括：

• 輸入：圖片格式—jpg、jpeg、png等；圖片傳輸格式—base64或url；ROI區域—數量，預設可以是整張圖片，最多支援多少個；ROI的畫法—矩形（左頂點+長寬），多邊形（所有座標點）；識別型別—如果介面支援識別多個內容，這個欄位可以加上指定需要演算法識別的內容；其他的鑑權、時間戳之類的欄位資訊可以讓開發定義；
• 輸出：核心資訊同演算法需求，但是需要落實到介面欄位上，如總目標數量、每一個目標的座標資訊、置信度，其他分析目標的特殊欄位資訊；
• 演算法準確率、誤檢率、漏檢率，這點筆者建議最好是以業務指標分析，以目標檢測為例，通常演算法是以mAP來衡量的，它是從目標維度來評估，但是使用者通常是從圖片的維度來衡量，一個圖片中有誤檢或漏檢的，使用者可能就會認為這張圖片識別出錯；因此，需要產品定義明確好；
• 耗時效能，這裡的耗時效能是指介面的整體耗時，即使用者傳入圖片到返回結果的耗時，需要演算法和開發一起評估，產品只需要定義產品需求。

2. GUI類

如果是GUI類的形態，產品重點關注的應該是產品原型如何設計，使用者體驗，使用者使用流程等，這個與傳統的產品設計並沒有什麼區別，只需要將演算法需求單獨拆分給演算法小夥伴。同時約定好演算法的規則即可，所謂的演算法規則即接受在當前的演算法能力下對使用者使用上的約束規則，比如要求使用者上傳的檔案格式、命名有什麼要求，演算法返回給使用者的識別結果有什麼限制。

作為產品其實很無奈，原則上應該以使用者為中心挖掘使用者最自然的使用者習慣，但是在AI技術不成熟的情況下，需要犧牲些使用者體驗。

結語

AI產品與傳統產品最大的區別在於，產品與開發之間又多了一層演算法。

AI產品只有先明確好演算法需求，在得到演算法可行性驗證結果後才能進一步考慮產品需求，當然演算法需求也是產品需求的一部分。

http://www.woshipm.com/ai/3059898.html

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69946223/viewspace-2664512/，如需轉載，請註明出處，否則將追究法律責任。