在學生時代擔任過課表明的童鞋,不妨發個評論示意一下。html
幫助老師收做業、髮捲子、交流傳達與學習有關的各項事宜……課表明的存在確實幫助老師減輕了不小的負擔。git
當你走上工做崗位,尤爲是,當你開始從事與機器學習有關的項目時,面對模型那複雜、繁瑣、耗時的訓練工做,有沒有考慮過請一個課表明來分擔分擔?畢竟都是爲了提升學習質量。吶,這個模型的訓練過程存在異常,那個模型的結果數據有質量問題,這時候,若是有個「課表明」能及時告知你,是否是感受輕鬆了很多。github
能夠勝任機器學習監督工做的「課表明」,這就來了!算法
Amazon SageMaker 模型監控器,這是 Amazon SageMaker 的一項新功能,能夠自動監控生產中的機器學習(ML)模型,並在出現數據質量問題時發出警報。數據庫
該功能的出現徹底是爲了幫助咱們盡一切可能關注數據的質量。畢竟,若是在訓練結束並出現異常後,花費數小時排查問題,最後發現居然是意外的 NULL 值或不知怎麼就到了數據庫中的一個外來字符編碼致使的,這該讓人多鬱悶。apache
因爲模型其實是根據大量數據構建的,所以也就不難理解,爲何ML從業人員會花費大量時間來維護數據集。尤爲是,須要花費大量時間和精力來保證訓練集(用於訓練模型)和驗證集(用於測量模型的準確性)中數據樣本具備相同的統計屬性。json
但光這樣還不夠,儘管咱們能夠徹底控制實驗數據集,但對於模型將要接收的真實數據就不是那回事了。固然,這些數據將是未經清理的,但更使人擔心的問題是「數據漂移」,即所接收數據的統計性質發生漸變。最小值和最大值、平均值、中位數、方差等,全部這些都是決定模型訓練期間作出的假設和決策的關鍵屬性。架構
直覺告訴咱們,這些值的任何重大變化都會影響預測的準確性。設想一下:要是因爲輸入特徵出現漂移甚至缺失,致使一個貸款應用程序預測的金額升高,那多可怕!app
然而這些條件很是難以檢測:咱們須要捕獲模型接收的數據,運行各類統計分析,以將這些數據與訓練集進行比較,定義規則以檢測漂移,並在發生漂移時發出警報…… 更麻煩的是,之後每次更新模型後,上述全部工做都要從新來過。專家級 ML 從業人員固然知道如何構建這些複雜的工具,但卻要花費大量時間並耗費大量資源。這不就是眉毛鬍子一把抓麼……框架
爲了幫助全部客戶專一於創造價值,AWS 構建了 Amazon SageMaker 模型監控器。
讓咱們經過一個例子來展現一下該功能的價值吧。典型的監控會話以下:
首先,咱們要從 SageMaker 的終端節點(可使用現有終端節點,也可專門爲了監控目的建立新終端節點)開始。咱們能夠在任何終端節點上使用SageMaker模型監控器,不管模型是從內置算法、內置框架,仍是從本身的容器訓練而來。
藉助 SageMaker 開發工具包,咱們能夠捕獲發送到終端節點的部分數據(可配置),也可根據須要捕獲預測,並將這些數據存儲在 Amazon Simple Storage Service(S3)存儲桶中。捕獲的數據會附加上元數據(內容類型、時間戳等),咱們能夠像使用任何 S3 對象同樣保護和訪問它。
而後,從用於訓練在終端節點上部署的模型的數據集創建基線。固然,咱們也能夠選擇使用已有的基線。這將啓動 Amazon SageMaker 處理做業,其中 SageMaker 模型監控器將執行如下操做:
使用這些構件的下一步是啓動監控計劃,以使 SageMaker 模型監控器檢查收集的數據和預測質量。不管使用的是內置容器仍是自定義容器,都須要應用許多內置規則,而且報告會按期推送到 S3。這些報告包含在上一個時間段內接收到的數據的統計和架構信息以及檢測到的任何違規狀況。
最後但一樣重要的是,SageMaker 模型監控器會向 Amazon CloudWatch發出與特徵相對應的指標,可用於設置控制面板和警報。CloudWatch 的摘要指標也能夠在 Amazon SageMaker Studio 中看到,固然全部統計數據、監控結果和收集的數據均可以在筆記本中查看和進一步分析。
更多信息以及有關如何經過 AWS CloudFormation 使用 SageMaker 模型監控器的示例,請參閱開發人員指南。
接下來,讓咱們使用通過內置 XGBoost 算法訓練的用戶流失預測模型進行演示。
第一步須要建立終端節點配置以啓用數據捕獲。在這裏,咱們決定捕獲100%的傳入數據以及模型輸出(即預測)。此外還傳遞了 CSV 和 JSON 數據的內容類型。
data_capture_configuration = { "EnableCapture": True, "InitialSamplingPercentage": 100, "DestinationS3Uri": s3_capture_upload_path, "CaptureOptions": [ { "CaptureMode": "Output" }, { "CaptureMode": "Input" } ], "CaptureContentTypeHeader": { "CsvContentTypes": ["text/csv"], "JsonContentTypes": ["application/json"] }
接下來使用常規的 CreateEndpoint API 建立終端節點。
create_endpoint_config_response = sm_client.create_endpoint_config( EndpointConfigName = endpoint_config_name, ProductionVariants=[{ 'InstanceType':'ml.m5.xlarge', 'InitialInstanceCount':1, 'InitialVariantWeight':1, 'ModelName':model_name, 'VariantName':'AllTrafficVariant' }], DataCaptureConfig = data_capture_configuration)
對於已有的終端節點,可使用 UpdateEndpoint API 來無縫更新終端節點配置。
反覆調用終端節點後,能夠在 S3 中看到一些捕獲的數據(爲清晰起見,對輸出進行了編輯)。
$ aws s3 ls --recursive s3://sagemaker-us-west-2-123456789012/sagemaker/DEMO-ModelMonitor/datacapture/DEMO-xgb-churn-pred-model-monitor-2019-11-22-07-59-33/ AllTrafficVariant/2019/11/22/08/24-40-519-9a9273ca-09c2-45d3-96ab-fc7be2402d43.jsonl AllTrafficVariant/2019/11/22/08/25-42-243-3e1c653b-8809-4a6b-9d51-69ada40bc809.jsonl
這是其中一個文件中的一行:
"endpointInput":{ "observedContentType":"text/csv", "mode":"INPUT", "data":"132,25,113.2,96,269.9,107,229.1,87,7.1,7,2,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,1,0,0,1", "encoding":"CSV" }, "endpointOutput":{ "observedContentType":"text/csv; charset=utf-8", "mode":"OUTPUT", "data":"0.01076381653547287", "encoding":"CSV"} }, "eventMetadata":{ "eventId":"6ece5c74-7497-43f1-a263-4833557ffd63", "inferenceTime":"2019-11-22T08:24:40Z"}, "eventVersion":"0"}
看上去沒什麼問題了。接下來讓咱們爲此模型建立一個基線。
這是一個很是簡單的步驟:傳遞基線數據集的位置以及存儲結果的位置。
from processingjob_wrapper import ProcessingJob processing_job = ProcessingJob(sm_client, role). create(job_name, baseline_data_uri, baseline_results_uri)
完成這項工做後,能夠在 S3 中看到兩個新對象:一個用於統計信息,一個用於約束。
aws s3 ls s3://sagemaker-us-west-2-123456789012/sagemaker/DEMO-ModelMonitor/baselining/results/ constraints.json statistics.json
constraints.json 文件告訴了咱們推斷出的訓練數據集的架構(不要忘記檢查它的準確性)。每一個特徵都分了類,此外還能夠得到有關某個特徵是否始終存在的信息(此處1.0表示100%)。如下是該文件的前幾行內容:
{ "version" : 0.0, "features" : [ { "name" : "Churn", "inferred_type" : "Integral", "completeness" : 1.0 }, { "name" : "Account Length", "inferred_type" : "Integral", "completeness" : 1.0 }, { "name" : "VMail Message", "inferred_type" : "Integral", "completeness" : 1.0 }, { "name" : "Day Mins", "inferred_type" : "Fractional", "completeness" : 1.0 }, { "name" : "Day Calls", "inferred_type" : "Integral", "completeness" : 1.0
在該文件的末尾能夠看到 CloudWatch 監控的配置信息:將其打開或關閉、設置漂移閾值等。
"monitoring_config" : { "evaluate_constraints" : "Enabled", "emit_metrics" : "Enabled", "distribution_constraints" : { "enable_comparisons" : true, "min_domain_mass" : 1.0, "comparison_threshold" : 1.0 } }
statistics.json 文件顯示了每一個特徵(平均值、中位數、分位數等)的不一樣統計信息,以及終端節點接收的惟一值。示例以下:
"name" : "Day Mins", "inferred_type" : "Fractional", "numerical_statistics" : { "common" : { "num_present" : 2333, "num_missing" : 0 }, "mean" : 180.22648949849963, "sum" : 420468.3999999996, "std_dev" : 53.987178959901556, "min" : 0.0, "max" : 350.8, "distribution" : { "kll" : { "buckets" : [ { "lower_bound" : 0.0, "upper_bound" : 35.08, "count" : 14.0 }, { "lower_bound" : 35.08, "upper_bound" : 70.16, "count" : 48.0 }, { "lower_bound" : 70.16, "upper_bound" : 105.24000000000001, "count" : 130.0 }, { "lower_bound" : 105.24000000000001, "upper_bound" : 140.32, "count" : 318.0 }, { "lower_bound" : 140.32, "upper_bound" : 175.4, "count" : 565.0 }, { "lower_bound" : 175.4, "upper_bound" : 210.48000000000002, "count" : 587.0 }, { "lower_bound" : 210.48000000000002, "upper_bound" : 245.56, "count" : 423.0 }, { "lower_bound" : 245.56, "upper_bound" : 280.64, "count" : 180.0 }, { "lower_bound" : 280.64, "upper_bound" : 315.72, "count" : 58.0 }, { "lower_bound" : 315.72, "upper_bound" : 350.8, "count" : 10.0 } ], "sketch" : { "parameters" : { "c" : 0.64, "k" : 2048.0 }, "data" : [ [ 178.1, 160.3, 197.1, 105.2, 283.1, 113.6, 232.1, 212.7, 73.3, 176.9, 161.9, 128.6, 190.5, 223.2, 157.9, 173.1, 273.5, 275.8, 119.2, 174.6, 133.3, 145.0, 150.6, 220.2, 109.7, 155.4, 172.0, 235.6, 218.5, 92.7, 90.7, 162.3, 146.5, 210.1, 214.4, 194.4, 237.3, 255.9, 197.9, 200.2, 120, ...
如今,讓咱們開始監控終端節點。
一樣的,咱們只須要調用一個 API:爲此需爲終端節點建立一個監控計劃,並傳遞基線數據集的約束和統計文件。若是須要調整數據和預測,還能夠傳遞處理前和處理後函數。
ms = MonitoringSchedule(sm_client, role) schedule = ms.create( mon_schedule_name, endpoint_name, s3_report_path, # record_preprocessor_source_uri=s3_code_preprocessor_uri, # post_analytics_source_uri=s3_code_postprocessor_uri, baseline_statistics_uri=baseline_results_uri + '/statistics.json', baseline_constraints_uri=baseline_results_uri+ '/constraints.json' )
而後開始將假的數據發送到終端節點,即根據隨機值構造的樣本,而後等待 SageMaker 模型監控器開始生成報告。
很快,能夠看到報告已經出如今 S3 中。
mon_executions = sm_client.list_monitoring_executions(MonitoringScheduleName=mon_schedule_name, MaxResults=3) for execution_summary in mon_executions['MonitoringExecutionSummaries']: print("ProcessingJob: {}".format(execution_summary['ProcessingJobArn'].split('/')[1])) print('MonitoringExecutionStatus: {} \n'.format(execution_summary['MonitoringExecutionStatus'])) ProcessingJob: model-monitoring-201911221050-df2c7fc4 MonitoringExecutionStatus: Completed ProcessingJob: model-monitoring-201911221040-3a738dd7 MonitoringExecutionStatus: Completed ProcessingJob: model-monitoring-201911221030-83f15fb9 MonitoringExecutionStatus: Completed
讓咱們找到其中一個監控做業的報告。
desc_analytics_job_result=sm_client.describe_processing_job(ProcessingJobName=job_name) report_uri=desc_analytics_job_result['ProcessingOutputConfig']['Outputs'][0]['S3Output']['S3Uri'] print('Report Uri: {}'.format(report_uri)) Report Uri: s3://sagemaker-us-west-2-123456789012/sagemaker/DEMO-ModelMonitor/reports/2019112208-2019112209
而後看看這裏面到底有什麼:
aws s3 ls s3://sagemaker-us-west-2-123456789012/sagemaker/DEMO-ModelMonitor/reports/2019112208-2019112209/ constraint_violations.json constraints.json statistics.json
顧名思義,constraints.json 和 statistics.json 包含監控做業處理的數據樣本的架構和統計信息。讓咱們直接打開第三個文件 constraints_violations.json!
violations" : [ { "feature_name" : "State_AL", "constraint_check_type" : "data_type_check", "description" : "Value: 0.8 does not meet the constraint requirement! " }, { "feature_name" : "Eve Mins", "constraint_check_type" : "baseline_drift_check", "description" : "Numerical distance: 0.2711598746081505 exceeds numerical threshold: 0" }, { "feature_name" : "CustServ Calls", "constraint_check_type" : "baseline_drift_check", "description" : "Numerical distance: 0.6470588235294117 exceeds numerical threshold: 0" }
糟糕!咱們好像給整數型特徵分配了浮點值,結果可想而知……
一些特徵還表現出了漂移現象,這也不是一個讓人樂見的狀況。也許數據提取過程出了點問題,也許數據的分佈實際上已經改變而須要從新訓練模型。因爲全部這些信息均可以做爲 CloudWatch 指標提供,所以咱們能夠定義閾值,設置警報,甚至自動觸發新的訓練做業。
Amazon SageMaker 模型監控器易於設置,可幫助咱們快速瞭解ML模型中存在的質量問題。
目前,該功能已在提供 Amazon SageMaker 的全部商業區域推出。此功能還集成在了 Amazon SageMaker Studio(AWS 的 ML 項目工做臺)中。而且別忘了:全部這些信息均可以在筆記本中查看並進一步分析。
敬請你們親自嘗試!