前Facebook產品經理：打造機器學習產品的黃金手冊（下）

作者：前 Facebook，雅虎產品經理 yaelg

編譯：珊珊

人工智慧時代，每位產品經理、企業家以及商業領袖都應該了解機器學習。

即使你不是在設計一款chatbot或者無人車，但為了產品保持競爭力，你早晚都要把機器學習融入到你的產品中。

好消息是，你不需要發明新的技術，只需利用已有的技術。許多科技公司開放開源工具和平台（如Amazon AI，TensorFlow—最初由Google開發的）使得幾乎所有公司都可以使用機器學習。

當我開始搗騰機器學習的時候，我什麼都不曉得，然而在很短時間內，我便掌握了領導開發機器學習產品的核心要領。

我的目標是讓你充分了解開發機器學習產品的技術和開發流程，使你能儘快開始。這將是一份循序漸進的教程，助你成為利用機器學習實現業務目標的PM（產品經理）。

5. 機器學習就是個UX（User Experience）問題

6. 產品經理應該了解的開發注意事項

▍第5部分

機器學習就是個用戶體驗（User Experience）問題

前面我們討論了如何建立有效的組織架構，現在我們來看看，如何幫助用戶從機器學習結果中獲益。

ML模型和結果不容易解釋清楚

許多ML演算法是黑盒子——輸入了大量數據，並獲得了一種神秘的方式產出結果的模型，這使得結果難以解釋。在許多演算法中還存在交互效應，使得模型更加難以解釋——這是各種能解釋部分行為的特徵值之間的關係，只通過單獨添加某個特徵值的效果是難以解釋的。

把它想像成特徵值之間的複合作用——整體大於其個體的總和，以很多奇怪和不能為人所理解的複雜方式作用一起。

也就是說，你和你的團隊將需要確信結果是有根據的，如果你能在超出統計指標的表面數字來理解結果就更好了。它也有助於確定未覆蓋的案例或結果無意義的領域，就像我們在前面模型構建章節所提出的。

這對你的用戶來說更為重要——通常他們需要一個解釋才能相信你的結果。即使你的結果是100％準確的，也不會助你得到更好的信譽，所以用戶可能需要得到你們顯示的結果的合理解釋。

在極端情況下，你甚至可能需要因結果去規避法律，如拒絕貸款申請的情況，法律上你必須給予客戶充分的拒絕理由。為了增加複雜性，你的模型不會100％準確，80％的準確率已經相當不錯了，所以有時候，用戶會想了解實際上是錯誤的結果！

換句話說，基本要求是，讓你的用戶在一段時間內發現明顯錯誤，而還選擇相信你的整體結果，就是很高要求了。

挑戰不僅來自於外部客戶使用的模型——也需要獲內部用戶的信任；即使他們支持你，你的團隊可能也不太會採用—不了解或者不信任的結果。

我見過一些案例，團隊首選使用易於理解的規則引擎，而不是ML模型，這可能會產生更好的效果，因為引擎規則是可以解釋的——它們是人寫出來的，所以人們能理解為什麼得出這樣的結果。

這不是一個可以等你建好模型之後，再來解決的問題——提前了解用戶可能想要看到的模型的數據和組件，以及模型是以何種方式呈現結果的，以至於這個模型的構建者信任它產出的結果，這是十分重要的。

得到的答案，可能會改變你構建模型的思路，並且將有助於防止出現出現問題時，你無法向用戶解釋原因的情況。並不是說提前考慮這一點就能一勞永逸了，建模本質上就是一個迭代的過程，如果你的模型已經開始改變，那麼可能需要你的方法更大範圍修改。

可解釋性建模

對可解釋性的需求，可能會影響你構建模型的方式，包括你需要提供的粒度級別。假設我們正在為投資者建立一個基於Marc Andreessen框架，評估初創公司的平台，該框架要求，每家創業公司的三個核心要素是團隊，產品和市場。

現在，Andreessen認為市場是最重要的因素，但其他投資者會認為一個好的團隊可以找到發展小市場的方法，所以團隊更重要。

你可以為公司的這三個維度，提供整體評分或成功概率估算，並給出你認為是正確的「結論」，但投資者不一定會為此買單。更具體來說，投資者可能只想了解這家公司中，他們最關心的某個維度有多好（高分）。

除了利用模型，你還需要讓他們看到這一點。這裡有幾種方法：

為市場，產品和團隊分別構建3個不同的模型，每個模型在單一維度上評估公司。然後構建一個將所有這些特徵值（以及潛在的其他特徵值）綜合在一起的綜合模型，這樣投資者就可以看到他們最關心的總體結果和具體維度了。

構建聚合模型，並找到一種方法，來提取最適用於每個維度的特徵，並向用戶傳遞其價值和重要性，或者顯示與每個維度對齊的數據點，以建立對結果的可信度。

正確的方法在很大程度上取決於你的問題領域，可用數據，建模方法等，但在進行原型設計模型之前，應該進行明確的討論和評估。

向用戶呈現結果

當決定如何顯示結果時，目標應該是使他們清晰，可信，最重要的是——可行的。這裡沒有指導手冊——每個問題都會產生不同的結果。

我們來回顧一些可行的方法和注意事項，為你提供一些思路：

回溯演算法，根據歷史數據將其輸入到模型中，以產生有已知值可驗證的過去預測。例如，如果你建立了一個根據N-1年數據預測第N年值的模型，則可以從2年前的模型數據，看對去年的預測是否正確，因為該信息是已知的。

這也是測試模型的潛在方法。根據歷史數據的完整性，以足夠的數據覆蓋一些簡單的假設和/或模型，調整可能會遇到困難（例如，如果模型使用來自社交網路的數據，你不能回溯到社交網路還不存在的時候）。對於某些模型，強化學習模型也是不適用的。

解釋你的方法和輸入。告訴用戶，你從他們的帳號中，提取並輸入這個被信任的模型中的數據，是他們自己做決定的時候也會考量的因素。

在Andreessen初創公司評估實例中，對市場評估的簡要說明會是：「創業公司的市場潛力，考慮到市場上已有的的公司數量及銷售總額，這個市場在過去5年全球範圍內的增長，新產品發布的數量，滲透率，併購活動和宏觀經濟趨勢。」

雖然這不是一個完整的解釋，但它確實能讓用戶瞄一眼黑盒子。如果你是在介紹一個新東西／服務，這是絕對有必要的。

公開一些基礎數據：這是最容易讓用戶了解和信任的方法，因為他們自己也看得到數據，儘管並不總是簡單的設計，還有有幾個缺點：

你需要公開你不希望或可以公開的數據（例如，因為它是專有的，受法律約束等），數據在某些個例中，可能不符合得出的模型（建模是關於概率），甚至可能沒有數據；該演算法不需要對其評估的實體進行全面覆蓋——如果數據具有足夠大的相似實體的數據樣本，則可以彌補數據中的差距。

簡化並僅選擇性顯示結果，以便於決策。亞馬遜對其一些產品建議做得很好。我搜索了一個護膝，看到我從Google搜索結果登陸的頁面下方。亞馬遜知道關於每個相關產品我會選擇購買的概率，而不只是給我30個類似產品的排序選項，我得到了一個二選一的簡單選擇方案——最便宜或最暢銷+最高評價的產品。

我不知道他們選擇對比產品的標準，以及是否符合我想找的產品的標準，但是講真，他們把一切選擇和購物流程，都簡化到我已經不在意標準了。

定義新的指標。你應該考慮的一個問題是，你是否要創建新的指標（新的「分數」方式）或預測一個很好理解的指標：你可以構建模型，來預測現有指標（例如公司，房價等）；

或者，你可以創建一個體現某個概念的分數，該分數代表尚未具被廣泛應用的指標，通過這個概念（「FICO分數為」）來實現實體的排名。這個決定大致歸結為是否有一個單一的指標可以用來表達你想要用模型達成的業務目標，或者是需要幾個因素的加權混合。

例如，如果我們評估某商業房地產資產對零售業的吸引力，我們可能希望創建一個「零售合適分數」，其中包括幾個組成部分，如每平方英尺的銷售量，每平方英尺的總成本和地段對品牌價值的貢獻（比方說，你認為第五大道上的鋪位，能增加品牌名聲，超越了它單純吸引到的人流量）。

在這種情況下，存在沒有包含這些指標的單一指標，所以你可能需要單獨為每個指標建模，然後通過某比例的權重，將它們組合在一起。選擇新的分數時，一個你需要考慮的重要因素是，這個過程，可能需要花更多的時間和精力，來教育你的用戶。

想想，要說服第一次聽說，就願意使用FICO分數的金融機構該怎麼下手？

精確度不總是那麼重要。許多模型產生的結果是一個非常精確的數字——概率，價格等。如果你給他們看到這麼精確的數字，那麼你就得冒著用戶可能比你想像中更嚴肅認真對待這些數字的「風險」。

預計價值583,790美元的住房的價值，並不比價值580,625美元的房屋划算多少。誤差幅度可能遠大於$ 3K。有時以精確的方式，將結果顯示給客戶是有效的，讓他們更關注數字。與其向客戶顯示演算法的確切輸出，給出某個範圍、十進位、等級或其他一些不那麼精確的價值測量，或許會是更好的做法。

有策略地提供對原始數據的訪問。除了展示自己的風險模型的結果外，借貸俱樂部還提供其原始數據，供其他人建立自己的ML模型。

這個方法對你有用嗎？可以在業務的其他部分增長嗎？除了提供潛在的貨幣化選擇外，這種方法還有助於ML研究界加快空間創新的步伐。例如，微軟的COCO（http://mscoco.org/）和CIFAR數據集（https://www.cs.toronto.edu/~kriz/cifar.html）的可用性大大有利於圖像分類功能。

再次，用戶體驗的選擇高度依賴於主題，產品和用戶需求 - 沒有「一刀切」。完全可能的是，上述任何選項都不會與您的產品相關。關鍵是，不要低估用戶體驗問題所需的思考和努力的數量 -如果用戶不能理解，信任或採取行動，即使最好的模式是無用的。

一個比較Geeky但很重要的提醒

可解釋性是ML研究中不斷發展的領域，研究人員積極尋找使模型看起來不那麼黑盒子的方法。有個例子是LIME（本地可解釋模型——不可知解釋，https://homes.cs.washington.edu/~marcotcr/blog/lime/）：

作為分類器（將輸入數據映射到類別或標籤的演算法）模型的「解釋器」，用來構建人類可以理解的模型。是否與你的目標相關或有效，取決於你的具體情況和使用的模型。

另一個研究領域是Layer-WiseRelevancePropagation

（LRP，http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0130140）——一種「解構」神經網路預測的技術，使對各個輸入變數的預測可視化和可被解釋。雖然構建有效的機器學習的開發基礎設施在很大程度上超出了本教程的範圍，但請記住，產品需求可能會影響開發決策和要求。

▍第6部分

產品經理應注意的開發注意事項

儘管在很大程度上，你的工程開發團隊負責設計穩固的系統架構，但業務需求可能會影響ML系統，從而使一個偉大的系統變成糟糕的系統。

作為PM的你，必須與工程開發團隊進行正確的深入討論，才有可能搭建出一個適合你們商業需求的系統。

雖然以下列表並不完整，但應該讓你對哪些領域應該深入了解有個大概方向：

實時要求。演算法的結果可以提前計算，還是需要實時計算？當你獲取新數據和/或用戶輸入特定信息或執行某些操作時，模型是否需要立即生成反應新結果的新數據？實時系統的架構，與可以離線處理數據的系統的架構大不相同。

數據和模型。系統可能由多個模型組成，其中一個模型的輸出可能會是另一個模型的輸入。當一個模型的輸出發生變化時，其他模型是否需要重新計算？當添加或修改數據時，哪些模型需要重新計算（有時甚至重新訓練）？更新速度要多快——什麼是可接受的SLA？

數據採集頻率。收集和累積數據的速度，會影響管道的設計和選擇的存儲方法。這取決於數據實際變化的頻率，了解其變化的重要性以及獲取數據的成本（如果你需要支付這些數據，就需要購買成本，以及檢索，處理和存儲成本）。

例如，如果你正在收集關於地震的數據，數據可能不會很頻繁地更新，但是當它改變時，你需要立即知道數據；如果你正在收集關於餐廳營業和停業的數據，那麼數據可能會比地震數據更頻繁地變化，但是發現這些數據的及時性，對產品的整體效用並不那麼重要。

數據收集方法。收集的數據是批量還是連續流式傳輸？是push還是pull？實時要求使這個問題更複雜化。 你的系統可能需要，支持多種數據收集或上傳方法--API，文件上傳等。它需要足夠的模塊化，以支持所有必要的方法，並將數據從數據處理中分離出來（這是一個很好的軟體工程原理）。

好了！ 你現在應該有足夠的知識開始搞搞機器學習了。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！