熟悉資料開發的施主一定知道，一個可交付的演算法模型從需求到釋出要經歷資料獲取、特徵工程、模型建立、結果檢驗和最終上線的過程。

那聊到敏捷，順應當下迅速變化著的市場，我們在期待遠期大而全的服務的同時，一定也希望近期小而美的逐步實現，而不是顛覆性的重造。就像伏爾泰所說的"完美是優秀的敵人（Le mieux est I'ennemi du bian）"，誠然周全的規劃，嚴密的論證，精確的設計確實可以做出既實惠又時髦的產品。但是企業發展不是一個砸鍋賣鐵追求完美的過程，而是在保持持續運作的前提下循序漸進的發展，最終的系統一定有一些老舊的元件會帶來運維以及與其他元件的磨合問題，但這也是需要在日後的發展中逐漸升級和磨合的。

同樣，現實中資料開發工作的目標也不是為了遠期的一個覆蓋所有場景、可以自學習，引數嚴密的演算法模型，而是在建模時不斷考慮新資料來源、修正演算法、調整引數、模型分片和新增欄位的開發過程。舉一例項來說，我們知道線性的資料開發應該是從需求理解到資料置備到建模到驗證最後到上線的過程。

但是在Salesforce這樣的體量的公司，幾乎每個客戶都需要獲取從智慧潛客篩查、行為分析、使用者旅程預測到機會分析等十幾種資料模型。如果SaaS服務商需要為每一個客戶都建立一套演算法模型，那這樣的SaaS一定有其產品的侷限性，而Salesforce所要面對的是全球十五萬的客戶群。作為一家專注做CRM服務的頭部公司，這麼多年下來在獲客的每一個環節上多少會有一些判斷的沉澱。

這樣的沉澱在Salesforce內部有一套製品庫-TransmogrifAI （https://transmogrif.ai），用於對所有開放案例進行自學習。相應的，新客戶會簽訂協議開放部分內部CRM的案例供SalesForce分析，在這部分案例尚不足以建立起該客戶自己的分析模型時，TransmogrifAI會先提供同業的模型，隨後在慢慢提高客戶自身模型的加權值。

上圖描繪了Salesforce的資料架構模型，全部功能模組都已微服務化；公司的資料科學團隊可以共享特徵庫和模型服務；TransmogrifAI可以識別不同的前端場景進行匹配的模型自學習。剖析其技術元件，它是一套基於Scala開發的全開源資料模型工具，由OpenNLP提供自然語言處理、Lucene提供全網搜尋，Tika提供元資料識別，Spark提供實時處理，Algebird提供分類加總，Avro提供資料序列化。由此資料科學家僅需關注新特徵、新模型的研究和驗證即可。

由於目標資料都是結構化資料，所以系統內部僅需維護好資料字典表，將不同的案例輸入傳給不同的特徵場景即可。

當然如果在一個特徵場景中只有一個演算法模型，自學習的意義對我們評價模型好壞就意義不大了，因此根據最終模型的匹配度，TransmogrifAI會將此已知案例放置在最高的模型庫下。

基於不同案例對於不同模型的對映與反哺關係，我們就大概可以知道在不同行業或企業下的不同模型的匹配情況，從而加深我們對行業的認識了。

原文連結：https://developer.aliyun.com/article/780383