test

1. RTBにおける
機械学習システムの実装と運用
アドテクスタジオ smalgo
成田敦博
1

2. 自己紹介
成田敦博
• アドテクスタジオ/smalgo エンジニア
• 入社1年半弱
• DSPを作っています
• 主に配信ロジック開発に関わっています
• 普段はscala たまにpython
• scala歴は2年くらい
• 配信アルゴリズムに関する共同研究なども
2

3. 概要
• RTBについて
• 機械学習を動かすための
• 実装のこと
• 運用やテストのこと
弊チーム(smalgo)での事例を紹介します。
3

4. RTB: Real Time Bidding
4

5. 5

6. RTB: Real Time Bidding
• 誰がどこにどんな広告を表示するか決めるための取引市場
• 多数のSSPやDSPがやりとり
• 広告が表示されれるたびに毎回オークションを行う
6

7. 7

8. • 多数のSSPやアドネットワークと接続
• 接続先が主催するオークションに入札する
• どんな人やどんな枠にうまく広告を見せられるか?
8

9. 予測モデルの実装のこと
9

10. DSPに必要なことの例
1. 請け負ったキャンペーンの管理
2. ターゲティングの判定
3. 予算の管理
4. 入札額の決定
• そのインプレッションをいくらで買うか賢く考えて入札する
• 収益に直結する部分
10

11. 入札額の決定
入札額を決めるために、1インプレッションの価値をその都度な
るべく正確に計算する必要がある。
↑ここに機械学習を使う
• 典型的には Click Through Rate(CTR) 予測モデルなど
• クリック単価 で入札
• 他には、動画の視聴開始率の予測などなど
11

12. 速度が重要
普通のwebサービスと比較して速度に対する要件が厳しい
• スループット
• bidリクエストが10万回/秒ぐらい来る。
そのうち1万くらいに入札する
• レイテンシ
• webページのロードの間に全てが終わってしまう。
どんなに遅くとも50msぐらいでレスポンスを返す必要がある。
12

13. 予測に使ってる変数
• 時刻
• キャンペーンのID
• 広告の表示位置,サイズ,ドメイン
• iosか androidか PCか
• etc.. etc..
13

14. GBDT
Gradient Boosted
Decision Tree
• 主に使っている予測モデル
• 二分決定木をいくつも並べ、出力の
和によって予測する
• IF分をたくさん るだけで済み
予測がそれなりに高速で実装しやす
い
14

15. GBDTの嬉しい点
カテゴリカルな変数(名義尺度)に強い。
• たとえば IPアドレス ・ ドメイン のような文字列
• 機械学習の多くのモデルでは、こういう変数を無理やり連続
なベクトル値にエンコードする必要がある (cf. word2vec)
• 決定木は入力がベクトル値でなくてもよく使いやすい。
15

16. データ分析の環境は外部にある
• 広告配信サーバーほぼscala(とjava)で動いている。
• 一方で、データ分析の多くはpythonの環境で行われる
• jupyter notebook, pandas, etc..
• 予測モデルの作成もこれらのツールを使っている。
• 世界はscalaやjavaで閉じていない
16

17. 学習器と予測器を別々に用意する
• 配信ログから各種予測モデルを定期的に学習する
• 予測モデルをJSONにエンコードし入札サーバーに受け渡す
• 入札サーバー側に取り込み、予測モデルをscalaで再構築
17

18. GBDTをjsonにエンコード
決定木を表現する
sealed trait BinaryDecisionTree {
def findLeaf(features: Array[Feature]): LeafNode
}
case class LeafNode(value: Double) extends BinaryDecisionTree {
def findLeaf(features: Array[Feature]): LeafNode = this
}
case class BranchNode(
condition: Feature,
yes: BinaryDecisionTree,
no: BinaryDecisionTree
) extends BinaryDecisionTree { ... }
18

19. GBDTをjsonにエンコード
決定木の配列としてargonautを使ってJSON化
[{
//枝ノードは分岐の条件と2個の子ノードを表現
"condition": {"name":"size","value":"320x50"},
"yes": 1.0, //葉ノードは値だけを書く
"no" { // 枝ノードを再帰的にエンコードする
"condition": {...}, "yes": ..., "no": ...
}
},...]
19

20. 全体の流れ
20

21. 予測モデルの運用・テストのこと
21

22. 功罪
予測と学習を別々の実装に分離したので…
• [pros] 学習側の実装に依存しない
• JSONさえ吐けばどんな学習を動かしても良い。
• [cons] I/Oを実装する手間とバグのリスクが増える
• 学習側と予測側で実装が違ってしまうが、同じモデルを動かす必要
• きちんと確認がいる（ここの話は後ほど）
22

23. 機械学習の運用・テストについて
予測モデルが正しく効果よく動くことを担保しないといけない
• 予測モデルの効果の良し悪しが後から分かる必要がある
• 一度学習した予測モデルは、時間がたつほど精度が落ち続け
る
→定期的に学習してその都度チェックが必要
• 不具合があっても一見それらしい値が出力されてしまう
23

24. A/Bテストの仕組み
予測モデルの良し悪しを A/B テストする仕組みは（多分)必須
• 複数の予測モデルをロード
• 入札時にランダムで予測モデルを選択
• どれを選択したか、IDをログに落とす
• あとで集計できるようにする
24

25. 不具合が出そうな場所
1. 学習時: 精度が低下していないか
2. 学習モデルの取り込み時
• 学習側と予測側でモデルファイルの解釈が違うかもしれない
3. 予測時: 予測器に入力を正しくできるか
25

26. 不具合が出そうな場所
1. 学習時: 精度が低下していないか ← 学習時にチェック
2. 学習モデルの取り込み時 ← 取り込み時に整合性チェック
• 学習側と予測側でモデルファイルの解釈が違うかもしれない
3. 予測時: 予測器に入力を正しくできるか (← 単体テスト)
26

27. 1. 学習時: 予測精度チェック
• 学習方法を用意しても、時間が経つにつれ環境が変わり性能が
低下するかもしれない。
• 学習データの一部を使って予測精度をチェックする
毎日の学習バッチで予測精度を確認できるようになっている
27

28. 2. モデル取り込み時: 整合性チェック
• 学習器と予測器が別実装になってしまった。
予測値が全く同じことを確認する
• モデル学習時にテストケースを自動生成する
• 学習データの一部を使って、
入力ベクトルの値と、期待される予測値を並べたcsvを出力
• 予測モデル１個に対してcsv1個
28

29. validation.csv ｲﾒｰｼﾞ
hour, cpn_id, ad_size, domain, os, ..., expected
3, 123, 320x50, example.com, ios-7, ..., 0.0121
21, 100, 300x250, abc.com, android-4.4,..., 0.0093
12, 91, 300x250, example.com, android-4.3,..., 0.0013
...(1000行くらい)
• JSONを入札サーバーに取り込む際に毎回チェック 失敗したらアラー
ト
• 入札側での予測器の開発にも役に立った
• バリデーション通るまでscalaコードを修正すればよい
29

30. たとえば学習ライブラリのアップデート時
• 突然モデル取り込みのバリデーションが失敗するように
• before: 予測値
• after: 予測値
• 学習で使うパッケージが何気なくマイナーアップデートされていた
バリデーションによって大惨事が防げた。
30

31. まとめ
• 機械学習による予測モデルをどう動かしているか
smalgoでの事例
• 学習と予測を分離した実装
• 精度や整合性のテスト
31