如何設計和管理AI產品?

什麼是AI和ML?為什麼AI產品管理比一般軟體更困難?

Bastiane Huang
Nov 22, 2019 · 10 min read

<給產品經理的 AI 開發指南>文章當中,我們討論了管理AI產品所需要的基礎認識和挑戰。 對產品經理(PM)來說,AI或ML(機器學習)產品管理比一般軟體更具挑戰性,因為它涉及更多的不確定性。不僅需要技術上的改變,還需要組織上的改變。

簡單舉例說明,如果你想教機器識別貓。透過軟體工程,你可能會列出像是「一隻貓有四條腿和兩個尖尖的耳朵」這樣的規則。規則越明確,越完整越好,因為機器必須依賴這些規則來做出判斷。

相反的,如果你使用深度學習,要做的就不是提供明確的規則。而是要為機器提供一堆照片(事先標記好哪些是貓?哪些不是?),然後建立ML模型或神經網絡,讓機器自行學習,摸索出規則。

(source: IBM Research Blog)

你和你的團隊要做的是:定義問題,準備數據,建立機器學習模型,反覆測試和調整,直到你擁有可以提供所需結果的模型為止。

正因為開發ML產品需要更多的反覆試驗,作為一個PM,你需要給工程師和資料科學家更多的空間和時間去探索。

但是你如何幫助你的團隊應對不確定性?如何在明確定義問題和衡量成功標準的同時,又給團隊足夠彈性進行實驗探索?以下這幾件事很重要:

1. 規劃:從明確定義問題開始。

ML是一種工具,是達到目標的方法之一。如果你要解決的問題不需要ML,就不應該使用ML。我們要從確定問題開始: 找到有市場需求,技術上可行的客戶痛點。先進行市場評估,找出客戶需求。

接下來:則是判斷ML是否可以幫助我們解決使用者的問題。機器學習有許多可能的應用,但原則上, 機器學習最適合用來進行決策或預測。 我們可以將ML應用分為幾種類型:

  • 檢測/檢查 (detection/inspection):幫助使用者識別缺陷或異常,例如銀行或保險的欺詐檢測,或生產線上的產品缺陷檢測。
  • 模式識別 (pattern recognition): 幫助使用者篩選大量數據。包括推薦,排序,個人化,分類,預測維護,以及人機互動;例如針對Alexa或Google Home等智慧音箱進行自然語言處理(NLP)
  • 高維認知 (high dimension cognition): 幫助使用者篩選,處理大量高維感官數據。例如:人工智慧機器人、自動駕駛汽車。

在以下情況下,你應該避免在產品中使用機器學習:

  • 可以用更簡單的規則解決問題。
  • 正在構建的解決方案不需要因應新數據而改變。
  • 無法取得訓練ML模型所需的數據。
  • 的產品要求高精度,不能容許任何一點出錯。
  • 產品需要資訊完全透明。

找到正確的問題後,下一個重要任務就是明確定義需求。

開發ML產品是一個需要迅速迭代(iterative)的過程。常會聽到有人說「我們先建一個ML模型,再看看結果如何」,但如果跳過了「事前計劃」和「定義問題」的步驟,最後可能反而會浪費整個團隊大量的時間,而得不到具體結果。

2. 定義「目標函數」和「指標」,保留更多空間和彈性。

ML產品不需要我們事先編寫規則;而是由機器自動從大量的數據中分析規則。與一般的軟體工程相比,它更具實驗性及不確定性,所以很難預測哪些方法有效、哪些無效。 這就是為什麼在決定最終解決方案之前,必須給工程師和資料科學家更多的空間和時間去探索。

作為產品經理,你可以藉由以下方法,幫助團隊在廣泛的探索過程中保持專注:

(1) 定義一個目標函數 (objective function):你的ML模型試圖預測的期望結果是什麼?或者你還在嘗試辨識出資料中的固定模式?有什麼「已知事實」(ground truth)可以用來比較模型的結果、並判斷準確性?例如你設計了一個模型來預測天氣,就可以比較預測結果與實際天氣數據,來驗證模型的性能。

(2) 定義性能指標 (performance metrics):如何衡量產品的成敗?設置驗收標準並不總是那麼容易。你會如何比較「翻譯模型」和「人工翻譯」的準確度?有時需要先查看模型的初步結果,才能確定標準為何;但最重要的,是儘早開始思考測試標準、並且不斷測試模型,直到找出預測結果令人滿意的ML模型為止。

(3) 儘早並頻繁地測試ML模型 (end to end testing): 你可以將ML模型看作一個黑盒子;定義模型的輸入和輸出,但不一定瞭解盒子裡的神經網路如何運作。這就是為什麼儘早、並且儘可能頻繁測試很重要;從簡單的原型(prototype)開始測試關鍵功能,然後進行修改。重點是,盡量避免在驗證好模型的關鍵功能前,就試圖建構太複雜的解決方案。

但需要注意的是,模型本身的準確性通常並不是最好的衡量標準。

我們必須同時考慮測量精確度Precision(true positives/all positive predictions)和召回率Recall(positive predictions/all true positives);精確度是「多少個選定項目的相關性」,而召回率則是「選定多少個相關項目的相關性」。

這沒有適用於所有情況的經驗法則,所以你需要根據使用者的案例來決定權衡。

3. 從第一天就開始規劃你的數據策略。

訓練ML模型需要大量高品質的數據。在使用大量數據進行訓練時,深度學習的性能會優於舊的算法;因此,從第一天就開始計畫取得數據的策略和途徑就非常重要。

數據可以來自購買、與其他公司合作、從客戶那裡收集、在內部生成、或是僱用第三方來生成或標記數據。同時,你也需要考慮競爭對手在做什麼、客戶和監管機構在想什麼、以及每種策略的相應可行性和成本。

擬定數據策略的責任不在於資料科學家,而在於產品經理,而且公司高層也需要經過清楚定義的競爭策略。

如果你是一家新創公司, 更需要三思而後行:你想進入的市場,是否有產業巨頭掌握了大多數資料?你可能不想在電子商務上與Amazon競爭、或是在位置資料方面與Google地圖匹敵。

所以,你必須找到目前還沒有一家公司能主導客戶資料的藍海市場。

你是否能夠建立可防禦且可持續的數據管道(data pipeline)?如何遵守使用者的隱私政策?如果你的公司在歐盟和其他數據保護法規範圍內營運,則必須熟悉GDPR(通用資料保護法規)的規定。

例如, 根據GDPR,公司需要確保個人資料不僅是合法收集的,而且要防止他人濫用。 因此,作為PM,你需要從產品開發的早期階段就考慮資料保護措施。

PM必須與ML團隊討論,以確定未來需要什麼數據、需要多少數據;同時,也必須讓法務和營運部門等其他相關單位參與。

為機器人和自動駕駛汽車等現實世界應用開發ML產品,帶來了更大的挑戰;所以必須充分利用模擬(simulation)方法、並且注意相關研究領域,包括轉移學習(Transfer Learning)和元學習(Meta Learning),以降低對大量數據的需求、並加快模型訓練過程。

4. 不能只考慮ML。

構建ML產品的過程,其實是跨領域的;而且在大多數情況下,我們開發的並不只是ML模型而已。為了做出完整、可立即投入生產的產品,我們還需要使用者介面(UI)、執行模型預測的軟體、以及硬體的搭配組合。

如果過度專注於ML模型上,而忽略了使用者體驗(UX),產品就不會成功。你需要一個不僅包括ML工程師和資料科學家,還包括數據工程師、軟體工程師、UI/UX設計專家和硬體工程師的跨領域的團隊;此外,還需要與後端工程師合作,以打造出支持ML產品的基礎結構。

作為PM,必須盡量減少不同職能或團隊之間的相互依賴和衝突。如前所述,ML的性質與一般軟體開發完全不同,因此在組織上也應該有所改變。

例如,雖然每日的站立會議(stand-up meetings)可能有助於保持軟體工程團隊的生產力,但對於ML團隊而言,這可能不是最好的時間利用方式。所以,ML開發不僅僅是技術上的改變,還牽涉到組織變革。

作為產品經理,你可以幫助其他團隊瞭解ML產品在本質上的不同、並協助解決潛在的衝突。

PM與內部團隊和客戶的溝通也很重要。ML產品的性能,會隨著時間的推移而提高;但這也代表著,客戶可能無法在一開始就獲得最好的結果。使用者可以接受這一點嗎?

如何減輕使用者的風險、並保證可接受的最低性能?如何設計產品,以降低不確定性、並獲得最好的使用體驗?

5. 投資ML產品的理由。

  • 改善使用者體驗或產品功能:ML可以用來讓產品更個人化、或是客製化;例如讓使用者更容易找到最相關的結果,或是應用ML來提高預測的準確性。這些都是對公司內部或外部使用者(客戶)潛在需求應用的考量。
  • 將流程或重複性任務自動化:公司同仁或客戶是否需要重複執行一些可以自動化的流程?透過自動執行重複性工作,可以節省時間、成本、資源,甚至創造更好的使用體驗。如果流程太複雜,是否可以將部分流程自動化、或幫助使用者更有效率地完成工作?Gmail的「Smart Compose」(字句建議)是一個很好的例子:現在,Gmail可以自動幫使用者完成句子,不需要每次都手動輸入「你好」這類重複的單詞或句子。
  • 開創新的商機: 是否有新的商機或使用者問題,是以往無法解決、但現在可以用ML完成的?例如在倉庫中,貨物分揀通常需要人工完成,因為很難幫機器手臂編寫程式,讓它們識別和處理數百萬種產品;但是有了ML,機器人可以在最少的人工幫助下,自行學會識別各種物體。ML與人工智慧的這種能力,為倉庫機器人打開了龐大的商機。

6. 有些好的PM直覺反而不適用於ML產品。

有時管理軟體產品的方法不一定適用於ML產品。我常會提醒自己以下幾點:

  • 必須清楚認知開發ML和軟體產品之間的區別。要讓單一組織流程適用於所有產品,是不太可能的;必要的時候,你必須調整產品計畫流程(sprint planning)、產品藍圖、甚至整個組織。
  • 不需要太詳細列出產品需求書(Product Requirement Document)上的所有需求,而要著重於定義目標功能和衡量標準,讓ML團隊有更多探索和試驗的空間。
  • 與其在開發過程開始時向ML團隊詢問可能結果,不如與團隊密切合作,儘早開發和測試產品原型。
  • ML只是方法之一,並不一定非用不可。

總結 - 關於管理AI產品,我認為最重要的幾件事包括:

  • ML產品管理比一般軟體更具挑戰性,因為它涉及更多的不確定;不僅需要技術上的改變,還需要組織上的改變。
  • ML最適合用於協助決策或預測。
  • ML產品經理最重要的工作:明確定義問題,確定需求,設定衡量成功的標準,並為ML工程師提供足夠的空間和時間探索解決方案。
  • 從第一天就開始計畫數據策略。
  • 構建ML產品是跨領域的,牽涉到的職能並不只是機器學習而已。

想看更多文章嗎?點這裡追蹤我!

感謝閱讀!如果希望看到其他相關的主題也歡迎留言!
如果你喜歡這篇文章,請給我 1–19 個拍手;
如果想看更多關於產品管理的文章,請給我 20–50 個拍手!
如果文章對你有一點啟發或幫助,請長按拍手按鈕(max50)讓我知道 👏每週我都會定期更新產品經理或機器學習相關文章,點這裡追蹤我!✨

Bastiane Huang 目前在舊金山擔任 AI/Robotics新創公司產品經理,專注於開發機器學習軟體,用於機器人視覺和控制。她擁有近10年產品及市場開發管理經驗,並在美國《機器人商業評論》及《哈佛商業評論》發表文章及個案研究。如果你也對Robotics 2.0(AI-Enabled Robotics)、產品管理、Future of Work有興趣,請點這裡追蹤她

UXeastmeetswest

We are four passionate UXers from Taiwan, working across…

Bastiane Huang

Written by

Machine Learning, Product Management, Robotics 2.0: AI-Defined Robotics, Tech x Business ✉ bastiane.substack.com Silicon Valley Startup, Harvard Business School

UXeastmeetswest

We are four passionate UXers from Taiwan, working across China and the U.S. We share our thoughts and work experiences to the Chinese audience, giving back to the community. UX四神湯是四位臺灣清華畢業的UX海外工作者所建立的內容平台,每週定期發布文章。內容涵蓋中美的工作環境與生活體驗、互聯網巨頭與新創公司的工作內容、設計趨勢、UX實務技能分享等

More From Medium

More on 產品經理 from UXeastmeetswest

More on 產品經理 from UXeastmeetswest

More on 產品經理 from UXeastmeetswest

想成為產品經理嗎? 分享3種轉職PM攻略。

More on 機器學習 from UXeastmeetswest

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade