- Done is bertter that perfenct
- 桶谷さん
- IT土方からスタート
- HighBall
- AWS ML Platform
- Echo
- #jawsug
- 機械学習システムに必要となる改善サイクル
- 問題を明らかにするのが大切
- ブレるとなにも使えなくなる
- モデルは一度作って終わりでは決してない
- 室の良い学習データが必要
- 解決したいビジネス課題を明確にする
- 機械学習を目的にしてはだめ
- 他の手段を試す
- 良質なデータが不可欠
- 大量の過去データをもとに未来の値を予測するのが基本
- データの中身がきちんと管理されている必要がある
- モデルは1回作って終わりではない
- 既存モデルでカバーできない部分がでてくる
- ビジネスの状況が変わってくる
- 新しいサイクルを高速に行えるようにしておく
- 1回やって満足して終わるケースも多い
- デプロイ後にさらに分析していく
- データレイクと自動化が必須
- GPUが必要だがクラウド利用でハードの問題は解決へ
- 構築したいモデルによって複数の異なる開発環境が必要
- どのアプローチが最適か試して見ないとわからない
- 開発と本番環境がことなる
- 開発はデータサイエンティストがR、エンジニアが本番用にJavaでとか
- Tensorflowのバージョン違い
- モデル作成後にすぐにデプロイできない
- デプロイが手作業
- アプリ組み込みで結合テストが必要
- デプロイが他サービスに影響
- 学習したモデルが再現できない
- 新しいモデルをデプロイしたら悲惨な状況に
- 構築プロセスは自動化できる必要がある
- 複数のモデルを同時に学習させて精度を比較する
- 繰り返しの学習プロセスを最小限の時間・開発コストで効率よく行う必要がある
- 結果のモニタリングが重要
- 結果のABテストも必要
- 精度が上がっていなければ、ロールバックが必要
- モデルの再学習や開発環境の再構築も必要
- DevOpsの考え方が必要
- インフラテクチャー as Code
- マイクロサービス
- Continuus Delivery (CD)
- 継続的なデプロイ・自動化
- 機械学習へのDevOps適用
- モデルとアプリが密結合されすぎてるとデプロイが困難になる
- 通常と機械学習でのDevOpsの違い
- 複数モデルとパラメータを並列で回して比較を行うというプロセス
- バージョン管理にはコードや環境だけでなく学習データも合わせて管理
- データ整備、モデル構築、開発・運用など複数チームが協働
- 本番で複数モデルのABテスト実施するのが一般的なやり方
- インフラテクチャー as Code
- マイクロサービス
- モデル部分のみマイクロサービス化
- Continuus Delivery (CD)
- デプロイ結果をモニタリング
- インフラテクチャー as Code
Amazon ECR
- Code Build
- Code Commit
- マイクロサービス
- SageMaker
- ECS
- Continuus Delivery (CD)
- SageMaker
-
汎用的なモデルAPIを利用する(AWS MLS)
- 画像認識
- 自然言語理解
- テキスト翻訳、チャットボット
- 学習済みのモデルが提供されている
-
SageMaker
- 機械学習のモデル作成のマネージドサービス
- 開発・学習・推論の3つを全部、一部利用が可能
- 分散学習も可能
- サーバサイドのリアルタイム推論
- リアルタイムのコンテンツ推論
- サーバサイドのバッチ推論
- エッジサイドのリアルタイム推論
- エッジ側にモデルを配置
- GreengrassでLambda実行
- データをあつめるところはS3
- StepFunctionsでモデル更新の自動化
- データ加工も含めて管理
- ワークフローエンジンはAWS外でも可能
- 複数モデル学習時の精度評価
- Cloudwatch経由でLambdaで比較
- モデルを含めたリソース管理
- ABテストと効果測定
- Kinesis経由で測定
- バッチ解析はS3+Athenaとか
- クラウド・オンプレのハイブリッド
- Direct Connect
- かならず継続的な改善サイクルができるように
- 自動化しないと辛いことになる
- 機械学習は課題解決のための1つの手段
- AWSのjob募集ページがある