在Dialexa，我們與企業和初創公司合作，從頭開始設計，構建和部署成功的數據驅動產品。數據驅動型產品的核心是基於智能引擎，該引擎利用數據自動執行決策。
舉例來說，這是一個競標在線廣告展示位置的平台。這是一個平台，需要以他們想要顯示的廣告，一些可選的硬出價限制和可配置的侵略性因素的形式進行一些人工輸入。系統本身可以由機器學習代理驅動，該代理可以進行出價，監控廣告的點擊率，並可能對自身進行在線調整以優化出價模式。
以產品為中心的數據科學和機器學習帶來了一系列全新的挑戰，典型的數據科學項目並未受到限制。在以產品為中心的項目中，數據科學家與設計師，軟件工程師和產品所有者的多學科團隊合作，確保他們的模型與業務目標保持一致，在系統的約束下創建，並在敏捷的時間框架內交付。
多年來，我們已經看到了多個項目的一些常見情景，並積累了一些關於如何降低風險，快速交付價值以及為未來制定可靠計劃的技術。
以下是那些希望構建數據驅動產品的人的一些建議。
儘早獲取和分析數據
成功的機器學習和數據科學產品依靠數據生存和消亡。在Kaggle比賽和一些學術研究領域，數據清晰，可訪問，值得信賴，並且足夠豐富，可以訓練模型。然而，工業數據科學數據通常是無格式的，嘈雜的，並且受到嚴格管理。
我們面臨的最大挑戰之一就是削減繁文縟節，以便掌握正確的數據集。企業在他們的倉庫中閑置着數據寶庫，但在您的團隊和數據之間有多個部門（法律，IT，治理），他們需要批准轉移，購買訪問權限的潛在談判過程以及團隊數據工程師在數據傳輸到您的團隊之前完成數據合同。
如果不能訪問這些數據，數據科學家只能推測他們可以用它做什麼。無法正確地假設此數據已準備好進行建模，甚至無法獲得達到目標KPI所需的信號。儘早獲取數據可讓團隊在深入了解可能不可行的建模路徑之前返回快速反饋。
我們建議使用簡短的「價值證明」階段啟動每個數據驅動的產品。這是一個小團隊完成獲取所需數據的基礎，使用初始幼稚模型建立基線，並根據該模型設置可達到的模型KPI。這是一種低風險的方法，可以通過少量資源來驗證您正在解決的問題。
理解最終用戶
當您構建產品時，您實際上正在構建一個工具來解決最終用戶利用的問題。用戶以多種方式工作並與產品交互。數據驅動的產品將重點放在從模型接收建議的過程中，並提供模型反饋以供學習。要構建成功的數據驅動產品，首先要了解您的用戶計劃如何與您的產品進行交互，他們希望從模型中看到什麼，他們對輸出有什麼控制，以及他們如何向系統提供反饋，這一點至關重要。
Web應用程序空間通過大量整合研究階段，完善了成功產品的設計流程。此階段通常包括構建角色，通過移情映射和進行用戶訪談來了解用戶和機器。此階段的輸出是產品所有者可以信賴的界面設計，以及工程師（和數據科學家！）團隊可以執行的界面。
在Dialexa，我們成功地將以數據為中心的提示和問題注入到這些工具中，以深入了解用戶實際需要的模型。這些新的數據點為數據科學家提供了指標，模型架構的要求，以及他們可能從未考慮過的許多新功能！
產品智能功能的一個很好的例子是AirBnB的上市價格建議。可以在研究階段發現的這個功能的一些重要內容是：
- 這只是一個建議，讓用戶控制最終價格
- 他們給出了選擇價格的主要因素
- 它們允許用戶直接反饋他們的定價模型
這個功能並不完美，並且因其他投訴中的定價清單而受到批評。可以通過再次理解用戶的顧慮來解決這些問題。我相信根據反饋，這個功能有很多方面需要改進。獲得用戶信任的一種方法是投資一個模型，該模型在決策中輸出置信區間。他們可能不得不犧牲一些準確性，但是，只要它仍然可以接受準確，最終用戶可能會對整個功能感到更滿意。
理解你的模型
就像最終用戶一樣，模特也需要愛。這些模型不是獨立的 – 整個團隊必須在同一頁面上，以便工程師可以編寫支持軟件，設計人員可以使用線框UI，利益相關者可以設置他們的交付期望。在建立模型或基於模型的功能之前，通過收集需求來讓整個團隊在同一頁面上是至關重要的。
我們採用的方法之一來自我們的研究和設計團隊。我們已經調整了用戶移情地圖以同情基於模型的功能。這是一篇很好的文章，深入描述了這個過程。練習的要點是讓團隊思考該功能，並記下以下內容：
- 感官 – 模型需要哪些數據和變量？
- 是 – 模型輸出和採取的操作是什麼？
- 說 – 用戶如何知道模型做出決定的原因？
- 想一想 – 該功能必須遵循哪些硬性規則？
- 感覺 – 我們如何知道該功能正在做我們期望的事情？
這些是我們對我們團隊運作良好的類別的解釋。像「說」和「感覺」這樣的類別可能特別難以包圍。我們通過提供類似功能的示例，讓團隊開始思考正確的方向。例如，AirBnB價格建議工具的一些便簽可能是：
感官
- 租用單位的位置數據
- 上市日期
是否
- 建議價格
- 一系列優惠的價格
說
- 該地區的類似房源
- 定價因素細分
想
- 不能低於最低收支平衡價格
- 有法律方面的考慮嗎？
感覺
- 來自該工具的直接用戶反饋
- 用戶是否在此範圍內？
此會話的輸出是對此功能的所有玩家的共同理解和一系列明確要求。在高層次上，數據科學家可以開始設計模型架構，工程師可以為新數據源和API端點規劃工作，設計人員可以對組件進行線框化，產品所有者確切知道將要交付的內容。多麼令人難以置信的運動！
從簡單開始，擴展複雜性
在產品團隊中，數據科學家的工作很多時候都是其他團隊成員工作的依賴。後端工程師無法有效地開發和測試軟件以支持他們的模型，直到他們可以訪問它。除此之外，產品所有者可能希望儘快推出用於beta測試的功能，而不是團隊可以優化模型。
在這種情況下採取的第一個也是最重要的行動是與您的團隊溝通。記錄預期的輸入和輸出，以便解決模型何時準備就緒的問題。這應該在模型移情地圖之後以高級別刷新！下一個要考慮的選擇是不使用機器學習模型或大幅簡化方法。
對於經驗豐富的機器學習工程師來說，應對產品團隊最困難的現實之一是機器學習是達到目的的手段，而不是目的本身。作為一名機器學習工程師，他喜歡閱讀和了解該領域前沿的進展 – 我很難寫出這一點。但實際上，大多數功能都是通過簡單的模型甚至是啟發式成功支持的 – 您不需要深入學習來解決每個問題。
快速部署一個簡單的模型，或者至少是模型的界面，可以解除團隊其他人的阻礙，讓他們的齒輪轉動。工程師可以放心地從該模型開始快速開發，利益相關者可以監控產品中模型的KPI，並在可接受時打開完整功能。
再舉一次AirBnB價格建議模型。在定義完整功能之後，團隊可以使用周圍區域的平均列表價格來構建和部署快速啟發式引擎。工程師可以開發出基於啟發式的模型並將其隱藏在功能標誌後面，等待在生產中打開。同時，數據科學團隊，中小企業和產品所有者可以一起工作以迭代模型，直到它準備就緒，然後將其發佈給最終用戶。
這是一個為我們創造奇蹟的過程。我們已經能夠快速迭代越來越多的高級模型，在類似生產的環境中測試模型，並以完全安全的方式發佈模型驅動的功能。
最後的想法
這些只是我們團隊為提供數據驅動產品而採用的眾多技術和流程中的一小部分。在我們渴望分享和幫助其他產品團隊實施的過程中，我們吸取了更多的經驗教訓。回到餐巾紙上
本文轉自medium，原文地址
Comments