(六). 如何當好AI時代的產品經理（實踐篇）

摘要： 讀完這篇文章你會收穫什麼 1. 做AI產品應該如何利用演算法的能力？ 2. 如何通過工程的角度更好地發揮演算法的作用。 3. 做產品應該瞭解演算法的邊界，利用產品最大化演算法和工程的產出結果。 ...

1. 產品與演算法的結合粒度要小

產品經理應當把大顆粒的整體性領域演算法拆成小顆粒的演算法單元，並在此基礎上尋找產品化的可能。

這句話的意思是說，我們不能給演算法團隊提出一個很大的領域型需求，然後就坐等演算法的突破。產品經理應當更小粒度地看待每個具體演算法過程和環節，並評估是否有能夠被產品化的成果。

比如，我們不能要求演算法團隊交付一個“聊天機器人”，這個需求粒度太大了，徹底完成會受制於各種因素，更是一個長期的過程。產品經理應該深入到領域內，比如看到自然語言理解（NLU），甚至看到其中本體庫搭建和句子的語法樹等等，可能部分完成的本體庫已經可以包裝為一個初級的人機互動引導產品。

我們在無碼科技做 Readhub.me 時，產品經理會盡量避免提出像實現命名實體識別（NER）或實現資訊抽取（IE）之類，這樣大而化之的需求；而是儘量參與到演算法過程中，分步去看過程產出。

比如命名實體識別過程中我們需要分詞，分詞作為一箇中間演算法，是否可以被直接產品化；再比如資訊抽取需要先找到大資訊量的文字片段，這個過程的產出，是否可以作為文章摘要或文字標籤等等。

過去產品和技術涇渭分明，但在 AI 時代，我認為這個界限應該被打破，產品經理要融入到技術過程中去，不止關注需求，更要關注供給，這樣才能做出真正的好產品。

2. 要重視工程的力量

當我們說人工智慧的時候，總是希望演算法可以解決所有問題，給出一個乾淨而準確的結果。吳恩達教授在去年神經資訊處理系統大會（NIPS）上也提到深度學習會向端到端的方向發展。

這句話什麼意思呢？

就是說，比如我做一個語音互動的機器人，過去的思路可能是人說話，先經過語音識別的演算法變成文字，然後再用自然語言處理的過程去理解這些文字的意圖，最後做出反應；而端到端的思路是直接把輸入，也就是人的說話聲音灌到演算法盒子裡，演算法輸出的直接就是最終的反應，不去編排中間過程。

但是，完全端到端在工業界有效程度沒那麼高，我們還是需要大量的工程工作去對演算法模組做銜接，對演算法的輸入輸出做清洗和篩選。我們不能在工業界套用學界的做事方式和標準，比如演算法能做到 63 分，這時我們繼續拼命優化演算法，努力提升到 65 分，這就不如找個皮實一點的 60 分的演算法，加上工程手段，或許可以快速做到 70 分甚至更高。

工程至少可以在三個方面快速提高產品的價值分值，一是通過規則在演算法的基礎上對輸入和輸出資料做篩選和過濾（很多時候體現為大量的正則表示式）；二是通過工程幫助演算法做降維，比如做人臉識別，我們不用把攝像頭拍下的整張圖片送進神經網路，而是通過工程的方法把圖片中的臉截出來並且特徵化之後再往演算法裡送；三是協助演算法的訓練，比如做手寫數字識別，樣本量不夠的情況下，可以用工程的方法新增旋轉和噪點，生成一些新的訓練資料。

3. 利用產品最大化演算法和工程的產出結果

產品經理的職責是用產品為使用者創造價值，至於這個價值有多少分來自演算法，其實並不是成功的核心（除非你是做純演算法產品，比如一些對外提供演算法介面的純技術性公司）。剛才我們提到可能演算法做到 60 分，加上工程可以做到 70 分，而一個常見的問題是，產品經理將一個 70 分的能力用到了 90 分或者 50 分的場景中，結果是造成使用者的失落或技術能力的浪費。

比如，我們都知道自動駕駛有幾個不同的級別，從完全不能自動化的 L0 到完全自動駕駛的 L5。如果現在我們的技術做到了 L4，非常牛了，這個級別下，大部分情況下都可以達到完全自動駕駛。

結果產品經理在此基礎上，做了一個沒有方向盤和窗戶的產品，使用者吃著火鍋唱著歌把車開到村裡，結果在田間地頭，車翻了；又或者，產品經理做了一個傳統的汽車模式，有方向盤有檔把，還需要人來操作，完全沒有把 L4 的技術能力用上，浪費了技術的輸出。

所以說， AI 時代的產品經理應該非常瞭解演算法的能力邊界，並設計出恰如其分的產品，同時也要管理好使用者的期望值，既不讓使用者覺得失落，也要發揮演算法的最大價值。

4. 做好資料規劃

人工智慧產品經理還有一個非常重要的職責，就是規劃、收集以及組織演算法所需要的資料。如何保證訓練、測試集中的資料特性分佈和最終場景中的資料一致；如何獲取足量的資料，並對它們進行低成本高效率的標註；用什麼樣的方式清洗資料，甚至基於資料做出統計學分析，為演算法提供參考，這一切內容都需要產品經理去完成。

業內有一種說法是：當前的人工智慧效果，2 分靠演算法，8 分靠資料（剩下的 90 分靠運氣，開玩笑的）。尤其是大量的深度學習應用，對資料的質和量提出了很高的要求。

產品經理應該要理解演算法的資料輸入要求和未來的演算法應用場景，找到合適的資料來源，合理合法地把這些資料收集下來，清洗乾淨；並有規劃地劃分開發、訓練和測試集，以保證資料價值的最大化。

當然這個過程不能單靠產品經理一個人，需要有配合的工程團隊一起。在無碼科技，我們有一個兄弟算是半個全棧工程師，專門跟產品經理配合做這個事情，他能寫指令碼、能做資料、還懂業務，但願你也能遇到這樣的特種部隊型選手。

另外產品經理還應當想辦法在業務中設計資料的閉環，通過產品的持續運轉，不斷生成更多資料提供給演算法做訓練。目前。大部分的訓練過程還是離線的，但如果未來線上學習持續發展，通過這樣的業務流程設計，就可以做到線上演算法迭代更新。

最後還有一個經驗是，盲目擴大資料量並不總是有用的，如果資料的多樣性得不到保證，擴大資料規模對演算法結果沒有太大幫助，甚至如果資料特性分佈出現問題導致訓練資料有偏，還可能會造成演算法的過度擬合和表現下降。

5. 去完美主義，理解演算法的不確定性

從某種意義上說，機器學習的不確定性是必然的，它跟傳統的面向流程和規則的思路截然不同，在這樣的框架下，就需要轉變產品設計的思路，摒除完美主義，利用產品機制去消化演算法帶來的不確定性。

比如，機器學習用在反欺詐或垃圾郵件監測上，就是存在概率的。一封郵件是否是垃圾郵件，在演算法完成推理前（尤其是深度學習），即便演算法的作者恐怕也無法給出準確的預測。

演算法有可能會錯判和漏判，這都是產品經理需要理解和考慮的場景，並且要去通過產品設計去消化它。比如反欺詐要準備申訴的流程和入口，垃圾郵件可能需要提醒機制和獨立的資料夾等等。

除此之外，我們評價一個演算法有效性的方式，也要從區域性轉向巨集觀，不能通過一條資料的推理結果去評價一個演算法。

有時演算法迭代升級，可能整體效果更好了，但單看某一條具體的測試資料，卻可能比原來糟糕。比如我們做命名實體識別，演算法升級之後，在測試集中跑出來的 F 值更高了，但可能某一條升級之前能夠正確識別的語料在升級之後卻不能識別了。

這是很正常的現象，儘管有點反直覺，但我們必須要把思維模式轉變過來。

總結

隨著這個領域的實踐和積累，我越來越相信人工智慧的發展一定會給這個行業帶來顛覆性的變化，就如同 08 年左右的移動，從最初的自成領域，到如今滲透至所有領域之中。我認為人工智慧也是一樣。

現在，我們看人工智慧覺得它只代表智慧音箱、智慧助理、人臉識別、下棋之類相對獨立的應用場景，但在不遠的將來，它一定會被打散，滲透到各種各樣的應用和場景中，成為新的基礎設施，作為產品經理，你不要錯過這一波機會。

回顧一下我今天的五點思考。

第一點是產品經理要能夠深入理解小粒度的演算法，並將其產品化；第二點要重視工程的力量，不要追求完全純淨的演算法輸出；第三點是利用產品設計，最大化演算法和工程的產出；第四點是提到人工智慧時代的產品經理一個特殊的職責，就是對資料的規劃；最後第五點我說到機器學習演算法帶來的思維模式變化。