みなさん、こんにちは、えいりんぐーです。
だいぶ時間が空きましたが、5月29日に行われた Machine Learning Casual Talks #10 に参加したので、そのレポートをしたいと思います。
chezou さん
まず初めに運営の chezou さんからです。
- MLCTをなぜはじめたか
- 実務的な知見の共有をしたい
- 地味で泥くさくてツライところを話してほしい
とのこと。実際、現場で機械学習をやる話はここ2~3年で増えて来ている気がします。
はて部のひと
syou6162さんです。わざわざ京都から来たらしいです。内容はMarckerelの異常検知についてです。Mackerel はサーバー監視管理サービスです。要件やニーズにあった実装をしている点が参考になりました。あと、LIMEやSHAPといった知らない言葉が出て来て勉強になりました。
- 異常検知
- 障害は少ないので教師有がむずかしい
- 教師なし学習
- 機械学習によって異常検知機能を作りたい
- 前提:どの単位でモデルを学習するか?
- サーバー横断
- 役割が様々、学習が難しい、誤検知も多い
- 個々のサーバー
- 学習は容易、同じようなデータならまとめるほうがいい
- ロール毎
- 粒度がちょうどいい
- サーバー横断
- 要件:モデルが軽量、根拠がわかる、誤検知を減らす
- ロール、中間の判定用APIサーバー、モデルというアーキテクチャ
- メモリにモデルを持っておけない
- 予測ごとにロード
- レイテンシも低くしたい
- GMMを使う、軽い速い
- 障害の状況がぱっと理解できるといい
- 誤検知を減らす
- ほかの監視ルールでカバーできる
- 想定内の変動を事前分布に入れておく
- システムの評価
- 実際に起きたアラートを人手でアノテーション
- 誤報率のトラッキング
Q&A
リクエストごとにモデルをロードするノウハウ、レイテンシを下げるには?
混合数の調整やシステムメトリックでカバーできるところはそうする
誤検知かどうかの事後学習どうする
ユーザーごとのチューニング、難しい
時系列の異常検知は?
GMMだからある程度対応できる
モデルの運用は?
2~3日ごとにお客さんのモデルを再学習している。
DynamoDBでTTLして揮発する。サポートのために念のため前のモデルも残す。
メルカリの人
dkumazawaさんで、NASによるモデル作成の高速化の話です。スタンフォードの修士学生で、今は休学してインターンをしているそうです。熱心ですね。質問し損ねたのですが、精度の基準策定やデプロイの可否はだれが決めていたのでしょうか。
- 規約違反の出品を見つけたい
- プレシジョンは高くしたい
- 課題
- 規約や法令が変化する。e.g. チケット不正転売禁止
- マルチモーダルの難しさ。データの意味が異なる
- 要求
- モデリングからデプロイまで自動でやってくれる仕組みが欲しい
- NASは重い
-
DARTSを使う
- 画像とテキストを使う
- 1枚のGPUで2日、確かにFeasible
- データをフィードしたら勝手にトレーニング・評価・サービングまでやってほしい
- モデリングからデプロイまで自動でやってくれる仕組みが欲しい
- yaml書けばできるようにした
- 内製のETLに組み込む
Q&A
違反データの変更、ラベリング・アノテーションはどうなってるのか?
データや特徴量設計は手動。
NASをNLPのみを対象にしたのは?
画像は処理と学習が重く、優秀な学習済みモデルがあるが、NLPに適用したものはベストプラクティスが定まり切っていないため。
規約の変更によるアノテーションどうする?
サポートががんばってやってくれている。
人の手の温もりが感じられます涙
リクルートコミュニケーションズ
宮井さんでデータ分析基盤Croisの話です。工作が趣味、マーケットフェアにも行ったそうです。工作パパらしいです。会社名ってズまで入るんですね。
- Croisが提供するもの
- コンテナの実行基盤
- コンテナのカタログ
- ワークフローエンジン
- API
- 実行エンジン
- AWS BatchとStepFunction
- yamlで書けば実行できる
- メリット
- ジョブ実行の制御を任せられる
- スケーラビリティが高い
- デメリット
- ジョブの状態をAPI側でもてない
- ダイナモで同期処理
- Batchはインスタンス起動に時間がかかる
- ジョブの状態をAPI側でもてない
- セキュリティ
- プロジェクトごとにKMSとロール
- デクリプトが対応ロールでしかできない
- S3はKMSで暗号化される
- 詰まったところ
- API制限で引っかかる
- Batch, StepFunction, KMS&Role
- モジュール開発用のリポジトリ
- 1リポジトリで複数のモジュール
- git diffで頑張る
- API制限で引っかかる
- 良かったところ
- Croisという名前をつけたこと
- 自然と名前が広まった
- エバンジェリストも現れた
- Croisという名前をつけたこと
Q&A
Droneを使う理由は?
エンジニアチームでメジャーなCIなのと、コンテナベースであることから。
Supershipの人
ニシヤマさん。アドテクの会社で働いているそうです。内容はdatabricksでノートブックでお手軽機械学習の話です。
- 普段は広告配信ログとかを扱う
- データがでかい
- アナリスト多いけどエンジニア少ない
- Sparkを使おう
- 既製品使うことでエンジニア負担を減らす
-
databricks
- 統合分析プラットフォーム、Jupyterみたいなもの
- pandasとかSparkとかいろいろ入ってる
- Jobs機能
- スケジュール機能とかAPI化とかできる
- 任意のワークスペースと同期したりできる
- databricksがよしなに巻き取ってくれるので楽
- 新しい機能も楽しみ
メルカリの人
中河さんで、画像検索システムの裏側の話です。画像検索システムは商品名を知らなくても画像から調べられる機能です。ディープラーニング勢強いですね。ANNは知らなかったです。
- 仕組み
- DNNで特徴ベクトルを作る
- 特徴ベクトルをANNへ
- ANN indexとは?
- Approximate Nearest Neighbor
- 基盤にはLykeion使ってます。
- 画像のダウンロードが一番時間がかかる
- k8sでインフラを抽象化している
- AWSもGCPも関係ない
- k8sの機能は活用
- CRD controller, Batch Execution, Service Discovery
informetisの人
蓮尾さん、電力データ活用ビジネスの話です。少ない社員 (10名くらい?) でニッチな分野ながらも国際的にやっているようです。WEBやスマホ系サービスでない事業の話は新鮮で面白いですよね。家電やセンサーの気持ちになるとは...
- エネルギーデータ分析
- ブレーカーに電力情報が流れてくる
- それをデバイスごとに分離する、推定する
- 課題
- 24時間365日
- リアルタイム
- 負荷が状況で不均一
- ソリューション
- Kubernetes
- Pub/Sub
- 問題点
- 電流が重なると足し合わせになって難しい
- 画像は重なってもまあ切り分けられる
- 物理現象やデータの生成過程を考慮するとヒントがある
- 家電の気持ちになる、センサーの気持ちになる
- 未知データ・新型家電
- あるいは古い家電
- イテレーションをいかに回せるか
- 海外の家電は全然違う
- 電流が重なると足し合わせになって難しい
- 技術的な抑えどころ
- 問題設定、入口を正しく
- データセットの精査、リーケージ回避
- 評価整備・課題整理、出口を正しく
Q&A
どんなモデル使っていますか?
秘密だけど、ファクトリアルHMM、それだけだと難しいからプラス機械学習
全体の感想
このところ機械学習系のミートアップで話される内容は、感覚としては、実務的な話題は大きく4つに分類されて、
- 機械学習の性能をどうやったら改善できるか
- 機械学習を使ったシステムの学習とデプロイ基盤について
- データや分析の基盤をどうするか (上とは微妙に要点が異なる)
- データ分析や機械学習を使うプロジェクト運営をどうするか
というところになっているのかなーと感じました。
今回も基盤寄りの話が多く、特に事業会社さんではPOCの域を越えて、どう運用を楽にするかといったところに焦点が当たっているようです。
色々と新しく知ったことも多く、楽しい会でした。