在決定要引入機器學習專案的時候，第一個要思考的問題就是，這個服務應該要從外面買？還是要自己建一個？(buy or build)。這個問題從管理層面、技術層面與商務層面切分。

管理層面

從管理層面出發，思考的則是(1)有沒有團隊(2)團隊的能力是否足夠(3)優先順序。

這三點通常會在一開始，就幫這個問題定下清楚的界線。
(1)有沒有團隊
除了資訊產業的公司之外，許多傳統產業、媒體、法律、房地產等產業，不見得都有自己的技術團隊。也有一些公司，只雇用商業以及行銷人員，做最核心的決策，將所有技術工作都外包到合作廠商身上。那這樣這一題的答案就會很清楚的歸向：購買。

(2)團隊的能力是否足夠
在有資訊團隊的狀況下，內部也需要權衡幾項事情。專案展開的急迫性有多高，相關資料、人力(devops、資料科學團隊)是否都已經準備好可以展開專案。相對應的決策，有可能會需要展開招募，有可能需要做內部訓練等等。這時候，專案的優先順序，和團隊的擴展擇依照各公司而定了。

(3)優先順序
ML專案對公司來說的急迫性，跟想要執行的原因是為什麼？因為競爭對手已經開始了，所以要跟進？因為想讓自己的公司保持在業界的領先位置？不管是基於甚麼原因，跟公司內部的專案比起來，ML的專案是立即性的會展開嗎？且目前的開發團隊是否有其他更重要、影響力更大的專案在身上，這些專案的優先順序是短期內可以更換的嗎？這些問題可能都帶領到下兩個層面去做思考。

技術層面

上可以切分成3個層面(1)系統面(2)服務底層架構面(3)模型與資料面。

(1)系統面
你可以跟一個軟體服務商購買推薦系統。公司提供使用者跟公司產品的相關數據，對方的API將自動回傳適合的推薦品項ID，讓你可以用在系統上。又或是你自己建一個推薦系統的服務，讓這些使用者跟產品互動的數據留在自家。

(2)服務底層架構
你可以自己公司有一個機房跟主機群，建立一個自己的工作集群，將服務部署在上面。抑或者選擇託管服務，將工作負載放在雲服務上。可以省去管理這些機器、附載、安全性等問題的力氣。

(3)模型與資料層面
可以考慮是要(A)使用別人已經預先訓練好的模型(完全不用展開任何訓練，直接用模型結果)、(B)遷移學習(使用別人的模型架構，並固定模型大部分的參數，只訓練少部分的參數)、(C)重新訓練(使用別人的模型架構，不使用裡面的所有參數，重新訓練所有的參數)、又還是(D)自己設計模型架構(從模型架構開始重新架構，當然參數也重新訓練)。

商務層面

除了這3點技術考量之外，做出此決定的主要標準是“新系統對公司的價值”和“企業願意對其進行的投資”這兩項的比較，也就是大家常聽到的ROI。在這樣的大方向之下，則可以去把整個流程切為四個階段：

＊圖片來源：Machine Learning — Build vs. Buy (or Sell and Optimize)

(1)購買：各種雲和 SaaS 提供商提供了許多 API服務，例如圖片分類、文本處理、語音識別、機器翻譯等。這些 API 基於非常龐大的資料集以及計算資源所建構。一方面相對單一公司來說很難構建，另一方面，這些服務的情境大多是通用的，不會因為所在的產業而有很大的變動，即便因為產業跟領域的獨特性，也是可以在一開始透過這些通用API達成大方向的效益。在這個圖表上也顯示，當購買的時候，對公司來說內部的報酬是有限的，因為自己處於一個服務使用者的角色。

(2)建構：那什麼時候開始適合建構自己的模型呢？當通用的API讓公司開始了解，如何與一個ML產品合作之後，自然會發現(A)通用模型可能在自己的領域上表現不是這麼完美，在同一個使用情境上，想用自己的資料，訓練出一個更專注於這個領域的模型(B)公司想要展開更多的ML專案，而這個專案跟通用的使用情境可能是不同的。這時候就必須建構自己的模型。

(3)獲利：在購買以及建構的階段之後，公司也已經跟ML產品有了多次的迭代。甚至可以將如何在某某產業中使用某某ML產品這樣的經驗、服務賣出去。從自己公司的核心業務出發，這些商業的核心問題是模型或系統是否可以推廣以滿足各種的客戶問題。

(4)優化：不管最後這個產品是對內、對外，都可以在ML的使用情境上面優化。對內，替公司加速拉開與其他對手公司的距離。對外提供服務給使用者，也讓自己的服務在使用者的心佔率中提高。

結論

也因此，公司是要買一個，還是建構一個。一方面取決於，公司的人力資源配置。一方面取決於公司的資料狀況。一方面也取決於ML專案與公司的商業模型合作之後，會是在市場的哪一個階段，想要執行的動機有哪些。希望這篇文章看完，能夠讓你對於buy or build有更清楚的方向。

[1]. Machine Learning — Build vs. Buy (or Sell and Optimize)