Amazon SageMaker

SageMaker の ハンズオンに参加。

内容は初心者向けでしたが、私には非常に効果的なレベル。というかギリセーフでした。半年前なら全く理解できていなかったでしょう。
参加者の顔ぶれを見ると働き盛りの若い方が多く、健全な分野と感じます。講習会といえばおじさんばかりの建設業界の異常さをあらためて認識させられました。

以下、備忘録です。
****************************************
フロー
①Sagemaker で開発
②Dodker 利用で学習環境に移行、学習、API化
③推論は API 利用
開発・学習はSagemaker、推論はオンプレミスというように、部分利用可

アルゴリズム
①AWS ビルトイン利用
・学習データのみ
②TensorFlow 等、一般的なモデルを使用
・学習データと開発したコードが必要
・Docekerでコンテナ作成
③それ以外
・学習コードと推論用 Web サーバが入ったコンテナを ECR に push
・学習データは S3 へ


開発と学習・・・データサイエンティストが SageMaker SDK を使ってJupyterで。
デプロイ~推論・・・機械学習と関連のないエンジニアリングが大半・・・インフラエンジニアが AWS SDK を利用
役割の違うチームがそれぞれに合ったツールを利用

ビルトインで気になったアルゴリズム・・・Image Classification（教師あり）
・ゼロからトレーニング or 大量のデータを用意できない場合に転移学習を使用
・ResNet を使用。
https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-algo-docker-registry-paths.html


学習時のＴｉｐｓ

・分散学習
instance_count を2以上で自動で分散学習
⇒基本はデータを分割
Tensorflow/Chainer/PyTorch/MXNet → instance_countに加えてコードも分散学習に対応させる必要あり。

・ハイパーパラメーターの自動チューニング
Estimater 初期化時に hyperparameters で引き渡すパラメータに関し自動チューニング
Tensorflow/Chainer/PyTorch/MXNetでも利用可

・学習ジョブの評価
CloudWatchLogs、後から集計

・Tensorflow
AWS 側で Tensorflow の分散学習に最適な Docker コンテナイメージ用意
https://github.com/aws/sagemaker-tensorflow-container

・大量データの読み込みにpipeモード
PIPE：学習用データを必要なタイミングで必要な分だけ S3 API 経由でストリーム処理
Tensorflow ： TFRecord フォーマット
MXNet ： RecordIO フォーマット


推論時のTips
・オートスケーリング
・Tensorflow
AWS 側で Tensorflow の推論に最適な Docker コンテナイメージ用意


セキュリティ
学習時の入出力データ、インスタンス、ストレージ、バッチ推論時の入出力データは暗号化可能

amazon-sagemaker-examples
https://github.com/awslabs/amazon-sagemaker-examples
SageMaker SDK
https://github.com/aws/sagemaker-python-sdk

出席者
Tensorflow 半数
次いでChaneir 、Keras
Pytorch　０
MXnet ０


不要な課金を避けるため、
エンドポイントの削除
ノートブックの削除
※停止でも良いが、S3に保存したデータは課金される
s3の削除
ログの削除
※ログは微々たるもの。置いたままでもOK
※トレーニングジョブは課金対象でなく、日がたつと自動で削除される。
ロールを削除
※課金対象ではない。

AWS 新サービス

昨日、AWSを触っていて、新サービスが増えていることに気づきました。

小さなロボットの制御ができるのでしょうか？楽しそうです。

AWS RoboMaker

https://aws.amazon.com/jp/blogs/news/aws-robomaker-develop-test-deploy-and-manage-intelligent-robotics-apps/

災害発生時に衛星へ命令し、データを取得し、SageMaker のモデルに渡して崩壊個所を自動検出、といったことができそうです。衛星を持っていない個人では使えないのでしょうか？

AWS Ground Station

https://aws.amazon.com/jp/blogs/news/aws-ground-station-ingest-and-process-data-from-orbiting-satellites/

他にも様々な発表があったようです。機械学習関連はコチラ。

Amazon SageMaker Neo
https://aws.amazon.com/jp/blogs/news/amazon-sagemaker-neo-train-your-machine-learning-models-once-run-them-anywhere/

AWS マーケットプレイスで機械学習アルゴリズムとモデルのパッケージを提供開始
https://aws.amazon.com/jp/blogs/news/new-machine-learning-algorithms-and-model-packages-now-available-in-aws-marketplace/

Neo はマスターしたいですね。
変化についていくのは大変ですが、頑張りましょう。

as a service

GPU, CUDA, Docker,  など、3時間ほどいじってあきらめたことが、SageMaker なら30分でできました。

うーん。やはり'サービスとして'提供されているものは利用すべきなのでしょうか？心が折れそうになりますが、早々に結果を出せる環境があるなら実務で利用しない手はないでしょう。

Amazon、Microsoft、Googleなどの tech giant が提供するクラウドサービスにより、上記の流れは加速するでしょう。新たなビジネスモデルについていかなくてはなりません。

地質は何？

「地質を説明して」と言われることがあります。

地質屋さんに聞かれた場合は時代と岩種、話の流れで構造を答えておけば問題ありません。が、土木分野での「地質」は広い意味で使われています。

土木分野での「地質」
・岩種（これは地質屋の尋ねる「地質」と同じ。）
・構造（様々なスケールの断層、亀裂、流れ盤なども「地質」です。）
・風化の程度、硬軟（軟岩、硬岩、風化土なども「地質」です。）
・沖積層・洪積層（これは「地盤」にも含まれます。）

力学や透水性といった工学の要素を含んでいる説明が、理解されやすいようです。馴染んでいるのでしょうね。

話しているうちに一つの事象にとらわれ、他の「地質」が頭から離れることがあります。問題解決にはすべての視点、スケールが必要です。何度も振り返りましょう。

pandas

90万行×3列の csv データの処理。

後輩君が EXCEL で開いたものの、ピボットテーブルすら作成できなかったとのこと。もう一方が VBA にて処理するも、10万行くらいでフリーズするとのこと。
32bit 版だから、と思っていましたが 64bit 版でもダメ。ま、大きなデータをEXCELだけで処理しようとすること自体が無謀なのでしょう。

今回はヒストグラムを見たかったので、python＋pandasで処理（実際はmatplotlibをpandasからcallしているようです)。
EXCELシートを読み込んで、ヒストグラムとサマリーを作成。ピボットテーブルを複数作成し、集計・演算を経て、EXCELデータとして保存。
ピボットテーブルの作成では、全データを複数の項目で整理しようとしたケースのみ時間がかかりました。ヒストグラムの作成や演算は軽い。
一番時間がかかるのは、書き込みですね。HDF5 だと速いのですが、EXCELへ持っていけません（書き出せないデータもありましたが）。

pandas を追加するだけ。pandas 偉い。

CNN

大量の画像データから、自動かつ高精度で異常を抽出できると、見逃しリスク低減に役立つでしょう。

ここ数日、画像を取り扱う機械学習手法について調べていました。2012年頃から深層学習による成果が報告され始め、フレームワークの整備され始めた2015年ごろから急速に増えているように感じます。現在、画像を扱う「教師あり学習」では 何らかの形で CNN を利用した手法がデファクトスタンダードになっているといっても良いでしょう。

医療分野においても CNN 全盛です。Medical Image Analysis での CNN の検索本数は以下の通り。

2018 50
2017 32
2016 2
2015 2

マンモグラフィーの画像を扱った例です。
Faster R-CNN

https://www.nature.com/articles/s41598-018-22437-z.pdf

CNN、転移学習、アンサンブル

https://medium.com/stanford-ai-for-healthcare/deep-learning-goes-pink-474c08a77c92

リスク低減手法は多々あると思いますが、その有効な手段の一つにしたいですね。

SCE-UA

報告書を2つ書き上げて、一息。
やるべきことがたまっています。

to-do list
・機械学習手法の特徴整理
・VisualSPHysics・・・ようやくtutorial ができました。
・文献収集・・・医療系画像診断の自動化など
・sagemaker
・タンクモデル、SCE-UA

最後の項目は最適化手法の一つで、タンクモデルで使われてきたようですね。
一連降雨ではピーク以外の時間も多く占めますので、 RMS 最小化の対象になり、ピークがなまってしまうようです。改善するには重み付けが必要です。それを実装した文献はすぐに引っ掛かりました。

杉原他ほか「SCE-UA法を用いたタンクモデルの構築と. それを用いた土砂災害発生危険基準線の設定」
https://www.jstage.jst.go.jp/article/jscejsp/67/1/67_1_1/_pdf

ペナルティ関数（といってもただの重み）を手動で追加しているだけですが、これなら一気に複数の一連降雨、ピークに対して最適化が可能です。理論的ではないですが、実務向きです。

CLによる空振り低下を狙うのに、まず流量を合わせに行くのは手法として正しいのかわかりません。土壌雨量指数の推定精度が改善することと、空振り率低下には理論的繋がりがないからです。現行では、土壌雨量の推定精度が甘くても、CLの選択で調整すればよいでしょ、とも言えます。が、この文献で扱っているケースでは改善していました。たまたまなのか、一般化できるのかはわかりませんが、ある地域に限定すると、その傾向が得られる可能性を示していると思われます。

近年の降雨を用いた RBFN 値の更新とCLの再設定は必要ですから、それらと合わせて土壌雨量指数の精度向上進める手はあると思います。また、この手法であれば自動更新も可能ですよね。今後に期待しましょう。