GINGI99 Blog

データ分析や日常に関するブログ

2018年導入してよかったこと・振り返り

今年も終わります。昨年のまとめに続きに今年も振り返ってみます。

gingi99.hatenablog.com

昨年の導入してよかったもの+習慣とかの振り返りを追加した感じです。

習慣

ワーク管理を更新

ツールを増やして、以下で運用中。

  • 一次受け
    • Google Keep:すべてのメモ
    • Pocket : Web系の気になる記事等の一時保存
  • To Do管理
    • Trello : To Do管理。カンバンっぽく使っている
  • 共有
    • HackMD:Markdownで他人に共有したいときに使っている
  • まとめ先
    • はてぶ : まとめれそうなものは記事化
    • ASANA:英語に関するメモやまとめ
    • Github と Gitlab : プロジェクトを作って、IssueやWikiにまとめる
    • Evernote:メモを含むすべてのまとめとして使ってたが、重くなってきたのと、整理できなくなってきたので、上記に一部移行中

他にも、KanbanFlowやScrapboxも使い始めてるが、ツールが多すぎると逆に面倒になりがちなので、使い方を考えている。

論文をiPad + Papersで読むようになった

iPadを調達して、論文を読むために、学生特権でPapers3を購入した。論文・PDF管理はそれに一任できて、問題は起こってないので、来年もこのままいく。

投資信託

博士課程を終えて、時間ができたのもあり、記事をみたり本を読んだりして勉強して、いろいろと申し込んだ。この辺の知識は知っているか知らないかで人生の後から損する系なのでコツコツ情報収集しないとなと思った。  

アウトプットの習慣

  • はてぶ : 12件
  • Qiita : 5件

であった。あまり数が多いほうが良いとかも思わないが、毎年+1以上で増やしていきたいと思っている。 書きかけの記事もあったりするが、質もあげていきたいので、コツコツ書く習慣を継続する。

転職活動した

転職エントリはまた別日に書くとして、転職活動は自分の悶々と考えていたキャリアプランをクリアにし、外を知ることで自分の立ち位置や今後どういうポジションの人になるのか考えるを良い機会であった。同じ業界のさまざまな人と話せるのはそれだけで楽しかったりしますしね。

朝型生活

会社にいくときは、7時30分に出社して、16時30分に帰るのをベースにした。 家に帰って、家族でご飯を食べて、子供をお風呂にいれて、子供が寝たあとは、夜は2時間以上時間ができるので、集中して1タスク以上取り組むみたいな感じ。

今年の後半は、有給消化の関係で、適当な生活時間になったが、来年もほぼこのベースを続けたい。

LINE Pay

お財布いらずで買い物できるし、貯まるポイントでお買い物できるのは良い。使える場所もめちゃくちゃ増えてるし。

動画で学習

Amazon Primeもそうだが、Youtube Premiumのおかげで広告なしでオフライン動画を見れる。 英語もGoogleのおかげで字幕付きで見れるし、これからはYoutubeでキャッチアップすること増えるだろうなーと思っている。

モノ

Huawei p20-lite

consumer.huawei.com

スマホを2年ぶりに買い替えた。以前のスマホよりカメラの性能が大きく上がって満足。キャリアもキャンペーンに乗っかりUQに変更した。

Baby Smile 電動鼻水吸引器 メルシーポット

Baby Smile 電動鼻水吸引器 メルシーポット S-503

Baby Smile 電動鼻水吸引器 メルシーポット S-503

子供鼻水吸いのための導入。先輩型のおすすめどおり買ってよかった。

大和屋 すくすくチェアプラス テーブル付

テーブルの高さと同じくらいで、子供を固定できて、成長してもイスや足置き場の高さを調整できる。

シャープ 過熱水蒸気オーブンレンジ 2段調理

一人暮らし用のレンジから買い替え。毎日使う妻が嬉しそうだった。パンも焼けたりで、生活の質が上がる良いお買い物でだった。

バンキンス 油が落ちるスリーブビブ

子供用に毎日使っている。夏は暑いかもだが、それ以外の季節なら汚れを服につけなくてとても良い。

象印 炊飯器 5.5合 IH式 極め炊き

一人暮らし用の炊飯器から買い替え。値段も安いのに一気に美味しくなるからもっと早めに買ってよかった。

メディアやアプリ

ゲームオブスローンズ

Amazon Primeでたまにコツコツみてる。まだシーズン5見終わったところ。ハマる理由として、キャラの濃さと毎回最後のシーンが「えっ?」って感じなところ。

Kindle Unlimited (無料体験のみ)

マンション関連の知識をつけたくて、1ヶ月だけ使った。読める本はそこそこ面白いのもあったが、継続して使うにはもう少し新書だったりを充実してほしいと思った。古い本は、情報が古かったりするので、あまり読む気になれなかったり。

Grammarly

www.grammarly.com

カンタンに英文の文法チェックをしてくれる。精度もそこそこ良いので、英文書いたら必ず通すようにしている。Macのデスクトップ版を使っている。

2019年の導入予定

マンション

購入するかどうかはわからないが、子供が大きくなる前に決めていきたいと思っている。今はいろいろ調べ中。

Amazon Echo でのスマートな生活

購入したものの、継続して使いこなすほど使ってないので、また改めて考えてみる。TVの電源を消すアプリ作るところからかな。

子供用のおもちゃ

最近はおもちゃで面白いの増えてる(自分はほとんど買ってないのだが)ので、自分がむしろ興味がある。 というのも、ボードゲームと同じようにおもちゃによる知育にゆるく興味があるので、なんか良さげなおもちゃをビックカメラで探してる。

Slackを通じて正解ラベルデータを集める

分析の精度を高めるために、正解ラベルを集めるコストはなんだかんだ大きいです。

よくある話ですと、がんばってラベル付けしたデータから学習したモデルをデプロイし、日々送られてくるデータのラベルを推論します。そして、予測スコアがある閾値を超えたら、Slackに通知する(「スコア ~~ で、異常が検知されました」など)サービスを考えます。 そのSlackの通知をラベル付けを担当する人が見て、「うーん、これは誤判定だな。」とか「おお、これは異常だ!すぐにエスカレしなければ!!」と判断します。

このとき、その判断した結果をすぐにデータ化(ラベリング)する仕組みがあると、最新データで継続的にモデルの学習を行うことができ、性能をアップデートするのに非常に役立ちます。

そこで、SlackにInteractive Button付きのメッセージを投げて、ラベル付けを担当する人がボタンをクリックすることで、データ化する仕組みをPythonで作りました。

github.com

通知のイメージは以下のとおりです。

f:id:gingi99:20181202225504p:plain

実装は、コードのとおりですが簡単に言うと、

  • APIサーバをFlaskで立てる
  • 通知がほしいときに、/postを叩き指定のチャネルにInteractive Button付きのメッセージを通知させる
  • ボタンのクリック結果を、通知したメッセージのリプライで返す。その中で、データ化する処理も別途書けばOK
    • このデータ化する処理Githubの方には書いていませんが、例えば、推論に使用したデータを保存しているデータベースのテーブルにインサートしていくとかです。

Slackアプリ、まともに作ったのは初でしたが、形にできるまで楽しかったです。Slackを通じてボタンクリックだけからチャートを作る仕組みも考え中…

参考

任意の相関係数をもつデータを可視化するShinyアプリを作った

(ピアソンの積率)相関係数が0.XXのときって散布図どんなんだっけ…?とかを直感的に確かめる / 相関係数を学ぶ人向けのツールが欲しかったので、Shinyで作りました。

以下のShinyappsで公開中

Correlation Viewer

コードはこちら

github.com

任意の相関係数を持つ疑似データの作り方は、以下のSlideを参考にしました。

Rで架空データの発生

今後機能を増やすかは未定です。なにか思いつくか、なにか要望を頂いたら考えます。

「人工知能システムのプロジェクトがわかる本」を読んだ

この本を読んだ目的

  • ML Engineerとして機械学習システムを構築する際に、必要な要件をもれなく把握しておくのに適していそうな本を見つけたため
  • 著者はNECで30以上システム導入経験があり、ノウハウが溜まった知識をすぐに知れそうだと思ったため

書評

タイトルのとおり、人工知能を積んだシステムを提供するときに考えておくべき項目がまとめられていた。 全体的に理解できている内容も多かったので、再確認することが多かったため、さくっと読めました。また、システムの運用の話まで入ってる本は珍しいので、とても参考になりました。

備忘メモ+感想

1章 実用化されつつある人工知能

分析の基本的な話

2章 通常のシステムと人工知能システムの開発プロセスの違い

1.企画フェーズのあとにトライアルフェーズがあること

2.開発フェーズの内の要件定義時や納品前にデータ分析を行うこと

3.運用フェーズにおいて人工知能システム特有の運用・保守(人工知能のモニタリングやメンテナンス)を行うこと

特に3がよくある負債の話。

3章 人工知能システムの企画

人工知能システムの運用・保守の代表的な作業

再学習

予測結果や精度の確認

新対象の追加

人工知能の挙動に対する問い合わせ応答

特に、よく聞かれる問い合わせとかは先にまとめておいたほうが良いと感じますね。本の例にもあった、人間の直感と反する場合の結果がでたときや、急に精度が悪くなった時の理由説明をスピードよく提供するとかですね。

4章 人工知能プロジェクトのトライアル

時間集計粒度 = 時間分解能

という言い方は知らなかった

回帰問題での評価指標

平均誤差

平均誤差率

最大誤差値

一定値以上の誤差値の割合

上振れ誤差率

下振れ誤差率

研究とかだと、RMSEが一般的だったりするが、データマイニングのように問題にあった評価指標を選定する感じがあって良いですね

5章 人工知能システムの開発

データ量の決定(例:どれくらい過去のデータを使うか)

モデルの更新方法の決定(例:バッチかオンラインか)

学習データが少ないときの対応(例:抽象度が高いデータを使う)

異常値処理方法の決定

よくある話でした

6章 人工知能システムの運用・保守

精度の日々の確認

人の知見・直感に合わない結果に対する原因

 学習データに要因となる特徴が入ってない

 運用時のデータの傾向が大きく変わっている

 過学習してる

 レアケースすぎて学習できてない

 結果がワンパターンすぎる

レアケースすぎて学習できてないとか結構あるんだよな…

「データ分析・AIのビジネス導入: プロジェクト進行から組織づくりまで」を読んだ

失敗しない データ分析・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的な知識は必要だなと日々感じる。

最近読んだKDDAirbnbの論文も人の判断をうまくパラメータにいれて最適化してるのを見ても、人の判断を入れるところまで意識してモデルを作り込んでみたい

ビジネス適用上の問題点

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)をしたい。市場動向を考慮しながら日々動的に適正な価格付けをする方法を提案する。

動的な価格付けをするための困難なところが、需要の見積もり変化(時間変化とリスティング変化)と部分的な価格適用(ホストの値段設定の考えもいれるところ)。

リスティングってのは部屋という意味でいいのかな。リスティング変化とは、ホテルは部屋が同じ作りであるものが多いが、一般に家の部屋の作りはすべて異なるため、部屋の評価レビューを考慮しながら部屋ごとに値段設定する難しさがある。高すぎると予約されなくなることも考えながら。

価格Pと時刻tとリスティングidにより、需要曲線F(P,t,id)が決まる。

適切な価格付けを行うPricing Modelsは3段階の構成にわかれている。

1つ目に、今から部屋が予約される夜までの間に部屋が予約される確率を分類モデルを構築する。

2つ目に、予約確率を特徴に入れ、値段付けモデルを構築する。

3つ目に、値段付けモデルは、ホストの値段設定の考えを適用して、最適化する。

これらの結果、研究としては、価格付けの効果を評価するメトリクスと悪い価格提案が起こらないようなモデルを導入できたことが貢献。

Pricing System Overview

f:id:gingi99:20180825110725p:plain

Booking Probability Modelはある部屋の未来のある日が予約されるかどうかを予測する。一般的な2値分類モデル。学習に使う特徴として、部屋に関わる特徴・時系列特徴・需要と供給の特徴(近隣の予約できる部屋の数など)を使う。

Gradient Boosting Model(GBM)を使う。学習は、市場の大きさで3段階に分けるなど、エリアごとに学習モデルを作ったほうがGlobal AUCの精度があがったみたい。ここで、場所ごとにサンプリングレートを変えるなどのテクニックもある。

推定されたモデルの予約確率(y軸)と値段(x軸)を見てみると、真のデータよりも、端にいくほど外れている事がわかる。

f:id:gingi99:20180825111837p:plain

この問題の難しいところとして、データのスパースネス(基準となる値段から離れたところをあてるのは難しい=price extrapolation)、ユニークネス(部屋は一つ一つがユニークなものが多く、一般化するのは難しい)、値段に依存した特徴(値段が高すぎると、利用率の特徴量が小さくなるなどがあり、値段との相関が悪さをする)などが考えられる。

そこで、収益最大化のアプローチもやったと書いてるが、最適な値段というデータがない(データにあるのが最適な値段といえないので)ので、うまくいかなかった。最終的に、最適な値段付けのための正しい評価メトリクスを作ったほうがいいねとなった(そう考えるのか!)

Evaluation Price Suggestion

一般的な回帰の教師あり学習と違って、最適な値段というデータがないので、私達の値段付けの性質を使った評価メトリクスを導入する。

イデアとしては、正しい値段を考えるのではなくて、何が悪い値段づけなのかという方向から考える。

実際の部屋の値段をP、提示する部屋の値段をP_{sug}、最適な値段(存在すれば)をP_{o}とする。

悪い値段付けとは、「値段Pで予約された部屋をP_{sug} < Pで値段付けしてしまうこと」ゆえに、この場合はP_{o} \geq P。逆もしかりで、「値段Pで予約されなかった部屋をP_{sug} \geq Pで値段付けしてしまうこと」なので、この場合はP_{o} < P

また、提案した値段付けが良いか悪いか判断がつかないものとして、値段Pで予約された部屋をP_{sug} \geq Pで値段付けすること。値段をこれ以上上げても予約はされたかどうかが判断がつかない。もちろん、逆も同じ。

ということで、以下の表ができあがる。

上記の考えから、5つのメトリックを定義する。実際には、以下の2つの指標を特に重要だと述べている。

PDR=\frac{d}{d+b}BR=median_{bookings}(max(0,\frac{P - P_{sug}}{P}))である。

PDRは、予約されなかった部屋のうち、値段付けが実際の値段より低くできたもの。大きいほうが悪くはない。

BRは、予約された部屋のうち、値段付けが実際の値段より低くしてしまった部屋の場合、損失率を計算し、それ以外は0。それらの中央値を返す。小さいほうが悪くはない。

この2つはトレードオフの関係にあるので、PDRを改善しながら、なるべくBRを大きくしないような最適化を考える(なるほど)

Strategy Model

この章で、本質となるモデルがでてくる。まずは損失関数を定義する。

特徴(もともとの値段やGBMが算出した予約確率など)を含む対象x_iとそれの予約の有無を表すy_iからデータ\{x_i, y_i\}_{i=1}^{N}を用意する。

サンプルx_iに対して、モデルが付けた値段をf_{\theta}(x_i)とする。一旦パラメータ\thetaのことは置いておく。

損失関数は、Support Vector Regressionで使われるε-許容誤差の考えを参考に、以下の損失関数を定義する。

 \mathcal{L} = \arg \min_{\theta} \sum_{i=1}^{N} (L(P_i, y_i) - f_{\theta}(x_i))^{+} +  (f_{\theta}(x_i) - U(P_i, y_i))^{+}

ここで、 L(P_i, y_i) = y_i * P_i + (1 - y_i) * c_1 P_i U(P_i, y_i) = (1 - y_i) * P_i + y_i * c_2 P_i である。

これを理解するのは、以下の図を見るのが早い。

f:id:gingi99:20180825215948p:plain

つまり予約されたサンプル(y_i = 1)はもともとの値段P_iよりも少し大きいc_2 P_iくらいなら損失は0にする。

逆も同様の解釈でいける。この幅をもたせてるのが、ε-許容誤差と似てるが、LとU次第にかかるパラメータc次第で幅は大きく変化する。

続いて、最適化するパラメータを含むf_{\theta}(x_i)について。

モデルが付ける値段を定式化していくわけだが仮定として、「(1) 予約確率と相関はあるように付ける (2) もともとの値段の周りに付ける (3) なんらかの需要がでたときに容易に追加できるように」という3つのアイデアを入れて定式化する。

それが、f_{\theta}(x_i) = P_{sug} = P * V で、Vは以下。

Pはもともとホストがつけた値段、qGBMが付けた予約確率、Dが需要スコアといって、各マーケットごとに決めるダイナミックに変わる需要量。

\theta_1 は制御パラメータ、\theta_2は微調整パラメータと読める。

需要スコアDガウス分布で正規化する。高いほど、需要が大きい。それを制御するパラメータ1 < \phi_L < \phi_U < 2 で設定する。2つあるのが、UpとLowで別々の比率がほしいので、これが非対称(下図)

f:id:gingi99:20180826115337p:plain

あとは、\theta_1\theta_2の勾配を求めて、収束したら、P_{sug}が求まる。

学習時のテクニックとして、GBMを学習するときはマーケット別に学習したが、このStrategy Modelはすべてのデータを使う。これは、同じマーケットで同じ部屋でも、ホストがつける値段がバラバラすぎるので、全部のデータで学習したほうがホストの依存が少なくなることを期待しているみたい。

あと、\theta_1\theta_2の範囲に制約を入れるなどで、非現実的な値段にならないように調整する。学習には、Sparkを用いて確率的勾配降下法 (SGD)で最適化する。また制約をいれても、Proximal Algorithm(近接法)で容易に求まる(らしい)

Experiments

ある期間のデータを使ってオフライン評価を行う。

ds がStrategy Modelが値段付けした日、ds_eval が予約の有無のラベル集めた日、その間に1つ以上の予約があれば、その対象は正例となる。

3つのデータセットを使って、PDRBRを評価する。需要曲線に基づいて予想される収益を最大化する費用を提示するナイーブなモデルと比較する。

結果は、そのナイーブなモデルと比べて、良好な結果(下表)。

f:id:gingi99:20180826121704p:plain

評価指標に基づいて悪い提案を避けるモデルに設計した効果がでている。

すでにこのモデルを1年以上デプロイしているが、着実にこのメトリクスでみると、改善が行われているとオンライン評価で述べている。

また、実際にモデルが付けた値段の推移を可視化している。東京の例があり、4月の桜のシーズンにモデルは需要を読み取って値段をあげている(下図)

f:id:gingi99:20180826122202p:plain

追記

書き終わって、ふと検索して気づいたのですが、すでにわかりやすい日本語で解説記事が上がってました…orz。やはりAirbnbの論文は注目度が高いですね。しかし、自分の理解が深まったので良しとしよう。

honawork.hatenablog.com

repose.hatenadiary.jp

useR2018に参加&ポスター発表をしました

表題のとおり、useR2018@ブリスベンに参加&ポスター発表してきました。useR初参加です。

Rで分析を行っている自分たちのユースケースを発表しながら、世界のRユーザ・Rコミュニティの動向を肌で体感したいと思い参加しました。

概要

2018/7/10-13の4日間開催で、1日目と2日目の午前中まで、半日チュートリアル×3。その後、オープニングとキーノートがあったり、トークやLTが6パラレルで続く感じでした。ポスターは2日目の夜のレセプションと3日目のランチ時間に開かれていました。

会場はブリスベンの都市部のBrisbane convention & exhibition centerというところです。4Fのフロアをすべて貸し切ってるようでした。

キーノートをする会場はホール形式。

f:id:gingi99:20180711100117j:plain

参加者のバッチはRらしくヘキサゴン形でテンションが上がります。参加者の所属もざっと見ていると、オーストラリア系の大学や企業がやや多めで、他の国の大学系などアカデミアが多くて、インダストリも一部来ているかなーという印象でした。オーストラリアという場所に依存した参加傾向になったかもしれません(謎)

オーストラリアの形でパッケージのヘキサロゴを貼ってたりもしました。

f:id:gingi99:20180712074225j:plain

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が遅いとかは知らなかったので、いくつかまたコードを見直すきっかけになりそうです。

また、コードを入念にRprofmicrobenchmarkを使ってデバッグしていくことはやはり必要なんだなと感じました。改めて、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、KeynoteTalkが始まりました。

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モニターを使った電子型ポスター発表です。

f:id:gingi99:20180711115501j:plain

自分たちはスライドを横長に作って、サイズをあわせて作ってきました。

f:id:gingi99:20180720220606j:plain

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)

GitHub - tidyverse/glue: Glue strings to data in R. Small, fast, dependency free interpreted string literals.

使いたいなーと思って使っていなかった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)

deck.gl

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

GitHub - IdoBar/shiny-server: A shiny server to deliver apps to retrieve annotated transcriptome data stored in Trinotate db

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)

GitHub - tidyverts/fasster: Forecasting with Additive Switching of Seasonality, Trend and Exogenous Regressors

スライドはこちら: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といったプロジェクトで行っているみたです。全然知らなかった。。

The 15th time series standard

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度程度ので、ユニクロのウルトラライトダウンで十分耐えれる感じです。昼でも日陰は冷たいですが、日なたは暑いくらいでカラッとした陽気はオーストラリアらしい天気でした。

f:id:gingi99:20180712113932j:plainf:id:gingi99:20180712114023j:plain

記念にカンガルステーキも食べることができました。

f:id:gingi99:20180712170714j:plain

ブリスベンはオーストラリア第3の都市と言われていますが、都市部はそれほど大きくなく、歩いて十分回ったりすることができました。シドニーメルボルンもいずれ行きたいと思いました。

さいごに

useRの発表はほぼすべて?ビデオで公開されているみたいですので気になったものは視聴することもできます。

R Consortium - YouTube

しかし、現地で生で聞いたほうが吸収率もあがる感じがするのは集中力の問題でしょうか…。 また、来年のuseR2019はフランスのトゥールーズで開催されるようです。別のネタでまた発表したいなと思いました。

www.user2019.fr