2016-12-06

報酬が線形モデルで表せる時のバンディット問題

バンディット問題の理論とアルゴリズム』本の,報酬がなんらかの特徴の線形モデルによって表現される場合に使える線形バンディットが前から気になっていたので輪読会で発表担当をするなど.

スライド


アルゴリズムの実装と人工データによる実験

感想

行動(腕)毎の報酬を推定するのでは無く,報酬モデルのパラメータを推定するという方策.妥当なモデルが作れたら実際に使えそうな感触.
実装は一発書きおろしで検算をしていないが,一応それっぽく動いた.ラプラス近似の処理が重いので勾配ベクトルとヘッセ行列の計算過程はキャッシュしておかないとつらい.
LinUCBかThompson Samplingかどちらを使うかというと,報酬が同期で観測できない広告配信は後者一択で,報酬が二値の場合はロジスティック回帰モデル方策がよさそう.あとはクリックやコンバージョンを線形で表現するための特徴量が上手く見付かればいいのだが…….

さらに現実的なケースとして9章には報酬が時間変化する例もあるので,続きも読んでいきます.

バンディット問題の理論とアルゴリズム (機械学習プロフェッショナルシリーズ)バンディット問題の理論とアルゴリズム (機械学習プロフェッショナルシリーズ)
本多 淳也,中村 篤祥
講談社
売り上げランキング : 79416
Amazonで詳しく見る by AZlink


このエントリーをはてなブックマークに追加

2016-10-17

Spotify社のエンジニア評価制度

Spotifyが日本に上陸しましたね。現在はアプリをインストールしてもすぐにサービスが利用できない様子、その隙に彼等の技術職評価制度についてのブログエントリを読みます。
ブログエントリは3部作になっており、技術職のキャリアパスフレームワークを作ったモチベーションに始まり、そこから得た物まで纏まっています。

印象に残った箇所

  • キャリアパスフレームワークをいつ作るか
    • 会社の初期の頃にはキャリアパスフレームワークは不要である。しかし8年間、Spotifyは昇格・昇給の正式な手続きが存在しなかった。
    • 昇格にはラインマネージャかプロダクトオーナーになるのが必要だと社員は考える様になってしまった。Spotifyにおいては、それは職種変更同然で開発者としての成長では無い。
    • 2014年の春に "career ladder" の開発に着手した。
  • 目標
    • Spotifyの文化に適合しており、社員の多様性、さまざまな経験度・ロールに適用可能なフレームワークを作る事。
  • 5つの特質
    • 個人の成功よりもチームの成功
    • 継続的な個人/チームの成長
    • 説明責任を持つ事
    • 仕事のビジネスインパクトを考える事
    • 各人がそれぞれの分野で熟練する事
  • 4つのステップとレベル定義
    • Individual
      • 新規要員。どのように生産的であり貢献できるかわかっている。
    • Squad / Chapter (チーム)
      • チームメンバとして貢献できており、一緒に働くメンバーの力になっている。
    • Tribe / Guild (より大きな組織)
      • 所属するチームを越えて活躍できる人。もしくはある技術に造詣が深い・困難な問題を解決するスキルがある・部署を越えた問題を解決に導ける。
    • Technology / Company (組織の最高レベル)
      • 会社全体に貢献できるレベル。組織を越えた活動に十分な時間を費やす事を期待される。
  • 各ステップに期待する行動
    • たくさん (気になる人は原文を参照してみてください)
  • ステップの昇格手順
    • squad/chapterへの昇格は、ピア(入社時に割り当てられるサポート担当?)のフィードバックに基づいて決定される。
    • tribe/guildへの昇格は、tribeレベルのリーダーで相談した後、関係するtribe leadの承認が必要。
    • technology/companyへの昇格は、technicalレベルのリーダーで相談した後、CTOの承認が必要。
    • 昇格には責任範囲の拡大が共なう。
    • 実績よりも振舞いを重視する。これはイノベーションを推奨するためであり、失敗は起る物とする。
  • 給与
    • 同地域・同業界の給与をベンチマークとしている。しかし厳密に合わせているわけでは無く、推奨レベル。
    • ステップと給与の関係は未完成。
  • 肩書(役職?)
    • ステップと肩書は連動しない。

感想

序盤の「The road is more important than the destination」という節にあるのですが、自社のキャリアパス制度を作ろうとしている時に、他社のやり方をそのまま使いたくなるかもしれないが、それはお勧めしない。なぜなら企業文化はそれぞれユニークであるから。とあり、楽はできないんだなと。彼らは評価制度を作るのに有志によるワーキンググループを作ったが、企業文化によってはここから別のルートになる所もあるだろう。
社員の成長をサポートする、つまりどの様に成長して欲しいかを定義するのは企業文化と照しあわせる作業であり、そのプロセス自体も企業文化に即していなければならない。

ステップ(レベル)と役職が連動していないのは、給料を上げるにはマネージャーにするしかない、という残念な状況を生み出さないので理にかなっている。(しかしそんな残念な会社もたまにあると聞く)

Companyステップに期待する事の一つが
Gives talks at industry events, and/or publishes research papers, and/or publishes company white-papers and/or may be a Spotify representative in industry groups or committees.
つまりこういった記事をブログで公開する事、彼ら自身が利用しているソフトウェアをGithubで公開したり研究成果を論文にするのも要求事項として明記されているんですね。素晴しい。

このエントリーをはてなブックマークに追加

2016-09-09

GCP NEXT Tokyoとbq_sushiで弊社事例の紹介をしました

9月6日に開催されたGCP NEXT Tokyoの事例紹介セッション及びパネルディスカッションでの講演機会をいただいたので登壇してきました。一緒に出演されたメルカリ様、DeNA様はApp Engine Goをバリバリに使っている事例で、VOYAGE GROUPはBigQueryと、他社のサービスに無いプロダクトを全面にプッシュしていたのでわかりやすい話になったかなと。反省点は、資料に沿って話すのに精一杯で、まだまだ自分の言葉で話せなかった所ですかね。

そして、この事例で紹介した仕組みで動いている処理の一つが先日発表した不正クリック検出なわけで、GCPのデータセンタには足を向けて寝られません。

そのまま夜はbq_sushi #4で事例紹介の縮小版をやりました。異常検知で利用しているクエリを紹介しようとしたらスライドに貼りきれず失敗したので、Qiitaに全部貼りました……。

bq_sushiで使用した資料

GCPではじめるスモールスタートなデータ活用 // Speaker Deck

ETL処理とlambdaアーキテクチャ

今回のGCP NEXTとbq_sushiで目を引いたのはETL処理とlambdaアーキテクチャ。リアルタイム性と遅れてくるデータの扱いをどうすべきか、最近の悩みでもあったのでヒントになりました。SpotifyのオンプレからGCPへの移行ケースの話も極めて俺得でした。Spotifyといえばジョブパイプラインの制御にluigiを使ってますが、もしかしてluigiのGCPまわりの開発が加速されるのかなと、密かに期待。


このエントリーをはてなブックマークに追加

2016-09-05

不正クリック検出の歴史と実装について発表しました

第56回データマイニング+WEB@東京で不正クリック検出について発表してきました。参加者の三割ぐらいがネット広告業界のエンジニアだったため、釈迦に説法にならないか心配でしたが、配信業態が変われば相対している問題も異なるようで良かったです。

発表資料


個人的にはパブリッシャーのブラックリストを広告業界全体で共有するくらいの事はやっても良いのでは、と思っています。 今は圧倒的に防御側が利用できる情報が少なく不利な状況にあります。(そして自分が楽をしたい)

あとはつい先日、CAリワードから「DNN+オンライン学習で不正検出してます」というプレスが発表されて、どうやっているんだろうと気になってしょうがないのですが、CAの人に会える機会が無くもやもやとしております。

このエントリーをはてなブックマークに追加

2016-08-17

[論文] Combating online fraud attacks in mobile-based advertising (2016) 読んだ

Combating online fraud attacks in mobile-based advertising

要旨: Abstract

広告バナーに対して機械的にクリックを生成するAndroidアプリ(不正クリックbot)を実装して、実際のAdNetwork8社に対してbotによるクリックが有効かどうかを検証した。
検証結果から、不正クリックbot対策の提案を3つする。

実装: Implementation of online fraud attacks

CPC収益モデルの広告に対して、悪意のあるPublisherはクリックイベントを生成する事により自身の利益としている。それらは実にシンプルに生成されているが、実際のAdNetwork各社がそうやって生成されたクリックに対して今だに脆弱であるかは疑問があった。
これを検証するため、次の実装とした。

  • 独立したAndroidアプリとし、表示された広告に対して自動でクリックイベントを生成する
  • Publisher自身の端末でこれを動かすシナリオを想定
  • Android Debug Bridge (ADB) を利用してクリックイベントを端末に送信
  • Device ID (or android_id) がサーバーに送信されるため、これをランダムに書き換える

実験結果: Experiments

6つのAdNetworkは機械的に生成したクリックを防げなかった。2つのAdNetworkは自動生成クリックに対抗し、アカウントがブロックされた。

対抗手段: Countermeasures

1. Androidのアーキテクチャを変更し、物理的なタッチイベントについてトレース可能にする。イベントの生成元がわかれば、プログラムによって生成されたクリックイベントをフィルタする事ができる。
2. 人間には見えないバナーでbotを釣る
3. 異常なふるまいを検知する
----

感想

攻める側の視点とは珍しいなと思って読んでみたが、全く難しい事をしておらず拍子抜け。しかも6つのAdNetworkにはこれが有効という結果。しかしbotの運用期間が書いてなかったので、不正検知に引っかかる前に実験を終えた可能性もある。

AdNetworkによってはAdvertising IDでは無くAndroid IDを端末の識別子として利用しているという点は、2016年にもなってそんな事するか?? と疑問ポイント。使える物は便利に使ってる、というだけかもしれないが。


このエントリーをはてなブックマークに追加