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

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

O'Reilly Japan - 仕事ではじめる機械学習
https://www.oreilly.co.jp/books/9784873118215/

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

お前だれよ

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

特徴

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

書けなかった事

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

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

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

大変ありがたい書評

「仕事ではじめる機械学習」を読んだメモ - k11i.biz
http://k11i.biz/blog/2017/10/26/ml-at-work-book/

一方で「整形されていないログとかはあるんだけど、ここから特徴エンジニアリングをどうやればいいの？」とか「リアルタイム予測に耐えうるような予測モデルと特徴ベクトルってどうやって作ってどこに保持すればいいの？」とか「コールドスタート問題は結局どうやって乗り換えればいいの？」といった具体的かつ詳細な実現方法をこの書籍で身につけるには、ちょっと難しいかと思います。

確かにこれらの点は自分も自信が無く、これがベストと言いきれないので知りたい。コールドスタートは事前分布を仮定して事後分布を更新していく方法だとか、バンディット使ったり、データが無い所は決めうちロジックが走るとか、割り切り面も含めて。応答速度の兼ね合いで訓練処理と予測処理の言語が異なるケース^*2はどうしてるんでしょうね皆さん。

「仕事ではじめる機械学習」を読んだので作者に媚を売る - Stimulator
http://vaaaaaanquish.hatenablog.com/entry/2017/10/29/222239

媚を売られてしまった。

個人的にワークフローフレームワークは嫌いで機械学習プロジェクトでは使いたくないとまで思っているんですが、まあ便利なので書籍内で取り上げてもらって筆者のプロの方々がどう考えているのか知れれば良かったなあ〜みたいな感じなので

ワークフローエンジンについては上に書いた通りです。今はAWS Batchのようなクラウドサービスで機能が提供されているので導入しやすいかもしれませんね。導入したらしたで単一障害点になる奴なので、可用性の担保をまかせられると安心。

AWSの新しいサービスを触る時間でKaggleをやったほうが良いのでは？

すごい良くわかる。ここは自分もどうすべきか悩んでいる所。ただチームメンバーのサポートがあるなら、リリースするのに何が必要か抽象レベル^*3での理解があれば良いかも。仕事を振る側からするとKaggleっぽい仕事に集中したいならKaggleっぽい仕事を切り出すし、ビジネス寄りがやりたいなら要件定義をまかせるので、チーム内でのスタンスを明確にするとやりたい仕事が降ってくるとは思う。

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