100msの世界で溺れた話 ~CA Tech Challenge~
みなさんメリークリスマス! 今年のクリスマスは如何お過ごしでしょうか?
自分は人事の方とキャッキャしたり、溜まりに溜まっているブログとウフフしたり(イマココ)しているので今年も充実したクリスマスで御座います!
今回はサマーインターン第n弾、アドテク編になります!
CyberAgentさんのCA Tech Challenge アドテクコンペ
に参加させて頂いたので振り返って行きたいと思います!
同じチームでサーバーサイド側のインターン生も書いてくれてるのでサーバサイドも知りたい人は合わせてどうぞ! bambootuna.com
参加の経緯
春と夏のインターンで多少アドテクとサーバーサイドの理解が進んだので、
一旦自分の実力を試すために参加した。と言う感じです!
ちなみに春と夏に参加したインターンに関してはこちらを合わせてどうぞ!
(クソ長記事なのでご注意下さい…)
- 実務でデータサイエンスしてWebヤムチャした話 ~CA Tech JOB~
(近日公開予定) - この夏、宝探しに行ってカエルになった話 ric418.hatenablog.com
コンペの概要
まずDSPとSSP、RTBといった所を説明しなければならないのですが割愛して、 とてもザックリと説明してしまうと
- Web広告枠をオークションで取り合う中で
- この枠いくらで買いますと言うサーバーに
- より利益・効果のでる枠を予測して値付けする機能をつけ
- リアルタイムかつ大量のオークションの中で運用する
これを以下の項目で競う感じでした!
コンペ期間中の流れ
前夜祭?
コンペ期間が始まる前に前夜祭的な物があり
- CAの事業を理解
- インターン参加者とメンターの方々との交流
- コンペの軽い理解
をしていきました!
個人的にAI事業本部について気になっていたのでそのお話を新卒の方々から伺えたのは貴重でした!
1日目
まずチームに分かれ、コンペのルール説明から今回構築するDSPとRTBについて基本的なインプットがされました。
チーム構成としては
- サーバサイド:3人
それぞれの機能をマイクロサービス化してそれぞれ分担 - データサイエンス(以降DS):2人(自分はこっち)
分析し予測する対象を確認(今回はクリック率(以後CTR)を精度良く予測する)
と言う構成でした、チームビルディングのため軽いボードゲームをしていきました。
DSサイドの動き
サーバーサイドの方々には全体のアーキテクチャとそれぞれのプロセスの役割を考えてもらいつつ、DSサイドは
「DSPに載せるモデルはどのような物が適するか?」
と言うのを詰めていきました!
100ms以内にレスポンスしなければならないと言う前提の元、軽く箇条書きで触れておくと
- 前処理と推論フェーズはメインプロセスに載っけたい
予測プロセスで余計なレイテンシは発生させたくない - モデルはなるべくシンプルなものに
コンペの短さ・メインプロセスに載っけやすい・計算も早く、これらを考慮 - 使う特徴量や前処理もシンプルで有効なものに絞る
複雑な前処理などはなるべく避ける方向で進める
これらを鑑みて分析・推論は、
- ロジスティック回帰によってクリック「される」・「されない」の2値分類をする
- 学習によって得られた重みをメインプロセスに渡す
- その重みを用いてメインプロセスでロジスティック回帰による予測をする
- その予測の確率値をCTRとして扱いオークションの値付けに用いる
このプロセスで行うことになりました!
ここでサーバーのメインプロセスにモデルをどう載せるか・なぜそう載せたいのかみたいな話をサーバーサイドの方々と相談する際にかなり円滑に決めていけたのは夏の期間に少しでもサーバーサイドを実装した事があるのが大きいと今でも思っています…!
2日目
ここからがコンペの勝負所って感じでした…が少しアクシデントがありましてサーバー側の実装に遅れが出てしまい…
ここに関してのリカバリなどに関しては自分の反省もあるので後ほど触れようかと思います…
DSサイドの実装
DSサイドに関しては基本的な回帰モデルは完成し、
完成まで色々こねくり回したわけですが…箇条書きでまとめておきたいと思います。
不均衡データへのアプローチ
今回はクリックされる(正例)サンプル数が極端に少ないので、これに対応していく必要があります。
対応する手法として色々なアプローチが考えられますが今回以下の2つを試して見ました。- Under Sampling : 今回はこちらを採用
Under Sampling したバイアスを補正(Calibration)する為に以下の式を適用し、その結果をCTR(クリック率)として用います。(ωはUnder Sampling率)
- Class weight : 今回は不採用、クリック数が広告主毎に大きく異なる場合はアリかも?
各クラスのサンプル数によって重みを変えていく手法
- Under Sampling : 今回はこちらを採用
評価指標はROC・AUCで十分か?
評価指標がROC・AUCだけだと
「入札額がn倍異なってもROCは同じ」・「実際のCTRを予測できているのか不明瞭」
と言った様な問題点が挙げられます。
ここで以下の様な評価指標も加えてモデルを評価・改善していきました。Logarithmic Loss
AccuracyやRUC・AUCがTrue/Falseの二値で評価していたのに対し、予測値が正解ラベルから離れるほどこのlossは増加しその値を評価します。
実際のラベルからどのくらい違っていたのかを考慮でき、予測した確率値が「割と近い…!」・「てんでダメやんけ!」なのか判断することが可能です。これが意味する所は、この値を少なくする事はCTRのズレを補正するのはもちろんオークションにおいて、とんでもない値付けをして入札してしまう事も少なくなる事に繋がると言うことになります。
- Calibration Curve
実際のクリック率にしたがっているかを検証する方法、idealな方に近づける様に改善していく
モデルを広告主ごとに分ける
広告主に特化した形にはなるが汎用性は低くなるイメージ。
メインプロセスでリクエストに対応する広告主のモデルの重みで推論する事は考えられますが今回は20広告主分のモデルを組む時間は流石にありませんでした…
- Probability Calibrationなるものを使う
この手法が先述したUnder SamplingにおけるCalibrationと同じなのか違うのかいまだ定かではないのですが(強い方ご教示頂けると幸いです…)、モデルによって算出された予測確率を本来の確率に近づける手法だそうで基本的に不均衡データに限った手法ではないにしろUnder SamplingにおけるCalibrationと同じ狙いだと現時点では考えています。
今回はメインプロセスに渡す重みを取り出す事が難しくなるので採用しませんでした。
サーバーサイドの実装
ここまでDSサイドが試行錯誤を色々やっていた間にもサーバーサイドの方々も実装を進めてくださいまして、最終的には以下の様な構成になりました。
サーバーサイドの方々がとても優秀でDataDogによるメトリクスのモニタリング体制や負荷試験の体制を揃えてくれていました…
実の所ユーザー情報を入れ込む所で時間がかかってしまい最終的には完成まではいかなかったのですがDSPとして最後まで安定稼働するものは作れたと言う結果になりました。
3日目
オークション中
最終日は実際のオークションの開始と発表だったのでそこまでの実装はしていなかったのですが、メトリクスなどを確認・修正してもらいながらDSPを見守っていました。
発表・結果
発表に関しては自分らがどうと言うよりかは、他のチームのシステム構成やモデル選定を見ているのが面白かったですね…
結果に関しては8チーム中3位と言う事で安定的なシステム運用を評価して頂いた形でした!
所感
反省点
- モデルを乗っける所までいけなかった (これは後悔って感じですが…)
- アクシデントの時のリカバリに回るべきだった
これがモデルが乗っからなかった要因でもあった上に、自分がサーバーも少しわかるのであればDSサイドで要らないこねくりをしてるヒマがあればサーバーサイドに回ってまず動くものを作るべきだったのかなと…
印象・学び
- 19卒の方々のキャラが濃い
なんと今回のインターンは19卒の方メインで運営していただいていた様で…そう言う面もさすがCAって感じでもありましたね… - サポート手厚い
これはCAさんのインターン全体でそう、ちゃんと考えて聞けばこちらの学びを潰さない形でイイ感じに示唆(答えではない)してくださる。これホント。 - サーバーサイドとDSが協調する様なインターンは貴重
これは職種間協調的な意味でもそうだがでそう特にDSP構築のコンペとなるとSSPも必要なのでそこも用意されてるとなると中々ないと思う… - やべーやつはやっぱり普通にゴロゴロいる
今回一緒に組んだサーバーサイドの方もそうだったのですが必要とあらばDSもサーバもインフラもやるぜ!って言う末恐ろしい方は普通にその辺にいますね…自分もウカウカしてられないと感じました - KPTの文化は割とどこでも大事
- モニタリング体制はサーバもそうだが予測モデルのパフォーマンス制御にも大事そう
- 19卒の方々のキャラが濃い
あったら・あって良かった知識・能力
これは後輩くんに聞かれてたので書いときます
こんな感じでしょうか、また思い出したら追記します!
では長々と失礼いたしました、それではまたどこかで!