2017-11-07

オライリーから「仕事ではじめる機械学習」という本を出しました

オライリーから「仕事ではじめる機械学習」という本を出しました。技術書典2で頒布した同人誌がベースで引き続き @chezou, @tokoroten 両氏と共著です。実務者向けの内容で対象読者は情報システム開発現場のエンジニアです。


私は同人誌版で「ゲームの試合結果データのマイニング」の章を書きましたが、今回はより実務的な内容として効果検証について書いています。主に仮説検定と因果効果推定です。内容はChezouさんの告知を参照していただくとして、補足とバックグラウンドを紹介します。

お前だれよ

インターネット広告配信システムの配信ロジックの開発をしています。2015年まではデータを集める所から分析基盤の構築を経てBIツールの導入、バッチ処理環境へのワークフローエンジン投入といった足回りの仕事がメインでした。今は足回りが整ってきたのもあり、その上で動かす機械学習モデルの訓練処理やアプリケーション側の予測処理を実装しています。

とはいえ機械学習に関してはKaggle Masterじゃないし情報工学で博士を取ったわけでもない素人です。データ分析チームの中の担当はビジネスサイドの要望を聞いて問題をKaggleの出題レベルの粒度に分解したり、論文を漁ってベースライン手法を見つけて実験したり、バッチ処理のパイプラインを組んで本番稼動させたりです。

特徴

エンジニアがプロジェクトをどう進めるかといった内容ですが、著者が3人ともプロダクションに投入してなんぼの実務者である事から、稼動環境としてHadoop Familyのプロダクト名がさらっと出てきたり、現場であった怖い話が随所に出てきます。アルゴリズムやモデルの詳細については主題から外れているため解説はありません。

書けなかった事

ワークフローエンジンやバッチ処理の設計については時間が許せば書きたかった所です。
機械学習が絡むバッチ処理は例えば複数の予測器を訓練した後にそれぞれの予測結果を入力として凸最適化を行ない結果を保存といった、依存関係をもった複数のタスクが連携する物となります。また、本番で利用しているモデルの他にハイパーパラメータを変えた物や新しく検証したいモデルの訓練・評価も日々のバッチ処理に載せたくなるでしょう。訓練の前に必要な中間テーブルの作成やデータの前処理、後に続くの評価レポートの作成やモデルのシリアライズも含めると複雑なパイプラインになりがちです。タスク毎に必要な計算資源も異なるため、一つのサーバーで全てを終らせるよりも複数の実行環境*1を組合せて利用した方が効率的です。
ワークフローエンジンを利用する事でタスク間の依存解決や実行順序・並列実行の制御をまかせる事ができます。障害発生時の影響範囲の把握・リトライ・リカバリが容易になる点も運用面で大きなメリットもあります。

一体何を供養していたのか

技術書供養寺の時に内容告知を書いていなかったのでこの機に解説します。同人誌版はボツになったデータ分析ネタを集めようという事で、私はElo ratingやStarCraftの勝敗予測手法を紹介し、スプラトゥーンのブキの強さ分析を行ないました。分析はstat.inkのデータを使いBradley–Terryモデルにあてはめて最尤推定でステージ毎のブキの強さを求めるといった内容です。ダイナモローラーが強かったですね。これは Statistical Emerging Pattern Mining with Multiple Testing Correction のデータ集めを手伝った際に行なった分析です。

大変ありがたい書評

一方で「整形されていないログとかはあるんだけど、ここから特徴エンジニアリングをどうやればいいの?」とか「リアルタイム予測に耐えうるような予測モデルと特徴ベクトルってどうやって作ってどこに保持すればいいの?」とか「コールドスタート問題は結局どうやって乗り換えればいいの?」といった具体的かつ詳細な実現方法をこの書籍で身につけるには、ちょっと難しいかと思います。
確かにこれらの点は自分も自信が無く、これがベストと言いきれないので知りたい。コールドスタートは事前分布を仮定して事後分布を更新していく方法だとか、バンディット使ったり、データが無い所は決めうちロジックが走るとか、割り切り面も含めて。応答速度の兼ね合いで訓練処理と予測処理の言語が異なるケース*2はどうしてるんでしょうね皆さん。


媚を売られてしまった。
個人的にワークフローフレームワークは嫌いで機械学習プロジェクトでは使いたくないとまで思っているんですが、まあ便利なので書籍内で取り上げてもらって筆者のプロの方々がどう考えているのか知れれば良かったなあ〜みたいな感じなので
ワークフローエンジンについては上に書いた通りです。今はAWS Batchのようなクラウドサービスで機能が提供されているので導入しやすいかもしれませんね。導入したらしたで単一障害点になる奴なので、可用性の担保をまかせられると安心。
AWSの新しいサービスを触る時間でKaggleをやったほうが良いのでは?
すごい良くわかる。ここは自分もどうすべきか悩んでいる所。ただチームメンバーのサポートがあるなら、リリースするのに何が必要か抽象レベル*3での理解があれば良いかも。仕事を振る側からするとKaggleっぽい仕事に集中したいならKaggleっぽい仕事を切り出すし、ビジネス寄りがやりたいなら要件定義をまかせるので、チーム内でのスタンスを明確にするとやりたい仕事が降ってくるとは思う。

------
*1: GCPを使っているならGCE・BigQuery・Cloud Dataflow・Cloud Dataprocあたりの組み合わせ
*2: 自分は予測処理を自前実装できるロジスティック回帰等を使いがち
*3: 監視やスケジューラー、計算資源の確保といった単位

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

2017-08-28

KDD2017感想 Tutorial Day: Asking the Right Business Questions?

データマイニングの国際会議であるKDDに参加してきました。まずは1日目のチュートリアルの感想です。

From Theory to Data Product: Applying Data Science Methods to Effect Business Change. 

http://www.t4g.com/kdd2017/

ビジネス現場におけるデータ分析プロジェクトをいかに回すかといったテーマ。T4Gというカナダのコンサルティング企業が実際に使っているフレームワークに沿った内容で、次の3部構成。
  1. プロジェクトの初動に何をすべきか。業界とトップダウン or ボトムアップで何が変わるかのケーススタディ
  2. 具体的なアクション導き出すための「Right Question」
  3. アジャイルプロセスを応用した意思決定
講義に加えてそれぞれの課題が渡されてグループディスカッションを行なった。どちらかといえば、現場リーダー向けの話。

参加者は20名程度で他のチュートリアルと比較すると少なかったが、内容に対する反応からほとんどは実務者である事が見てとれた *1。そして常日頃から「実装に集中したいから、腕の良いプロジェクトマネージャーが降ってこないかな」と思っている自分にとっては得るところが大きかった。特にプロジェクトの具体的なアクションを決める際の「Right Questionの導出」のくだりが印象的だった。そこからActionableで実行すると計測可能な結果が得られる物とせよ、という話に続く。

プロジェクトで具体的に何をするか(作るか)を決めるのは難しい。所謂データ分析チームで仕事をはじめて2年経つが、半年以上かけて開発に取り組んだ予測器が実は不要だったケース、課題解決のアプローチを間違えたまま進めて成果に繋がらなかったケースを見てきた。
例えば「事業の粗利率が低い」みたいな課題があったとして、タスクをKaggleの出題レベルの粒度まで分解して落とし込むには課題解決のための道筋と具体的なアクションを決める必要がある。しかしこの能力はKaggleのランキングの様に可視化されない物であるし、能力のある人間の採用も難しい気がする。そもそも職場でコンサルっぽい職種の採用をしていないので、迷いなくコードを書くためには自分ができるようになる必要があるなと思った。

参考: T4G: Are You Asking the Right Business Questions?

A/B Testing at Scale

http://exp-platform.com/2017abtestingtutorial/

午後はMicrosoftのプロダクト改善にまつわるA/Bテストの話。月に1,000個のA/Bテストを回せるシステムがどうなっているかというと、いろいろ凄かった。
実験対象のユーザー群の抽出がシステム化されており、過去のデータを使ってA/Aテストをして即座に実験が開始できるようになっていたり。ユーザーを保護するために結果の悪い実験のアラート通知と自動停止。相互作用のある実験を同時に流すとテストにならないため、実験同士の相互作用を検出したり。
システムの話だけでなく、プロダクト改善のためには何を指標として計測すべきかという根本の話もあって良かった。

本会議のセッションでも統計的検定やp値ハック、因果推論とからめた施策の効果測定ネタがあったので、データマイニング界隈でホットなトピックの一つなのだと感じた。

2日目の感想、AdKDDのまとめに続きます。

----
*1: グループ課題の問題文の1行ごとに「Flequently……」と呟く人がいて面白かった

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

2017-08-01

人工知能学会誌に「アドネットワークにおける広告配信計画の最適化」という記事を寄稿しました

人工知能学会誌の特集「広告とAI」に仕事でやっている事について寄稿しました。



詳しくは職場のブログに。

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

2017-07-12

DATUM STUDIO Conference 2017で講演してきました

お仕事の事例紹介になります。

発表といえば普段はエンジニア向けの内容になるのですが、今回はエンジニアはほぼいないだろうという見込みがあったので悩みました。 結局はいつもと変わらないスタイルに、後で面白かったと感想がもらえて安堵しました。


正直、他のスピーカーの経歴と肩書が凄くてびびった。

発表スライド

感想

普段Web業界の事例ばかり見ているので、映画の興行収入の予測であったり、養殖している魚の成長予測といった話は新鮮だった。 中古車の買い取り業務、魚の養殖の餌やりといった職人の勘の世界だった物が予測モデルに置き換えられていく過程は面白い。

自分はエンジニアなので分析といえばPythonやR使ってガリガリやるイメージが強かったが、統計モデリングソフトを使ってコードは書けないけど統計はわかるという人が分析しまくってる世界があるのを知れてよかった。

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

2016-12-06

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

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

スライド


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

感想

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

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

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


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