AWS 的AI與機器學習服務簡介

如果歸檔資料是紀錄我們的過去，大數據是同步分析我們的現在，哪麼預測性演算法與機器學習就是占卜我們的未來。

本篇我們會學習到AWS針對機器學習(以下簡稱ML)會遇到的不同問題，如影像/聲音的分析，自然語言處理，文字轉成語音(或是反過來)，或是建立推薦系統，時間序列預測等等問題所提供的各種不同的服務。AWS所提供的這些服務可以讓我們很快的建立我們所需要的ML平台，而不需要太高深的ML經驗或知識。我們將會學習到如AWS的SageMaker，這是一種全託管服務並且能夠提供給資料科學家與ML開發人員來建立，訓練，並且部署ML模型在AWS中。

AWS Rekognition

這是一個對圖片或 影像分析作業流程的服務。這是AWS累積了非常多基於圖片(例如圖片分類，影像中物件偵測，影像中文字的偵測，臉部辨識，情緒分析等等)的深度學習經驗後提供給我們的AI服務。

儘管開發影像分析模型背後有大量的深度學習研究，但訓練這些深度學習模型的電腦運算成本通常很高，並且可能需要一個團隊的資料科學家或開發人員的時間。 這時 AWS Rekognition 就能上場幫忙 。借助 AWS Rekognition，開發人員可以簡單地利用預先訓練好的模型或訓練自定義的ML模型，而不需要編寫演算法，或者設置/管理用於訓練和部署深度學習模型的基礎設施。 更重要的是，我們不需要任何先備的ML或深度學習知識即可使用此服務。

在我們進一步介紹 AWS Rekognition之前，我們很快地來看一下在深度學習中的圖片和影像主題上的一些基礎。影像辨識通常會需要依靠CNN(Convolutional neural network)架構。 CNN是由交替的卷積神經層(convolutional layer)組成的深度學習演算法，它對輸入的資料使用各種過濾器以擷取不同級別(scale)的不同資訊，通過polling layer的方式做資料流動，從而減少網路中的參數數量以及呈現的空間大小。初始層(initial layers)會擷取low-level feature，像是物體的邊緣與線條，接續的layer會建立high-level的物體到最終能辨識這項物體。在CNN中有非常多架構，例如ReNet或Inception V4，不過我們還是要能理解這些架構的概念。

在ML中，學習transfer learning 的概念也是相當重要的。Transfer Learning 是指採用在一個資料集上預先訓練好的模型，凍結初始層，並讓它在不同的資料集上重新學習模型的最後幾層。 這樣做的好處是：

• 減少從零到full neural network的算力
• 當我們沒有足夠多的資料或data labeling是昂貴的，使用這種預訓練模型比從零開始訓練的模型會有更好的效能。

在圖片分類領域，Transfer learning中使用的 Inception V4 與 ResNet演算法都是很普遍的。而Transfer Learning的用途不只可以用在 圖片或影像的資料型態，它也能用在自然語言處理(NLP)。

對於物件偵測(object detection)，基本架構是相似的，但這個模型不是偵測貓與狗（這種有固定label），而是偵測在一定的範圍內想找的物件。 常用的演算法包括SSD(single shot detector)、R-CNN 或 Faster R-CNN，以及 YOLO v4。

最後，semantic segmentation實際上是通過對物件是否屬於特定的像素(pixel)進行分類來分割圖片中我們想找的物件。 一個例子是偵測人體組織中的腫瘤。 對醫生來說，不能只框出一個邊界就足夠了，還需要準確地將腫瘤組織與正常人體組織劃分開來。

我們可以使用 AWS Rekognition在以下的案例:

• Image Labeling — 這是指標記圖片是否由正確的物件(自然界存在的物體), 事件(尾牙，聚會等等)，概念性(景點，大自然，夜晚)，或活動。
• 自訂義的Image Labeling — 假設我們是製造業，我們需要檢查裝配線上的零件是否有缺陷。 由於我們的零件不是自然界中會見到的，我們可能需要訓練自定義的模型。AWS Rekognition 允許我們為此種狀況訓練自定義模型。
• 臉部辨識與搜尋 — AWS Rekognition 不只能在圖片上進行臉部辨識而且還能一堆圖片中進行搜尋。想像我們在一個交通路口中有一大堆的人，我們需要在這川流不息的人群尋找特定的逃犯。
• 軌跡追蹤 — AWS Rekognition 可以追蹤影像裡的人類移動軌跡。例如，我們需要追蹤逃犯的所有移動軌跡以利我們進行後需資料分析與處理。
• 文字偵測 — AWS Rekognition 可以偵測圖片中的文字並且將它轉化為機器讀得懂的文字，以利我們能進行後續的動作。
• PPE(Personal Protective Equipment) — AWS Rekognition能夠在圖片中偵測PPE

圖片與 影像的作業

AWS Rekognition可以用在靜態的圖片以及影像(已經錄製存放的)。圖片的操作是同步的，而影像則是非同步的。這意思是當我們使用 Rekognition處理影像的作業完成時，Rekognition會通知(使用SNS )我們。我們之後就可以呼叫一個"get* API"來存取產生的結果。而同步的API Call作業則在呼叫同時得到我們要的答案。

AWS Rekognition並不是支援所有影像的操作;例如，PPE detection API只能支援圖片。而人類的軌跡移動只能用在影像。

例如在圖片或影像中偵測一個物件。對於在圖片中偵測物件，我們的圖片來源可以是在S3中的圖檔(如 JPEG or PNG)或是一個byte-encode image input。 假如我們使用boto3( AWS的 Python SDK),我們就需要使用呼叫一個API call。(完整的範例與操作)

經過上面的運算，運算結果會長得像以下這樣

通過指定 MaxLabels ，我們可以限制收到的回應數量，AWS Rekognition 將返回一個回應，來顯示圖片中偵測到的各種物件的邊界框和信心指數(confidence score)，如上一個範例所示。 信心指數可用於下游作業。

相比之下，對於影像作業，我們不能傳位元型的資料，而必須傳存儲在 S3 中的影像位置。其 API 是 StartLabelDetection，我們還需要傳一個 SNS topic，以便 AWS Rekognition 在完成影像標記作業後向其推送一個 notification。 然後，我們可以呼叫 GetLabelDetection API 來存取結果。

另一個 AWS Rekognition 是可以用在串流影像。AWS Rekognition可以擷取(ingest)串流影像，但必須是從AWS Kiniese Video streams過來的資料，處理完成後再推送到Kinesis Data Streams。

小提示：
如果我們想要用的是一個可擴展的圖片/影像分析流程，我們可以考慮使用 AWS Lambda 來 製作一個 AWS Rekognition API calls。可以用AWS SQS來queue傳入的資料，限制會進到 AWS Rekognition API。詳細的架構可以參考此連結。

AWS Textract

這是一個可以讓我們從各式各樣的文件提取我們想要的文字，而讀取文字的方式是使用OCR(optical character recognition)。使用Textract，我們不再需要建立深度學習影像模型來提取這些文字(例如從PDF檔案)。這一個服務能夠讓我們在現今充滿大量數位文件的世界中快速建立自動化的文件處理流程。而Textract可以處理"非結構化”及”半結構化”的資料(free-form text/ tables等)。

不過此項功能只有提取文字的作用，它並不能對文件進行分類，情緒分析，或辨別整份文件。而這些功能只有AWS Comprehend才有，後面會提到。不過在我們商業流程中， textract與 Comprehend是經常組合一起使用的。

使用AWS textreact的常見場景如下:

• 通過將 Textract 文件分析的結果存儲在 DynamoDB 等key-value存儲型態中來建立search index。
• 從文件中挖掘文字以進行自然語言處理 (NLP)：Textract 可以提取words、lines和tables，我們隨後可以在基於 NLP 的工作流程中使用這些words、lines和tables。
• 從表單中自動捕捉資料：Textract 可以從結構化文件（例如稅單或申請表）中提取資訊。

同步與非同步APIs

文件有著多種的形式與大小，例如掃描後的圖檔或是一個檔案有很多頁的PDF檔。

對於同步 API，我們可以用byte array或 S3 object將資料傳到Textract進行處理。 我們可以使用 DetectDocumentText 或 AnalyzeDocument 等同步 API 來返回包含偵測到或分析的文字的 JSON output。 Analyze API 還識別文件中的層次結構，例如form data、tables以及text的行列和字。 Detect API 僅偵測文字。

雖然文件通常都被歸類為非結構化資料，不過它們通常還是有結構存在的。例如，一些制式化的銀行申請表單一定會有一個姓名欄位，後面就會有一個名字，如Jason Kao。現在Textract掃描後返回這一個名字後，這一筆資訊就可以讓我們傳到下游系統繼續處理。

AWS Textract 將文字轉換成key-value pair ，允許我們將這些輸出直接的存到key-value DB。類似如table 和table data分別作為 Block 和 Cell objects，提供有關文件中表格位置的邊界框資訊，然後是有關表格中底層cells的資訊。

對於 PDF 檔案或大於一頁的文件，需使用非同步 API StartDocumentAnalysis 和 StartDocumentTextDetection 。由於偵測大型文件中的文字可能需要一些時間，Textract 將在背景處理文件並將完成狀態發送到 SNS topic。這個topic的subscriber隨後將收到作業已完成的通知，並可通過使用 GetDocumentAnalysis 或 GetDocumentTextDetection API 查看結果。然後可以將作業的結果存儲在 DynamoDB table、S3 bucket。

讓我們看一個使用案例，一家醫療公司希望從病患表單中提取文字以後讓下游系統繼續處理，例如使用ML改善整體病患體驗。該公司目前在 S3 中存儲了數百萬個 PDF 文件。由於這是一家醫療公司，因此保護病患資料是頭等大事，並且HIPAA法規是任何雲端服務的一項要求。最後，公司高層不完全信任基於ML的解決方案，並希望人工審查一些由ML產生的結果。

首先，AWS Textract 在這裡可能是一個潛在的解決方案，因為它符合 HIPAA 標準，並且具有非同步 API，可以使用PAYO(pay-as-you-go)定價模型從大量 PDF 文件中提取文字。此外，AWS還有一項名為 Amazon Augmented AI (Amazon A2I) 的服務，可以直接與 Textract 文件分析 API 整合，根據特定threshold condition（例如對偵測到ML很低信心分數的文字）發送文件以供人工審核（如下圖 ）。

AWS Transcribe

這是一項適合大型客服中心的服務。這個客服中心可以每天處理客戶電話的voice data(real-time/streaming and batch)錄音作業，由於每天要接成千上萬通的電話並且有著多種語言的服務。我們需要一套系統來幫我們解決這一項作業，並且是具成本效益與可擴展還有不需要太多的設定。

傳統的客服中心通常都是把聲音錄成音檔格式。而電腦可以將這些音檔轉換成文字。為此，現代化方法稱為ASR(Automatic Speech Recognition)，並為 Amazon Alexa 等技術提供支援。 這些技術使用神經網路將 audio sequence作為輸入(input)，並使用稱為sequence-to-sequence的模型產生由文字組成的output sequence。 然而，準確地建立這些模型需要大量資料，而並非所有公司都會有的。

AWS Transcribe 利用與 Amazon Alexa 相同的技術，但可作為transcription service使用，讓我們無需任何ML知識即可轉錄我們的語音資料。 以下是其中的一些功能。

Transcribe Features

Stream and Batch Mode — Transcribe支援用串流或批次的模式。如果是 串流，audio會直接用HTTP/2協定的方式傳入。也可以用Transcribe提供的streaming client，或者是我們也可以使用 WebSocket協定。如果是已經存在S3的音檔，我們可以使用 批次錄音作業(batch transcription job)中的StartTranscriptionJob API來完成。

多語系支援 — AWS Transcribe 支援多種語言，並且AWS會持續更新語言清單。

多語系轉錄 — 我們的音檔中可以包含多個語言。如果我們知道我們的音檔中包含一種以上的語言則可以通過指定 LanguageOptions 將language code作為 API call的一部分進行傳輸。

Job Queuing — 為了不把API服務打爆(API throttling),可以使用此種功能將job送往queue，這樣就不用建立一套邏輯防止API被打爆。

Custom Vocabulary and Filtering — Transcribe提供類似一個字典功能(這是可以自訂義的)，來讓Transcribe可以使用辨認其語音，像是特定名詞或是特定領域的詞彙。當然我們也可以去除一些文字，例如不好的語言。

自動內容編輯 — 假如你的音檔包含了一些敏感的個人資訊，Transcribe可以讓你編輯這些敏感資訊在處理後的資料中，或是分成兩種腳本(編輯過與未編輯過的)。

語言辨識 — Transcribe 可以辨識在我們的錄音檔中的主場語言是甚麼。

發言者辯識 — 在transcriptio中可以辨認不同的發言者。

讓我們回到客服中心的例子，現在要開始對AWS Transcribe進行POC(proof-of-concept)。由於在音檔轉文字的過程中我們需要移除個人資訊並且另外儲存這些資料，這一點Transcribe PII detection 功能可以做到。但我們在POC的過程中發生了一些狀況，雖然整體功能良好，但是在某些特定領域有一些狀況，就是轉錄的文字不夠精確。再來，這個領域的高度特殊的詞彙大小超出了 50KB的限制。為此，我們需要建立自訂義的模型。而我們也需要有training dataset來訓練這一個模型。

小提示:
AWS Transcribe自訂義的model與AWS Comprehend有甚麼分別呢?Transcribe自訂義的model只能用在聲音轉錄成文字。Comprehend Custom是可以針對文件進行分類與entity extraction。

Transcrible醫療領域的使用

醫療領域高度專業化，特殊詞彙的量很大。 因此，大多數常見的深度學習模型在該領域都不能很好地發揮作用，除非它們經過專門的醫學資料訓練。 AWS Transcribe Medical 是一項 ASR 服務，可讓我們轉錄醫療音檔，例如醫生口述、患者與醫生的對話和遠距醫療。 Transcribe Medical 可在串流與批次模式下使用（僅適用於一般性問診），允許我們建立自定義詞彙表並從我們的串流轉檔中編輯PHI。

AWS Translate

假設專門為一家在全球多個不同國家/地區營運的全球連鎖飯店工作，我們希望匯總和收集客戶服務的線上對談資料以改善客戶體驗。 唯一的問題是，使用場景會發生在不同的語言中，而且用不同的語言建立基於神經網路的翻譯模型既困難又昂貴。 第三方翻譯工具可能還有品質問題，而我們可能更喜歡按使用pay-as-you-go的定價模式。 使用 AWS Translate，這是一項文字翻譯服務，它使用先進的深度學習為沒有任何深度學習經驗的客戶提供高品質的翻譯功能，並採用按需付費的定價結構。

現在我們進入POC階段，如果我們已經有所有的線上對談資料。但業務團隊提出了以下兩個問題:

• 只有少數的應用程式跑在AWS Lambds，並且這些的資料量很少，大量的資料是放在S3上，而這些需要非同步的處理。
• 在某些特定的國家，我們有一些特定的術語需要被使用來對應到旅館名稱，所以需要在翻譯中被考慮到而不是直接被翻譯成當地語言。

AWS 的翻譯功能

以下是AWS的翻譯功能：

• 同步與非同步API : AWS翻譯功能能夠讓我們非同步與批次的處理大量的文件資料，batch job最大資料為5GB(使用 StartTextTranslation API)。這個API的好處是當單一文件包含的collection是很小的，例如社群媒體的評論或評分。而size很小的文件我們也可以用 TranslateText API來處理它。
• 自定義的術語與平行資料：此外，我們可以通過提供自定義術語（CSV 文件）來自定義翻譯的輸出，該文件提供原始語言中的自定義術語和所需的目標術語。 我們還可以傳入parallel data，向這個翻譯服務展示我們希望如何翻譯文章段落。 不過，並非所有語言都適合自定義術語；我們可以在AWS網站找到相對應的文件。

Translate 不允許我們建立自己的自定義翻譯模型； 它使用由AWS訓練的模型。 因此，AWS可能會使用客戶資料來提高其演算法和模型的品質。 如果不要 AWS Translate 和其他 AI 服務用我們的自訂義資料，我們可以選擇退出此功能，請參閱這個文件。

下圖是完整的batch-based流程來處理已儲存的資料，這個範例是從西班牙語轉成英語然後運行一個 custom entity 或lebel detection model(使用的是 AWS Comprehend)。

AWS Polly

這跟Transcribe是相反的服務，這是從文字轉成音檔(Text to speech)。這主要提供一個文字檔(plain text)或使用 SSML(Speech Synthesis Markup Language)語法。Polly會去讀這個語句並可以產生不同語言的音檔。

那麼語音合成是如何作業的呢？ 標準語音合成 TTS 的工作原理是將稱為音素(phonemes)的基本語音單元串在一起，形成聽起來自然的合成語音。 諸如深度學習之類的AI技術已應用於文字轉成音檔以產生 Neural TTS（NTTS）。 Neural TTS 模型由所謂的sequence-to-sequence模型組成，該模型採用輸入序列（通常是一個句子）並生成一個輸出序列（由模擬大腦在處理語音時使用的聲學特徵的頻段組成的頻譜圖）。 該模型的結果會傳遞給Neural vocoder。 Neural vocoder是相當於將頻譜圖轉換為語音音素的語音。

哪麼何時使用TTS或NTTS呢？

訓練 NTTS 模型準確需要大量資料，想爾當然它們還不是在所有語言中都可用。 因此，首先，我們要檢查 NTTS 是否適用於我們要翻譯成的語言。 如果我們正在尋找新聞播音員的演講風格，則必須使用 NTTS。 通常，如果我們可以選擇，與標準 TTS 相比，NTTS 會生成更優質的語音。

如果我們想控制語音輸出的產生方式，例如放慢或加快速度或控制音調或說話風格可以 使用SSML tags。將 SSML 視為一種類似於 HTML 的語言，它允許我們使用tag來定義如何呈現特定對象。 有關 SSML tag和 AWS Polly 支援的tag的更多資訊可以參閱AWS的文件。

SSML 類似於語音的 HTML。 通過指定諸如 <prosody> tag 之類的標籤，我們可以控制語調、音量和語速。 同樣，如果我們想用不同的語言拼寫一個單詞，使用 <lang> tag。

通過指定 volume=”loud”，我們可以使用這個tag讓聲音變大。如果要讓聲音變柔和可以用 volume=”soft”。

或者，AWS Polly 還以speech maker的形式返回一個產生語音關聯的metadata。 這些可以告訴我們特定音頻在什麼timestamp開始、speech mark的類型（句子、單詞、SSML 等）、開始和結束偏移、哪個可用的 Polly 語音 ID 正在說話，等等。 有關speech marker的更多資訊更參閱AWS文件。

AWS Lex

客戶/消費大眾現今利用聊天機器人與我們的軟體互動，而這些軟體也了解這些使用者的意圖並且有正確的回應。普遍的案例包含電子商務/銀行的客戶支援，醫院門診的預約，旅館、機票等等的預定。

AWS Lex是AWS所提供的自然語言理解(NLU-natural language understanding) 與自動語音辨識(ASR- automatic speech recognition)，這些服務讓我們能夠建立與佈署一個跟我們的軟體與人類之接的對話介面。使用AWS Lex我們可以為客戶打造量身定制的個性化體驗，無需任何深度學習專業知識即可與我們的軟體互動。

小提示:
Lex 與Polly的不同:
Polly也有使用到ASR, 但Polly只會把文字轉成語音。而Lex是一個中介的介面，介於我們的軟體平台跟使用者的意圖。

而主要在開發聊天機器人程式時通常有以下一些關鍵步驟:

1. 製作這個機器人需要了解的語言(或數種語言)，目的是要了解使用者的目的與使用者對話以實現其意圖。
2. 測試機器人
3. 發佈機器人(是有版本的，以便能夠在有問題時roll back)
4. 部署機器人到終端平台，例如我們的網站、FB messenger、Slack或Twilio。

為了執行這些步驟，我們首先需要理解一些主要概念。

Lex概念

所謂Bot(機器人)是一個實體(entity)，它可以實現客戶想要的作業/操作。以電商／銀行的程式來看，這類的作業可能是客戶的下單，呼叫真人，或是進到後端資料庫找客戶想要的資料。

AWS Lex會呼叫Lambda函數這一類的背景作業來完成。例如，我們的bot可以幫我們預約到附近診所的醫生看診，哪就可以讓Lambda寫這一筆資料到RDS或DynamoDB。同樣的Lambda可以進到資料庫查找這一筆資料來提醒使用者看診的時間。

而在面對使用者的前端，bot需要了解使用者的意圖。這需要使用者輸入這個bot了解的語言（或數種它了解的語言）。關於AWS Lex的支援語言在這個AWS文件庫。

使用者的意圖就是bot要去執行的作業。話語就是使用者實際要求的內容。例如，我們要訂一個pizza，哪話語應該會是＂我要一個pizza＂而意圖就是去"下訂一個pizza"。

這時NLU與深度學習就要上場了。AWS Lex需要一些從使用者提供的少量的範例意圖資料來建立一個模式，而這個模式可以概括為使用者可以要求某事的無數方式。

讓我們回想一下在深度學習之前這是如何作業的。開發人員需要首先提供可以發出特定要求的所有方式的本體，然後建立一組規則來以某些方式對意圖做出回應，而如果使用者的話語不是機器人詞彙的一部分，哪麼就要提示使用者以不同的方式提出問題。

通過深度學習，該模型可以概括到新的話語，而無需有預先定義的規則。我們可以提供一些範例話語，例如“我想要披薩”、“我可以訂購披薩嗎”，Lex 將建立一個模型來概括到其他意圖。

Slot是定義使用者要求的一組參數，slot type是該slot的特徵(characterization)。該Slot可用於使聊天機器人對話。例如，如果使用要訂購比薩，則slot type可以是pizza，slots可以是小、中和大，這樣組合起來就是由小到大的pizza。機器人可以要求使用者提供尺寸或配料清單。一旦提供了所需的slots，聊天機器人就可以連接後端 Lambda函數，然後這個函數將呼叫 API 來下訂單或將訂單寫入訂單表。為了簡化聊天機器人應用程序的建置，Lex 為常見項目（如日期、姓名、號碼、電子郵件、地址和時間）提供了一組內建的slot和slot type。

如果我們正在使用 Lex 建立機器人，並且我們的機器人效能不佳，請嘗試增加範例話語的數量。我們提供的example越多，模型就能夠更好地概括沒見過的話語(utterance)。

如果機器人不理解使用者講甚麼怎麼辦？ AWS Lex 會自動包含fallback intent(就是機器人會說: 對不起，我聽不懂你說的)，因此我們無需自行建立。這一類的intent(意圖)會發生是，當機器人在設定的重試次數後無法識別意圖，或者該意圖無法將使用者的輸入識別為slot value或對確認提示的回應時。

通常，如果發生了 fallback intent，我們可以讓 Lambda 函數執行一些預先定義的操作，例如連接到人類客服。通過這種方式，對話流程給人一種對話式和自然的感覺。或者，如果我們的機器人無法理解使用者的要求，它可以觸發文件搜尋以提供答案(雖然很多人都不喜歡這種回應方式)。為此，我們可以使用 KendraSearchIntent API，它在後台利用 AWS Kendra。

下圖顯示如何使用 Lambda函數將後端的 Lex 與不同的 AWS 服務整合。 在這種情況下，AppointmentBot 使用關聯式 和非關聯資料庫向終端使用者顯示相關資訊。

小提示:
Slots是可以設置的參數，utterance(話語)是實際的句子，而inetnt是整體的對話意思。在定Pizza的範例中，slots可以是pizza的大小或要加甚麼樣的配料，intent是要訂一個pizza，並且句子是說"我要一個夏威夷pizza"，"我要一個小pizza"等。

AWS Kendra

一個跨國企業需要在員工之間共享的內部資訊。此外，這些資訊通常以非結構化文件格式可能包含在來自 Microsoft Word 、Microsoft PowerPoint 、PDF 甚至第三方工具（如 Confluence、Salesforce、ServiceNow、Microsoft OneDrive 和 Microsoft SharePoint）的不同資料來源中。

該企業的 CIO 希望建立一個應用程式，允許內部員工查詢和搜尋這種非結構化資料並對其進行data mining以得到新的見解，並為使用者搜尋功能是能快速回應的，以提高知識共享和員工生產力。什麼 AWS 服務將允許我們建立這樣的應用程式？

看著敘述，我們可能認為這是要求我們從各類文件資料中提取字串，我們可能認為 Textract 是正確的服務，但這裡有兩個關鍵點：

1. CIO 不是要求我們簡單地提取字串；而是要求我們搜尋文件並建立一個提供有足夠智慧答案的應用程式。
2. 資料來源不是只有 PDF。這兩點都會告訴我們 Textract 不是這裡的解決方案，而是 AWS Kendra。

AWS Kendra 允許我們使用自然語言建立我們自己的搜尋應用程式，為使用者查詢提供高度相關的回應，就像我們從組織內的人類專家那裡得到的一樣。使用 Kendra，我們可以獲得事實（例如阿里山的高度）的答案，以及複雜問題的描述性答案，例如“什麼是 合作夥伴表格？”甚至是使用者可以輸入“廠商匹配”或“退休福利”的關鍵字搜尋。

本質上，Kendra 由深度學習演算法提供支援，但效益是這一切都是從終端使用者那裡抽像出來的。原因很簡單，為自然語言建立和訓練高度準確的深度學習演算法既昂貴又複雜，並且需要企業對很難找又貴的ML專家進行大量投資。儘管並非所有企業都能負擔得起這樣的投資，但提供可擴展的內部搜尋平台的需求是普遍存在的。認識到這一點，Kendra 提供了兩種定價模式：開發者版和企業版。兩者都是PAYG，但後者通過在三個AZ運行來提供更高的可用性，允許更多查詢，並且可以傳入更多文件和文字。

Kendra是如何作業的

以下是Kendra基本的核心概念:

1. Index
   首先我們需要建立針對文件建立索引以方便我們進型搜尋。索引是由 Kendra 管理的物件，它帶有關該文件的一些metadata，例如建立和更新的時間、版本以及我們可以作為使用者修改的custom fields（例如日期和數字）。
2. Documents
   其中包括 Kendra 將編制索引的實際文件。 它們可能包括FAQ或純粹的非結構化文件，例如 HTML 文件、PDF、純文字或 Microsoft Word 或 Microsoft PowerPoint 。
3. Data sources
   我們是否需要手動index documents？ 答案是不用; 我們只需向 Kendra 提供資料來源，例如 Confluence server、Microsoft SharePoint、Salesforce sites、ServiceNow instance或 S3 bucket，Kendra 將為文件編制索引，並將資料來源與索引同步以保持相關性和更新。 有關AWS Kendra 支持的source data的完整清單在這裡。

我們可以按內容脈絡或類別（例如某個人創作的文件）來過濾搜索。 我們還可以根據自定義屬性對搜尋到的資料進行排序。 預設排序順序是 Kendra 根據我們的搜索由回應資料的相關性指定的。

通常，當我們搜索某個item時，我們通常不會用確切的名稱。 例如，如果我們正在搜索 Amazon Web Services； 我們可能會用簡寫“AWS”，或使用 Kendra 代替 AWS Kendra。 我們可以在同義詞庫文件中提供 Kendra 的同義詞清單，其中可能包括公司內部第一個字母的簡寫或特定於產業領綠的常用簡寫。

小提示:
Kendra與Comprehend同樣的地方在於他們都有使用到NLP，不同處在於，Kendra只能進行智慧化的文件搜索。而Comprehend能夠使用預訓練或自行訓練的模型來進行情感分析，文件分類，與實體標註。

回顧到現在所介紹的AWS AI/ML服務，在之前關於 AWS Lex 的部分中，我們介紹如何在沒有任何 ML 知識的下在 AWS 上建立聊天機器人應用程式。 我們現在可以使用 Lex 和 Kendra 建立端到端的FAQ解答對談機器人。 Lex 提供了基於話語(utterance)識別使用者意圖的前端，它可以通過將意圖作為輸入傳遞來使用 KendraSearchIntent 呼叫Kendra。 然後，Kendra 可以搜索並傳回聊天機器人顯示的最相關的結果。

AWS Personalize

個人化服務已迅速成為廣泛的垂直領域中無處不在的案例，例如以下範例：

金融服務 一家為客戶提供個人化保險體驗的保險公司提供

電商平台 一家公司為其客戶提供購買或基於客戶搜索歷史的推薦系統

旅遊公司 一家為客戶提供旅行地點、活動或住宿地點建議的公司

媒體和娛樂業務 一家根據其他客戶推薦的下一部片觀看內容的偏好和歷史

Amazon Personalize是一項ML服務，允許企業快速開發個人化推薦系統，為終端客戶提供更好的客戶體驗。從ML的角度來看，所有這些不同的業務問題都有一些共同點。它們都依賴於三種形式的資料：

1. 使用者資料
   這可能包括有關使用者年齡、位置、收入、性別、個人偏好和其他人口統計資訊的資料。
2. 商品或服務資料
   這是關於公司銷售或試圖推薦的實際產品或服務的資料。
3. 使用者-商品的互動資料
   這是關於一組使用者如何與這些商品進行互動的資料，例如他們過去是否購買過這些商品，他們喜歡或不喜歡這些商品，或者他們是否提供了對這些商品的評論或評分。任何個人化服務的目標都是獲取這些資料並提取有意義的見解，從而引導客戶購買產品或服務。

傳統上，這是通過幾種方式完成的：只使用使用者資料，公司會將使用者聚合到相似的群組中並推薦該群組中其他人購買的商品，或者他們將商品聚合到相似的群組中並向使用者推薦”相似已購買商品”或根據”使用者的feedback”。這通常分別稱為clustering和content-based filtering。

還有一種稱為collaborative filtering(協同過濾)的方法，其中使用者-產品互動資料通常用於推薦產品。這個使用者-產品互動資料通常是一個非常大的sparse-matrix（用戶數量產品目數量成正比）。例如，像 Netflix 這樣的公司，擁有數百萬訂閱者（使用者）和數十萬部電影和節目（產品）。協同過濾(collaborative filtering)將大型sparse-matrix分解為更小的矩陣（matrix factorization），以提取每個使用者和每個產品的hidden或latent vectors。這些會積累出最終分數，它決定了是否推薦一個產品。

雖然這是一種非常普遍的技術，但如果我們沒有很多產品，matrix factorization通常運作效果會很差。在這種情況下，我們可以考慮使用其他方法，例如使用 XGBoost 和Factorization machine等模型進行監督式學習。在這邊，我們是根據模型預測使用者購買商品的概率，並推薦概率最高的產品。

Collaborative filtering的缺點之一是它”不納入時間因素”。 它不考慮使用者的購買或對話歷史。 例如，如果我們一個月前在電商平台上購買鞋子，現在對Apple watch感興趣，那麼好的推薦系統可能不應該向我們推薦鞋子。

出於這個原因，科學家們開始使用RNN(recurrent neural networks)，它能夠”保留使用者的對話歷史資料作為模型訓練的一部分”。 深入的RNN 架構，可以參考 Balázs Hidasi、Alexandros Karatzoglou、Linas Baltrunas 和 Domonkos Tikk 撰寫的"Session-based Recommendations with Recurrent Neural Networks" 。

AWS的科學家將其進一步擴展到名為 HRNN-Metadata 的模型，該模型使用 RNN 來存儲使用者歷史記錄，還能夠將使用者和產品的metadata作為訓練的一部分。 這使他們不僅可以解決時間歷史問題，還可以同時解決cold start problem — 即推薦者無法向新的使用者推薦產品，詳細介紹可參閱此篇文件。

Multiarmed bandits(MAB)從High level來說，MAB 使用了探勘-開發權衡(exploration-exploitation trade-off)的概念。 目標是在固定數量的步驟後最大化total reward。 在探勘階段，演算法探索可以最大化效益的不同可能組合，記錄每一步的reward以建立reward distribution。 在開發階段，它選擇一個已知的選項來增加overall gain。 當與現行選擇相比，探勘可能會降低收益時，就會出現權衡。 但是，除非我們進行探勘，否則我們將不知道是否還有其他選項可以取代我們當前的選擇。 有關 MAB 的更多詳細資料，可參考此篇文件。

AWS Personalize 是一個 AI 服務，它將個人化的這一領域知識轉化為 Web service，允許客戶將推薦系統構建到他們的應用程式中。 AWS Personalize 採用recipes的概念，針對特定的user case分為三種類型。 Recipes 允許我們在沒有任何先前 ML 知識的情況下建立推薦系統：

User Personalization Recipes
這些recipes有三種。 首先，user-personalization 使用 user-item interaction data並測試不同的推薦場景。 這是推薦的個人化recipe，並使用我們之前討論的exploration-exploitation trade-off來建立。 其次，流行度計數(popularity count)會推薦所有用戶中最受歡迎的item，並且是比較其他recips的良好baseline。 最後，還有一些涉及我們之前討論過的 HRNN 和 HRNN-meta models的傳統方法。

Ranking-Based Recipes
這是一個使用HRNN，但也同時使用排名(ranks)的推薦方式。

Related Item Recipe
這是之前提到的 collaborative filtering 演算法。

除了recipes之外，AWS Personalize 可以識別三種的資料集分別是: user data/item data/interaction data。user 與 item 資料集都屬於 metadata type並且只使用在特定的recipes。詳細的資訊可以參考此篇文件。當AWS personalize使用 HRNN recipes, interaction data需要包含timestamp來辨識其互動的歷史。

使用AWS personalize 建置一個個人化的模型在AWS上稱為solution。當我們上傳資料後，第一步是create 一個solution(會包含一個recipes)。AWS personalize 會根據我們提供的資料而有不同的solution 版本並且會自動切割資料分成訓練(90%資料)/測試(10%資料)。我們可以調整演算法的超參數(hyperparameters)或讓Personalize幫我們代操。然後它將在評估或測試資料集上評估solution版本，但將最舊的 90% 的text data作為input提供給它。 然後，它將根據最新的 10% 的test data評估建議。

模型的效能基於評估指標，例如 Precision at K 和 Mean Reciprocal Rank at K。了解這些指標的含義很重要，以便能夠判斷模型的質量：

• Precision at K: Of the K items 推薦，除以 K後有多少是實際相關的。
• Mean Reciprocal Rank K：K 中第一個推薦的倒數排名的平均值，其中平均值用於所有查詢。

更多有關於AWS personalize的其他指標細節，請參閱此篇文件。

Create solution版本後，我們可以建立一個campaign來即時或批次為item評分。 Campaign用於為使用者提供推薦。 Personalize 提供了一個SQL-like的界面，可以即時和批次使用場景中的查詢來過濾推薦。更多關於campaigns的資訊請參閱此文件。

一個常見問題是，當有新的user-item data時，需要多久重新訓練一次模型。對於某些recipes，Personalize 允許我們在推薦中包含real-time event data，而無需每次都重新訓練模型 ，通過將新資料加到我們的user history並使用新資料自動更新模型。更多的基於 real-time event data建立的推薦請參閱此文件。

也就是說，許多客戶會根據他們推薦的新鮮度（或相關性）以某個固定的節奏（每晚、每週）重新訓練他們的模型。 這通常是一個業務性題 — — 在某些產業中，客戶的喜換變化的速度可能比其他產業快得多。 通常，在建立任何 ML使用場景時，我們將希望與相關業務利害關係人合作來回答這些問題。

AWS Personalize 使用一些獨特的術語，並且能夠對應到一般性的資料科學工作流程(如下圖)。

小提示:
在後面我們將介紹 AWS SageMaker，它有一個稱為 Factorization Machine 的內建演算法。 這是一種監督學習算法，與非常適合大量item（> 100）的類似HRNN 等演算法相比，當我們只有少量item時，這種演算法效果很好。 如果我們要在SageMaker 上運作personalization，就需要考量 Factorization Machine。

AWS Forecast

如同Personalization，forcast是另一個幾乎影響所有產業的問題。例如:

• 航運公司需要預測其船隻在各個港口的需求，以相應地安排航線。
• 一家醫療公司需要預測不同醫院的醫療用品需求。
• 一家大型零售商需要預測產品需求，以確定要保留在其倉庫中的庫存。
• 雲端運算供應商需要預測客戶的基礎設施和運算需求，以規劃其資料中心的容量。
• 客服公司需要預測其客服中心不同時期的來電數和持續時間，以計劃招募客服人員。

AWS Forcast是一項AI服務，主要使用統計方式與深度學習演算法來提供高度精確的預測。如同Personalization，對於大型零售商與雲端運算業者來說，預測需求是一個長久以來的一定要的功能，就如同亞馬遜電商網站。而AWS Forecast 提供這樣的功能。

從資料科學的角度來看，傳統的預測方法本質上是Autoregressive，最普遍的演算法之一是自Auotregressive integrated moving average(ARIMA)。 ARIMA 是一種統計演算法，是用過去的數值用於預測未來的數值。 ARIMA 模型根據時間 t-1 … t -p 的歷史值加上一些error terms來預測時間序列在時間 t 的值。移動平均(moving average)是regression error，autoregressive這一部分是lagged temporal features。Integrated的部分是加入differenceing component（取相鄰點的時間序列值的差值），使時間序列是平穩的。

這個模型的主要優點在於其簡單性，並且有許多不同開發語言（Python、R 等）的packages可以使用 ARIMA 來預測時間序列。長久來，ARIMA 方法在許多方面得到了改進 — — 例如，S-ARIMA 或seasonal- ARIMA，其中包括季節性，以及由 Facebook 引入的 Prophet。

與 ARIMA 不同，它假設時間序列的數學形式，Prophet 試圖通過檢測不同時間間隔（例如季節性）的趨勢來將時間序列與資料配適(每日、每周和每年的趨勢，甚至假期的影響)。這導致 Prophet 成為當今最普遍的預測模型之一。但這也會增加其複雜性； ARIMA 模型易於解釋，因為它具有簡單的線性數學形式。而Facebook 發布了 Prophet 的神經網路版本，稱為 Neural Prophet。

隨著深度學習的出現，特別是深度學習模型學習序列型資料的能力，這些方法自然也被使用到time series forecasting中，可以看作是一個sequence。AWS科學家開發了一種稱為 Deep-AR 的演算法，該演算法使用基於 LSTM(long short-term memory) 的模型和probabilistic sampling技術來產生成概率預測。

與 AWS Personalize 一樣，AWS Forecast 主要將外部使用的普遍運用預測演算法和 AWS內部研究的演算法整合到一項服務中，使我們無需先備的ML知識即可建立準確的預測。

在特定schema中提供資料，然後讓 AWS Forecast 幫我們選擇一種演算法，或者自行選擇 Forecast 中可用的眾多演算法之一，例如 ARIMA、DeepAR+ 和 Prophet。

以下我們來看一下在AWS Forecast有哪些演算法是可用的(同時也稱作predictors):

• DeepAR+
  這是我們之前討論的 DeepAR 的延伸，並在許多相似的時間序列（> 100 秒）上訓練單一個模型。 它的工作原理是將時間序列隨機分成稱為context length的fixed-length “windows”，主要在預測從未來直到稱為forecast horizon的這一個區間長度。 通過在多個epoch和不同的時間序列上這樣做，DeepAR 可以學習不同時間序列的共同模式，以產生準確的全局模型。 DeepAR+ 將context length視為模型中的超參數，允許我們調整它們以獲得更好的效能。 此外，DeepAR 以相關時間序列或簡單的item metadata的形式接受有關item的metadata。 因此，如果我們要預測銷售額，那麼相關的時間序列可能是商店地區的天氣資料或人流資料的時間序列。 雖然 DeepAR+ 可以處理資料中的缺失值(missing values)，但如果資料有很多缺失值，那麼預測可能會受到影響，因為模型無法學習到有用的模式。
• ETS
  或稱 exponential smoothing是一個統計演算法(特別在季節性資料集很有效)。它的工作原理是計算prior features的加權平均值，但不是恆定權重，而是應用指數衰減函數作為加權參數。 ETS 不接受任何metadata或相關時間序列。
• Prophet:
  當我們的時間序列在多個月/年中具有強烈的季節性變化並且我們有詳細的時間序列資料時，就要使用Prophet 。 當資料包含不規則性（例如黑色星期五期間的峰值）或缺失值時，它也很有用。
• CNN-QR
  Convolutional Neural Network Quantile Regression演算法也使用深度學習，但這次使用卷積神經網路 (CNN) 而不是 DeepAR 等recurrent neural nets。 它使用稱為sequence-to-sequence learing的概念，其中模型被輸入一個輸入序列並生成該序列的hidden representation。 這稱為encoder。 然後使用另一個稱為decoder的網路使用這個representation來預測輸出序列。 我們在此不深入介紹equence-to-sequence模型，但了解它與 DeepAR 之間的區別很有用。 DeepAR 使用 LSTM，而 CNN-QR 使用causal convolutional neural network。 有非常多的書籍可以參閱，如這個與這個。
• Nonparametric time series(NPTS):
  不像ARIAM與ETS是以數學的方式來處理時間序列問題。NTPS是非參數(nonparametric)的方式。它適用在季節性或爆量類型的資料，或是資料是非連續的value。事實上，NPTS較Prophet被常使用。

小提示1:
如果我們手上只有一些時間序列的資料，用ARIAM, ETS或 Prophet會比較好。如果全都是時間序列資料，哪就考慮 DeepAR+或CNN-QR。

小提示2: 何時應該用到 CCN-QR或DeepAR+?
這兩個模型都是接受metadata與相關時間序列的輸入(input)。然而，CNN-QR 不需要相關的時間序列延伸到要預測範圍，但 DeepAR 需要。 想像一下，我們有一個時間序列的商品銷售到時間 t，並且正在嘗試預測從時間 t + 1 到 t + n 到未來的銷售額。 如果使用天氣資料作為相關時間序列，DeepAR 需要準備好從時間 t + 1 到 t + n 的天氣預報，以便預測未來的銷售額。 CNN-QR 沒有這個要求。

AWS Forecast 的其他效益之一是，除了演算法之外，它還允許我們在時間序列中包含天氣和假期資訊。

Forecasting Metrics

時間序列演算法複雜的地方之一是如何衡量模型的效能。與可以將資料隨機分成train/test的一般分類性(classification)問題不同，這不再適用於時間序列，因為時間序列中的不同data row在時間上彼此相關。

相反，時間序列使用一個稱為回測(backtesting)的概念，其中模型根據歷史資料進行測試，其中真實的資料。例如，假設我們是一個靠股市交易維生的人，並試圖預測股票價格。我們已經訓練了一個模型來擷取歷史股票資料並預測未來價值。我們將如何測試模型質量？

在這種情況下，可以根據歷史股票價格對模型進行回測，可以在其中準確了解市場表現。通常，進行多次回測是一個很好的做法，每個回測都有再多一點的training data(expanding windows)，但固定長度的測試範圍或固定但滑動的training data(sliding window)和固定的測試範圍。

在每種情況下，評估模型的一個很好的指標是mean squared error(MSE)，通常回報為root mean squared error (RMSE)。如下公式：

其中 y i.t 是時間序列 i 和時間 t 的預測值； y i.t表示時間序列的實際/觀察值； 總和是所有時間序列和時間，由 NT 正規化：backtest中的number of points。

這個指標放大了離群值，而另一個稱為weighted absolute percentage error (WAPE) 的指標對離群值更穩健，因為它不開平方。WAPE有時也稱為 absolute percentage error(MAPE)。

我們的預測依賴於哪個指標取決於使用場景：如果離群值可能會產生巨大的業務影響並且一些大的錯誤預測可能代價高昂，我們可以考慮 RMSE 而不是 WAPE。

在這兩種預測中，模型並不在意我們是低估(underpredict)還是高估(overpredict)。 但是，在許多業務問題中，低估的代價可能與高估的代價大不相同。 例如，在零售業中，我們可能希望庫存過剩而不是庫存不足。 AWS Forecast 提供quantlies（例如 p10、p50 或 p90）來提供概率預測。 了解這些分位數(quantiles)的含義是有用的：

• p10意味我們的模型預測只有 10% 的情況下，真實值會小於該值。
• p90意味我們的模型預測90% 的情況下，真實值會小於該值。

作為是一家零售業，如果庫存不足的價值超過庫存過剩的成本，p70 或 p90 預測可能對我們作為一家企業更有用，因為我們更喜歡庫存過剩而不是庫存不足。 在這種情況下，我們可以選擇weighted quantile loss (wQL)，它允許我們設置分位數，其值可以從 0.01 到 0.99。 我們可能希望將其設置為 0.70，模型將自動包含對underfitting與overfitting的不同penalties。 我們不會在此處展示 weighted quantile loss公式，但對於test而言，與 RMSE 或 WAPE 不同，這種loss可以區分低估和高估就足夠了。

小提示:
什麼時候應該使用 WAPE、RMSE 和 wQL loss？ 如果我們的業務會對一些大的mispredictions產生巨大影響，那麼就用 RMSE。 如果我們的業務成本根據預測是低估或高估而發生變化，就用 wQL loss。 不然，就用 WAPE。 通常，根據多個指標查看模型效能並使用不同的分位數（例如 p20、p50 和 p90）可視化我們的預測是一種很好的做法。

p50 分位數與 WAPE 預測相同。 WAPE 預測通常稱為mean absoluate percentage error(MAPE) 或median forecasting。

AWS Comprehend

AWS Comprehend 一個預先訓練和自定義的模型且提供了一組基於自然語言處理的 API，可以從文件中提取見解。 AWS Comprehend 可以分析文件的以下特徵：

1. Entities : — 如日期，地點，組織，人員，數量，稱謂，事件等。
2. Key phrases — 描述特定事物的名詞短語.
3. PII (Personally identifiable information)
4. Language — 可以用來辨識文件中的主場語言。這可以是 100 種公認的語言之一。
5. Sentiment — 可以辨識文件中的情感; 可能是正面的，負面的，混雜一起的，或中性的。
6. Syntax — 這用於為文件中的每個單詞提取詞性。

除了使用API呼叫的預先訓模型，我們也可以在AWS Comprehend訓練自訂義的模型(當然是使用我們的資料訓練)。這一個自訂義模型是同步流程(synchronous process )— 也就是客戶自行準備文件資料，訓練模型，並且使這訓練好的模型進行預測。有三種型態自訂義模型可以讓我們在AWS comprehend上訓練:

1. Custom document classification
   我們需要準備一些文件，這些文件每一個都需要帶有label。一旦完成了自訂義模型的訓練，我們就可以將新文件傳入這個模型並得到一個label(在一定程度的信心水準下)。
2. Custom entity detection
   這個用來提取自訂義的entity type。Comprehend 上的預設的entity detection中不包含諸如保單編號或零件編號之類的自定義術語。 可以使用entities list和包含它們的一組文件來訓練Custom entity detection。 訓練模型後，我們可以使用此自定義模型來提取針對我們的use case自定義的entities。
3. Document topic modeling
   Topic modeling在comprehend 使用非監督式學習的技術稱為Latent。

一些適用於 AWS Comprehend 的總體準則要記住的是 — 所有text documents中使用的文字編碼都是 UTF-8，並且每個文件的大小必須小於 5,000 bytes。 如果要每秒發送 25 個以上的文件，則要用batch operation。 例如，如果我們每秒發送 20 個文件，可以使用 DetectDominantLanguage API，但使用 BatchRequestDominantLanguage API，每秒最多可以發送 250 個文件但由於它是batch job，可能需要更多時間來接收 S3 中所有文件的最終結果。 StartEntitiesDetectionJob 或 StartSentimentDetectionJob 等非同步操作的最大Quota包括最大文件大小為 1 MB，最大batch文件大小為 5 GB，並且batch operation中的文件數量小於 100 萬。更多AWS Comprehend限制可參考此文件。

AWS CodeGuru

Aws CodeGuru 使用從 Amazon codebase中的數百萬行 Java 和 Python code 建立的program analysis和ML，為提高code 效能和質量提供智能建議。 CodeGuru 包含兩個主要服務：Reviewer 和 Profiler。

Aws CodeGuru Reviewer 主動偵測潛在的code defects並提供改進 Java 或 Python code的建議。 CodeGuru Reviewer 不會識別語法錯誤（IDE 是一種更好的方法），但它確實提出了與 AWS best practices、resource leak prevention、concurrency、敏感資訊洩漏預防、重構、輸入驗證和安全分析相關的改進建議。 CodeGuru Reviewer 可以分析 AWS CodeCommit、Bitbucket、GitHub 或 S3 中的code。

Aws CodeGuru Profiler 從我們的線上應用程式收集運行時效能資料，並提供有關如何微調效能的建議。 CodeGuru Profiler 使用ML幫助找到最昂貴的code line，提供分析數據的可視化，並建議減少 CPU bottlenecks的方法。 CodeGuru Profiler 提供dashboard來了解應用程式效能問題，還可用於分析在 AWS Lambda 和其他 AWS 運算服務中運行的code。在 AWS Lambda 上，如果我們使用 Python，codeguru_profiler_agent 的最簡單方法是是加上一個在lambada layer有包含這個功能的package，然後使用function decorator，如下所示：

AWS Augmented AI

Aws Augmented AI（或稱 A2I）用於對ML模型low-confidence預測進行第二次人工審查。 A2I 與 Aws Rekognition 和 Textract 是一起直接使用的，但我們也可以將 A2I 與我們自己的自定義 ML 模型結合使用。當我們想要檢視 low-confidence prediction或稽核隨機預測樣本時，通常會使用 A2I，而不管confidence level如何。我們需要做的第一件事是定義人工審核工作流程。

人工審核工作流程涉及

1. 定義一個將review prediction的工作團隊
2. 使用 UI template來提供指令和人類提供feedback的界面（稱為worker task template）。

作業團隊可以由 一般大眾（由 AWS Mechanical Turk 提​​供支援）、廠商的員工、或我們自己的員工組成。worker task template顯示我們的輸入資料（例如圖像或文件），並提供交互式工具以允許人工審核人員完成審核ML模型預測的任務。

對於 AWS Rekognition 和 Textract 的兩種內建任務類型，相應的 AWS 服務將自動觸發人工檢視迴圈。何時觸發人工檢視迴圈的條件在 JSON檔案中定義。例如，如果我們使用 AWS Textract 從提交的表單中提取特定key，我們可以使用 ImportantFormKey 參數和 KeyValueBlockConfidenceLessThan 參數在與特定key關聯的confidence低於特定threshold時觸發人工審核作業。使用自定義ML模型時，您可以使用 AWS A2I Runtime API 通過呼叫 StartHumanLoop API 來啟動人工循環。

範例: 偵測貸款詐欺

一家銀行有一個ML模型，可以預測貸款申請是否存在欺詐。 最近的一項授權規定，該銀行必須在做出貸款決定之前審查人類員工對欺詐性貸款申請的預測。 該銀行使用 A2I 通過首先呼叫ML模型endpoint並分析confidence score來支援自動化ML。 如果confidence score低於 90%，客戶端會在 A2I 中觸發人工review loop，然後從存儲在 S3 中的輸出文件中分析人工審核結果（如下圖）。

AWS SageMaker

AWS SageMaker 是一個end-toend ML平台，可讓我們大規模建立、訓練、調整和部署模型。 SageMaker 在典型ML生命週期的每一步都提供功能。 在這裡，我們討論此生命週期中的每個主要步驟，並提供有關 SageMaker 提供的features的詳細資訊。 但本文中，我們不會在這裡討論 SageMaker 的每一個feature，而是將重點放在支援典型ML生命週期最重要階段的features上。 供你參考，下表為與SageMaker相關的在不同階段的ML功能(最新的feature set可以參考此文件)。

分析與預處理資料

通常，ML生命週期的第一步是準備用於訓練的資料。 開發有助於準備資料的代碼的首選工具 IDE(Integrated Development Environment)，較常見的是 Jupyter Notebook。 Notebook包含 Markdown 和可運行代碼的混合，用於記錄每個可運行單元的結果。 在Notebook上完成code experimenting後，通常也可以在獨立 Python code中執行相同的預處理。 SageMaker 提供了以下components來幫助完成 ML 生命週期中的這個階段：

1. SageMaker notebook instance
2. SageMaker Studio
3. SageMaker Data Wrangler
4. SageMaker Precessing
5. SageMaker GroundTruth

以下我們將針對每個component來討論

SageMaker notebook instance

SageMaker notebook instance 是跑在 Jupyter server的託管 ML compute instance。我們可以從 SageMaker console或使用 CreateNotebookInstance API create notebook instance。建立notebook instance時，SageMaker 首先在所選定的 VPC 中create network interface，並將我們在request中提供的security group與特定AZ中的subnet 連結起來。 SageMaker 然後在這一個 VPC 中啟動一個instance並打開這個 VPC 和notebook instance之間的網路流量。然後 SageMaker 安裝common package和 ML framework，並額外運行我們定義的任何lifecycle configuration scripts；這些scripts可用於從 Git repository中pull latest updates、掛載share driver或下載data和package。 SageMaker 然後附加一個 EBS volume（可以選擇 5 GB 到 16 TB 之間的大小）。存放在 /home/ec2-user/SageMaker 目錄中的文件在notebook sessions之間保持不變（意思是，當我們關閉並再次打開notebook instance時）。我們可以使用lifecycle configuration scripts或通過 Lambda function來完成，原因是可以將降低沒在使用notebook的費用。關於更多在正確的使用Sagemaker與不必要的花費，可以參考此篇文件。

當我們access notebook instance時，AWS Console會使用我們用於登錄的credential通過呼叫CreatePresignedNotebookInstanceUrl API 來取得presigned URL。如果我們使用公司的SSO、Active Directory 或其他身份驗證商（如 Google 或 Facebook）登錄，則使用IAM role的身份。最後，SageMaker 使用 nbexamples Jupyter extension提供了 200 多個example，這些example展示了各種範例和 SageMaker 功能。 SageMaker 還允許我們將notebook instance 與project Git repo相關聯，這個repo在啟動時自動複製到我們的instance。

使用 SageMaker notebook instance時，我們可以編輯notebook execution role來access其他 AWS 服務。例如，我們可以使用notebook instance通過對 AWS Glue 進行 API 呼叫來管理大規模資料預處理，或將您的notebook連接到 AWS EMR 以運作 PySpark kernel。我們還可以在 AWS Redshift 中查詢我們需要準備訓練的資料。

SageMaker Studio

SageMaker Studio 是一個基於 Web 的機器學習 IDE，基於高度客製的 JupyterLab 環境。 在單一的可視化界面中，我們可以編寫和維護notebook、track experiments、部署和監控模型等等。 與notebook instance相比，SageMaker Studio 啟動用於運行notebook kernel的containerized images。 這讓我們可以用到多個back-end compute instance運行我們的notebook。 例如，Studio 上的一個notebook tab可能運行general-purpose m4 instance，而另一個notebook可能運行 GPU instance以進行local training。 SageMaker Studio 允許我們與團隊成員共享notebook snapshot，共享同一個domain的其他使用者可以copy並在他們自己的personal workspace中使用。 workspace設置是 AWS EFS driver中的一個文件夾，它可以隨著local data的增長而彈性擴展。 SageMaker Studio 還為許多其他 SageMaker 功能提供了可視化界面，例如：

• Visual Git workflow
• Experiment tracking
• SageMaker Autopilot for AutoML on tabular datasets
• Curated one-click solutions for applications on SageMaker Jumpstart
• Pretrained and fine-tunable models for typical vision and NLP jobs through SageMaker Jumpstart
• Model-building pipelines using SageMaker pipelines
• SageMaker Clarify for detecting pretraining bias
• SageMaker Feature store for creating, sharing, and managing curated data for ML development
• SageMaker Data Wrangler for preparing data

SageMaker Data Wrangler

SageMaker Data Wrangler 允許我們通過可視化工作流程導入、轉換和分析資料，然後導出這個workflow。 Data Wrangler 允許我們從 S3、Athena 和 Redshift import 資料。 SageMaker Data Wrangler 上的data preparation pipeline稱為data flow。

當我們在data flow加上新step時，SageMaker Data Wrangler 會自動建立一個新的intermediate data frame。 我們加的四種不同類型的step：

Data Transform Step
Data Wrangler 提供了超過三百種以上內建的transforms(不用寫code)對資料(columns)進行normalize, transform , combine。當然我們也可以使用 Python/ PySpark 寫出客製的step。

Data Analysis Step
使用我們資料集的 100,000 row來提供內建或客製可視化、用於評估特徵重要性分數的快速ML模型、columns的統計摘要以及相關性或target leakage report。

Join
這是join兩個dataset，並產生一個 data frame(可以是 left join, right join, inner joins)。

Concatenate
此步驟將一個dataset連接到另一個dataset並將結果加到我們的data flow中。

SageMaker Data Wrangler step可以export到 Data Wrangler job、包含所有step的notebook、feature store或獨立 Python code。 這使我們可以模組化預處理步驟並按我們想要的方式運行，而這通常使用 SageMaker Processing。

SageMaker Processing

SageMaker Processing 是 SageMaker 上的一項簡單的託管功能，可讓我們運行常見的資料處理負載，例如preprocessing, feature engineering, 與model evaluation。 SageMaker 使用我們的 Python 或 PySpark scripts，從 S3 copy data，處理資料，並將輸出資料寫回到我們aws account中的另一個 S3 。 我們還可以提供自定義的contain image。 傳入 Python script時，我們使用 SKLearnProcessor ，傳入 PySpark script時，我們使用 SageMaker Python SDK 中的 PySparkProcessor classes。 通常使用多個instance來處理資料，在這種情況下，我們可以通過 S3 key對input object進行shard，以便每個instance接收相同數量的input file進行處理。

SageMaker GroundTruth

SageMaker GroundTruth 在 ML 生命週期的這個預處理階段提供了一個重要的功能。 要使用監督演算法訓練 ML 模型，我們需要高質量的labeled data。 GroundTruth 為常見task type（如image classification或document classification）提供內建的label function，並且還允許完全自定義的工作流程。 借助 GroundTruth，我們可以使用群眾外包（Amazon Mechanical Turk）、員工或供應商。 您可以選擇對某些任務類型使用automated data labeling，它使用主動學習同時也訓練模型並決定將哪些資料樣本發送給人類labeler。 涉及images, video frames, text data, and LiDAR data 的內建task type會具有管理的 UI。 您還可以為data labeling job提供自定義 UI。 有關 SageMaker GroundTruth 的更多資訊可參考此文件．

Training

一但你已經準備好你的資料後，你可以在SageMaker中用以下方式訓練我們的模型：

• AWS SageMaker 為典型use case提供了 17 種內建演算法。 其中包括binary or multiclass classification, regression, time series forecasting, anomaly detection, IP address anomalies, embedding generation, clustering, topic modeling, text classification and summarization, image classification, object detection, and semantic segmentation.
• 使用常用的 ML 框架（如 TensorFlow、PyTorch 或 MXNet）時，我們可以在 SageMaker中 submit這些scripts。 SageMaker 將提供一個managed container，可以運行這些常用框架的多個版本。 當我們想使用自己的演算法而不需要管理自定義容器的額外作業時，這是有效益的。
• 最後，我們可以為我們的training job建立一個完全自定義的容器。 SageMaker 將使用我們提供的entry point在我們選擇的managed training instance中運行container。 例如，我們在 Dockerfile 中的entry point可能如下所示：ENTRYPOINT [“python”, “train.py”]．

SageMaker還提供了以下額外的功能：

Distributed Training — SageMaker 提供model parallel 與data parallel分散式訓練策略。 分散式訓練中的data parallel策略是將dataset拆分到多個處理節點。 每個節點運行一個 epoch 並與其他節點共享結果，然後再進入下一個 epoch。 在model parallel訓練中，模型被拆分到多個處理節點。 每個節點都帶有模型的一個subset，並負責運行由pipeline execution schedule決定的transformations subset，以便最大限度地減少由於順序計算造成的效能損耗。

Managed Spot Training — -我們可以使用managed spot instances代替on-demand instances，將training cost降低多達 90%。 Spot instance的中斷由 SageMaker 處理，但“我們有責任建立自己的checkpoints”，以允許訓練在出現任何中斷後繼續進行。

Automatic Model Tuning — SageMaker 的Automatic Model Tuning，也稱為hyperparameter，可用於使用 random search or Bayesian optimization來搜索最佳的hyperparameter。 我們可以使用產生最佳模型版本的hyperparameter，通過我們選擇的指標（例如，validation accuracy）來衡量。

Monitoring Training Job — SageMaker training log job可以在 AWS CloudWatch 中查看 。 此外，可以在console中將training job metrics（例如發出的training error）做為圖表。 training job結束後，我們還可以使用 DescribeTrainingJob API call 查看final metric。

SageMaker Debugger — ageMaker Debugger 可用於分析和debug我們的training job，通過消除bottlenecks和偵測nonconverging conditions來提高 ML 模型訓練的效能。 Debugger存儲我們在training code中定義的 instance-level metrics, framework-level metrics, and custom tensors。 我們可以使用各種內建規則（如loss不減少或overtraining）或我們自定義規則來分析由training code 發出的tensor。 Debugger 還提供了profiler rules，例如 CPU bottleneck threshold and I/O bottleneck threshold。 規則啟動後，我們可以觸發 AWS SNS 通知或 Lambda function以採取進一步行動，例如停止training job。

模型推論

在 SageMaker 上訓練模型會在 S3 上產生訓練好的模型（通常是 model.tar.gz 的檔案）。要讓這個模型開始工作，我們可以託管在real time的persistent endpoint，也可以使用 SageMaker batch transform API 將模型預測用在整個test dataset。

對於real time prediction，SageMaker 提供全託管的模型服務並產生private HTTPS endpoint，我們的模型可以在其中return prediction output。我們可以部署模型的多個production variant，以將不同百分比的流量轉移到模型的不同版本。我們可以託管多個模型並從呼叫 endpoint的client application中指向這些模型。最後，在我們將模型部署到生產環境後，我們可以使用 SageMaker 的Model Monitor及時持續監控模型質量指標，並在偵測到data drift等偏差時向發出通知。

對於batch predicitions，SageMaker 會初始化request的compute instance數量並分配inference workload，包括在這些instance之間拿到大的test dataset的預測。batch transform jobs建立與input file相同數量的output file，並帶有額外的 .out 副檔名。我們可以通過調整控制接收的最大有效payload、最大的concurrent transforms或使用的batch strategy的參數來減少執行大規模batch transform job所需的時間。

在Production中變得重要的model deployment的其他功能如下：

Endpoint Autoscaling — 動態的調整我們模型使用的instance數量，以符合我們不斷變動的workload。

Model Compilation— SageMaker Neo可以在cloud或 edge device上有效的優化我們的模型。

Elastic Inference(EI) — EI 讓我們使用GPU加速器加到我們的hosting instance，並支援任何TensorFlow, MXNet, PyTorch, 或 ONNX model。

Inference Pipeline — 部署最多五個container的linear sequence，這些container對傳入的data 執行steps。 通常，這個 sequence可能涉及需要及時完成的preprocessing step, model prediction step, 還有 post-processing step。

SageMaker Model Registry — 產生catalog model、管理版本、添加和管理模型的手動核准步驟，以及使用CI/CD自動化模型部署。

案例:使用 A/B 測試部署

已經擁有託管模型的客戶想要測試具有roduction流量的新版本。 為此，客戶更新endpoint配置並將 10% 的流量轉移到新的生產版本(如下圖)。

AWS ML Devices

這裡，我們將簡單的介紹屬於ML Stack的設備：

AWS DeepLens
DeepLens 生態系統通過為我們提供一個full programmable video camera和幾個預先訓練好的模型和範例，主要是了解vision system和深度學習。

AWS DeepRacer
DeepRacer 生態系統可以使用全託管的模擬和訓練環境以及可以運行訓練模型的 1/18 比例 RC（賽車）車來了解reinforcement learning。

AWS DeepComposer
DeepComposer 是一款full programmable MIDI 鍵盤，可讓您使用GAN(生成對抗網路) 播放、錄製、訓練和生成音樂。

AWS Panorama Device and SDK
這允許我們將基於computer vision的Application加到 IP camera steup中。 可以平行分析來自多個camera的video feeds，根據我們使用 SageMaker 在cloud上訓練和compile的模型產生預測。

總結

如我們在本文中介紹的，機器學習具有廣泛的應用，例如分析images和video以獲得insights、mining text data, translating and transcribing speech, enterprise search, personalization等。我們已經認識到，Rekognition、Personalize、Forecast、Transcribe 等 AI 服務可以輕鬆建立這些 ML Application，只需很少的先備 ML 知識或只需少量的代碼。

也就是說，有時 ML 開發人員需要靈活的訓練自己的演算法、調整hyperparameters、探索和分析ML data，然後將這些模型部署到Production中。這需要一些 ML 知識和編寫code來開發演算法。而時 AWS SageMaker 的就登場了； SageMaker 讓資料科學家專注於資料和 ML 模型開發，同時從中底層基礎設施需求脫離出來。

最後，我們已經看到即使部署了模型，人們通常也需要檢查 ML 模型產生的結果。像Augmented AI這樣的服務可以讓人類參與ML 工作流程中的循環，以檢查模型效能。