如果你喜歡哲學(xué)并且你是一個 IT 從業(yè)者，那么你很可能對軟件哲學(xué)感興趣，你能發(fā)現(xiàn)存在于軟件領(lǐng)域的哲學(xué)之美。本文我們就從軟件哲學(xué)的角度來了解一下亞馬遜云科技的拳頭級產(chǎn)品?Amazon SageMaker，有兩個出發(fā)點：一是 SageMaker 本身設(shè)計所遵循的軟件哲學(xué)；二是從軟件哲學(xué)的角度我們應(yīng)該如何使用 SageMaker 提供的功能。SageMaker 是一個全托管的機器學(xué)習(xí)平臺（包括傳統(tǒng)機器學(xué)習(xí)和深度學(xué)習(xí)），它覆蓋了整個機器學(xué)習(xí)的生命周期，如下圖所示：

亞馬遜云科技開發(fā)者社區(qū)為開發(fā)者們提供全球的開發(fā)技術(shù)資源。這里有技術(shù)文檔、開發(fā)案例、技術(shù)專欄、培訓(xùn)視頻、活動與競賽等。幫助中國開發(fā)者對接世界最前沿技術(shù)，觀點，和項目，并將中國優(yōu)秀開發(fā)者或技術(shù)推薦給全球云社區(qū)。如果你還沒有關(guān)注/收藏，看到這里請一定不要匆匆劃過，點這里讓它成為你的技術(shù)寶庫！

我們從如下的幾個方面來展開討論：

• 天下沒有免費的午餐——權(quán)衡之道
• 簡單之美——大道至簡
• 沒有規(guī)矩不成方圓——循規(guī)蹈矩
• 沒有“銀彈”——對癥下藥
• 變化之本——進化本質(zhì)
• 知其所以然——心中有數(shù)
• 保持一致性——質(zhì)量可控

天下沒有免費的午餐——權(quán)衡之道

軟件有很多的品質(zhì)（品質(zhì)也叫非功能性需求）：性能（比如時間性能，空間性能，模型性能），可用性，易用性，可擴展性，兼容性，可移植性，靈活性，安全性，可維護性，成本等。一個軟件沒有辦法滿足所有的品質(zhì)，因此我們在和用戶交流的過程中，要真的弄清楚用戶想要的是什么（沒有想象中那么簡單），哪個或者哪些軟件的品質(zhì)是用戶當前最關(guān)心的。很多軟件品質(zhì)經(jīng)常會互相制約（一個經(jīng)典的例子就是安全性和時間性能，安全這個品質(zhì)就是一個讓人又愛又恨的東西，一般來說需要加入安全性的時候，在其他上下文不變的情況下，基本上時間性能就會變差了），所以我們需要權(quán)衡，而在權(quán)衡的時候一定要把握好“度“。

對于 SageMaker 來說：

• SageMaker Processing job 要求數(shù)據(jù)的輸入和輸出都需要在 S3，基本原理圖如下：

SageMaker Processing job 提供了托管的單個實例或者集群來做數(shù)據(jù)預(yù)處理，特征工程以及模型評估。如果你的原始數(shù)據(jù)并沒有存放在 S3，這個時候你需要權(quán)衡空間性能與可托管性（可托管性的好處是很多運維的工作就不需要你關(guān)心了，交給了亞馬遜云科技來運維），是把數(shù)據(jù)從源拷貝到 S3 來使用托管的 Processing job 服務(wù)還是就地來用自建的集群來處理；如果你的原始數(shù)據(jù)本身就存放在 S3，那么直接用 Processing job 來使用 SkLearn 或者 SparkML 來進行數(shù)據(jù)預(yù)處理或者特征工程是你的首選。

• SageMaker 的內(nèi)建算法對數(shù)據(jù)輸入格式的要求以及可配置的有限的超參數(shù)。SageMaker 提供的內(nèi)建算法（SageMaker 對常見的 ML 任務(wù)基本都提供了一種或者多種算法）對數(shù)據(jù)輸入格式的要求以及提供的超參數(shù)可能與開源界的算法的數(shù)據(jù)輸入格式和提供的超參數(shù)略有區(qū)別。這里你需要權(quán)衡易用性與靈活性：如果你只是想實現(xiàn)一個 ML 的任務(wù)并且不想關(guān)注算法的實現(xiàn)細節(jié)，那么可以優(yōu)先嘗試 SageMaker 的內(nèi)建算法；如果你想更深入了解算法的實現(xiàn)細節(jié)以及更靈活的超參數(shù)設(shè)置，那么建議的選擇是把你的算法或者開源的算法遷移到 SageMaker 中。
• SageMaker 訓(xùn)練時的 HPO 自動超參數(shù)優(yōu)化功能的使用。自動超參數(shù)優(yōu)化的初衷是為了減輕算法工程師/數(shù)據(jù)科學(xué)家/應(yīng)用科學(xué)家們手工調(diào)參的痛苦。SageMaker 的 HPO 自動超參數(shù)優(yōu)化對于內(nèi)建算法和非內(nèi)建算法都支持，并提供了貝葉斯搜索和隨機搜索兩種方式供你選擇。不是所有的算法都需要走自動超參數(shù)調(diào)優(yōu)，需要權(quán)衡模型性能（就是指模型效果）與成本。一般來說，對于深度學(xué)習(xí)模型或者海量數(shù)據(jù)集的情況下可能做自動超參數(shù)調(diào)優(yōu)的時間代價和成本代價太大。因此在實際的 ML 項目中，用戶很少對深度學(xué)習(xí)模型或者海量數(shù)據(jù)集做自動超參數(shù)調(diào)優(yōu)；對于傳統(tǒng)的機器學(xué)習(xí)模型并且在數(shù)據(jù)集不大的情況下，可以考慮用自動超參數(shù)調(diào)優(yōu)來找到可能的最優(yōu)解。
• SageMaker 內(nèi)建的 inference pipeline 的數(shù)據(jù)流。SageMaker Inference pipeline 可以把多個容器（容器中可以跑特征處理邏輯或者跑模型 serving 邏輯）串接起來，它的目的是把推理時的特征處理模塊和模型串接起來，或者把多個模型做成上下游串接起來。它的數(shù)據(jù)流是這樣的：

也就是說，每個容器的輸出由 SageMaker 內(nèi)部組件做中轉(zhuǎn)，該組件把上一個容器的輸出做為新的 request 發(fā)送到下一個容器。通過使用 Inference pipeline 這個功能可以簡單方便的實現(xiàn)模型的上下游串接或者特征處理模塊和模型的串接，但從上面的數(shù)據(jù)流可以看到會帶入一些延遲，這個時候你需要考慮延遲是否在可以接受的范圍內(nèi)并使用 Inference pipeline，也就是需要權(quán)衡易用性與時間性能。

• SageMaker 中對于 Tensorflow 和 Pytorch 兩種框架都提供了多種訓(xùn)練方式。訓(xùn)練方式包括開源框架原生的方式以及 SageMaker 專門實現(xiàn)的針對這兩種框架的數(shù)據(jù)并行和模型并行兩種方式。SageMaker 的數(shù)據(jù)并行訓(xùn)練方式適合每個 GPU 卡可以跑完整的模型訓(xùn)練但是數(shù)據(jù)集是海量的情況；SageMaker 的模型并行訓(xùn)練方式適合單個 GPU 卡無法直接跑模型訓(xùn)練的情況（比如模型太大了）。也就是說，在海量數(shù)據(jù)集大規(guī)模訓(xùn)練或者超大模型訓(xùn)練的場景，使用 SageMaker 的這兩種專有的訓(xùn)練方式比框架原生的訓(xùn)練方式會更高效，但是使用 SageMaker 的數(shù)據(jù)并行和模型并行的訓(xùn)練方式的話，對于框架的版本有要求并且需要一定的代碼修改，因此需要你權(quán)衡代碼的可移植性與時間性能。

簡單之美——大道至簡

“簡單”可能的含義有很多，比如精簡，簡樸，可讀性好等?！昂唵巍钡亩攘繕藴士赡苊總€人的理解都不一樣，但是一個通用的原則是，“您”在設(shè)計軟件的時候盡量多想著：“軟件需要別人來用，還需要別人來迭代和維護”，您一定要高抬貴手?！昂唵巍钡膶α⒚婢褪恰皬?fù)雜”，業(yè)界的共識是通過降低復(fù)雜度來得到高質(zhì)量長生命期的軟件，而如何降低復(fù)雜度是每個軟件設(shè)計人員以及開發(fā)人員無時無刻需要關(guān)注的事情。

在 SageMaker 中的體現(xiàn)：

• SageMaker 是基于 container 的設(shè)計，到目前為止沒有選擇 Kubernetes。在當前業(yè)界大興 Kubernetes 的情況下，SageMaker 并沒有隨大流。Kubernetes 的功能很強大但是很復(fù)雜，對于 SageMaker 來說，很多 Kubernetes 的功能用不上，那么為了減少軟件依賴以及降低復(fù)雜度，SageMaker 選擇了更輕量的設(shè)計（殺雞真的沒有必要用牛刀）。
• SageMaker high level API（high level API 指的是SageMaker Python SDK，這個 API 的使用習(xí)慣類似常見的 ML 框架比如SKLearn）設(shè)計很簡潔，類層次也很清晰（分層就是一種降低復(fù)雜度的方法），很多 feature 通過簡單的參數(shù)設(shè)置就能搞定。比如通過簡單的設(shè)置distribution 參數(shù)就把底層復(fù)雜的分布式環(huán)境部署隱藏掉了（信息隱藏也是降低復(fù)雜度的一種方法），讓 API 調(diào)用者的關(guān)注點更集中在訓(xùn)練腳本本身；比如簡單的設(shè)置模型的 S3 保存位置，SageMaker 就會幫助你在訓(xùn)練結(jié)束或者訓(xùn)練中斷時把對應(yīng)目錄下的模型壓縮打包并上傳到 S3 指定路徑；比如通過設(shè)置 git_config 參數(shù)，你就可以直接用 github 中的代碼在 SageMake 中來訓(xùn)練，而不需要你關(guān)心代碼的拉取過程。
• SageMaker 提供了多種算法選擇：內(nèi)建算法，BYOS（基于預(yù)置的機器學(xué)習(xí)框架來自定義算法），BYOC（自定義算法設(shè)計并自己來打包容器鏡像）和第三方應(yīng)用市場（在 Amazon Marketplace 中挑選第三方算法包，直接在 Amazon SageMaker 中使用）。而 BYOS 和 BYOC 是 SageMaker 中實際用的最多的兩種選擇。那如何選擇 BYOS 和 BYOC？總的來說，優(yōu)先看 BYOS 是否能滿足需求。BYOS 相對于 BYOC 要容易，需要遷移到 SageMaker 的工作量也少。而選擇 BYOC，常見的是如下的情景：

除了上面這些情景，盡量優(yōu)先考慮 BYOS 的方式，它使用方式簡單，學(xué)習(xí)曲線也相對平緩。

• SageMaker 提供了兩個可用于超參數(shù)的變量 sagemaker_program 和 sagemaker_submit_directory 來幫助你輕松的完成 BYOC 的調(diào)試。前者告知 SageMaker 把這個參數(shù)的值作為 user entry point（就是用戶提供的需要 SageMaker 調(diào)用的腳本），后者則是這個 entry_point 對應(yīng)的代碼以及它所依賴的代碼打包（tar.gz）后的 S3 路徑。通過設(shè)置這兩個參數(shù)，在調(diào)試代碼的時候只是需要把修改后的代碼重新打包上傳就可以，而不是每次都 build docker file，簡單方便而且很節(jié)省時間。

沒有規(guī)矩不成方圓——循規(guī)蹈矩

擁有豐富經(jīng)驗的你可能聽過或者踐行過契約式編程，而契約式編程簡單說就是，你需要按照對方的一些約定來 coding。一般來說，只要是提供給別人使用的軟件/工具，或多或少都會有一些約定。SageMaker 從盡量減少代碼侵入性和最小代碼遷移工作量的思路出發(fā)，提供了很多約定。

在 SageMaker 中的體現(xiàn)：

訓(xùn)練時，數(shù)據(jù) Channel 相關(guān)的約定：

• 訓(xùn)練容器本地路徑相關(guān)的約定，如下圖所示：

我們重點關(guān)注下表中的四種路徑（除了下面這些路徑，訓(xùn)練過程中放置在其他路徑下的文件，在訓(xùn)練結(jié)束后都會被丟棄）：

SageMaker 給容器提供了很多方便使用的環(huán)境變量，包括 SageMaker 相關(guān)的和內(nèi)建框架相關(guān)的。比如 SageMaker 相關(guān)的一部分環(huán)境變量如下：

SageMaker 內(nèi)建的 TF serving 框架的 service side batch 相關(guān)的環(huán)境變量如下：

• SageMaker 內(nèi)建算法對輸入數(shù)據(jù)格式的要求。SageMaker 內(nèi)建算法對輸入數(shù)據(jù)的格式要求可能和開源算法對數(shù)據(jù)格式的要求不同，如果不注意這個，在調(diào)試模型的時候可能會出現(xiàn)比較奇怪的結(jié)果。比如 SageMaker 目標檢測算法對 BBOX 的格式要求如下：對于 json 格式的輸入標注文件， 要求的坐標格式是 [top, left, width, height]，如果你的數(shù)據(jù)集的標注是PASCAL VOC 格式的（xmin，ymin，xmax，ymax）或者是 COCO 格式的（x，y，width，height），都需要做不同的轉(zhuǎn)換；對于 recordIO 格式的輸入文件， 要求坐標格式是相對坐標，[xmin/width，ymin/height，xmax/width，ymax/height]。
• Spot 實例與 SageMaker checkpoint 機制的配合。為了節(jié)省成本，使用 spot 實例進行訓(xùn)練是首選。為了讓 spot 實例被回收對你的訓(xùn)練任務(wù)造成的影響最小化，SageMaker 通過兩個參數(shù) checkpoint_local_path 和checkpoint_s3_uri 來助你一臂之力（當然你不使用 spot 實例，也仍然可以利用 SageMaker 的 checkpoint 機制）。這樣訓(xùn)練 job 被 spot 回收中斷以后并自動重新開始訓(xùn)練后，就不用從頭開始訓(xùn)練了，而是從最新的 checkpoint 開始接著訓(xùn)練（SageMaker 提供了 checkpoint 上傳和下載的機制，你需要修改你的代碼來配合，也就是你需要從約定的 checkpoint local 路徑來初始化你的模型參數(shù)，否則是空談），從而在節(jié)省成本的同時節(jié)省訓(xùn)練時間。

沒有“銀彈”——對癥下藥

可能我們自己腦海中或者遇到過別人問我們?nèi)缦碌膯栴}：對于XX任務(wù)當前哪個模型效果最好？使用 AutoML 是不是就不需要我們做特征工程和樣本工程了？自動超參調(diào)優(yōu)是不是就徹底解放我們的手動超參調(diào)優(yōu)了？如果真的是這樣的話，那就太美好了。在軟件界，“沒有銀彈”這句話流行很久了，對于人工智能領(lǐng)域也是同樣道理，都需要 case by case 來分析每一個目標任務(wù)。

現(xiàn)在 Bert 以及 bert-like 的模型比如 GPT3，T5 等很火，恨不得只要是 NLP 的任務(wù)都用這樣的模型。我覺得還是應(yīng)該至少要考慮具體的目標任務(wù)是什么，目標任務(wù)的建模難度這兩個因素來進行模型選型。如果在語料充足的情況下，做一個簡單的文本分類任務(wù)，這個時候可能用一個簡單的模型比如 fasttext 來就夠用了，而不用 bert 模型做 fine tuning 這么復(fù)雜；如果是針對用戶評論做細粒度情感分析任務(wù)，這個任務(wù)就很復(fù)雜了，用簡單模型就可能不合適了，這個時候用比如 T5 這樣的復(fù)雜模型才合適。盲目的追新和追熱點，受傷的是你的項目（可能你能從中受益）。

對于 SageMaker 來說：

• SageMaker 有內(nèi)建算法，BYOS，BYOC 和 Marketplace 以及新出的 JumpStart 上面的算法可供你選擇，總有一款適合你。很有意思的一個現(xiàn)象是，SageMaker 在剛發(fā)布的時候 bulid 了17種內(nèi)建算法，很多年過后一直也沒有在增加新的內(nèi)建算法。我猜測 SageMaker 的開發(fā)團隊會認為，即使不斷的增加一些內(nèi)建算法，也沒有辦法及時對主流的一些算法進行跟進。正是因為針對任何一種細分場景，沒有包治百病的“算法”，SageMaker 就不在內(nèi)建算法上花費更多的時間和精力，它提供更靈活的 BYOS 和 BYOC 讓用戶把開源的算法方便的遷移過來，或者通過 Marketplace 讓買家和賣家都能嘗到使用算法的甜頭。
• SageMaker 提供了 Autopilot 和 Auto model tuning（即自動超參數(shù)調(diào)優(yōu)）這樣兩種 AutoML 機制。AutoML 一直是一個很熱門的研究方向，也是我們?nèi)祟惡芷诖囊粋€能大量落地的方向（誰不喜歡簡單省事就能完成一項任務(wù)呢？）。如果每個目標任務(wù)都可以用 AutoML 來解決的很好，那么大部分人都可以騰出時間來攻克別的技術(shù)難題了。雖然 Autopilot 可以直接對結(jié)構(gòu)化數(shù)據(jù)來建模，它也能自動做一些特征處理，但是它并不是銀彈，不是什么數(shù)據(jù)集直接丟給它就能出一個不錯的效果的；要使用 Autopilot，自己提前做一些特征工程可能效果會更好（比如特征縮放，特征生成，特征交叉，甚至不同的缺失值處理方法，異常值處理等）。

而對于自動超參數(shù)調(diào)優(yōu)，如果使用默認的超參數(shù)搜索空間，時間成本和金錢成本太大，那么還是需要人工首先限定每個需要搜索的超參數(shù)的區(qū)間的左右端點，同樣這里沒有“銀彈”，左右端點的確定要么根據(jù)已有的經(jīng)驗，要么就是通過實驗來大致選取。一定不要無條件的使用 Autopilot 或者自動超參數(shù)調(diào)優(yōu)來解決你的問題，三思而后行！

變化之本——進化本質(zhì)

為什么要考慮“變化”？設(shè)計之初就應(yīng)該考慮到將來的可能變化，也就是說系統(tǒng)框架要設(shè)計的比較有彈性（就像亞馬遜云科技的很多服務(wù)那樣彈），對于將來的需求的改動不會付出很高代價。在軟件設(shè)計中，經(jīng)常會談到“面向變化編程”，即永遠不要假設(shè)需求不變，現(xiàn)實中需求大大小小經(jīng)常變。變化是創(chuàng)新的必經(jīng)之路，永恒不變的東西只有變化。

在 SageMaker 中的體現(xiàn)：

• SageMaker 早期的版本提供了 SageMaker-container 包供你使用來創(chuàng)建 SageMaker 兼容的容器和自定義的框架。后期的版本，為了讓基于 SageMaker-container 包的容器鏡像盡量更小更內(nèi)聚，SageMaker 把這個 SageMaker-container 包拆分為 sagemaker-training toolkit（專為訓(xùn)練的容器）和 sagemaker inference toolkit（專為推理 /serving 的容器）兩個包來瘦身。
• 隨著不斷的進化，SageMaker 現(xiàn)在是一個完全自洽的全生命周期的機器學(xué)習(xí)平臺。在早期的時候，SageMaker 只有三大核心功能：訓(xùn)練，推理（離線推理和線上推理），notebook 實例。為了能把ML生命周期中的數(shù)據(jù)預(yù)處理，特征工程，模型評估這些功能也納入，SageMaker 后續(xù)推出了 Processing job 來做這些事情。而隨著很多用戶對于多種機器學(xué)習(xí)任務(wù)的高質(zhì)量標注需求的上升，SageMaker 推出了帶有人工標注和機器自動標注的 Ground Truth 功能（這里又體現(xiàn)了客戶至上的企業(yè)文化）。而隨著 SageMaker Studio（它是用于機器學(xué)習(xí)的集成式開發(fā)環(huán)境 IDE，可讓你構(gòu)建、訓(xùn)練、調(diào)試、部署和監(jiān)控機器學(xué)習(xí)模型）的推出，以及 MLOps 的更多功能的加入，現(xiàn)在的 SageMaker 變成了“超人”（短時間能增加如此多的功能并且還保持健壯，正是因為 SageMaker 的設(shè)計基因就是面向變化的）。

知其所以然——做到心中有數(shù)

我們可能知其然，但是所以然知道了嗎？可能有些感興趣的東西我們會去了解其深層的原因，但是軟件的問題我們?nèi)パ芯苛藛?#xff1f;軟件是枯燥的，很多時候我們都是作為謀生的手段來應(yīng)付之，因此不知所以然也就很正常了。但是如果您是要真正的學(xué)習(xí)東西，或者更好的服務(wù)于用戶，最好還是”再深一點“。

對于 SageMaker 來說：

• SageMaker 相關(guān)的代碼比較分散，為了滿足好奇心可以去閱讀源碼。比如有 SageMaker 平臺相關(guān)的開源代碼包 sagemaker-container，sagemaker-training，sagemaker-inference；與內(nèi)建框架相關(guān)的開源的代碼比如 SageMaker tensorflow training，SageMaker tensorflow serving；SageMaker Python SDK 的開源實現(xiàn)代碼。通過閱讀這些代碼，你會對 SageMaker 如何工作有更深刻的理解。
• 當訓(xùn)練文件的數(shù)量比較多的時候，SageMaker Pipe mode 和 File mode 哪種方式訓(xùn)練 更快呢？拿Tensorflow 的 tfrecorddataset API 來舉例，在其他的 dataset API 基本一樣的前提下，File mode 更快（這個在多個實際用戶項目中測試過）。主要的區(qū)別就是 pipemodedataset API 和 tfrecorddataset API。tfrecorddataset API 可以設(shè)置 num_parallel_reads 來并行讀取多個文件的數(shù)據(jù)，還可以設(shè)置 buffer_size 來優(yōu)化數(shù)據(jù)讀取。 Pipemodedataset API 則沒有類似上面的參數(shù)來加速數(shù)據(jù)的讀取。也就是說 Pipe mode 更適合讀取文件數(shù)量不多，但是每個文件都很大的場景（除了這里提到的 Pipe mode 和 File mode，SageMaker 訓(xùn)練的數(shù)據(jù)讀取方式還提供了 FastFile mode；SageMaker 訓(xùn)練支持的數(shù)據(jù)源除了 S3，還包括 Amazon Elastic File System 以及 Amazon FSX for Lustre，詳細內(nèi)容可以參考官方博客）。
• SageMaker Endpoint for TFS vs for Mxnet/Pytorch 的內(nèi)建serving 框架復(fù)雜性對比。SageMaker Endpoint for TFS 的介紹如下：

SageMaker Endpoint for Pytorch serving 的介紹如下（SageMaker Endpoint for Mxnet serving 是類似的）：只使用一個組件 torchserve，它的特點是，直接支持鉤子函數(shù)；支持處理 /ping REST API；缺省會使用所有的GPU來做推理（而單個 TFS 進程只使用一個 GPU 來推理）。

保持一致性——質(zhì)量可控

一致性是降低系統(tǒng)復(fù)雜度有利的手段。如果一個系統(tǒng)保持一致，意味著類似的事情用類似的方法去做，降低了認知負荷。在ML機器學(xué)習(xí)領(lǐng)域，我們經(jīng)常會談到一致性，比如效果線上線下一致性（如果模型離線效果好，模型上線以后表現(xiàn)不好，這就是發(fā)生了效果線上線下不一致），特征的線上線下一致性（特征的線上線下不一致是效果線上線下不一致的一個常見原因；特征的線上線下不一致指的是線下訓(xùn)練時樣本中的特征的特征值可能會發(fā)生變化，并不和該樣本在線上生成時的特征值完全一樣。關(guān)于特征的線上線下一致性更詳細的討論請參考我的另一個文章）。保持一致性是模型質(zhì)量可控的一個重要因素。

對于 SageMaker 來說：

• 使用 SageMaker Processing job 對訓(xùn)練集做的一些特征工程比如某個特征 Z-score 標準化，那么為了讓預(yù)測時與訓(xùn)練時有一致的特征工程，需要如何處理呢？在對訓(xùn)練集做了某個特征的 Z-score 標準化以后，用到的該特征的均值和方差這些 metadata 需要保存起來（SparkML 和 Sklearn 都有相應(yīng)的 API 把這些 metadata 以文件的形式保存起來）；然后利用 SageMaker Inference pipeline 在第一個容器中把之前保存的 metadata 文件加載進來對原始特征進行 Z-score 標準化處理之后再送入第二個容器即模型推理容器。
• 如果在模型 serving 的時候，能及時知道每個特征的分布是否和訓(xùn)練時的數(shù)據(jù)集尤其是驗證集的分布是否基本一致，對于模型才更可控。而 SageMaker 的 model monitor 的一個重要功能就是監(jiān)控特征的統(tǒng)計漂移，如果模型在生產(chǎn)過程中接收到的數(shù)據(jù)的統(tǒng)計性質(zhì)偏離了訓(xùn)練所依據(jù)的基準數(shù)據(jù)的性質(zhì)，則模型將開始失去其預(yù)測的準確性。Model Monitor 使用規(guī)則檢測數(shù)據(jù)漂移，并配合 Amazon 其他服務(wù)在發(fā)生數(shù)據(jù)漂移時向您發(fā)出警報。下圖說明了此流程的工作方式：

總結(jié)

本文從軟件哲學(xué)角度來介紹了 SageMaker 的一些設(shè)計思想以及如何使用 SageMaker 的一些功能?？傮w來講，不管你是否考慮采用 SageMaker 作為你的機器學(xué)習(xí)平臺，至少它的這些實現(xiàn)的思路以及設(shè)計哲學(xué)都是可以用來參考的。SageMaker 作為全球使用量最大的機器學(xué)習(xí)平臺，是值得你花時間來好好研究和探索以及實踐的。關(guān)于 SageMaker 更多詳細和更多深入的內(nèi)容請參考我的?github。感謝大家的耐心閱讀。

本篇作者

梁宇輝

亞馬遜云科技機器學(xué)習(xí)產(chǎn)品技術(shù)專家，負責(zé)基于亞馬遜云科技的機器學(xué)習(xí)方案的咨詢與設(shè)計，專注于機器學(xué)習(xí)的推廣與應(yīng)用，深度參與了很多真實客戶的機器學(xué)習(xí)項目的構(gòu)建以及優(yōu)化。對于深度學(xué)習(xí)模型分布式訓(xùn)練，推薦系統(tǒng)和計算廣告等領(lǐng)域具有豐富經(jīng)驗。

文章來源：https://dev.amazoncloud.cn/column/article/63098fa80c9a20404da79138?sc_medium=regulartraffic&sc_campaign=crossplatform&sc_channel=CSDN