Slackを通じて正解ラベルデータを集める
分析の精度を高めるために、正解ラベルを集めるコストはなんだかんだ大きいです。
よくある話ですと、がんばってラベル付けしたデータから学習したモデルをデプロイし、日々送られてくるデータのラベルを推論します。そして、予測スコアがある閾値を超えたら、Slackに通知する(「スコア ~~ で、異常が検知されました」など
)サービスを考えます。
そのSlackの通知をラベル付けを担当する人が見て、「うーん、これは誤判定だな。」とか「おお、これは異常だ!すぐにエスカレしなければ!!」と判断します。
このとき、その判断した結果をすぐにデータ化(ラベリング)する仕組みがあると、最新データで継続的にモデルの学習を行うことができ、性能をアップデートするのに非常に役立ちます。
そこで、SlackにInteractive Button付きのメッセージを投げて、ラベル付けを担当する人がボタンをクリックすることで、データ化する仕組みをPythonで作りました。
通知のイメージは以下のとおりです。
実装は、コードのとおりですが簡単に言うと、
- APIサーバをFlaskで立てる
- 通知がほしいときに、
/post
を叩き指定のチャネルにInteractive Button付きのメッセージを通知させる - ボタンのクリック結果を、通知したメッセージのリプライで返す。その中で、データ化する処理も別途書けばOK
- この
データ化する処理
はGithubの方には書いていませんが、例えば、推論に使用したデータを保存しているデータベースのテーブルにインサートしていくとかです。
- この
Slackアプリ、まともに作ったのは初でしたが、形にできるまで楽しかったです。Slackを通じてボタンクリックだけからチャートを作る仕組みも考え中…
参考
任意の相関係数をもつデータを可視化するShinyアプリを作った
「人工知能システムのプロジェクトがわかる本」を読んだ
人工知能システムのプロジェクトがわかる本 企画・開発から運用・保守まで (AI & TECHNOLOGY)
- 作者: 本橋洋介
- 出版社/メーカー: 翔泳社
- 発売日: 2018/02/15
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
この本を読んだ目的
- ML Engineerとして機械学習システムを構築する際に、必要な要件をもれなく把握しておくのに適していそうな本を見つけたため
- 著者はNECで30以上システム導入経験があり、ノウハウが溜まった知識をすぐに知れそうだと思ったため
書評
タイトルのとおり、人工知能を積んだシステムを提供するときに考えておくべき項目がまとめられていた。 全体的に理解できている内容も多かったので、再確認することが多かったため、さくっと読めました。また、システムの運用の話まで入ってる本は珍しいので、とても参考になりました。
備忘メモ+感想
1章 実用化されつつある人工知能
分析の基本的な話
2章 通常のシステムと人工知能システムの開発プロセスの違い
1.企画フェーズのあとにトライアルフェーズがあること
2.開発フェーズの内の要件定義時や納品前にデータ分析を行うこと
特に3がよくある負債の話。
3章 人工知能システムの企画
人工知能システムの運用・保守の代表的な作業
再学習 予測結果や精度の確認 新対象の追加 人工知能の挙動に対する問い合わせ応答
特に、よく聞かれる問い合わせとかは先にまとめておいたほうが良いと感じますね。本の例にもあった、人間の直感と反する場合の結果がでたときや、急に精度が悪くなった時の理由説明をスピードよく提供するとかですね。
4章 人工知能プロジェクトのトライアル
時間集計粒度 = 時間分解能
という言い方は知らなかった
回帰問題での評価指標
平均誤差 平均誤差率 最大誤差値 一定値以上の誤差値の割合 上振れ誤差率 下振れ誤差率
研究とかだと、RMSEが一般的だったりするが、データマイニングのように問題にあった評価指標を選定する感じがあって良いですね
5章 人工知能システムの開発
データ量の決定(例:どれくらい過去のデータを使うか)
モデルの更新方法の決定(例:バッチかオンラインか)
学習データが少ないときの対応(例:抽象度が高いデータを使う)
異常値処理方法の決定
よくある話でした
6章 人工知能システムの運用・保守
精度の日々の確認
人の知見・直感に合わない結果に対する原因
学習データに要因となる特徴が入ってない
運用時のデータの傾向が大きく変わっている
過学習してる
レアケースすぎて学習できてない
結果がワンパターンすぎる
レアケースすぎて学習できてないとか結構あるんだよな…
「データ分析・AIのビジネス導入: プロジェクト進行から組織づくりまで」を読んだ
失敗しない データ分析・AIのビジネス導入: プロジェクト進行から組織づくりまで
- 作者: 株式会社ブレインパッド,太田満久,井上佳,今津義充,中山英樹,上総虎智,山?裕市,薗頭隆太,草野隆史
- 出版社/メーカー: 森北出版
- 発売日: 2018/07/13
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
この本を読んだ目的
- Twitterで良いと見て
- AIのビジネス導入とか考えるえらい人にこの本読んでとおすすめできるように
- ビジネス導入のつらみは大雑把にはわかってるつもりでしたが、体系的に読んで、知らなかったことをまとめておく(自分の言葉で言えるようにする)ため
書評
ブレインパッドのノウハウが凝縮されているような本でした。コンサルの本らしく期待通り体系的にまとまっててとても良かった。データ活用したいとか言ってる人にはぜひ一度読んでもらうのが良いと感じました。
備忘メモ+感想
1章 AI導入はなぜ失敗するのか
データ分析プロジェクトの7つのリスク
1.分析の進め方として時間と成果が比例しないリスク
2.データの量や質が不十分なリスク
3.データへ依存するリスク
4.データのトレンド変質に関するリスク
5.分析結果に関するリスク
6.分析結果が活用されにくいリスク
7.システム化するときのリスク
このリスクとかあるある。案外最初の1とかってリスクとして提言したことなかったなー
2章 データ分析の基礎を押さえる
データ分析をビジネスに適用する際に注意すべきポイント
1.分析遂行前に業務におけるユースケースや必要な入出力情報、必要精度や評価指標を明確にする
2.初期段階で、概念検証(PoC)段階を設け、適用可能性やリスクを把握する
3.ビジネス適用に際しては、人の判断の入る余地を残す
4.必要なデータを収集、分析する環境を確保する
1章であげたリスクを回避するポイントが上記4つ。人の判断の入る余地を残すは大事だなと思うので、AI適用には、HCI的な知識は必要だなと日々感じる。
最近読んだKDDのAirbnbの論文も人の判断をうまくパラメータにいれて最適化してるのを見ても、人の判断を入れるところまで意識してモデルを作り込んでみたい
ビジネス適用上の問題点
1.ビジネス理解
2.データの理解・準備
3.評価指標の選択
4.ビジネスインパクトの算出
データ分析は「すべてはデータから始まる」というボトムアップ的な特性から、全体感を失いがちである。
そのため、結果をどう活用するのかという大局的なビジネス的観点に絶えず立ち返ることが必要
なるほど、ボトムアップ的な特性が強いから、全体感を失いやすいのかという整理に納得しました。
3章 データ分析の仕事の流れを理解する
プロジェクト立ち上げ -> PoC -> ビジネス適用
この流れがデフォルトですよね
PoCを実施する理由
データ分析プロジェクトは不確実なことが多い。プロジェクトの目的・目標の実現可能性を評価するため
PoCってとくにデータ分析プロジェクトに特別多いことではないと思いますが、結局は不確実性が強いプロジェクトに役立つということかなと感じています
4章 プロジェクト立ち上げ
【ゴール設計】
1.プロジェクトの目的の設定
-ビジネスの理解
-分析結果の活用法検討
2.データ利活用で解決可能な目標の設定
【アセスメント】
3.活用されるデータの収集と概要把握
4.スコープの設定
5.プロジェクトメンバーの選定と役割の設定
例:
-目的:ECサイト内での売上向上
-目標:データから顧客の理解を深め、レコメンドアルゴリズムを洗練させることでCTRを1%向上させる
良いですね。新たな分析案件がはじまるときは、上のフレームワークにあてはめてみようと思いました。
5章 PoC
揃えておくべき認識
1.分析結果はどのようにビジネスに活用されるのか
レベル1 : 結果を人が見て、意思決定の参考情報にする
レベル2 : 意思決定は人が行うが、意思決定者に具体的行動を提案する
レベル3 : 意思決定を含めた自動化を行う
2.何が対象か
3.どんな出力値が必要か
4.モデルにはどの程度解釈性が必要か
5.分析結果をどのように評価するか
6.利用するデータに制約はあるか
7.処理時間に制約はあるか
8.環境面の制約はあるか
これも自分のフレームワークにできそうでした。個人的には、時間的制約と意思決定者自体の不確実性度合い(笑)なんかも必要と感じました
6章 ビジネス適用
PoCとビジネス適用の違い
1.PoCは実験用のコードである = コードの品質を高める
2.システムや業務フローに関する検証 = デプロイするときの実行環境を意識する
3.常時更新されるデータ = 随時流れるリアルデータに適用することを意識する
これは普段から意識してることです。PoCの段階で、上記が発生することを知ってPoCをやるかやらないかで、ビジネス適用に進むスピードも全然違うので、特に気をつけています
PoCでできたモデルを実環境に乗せるためにエンジニアの後任者に渡す場合、 ドキュメントに残すのは詳細に必要。
理由:なぜこの処理が必要とされるか?なぜこの特徴が必要されるか?などの理由により、当初の意図が伝わらず、謎の処理が残ってい くことになる。
まさによくある機械学習の負債話。。
機械学習システムと普通のシステムとの違い
1.外部データへの依存と暗黙のフィードバック
2.挙動が確率的である
3.実装が複雑になりやすい
挙動が確率的という言い方は、学習データに応じてモデルも確率的に変わるという見方があるからなのかなーと考えました
7章 データ活用する組織を作る
組織論は組織によるところが多すぎるーーと思ってるのですが、「分析をスケールさせる=人を学習させていく」ことがデータ分析組織を作る考え方の前提にあるというのが、普通の組織とは違い難しいところかなと改めて感じました
KDD2018 : Customized Regression Model for Airbnb Dynamic Pricing を読んだ
論文はこちら:KDD 2018 | Customized Regression Model for Airbnb Dynamic Pricing
Airbnb の Applied Data Science Track Paper。読んでみてAirbnb特有の問題でもあるのかと思いきや、価格付けをサービス事業者側から提案するアプローチは、C to Cサービス等を提供する企業などで導入できる考えがあり、勉強になりました。
概要
商品の最適な値段付け(ユーザがぎりぎり買うまで高く値段付けしたい or 買わなかった商品を買ってくれるぎりぎりまで低く値段づけしたい)は難しいが、独自のメトリクスを定義して、値段付けが悪くならない方向に最適化を行う方法を提案。結果はAirbnbのデータで良好な結果を得ており、すでに1年以上デプロイしてるモデル。
Introduction
ホスト(部屋を貸す人たち)は自由に各日の宿泊費を設定できるが、Airbnbから適正な費用提案(Price Suggestion)をしたい。市場動向を考慮しながら日々動的に適正な価格付けをする方法を提案する。
動的な価格付けをするための困難なところが、需要の見積もり変化(時間変化とリスティング変化)と部分的な価格適用(ホストの値段設定の考えもいれるところ)。
リスティングってのは部屋という意味でいいのかな。リスティング変化とは、ホテルは部屋が同じ作りであるものが多いが、一般に家の部屋の作りはすべて異なるため、部屋の評価レビューを考慮しながら部屋ごとに値段設定する難しさがある。高すぎると予約されなくなることも考えながら。
価格と時刻とリスティングにより、需要曲線が決まる。
適切な価格付けを行うPricing Modelsは3段階の構成にわかれている。
1つ目に、今から部屋が予約される夜までの間に部屋が予約される確率を分類モデルを構築する。
2つ目に、予約確率を特徴に入れ、値段付けモデルを構築する。
3つ目に、値段付けモデルは、ホストの値段設定の考えを適用して、最適化する。
これらの結果、研究としては、価格付けの効果を評価するメトリクスと悪い価格提案が起こらないようなモデルを導入できたことが貢献。
Pricing System Overview
Booking Probability Modelはある部屋の未来のある日が予約されるかどうかを予測する。一般的な2値分類モデル。学習に使う特徴として、部屋に関わる特徴・時系列特徴・需要と供給の特徴(近隣の予約できる部屋の数など)を使う。
Gradient Boosting Model(GBM)を使う。学習は、市場の大きさで3段階に分けるなど、エリアごとに学習モデルを作ったほうがGlobal AUCの精度があがったみたい。ここで、場所ごとにサンプリングレートを変えるなどのテクニックもある。
推定されたモデルの予約確率(y軸)と値段(x軸)を見てみると、真のデータよりも、端にいくほど外れている事がわかる。
この問題の難しいところとして、データのスパースネス(基準となる値段から離れたところをあてるのは難しい=price extrapolation)、ユニークネス(部屋は一つ一つがユニークなものが多く、一般化するのは難しい)、値段に依存した特徴(値段が高すぎると、利用率の特徴量が小さくなるなどがあり、値段との相関が悪さをする)などが考えられる。
そこで、収益最大化のアプローチもやったと書いてるが、最適な値段というデータがない(データにあるのが最適な値段といえないので)ので、うまくいかなかった。最終的に、最適な値段付けのための正しい評価メトリクスを作ったほうがいいねとなった(そう考えるのか!)
Evaluation Price Suggestion
一般的な回帰の教師あり学習と違って、最適な値段というデータがないので、私達の値段付けの性質を使った評価メトリクスを導入する。
アイデアとしては、正しい値段を考えるのではなくて、何が悪い値段づけなのかという方向から考える。
実際の部屋の値段を、提示する部屋の値段を、最適な値段(存在すれば)をとする。
悪い値段付けとは、「値段で予約された部屋を < で値段付けしてしまうこと」ゆえに、この場合は。逆もしかりで、「値段で予約されなかった部屋をで値段付けしてしまうこと」なので、この場合は < 。
また、提案した値段付けが良いか悪いか判断がつかないものとして、値段で予約された部屋をで値段付けすること。値段をこれ以上上げても予約はされたかどうかが判断がつかない。もちろん、逆も同じ。
ということで、以下の表ができあがる。
上記の考えから、5つのメトリックを定義する。実際には、以下の2つの指標を特に重要だと述べている。
と である。
は、予約されなかった部屋のうち、値段付けが実際の値段より低くできたもの。大きいほうが悪くはない。
は、予約された部屋のうち、値段付けが実際の値段より低くしてしまった部屋の場合、損失率を計算し、それ以外は0。それらの中央値を返す。小さいほうが悪くはない。
この2つはトレードオフの関係にあるので、を改善しながら、なるべくを大きくしないような最適化を考える(なるほど)
Strategy Model
この章で、本質となるモデルがでてくる。まずは損失関数を定義する。
特徴(もともとの値段やGBMが算出した予約確率など)を含む対象とそれの予約の有無を表すからデータを用意する。
サンプルに対して、モデルが付けた値段をとする。一旦パラメータのことは置いておく。
損失関数は、Support Vector Regressionで使われるε-許容誤差の考えを参考に、以下の損失関数を定義する。
ここで、 と である。
これを理解するのは、以下の図を見るのが早い。
つまり予約されたサンプル()はもともとの値段よりも少し大きいくらいなら損失は0にする。
逆も同様の解釈でいける。この幅をもたせてるのが、ε-許容誤差と似てるが、LとU次第にかかるパラメータc次第で幅は大きく変化する。
続いて、最適化するパラメータを含むについて。
モデルが付ける値段を定式化していくわけだが仮定として、「(1) 予約確率と相関はあるように付ける (2) もともとの値段の周りに付ける (3) なんらかの需要がでたときに容易に追加できるように」という3つのアイデアを入れて定式化する。
それが、 で、Vは以下。
はもともとホストがつけた値段、はGBMが付けた予約確率、が需要スコアといって、各マーケットごとに決めるダイナミックに変わる需要量。
は制御パラメータ、は微調整パラメータと読める。
需要スコアはガウス分布で正規化する。高いほど、需要が大きい。それを制御するパラメータ1 < < < 2 で設定する。2つあるのが、UpとLowで別々の比率がほしいので、これが非対称(下図)
あとは、との勾配を求めて、収束したら、が求まる。
学習時のテクニックとして、GBMを学習するときはマーケット別に学習したが、このStrategy Modelはすべてのデータを使う。これは、同じマーケットで同じ部屋でも、ホストがつける値段がバラバラすぎるので、全部のデータで学習したほうがホストの依存が少なくなることを期待しているみたい。
あと、との範囲に制約を入れるなどで、非現実的な値段にならないように調整する。学習には、Sparkを用いて確率的勾配降下法 (SGD)で最適化する。また制約をいれても、Proximal Algorithm(近接法)で容易に求まる(らしい)
Experiments
ある期間のデータを使ってオフライン評価を行う。
がStrategy Modelが値段付けした日、 が予約の有無のラベル集めた日、その間に1つ以上の予約があれば、その対象は正例となる。
3つのデータセットを使って、とを評価する。需要曲線に基づいて予想される収益を最大化する費用を提示するナイーブなモデルと比較する。
結果は、そのナイーブなモデルと比べて、良好な結果(下表)。
評価指標に基づいて悪い提案を避けるモデルに設計した効果がでている。
すでにこのモデルを1年以上デプロイしているが、着実にこのメトリクスでみると、改善が行われているとオンライン評価で述べている。
また、実際にモデルが付けた値段の推移を可視化している。東京の例があり、4月の桜のシーズンにモデルは需要を読み取って値段をあげている(下図)
追記
書き終わって、ふと検索して気づいたのですが、すでにわかりやすい日本語で解説記事が上がってました…orz。やはりAirbnbの論文は注目度が高いですね。しかし、自分の理解が深まったので良しとしよう。
useR2018に参加&ポスター発表をしました
表題のとおり、useR2018@ブリスベンに参加&ポスター発表してきました。useR初参加です。
Rで分析を行っている自分たちのユースケースを発表しながら、世界のRユーザ・Rコミュニティの動向を肌で体感したいと思い参加しました。
概要
2018/7/10-13の4日間開催で、1日目と2日目の午前中まで、半日チュートリアル×3。その後、オープニングとキーノートがあったり、トークやLTが6パラレルで続く感じでした。ポスターは2日目の夜のレセプションと3日目のランチ時間に開かれていました。
会場はブリスベンの都市部のBrisbane convention & exhibition centerというところです。4Fのフロアをすべて貸し切ってるようでした。
キーノートをする会場はホール形式。
参加者のバッチはRらしくヘキサゴン形でテンションが上がります。参加者の所属もざっと見ていると、オーストラリア系の大学や企業がやや多めで、他の国の大学系などアカデミアが多くて、インダストリも一部来ているかなーという印象でした。オーストラリアという場所に依存した参加傾向になったかもしれません(謎)
オーストラリアの形でパッケージのヘキサロゴを貼ってたりもしました。
1日目
初日は午前と午後のチュートリアルが2本ありました。
Production-ready R: Getting started with R and docker
スライドはこちら:GitHub - SymbolixAU/useR_docker_tutorial: useR!2018 docker tutorial slides and notes drafts
Dockerを使ってRStudio等をデプロイする話に参加しました。Dockerも普段から使用するので、基本的なことは既知だったのですが、rockerのImageの依存関係は知らなかったので、どのImageをベースにDockerfileを作成するかは参考になりました。また、デプロイするときにどうしても、パスワードやAPIキーの管理をどうするかという話になるのですが、.Renviron
で管理すればいいという話は試したことがなかった(たぶん基礎なのに…笑)ので、今後やってみたいと思いました。
fasteR: ways to speed up R code
スライドはこちら:GitHub - tslumley/useRfasteR: for a tutorial at useR2018
Rの高速化についてのチュートリアルに参加しました。チュートリアルというよりはプレゼンターの高速化のTipsまとめだった印象です。data.frameが遅いとか、vectorizeをしましょうといくつか知ってることもありましたが、if elseが遅いとかは知らなかったので、いくつかまたコードを見直すきっかけになりそうです。
また、コードを入念にRprof
やmicrobenchmark
を使ってデバッグしていくことはやはり必要なんだなと感じました。改めて、Rの高速化は基本的なテクニックを抑えながら、Profileして地道な作業と思いました。といいつつ、いまのところそこまでシビアに高速化する必要もなかったりで、、、
それとこのセッションを見て思ったのは、高速化をすると、コードの可読性も落ちてしまうケースもある気がするので、Rに習熟していない人と共有する場合に読みづらいコードになるのは避けたいなーという気持ちもあるので、バランスや高速化Tipsの方向性は揃えないといけないと感じました。
2日目
午前中は、useR2018の3つ目のチュートリアルに参加
Interactive data visualization on the web with R
スライドはこちら:Interactive dataviz on the web with R & plotly
最近plotlyをshinyで使っているのですが、知らない機能が知れてすごく有意義でした。とくにhighlight_key
で大量時系列の一部をハイライトする機能や生データとAggregationしたデータをひもづけた可視化など。複数系列から比較して見るのも容易になるので、最初からfilterしなくても対応できる場合がありそうで、これから試してみようと思いました。
午後からはOpening、Keynote、Talkが始まりました。
Talkで面白かったものを紹介します。
Automated unit test generation using genthat
GitHub - PRL-PRG/genthat: An R package for extracting unit tests from existing code
testスクリプトを自動生成するパッケージを開発している話でした。たしかにcoverage率あげるためにtesthatのスクリプトをがんばって書くこともあると思いますが、自動化できるならだれもがやりたいと思います。 論文としても発表しているみたいで、いろんなRのパッケージで実験して評価していました。興味深かったです。
Poster Session
Posterはロビーで47inchモニターを使った電子型ポスター発表です。
自分たちはスライドを横長に作って、サイズをあわせて作ってきました。
18.07.11_useR2018 Poster_Time Series Digger : Automatic time series a…
時系列データを分析する際のデータサイエンスプロセスと、EDAと特徴抽出とそれらに基づいて異常検知をパッケージ化して社内で使っている話をしました。 パッケージ公開の予定や具体的な手法や手法の使い分けなど議論できました。
他の参加者はShinyを使ったデモ形式で発表している人も多かったので、次回以降はそっちのほうが参加者と議論しやすくてわかりやすいかもと感じました。
3日目
この日のKeynoteでは、The Grammar of Animation(Thomas Lin Pedersen)に参加。主に、インタラクティブグラフやアニメーションの使い所についての話。
スライドはこちら:Keynote
gganimate 数年前に使ったときより、使いやすくなってそうだなと思いました。時間をアニメーションで動かして、散布図が動くやつ一度実データで描いてみたいです。
Talkでは、面白かったものを紹介します。
Statistical Inference: A Tidy Approach using R(Chester Ismay)
スライドはこちら:Statistical Inference: A Tidy Approach
tidyライクな統計的仮説検定を行えるinferの紹介。聞いててテンションがあがりました。まさか統計的仮説検定の各々もtidyベースで実行できるようになるとは…。これはこれから必須のパッケージになる予感です。
prioritizr: Systematic conservation prioritization in R(Jeffrey O. Hanson)
GitHub - prioritizr/prioritizr: Systematic conservation prioritization in R
整数計画問題を解くパッケージ。これまた簡単なインタフェースで直感的に制約条件などを設定できそうで便利なパッケージだなーと思いました。研究を進める上で開発したのかなと思いました。
Glue strings to data in R(James Hester)
使いたいなーと思って使っていなかったglueパッケージ。pasteなどでがんばってprintしていたものを、変数なども分析するときに簡単にprintできたり、formatを揃えることができたりと、便利そうなパッケージ。使ってみて恩恵を感じたいと思います。
Data Preprocessing using Recipes(Max Kuhn)
GitHub - tidymodels/recipes: A preprocessing engine to generate design matrices
チュートリアルのスライドはこちら:user2018/Recipes_for_Data_Processing.pdf at master · topepo/user2018 · GitHub
caret開発者が現在開発している、データの特徴設計をtidyライクに書くことができるパッケージ。すごく簡単に特徴づくりできそうです。caretとの連携部分も開発中とのこと
Moving from Prototype to Production in R: A Look Inside the Machine Learning Infrastructure at Netflix
スライドはこちら:From Prototype to Production
Netflixで利用しているmetaflowの紹介。Rからデータを前処理してモデルを作って、デプロイしていくのを簡単にするパッケージの様子。ただ、まだ未公開なので、今後公開されることを祈る。この手のRでアドホックに分析したものをプロダクションに持っていくのをサポートするとこまでやっちゃうところはさすがNetflixだなーと思いました。ただ、やっぱりRでやる必要もないような…。
Estimating individual Customer Lifetime Values with R: The CLVTools Package(Bachmann Patrick)
解約予測の新たなパッケージ。分布の条件から、問題設定を4つに分けて、各種条件に応じてモデルを選択して予測できる。細かいアルゴリズムはわからなかったけど、パッケージももうすぐ公開予定みたい。
Large Scale Data Visualisation with Deck.gl and Shiny(Ian Hansel)
Uberで使ってる地理データのWebGL可視化ライブラリ。Rからのインタフェースもあるみたいでデモを見てたらきれいな絵がかけていた。大規模データでも耐えれるようにというモチベーションみたいだが、どれくらいのポイントでも動くか試してみたい。
Poster Sessin
この日はランチ時間帯にポスターセッションがありました。
日本から来ていたhoxo_mさんのmagic_forのユースケースが直接聞いて理解できたのと、自分たちが書いたコードでも思い当たる節があるので、これから使っていきたいと思います。コードがきれいになる予感がします。
GitHub - hoxo-m/magicfor: Magic Functions to Obtain Results from for Loops in R
4日目
Keynote : Teaching R to New Users: From tapply to Tidyverse (Roger Peng)
S言語からの話やRの歴史的発展、tidyverseの紹介なども最後まで飽きずに聞けました。
面白かったTalkをメモしておきます
Shinotate: an R-based shiny server for annotation and analysis of RNA-Seq transcriptome assemblies
Shinyでアノテーションツールを開発してる話です。期待してるものではなかったのですが、デザインの話やインタフェース設計は参考になりました。
DALEX will help you to understand this complex predictive model(Przemyslaw Biecek)
GitHub - pbiecek/DALEX: Descriptive mAchine Learning EXplanations
機械学習のモデルの解釈のためのパッケージです。breakDownやLIMEを包含したパッケージのようです。
fasster: Forecasting multiple seasonality with state switching(Mitchell O'Hara-Wild)
スライドはこちら:fasster::useR2018
時系列データのモデリングのためのパッケージで、季節成分を複数考慮したり等、拡張の幅が広そうなインタフェースで提供していました。最後にRMSE等でProphetよりも精度が高い結果も示していたので、要チェックなパッケージになりそうです。
seer: R package for feature-based forecast-model selection(Thiyanga Talagala)
GitHub - thiyangt/seer: Feature-based Forecast Model Selection (FFORMS)
時系列データの分類のための時系列データの特徴抽出をかなり作り込んでる印象でした。特徴抽出の手法の実装は参考になりそうです。
その他気になったパッケージ
Talk等はセッションがかぶっているため聞けなかったですが、気になったもの
半教師あり学習のパッケージ。Self-Training以外は実装名からは検討がつきませんが、まとめている感じでしょうか。
GitHub - mabelc/SSC: The ssc R package
4日目のTalksであった時系列系のデータのtidy化をtidyvertsといったプロジェクトで行っているみたです。全然知らなかった。。
forecast系のパッケージもfableでtidy化してるみたいです。便利すぎる。。
GitHub - tidyverts/fable: Forecasting with tidy objects
パッケージは関係ないですが、発表者のスライドをRmdやgganimateで気合入れて作ってる人が多くて、さすがのRのカンファレンスという印象でした。
発表までの流れ
次回以降useRで発表したい人のために、今回の発表までの流れを共有しておきます。
- 2018/3/15 : アブストラクトを締切日に提出(1200文字)。単語数じゃないので注意。はやく提出した人からアクセプトされていくので、はやめに出したほうが良いみたいです。といっても、出そうかと話したのが3/14だったので、これ以上自分たちも早くはできなかった…。
- 2018/3/23 : アクセプト通知がくる。最終日に提出してもいけたので問題なかったみたいです(むしろRejectはあったのか?)
- 2018/6/16(くらい):ポスターの仕様が公開。47inchモニターに写して発表と知る。横長で作りなおした。
- 2018/6/22(くらい):ポスター発表スケジュールが公開
- 2018/7/11 : 発表
ブリスベンについて
ブリスベンへは、東京からカンタス航空で直通便がでており、8時間15分程度のフライトでした。オーストラリアの入国検査は無人で行えるスマートゲートですぐに入国できたのは感動的でした。いろんな国に導入してほしいな…。
到着後は、タクシーで約30分で会場近くのホテルに到着しました。景色や部屋も広くてとても快適でした。
オーストラリア自体が初めて訪れました。この時期は冬ということで、朝と夜は冷えますが、それでも10度程度ので、ユニクロのウルトラライトダウンで十分耐えれる感じです。昼でも日陰は冷たいですが、日なたは暑いくらいでカラッとした陽気はオーストラリアらしい天気でした。
記念にカンガルステーキも食べることができました。
ブリスベンはオーストラリア第3の都市と言われていますが、都市部はそれほど大きくなく、歩いて十分回ったりすることができました。シドニーやメルボルンもいずれ行きたいと思いました。
さいごに
useRの発表はほぼすべて?ビデオで公開されているみたいですので気になったものは視聴することもできます。
しかし、現地で生で聞いたほうが吸収率もあがる感じがするのは集中力の問題でしょうか…。 また、来年のuseR2019はフランスのトゥールーズで開催されるようです。別のネタでまた発表したいなと思いました。
社会人博士課程を修了しました
2018年3月に博士(工学)の学位を頂きました。2013年3月に修士(工学)を卒業し、2015年4月に再び同大学で社会人博士課程で入学し、ちょうど3年で卒業しました。
私の研究は、簡単にいうとデータ分析の結果をさまざまな条件下で活用するための研究になります。社会人博士課程は大変と聞いていましたが、実際3年経って振り返ると自分の想像以上に大変でした。しかしながら、3年間取り組んで良かったと思います。実際に、博士の学位を取って後悔した人はほとんどいないと聞いていたとおり、私自身もそう感じています。なぜそう感じるかは、いろいろな面でのスキルアップやコミュニティ形成などがあったからなのでしょうが、私自身は博士論文を完成させるまでの過程で訓練される「本質とはなにかを考える力」が自分にとっては1番大きいものだと感じています。
この記事では、入学から卒業までの3年間の流れを振り返ります。これから社会人博士課程を目指す人になんらかの参考になればと思います。
入学の理由
- 単純に博士という学位自体に興味があった。そして取り組みたい問題もあった
- 学部時代に社会人博士課程に通っている先輩がいて、社会人をしながら研究・勉強を続けている姿に憧れを抱いた
- 私も修士で就職すること(ソフトウェアエンジニア or データ分析者として)は決めていました。当時、社会で役立つものは何かを自分なりに考えてから、それを踏まえてもう一度研究をしたいと考えていたため
環境
入社してからデータ分析に関する研究開発部署に配属。今でも大きく環境は変化していません。 社会人2年目の後期に、当時の研究室の教授にアポイントをとり、直接相談して、社会人博士課程で入学することを快諾してくれました。
その後、会社では上司に相談。上司も快く快諾してくれた。私の所属が研究開発部署であったことがとても大きかったと思う。また、周りに社会人博士課程を卒業した先輩社員もいた。
入試
研究テーマに関して、入学する専攻の教授陣(10名〜20名)に対してプレゼンテーションを行いました。とくに3年間のストーリーを話すことができるかが議論の対象だと思います。
今思うと、このとき話した内容から大きくずれた研究もしているなと感じます…。
授業
自分の場合は修士と同じ大学であったため、取得する必要のある授業はなく、必修科目の研究指導関連のみ。これは社会人である自分にとってとても助かりました。
時間
平日は帰宅後、数時間。電車での移動中に論文読んだり、考えたり。残業もあまり無い環境であったので、環境にも恵まれたと思います。
あとは土日。ずっとっていうことは無く、妻と予定を立てて、ご飯を食べに行ったり、たまに日帰りで遊びにいったり、気分転換も割とやっていました。自分の場合は、研究はどこでもできる(脳内)と思っていたので、移動中に論文読んだり瞑想したりで少しでも研究脳を忘れないように意識はしました。また、幸いにも妻もいろいろと気を遣ってくれたことに本当に感謝。博士論文執筆中に、ちょうど子供も産まれましたが、多くのサポートをしてくれました。
費用
学費
国立大学の一般的な学費(入学金+授業料)がかかりました。
交通費
月1度、片道1万程度の新幹線がかかっていました。私の場合は、2年生前期〜3年前期からは仕事の都合で関西勤務となり、交通費を抑えることができたのは助かった。また、色んな経緯で貯めることができていたマイレージを使用して国内線特典予約をかなり利用できたので、金銭的に助かりました。
PC
大学からの支給品や自宅のMacbookで十分だった。
計算環境
これもリモートからログインして計算に利用できる十分なサーバが環境としてあったので問題なかった。これもかなり大きいのではと思います。
タスク管理
Trelloで管理した。とくにラベル付けなどをちゃんとして、見た目を充実させて自分のモチベーションを維持した。仕事ととの頭の切り替えが難しいときもあったので、すぐに研究で考えていたことを思い出せるように、Trello上にTO DOをダンプするようにした。
論文整理
Evernoteでまとめた。ダウンロードしたPDFファイルは、論文整理用のソフトは使わずに、Dropboxで[YEAR]_[AUTHOR]_[TITLE]でカテゴリごとにディレクトリを作って保存していた。しかし、最終的に効率の良さを考えて、Papers3 を導入した。学生なら49ドルで購入できるので、とても便利です。
英文校正
博士論文の質をあげるために、英文校正を行いました。基本的な英文法チェック等の一般的なものを使用した。 価格は最初の提示額から希望値段を言うと、半額以下に値下げることができたので、主張することは重要。
博論製本
私の大学では、PDFファイルを提出すれば、製本は不要でした。 そのため、落ち着いた3月に関係者に配るため、記念に製本しました。 研究室の製本機が不調だったので、インターネットで検索して専門業者に依頼しました。
博士過程の流れ
1年目(2015年)
- 修士時代に行っていた研究を後輩が追加実験を行ってくれていて、それらを加えて、改修したものをジャーナル論文(1本目)として投稿した
- もともと興味のあった分野の最近の動向や研究を調べて、予備実験を行っていた
- 後半くらいから主張すべき点をまとめて、国内の全国大会向けに投稿した
2年目(2016年)
- 春に全国大会発表、夏にも国内の学会で発表。学生賞を頂いた
- 春に発表した内容をブラッシュアップして、国際学会で発表
- 9月ごろに1本目の論文がアクセプト
- 発表した国際学会の特集号を狙いに、12月頃にさらにブラッシュアップしたものを論文投稿(2本目)
- ほぼ、同時に12月ごろに別の研究のアイデアがでてきて、実験したらうまくいったので、2月にそのまま国際学会に投稿
3年目(2017年)
- 昨年発表したものがヤングリサーチャー賞を受賞。表彰される(とてもラッキーでした)
- 特集号の2本目の論文がアクセプト
- 国際学会発表
- 国際学会発表後に、ブラッシュアップしたものを国内の学会誌に論文投稿(3本目)
- 投稿後、それの拡張の実験をしていると同時に、博士論文執筆時期
- 2月に国内の学会誌もアクセプト通知
博士論文のスケジュール
2017年春ごろ
- 学位を取得した先輩から、論文のフォーマット(Tex)を頂く。ざっくり修了までの流れを雑談で聞く
2017年夏ごろ
2017年10月
- とりあえず投稿したものをまず流しこんで体裁をざっくり整える
2017年11月
- 上旬:発表論文リストや謝辞もつくり、一旦完成させる。。この時期に、会社で行っていた研究のアクセプト通知。2月上旬にアメリカでの発表が確定したので、審査と重複しないか早めに確認
- 中旬:主査の先生(担当教員)に提出
- 下旬:副査の先生方にも提出。提出の際に、数十分程度軽く内容を説明する
2017年12月
- 上旬〜:担当教員から添削と修正点がはいる。かなり真っ赤になったことに反省。。
- 上旬〜:添削頂いたところを修正
- 中旬:公聴会で発表。副査の先生を中心にコメントをもらう
- 下旬:学位申請書等の事務手続き資料を揃える。当時の後輩が論文の著者で連名になっているものがあったので、サインをもらったりが必要
2018年1月
- 冬休みを利用して、論文を修正。 年越しの瞬間も論文修正してた。
- 上旬:外部の英文校正会社に論文チェックをしてもらってさらに修正
- 中旬:論文を印刷して、簡易製本を行い、学位申請書と共に事務に提出。これで一息つけた
2018年2月
- 上旬:企業で行った研究について国際学会で発表@アメリカ
- 中旬:最終諮問を実施。そのまま最終版を印刷して提出。終了
2018年3月
- 上旬;最終審査を通過した連絡を頂く
- 下旬:卒業式。学位記を受領
よかったこと
- 博士論文を仕上げることで、技術はもちろんなのですが、問題に対して、議論の質をあげる力、執筆力、プレゼンテーション力など総合力が鍛えられたのかなと思います。目に見えるものではないですが、ときどき実感することはあります
- 名刺に博士(工学)と書けること(わかりやすく嬉しい気がします)
- なんとなく会社でも広まって、応援してくれたり、そういう目で見られてなんとなく評価ももらえたこと(直接的なものではないが、人間的によかった)
- まだまだ企業人で博士の学位を取得している人は周りに多くいないので、自分自身のプレゼンス向上につながる(はず)
苦労したこと
- 博士論文自体の執筆は、単なる投稿した論文の焼き直しではないことを実感。ストーリーから構成まで新たに執筆する部分が増えて大変でした。。研究の振り返りにもなると思うので、ストーリーはどこかのタイミングで定期的に考えないとなと思いました。
- 執筆における英語の表現力が不足していることを痛感しながら、英語は最後まで苦労しました。。
- 仕事の繁忙期と学会誌の締切が重なると普通に辛いですね。。
犠牲になったこと
少なくとも約3年間の平日と休日の余暇が犠牲になります。 例えば、友人と遊ぶ時間・飲み会の参加・他の勉強したいことができたときに優先度をうまくつけれるか等、多くの葛藤が生まれます。
私の場合は、例えば別の興味のある技術を勉強したい、会社でやっていた仕事で必要な技術を深めたい、などありました。今思えば、それらを並行になり遂げることもできたかもしれませんが、頭の中のパーセンテージを切り替えていくのも大変でした。このように、時折の自分自身のモチベーションが、優先度をつけてメリハリをつけて研究するための時間を捻出する精神力が必要になります。
そんな時もありましたが、妻がそばにいてくれたおかげで、良い息抜きもできました。逆にシングルは精神的に辛いことも増えるのかもしれません。
今後
一時期は、大学に戻ろうかなと考えていた時期もありましたが、周辺の大学の先生方の話を聞き、自分はデータがある企業でリサーチャー or データサイエンティストをしながら、現実の問題に向き合いながら、データを解析することに集中することにしました。仕事がら、大学とは何らかの関わりは今後とも継続するかと思いますが。
最後に私の恩師からありがたい言葉をいただきましたので、そのまま引用して終わりたいと思います。
10年後、20年後のことは、誰にも予測はできない時代になってしまいましたが、働きながら寸暇を惜しんで研究した経験は、きっと未来を照らす光になることは、私の経験上からも明らかです。
参考:博士課程に関するブログ
過去のブログ記事が出る度に読んで参考にしていました。こういう数少ない記事から、自分もがんばろうと思えていました。偉大なる先輩方に感謝です。