AWS機器學習 — 模型訓練

演算法和人類之間的差別在於，如果將相同的資料輸入到演算法中兩次，最後會得到相同的答案，但人類並非如此。

61 min readDec 28, 2021

本文中，我們將會學到有關於機器學習(以下簡稱ＭＬ)演算法，這些演算法可以用在不同的業務問題上。在之前的AWS ML 文章中我們學到了如何 source、 label,、wrangle與清理資料以及設計訓練 ML 模型所需的必要功能。現在我們將介紹在資料上訓練的實際模型本體。我們將在本地(我們的桌機或筆電)討論用於實驗的訓練模型與大型資料集使用分佈式訓練。 ML流程是高度迭代的(iterative)，我們永遠不會將我們訓練的第一個模型投入生產環境。出於這個原因，我們將探索調整模型參數以獲得最佳模型的策略。

常見的ML演算法

ML 的目標是允許我們使用歸納法對資料進行推斷。基於這個原因，一個ML模型需要能夠歸納(generalize) — 意即，對之前沒看過的資料(沒用來train的)進行一個精準推斷。否則，模型只會簡單地記住資料，這不是我們要的結果。根據資料類型，ML 的use case主要分為三類：

監督式學習
這是指當模型顯示基本事實數值(也就是這個數值是真的)的label example並學習根據輸入的資料或特徵預測label時。也就是要用基本事實這個 x值來預測這個label (y 值)。
非監督式學習
這是指我們的資料沒有任何有被標記(label)的資料，而我們要模型在這些未被標記的資料中去探索資料的模式。
強化式(Reinforcement)學習
強化式學習是指模型或agent(例如小精靈遊戲的ML化)通過與其環境交互來學習。強化式學類似於trial-and-error learning，其中agent因採取的行動而獲得獎勵和懲罰，其目標是最大化長期獎勵。

以上這些是大多數 ML 屬於AWS會分出的主要類別，但值得注意的是，半監督學習是 ML 的另一個分支，其中我們有一些labeled data和可用的非結構化資料。

監督式學習

也許我們常在ML領域中遇到最多的是監督式學習，我們的資料中伴隨這一些標籤(label)。在真實案中的這樣的狀況可能包含了信用卡詐欺，信用卡交易資料標誌著"詐欺/非詐欺";房價和商品價格準確率，我們有關於房屋面積、房間數量等的資料。而標籤就是房價;大台北計程車、共享單車的資料，標籤就是租車費用；或許多文件/新聞文章，標籤是新聞標題等等。

Note:
資料類型（無論是結構化還是非結構化）並不決定是否監督式學習。在我們的example中，資料可以是數字資料(交易/車租)或image，也可以是raw text。 標籤的存在與否決定了是監督式學習還是非監督式的。

監督式學習有以下幾種特性:

Binary Classification(二元分類)
標籤是二元的，例如詐欺/非詐欺，狗/貓，垃圾郵件/不是垃圾郵件。
Multiclass classification(多類別分類)
標籤會有兩個以上的類別。
Regression(迴歸)
標籤是一個連續的數字，例如房價。

以下我們討論一些普遍使用結構化資料的監督式學習演算法

線性與邏輯迴歸

線性模型是監督式ML的一種形式，其中模型預測"資料和標籤"之間的線性關係。當我們有一個連續的標籤（regression task）使用線性回歸，其中假設標籤與資料的線性相關。

如果我們有標籤 yi和特徵 x1i…xni，線性回歸假設如下

其中粗體值表示整個大小資料集上的向量 ieN. 這裡 貝它i是模型將學習的係數或權重，算式中最後一個符號對應於noise term，它應該是一個隨機變量。從數學上看就是這種方式，我們的目標是預測係數 貝它i，這將最小化整個資料集的錯誤 (算式中最後一個符號)。

通常使用誤差的平方和作為要最小化的量，也稱為損失(loss)。當使用平方和時，損失通常也稱為均方。下圖顯示了線性回歸的一維範例。

線性回歸模型功能強大，因為它們容易被解釋。然而，這種情況是有代價的：模型做出了多個假設，需要先測試這些假設，然後才能將線性模型準確地融合到資料中。第一個是線性 — — 標籤是輸入資料或特徵向量的線性組合。其次，這些模型假設常數方差(constant variance如下圖) — — 標籤中的統計變量(statistical variance)是相同的，而不管輸入資料的value如何。

此圖顯示缺乏constant variance。顯示為垂直箭頭的誤差項隨著 x 的增加而增長

例如，如果我們要預測房價，無論我們擁有一間臥室還是五間臥室的房屋，房價的差異都是相同的。這種假設經常受到實際資料的挑戰，限制了這些模型的實用性。第三個關鍵假設是特徵之間不能有很強的相關性；在極端情況下，如果兩個特徵是multicollinear的（其中一個特徵可以從另一個線性導出，在最簡單的例子中；它們通過一個常數(constant)相關），那麼之前的線性回歸方程式將會得不穩定。

小提示:
如果我們的資料中有高度相關的特徵，線性回歸模型是否無法使用？我們可以使用稱為”正則化(regularization)”的技術來緩解這種情況。正則化通常用於ML，作為一種懲罰模型的方法，這是因為模型學習權重不能很好的推斷到沒見過的資料。而正則化降低了整體模型的複雜性並防止過度擬合(overfitting)。最常見的正則化形式是ridge（在其中向權重添加 L2 penalty或quardratic penalty）、lasso（向權重添加 L1 penalty或絕對值penalty）和elastic net（將兩者結合起來）。需要注意的是，ridge regression傾向於減少在預測標籤時不重要的權重值，而 lasso 傾向於將權重縮小為零。如果我們有一個具有很多特徵的線性回歸問題，使用 lasso 懲罰作為開始是消除不重要特徵的一個很好的解決方案。因此，lasso regresion也稱為shrinkage。需要注意的是ridge、lasso和elastic net都是不同形式的regression；它們僅在損失函數(loss function)上有所不同。

我們可以看下圖

當 y值大且為負時，它接近 0，而 y 值大且為正時，它接近 1，因此在 [0, 1] 之間

在這個案例中我們是仍然使用線性回歸嗎？當然，我們可以定義新的變數(如下)

現在我們可以看到標籤y在 x2是呈線性的．這通常稱為多項式回歸，是線性回歸的摡括。通過從原始特徵建立多項式來建立新特徵是特徵工程的一個簡單範例。 需要注意的是我們如何使用特徵工程仍然使我們能夠使用簡單的模型，例如線性回歸。通常在ML中，決定模型效能和最終商業價值的不是模型，"而是我們如何設計特徵"。

邏輯回歸是線性回歸在二元或多元分類問題中的應用。因此，邏輯回歸使用所謂的logit函式，其中標籤按以下方式建模：

這意味著我們現在可以將 p 解釋為由以下公式給出的概率

邏輯回歸靠的是概率的簡單閥值(threshold)來解決二元分類問題：假如概率大於0.5, 模型預測一個類別;如果小於0.5就預測另一個類別。為此，它使用稱為 cross-entropy loss損失函數的定義如下：

其中 Pi 是真實概率，p-hat-i 是模型在訓練期間的預測概率。 sum是我們資料集中所有資料點(data point)的總和。

我們可以將其概括為多元分類問題(multicalss classification problem)，不過在此不討論數學上是怎麼做的。只要知道邏輯回歸可以被應用在二元分類與多元分類問題上。無論底層演算法如何，Cross-entropy loss都是 ML 中針對classification problem最常見的損失函數。

最後，從Production的角度來看，與可能非常大（有時幾 GB）的深度學習模型不同，邏輯回歸模型只存儲係數(coefficients)，因此模型可能非常小。通常建議從邏輯回歸等簡單模型開始，然後再轉向更複雜的深度學習或 tree-based 演算法，因為邏輯回歸通常用作模型效能的benchmark。

AWS SageMaker有著內建的演算法，這些演算法包含了線性與邏輯回歸的use case，稱為linear learner。這一個內建linear learner演算法建立在MXNet的框架，識別已知的資料格式，例如RecordIO-wrapped protobuf 。此外由於大多數的檔案格式都是CSV檔，linear learner演算法也可以識別CSV。更多的linear learner資訊可以參閱此文件。

Factorization Machine(分解機)

有時除了資料和標籤之間的線性關係之外，標籤還可能與不同自變量之間的交互項成正比，例如兩個特徵XiXj的乘積。 SageMaker 的分解機演算法在建立模型時會考慮到這一點。 分解機可用於監督式學習的分類和回歸作業。

當我們要處理大型的稀疏(sparse)資料時，可以考慮使用分解機演算法。這通常發生在在廣告行銷上，如clickstream預測或產品的推薦。分解機，顧名思義，通過稱為矩陣分解的方法進行作業，這是推薦系統中的一種普遍做法。

如同 linear learner，分解機也是建立於MXnet框架之上並且也能讀懂RecordIO格式。但不能讀取CSV檔案，因為CSV不適合儲存大量的稀疏矩陣(sparse matrices)的資料格式。AWS建議我們使用分解機用在大量的稀疏矩陣的資料類型。

K-Nearest Neighbors

另一種在結構化資料的監督式學習演算法稱為KNN(k-nearest neighbors)。這個演算法的作業方式是首先在我們資料集建立一個由任意兩個資料點(data point)之間的距離組成的index。當提供了新資料點，它的標籤是未知時，KNN 演算法會根據特定距離計算該點的k-nearest neighbors，並在迴歸(regression)的情況下對這些 k -points的標籤值(label values)求平均值，或者使用最常返回的標籤作為分類標籤。

這個演算法的訓練主要對應於建立index。推論對應於對該index執行快速查找。這裡的index是指輸入資料集中每個資料點的向量呈現，可以快速放到記憶體中，以便之後執行查找分析。需要注意，資料集越大，模型越大。

要有效地執行這個操作，我們首先需要對資料集進行取樣，以便將它放到記憶體中。接下來，我們需要降低資料集的維度數以避免所謂維度的詛咒，它會影響高維空間中的距離測量。通過降低維度，我們還可以使用歐幾里得距離、餘弦距離、曼哈頓距離或其他距離度量有效地測量距離。

取一個高維向量並在低維空間中有效地呈現它的過程通常稱為降維(dimensionality reduction)或壓縮(compression)。在此之後，每個向量(vector)都根據一些相似性度量分配給一個cluster。一種稱為 k-means clustering的演算法經常用在這裡。

現在index 儲存以向量呈現，以及向量所屬的cluster。每個cluster都有一個質心(centroid)，由質心向量呈現。這種存儲資料的方法稱為inverted list。

在推論(inference)或查找(lookup)階段，演算法首先通過將距離與質心進行比較來識別一個點所屬的cluster。然後，在這個cluster內進行第二次相似性搜索，以找到 k 個最近的點來確定最終label。更多KNN的資訊可以參考此篇文件。

SVM(Support Vector Machine支援向量機)

另一個普遍使用的ML模型就是SVM．這個演算法在生物領域，如神經科學，特別流行並在今天很多人繼續使用。

SVM的概念非常簡單：
找到以最寬的(所謂margin)將兩個classes分開的separating hyper-plane。 margin越寬，演算法的質量及其概括化(generalize)能力就越好。

下圖直觀的呈現了 SVM 背後的概念，模型要找到最能將兩個cluster(橘色與藍色)的點分開的實線。

SVM 還可以摡括到分離邊界可能不是線性的非線性情況。這可以通過引入所謂的kernel trick來完成。基本概念是在更高維空間中呈現point，在那裡分離它們變得更容易。但是，針對測試，必須注意非線性 SVM 可用於區分不能被直線分隔的點，如下圖所示。

我們選擇的kernel function必須能夠表示由以下計算式給出的圓(如上圖左邊)

其中r是半徑，而a與b分別代表x與y軸(SVM概念圖)。

Tree-Based Models

另外一種監督式學習是決策樹(decision tree)、隨機森林樹和 XGBoost。我們從單一決策樹開始介紹：
決策樹由root node或parent node組成，並根據特定標準從child node或leaf node中衍生出來。如今，大多數企業使用決策樹作為rule-based system的一部分，其中規則決定是否拆分節點。儘管rule-based system非常普遍並將繼續流行，但為了包含到商業見解，決策樹學習讓tree 學到何時根據輸入資料產生新節點。

有一些普遍的決策樹演算法，最普遍的是CART(Classification and Regression Trees)。 CART 首先使用指標(metric)來決定何時適合將parent node拆分為child node。然後將此規則遞回應用在child node。當無法獲得更多的gain或滿足其他一些條件時，拆分就停止。

哪CART演算法在何時決定拆分parent node呢？有兩個普遍性的指標是 Gini impurity 或 entropy metric。 Gini impurity是對具有特定標籤的資料點會有錯誤分類的概率的量測。用這種方式，它代表了一些關於系統的資訊。下面的公式表示具有 K 個類別的多元分類問題的 Gini impurity：

CART 通過使用greedy演算法來選擇要拆分的輸入變量，並且對於該輸入變量，所有不同的拆分點都會針對 Gini impurity進行評估。然後選擇最低值作為分割點，再來對parent node的每個child node重複該過程。

決策樹有哪些局限性？決策樹的一個常見問題是它們容易過度擬合；這意味著，在極端情況下，每個資料點都有自己的leaf node，並且Tree會變得有很深的分支。這是一個限制，因為在此範例中，我們的決策樹只是學資料，它缺乏對未知資料進行概括化的能力。

為了避免這樣的狀況，我們有兩種方式可以處理：

增加每個leaf的最小數量的point：可以防止tree產生新的leaf，除非leaf代表的資料點數量滿足最小閾值。
Pruing：是指簡單地刪除與分類無關的Tree的部分。

scikit-learn 等框架包含預先建立的 DecisionTreeClassifier 和 DecisionTreeRegressor用於使用決策樹處理二元和多元分類和回歸作業。這些框架還允許我們將tree的max_depth 作為參數進行限制。這還通過確保演算法不會建立非常深的tree來防止過度擬合。決策樹的離散性質自然意味著它們無法輸出原始資料中不存在的標籤。例如，對於迴歸問題，tree輸出訓練資料集中最近的點（屬於tree上的leaf node)．

關於決策樹的另一個觀點是所謂的 bias-variance trade-off。不過在討論這個之前，我們要先討隨機森林樹(random forests)與 XGBoost。

如我們之前提到的，決策樹的侷限性是它會產生過度擬合。而隨機森林樹就是被設計用來解決這樣的問題的，因為它有很多棵樹。每棵樹只使用一種稱為bootstrap aggregation或bagging的方法在輸入特徵的一個子集(subset)上進行訓練。 Bagging本質上是指sampling但會replacement。

為了了解sampling with replacement，假設我們被要求從一個總體資料中隨機抽取 20個個體的樣本。如果我們在不放回樣本的情況下進行抽樣，一旦我們挑選了前 20 個樣本，這會影響下一批 20 個，第一次我們將挑選的前 20 個樣本，將無法再次挑選。通過允許原始的 20 個樣本在隨後的交互中成為sampling pool的一部分，sampling with replacement只是允許不同的樣本相互獨立。也就是每次抽樣之後的樣本都需要再放回總體中。

以這種方式。隨機森林樹試圖通過從特徵子集(subset of feature)進行sampling with replacement來確保不同的樹相互獨立。隨機森林樹然後使用相同的技術來構建樹，例如指定最大樹的深度和/或每個leaf node的最小資料點。然而，最終的預測或迴歸作業是通過平均所有樹的結果來完成的。

而像 scikit-learn 這樣的框架提供了易於使用的package訓練隨機森林樹的 regressors和classifiers。

小提示:
關於在決策樹與隨機森林樹中使用scikit-learn來了解我們如何防止過度擬合的狀況發生是值得我們可以再深入研究的。要記住的一點是，要防止過度擬合，我們在tree上要做的是在每一個leaf去增加minimum samples但最大化的減少樹的深度。

隨機森林樹的效益是可以平行訓練多棵樹。然而，隨機森林樹的一個缺點是不同的樹不能一起作業以減少整體誤差。 這就是sequential learning或 XGBoost 的登場的時候。

XGBoost(如下圖)一樣秉持決策樹的想法 — 即 CART演算法，但不是bagging，而是使用稱為boosting的技術。boosting 指的是 sequential learning，其中每個後續的tree主要在對被其前一個misclassification的錯誤進行準確分類。這也防止了過度擬合，因為每棵樹都可以是所謂的 weak learner或shallow tree，但總體來說，它們可以成為一個強大的learner。

有非常多普遍的boosting 演算法，像是AdaBoost與 Logit Boosting, 這些是gradient boosting(梯度提升)的例子。gradient boosting是指將error terms視為連續變量(continuous variables)並使用泰勒展開式擴展其梯度或derivatives的能力。再加上我們之前討論的正則化技術（L1 和 L2 ），這可能是一個非常強大的演算法。我們還可以利用 GPU 等基礎設施快速計算梯度，這使得 XGBoost 成為當今 ML 中最受歡迎的演算法之一。

SageMaker 提供了一個內建的 XGBoost 演算法，在撰寫本文時，這個演算法可在多個 CPU/GPU 上運行。它可以用於 CSV 和 LIBSVM 資料格式，儘管有一些函式庫可以將我們的資料從 Parquet 轉換為 CSV，以便隨後與 XGBoost 一起使用。 XGBoost 的一個關鍵效益是它能夠擴展到非常大的資料集，這可能發生在常見的 ML 問題中，例如欺詐偵測。更多有關於AWS SageMaker中的XGBoost演算法可參考此篇文件。

Textual Data

表格式資料之後最常見的資料形式之一是非結構化text data。這可能是文件、社交媒體提要（例如新聞文章或 Twitter 提要）或各種基於聊天的應用程式。

越來越多的企業對建立能夠理解這些文件中的自然語言模型感興趣，並被用於建立智能應用，例如金融服務中前台和後台工作的文件分類，改善醫療診斷的醫療文件分類，分析來自新聞和社交媒體提要的發言情緒，分析來自客服應用程式的聊天內容並將它們路由到適當的人類克服或使用 NLP 提供自動回應。

在AWS 的AI與機器學習服務介紹，我們討論了許多可以幫助使用者將 NLP 和智能導入我們應用程式的 AI 服務，例如用於文件處理的 Textract、用於自然語言理解的 AWS Comprehend 和 Comprehend Medical，以及用於將音檔轉錄成文字的 Transcribe。在這一節中，我們將討論一些SageMaker 中的NLP內建演算法。

使用BlazingText於文件分類作業

NLP 的主要突破之一是使用 ML，Google在一系列論文中發布了一種名為 Word2Vec 的架構.

Word2Vec 是一個以兩種方式運行的淺層神經網路演算法。首先，給定一組來自預先指定windows的contextual words的input set — 呈現為token，Word2Vec 主要在預測當前的word。下面是一個例子：

演算法的目標是預測單詞“fox”。另一種方法是預測上下文，給定一個詞；例如，給定一個input word，如 Taipei，演算法預測“is the capital of Taiwan”。這被稱為skip-gram method，而前者被稱為CBOW(continuous bag-of-words)。

在以上任何一種情況下，演算法首先需要定義一個固定的詞彙表，並將我們語料庫（dataset）中的所有句子分解為token。 Token只是機器讀得懂的詞彙表中句子的數學呈現。例如，如果我們的詞彙看起來像這樣:{quick:3, the:7, brown:9, fox: 38, jump:20, over: 11, dog: 6} 那麼我們可以用以下形式呈現例句現在可以將一系列數字輸入模型作為[3,7,9,38,20,11,6].

演算法使用神經網路來學習單詞的嵌入。為此，我們必須傳入帶有標籤的訓練資料集，其中在 CBOW 或 skip-gram 的情況下，標籤分別是token或context。該演算法根據訓練資料集的context將每個單詞嵌入到一個數學向量中 — — 因此得名 Word2Vec。在預測時，這些嵌入用於預測與輸入sequence/word相對應的最接近的詞或詞集（context）。

Word2Vec 變得非常普遍，因為它能夠保留之間的語義關係。例如，諸如“Taipei is to Taiwan what Washington, DC, is to the United states”之類的模式被準確捕捉到。同樣，brother, man, woman, and sister obeys的vector的向量呈現遵循以下關係：

儘管這個演算法如此普遍，但Word2Vec仍然遭受挑戰 — 哪就是它無法有效的在大型資料集被訓練或是使用GPU做訓練。這時就可以使用BlazingText。

AWS SageMaker的BlazingText提供了Word2Vec的高度優化並且使可以使用GPU來訓練，這讓我們可以在一分鐘之內訓練數百萬個詞。更進一步，使用一種稱為character embeddings, 它可以克服Word2Vec另一個限制，哪就是概括以前未見過的詞彙，這是原來Word2Vec做不到的。

BlazingText讓我們在SageMaker上使用skip-gram或CBOW方法來做文件分類作業或簡單的抽取 word embedding來給其他的下游作業程序，並且它也支援使用單一個GPU執行大型資料集的訓練。

我們討論過的很多深度學習演算法都是通過產生某種形式的資料的向量崁入來作業的。針對text，我們可以使用BlazingText演算法;而對image，我們可以使用image classification與object detection演算法; 如果我們要在pairs of objects之間產生embedding，我們可以使用Object2Vec模型。

Object2Vec 是高度客製的，適用於不同類型的資料輸入。它產生輸入的encoding pairs並將它們連接成單一個embedding vector。當我們想要比較相似或不同的items、為recommendation system 抽取user-item pairs的embedding，或者建立product-product pairs, customer-customer pairs, 或sentence-sentence pairs時，這會很有用。

小提示:
哪在文件分類的問題上，何時該使用 Comprehend 或是BlazingText呢？Comprehend model是不能被運用在AWS以外的地方，因為它是一個託管式的服務．而BlazingText model可以託管在SageMaker endpoint上，甚至是 SageMaker以外．

其他自定義的演算法(如BERT)

自2018年後，如Word2Vec這一類的model就不再這麼受歡迎了，而新一類的NLP稱為transformation，其中一種最受歡迎的稱為BERT(Bidirectional Encoder Representations from Transformations)．

BERT 有幾個關鍵進展遠遠超出了本文的範圍，但最重要的是attention mechanism的概念。利用我們在AWS 的AI與機器學習服務介紹中簡要討論過的 RNN 或 LSTM 等演算法的傳統 NLP 模型存在一個問題，即 ML 模型難以理解contextual information。例如，考慮以下句子：

The company financial are strong, and while its shareholders can see a large return on equity in the long term, they may not be able to realize gains in the near term.

儘管人類很清楚”its”指的是公司，而”they”指的是股東，但這對於 ML 模型來說可能很難。 Bert 使用了一個稱為 Transformer 架構的概念。

為了更好地理解這一點，使用機器翻譯作業將英語“I am student”翻譯成法語“Je suis etudiant”．

編碼器(encoder) 對input English token或單詞的embedding以及其在句子中的位置（positional encoding）進行區塊編碼。然後將其提供給一個attention network，這是一個簡單的transformation，它告訴network對於句子中的每個單詞要“attention”句子的哪些部分。

Attention mechanims的數學基礎超出了本文的範圍，但 Bert 還有另一個先進的地方：編碼器模組編碼出一個雙向attention並關注input word之前與之後的詞。

這個編碼器區塊與一個解碼器區塊耦合(couple)，它也由類似的attention layer和 LSTM layer組成，這次編碼法語輸出加上來自編碼器網路的輸入，以預測法語句子中的下一個單詞。

這樣，模型在訓練過程中通過預測句子中的下一個詞來依序學習，一旦模型訓練好，就可以用於任何作業，例如產生text sequence，machine trnaslation，甚至使用編碼進行分類文件、總結文件內容等。

值得注意的是這種 attention的encoder-decoder架構，現在是SageMaker seq2seq(sequence to sequence)演算法的一部分了。當我們需要進行machine translation或文件內容總結時就可以使用這種內建的演算法，或將演講內容轉換為文字。

圖片分析

我們在之前的文章介紹過AWS Rekognition，這是一個可以讓我們使用預先訓練好的(object detection或image classification models)模型或是使用transfer learning或客製的一個從頭開始訓練的image labeling models，而這種預先訓練好使用的資料集是 ImageNet DB。

在SageMaker中，我們可以使用圖片分類演算法，這是一種利用ResNet演算法來訓練一個圖片分類模型(不管是上述說的內建或客製方法)。圖片分析演算法可以看懂 RecordIO或是 raw image的輸入並支援一個或多個 CPU/GPU上訓練。

ResNet 通過一個稱為 shortcut connections的layer之間具有residual connections來摡括傳統的 CNN(convolutional neural networks)。這些connection改善了layer之間的梯度(gradient)流動並防止梯度消失，從而改善模型訓練。

通常的情況是偵測圖片中的object而不是對圖片進行分類。在這種情況下，我們可以使用 object detection 演算法，它會在相關object周圍生成一個 bound box。與圖片分類演算法一樣，它可以從頭開始訓練，也可以使用預先好的訓練模型進行微調。

小提示:
一個普遍的設計決策是，我們需要從頭訓練一個模型還是使用一個已經訓練好的模型來微調呢?

假如我們有很多資料或是非常特殊的使用場景，從頭訓練是一個make sence的做法。但如果我們只有很少而且是正確的資料有標籤，或是公司的業務需要一個快速地得到見解並且使用場景不需要高度特別的領域知識，使用 transfer learning是一個好的解決方案。我們需要注意，微調也具有成本效益，因為由於需要大量標籤資料和基礎設施需求，從頭開始訓練神經網路可能是非常昂貴。微調只訓練神經網路的最後幾層並固定其餘的權重(weights)，顯著減少訓練模型所需的參數量和成本。

非監督式的ML

這是一種我們的資料集沒有標籤的資料，而必須在這資料集中找到模式(patterns) 或 cluster．非監督學習也經常用作半監督學習策略的一部分，在這種情況下，我們有著大量無標籤的資料，但只有少量的資料有標籤，而取得標籤資料的代價高得令人望而卻步。我們將討論三種常見的表格式資料的非監督學習演算法。

PCA(Principal Component Analysis)

PCA是針對降維(dimensionality reduction)的一種非常普遍的非監督學習技術．降維是指通過將高維資料集mapping到低維向量空間來降低高維資料集的維度數量。 PCA 演算法主要在以保留盡可能多資訊的方式進行mapping。資訊的度量由covariance matrix決定。

主成分是covariance matrix的特徵向量，每個特徵向量彼此不相關。具有最大特徵向量代表資料中最大的變異性，第二大的對應於第二大的變異性，以此類推。

由於 PCA 是一種線性技術（涉及線性代數，例如矩陣對角化）並且保留了資料中的資訊但也會產生不相關的特徵，因此 PCA 通常用於去相關資料集中高度相關的子集。或者，當我們的資料中有大量特徵時，通常會應用 PCA 作為在 ML 訓練之前減少資料維度的一種方式。

借助 AWS SageMaker 的內建 PCA演算法，我們可以使用常規或隨機 PCA 策略。常規策略適用於較小的資料集，而隨機策略為大量特徵產生近似的covariance matrix。 SageMaker 的 PCA演算法支援 RecordIO 和 CSV 格式。

Note:
因為PCA是一種用於降維或去特徵是相關的普遍技術，我們也可以將 PCA 視為我們特徵工程過程的一部分，而不是實際的模型訓練。通常，PCA 是在模型訓練之前是用在特徵工程步驟的一部分；但是，我們將其包含在此處，因為它是非監督式演算法。

K-Means Clustering

表格資料集上最受歡迎的非監督式學習演算法之一是 k-mean clustering。k-means clustering是用在當我們的資料是沒有標籤但我們要把我們資料中資料點群聚成一個個相似的群組(如下圖)。

通常，我們可能已經有一些業務知識，可以告訴我們預期有多少cluster或group，或者我們可以進行多次的k-mean 演算法以找到最佳群組數。

k-means training首先確定一組隨機的 k points作為cluster中心。現在，對於每個 k centers，使用距離度量（例如歐幾里得距離）找到最接近該center 的subset of point。將new centroid定義為所有這些point的均值向量。重複執行這些步驟，直到演算法收斂(converges)，即cluster center不超過某個閾值(threshold)。

雖然在某些情況下，我們可能對cluster的數量有先驗的業務知識，但在許多問題中，情況並非如此。因此，我們需要確定”最佳”的clusters或group。

優化cluster數量的常用技術是使用 elbow method， elbow method 繪製方差(variance)百分比，解釋為cluster數量的函數。衡量這一點的一種方法是查看cluster之間的間隔平均值或最小值除以cluster內最大間隔的比率：

在elbow method中(如下圖)，我們將此數量繪製為cluster數量的函數，它通常具有明顯的elbow feature。正確的cluster數量由elbow在曲線中的位置決定。

PCA 的elbow曲線分析以確定最佳cluster數量，在這種情況下為 4 或 5

由於Clustering經常用於大規模資料集，SageMaker 的 K-means 演算法專為大規模clustering而設計，它使用一種技術將批次資料直接stream到training instance。它還在單個GPU instance上運行以加快訓練時間。它能讀取 RecordIO 和 CSV 資料格式。

小提示:
K-mans是非監督式學習， KNN(k-nearest neighbor)是監督式學習。

使用Random cut forest執行異常偵測

RCF(Random cut forest) 的工作原理類似於隨機森林樹，隨機森林樹是一種監督式學習演算法。 RCF 首先將資料集拆分為隨機樣本，然後將每個隨機樣本劃分為一棵樹，稱為 k-d tree。 k-d tree或 k-dimensional tree是一種用於在 k 維空間中組織和clustering data point的資料結構。

然後將異常分數(Anomaly score)分配給需要在樹的複雜度上發生較大變化的point，以將該point添加到樹中，例如，如果解釋樹中的那個point需要樹深度的較大變化。然後異常分數與樹深度成反比。與隨機森林數一樣，RCF 演算法建立了許多樹以減少由單個樹導致的總體方差(variance)，並將所有樹的分數平均在一起。異常點被歸類為與資料集中的平均異常分數相差 3 個標準差以上的點。

當我們有具有“尖峰”或非週期性行為的時間序列資料時，可以使用 RCF演算法。 RCF演算法主要在通過利用分佈式訓練的優勢來擴展大資料量，我們將在本文後面深入介紹。 但是，它設計給GPU用的。

小提示:
RCF適用於非監督式學習，而隨機森林樹是用在監督式學習。

另一種異常偵測演算法稱為isolation forest。本文不多做介紹，但你可以在scikit-learn implementation學到關於更多關於這種演算法的知識。

Topic Modeling with LDA or NTM(Neural Topic Model)

非監督式學習也可以運用在非結構化的文字資料。一個常用的案例是我們有一堆的文件並且我們想要這些文件的總結/摘要或是確認這些文件的主要Topic是甚麼。

總結/摘要是 NLP 中的一個大型研究主題，總結/摘要的一種方法是Topic modeling。 Topic modeling主要在發現一組代表大量文件的topic。 topic由相似詞的集群定義，並且不是先驗已知的，因此使其成為一種非監督的技術。

最常見的Topic modeling演算法稱為 LDA(Latent Dirichlet Allocation)。 LDA 使用 Dirichlet distribution基於潛在或隱藏變量是文件中的單詞分佈生成概率模型。這些隱藏的變量就定義了topic。在 LDA 中，單詞的順序是不重要的。

LDA 是一個生成模型，對於文件中的每個單詞，我們可以從distribution中選擇一個topic。然後我們選擇topic-word distributipn並從分佈中採樣另一個詞。該演算法的目標是優化最準確地“產生”文件中所有單詞的topic和distribution。

深入研究該算法背後的數學形式超出了我們的範圍，但足以理解該模型用於識別topic或將文件匯總為topic。它使用 Dirichlet distribution，是非監督式的，並且本質上是生成式的(Generative)。

儘管它很受歡，但該演算法的一個局限性在於它假設文件中的單詞分佈遵循 Dirichlet distribution。 NTM 演算法重新定義了這個假設，主要在沒有先驗假設(prior assumptions)的情況下學習一個latent representation。 LDA 和 NTM 演算法都適用於 GPU 和 CPU instance以加快訓練時間。 NTM 也可以在多個 GPU 上運行，但 LDA 僅支持單一個instance training。

小提示:
總體來說，NTM 演算法已被證明優於 LDA 演算法，並且可擴展到多個節點的分佈式訓練。不過， LDA 在概念上更簡單。

對於一般的文件摘要，其他演算法（如 BART）已經開始流行，它們可以提取準確的文件摘要，而不僅僅是topic。這在我們想要從文本語料庫（例如財務文件）中提取簡短摘要的應用程式中特別有用。然而，這是一個抽取式摘要模型 — — 也就是說，它不會生成new word，而是簡單地從原始文件中挑選它認為最重要的句子。

Reinforcement Learning(強化式學習)

這部分我們要理解的是強化式學習(以下簡稱RL)不同於監督/非監督式學習的地方。

非監督/監督式學習模型從有標籤或無標籤的資料中學習資料的模式，而RL主要最小化環境中的問題，並由可以在該環境中採取controlled set的agent組成。然後基於該這個agnet進行獎勵或懲罰其行動結果，並可以採取另一個行動。隨著時間的推移，目標是最大化獎勵(rewards)，並且agent學習最大化長期獎勵的最優“策略”。

RL與classical optimization theory，Markov decision process與dynamic programming有很多數學關聯。Bellman equation給出了最優性原則，它定義了在每一步採取行動時的獎勵和概率的最優策略。雖然這個方程式正式定義了問題，但實際上，這個方程式是棘手的。

RL有很多開源框架，例如 OpenAI Gym、Ray RLlib、Intel Coach 和附加到 TensorFlow/PyTorch 的框架，我們可以在 AWS SageMaker 上使用。

以下是一些RL的場景

金融業使用強化式學習來模擬市場的動態去訓練agent進行股價預測。
在機器人領域中，我們可以訓練agent執行諸如倉庫中取放包裹之類的操作。
RL 能可用於無人機遞送包裹。
RL 已被用於訓練計算機擊敗人類作為複雜的遊戲，例如 AlphaGoZero 的 GO，而無需先驗遊戲知識。

Local Training and Testing

資料科學是一個高度迭代的過程，隨著資料集變大，自然會出現一個關於如何最好地訓練這些大型資料集的問題。大的意思是指通常不適合放在機器記憶體中的資料。許多演算法（例如 XGBoost）需要將資料載到記憶體中以進行訓練，而隨著我們的資料大小增長到數百 GB 甚至 TB，這通常變得不太可能(不過如果你們公司很有錢，這可能又是另一回事)。

我們將在本文稍後介紹分佈式訓練，它可以解決這個大數據問題。第二個關注點與資料科學流程本身有關；通常，出於以下原因，資料科學家可能希望首先在小型資料集上快速測試我們的模型：

找出模型是否可以在少量但具有代表性的資料樣本上產生良好的結果
在啟動大型訓練作業之前調整我們的訓練代碼
可以選擇使用不同的模型演算法或特徵組合進行迭代

由於以上原因，資料科學家將首先使用scripts甚至使用Notebook interface（例如 Jupyter Notebook）在其本地(桌機/筆電/AWS上的EC2 instance)訓練模型，Jupyter Notebooks 是資料科學家中非常流行的交互式應用程式，用於資料探索以及本地訓練模型。另一個流行的軟體是 R ，使用 R 編碼的資料科學家傾向於使用 R studio 之類的工具。我們也可以使用IDE（例如 VSCode）在本機編寫我們的代碼。

為了加強這種資料科學經驗，AWS SageMaker 還提供了一個 Junpyter Notebook interface供資料科學家使用。 Notebook連接到存儲我們資料的 S3 buckets。針對訓練，我們可以簡單地在 SageMaker notebook 上的小型資料集上運行我們的代碼，甚至可以將我們的 SageMaker notebook(以下會簡稱NB) 擴展到大的NB instance以便在更大的資料集上進行訓練。

然而，雖然 NB 是很好的迭代工具，但當我們準備好在整個資料集上訓練模型或在生產環境中訓練時，我們會出於一些原因希望從 NB 遷移。

NB 可以scale up，但不能scale out。我們無法在 NB 上運行分佈式訓練，而且隨著資料規模的增長，我們可能需要同時在多台機器上訓練我們的模型。
我們很難在NB上進行版本控制。最佳實踐是將我們的code轉換為scripts（例如 Python scripts）並將其上傳到版本控制工具（例如 Git）。
我們的訓練代碼可能會依賴其他packages，我們通常不希望通過安裝大量package來放在 NB memory。最好使用專門用於訓練的獨立instance。

出於這些原因，SageMaker notebook interface提供local mode training的能力。不是將所有代碼都存儲在 NB cells中，而是使用local mode，我們可以將我們的訓練代碼和所有相關的dependencies打包到一個 Docker 容器中。要構建 Docket容器，我們可以使用 SageMaker 內建框架之一，例如 TensorFlow、MXNet 或 PyTorch。 Local mode不適用於 SageMaker 內建演算法，僅適用於public SageMaker container image。

Local mode使用 Docker compose 和 NVIDIA Container ToolKit for Docker 首先pull public SageMaker training image或從頭開始構建客製的training container。在我們的 SageMaker NB instance上本地構建容器後，我們可以像往常一樣運行 SageMaker 訓練作業，唯一的變化是啟動訓練作業的instance type。我們將指定 instance:type=’local_gpu’，而不是指定 EC2 instance type。 Local mode不支持分佈式訓練，因為訓練在 NB 本身上進行。

更多有關於local mode training的不同框架，我們可以參考GitHub repo。

Local mode的主要好處是我們不僅可以測試和debug資料集上的演算法代碼，還可以測試我們的訓練容器本身。通過將我們所有的代碼和dependencies打包到一個容器中，我們可以實施開發最佳實踐，例如版本或源代碼控制以及維護容器版本。

Remote Training

一旦我們出於開發目的在小型資料集上完成本地訓練，我們將希望在整個資料集上啟動訓練作業。對於大型資料集，訓練可能需要幾個小時，甚至幾天。由於我們在上一節中介紹的超大型 NLP 模型的某些原因，例如具有超過 1000 億個參數的 GPT 系列中的模型，訓練時間變成了數週。

作為最佳實踐，我們希望不在我們的 NB 或本地機器上而是在remote cluster上啟動我們的訓練作業，因此模型可以在後台訓練，同時我們可以繼續探索資料，繼續在我們的 NB 或 IDE開發其他演算法。為了加強remote training，AWS SageMaker 提供了一個 Python SDK（或者我們也可以使用較低級別的 boto3 AWS Python SDK）來啟動remote training job。 SageMaker 將在我們的AWS帳號中的remote EC2 instance上進行我們的訓練作業，因為 SageMaker 是託管服務，這些instance將由 SageMaker 管理並且在我們的 AWS帳號不會看到。

以下步驟是啟動一個訓練作業:

將我們的演算法代碼與相關的dependencies 放在一個local folder或GitHub repo
傳入Training script作為 SageMaker 的entry point。這樣，一旦我們的代碼和訓練資料載入到訓練用的容器中，SageMaker就知道執行 Training script。
指定 IAM role。 SageMaker training在幕後使用 EC2，因此我們需要向 SageMaker 傳遞一個 IAM role以及 IAM:PassRole 權限，以代表我們進行 EC2的啟動。這些 Ec2 instance不在我們的aws account中，因此我們不會在 EC2 控制台上看到它們。
指定我們要啟動的instance數量。
指定我們要啟動的insatcne type。
指定我們希望存儲模型工件的output S3 path。
通過傳遞到我們的訓練資料的S3路徑來呼叫estimator.fit 函數。我們還可以在訓練期間傳遞驗證資料集。

以下範例顯示了 PyTorch 框架的estimator function：

有關使用 SageMaker SDK在 AWS SageMaker 上啟動remote training的更多詳細資料，請參閱此文件。

Distributed Training

隨著 ML 和深度學習模型變得越來越複雜和資料量增加，在某些情況下訓練模型可能需要幾個小時到幾週的時間。分佈式訓練在單一instance 和across instance中利用compute core的平行性來減少訓練時間。在深入研究分佈式訓練之前，讓我們先回顧一些關於訓練 ML 模型的概念：

整個訓練資料的一個子集(subset)，稱為mini-batch資料，在訓練演算法的單次迭代中被發送到運算單元進行處理。但什麼是一次訓練迭代(iteration)？
使用mini-batch資料執行的單個forward和backward pass稱為一次的迭代(iteration)。
通過我們整個資料集的一個訓練週期稱為一個epoch。每個epoch有多次iteration是很常見的。
SGD(Stochastic Gradient Descent) 是一種在深度神經網路中使用的優化演算法，我們將用它來解釋分佈式訓練的一些核心概念。儘管 SGD 和其他訓練演算法的詳細資訊不在本文範圍內，但如果讀者有興趣，可以Google搜尋一下。對於 SGD 中的每個 epoch，該演算法執行以下操作：

初始化網路的權重並將資料分成mini-batch
對於mini-batch隨機抽取的每個資料樣本，根據網路的當前權重計算預測
使用損失函數(loss function)計算loss（這是預測輸出和樣本實際輸出的函數）
計算關於損失的梯度
更新權重並重複一直到我們滿足一些收斂規則（例如一組epochs或non-decreasing loss）

當資料和模型權重可以放入單一server或instance的記憶體中時，上面步驟1–5都由單個process控制，這個process首先載入一個mini-batch data並將其發送到 GPU 以執行這些步驟 .
當訓練資料不能完全容納在可用的記憶體中時，通常要不選擇具有更多記憶體的instance，要嘛進行data parallel training；首先在單一instance上使用多個 GPU，然後使用這一類走多個GPU的多個instance。
在data parallel training中，為每個 GPU（在一個instance內或跨多個instance）建立模型副本，並且訓練通常由每個 GPU 由一個process控制。在每次訓練交互期間，每個process載入一個mini-batch data並將其傳遞到 GPU，在那裡執行梯度計算。在典型的案例（稱為synchronous data parallel training）中，梯度由所有 GPU 控制並在更新模型權重之前進行平均。平均這些梯度的行為是由稱為parameter server的worker完成的。
正像為平行化(parallelization)增加模型訓練節點一樣，parameter servers的數量也可以增加。但是，parameter servers的數量與training worker的比例取決於作業量，因為在communication bottlenecks之間需要取得平衡（所有 parameter servers，需要從許多/所有training worker那裡獲得update)。
最後，梯度平均也可以使用training worker來完成，而無需單獨的 Parameter server。這稱為 Ring-Allreduce 方法，在 Horovod Python packager中實作，可以與大多數的深度學習框架一起使用。
當模型本身很大且複雜時，例如在基於視覺和語言的大型模型的情況下，它可能不適合跑在單個節點的記憶體中。另一個有助於分佈式訓練的策略是 model parallel training。模型本身被分區(Partition)並分佈在許多節點上。然後執行計劃將batch data跨多個節點傳遞以計算梯度。
如果模型被拆分，我們可能會問某些 GPU 是否是閒置的，直到帶有模型部分的前一個 GPU 首先完成batch process。為了最大化 GPU 利用率，我們所說的 mini-batch data被進一步拆分為幾個micro-batch — — 當 GPU 1 處理micro-batch 1 時，pipeline execution schedule告訴 GPU 2 處理micro-batch 2，以便 GPU 利用率最大化，並且最終，我們的training progresses是盡可能快。

所以，我們該何時使用 data parallel training或 model parallel training呢?

假如我們的模型可以放到一個單一instance的記憶體中，哪就用 data parallel training。
假如我們的模型無法放到一個單一instance的記憶體中，通過逐漸減小input的大小或batch大小和(或)更改模型的hyperparmaters來再次檢查。
假若模型還是放不進去，試著用 mixed-precision training。使用 mixed-precision training，模型參數使用不同的數字精確度呈現，以減少記憶體消耗並加快訓練速度。由於減小mini-batch大小會導致更高的error rate，因此使用mixed-precision training以允許較大的mini-batch可能是有益的。
如果上面的辦法都沒有用的，哪就使用 model parallel training.

現在我們知道什麼時候使用什麼策略進行分佈式訓練，讓我們看看這在實作中會是什麼樣子的。我們可以在安裝了 PyTorch 的終端機上進行操作。

我們將會從PyToch使用一個玩具的範例．我們可以使用 Jupyter Notebook或我們慣用的IDE來import部分的code．首先，我們會從PyTorch import 要使用的model並初始化一個simple model。

import torch
import torch.nn as nn
import torch.optim as optim

之後我們在PyToch訂義一個簡單有順序的model, 這個model會伴隨一個 input layer, 一個RELU(Rectified Linear unit)，這是另一個 output Linear layer．現在，將它們視為單獨的函數 f、g 和 h，因此可以將input x 穿越模型的“forward pass”視為 f(g(h(x)))。

model = nn.Sequential(nn.Linear(5, 5), nnReLU(), nn.Linear(5,1))

為了測試這個模型是否可以作業，我們讓我們嘗試傳入一個隨機張量(random tensor)來建模：

如果會有output類似如上所示，哪麼表示可以work．現在我們要定義一個損失函數與選擇一個 SGD optimizer:

上面， MSE指mean squared error， SGD指stochastic gradient descent 演算法, lr指learning rate.

在PyTorch中，它通常對所有的model梯度參數設置為0．然後我們會計算損失函數，使用 PyTorch 的 autograd 模型進行反向傳播並計算梯度，然後執行optimizer的One step：

重複這些步驟，直到我們達到epochs的數量。我們現在看到的玩具模型每個epochs執行的步驟與可以找到的大多數其他範例非常相似。

現在，假設我們想在單個instance上使用多個 GPU；在 PyTorch 上實現這一點的方法是使用 DataParallel model。這通過將input分成批次來平行化(parallelize)我們的模型訓練。模型的副本執行forward pass(model(input)) ，在backward step中，梯度會從每個副本自動組合。在代碼中，我們需要進行的唯一變動是：

如果我們的資料沒有辦法全部都放在一個單一insatnce中，我們就可以使用多個insatnce執行分佈式訓練．我們可以使用 DistributedDataParallel來實現：

每個 GPU device，在我們訓練的多個instance中，都有一個 ID 或一個rank。 DataParallel 在單一個instance上作業，由具有multiple threads的單一process控制，而 DistributedDataParallel 是mutliprosess並且在單個和多個機器上作業。如果我們的模型太大而無法在單一 GPU 上作業，那麼我們可以使用model parallel training。為此，我們首先使用 Pipe command拆分模型：

model =Pipe(model, chunk=8)

我們還可以更改我們之前擁有的sequential model來手動拆分我們的模型：

model = nn.Sequential((5,5), nn.ReLU(), nn.Linear(5,1))

來定義一個custom class:

將每一個layer指向特定設備，如上面所示 to(‘device’)的方法．

我們剛剛介紹了如何使用 PyTorch library的資料和model parallel function。在 AWS SageMaker 的Distributed data parallel library上，多項優化（包括更快的node-to-node communication和反向傳遞操作的optimal overlapping）提高了 GPU 利用率並實現near-linear scaling，並有效地縮短了訓練時間。在某些情況下，SageMaker 的data parallel library優於特定於框架的實現；詳情可以參考此篇文件：

SageMaker’s Model Parallel library 幫助我們自動將我們的 TensorFlow 或 PyTorch 模型跨多個device進行partition，而對我們的code進行最少的變動。SageMaker 中的Model Parallel library平行處理執行 schedule， operations的 pipeline execution，其中不同的設備可以使用不同的micro-batch data處理不同的forward和backward passes。要了解有關 SageMaker 的Model Parallel library的更多資訊，請參閱此文件。

監控Training Jobs

AWS上具有 SageMaker 等training component的 AI/ML service可以使用 AWS CloudWatch 等服務進行監控。 CloudWatch 允許我們監控各種流程，包括使用real-time logs、metric和event的訓練作業。我們還可以建立自定義儀表板和告警，在特定指標達到threshold時採取一些措施。另一方面，AWS CloudTrail 記錄我們 AWS account中的各種 API呼叫。最後，AWS EventBridge 可讓回應特定於訓練作業中狀態變化的事件。讓我們更詳細地看看這些選項。

AWS CloudWatch

首先，CloudWatch 可讓我們收集和分析來自各種service的詳細logs。特定服務的log會在 CloudWatch 上的專用“log groups”下。例如，可以在 /aws/sagemaker/TrainingJobs log group下找到 SageMaker training job log。這個log group包含許多“log streams”，如下所示：

[training-job-name]/algo-[instance-number-in-cluster]-[epoch_timestamp]

例如，我們可能在 SageMaker 中有一個trining job的log group，如下所示：

/aws/sagemaker/TrainingJobs pytorch-training-2021–03–16–17–53–49–690/algo-1–1615917370

SageMaker 還會將log推送到與其他feature相對應的log group，例如notebook instance、processing jobs和transform jobs。

到目前為止，我們了解到許多 AI service都可以讓我沒使用自己的資料集訓練自定義模型，但沒有詳細背後的training log。此類service的範例包括 AWS Rekognition Custom Labels和 Comprehend Custom Classification或Entity recognition。在這些情況下，這個服務會在控制台頁面以及 CloudWatch 上產生high-level metric，供我們分析模型並可能重新調整資料或input parameters並重新訓練模型。 Comprehend 和 Rekognition 模型都會為我們的自定義模型發出 Precision、Recall 和 F1 score，這些score是使用我們資料集（最常見的是在 S3 bucket中）訓練的。另一方面，SageMaker 產生標準以及自定義log和metric。使用notebook instance啟動訓練作業時，來自training instance的real-time log會顯示在notebook cell output中，並且還會發送到 CloudWatch。 SageMaker 以一分鐘一次發布多個metric，包括training jobs, processing jobs, transform jobs與endpoint。一些自動發布的metric包括 CPUUtilization 、GPUUtilization 、MemoryUtilization 、GPUMemoryUtilization與DiskUtilization．

還發布了與此處未討論的 SageMaker 功能相關的其他指標，例如來自 Ground Truth labeling job、endpoint invocation或與模型相關的指標。 endpoint invocation（model prediction）的一個重要指標是 ModelLatency ，它測量模型回應的整體時間，包括從容器發送和接收回應所花費的時間（network latency），以及在microseconds內完成容器中的inference所花的時間。更多有關於SageMaker推送 log到CloudWatch的文件請參考此篇文件．

AWS CloudTrail

User、role或 AWS service採取的Action由 AWS CloudTrail 記錄。詳細了解我們AWS account中的活動對於合規性、治理以及運營和risk auditing非常重要。 CloudTrail 允許我們查看和分析我們aws account中長達 90 天的歷史資料，並且我們還可以選擇將這些event存放在 S3 中以供將來分析或出於合規檢查。目前為我們所介紹的所有service CloudTrail 都有support；更詳細的資料可以參閱下表中提供的特定於服務的topic。這個表格包括此處討論的 AWS 上的 AI/ML 服務，以及一些有助於構建ML end-to-end solution的支援服務。

AWS EventBridge

AWS EventBridge 是一種serverless event bus，可提供來自客製應用程式、有支援的SaaS和 AWS service的real-time data，並將這些資料發送到 AWS Lambda、 SNS、SQS、ECS tasks 、CodeBuild、CodePipeline、API gateway等。 EventBridge rules用於確定哪些event可以觸發target。我們可以建立custom event和rule，還可以讓其他services對來自 AWS service的event做出反應。在本節中，我們將介紹 AWS 的一些 AI/ML 服務，這些服務發出可由 EventBridge 偵測到的event。

AWS SageMaker

AWS EventBridge 偵測各種 SageMaker component中的狀態變化，例如labeling、processing、training, tuning、inference endpoints還有feature groups。以下是 EventBridge 監控的event example：AlgorithmStatus、 EndpointStatus、HyperparameterTuningStatus、LabelingJobStatus、 ModelPackageStatus、NotebookInstanceStatus、ProcessingJobStatus、 TrainingJobStatus、EndpointStatus、FeatureGroupStatus。

Augmented AI

EventBridge events可用於偵測Augmented AI 中human review loops的變化並做出反應。當review loops將其狀態更改為 Completed 、 Failed 或 Stopped 時，Augmented AI 可以發送包含詳細資訊的event，包括human loop name、ARN, status、failure code和失敗原因。

Debugging Training Jobs

Debugging training jobs通常比debugging code更困難，因為它涉及以下內容：

更長的運作時間
需要debug底層框架代碼（例如，對於 PyTorch 或 TensorFlow 框架錯誤
在本地以及 SageMaker 等服務中進行測試
可能在多個devices或instances上運行的複雜的分佈式處理作業
追踪、關聯和分析單一個training job，這些job都可以作為single experiment的一部分
記錄和搜索來自distributed training jobs或hyperparameter tuning jobs的log
在 AWS 上構建 ML 時，可能涉及debugging roles、服務之間的connection和特定於服務的單一log

借助 AWS 上的 AI service，可以對結果進行high-level tracking and analysis，而無需來自底層算法的詳細資訊。在 SageMaker 上使用自定義（或內建）演算法時，我們可以使用稱為 SageMaker Debugger 的功能debug、monitor 與 profile training job。 SageMaker Debugger 提供兩個主要功能:

Debugging，用於模型優化；這是為了更深入地分析訓練作業。
Profiling，用於效能優化；這是為了識別效能問題並提供建議以提高資源使用率。

內建規則支援這兩個功能（我們也可以建立自己的規則）。當這些規則被觸發時，我們可以自動執行一些actions，例如停止training job或發送 SNS notification。對於 SageMaker 上的任何training job，我們可以使用與以下內容相關的內建規則：

System metrics
CPU bottleneck、I/O bottleneck、低GPU使用率，與整體系統使用率
Framework metrics
初始化時間，整體framework-level metrics, 與在step中的異常偵測
Modeling training tensors and metrics
vanishing gradient、exploding tensor、overfitting、overtraining、class imbalance、loss not decreasing等等

SageMaker Debugger 提供了一個名為 smdebug 的開源 Python library，用於設置內建和自定義規則。 Debugger還會產生一份報告，匯總所有監控和分析規則。有關 SageMaker Debugger 工作原理和最佳實踐的更多詳細資訊可以參考此篇文件．

Hyperparameter Optimization

HPO(Hyperparameter Optimization) 涉及使用各種輸入超參數運行多個訓練做作業，以根據某些指標找到最佳模型。讓我們回頭看分佈式訓練中使用的玩具的範例來探索這一點:

model = nn.Sequential(nn.Linear(5, N1), nn.ReLU(), nnLinear(N1, 1))

這裡使用了一個非常簡單的網路，包括一個linear layer、ReLU activation和另一個linear layer。術語 N1 是可配置的或取決於user input。在代碼中，我們使用另一個表示learning rate的可配置輸入 N2 定義優化器。

optimizer = optim.SGD(model.parameters(), lr=N2)

在這個非常簡單的例子中，我們需要運行幾個控制 N1 和 N2 值的實驗。這些是我們的超參數，超參數優化是找出 N1 和 N2 的組合的過程，該組合可以最小化我們更早定義的metric，即MSE(mean squared error)：

loss_fn=nn.MSELoss()

我們定義了 N1 和 N2 的範圍（上限和下限），並決定了 N1 和 N2 是什麼類型的變量。在這裡，我們決定 N1 是一個可以從 20 到 50 的值的整數，而 N2(learning rate) 是一個可以從 0.0001 到 0.1 的浮點數。

現在讓我們來看看多種 HPO 演算法，從我們可能要的最簡單的實驗到更複雜的實驗：

Manual Tuning
在這裡，我們可以手動更改 N1 和 N2 的值，重跑training code，測量Loss，並進行幾次這樣的修改/運行代碼的方式。可以想像，這種方法非常耗時，並且需要根據之前的實驗手動決定 N1 和 N2 的哪些value來嘗試。

Grid Search
為了加速手動訓練，我們可以編寫code來自動化和搜索每個可能的 N1 和 N2 值。對於 N1，這點還蠻容易的，N1 是一個範圍從 20 到 50 的整數，但是對於 N2，我們如何尋找 0.0001 到 0.1 之間的所有可能的浮點數？這通常通過“離散化(discretizing)”N2 的範圍來完成；也就是說，為 N1 與 N2 探索的graph of points會像下圖中顯示的那樣。

Random Search
我們從distribution中隨機採樣 N1 和 N2，並使用 (N1, N2) 的這種特定組合來進行experiments。我們可以繼續隨機採樣點，直到達到設定的最大實驗次數或達到所需的指標值。在同一張圖上，使用random search探索的點看起來像下圖

Bayesian Search
貝葉斯優化是一種非常普遍的高效、大規模超參數優化演算法。在grid search和random search中，不會從前一次實驗中學到的資訊用在為後續實驗提供資訊，目的是在獲得好的答案的同時減少訓練作業的總數。目的是在獲得好的答案的同時減少訓練作業的總數。使用貝葉斯優化，根據我們選擇的度量模型的效能被建模為高斯過程，這有助於根據之前的所有實驗回答接下來要嘗試哪些參數（N1 和 N2）的問題。更多關於Bayesian optimization的資料，可以參考這篇與這篇文件。

Multi-algorithm HPO
到目前為止，我們只更改 N1 和 N2，因為它們與一種“訓練演算法”相關，由網路參數和訓練優化器參數定義。通常嘗試使用多種演算法解決 ML 問題，因此使用同時探索多種訓練演算法的產品也很常用。

我們可以使用 AWS 控制台或支持的 API call在 AWS SageMaker 上創建 HPO 作業。這些 HPO作業可以使用random search, Bayesian optimization with single or multi-algorithm cases。有關如何在 AWS SageMaker 上運行 HPO 作業的詳細範例，我們可以參考官方文件。

我們可以使用 AWS SageMaker 的 HPO 功能來調整我們自己的training runs，無論是使用 17 種內建演算法中的一種還是我們使用支援的框架（TensorFlowm PyTorch、MXNet、scikit-learn 等）的演算法或我們自己的容器。 SageMaker Autopilot 可用於自動推斷我們的表格資料的預測問題類型，然後探索多種演算法，包括 XGBoost、神經網路和邏輯回歸，使用多演算法 HPO 找到最適合我們資料的模型。在 SageMaker 之外，AWS 上的許多 AI 服務都可以執行 HPO 來為我們的資料集找到最佳模型。例如：

AWS Personalize, 我們可以選擇recipe-specific parameters或ecipe-specific HPO。我們還可以執行 Auto ML，它探索多個recipe並成為最終解決方案優化specified metric的recipe。
AWS Forecast 包括六種內建演算法，其中三種允許手動覆蓋超參數（CNN-QR、DeepAR+ 和 NPTS）。 CNN-QR 和 DeepAR+ 執行 HPO。我們還可以選擇執行 Auto ML，讓 AWS Forecast探索多演算法並選擇一種對我們的資料集表現最佳的算法。
AWS Rekognition Custom Labels 可以使用 AutoML 檢查input image和label，探索多種訓練演算法，並訓練一個模型，以最大限度地提高測試資料集的效能指標。
其他服務，例如 AWS Comprehend Custom labels、AWS Fraud Detector、Lookout for Metrics、Lookout for Vision 和 Lookout for Equipment，都能夠運行 AutoML（通常涉及多個資料準備、訓練和探索策略，以找到最佳模型）。

總結

在本文中，我們討論了 ML use case的分類方式 — — 監督式學習、非監督式學習和強化式學習。我們還討論瞭如何在本地和remote instance中實施訓練以及分佈式訓練和hyperparameter優化的基礎知識。最後，我們討論瞭如何使用 AWS 上的適當工具監控和debug訓練作業。