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): # 給訓練代碼佔座 passdef 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 sagemakerfrom sagemaker.mxnet import MXNetm = 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 之後的發展情況。