業內較為常見的人工智能規劃流程是CRISP-DM，這個流程確定了一個數據挖掘項目的生命週期。
移動互聯網的產品設計流程，通常要經歷需求調研、需求分析、功能設計、視覺設計、編碼測試幾個階段。圍繞的重心是智能手機設備，對於產品的功能流程設計是否合理，用戶交互是否順暢，界面設計是否美觀有著較高的要求。
如下圖所示：
移動互聯網產品規劃流程
但是，在人工智能產品設計中，核心的重點不再是手機界面，而是對於業務的理解。
對數據的理解和對算法的理解，這就要求我們在進行產品規劃的時候，將設計的重點從手機界面轉變為以圍繞業務目標的數據為核心。
目前，業內較為常見的設計流程是CRISP-DM（Cross-Industry Standard Process for Data Mining，跨行業數據挖掘標準流程）。
CRISP-DM跨行業數據挖掘標準流程
在1996年的時候，SPSS，戴姆勒-克萊斯勒和NCR公司發起共同成立了一個興趣小組，目的是為了建立數據挖掘方法和過程的標準。並在1999年正式提煉出了CRISP-DM流程。
這個流程確定了一個數據挖掘項目的生命週期，包括以下六個階段：
- 商業理解：瞭解進行數據挖掘的業務原因和數據挖掘目標。
- 數據理解：深入瞭解可用於挖掘的數據。
- 數據準備：對待挖掘數據進行合併，彙總，排序，樣本選取等操作。
- 建立模型：根據前期準備的數據選取合適的模型。
- 模型評估：使用在商業理解階段設立的業務成功標準對模型進行評估。
- 結果部署：使用挖掘後的結果提升業務的過程。
這套流程沒有特定工具的限制，不論是使用SPSS這類圖形化的數據挖掘工具，還是python這類可用於數據挖掘的編程語言都可以。
也沒有特定領域和行業的侷限，是適用於所有行業的標準方法論，相對於其他的數據挖掘方法路，CRISP-DM具有靈活和適用範圍光的優點。
需要特別注意的是：雖然這套數據挖掘流程的完整生命週期包含六個階段，每一個階段都依賴於上一個階段的產出物，但是這六個階段的順序卻並不是固定的。尤其是商業理解和數據理解，數據準備和建模階段可能經常出現反覆循環的過程。
是否可以繼續進行下一個階段取決於是否有達到最初的業務目標，如果業務目標沒有達到，那麼就要考慮是否是數據不夠充分或算法需要調整，一切都以業務目標為導向。
那麼，接下來，我們用一個電商案例來看一下：如何在實際工作中運用這套流程？
商業理解
海微購是一家從事跨境電商業務的創業公司，公司在前幾年抓住了海淘的趨勢，用戶量和交易額都還不錯。在新的財年，公司希望能在去年的基礎上將GMV提高10%，並以此為目標制定新一年的工作計劃。
1. 確定業務目標
首先，需要先確定業務目標。
根據電商零售額公式（零售額=流量轉化率客單價*復購率），公司認為：在獲客成本較高的市場環境，以及本公司經營的海淘產品復購週期較長的情況下，應優先提高轉化率和客單價兩項指標。根據SMART目標制定原則，確定下一次迭代的產品目標為：猜你喜歡模塊中的商品點擊量需提高20%，交叉銷售額提高10%。
2. 確定數據挖掘目標
第二步，需要將業務的問題轉化為一個數據挖掘的問題。
根據業務目標，我們可以將其轉化為以下幾個數據挖掘問題：
- 聚類問題：構建大數據用戶畫像，形成用戶的商品偏好標籤體系，用於商品精準營銷和消息推送。
- 預測問題：構建用戶流失預警模型，預測用戶的流失可能性，對可能流失的用戶進行挽回關懷，防止流失。
- 分類問題：結合用戶日常消費額度和信貸記錄，向用戶推薦符合其購買力或購買習慣的商品，提高轉化率和客單價
- ……
在制定數據挖掘目標時，需要明確數據挖掘的問題是一個分類問題，聚類問題還是一個預測問題，以便於後續的建模階段選擇合適的算法。另外，還需要確定的是數據挖掘的範圍，是針對所有用戶大範圍調整，還是先針對小規模的部分用戶進行A/B Test，待驗證成功之後再全面推行。
如果前期有相關的經驗或數據積累，最好在這一階段定義清楚數據挖掘成功的標準是什麼，例如：推薦的準確率要提高40%，或用戶的流失概率降低20%等，通過可量化的指標評估整個工作的效果。
3. 制定項目計劃
第三步，明確好目標之後，就可以根據具體的，可量化的方案組織相關的干係人來評估工作量。根據工作量倒排項目計劃表，將目標拆解到更小的時間顆粒度，並指定相關責任人進行任務跟進，如下圖所示：
在這個階段需要明確各個環節的交付產物，並識別可能的項目風險，提前制定風險應對計劃。
例如：本公司缺乏某方面的數據，需要從外部獲取，或者相關人員配置不足，需要招聘或借調人力資源的支持等等。在項目進行的過程中持續監控，以確保項目的正常進行。
數據理解
明確了業務目標之後，我們需要針對數據挖掘的問題收集相關的數據，並對數據進行初步的處理，目標是熟悉數據，探索數據與數據之間的內在聯繫，並識別數據的質量是否有問題。
1. 收集數據
數據理解的第一步是收集數據。
根據來源的不同，數據可以分為內部數據和外部數據兩類，根據數據的類型又可以拆分為：用戶數據和商品數據。
海微購公司的產品經理通過排查發現：公司目前已經通過埋點收集到了用戶在web端和APP端的行為數據，且平臺售賣的商品有專門的人員負責打標籤的工作，內部數據較為完善。但是，還缺乏用戶對於平臺上未售賣商品的偏好數據以及用戶的人口屬性數據。
針對這一點，海微購公司的產品經理決定組織一次用戶有獎問卷調研活動。通過問卷調研的方式，抽樣選取用戶進行問卷填寫，成功的收集了用戶對於平臺未售賣商品的偏好數據以及人口屬性數據。
另一方面，通過網絡爬蟲數據，爬取了競爭對手平臺的所有商品銷售量，並根據銷售單價推算出了總的銷售額，完善了現有的數據體系。
2. 數據標註
海微購公司所擁有的數據並不只有數據庫中已經結構化了的數據，他還擁有很多非結構化的數據，例如：商品的圖片數據，客戶與客服的通話語音數據等等。
這些非結構化的數據並不是直接用於建模，而是需要先進行數據標註，將其轉變為計算機可以識別的數據格式。
例如：如果對商品的圖片進行了結構化標註，建模階段就可以通過圖片識別技術對新上線的商品進行自動分類和打標籤，甚至自動生成商品的廣告海報圖片。如果對通話語音進行了數據標註，就可以為後續的人工智能客服提供語義數據，降低公司成本，提高服務效率。
3. 描述數據
當數據準備充分之後，需要對數據進行描述，以供後續階段使用。主要包括對數據量的描述，數據值類型的描述以及編碼方案的描述。
不同的算法對於數據量的大小有一定的要求，雖然越大的數據集可以生成更為準確的算法模型，但是同時也會增加計算的時間。所以，標註數據量的大小可以讓算法工程師在建模之前決定是使用全部的數據集，還是從一個大的數據集中分出若干個小的子集來進行建模。
建模的數據可能有多個來源，且收集數據的人和負責建模的人可能不是同一人，所以在建模之前務必對數據的類型進行描述。數據的類型有多重，例如：數值型、分類型、布爾型、時間等等。標註清楚數據類型可以加快後續建模階段的效率，防止數據類型的錯誤而導致出現問題。
在數據庫中，常常使用不同的數值來表示不同的數據特徵，例如：海微購公司的用戶來源可能來自地推、線上獲客、朋友推薦、自主下載等多個渠道等。
這些渠道類型在數據庫中可以用文字來進行表示，也有可能用1234的數字來表示，在數據描述中需要特別註明這一類的數據及其對應的含義，以便後續階段能正確的使用這些數據。
數據準備
數據準備是數據挖掘最重要的階段之一，通常這一階段所花費的時間和工作量佔整個項目的50%-70%。
如果產品經理在前期對於業務理解非常準確，數據理解也非常充分，那麼將極大的減少數據準備階段的工作量，提高工作的效率。
1. 選擇數據
在第一步選擇數據階段，需要做兩件事情：第一是在所有的數據中選擇哪些數據作為訓練集，哪些數據作為測試集；第二是選擇參與建模的特徵字段有哪些。
以海微購公司為例：公司希望提高提高推薦的準確度和銷售額，那麼需要通過用戶畫像，選擇典型的主要客戶——例如：最近有過購買記錄，並且在一定時間內持續活躍的用戶。而不能選擇已經流失的，或者是從來沒有購買記錄的無效客戶。
對於參與建模的特徵，需要選擇那些與業務目標息息相關的數據，以購買商品轉化為例：從業務經驗來看與之相關的數據有用戶的月均消費額度、用戶的商品偏好、商品的曝光率、好評率等等。
當然，也有一些基於統計學的方法可以幫助我們選擇數據，例如：相關係數，卡方檢驗，T檢驗等等，我們在特徵工程的章節會詳細的講到這些方法是如何使用的。
2. 清理數據
數據準備的第二步，是對數據進行清理，在實際的工作中，收集的數據不一定是100%準確無誤的，常見的數據問題有：缺失值，錯誤值，離群值，編碼不一致和無效數據。
例如：用戶的年齡信息與是否購買某些商品有非常強的關係，但是用戶的年齡信息對於用戶本身來講不是一個必填的信息。所以，商家不一定能獲取到而造成缺失值。另外一種可能就是用戶未填寫真實的年齡，導致年齡出現負數或大於200的數這類錯誤值。
還有一些數據，例如用戶的身高數據，如果絕大多數用戶的身高在1.5米到1.9米之間，但是並不排除有一些用戶的身高可能低於1.5米或高於1.9米。這類數據並不是錯誤數據，而是離群值，這類離群值量級較少，不是主要客戶特徵，但如果不加以排除直接參與到建模階段，就有可能對建模造成一定的負面影響，比如：影響正常的平均值或極差。
編碼不一致的問題也經常出現在數據中，例如：很多數據在低於1萬的時候，顯示的是具體的數值，而高於1萬之後就不再顯示具體的數值，而是顯示成x.x萬這樣的格式，造成格式編碼不一致的情況，在建模之前需要將所有數據處理為統一的單位和格式。
數據的正確性會直接影響後續建模階段的模型效果，所以在數據準備階段需要將這些問題數據進行處理，最簡單的方法就是直接刪除有問題的數據。但如果數據的量本來就比較少的話，也可以通過一些統計學的方法對數據進行修復或插補，例如：均值填補法處理缺失值，蓋帽法處理離群值等等。
3. 構建新數據
在數據挖掘中，有一些數據可以通過其他的數據轉化而來，例如：如果獲取到了用戶的身份證信息，就可以根據身份證的生成規則知道用戶的籍貫地址，生日以及性別。知道了用戶的手機號，就可以通過手機號的歸屬地查到用戶所在地；知道了用戶的常用收貨地址，結合房產數據，可以推測出用戶大致的月收入。
除了對已有數據進行轉化，還可以通過人工定義的方式將一些用戶的事實行為通過規則轉化為新的數據，例如：將月均平臺消費超過1萬的定義為高消費客戶，將月活躍天數大於15天的定義為高活躍用戶等等。
4. 數據降維
建模速度與數據的量級成正相關，數據量越大，建模的時間也就越長。我們在數據準備階段，可以通過數據降維的方式減少數據特徵，減少數據中的特徵數量的同時，避免丟失太多信息並保持模型性能，以此達到簡化計算量的目標。
數據降維的另一個目的是對數據進行可視化，我們生活在一個三維的世界中，但如果數據的維度大於三維，就無法進行可視化了。而通過降維將數據降為三維或二維的數據，並保持數據之間的關係，就可以通過肉眼來觀察數據模型的效果了。
建立模型
到了這個階段，之前的工作終於可以有所回報了，我們可以運用算法對前幾個階段準備的數據進行建模，看是否可以達到我們期望的結果。
建模的過程通常會執行多次，使用多個不同的算法和參數，因為在實際工作中，只是用一個算法且僅執行一次運算就能圓滿的解決業務需求。這樣的情況幾乎是不存在的，正常的情況是我們可能需要在數據準備階段與建立模型階段之間反覆多次，以確保業務目標達到最佳的效果。
1. 選擇建模算法
第一步，我們需要根據業務目標選擇適合的算法，在前文我們提到過算法分為有監督學習和無監督學習兩種。根據業務目標的不同，又可以分為：分類算法，聚類算法或預測算法。
算法的選擇並不一定是越複雜的算法效果就越好，最終的效果取決於訓練的數據以及設置的算法參數，所以我們可以在建模的時候，將適合的算法都嘗試一次，根據結果來進行選擇。
2. 訓練集評估
第二步，在選擇好使用哪種算法之後，我們需要選擇與訓練集對應的測試集數據，並對算法的結果定義一個明確的評價標準。
對於有監督算法，通常使用模型的正確率來進行評估，而對於無監督算法，我們通常是根據結果是否易於解釋，是否易於部署以及算法運行的時間等標準來評估
3. 構建模型
第三步，是真正建模的過程，在這個階段根據算法的不同，可能需要對算法的參數進行調整，例如：KNN模型中調整K的值，或者深度神經網絡算法調整隱藏層的數量等。
在每次調整算法參數並實際生成模型之後，我們需要根據在上一步定義的評價標準，記錄模型的結果數據。這些結果數據將用來與其他的算法，以及同一個算法不同參數間的比較，確定最佳算法和參數。
這聽起來是一件非常瑣碎且耗時的事情，事實也確實如此，但是感謝技術的發展，大多數調參的過程都可以通過計算機自動完成，不需要人來值守。而且，通過集成算法的運用，我們可以同時使用不同的算法來對數據進行建模，我們在後面還會詳細的講到。
模型評估
至此，我們的項目已經完成了絕大多數的工作，在開始最後的部署階段之前，最重要的事情是徹底的評估模型，根據在商業理解階段定義的業務目標來評估我們努力的成果。
1. 評估結果
最終的算法模型結果有可能達成了我們最初的業務目標，當然也有可能沒達成。
達成了當然是一件好事，但如果沒達成也不一定是一件壞事，就像愛迪生髮明燈泡試驗了一千種材料，失敗了一千次也並不認為自己是失敗了。他說：“我只是證明了這一千種材料不適合做燈絲而已。”
數據挖掘沒有達成業務目標的結果，也不一定意味著建模的失敗，有多種可能性導致不成功的結果。
例如：業務目標一開始定得不夠合理，與業務目標密切相關的數據未收集到，數據準備出現了錯誤，訓練數據和測試數據不具備代表性等等。這時候我們就要回到之前的步驟，來檢視到底是哪個環節出現了問題。
2. 審核過程
就像每個項目結束之後都需要進行復盤一樣，在一次數據挖掘項目迭代之後，也需要對過程的成功之處和不足之處進行總結——回顧每個階段的任務與關鍵的決定，看看每個階段所做的事情對於最終的結果是否有所貢獻？有沒有什麼方法是可以簡化或者改善某一階段任務完成情況？有沒有什麼不足之處，是可以在下一次迭代時進行改進的？有沒有什麼導致失敗的問題是可以在下一次提前預測到並且避免的？
3. 確定後續步驟
無論成功或失敗，到現在都已經生成了最終的結果，那麼就應該考慮一下：接下來該做些什麼了？
一般會有兩個選擇：
- 如果成功了，那麼就進入最後的結果部署階段，將數據挖掘的結果併入到產品的業務目標中。
- 如果沒有成功，那麼可以返回前面的步驟重新設定業務目標或重新收集數據進行建模，有過一次失敗的經歷之後，有極大的可能發現失敗的原因，並在下一次的建模中避免失敗。
當然，我們還可以選擇其他方式來達成業務目標，畢竟一切的技術都是為了業務目標服務的，人工智能也並不是萬能的，根據業務專家設置的規則或從產品運營角度也能提高業績。
結果部署
建模的作用是從數據中找到知識，獲得的知識需要以便於用戶使用的方式重新組織和展現，這就是結果部署階段的工作。根據業務目標的不同，結果部署簡單的可能只需要提交一份數據挖掘報告即可，也有可能複雜到需要將模型集成到企業的核心運營系統當中。
1. 制定部署計劃
根據業務要求和運算性能的的不同，部署的模型可分為：離線模型，近線模型和在線模型三種。
離線模型一般適用於重量級的算法，部署於大數據集群倉庫，運算的時間需要以小時計，並且時效上通常是T+1的。
近線模型適用於輕量級算法，一般在內存和Redis(一種支持Key-Value等多種數據結構的存儲系統，適用於高速消息隊列)中進行，運算的速度以秒為單位。而在線模型則通常根據業務規則來設置，在內存中運行，運行的速度以毫秒計。
另外，部署還需要考慮不同編程語言對於算法模型的調取兼容性，在這個階段算法工程師需要與原有業務的開發工程師進行聯調協作，確保業務系統能夠正確的調用算法模型結果。
2. 模型監督和維護
我們知道算法模型是基於歷史數據得來的，但是在模型部署並運行一段時間之後，可能業務場景已經發生了變化，原有的模型已經無法滿足當前的業務需要。這就需要我們在模型部署上線的同時，同步上線模型的監督和維護系統，持續跟蹤模型的運行狀況。
當發現模型結果在出現短期異常值時，排查異常的原因，例如：運營活動或者節假日等因素，當發現模型長期表現不佳時，則要考慮是否是用戶和產品的數據構成已經發生了變化。如果是因為數據構成已經發生變化，則需要重新通過CRISP-DM流程構建新的模型。
3. 生成最終報告
最後，不要忘了向項目的相關干係人發送一份最終的項目總結報告。
不論是在項目過程中一起並肩作戰的同事，還是對項目關心的領導，都需要了解項目的最終成果。一個項目的成功，總離不開每個人的努力，常懷一顆感恩的心才能讓一個團隊走得更遠。
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
