編輯導語：本文作者根據自己從0到1搭建指尖查詞功能的經驗，以大力智慧檯燈產品為例，從產品經理的視角，梳理了AI產品（計算機視覺產品）的工作流，感興趣的小夥伴們一起來看一下吧。
最近在做類似大力和有道的智慧檯燈產品，從0到1搭建了指尖查詞功能，對AI產品算是有了一些基礎的理解。
本文試圖以產品經理的視角梳理AI產品（計算機視覺產品）的工作流。
一、工作流框架
下圖是一個AI產品的大概框架。這裡面關鍵的認知是，AI能力迭代是跟產品功能迭代平行的、一條需要基於反饋不斷迭代的一個子工作流。
引用自微軟《人工智慧系統》
基於兩者是平行的流程，我們可以借鑑產品經理的工作流，對AI產研的工作流程進行拆解和構建。下面，我們來看一下每個流程中AI產研應該關注的問題。
二、需求分析
在需求分析階段，對AI產研來說，同樣需要了解使用者、場景、需求。接下來舉一些例子。
1。 場景分析
不同的場景對於AI的需求是不一樣的。比如在於指尖查詞專案中，我們需要了解使用者在使用智慧硬體產品時的燈光環境，這個涉及到我們對於演算法訓練集的選擇。
在學習場景中，可能很多家長或者孩子會在光線很暗情況下看書，但是他們可能自己並不知道。
還有的人家裡的燈光很黃，拍出來的影象就會顯模糊。還有的影象會有一些暗光甚至區域性曝光。
另外，有些攝像頭會在不同的光線之下自動做白平衡，這會導致最後出來的影象差異非常大，這些都會導致最後演算法的準確率很差。
——紙上世界創始人分享
2。 痛點分析
我們需要了解使用者在某個場景下的問題，然後分析AI對此問題能否有效（提升效率、降低成本、提升體驗）。
比如在指尖查詞專案中，使用者原有的解決方案比如查紙質字典，就存在以下問題：
1）便捷性差
字典是個大塊頭，不方便攜帶，一般都放在書桌。
2）查詢效率低
尋找一個目標單詞需要先找到首個字母所在的大概位置，然後再進一步去找該單詞，定位比較麻煩。
3）資訊維度不夠
比如詞典裡面的單詞音標，目的是教小朋友學習發音，但是低年級的小朋友是沒有學到音標的。所以這些學生要有標準的發音進行引導，除此之外，還需要有發音的口型教學內容。基於計算機視覺的AI能力，類似有道詞典筆的產品可以大幅提升查詢效率，這是整個產品能夠成立的關鍵。
3。 可行性分析
除了驗證AI能否有效以外，我們還需要知道我們的AI是否可行。比如在指尖查詞專案中，我們就需要知道使用者對於AI的要求，比如以下指標：
精度、召回率
結果返回耗時
如果我們演算法的精度大大低於使用者的預期，則專案無法成功。
三、競品研究
AI能力也需要進行競品研究，我覺得可以從技術的成熟程度來進行對應的競品研究。
1。 前沿技術創新
很多前沿技術雖然還沒有被大規模投入使用，但是已經能產出很多demo了。尋找這一類的競品，我覺得可以在github上面找到。
比如，我跟演算法同學聊了指尖的軌跡跟蹤，立馬丟給我一個github的軌跡跟蹤的專案deepsort。
類似這種，github上的技術，對於自研AI的團隊來說非常重要，一方面這些內容能夠讓我們瞭解技術的能力邊界，另外一方面，基於這些開源的演算法，我們能夠快速搭建demo。
2。 業界成熟的技術
這一類可以從AI平臺找到，比如百度、華為、阿里、騰訊這種AI大廠的開放平臺，就展示各種已經成熟的AI能力，以及成功案例。
比如以百度AI為例，其官網就有非常多的技術，值得學習。
四、演算法設計
在演算法同學進行演算法設計時，我們AI產品需要知道演算法，這樣有利於我們進行產品設計，我覺得以下兩個是一個好的切入點。
1。 整體框架
對於AI產品來說，雖然不需要寫演算法，但是知道整個演算法的框架有利於產品設計。
比如在指尖查詞專案中，如果在客戶端部署了指尖檢測的演算法，我們就可以在檢測到指尖時，給予使用者及時的狀態反饋，而不用等到整個文字識別結果返回才給到反饋。
推測大力的整體框架
對於演算法，我們產品經理不應該把它當做黑盒子，而是應該瞭解，然後在此基礎上做出更好的產品。
2。 介面文件
除了整體的框架，我們AI產品還可以通過了解介面文件，來增進對於演算法的瞭解。
比如我們看了百度OCR的介面文件，我們發現AI能夠識別文字的角度。基於這個能力，我們可以在發現使用者書本方向放錯時，給予使用者及時的反饋。
五、需求文件
在需求文件這塊，除了傳統的需求文件模組之外，AI產品（計算機視覺產品）可能需要需要在以下幾個層面進行深入。
1。 AI互動細節
大力檯燈在指尖查詞上的互動給業界定了一個標杆。具體而言，大力定義了幾種互動狀態：
開始檢測：方括號開始閃動
檢測到使用者的手指：方括號內出現手指
識別到手指後，開始進行文字識別：方括號開始出現轉圈
大力互動厲害的地方在於透過對三個圖示（方括號、手指、載入圓圈）進行簡單的組合，就構建了一套互動體系，給到使用者即時反饋。
整個解決方案，對於使用者來說學習成本比較低，是一個比較優雅的解決方案。
2。 異常情況處理
由於演算法在早期的效果是不夠理想的，所以我們要界定一些超出AI能力的異常情況，也就是黑話“兜底”。
比如計算機視覺中一直沒有返回影象識別結果，對話機器人中一直無法判斷使用者是否說完話或者使用者意圖，等等。大部分的兜底策略就是用開玩笑的口吻迴應使用者，比如“這個單詞還沒學會”、“這個技能還要再練習”。
3。 指標需求
一些關於AI能力的指標需求，常見的指標如下：
準確率、錯誤率
精確率（查準率）、召回率、F1
ROC曲線、AUC
計算速度、結果返回耗時、魯棒性
六、冷啟動策略
1。 演算法冷啟動流程
演算法最終會達到一個正向迴圈，即上線後拿到使用者資料，對這些資料標註後，訓練演算法，提升演算法效能，然後會有更好的體驗，會有更多的使用者使用，接著拿到更多的使用者資料，走向正迴圈。
但是剛開始的時候，沒有大量資料進行訓練的時候，演算法效能是不高的，需要慢慢達到正迴圈，再次之前的過程，我理解為演算法的冷啟動。
2。 接入服務 vs 自研
如果我們是接入百度、華為等大平臺的AI能力，那冷啟動的過程相對來說要快很多，但是一個要注意的問題是大平臺的服務相對來說是通用的，可能對於我們自己的垂直場景沒有做過最佳化，估計資料表現也不會很好。
百度有一個EasyDL的平臺，是專門解決這個問題的。
如果我們的深度學習演算法是自研，我們可以透過以下幾個層面的行動進行演算法的冷啟動：
演算法層面：
把開源的演算法拿來用，進行遷移學習，從而快速達到一定的演算法精度。
資料採集/標註:
購買市面上已有的資料集
機器合成對應場景的資料，快速生成訓練集
透過人工或者工具產品的方式，收集對應場景的真實資料，進行標註
3。 場景容錯性判斷
我們知道演算法的精準度等指標剛開始是不理想的，尤其是在自研的情況下，我們需要讓使用者先用起來，然後收集資料之後，再進行訓練和迭代。
其實這個跟產品的MVP很像，剛開始釋出的第一個版本，也不是一個完美的版本，需要使用者用起來之後進行迭代才行。
但是在冷啟動的時候，要考慮場景的容錯性。比如自動駕駛領域，可能對於計算機視覺的能力要求非常高，出錯了會造成乘客的生命危險，這個場景的容錯性是很低的，所以這種產品內部要做很多測試，達到較高的標準之後，才能釋出給使用者體驗。
但是，對於很多場景容錯性相對較高，比如娛樂遊戲場景，則標準比較低，可以儘快上線，接受使用者的反饋。
七、演算法迭代
1。 準備測試集
我在做指尖查詞的產品過程中，跟著演算法工程師一起把演算法的準確率從70%+提升到了90%+，可以分享一下整個過程。
深度學習作為監督學習，需要大量資料進行訓練。這些資料分為三個部分，訓練集、驗證集和測試集。
訓練集：相當於課後的練習題，用於日常的知識鞏固
驗證集：相當於週考，用來糾正和強化學到的知識
測試集：相當於期末考試，用來最終評估學習效果
對於AI產品經理來說，我們需要測試集，這樣方便我們對深度學習演算法進行評估。
2。 分析測試集資料
準備測試集之後，我們基於演算法的框架，使用漏斗模型，得出每個節點的準確率。
比如，對於指尖查詞來說，演算法從開始識別，到最終識別成功，可以用以下的漏斗模型進行表示。
透過測試集的資料分析，我們發現，主要的問題出現在3-4層、4-5層漏斗中，即指尖識別的座標錯了（識別到別的字了）、文字識別錯誤（類似把apple識別為abble）。
更具體而言，整個測試集樣本中，有12%的樣本是指尖識別座標錯誤，有6%是因為文字識別錯誤，所以我們第一個版本的準確率大概只有70%左右。
3。 找到改進機會點
1）指尖識別座標錯誤
演算法同學對於錯誤的樣本原因進行分析，發現對於指尖識別座標錯誤這一型別，是屬於演算法最佳化的點。
主要理由是，演算法同學判斷指尖附近內容的方法存在問題。最佳化之後，後面幾乎沒有座標識別錯誤，正確率一下子提升了12%個點。
2）文字識別錯誤
對於識別錯誤，演算法同學同樣對錯誤的樣本進行分析，並且分類。如下面所示：
主要的解決方案是針對細分場景，準備更多的資料進行訓練，或者基於更優的規則，以提升準確率。
4。 迭代演算法
經過一個週期的努力，我們把演算法的準確率從70%+提升到了90%+，使用者的體驗有了質的提升。
八、使用者體驗管理
早期演算法還不是很厲害的時候，我們需要主動做一些使用者體驗管理。我覺得可以從以下幾個層面進行管理：
1。 預期管理
基於我們場景的容錯率，我們的產品要在滿足使用者的最低要求後，才能給到他們使用。釋出之後，最好也要進行預期管理，告知目前哪些場景可以支援，準確率怎麼樣，哪些又不能支援，希望能夠給到使用者合理的預期。
2。 容錯設計
比如指尖查詞場景裡面，當演算法不確定使用者是指哪一個單詞時，我們可以把兩個相近的兩個單詞都給出來，方便使用者進行挑選。
類似以下場景中，大力檯燈把【朱】【旭】都展示出來，使用者可以透過切換得到自己想要的詞。
競品的指尖查詞（圖來自藍鯨教育）
3。 使用者反饋問題入口
某些場景我們的演算法確實搞錯了，則可以留一個入口給到使用者。一方面給到使用者一個宣洩的渠道，另外一方面也可以作為一個樣本給到我們去判斷底層的問題。
4。 規範使用者行為
有一些場景AI功能還未覆蓋，則我們需要規範使用者行為，告知目前不支援這些場景。
比如，我們的OCR識別還不識別手寫體，則使用者拿手寫體過來時，則要告知使用者不支援手寫體，不然使用者會很有挫敗感，類似還有：
燈光過暗
字型過大或過小
書本摺疊
手指蓋住單詞
識別非目標語言的文字
5。 系統思考：不止AI
不能把所有的體驗問題都歸咎於AI演算法，比如在識別過程中的耗時問題，除了AI演算法可能存在問題外，我們的app可能在攝像頭開啟、識別結果資料庫對比等環節都存在耗時過多的問題。
我們要進行系統思考，這樣才能定位到真正的問題。
以上就是從產品經理的視角梳理AI產品的工作流，請多多指教。
本文由 @小明的產品筆記 原創釋出於人人都是產品經理，未經作者許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議