熟悉資料開發的施主一定知道，一個可傳遞的算法模型從需求到釋出要經曆資料擷取、特征工程、模型建立、結果檢驗和最終上線的過程。
那聊到靈活，順應當下迅速變化着的市場，我們在期待遠期大而全的服務的同時，一定也希望近期小而美的逐漸實作，而不是颠覆性的重造。就像伏爾泰所說的"完美是優秀的敵人（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會将此已知案例放置在最高的模型庫下。
基于不同案例對于不同模型的映射與反哺關系，我們就大概可以知道在不同行業或企業下的不同模型的比對情況，進而加深我們對行業的認識了。