機械学習を無理なく広告システムに導入する
by
hiroaki
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
機械学習を 無理なく広告システム に導⼊する MLOps勉強会 Fringe81 ⻑⾕川⼤耀
Slide 2
Slide 2 text
⾃⼰紹介 ⻑⾕川⼤耀(@Hase8388) で、機械学習の開発やってます 物理学(⼤腸菌)=> 広告配信(Scala)=> 広告配信(ML)
Slide 3
Slide 3 text
広告配信のビジネスモデル • ユーザー情報を元に、興味がありそうな広告を配信する • お⾦が⼊ってくるのは、広告をclickしたときなので、 よりユーザーが興味がある広告を優先的に表⽰すれば、それだけ 利益に繋がる
Slide 4
Slide 4 text
• ユーザー情報を元に、興味がありそうな広告を配信する • お⾦が⼊ってくるのは、広告をclickしたときなので、 よりユーザーが興味がある広告を優先的に表⽰すれば、それだけ 利益に繋がる 広告配信のビジネスモデル 機械学習でclickする確率(CTR)をより正確に予測すれば 売上に貢献しうる
Slide 5
Slide 5 text
もっと単純なロジックでも良いのでは? 機械学習にすることでメリットは⾮常に多い • メディアなどの傾向が変わってもすぐに柔軟に対応できる • 多くの情報(特徴量)を、より柔軟に予測に活⽤できる • 特徴量やパラメータなど、改善できる⾃由度が増える
Slide 6
Slide 6 text
今⽇話すこと 話さないこと • アルゴリズムのガッツリとした話 • 特定のライブラリ、フレームワークの話 など 機械学習を広告配信システム 上で安定的に動かすための 実装、運⽤⽅法 その上で機械学習システムを 確実に運⽤と改善を ⾏っていくための⼯夫
Slide 7
Slide 7 text
No content
Slide 8
Slide 8 text
広告配信は、ビジネス上の制約も多い 配信側で、モデルを復元/予測を⾏う必要が あるため、配信側(アプリケーション側)のエンジニアと 密な連携が不可⽋ 配信側の開発を⾏うエンジニアと、 どのように齟齬なく、開発をおこなうか? 20ms以内に、最適な広告を決定 し、返却する必要がある
Slide 9
Slide 9 text
1. チーム間で開発前に認識合わせを⾏う • 懸念されるリスクを整理し、対策を考える • 正常/異常のパターンを洗い出し、どちら側で対応するかを決める • ex モデルのメトリクスがおかしい場合、ML側で更新を停⽌します • 配信側でできること/できないことの整理 • 仕様に落とし⽳がないかをチェック • ex xxGBまでは配信のメモリに乗せれるけど、それ以上だと厳しいです • それぞれチームでの⽤語についての認識を合わせる • ⼀番重要! 意味がズレると予測も当然ズレる • ex この数値、パーセンテージで表してるんじゃないの!?
Slide 10
Slide 10 text
特に、ログに落とせる(せない)モノを確認 ML側でテストと検証を⾏いやすいように、 ログの仕様については予めシステム側のエンジニアと協議 • A/Bテストや、性能確認のために、必ず落としたい値 • 配信パフォーマンスや設計上、どうしてもムリな値 • メトリクス観点で、ロジックid, 予測値、clickしたか、落札額など • テスト観点で、1000回に⼀回だけ、重み値、特徴量の種類、など 出⼒するログは、
Slide 11
Slide 11 text
2. それぞれの実装を相互レビュー • 配信側にMLがわかるエンジニア、ML側に配信サーバー がわかるエンジニア(私)がいたので相互レビュー • 詳細に確認したのは、 • 配信側エンジニア: 読み込む重みファイルのフォーマット • ML側エンジニア: 予測計算の式と、ログのフォーマット 向こう側の、ここがズレてると死ぬ! という観点をお互い認識して、確認し合う
Slide 12
Slide 12 text
3. なにかあっても、すぐ⽌められる設計に • ストレージに学習結果を保存し、配信側で読み込んで予測する 機械学習 システム ストレージ • 開発とテストが⾮常に楽 • 機械学習側で問題が起きても、配信で読み込みをやめればよい • 問題が起きたときも原因の切り分け、特定が容易 学習結果 を保存 配信サーバ 読み込み
Slide 13
Slide 13 text
3. なにかあっても、すぐ⽌められる設計に • ストレージに学習結果を保存し、配信側で読み込んで予測する 機械学習 システム • 開発とテストが⾮常に楽 • 機械学習側で問題が起きても、配信で読み込みをやめればよい • 問題が起きたときも原因の切り分け、特定が容易 配信サーバ 古いファイル を再読み込み 学習結果 を保存 障害 発⽣ ストレージ
Slide 14
Slide 14 text
さらに配信側の負荷をより減らすために モデルを復元するための、 重み値をすべて配信サーバーのメモリで持つ必要がある 巨⼤なファイルだとGCが⾛って、配信の処理が⽌まる そのため、精度を担保しつつ、 重みファイルの容量をなるべく⼩さくする必要がある
Slide 15
Slide 15 text
• カテゴリの数が⼤きい特徴量は使わない • モデルを数週間に⼀回、洗い替え • もう使われなくなったCreativeなどの重み値を削除する • ファイルの容量が閾値異常なら、エラーを吐く • (やらなかったけど)L1正則化で、影響が⼩さいカテゴリは消す さらに配信側の負荷をより減らすために
Slide 16
Slide 16 text
4. あと細々したコード上の⼯夫とか • 塵も積もればの精神で諸々⼯夫 • メモリの最適化、処理の効率化などなど • このあたりは、別のタイミングで発表したので、もしご興味あれば https://speakerdeck.com/hiroaki838 8/pythonde-chu-li-woyorixiao-lu- hua-surutamefalsetipsji
Slide 17
Slide 17 text
機械学習システムとして、⾏いたい仕様 学習: ⼤量のログから、短時間で効率的な学習⽅法 改善: なるべくコードに⼿を⼊れず、簡単に本番にデプロイ
Slide 18
Slide 18 text
学習: ⼤量のログを効率よく学習するために • 異なるログから複数個のデータセットを構築し、 並列でモデルを学習 • 並列処理はPythonで無理せず、プロセス⾃体を複数⽴ち上げ実⾏ data1 model1 model3 data2 data3 model2 学習 学習 学習 weight 平均 平均 平均
Slide 19
Slide 19 text
改善: AWS Cloud Foramtion + Step Functions で素早くデプロイ • Cloud Formationを利⽤し、⼀発で環境構築、更新 • インスタンスタイプなどの、実⾏環境を容易に変更可能 • Step Functionsで、job flowを定義 • 処理がどこまで実⾏されているかがConsole上から確認できる
Slide 20
Slide 20 text
おわりに • 広告配信のように 、MLとシステムが密になるなら、 • 設計段階から配信側と連携 • ここが⾷い違っているとヤバいポイントを予めお互い把握 • テストや責任範囲も明確にしておくとリリース後もスムーズ • 機械学習モジュール⾃体は、 • ⼤量のログを効率的に(スケーラブルに)さばけるように⼯夫 • リリース後、なにか起きることを前提に、容易に修正できる設計
Slide 21
Slide 21 text
No content