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

いち機械学習エンジニアが考える、 広告効果予測プロダクトへの 価値提供と貢献の仕方 / Pro...

Avatar for CyberAgent CyberAgent
October 05, 2023

いち機械学習エンジニアが考える、 広告効果予測プロダクトへの 価値提供と貢献の仕方 / Providing value to products that predict advertising effectiveness, as considered by ML engineers

Avatar for CyberAgent

CyberAgent

October 05, 2023
Tweet

More Decks by CyberAgent

Other Decks in Technology

Transcript

  1. 自己紹介 • 2017/12〜 アドテク本部 CA DyVE • 2019/09〜 AI事業本部 極TD

    基本属性はフルスタックエンジニア サイバーエージェント入社後、Data & MLに も領域を広げる 西村 政輝
  2. 極TD立ち上げ初期のDataOps整備 As-Is(当時): • 学習データは広告メディアの管理画面から手動CSV出力後Google Drive保存 ◦ 再学習の都度手間もかかるし、スピード感もない、人的ミスの可能性も ◦ 仮組みした学習パイプラインはあれど、MLOpsを自動化できない To-Be:

    • DWH(データウェアハウス)が存在する状態 ◦ 常にデータが必要な時にプログラム等からクエリで利用できる ◦ データが最新の状態に保たれている ◦ ETL,ELTの出力先としても使え、MLの前処理済データ等も統一的に管理
  3. 極TDバッチ・ ワークフロー 極TDのDWH 極TD立ち上げ初期のDataOps整備 プロダクト 共有DWH 広告 メディア API BigQuery

    配信設定& 実績DB 学習用 rawdata 前処理 済データ 前処理 BigQuery 極TD用 学習データ 取得 Dataflow Dataflow Cloud Composer 極TDリリース後数ヶ月でこの形ができあがる • 下記青枠の箇所が極TD実装 • 同時期にプロダクト間共通データを扱う BigQueryも部署内で整備され、諸々のデ ータソースをBigQuery内で完結 学習
  4. 極TD立ち上げ初期のDataOps整備 得られた成果: • BigQueryを軸としCloud Dataflow, Cloud ComposerといったGCPスタ ックに乗る形で、設計思想が統一されたDataOps環境が構築できた • 上記によるシステム面の運用自動化が速やかに達成できた

    • 実験・データ分析の際に欲しいデータが常に速やかに手に入る形になった SWE経験が活かされたところ: • 直前に所属していた広告配信プロダクトで既にBigQuery, Cloud Dataflowの実務経験があり、ここで得たDataOpsのノウハウを活用できた
  5. 広告メディア ABnテストテーブル(一例) • **%: 今効果が出てるモデル • **%: 新しい実験用モデル • **%:

    ランダム(コントロール群) ①TDを効果予測し tracking_idを 払い出し ②TDの入稿ラベルに tracking_idを 付与して入稿 予測 結果 配信 実績 TD制作ライター 開発・運用 ④新予測モデルの開発 ABnテストテーブル更新 ③tracking_idで joinして集計 &分析 予測モデルの効果検証のためのABnテスト基盤 ABnテストの仕組み概要:
  6. 予測モデルの効果検証のためのABnテスト基盤 SWE経験が活かされたところ: • TDの入稿ラベルにトラッキングIDを与え配信実績を追跡する設計上の着想 は、SWEとして分散トレーシングが馴染み深かったことから得られた • 今回の要件にあったプロキシサーバの実装難易度は高めだが実装力でカバー ◦ ABnテストのyaml定義ファイルをプログラムに落とし込む ▪

    Interpriter, Decorator, Chain Of Responsibility @ GoFデザパタ ◦ 非同期プログラミング、ノンブロッキングIOの意味と特性を理解した上 での分散・並行リクエスト (Pytyonならコルーチン・Async/Await) ◦ 諸々の複雑寄りの実装を支えるためのコンストラクタDIとテスト実装
  7. Dataflowによるアセット組み合わせ大規模バッチ推論 技術要件: • 1実行あたり、数億の自動生成アセットの組み合わせパターンに対して推論 ◦ 各adに対し広告アセットの最適な組み合わせを探索するバッチ ▪ 広告数 x 組み合わせ各nパターンずつ推論を試行

    • 1実行あたりの推論コストは決して低くない ◦ モデル側の推論はともかく、NLP絡みの前処理が少し重い • 予測対象増加やモデルアップデートに備え、処理能力をスケール可能
  8. LLM API活用 TDオンデマンド生成サーバー開発 技術要件: • 今回開発するサーバーはクライアントに非同期APIを提供すること ◦ LLMの応答は各プロンプトあたり数十秒〜掛かる ◦ サーバはjob_idを返し、クライアントはjob_idで生成進捗を問い合わせる

    • LLM APIコールのタイムライントレースログを記録できること • 運用形態によりそのスケール幅に柔軟に対応できること ◦ 社内外の様々なLLM APIに対応しつつ大量の生成タスクを同時実行 ◦ 1jobあたりの処理は I/O waitがほぼ全てでCPUが遊んでいる ▪ サーバー内で複数jobをマルチプロセスで処理できるとよし
  9. BigQuery Cloud Storage worker ElastiCache Redis LLM API 推論結果 キャッシュ

    Job進捗 RQ data RQ sub LLM servrice volume llm_io .jsonl scraping service logic (LLM Chain的 なもの) fluentd progress repository GCS plugin 広告主様 のLP LLM APIs (接続計画含む) llm_io .jsonl llm_io .jsonl llm_io .jsonl .gz TD生成結果 極予測TD 制作画面 LLM API活用 TDオンデマンド生成サーバー開発 LLMログ (外部参照) ECS Fargate APIサーバー RQ pub progress repository HTTP server POST /jobs GET /jobs AWSデプロイ時のアーキテクチャ図 (次のスライドで要点をドリルダウンします) (内製LLM API)
  10. BigQuery Cloud Storage worker ElastiCache Redis LLM API 推論結果 キャッシュ

    Job進捗 RQ data RQ sub LLM servrice volume llm_io .jsonl scraping service logic (LLM Chain的 なもの) fluentd progress repository GCS plugin 広告主様 のLP LLM APIs (接続計画含む) llm_io .jsonl llm_io .jsonl llm_io .jsonl .gz TD生成結果 極予測TD 制作画面 LLM API活用 TDオンデマンド生成サーバー開発 LLMログ (外部参照) ECS Fargate APIサーバー RQ pub progress repository HTTP server GET /jobs サーバーとワーカーを分離し、MQ(今回はRQ)経由でjobを配布することでスケール POST /jobs (内製LLM API)
  11. BigQuery Cloud Storage worker ElastiCache Redis LLM API 推論結果 キャッシュ

    Job進捗 RQ data RQ sub LLM servrice volume llm_io .jsonl scraping service logic (LLM Chain的 なもの) fluentd progress repository GCS plugin 広告主様 のLP LLM APIs (接続計画含む) llm_io .jsonl llm_io .jsonl llm_io .jsonl .gz TD生成結果 極予測TD 制作画面 LLM API活用 TDオンデマンド生成サーバー開発 LLMログ (外部参照) ECS Fargate APIサーバー RQ pub progress repository HTTP server POST /jobs GET /jobs 生成の進捗&結果はRedisに記録することでどのAPIサーバープロセスからも取得可 (内製LLM API)
  12. BigQuery Cloud Storage worker ElastiCache Redis LLM API 推論結果 キャッシュ

    Job進捗 RQ data RQ sub LLM servrice volume llm_io .jsonl scraping service logic (LLM Chain的 なもの) fluentd progress repository GCS plugin 広告主様 のLP LLM APIs (接続計画含む) llm_io .jsonl llm_io .jsonl llm_io .jsonl .gz TD生成結果 極予測TD 制作画面 LLM API活用 TDオンデマンド生成サーバー開発 LLMログ (外部参照) ECS Fargate APIサーバー RQ pub progress repository HTTP server POST /jobs GET /jobs LLM I/OログはjsonlでGCSに集約すれば、BQの外部テーブルとして分析可能 (内製LLM API)
  13. LLM API活用 TDオンデマンド生成サーバー開発 得られた成果: • あらゆる実行環境に適応できるコンパクトかつelasticなシステムとなった ◦ ローカルでDocker Compose等で小さく起動 ◦

    極TD画面からの1APIサービスとして起動 ◦ バッチ実行向けに大きくスケールアウト(OpenAIのTPMリミットに注意) SWE経験が活かされたところ: • 非同期仕様のAPIはたまによく作るもの。今回もその延長線上にあり • クリーンアーキテクチャで実装し、コードの運用・保守性を担保