機械学習エンジニアの田口です。
現在私が所属するリクルートテクノロジーズのデータイノベーション推進部は、各事業会社(じゃらんやホットペッパーグルメ等の運営会社であるリクルートライフスタイルや、カーセンサー・ゼクシィ・スタディサプリなどの運営会社であるリクルートマーケティングパートナーズ等）とタッグを組み、データ活用の側面からサービスの価値や収益性を高めていくという活動をしています。
その中で僕はデータを使ったプロダクトの開発/運用を担っており、自分で開発したプロダクトとともに、DataRobotの社内運用や活用推進にも携わっています。
※良いプロダクトであれば自分たちで開発したものでなくとも積極的に利用し、そのプロダクトに対しての要望も積極的に出して行くようにしています。
今回、機能リクエストと社内事例共有のため、DataRobot本社(ボストン)に訪問してきました。
リクルートはDataRobotに出資しており、日本で最初に大々的にDataRobotを導入した実績があります。
DataRobot社の方とは、社内でどうデータ活用を推進していくか・より高度化するためにどうしていくかということを定期的にお話していますが、時々製品の仕様/機能まで踏み込んだ話が出てきていました。
DataRobot Japanの方々も様々なクライアントから出てくる主要な改善ポイントをアメリカの本社にフィードバックしていましたが、グローバルで現在固まっている仕様/機能については当然簡単に動かせるような話ではありません。
我々としては日々感じていることをぶつけることで、データを使った価値創造をより早く・楽に・高度に実現していくためのプロダクトになって欲しいと考えていました。また、DataRobot社としても様々なテーマでプロダクトを活用している生のユーザの声を聞けることに価値を感じていただける（生のユーザの声を現場に理解してもらい、改善点を効率的に炙り出し、より良い製品を作っていきたい）と言っていただけたので、今回の本社への訪問が実現しました。
調整してくださったDataRobot Japanの小川さん、ありがとうございました！
以下では訪問した際に仕入れてきた内容について共有したいと思います。
時系列モデルの概要とDataRobotにおける実装について
みなさんMichael Schmidt氏はご存知でしょうか？
彼の紹介の仕方は様々あり、
・時系列モデルを専門で扱っていたNutonian社の元CEO
・DataRobot社の時系列予測部門マネージャー
・2017年、Forbesで最も影響力のあるデータサイエンス人材100に選出された人物
・時系列モデルの世界的権威
というスーパーマンなのですが、幸運にも彼と直接話し、DataRobotにおける時系列モデリング実装についてお話を聞くことができました！
以下聞けたお話を簡単に列挙します。
・DataRobotで採用している時系列モデル3種
1:ARIMA等の自己回帰系
2:xgboost、lightGBM等のkaggleでよく使われる高精度ツリーベースのものをtime-awaredにしたもの
3:(線形)補間ベース
上記それぞれのモデルが従来のDataRobotと同様に自動でモデルが構築され、高精度のものを選択する仕様になっています。
弊社でも昨年の大事なモデリング案件で上記2種目（time-awared,xgboost）が実装され、プロダクション環境にデプロイされていたこともあり、非常に納得感のある内容でした。
・特徴量作成
時間を表現する変数をデータ投入後に指定してあげる必要はありますが、RAG変数等、時系列モデリングに重要な変数を自動で作成してくれます。
予測対象期間の指定
翌ポイント予測しかしないケースや、nポイント先まですべて予測するなど、予測対象期間が簡単に変更できます。
加えて、実際にデータが手に入るタイミングを考慮することも可能です。例えば、「3日前までの1ヶ月分のデータを使って5ポイント先まで予測」といった具合です。（発生するデータが整形されて手に入るには3日ほどかかるため）
時系列モデリング機能は現在専任者15名以上の体制で開発されているらしく、今後の発展もとても期待できる印象でした。
ちなみに、今回同僚がlightGBM、prophetの実装、ホールドアウトの複数用意(※)をリクエストしたのですが、lightGBM、prophetは最新版ですでに実装済みでした。早い・・・
ホールドアウトはMichaelが興味を持ってくれたので、実装されることを期待しています。
※従来ホールドアウトは全データに対して1つが用意されているのみですが、バリデーションセットと同様、複数セット準備してほしいとリクエストをしました
事例共有
自分たちがいかにしてDataRobotを使い、社内で広めるための動きをし、実際に価値を生み出しているかを共有しました。DataRobot Japanの小川さんからも事前に「ユーザ事例の生の声は現場に大きく響く」とお話いただいていましたが、その事前情報に違わず、僕らの発表が終わった後には予想より多くの質問をいただくことができました。
打ち合わせ時間の待機場所がないのでオープンスペースで待機しているときにも、みなさんフレンドリーに、聞きたいことをどんどん質問してくれました。
発表内容の詳細は社外秘を含むため割愛させていただきますが、自前でDataRobotをホストするサーバを構築(※)し、運用/活用推進の担当を置いても大きくペイする結果が生み出せていること、用途は多岐にわたること、現場の人たちが効果を出すことを念頭に置いて、我々データ部隊が必要なサポートをふんだんに行なっていることをお話しました。
(※)社内セキュリティ要件を満たすため
本社の方が特に知りたがっていたのは、ビジネスサイドでデータ分析に知見がない方がDataRobotを使って大きな効果を上げるまでのプロセスについてです。私見ですが、現状効率のいいショートカットは見当たらず、愚直に目的やデータ、プロセス、フィードバックループ、実際の業務装着について知見がある人とタッグを組んでやり遂げていくのが良いのでは、という印象を持っています。
本社の方々にも共有したのですが、リクルート内部限定で200人規模のユーザーカンファレンスを実施した際、登壇した人は全員僕らのようなデータ寄りの知見がある人間とタッグを組んだ上で上記のループを回し、成果を出していました。
DataRobot社主催のカンファレンスでは「リクルートのデータ活用は進んでいる」と言ってもらえることもありますが、実態は上記の通り、ビジネス、データそれぞれの知見がある人がタッグを組んで、泥臭くいいモデルができるまで改善のループを回し続けているだけです（※）。
余談ですが同ミーティングはDataRobot Japanにも繋がっていまして、そのことを後から知らされた僕らはやや気恥ずかしい思いをしました。考えてみれば「全社」ミーティングなので当然ですね。とはいえ先に言ってほしかった！
(※)ビジネスサイド/データサイドの役割分担
リクルートグループ内での、データ活用プロジェクトのライフサイクルと役割のイメージ
上記テーマだけでもう一つ記事が書けそうな予感しかしないので、ここでは触れません。
feature requestと将来の方向性について
今回訪問目的のメインです。ユーザへのヒアリング結果や、インフラ側で改善を求めている部分を洗い出すと、大小含め合計約30ものリクエストが出ました。が、ここでは優先度の高いものに焦点を絞って伝えることに。
・予測サーバの利用コントロール
リクルートグループではDataRobotをオンプレで利用しており、リソースを多くのユーザで共有して使っています。
ユーザあたりの利用可能上限は当然ありますが、全体での利用可能上限も存在するので、リソースは早い者勝ちです。
同じ部署の中で利用者全員が使ったりするとリソース割り当てに不公平感が出て、全体の不利益につながるので、ユーザグループごとの上限も設定できるようリクエストしました。
・API互換性の担保
DataRobotはR&Dに非常に積極的であるため、新たな機能が追加されたり、もっと使いやすくなったりといったことが比較的多く起こります。一方でそうした場合に対応するAPIが存在しなかったり、違うまとめ方をした方がいいケースがあったりするのも事実です。
とはいえ機械学習はプロダクション環境にデプロイされて初めて価値を発揮しうるものなので、安定稼働しているコード内部で呼んでいるAPIの仕様変更が頻繁に起こってはメンテナンスのコストが(DataRobotを利用していればしているほど)高くなってしまいます。
とはいえ全く変更しないのは不可能なので、折衷案でn世代分の後方互換性を担保してほしいとリクエストしました。
プロジェクト管理
とあるサービスではDataRobotを使ったモデル構築数や関わる人数がどんどん増加しています。当然関わる人数が増えるほど、その中の人が異動や退職をする可能性も上がります。そうした際には当然作成したモデルの移譲や共有、消去が必要になってきますが、現在当該の操作は1つずつ、すべてマニュアル操作で実施する必要があります。APIの話もそうですが、プロジェクトが大きくなり、DataRobotを使えば使うほど管理の手間が増えるという仕組みになっていることが大きな負なので、現在より簡単にモデル/プロジェクトの移譲、共有、消去ができるようリクエストしました。
新機能
すでにクラウド版では機能が公開され始めましたが、モデルマネジメントの機能についてお話しいただきました！
今までのDataRobotのスコープは特徴量加工〜モデリング、API公開まででしたが、その後のモニタリングにまで踏み込んでサービスを提供し始めました。
新機能第一弾は変数ドリフトのモニタリングだけに絞られているようですが、今後は精度のモニタリングや精度低下時の自動モデルリフレッシュがスコープに入ってくる模様です。プロダクションレベルのモデルがお気軽に作れ、かつわかりやすい精度経緯のダッシュボード、高精度のモデルが適用され続けることが概ね保証されたデータサイエンスプラットフォームに進化を遂げている印象です。
もともと実世界でデータを使った価値を作り出すために必要なのは、大まかに言えばドメイン知識＋生データのクオリティ、前処理とモデル作り、プロダクション環境への装着、およびモニタリング、モデルリフレッシュの機構でした。本機能が提供されたことによって、多少大袈裟かもしれませんが本当に必要不可欠なのは前者2つだけになったのでは・・・
かの有名な統計家が最もセクシーな職業になる、と言われていた2009年当時の状況(※NewYork Times、2009年8月5日の「For Today’s Graduate, Just One Word: Statistics」“I keep saying that the sexy job in the next 10 years will be statisticians,” said Hal Varian, chief economist at Google. “And I’m not kidding.”)と比較すると、驚くべき状況になってきていますね・・・(そしてあと1年で2009年から見たときの10年が終わってしまう・・・)
番外編
真似したい
全会議室にmacが置いてあり、当該macにzoom(TV会議システム)で繋いだ上で画面共有でスライド等々を映す。一手間かかるが、PCのジャックを気にしなくて良くなる上、録画した会議の内容を振り返ったり、全世界に共有可能。特に新機能の従業員に対するトレーニング等だと、非常にうまくワークする。(小川さん談)
・写真
受付
オフィス
部門ごとの所在がわかりやすい！
炭酸水飲み放題
気軽な質問
feature request
