機器學習產品寶典：這是谷歌內部總結的七大要點

李林 若朴 編譯整理

量子位 報道 | 公眾號 QbitAI

產品經理新入機器學習坑，應該注意什麼？

Google的用戶體驗設計團隊總結了7點，量子位編譯如下：

在沒有用上機器學習(ML)的時候，一個網站或者App有許多人為設定的規則。而機器學習，能讓產品不依賴這些規則，從數據中發現模式和關係。

機器學習能夠為用戶創造個性化的動態體驗，小到視頻網站、新聞應用，大到無人車，都在使用這種技術。

於是，用戶體驗設計師，或者說產品經理，面臨著一項重任：確保機器學習和用戶體驗的協調，讓用戶感受到自己掌控著技術，而不是被技術掌控。

和互聯網、移動互聯網兩波浪潮一樣，ML也讓我們在建立每一項用戶體驗時，都需要重新思考、重組、置換，考慮新的可能性。

Google的用戶體驗設計團隊為了應對機器學習帶來的新問題，提出了一個努力方向：「以人類為中心的機器學習」(HCML)。

這個名字有點眼熟？量子位猜，大概是因為和「以用戶為中心的設計」比較像。

我們從「以人類為中心」的角度去看產品，探索怎樣從人類的需求出發，用只有通過ML才能完成的獨特方式去解決這些需求。

如果你剛剛開始接觸機器學習，可能會覺得信息量太大。

不要慌。

通過Google用戶體驗團隊和AI團隊的合作，以及試錯的經驗，我們列出了以下7點，幫用戶體驗設計師來熟悉「機器學習驅動的產品」這一新領域。

這些要點能幫你把用戶放在第一位，快速迭代，並了解機器學習帶來的獨特機會。

開始吧。

1. 不要指望機器學習自己找出需要解決的問題

機器學習和人工智慧炒作得太火熱，很多公司和產品團隊在制定產品策略的時候，甚至不管要解決什麼問題，先確定了以機器學習作為解決方案。

如果只是純粹的技術探索，這樣沒什麼問題，可能還會激發產品設計靈感。

但如果是在設計產品，你不從人的需要出發，可能就會建立一個非常強大的系統來解決非常小、或者根本不存在的問題。

所以，我們要說的第一點是，那些挖掘用戶需求的苦活累活，你還是得自己做。

那些情境調查、訪談、深入討論、用戶調查、日誌分析統統不能簡化，你需要接近用戶，找出你是否解決了問題，或者找到了他們潛在的需求。

機器學習不能自己找出該解決的問題，這需要我們來定義。

作為用戶體驗設計師，無論哪種技術範式主導，我們指導團隊的基本工具還是不變的。

2. 問問自己，機器學習能否以獨特的方式解決問題

一旦你確定了需要解決的問題、需要滿足的需求，就該評估機器學習能否以獨特的方式解決這些問題了。

很多問題根本用不上機器學習。

在產品開發的這個環節，一個很大的挑戰是去確定哪些用戶體驗需要ML，哪些功能用了ML會得到有意義的增強、哪些用不用都一樣，甚至用了還不如不用。

很多產品不需要ML就能給人「智能」或者「個性化」的感覺，不要以為只有機器學習才能救產品。

忘了加附件的提示，就不適合用機器學習

我們創建了一組問題，來幫團隊了解ML對其用例的價值。

這些問題，深入挖掘了用戶與ML系統的交互可中可能有什麼樣的心理模型和期望，以及該系統需要哪些數據。

這裡有三個例子，Google某團隊想要用ML來解決一個用例時，就回答過這些問題：

描述理論上的人類「專家」現在可能怎樣執行這個任務。

如果你的人類專家要執行這個任務，你會如何回應他們，以便下次改進？對混淆矩陣的四種情況(真正、真負、假正、假負)都做出說明。

如果一個人要執行這個任務，那麼用戶希望他們做出什麼樣的假設呢？

花幾分鐘時間回答這些問題，能幫我們了解用戶會帶著哪些預設去使用ML產品。在產品團隊的討論中，或者在用戶研究的過程中都可以去問這些問題。

稍後我們討論定義標籤和訓練模型時，還會再提到它們。

回答了這些問題，為特定的產品或者功能寫了故事板，我們就可以將團隊所有的產品想法都放進這四個象限中：

橫軸代表ML帶來的影響，縱軸代表對用戶的影響

通過這個坐標系，我們能找出哪些想法比較有影響力，哪些想法依賴於ML來實現。在前面的對話中，你就應該開始和開發人員合作了，如果還沒有，從這裡開始也不晚，讓他們來衡量這些想法在實際中能否用機器學習解決。

在象限右上角的功能：也就是對用戶有著最大的影響力，ML技術也能帶來獨特體驗的那些，就是優先順序最高的。

3. 原型設計：個人示例和Wizard of Oz

ML系統的一個重大挑戰是原型設計。

如果產品的核心價值在於通過獨特的數據來為用戶定製個性化體驗，你很難快速地設計一個具有真實感的原型。但是，如果你等ML系統建完再去測試它的設計，可能就沒機會改了。

不過，有兩種用戶研究方法可以解決這個問題：使用參與者建立個人示例、Wizard of Oz研究。

在使用早期模型進行用戶研究時，可以讓參與者帶一些他們自己的數據來，比如個人照片、通訊錄、他們收到的音樂或電影建議等。當然，要讓參與者完全明白他們的數據將被用來幹什麼、什麼時候才會被刪除。

對於參與者來說，這可能是一個很有意思的家庭作業。

通過這些示例，你可以模擬系統的正確、錯誤響應。比如說你可以模擬系統向用戶返回錯誤的操作建議，查看用戶的反應，了解他對錯誤原因的假設。

和虛擬示例或者概念描述相比，這可以幫你更可靠地評估各種可能性的成本和收益。

還沒造出來的機器學習產品的第二種測試方法，是Wizard of Oz研究。過去20年間，Wizard of Oz研究在用戶研究方法中的重要性越來越低，現在，它回歸了。

Wizard of Oz？綠野仙蹤？

這種測試指的是由一名產品團隊人員代替系統，向用戶做出反饋。

GIF/1870K

聊天界面是Wizard of Oz測試最簡單的方法之一，只要在另一端準備一名產品人員，假裝「AI」來輸入回復。

讓產品團隊人員模仿機器學習系統的行為，比如回復聊天信息、給出呼叫建議、電影建議，可以幫用戶模擬體驗與「智能」系統的交互。

這些交互可以為產品設計提供關鍵的指導，因為當參與者認真地與「AI」交互的時候，他們會自然形成系統的新力模型，根據模型來調整自己的行為。

觀察他們的對系統的適應、與系統的二次交互，對於產品設計有重大的參考價值。

4. 衡量假正類和假負類的成本

你的機器學習系統會犯錯。了解這些錯誤是什麼樣的，以及它們如何影響用戶的產品體驗很重要。

我們在第二點中提到了混淆矩陣。這在機器學習中是一個關鍵的概念，描述了當機器學習系統正確或者錯誤的時候是什麼樣子。

混淆矩陣的四個狀態，以及對用戶意味著什麼

對於機器來說，所有的錯誤都一樣，但對人來說卻不是這樣。

例如，如果我們有一個「人類or魔怪」分類器，意外把人識別成魔怪。這只是系統的一個錯誤，不涉及侮辱或者文化因素考量。機器不會明白，人被錯誤的識別為魔怪帶來的侵犯感，遠大於魔怪被錯誤識別為人。這也許就是以人為本的偏見。：）

在機器學習中，需要有意識地在準確率和召回率之間進行權衡。

也就是說，如果你認為囊括所有的正確答案更重要，那意味著也會包含更多的錯誤答案（優化召回率）；如果想讓錯誤答案最小化，代價是捨棄一些正確的答案（優化準確率）。

例如，你在Google Photos中搜索操場，可能會看到如下結果：

其中包括一些兒童玩耍的場景，但不在操場上。在這個案例中，召回率優先於準確率，找到所有的操場照片更重要。

5. 有計劃的進化

最好的機器學習系統，應該隨著用戶的心智模型不斷進化。

當人們與這些系統交互時，他們也在影響和調整著這個系統未來的輸出；而這些調整反過來又將改變用戶和系統交互的方式……（子子孫孫無窮匱也）

當然這種不斷的反饋循環，既有可能是良性的，也有可能是惡性的。所以你需要注意引導用戶，給出有利於自己和模型的反饋。

良性循環的一個例子就是谷歌輸入法的Gboard，他能不斷的進化並預測用戶下一步要輸入什麼字，使用系統建議的人越多，給出的建議就越好。

Gboard示意圖

機器學習系統都是用現有數據集訓練而成，並會根據新的輸入進行調整，但這些改變在發生之前都很難預測。所以我們需要同步調整用戶研究和反饋策略。這意味著在產品周期中進行提前規劃縱向、高個性化以及廣泛的研究。

你需要規划出足夠的時間，隨著用戶和用例的增加，對準確率和召回率進行量化測量，來評估機器學習系統的性能。當然還需要和用戶坐在一起，了解他們如何使用系統，以及成功或者失敗背後的心智模型。

另外，我們需要考慮如何在整個產品生命周期內，獲得用戶的真實反饋，以改進機器學習系統。能否設計出更好、更快的交互反饋模式，是良好的機器學習系統與優秀的機器學習系統之間的區別。

Google app隔段時間就會詢問某個頁卡是否有用，以獲取相關的反饋意見

用戶可以對Google搜索自動完成功能提供反饋，包括為什麼預測的結果不合適等

6. 用正確的標籤訓練演算法

當我們談交互時，已經習慣於把線框、mockup、原型和紅線作為標誌可以交付的成果。

然而，當我們談到機器學習增強的交互時，還得指定更多，因為「標籤」來了。

標籤是機器學習的重要組成部分。

很多人的工作就是查看大量的內容，然後打上標籤，例如標註出一張圖片上是否有貓。一旦有足夠的照片被標記為「貓」或者「非貓」，就形成了一個數據集，可以用來訓練模型識貓。更準確一點說，是讓模型以一定的置信水平預測一張照片中是否有貓。

很簡單，是吧？

你能通過這個測驗么？

真正的挑戰在於，讓模型預測對於用戶來說非常主觀的東西，例如是否對一篇文章感興趣或者提供電子郵件的回復建議。

而且模型訓練需要很長的時間，獲得一個完全標記的數據集可能非常昂貴，而錯誤的標籤還會給產品帶來巨大的負面影響。

該怎麼辦？

可以先從合理的假設開始，並且對這些假設進行廣泛的討論。

這些假設通常採用這樣的形式：「對於在（某）情境下的（某）用戶，我們假設用戶更喜歡（這個）而不是（這個）」。然後儘快把這些假設放到原型里，收集反饋進行迭代。

建議為你的機器學習找一個外援，例如在相關領域有深入研究的專家。

接下來，你會發現哪些假設看起來更加「真實」。但是在大規模收集數據和打標籤之前，最好讓專家挑選一些真實用戶數據進行關鍵的第二輪驗證。

用戶應該測試一個高保真的原型，感覺到在與一個AI進行交互。

通過這些實操驗證，可以讓專家創建一個AI功能的示例組合。然後把這些案例作為後續收集的路線圖，進而生成一套強大的訓練數據集，以及大規模的標籤協議框架。

7.擴展思維，發揮創意

作為一個產品經理，可能都會得到一些令人抓狂的微調反饋，可能都有一些你再也不想打交道的工程師。

具體到機器學習這件事上，有一些微小的建議供參考。

對於一個機器學習的產品經理來說，規範太多可能會導致無意的錨定，進而束縛了工程師的創造力。要相信他們的直覺，鼓勵他們不斷試驗，即便整個框架還不完整也可以開始用戶測試。

機器學習是一個更具創造力和表現力的工程。但訓練一個模型可能很慢，可視化的工具還不是很好，所以工程師在最終調整演算法時，經常需要靠想像力……

所以產品經理需要一直幫助工程師走在以用戶為中心的道路上。

攜手合作，共創未來

要用不同的方法給工程師以啟迪，要溫和的給出批評意見，要幫助他們深入的理解產品原理和目標。

工程師越早展開迭代，機器學習體系的魯棒性可能越好，你就越有可能推出具有影響力的AI產品。

結論

以上是我們在Google內部強調的七個要點。希望對於正在或者想要開發機器學習產品的你有所幫助。隨著機器學習開始驅動越來越多的產品，我們更應該以人為中心，為人們提供獨特、有價值、極好的產品體驗。

作者：

Josh Lovejoy，Google研究和機器學習小組UX設計師

Jess Holbrook，Google研究和機器學習小組UX經理和UX研究員

插圖 by Akiko Okazaki

【完】

一則通知

量子位讀者5群開放申請，對人工智慧感興趣的朋友，可以添加量子位小助手的微信qbitbot2，申請入群，一起研討人工智慧。

另外，量子位大咖雲集的自動駕駛技術群，僅接納研究自動駕駛相關領域的在校學生或一線工程師。申請方式：添加qbitbot2為好友，備註「自動駕駛」申請加入~

招聘

量子位正在招募編輯/記者等崗位，工作地點在北京中關村。相關細節，請在公眾號對話界面，回復：「招聘」。

掃碼強行關注『量子位』

追蹤人工智慧領域最勁內容

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