Upgrade to Pro — share decks privately, control downloads, hide ads and more …

機械学習を無理なく広告システムに導入する

hiroaki
February 05, 2020

 機械学習を無理なく広告システムに導入する

hiroaki

February 05, 2020
Tweet

More Decks by hiroaki

Other Decks in Technology

Transcript

  1. 機械学習を
    無理なく広告システム
    に導⼊する
    MLOps勉強会
    Fringe81 ⻑⾕川⼤耀

    View full-size slide

  2. ⾃⼰紹介
    ⻑⾕川⼤耀(@Hase8388)
    で、機械学習の開発やってます
    物理学(⼤腸菌)=>
    広告配信(Scala)=>
    広告配信(ML)

    View full-size slide

  3. 広告配信のビジネスモデル
    • ユーザー情報を元に、興味がありそうな広告を配信する
    • お⾦が⼊ってくるのは、広告をclickしたときなので、
    よりユーザーが興味がある広告を優先的に表⽰すれば、それだけ
    利益に繋がる

    View full-size slide

  4. • ユーザー情報を元に、興味がありそうな広告を配信する
    • お⾦が⼊ってくるのは、広告をclickしたときなので、
    よりユーザーが興味がある広告を優先的に表⽰すれば、それだけ
    利益に繋がる
    広告配信のビジネスモデル
    機械学習でclickする確率(CTR)をより正確に予測すれば
    売上に貢献しうる

    View full-size slide

  5. もっと単純なロジックでも良いのでは?
    機械学習にすることでメリットは⾮常に多い
    • メディアなどの傾向が変わってもすぐに柔軟に対応できる
    • 多くの情報(特徴量)を、より柔軟に予測に活⽤できる
    • 特徴量やパラメータなど、改善できる⾃由度が増える

    View full-size slide

  6. 今⽇話すこと
    話さないこと
    • アルゴリズムのガッツリとした話
    • 特定のライブラリ、フレームワークの話
    など
    機械学習を広告配信システム
    上で安定的に動かすための
    実装、運⽤⽅法
    その上で機械学習システムを
    確実に運⽤と改善を
    ⾏っていくための⼯夫

    View full-size slide

  7. 広告配信は、ビジネス上の制約も多い
    配信側で、モデルを復元/予測を⾏う必要が
    あるため、配信側(アプリケーション側)のエンジニアと
    密な連携が不可⽋
    配信側の開発を⾏うエンジニアと、
    どのように齟齬なく、開発をおこなうか?
    20ms以内に、最適な広告を決定
    し、返却する必要がある

    View full-size slide

  8. 1. チーム間で開発前に認識合わせを⾏う
    • 懸念されるリスクを整理し、対策を考える
    • 正常/異常のパターンを洗い出し、どちら側で対応するかを決める
    • ex モデルのメトリクスがおかしい場合、ML側で更新を停⽌します
    • 配信側でできること/できないことの整理
    • 仕様に落とし⽳がないかをチェック
    • ex xxGBまでは配信のメモリに乗せれるけど、それ以上だと厳しいです
    • それぞれチームでの⽤語についての認識を合わせる
    • ⼀番重要! 意味がズレると予測も当然ズレる
    • ex この数値、パーセンテージで表してるんじゃないの!?

    View full-size slide

  9. 特に、ログに落とせる(せない)モノを確認
    ML側でテストと検証を⾏いやすいように、
    ログの仕様については予めシステム側のエンジニアと協議
    • A/Bテストや、性能確認のために、必ず落としたい値
    • 配信パフォーマンスや設計上、どうしてもムリな値
    • メトリクス観点で、ロジックid, 予測値、clickしたか、落札額など
    • テスト観点で、1000回に⼀回だけ、重み値、特徴量の種類、など
    出⼒するログは、

    View full-size slide

  10. 2. それぞれの実装を相互レビュー
    • 配信側にMLがわかるエンジニア、ML側に配信サーバー
    がわかるエンジニア(私)がいたので相互レビュー
    • 詳細に確認したのは、
    • 配信側エンジニア: 読み込む重みファイルのフォーマット
    • ML側エンジニア: 予測計算の式と、ログのフォーマット
    向こう側の、ここがズレてると死ぬ!
    という観点をお互い認識して、確認し合う

    View full-size slide

  11. 3. なにかあっても、すぐ⽌められる設計に
    • ストレージに学習結果を保存し、配信側で読み込んで予測する
    機械学習
    システム
    ストレージ
    • 開発とテストが⾮常に楽
    • 機械学習側で問題が起きても、配信で読み込みをやめればよい
    • 問題が起きたときも原因の切り分け、特定が容易
    学習結果
    を保存
    配信サーバ
    読み込み

    View full-size slide

  12. 3. なにかあっても、すぐ⽌められる設計に
    • ストレージに学習結果を保存し、配信側で読み込んで予測する
    機械学習
    システム
    • 開発とテストが⾮常に楽
    • 機械学習側で問題が起きても、配信で読み込みをやめればよい
    • 問題が起きたときも原因の切り分け、特定が容易
    配信サーバ
    古いファイル
    を再読み込み
    学習結果
    を保存
    障害
    発⽣
    ストレージ

    View full-size slide

  13. さらに配信側の負荷をより減らすために
    モデルを復元するための、
    重み値をすべて配信サーバーのメモリで持つ必要がある
    巨⼤なファイルだとGCが⾛って、配信の処理が⽌まる
    そのため、精度を担保しつつ、
    重みファイルの容量をなるべく⼩さくする必要がある

    View full-size slide

  14. • カテゴリの数が⼤きい特徴量は使わない
    • モデルを数週間に⼀回、洗い替え
    • もう使われなくなったCreativeなどの重み値を削除する
    • ファイルの容量が閾値異常なら、エラーを吐く
    • (やらなかったけど)L1正則化で、影響が⼩さいカテゴリは消す
    さらに配信側の負荷をより減らすために

    View full-size slide

  15. 4. あと細々したコード上の⼯夫とか
    • 塵も積もればの精神で諸々⼯夫
    • メモリの最適化、処理の効率化などなど
    • このあたりは、別のタイミングで発表したので、もしご興味あれば
    https://speakerdeck.com/hiroaki838
    8/pythonde-chu-li-woyorixiao-lu-
    hua-surutamefalsetipsji

    View full-size slide

  16. 機械学習システムとして、⾏いたい仕様
    学習: ⼤量のログから、短時間で効率的な学習⽅法
    改善: なるべくコードに⼿を⼊れず、簡単に本番にデプロイ

    View full-size slide

  17. 学習: ⼤量のログを効率よく学習するために
    • 異なるログから複数個のデータセットを構築し、
    並列でモデルを学習
    • 並列処理はPythonで無理せず、プロセス⾃体を複数⽴ち上げ実⾏
    data1 model1
    model3
    data2
    data3
    model2
    学習
    学習
    学習
    weight
    平均
    平均
    平均

    View full-size slide

  18. 改善: AWS Cloud Foramtion + Step Functions
    で素早くデプロイ
    • Cloud Formationを利⽤し、⼀発で環境構築、更新
    • インスタンスタイプなどの、実⾏環境を容易に変更可能
    • Step Functionsで、job flowを定義
    • 処理がどこまで実⾏されているかがConsole上から確認できる

    View full-size slide

  19. おわりに
    • 広告配信のように 、MLとシステムが密になるなら、
    • 設計段階から配信側と連携
    • ここが⾷い違っているとヤバいポイントを予めお互い把握
    • テストや責任範囲も明確にしておくとリリース後もスムーズ
    • 機械学習モジュール⾃体は、
    • ⼤量のログを効率的に(スケーラブルに)さばけるように⼯夫
    • リリース後、なにか起きることを前提に、容易に修正できる設計

    View full-size slide