為什麼說AWS釋出的SageMaker會是一個大殺器？

作者丨楊賽

2014 年，AWS 在 re:Invent 上釋出 Lambda 服務的時候，很多開發者尚未意識到這個服務能給他們帶來怎樣的好處。時隔三年，Lambda 服務已經成為了“Serverless”和“Function as a Service”開發範式的代表，并且已經承擔起為數不少的企業關鍵業務。可以說，Lambda 服務為應用開發領域開辟了一片全新的遊戲場地。

在 InfoQ 編輯看來，AWS CEO Andy Jassy 在今年的 re:Invent 大會上釋出的 Amazon SageMaker 也是一個改寫遊戲方式的關鍵标志，而這一次的遊戲場地是在人工智能領域（2017 年 AWS re:Invent 的産品釋出清單見之前的這篇報道）。

http://www.infoq.com/cn/news/2017/11/aws-reinvent-2017-andy-announce

在 2017 年的今天，阻礙人工智能技術被廣泛應用的最主要的門檻是什麼？

晶片、架構、算法、資料量？這些領域當然還有很大成長空間，但很難說是目前的最大門檻。有人說，最大的門檻是準确率還不夠，尤其是 toC 領域的自然語言處理這樣的場景，機器對人的表達方式的了解還遠遠達不到可以正常交流的水準。對于這個準确率的問題，每個體驗過相關服務的讀者應該都有自己的判斷。但如果說這個問題為真，那麼下一個問題是：為什麼在這些領域，準确率提高得還不夠快？

用機器學習來解決一個問題是建立在一個假設之上：針對任何一個問題，我們是能夠根據固定數量的變量，得到一個足夠好的模型，進而對其進行有效的解釋與預測的。是以，基于這樣的一個假設，那麼準确率低的問題，就是一個模型不夠好的問題。

模型不夠好有很多原因，可能是因為訓練資料不夠，也可能是因為算法不合适，或者算法的參數沒選擇到最合适的組合。訓練資料不夠，就要多采集資料、多存儲資料、多清洗資料。算法不合适，可能是因為參數的調試還沒做到位，可能因為參數的調試需要耗費太多時間和其他成本是以在一個局部最優解就停下了，也可能是因為使用的架構（引擎）不合适。至于哪個架構更合适，可能需要多試幾個架構，乃至于可能目前市面上流行的架構都不合适，需要一個新的架構。

對于以上各種可能的問題來源，Andy Jassy 提出了一個也許是更根本的問題：

也許，我們在模組化這個層面的人手太少了？

根據 InfoQ 編輯所了解，目前市面上有一些業務做得很好的大資料公司，他們的技術團隊 / 資料團隊有 80% 的精力都用來做什麼工作呢？

資料準備。

剩下的 20% 精力，又有很大部分是用在部署叢集、安裝架構、調優這些“雜活兒”上面了。

從目前的客觀情況來看，這是把資料分析業務做好的一個基本功。然而從理想世界的角度來看，這樣的現狀是相當驚人的浪費。AI 領域大牛李飛飛，她有多少時間是用在改進架構和算法上，有多少時間是投入到标記那 320 萬張圖檔上？

這就好比在雲計算出現之前，一個開發者想要開發一個應用，可能 80% 的時間是用在買伺服器、安裝作業系統、調試資料庫、部署擴容備份等等跟開發應用無關的事情上了。現在的資料領域，跟那個年代的應用開發領域其實是非常相似的——一半以上的時間都不是用來産出的。

有些開發者可能還沒動手就被這些麻煩事兒吓跑了。堅持在這個領域深耕的資料科學家們，他們的精力也用不到刀刃上。這就是 AWS 釋出 SageMaker 的立場：讓有能力去改進架構和算法的開發者，盡可能少花費精力在那些跟主業無關的事情上。

簡單的看一下 SageMaker 的基本用法——如何訓練一個模型。以下内容來自 AWS 布道師 Randall Hunt 釋出的部落格。

首先，在 AWS 的背景建立一個 Notebook 用來放置你的代碼和一些配置資訊。建立好的 Notebook 下面會自帶一個叫做 sample-notebooks 的目錄，裡面包含了一些預置的算法：

無論是哪種算法，代碼大緻上是下面這個結構：

def train( channel_input_dirs, hyperparameters, output_data_dir, model_dir, num_gpus, hosts, current_host): # 給訓練代碼占座 pass def save(model): # 找個地方儲存模型檔案 pass
           

首先，channel input dirs：訓練資料從哪兒來？可以是本地的一個目錄，也可以是雲端的。自從 S3 支援對象級别的查詢之後，S3 在這幾年已經變成一個挺流行的 Data Lake 選項。現在有了新釋出的 S3 Select，這個 Data Lake 的查詢變得更高效了。而且現在還有了 Glacier Select，于是那些冷資料也可以直接被拿來當作訓練資料（題外話：Andy Jassy 說這兩個 Select 功能是研發了一年的時間做出來的。你怎麼看？我真心覺得還挺快的。）

然後，hyperparameters：這一個步驟就是 SageMaker 的第一個魔法所在了。看看教程中是怎麼定義這個 hyperparameter 的：

hyperparameters={ 'batch_size': 128, 'epochs': 50, 'learning_rate': 0.1, 'momentum': 0.9 }
           

傳統來說，這些 hyperparameter 的初始設定可能對最終的模型品質有很大的影響。比如這個 learning rate，如果設定太低，則學習得太慢；如果設定太高，可能壓根跑不出來結果。于是乎，資料科學家們不得不一次又一次的試錯，一直試錯到他們覺得足夠好，或者他們覺得足夠煩了為止。

SageMaker 的第一個魔法就在于這一個步驟的自動化：把試錯這件事交給機器來做，直到機器認為足夠好了為止——機器可是從來都不會厭煩的。

其餘的訓練參數定義比較直覺，就不多介紹了。要跑訓練的時候，假設你要用 MXNet 這個架構配合一個你寫好的 cifar10 算法，那麼你就這麼寫（點選這裡檢視 AWS 提供的 sample notebook - cifar10.py 檔案的詳細内容，以及 AWS Github 賬号上的 SageMaker Python SDK。這個檔案使用了 Gluon API。）：

import sagemaker from sagemaker.mxnet import MXNet m = MXNet("cifar10.py", role=role, train_instance_count=4, train_instance_type="ml.p2.xlarge", hyperparameters={'batch_size': 128, 'epochs': 50, 'learning_rate': 0.1, 'momentum': 0.9})
           

現在，可以把訓練資料丢給它了：

m.fit("s3://randall-likes-sagemaker/data/gluon-cifar10")
           

于是你就有了四個 P2 執行個體開始幫你跑訓練了！當訓練跑完的時候，你就有了一個模型 m，可以拿來做預測了。至于這四個 P2 執行個體，它們會被自動釋放，不用去管它們。這是 SageMaker 的第二個魔法：忘記你的伺服器，也不用折騰各種架構的安裝部署這些底層工作。SageMaker 上的這些架構都是已經優化好的，你自己部署的話，效果多半不會比它更好。

預測的執行也僅僅需要下面這一個指令，不需要在主機層面搞東搞西：

predictor = m.deploy(initial_instance_count=1, instance_type='ml.c4.xlarge')
           

比如，可以把想要做預測的線上實時資料——比如一張 Twitter 上的新照片——通過一個 Flask App 丢過去：

@app.route('/invocations', methods=["POST"]) def invoke: data = request.get_json(force=True) return jsonify(predict.download_and_predict(data['url']))
           

然後你就可以得到你的預測結果——比如說，這張照片的拍攝地點。

那麼你要問了，SageMaker 對于資料準備這個最大的“雜活兒”有啥幫助呢？

SageMaker 有一個 preprocess 資料的功能。至于這個功能能做到什麼程度，還得試試才知道，詳細情況可以參考這個文檔。我想，恐怕暫時還不能跟那些專門提供資料準備服務的品質相比，因為這個文檔裡面同時也推薦了 Marketplace 上的相關服務。

不過，能夠節省下建立執行個體、安裝架構、訓練試錯這些方面的工作，已經是一個很大的進步。現在，開發者隻要有一個 AWS 賬号就可以體驗 SageMaker，而且現在是有兩個月的免費額度的，正是嘗鮮的最佳時機。AWS 的開發者文檔網站已經更新了 SageMaker 的詳細說明，可以在此檢視：

https://aws.amazon.com/blogs/aws/sagemaker/

期待看到 SageMaker 之後的發展情況。