2019-04-06

1st Shiny Contest に参加しました

Shiny Contest とは？

Shinyとは、さまざまなinput形式に基づき動的にグラフを作成し、Webアプリやダッシュボードとして簡単に公開できる人気の高いRライブラリです。

Rが好きな理由の一つに、Shinyのことを言うRユーザは多いのではないでしょうか（私の希望的観測）。

本題のShiny Contestとは、1月7日にRStudio社の公式ブログで発表された第1回目のShinyアプリのコンテストです。

blog.rstudio.com

参加資格としては、

RStudio Cloudでソースコードを公開すること
shinyapps.io にデプロイすること
コードやデータは自由に公開できること

を満たすアプリであればだれでも参加できます。

参加するために、RStudio CommunityにBlogを投稿する必要がありますが、アプリの紹介とデプロイしたアプリのURLを書いて投稿完了となります。

締め切りは3/8まででした。実は私がこのコンテスト知ったのは、2月末ごろにRStudio社のツイートがRetweetされていたのをたまたま見て知りました。

ABテスト用のサンプルサイズ計算アプリを投稿してみた

このコンテストを知る前から、自身の統計の勉強も兼ねて、ABテストのシミュレーションに使用するためのサンプルサイズ計算Shinyアプリを作っていました。

ちょうどコンテストのことを知ったときくらいに、アプリはできていたので、いろいろと機能を加えて投稿しようと考えました。

ABテスト用のサンプルサイズ計算アプリはすでに世の中にたくさんあります。しかし、このとき自分がなぜいまさらShinyアプリを作ろうと思ったのは、既存のアプリでは満足できなかったからです。例えば、

Type Ⅰ / Type Ⅱエラーのサマリーした表が欲しかった。有意水準と検出力を人に理解してもらうためでもあります。検出力が小さいとこの箇所のパーセントが小さくなりますと人に説明することを想定しています。
サンプルサイズ計算までの各パラメータをまとめてhtmlのテーブルに出力したかった。htmlテーブルだと、社内のConfluenceに秒でコピーペーストでき、各パラメータを動かしたときの必要なサンプルサイズの結果をすぐにお伝えすることができるからです。
有意水準と検出力を可視化したプロットが欲しかった。この効果量だと、A群とB群の分布がこうなるんですよと人に見せることをを想定しています。

上記のように、人に説明することを想定して、自分の理解も深めようと考えアプリを作成しました。

実装したGithubはこちらにあります。

github.com

また、RStudio Communityに投稿したポストはこちらです。

community.rstudio.com

実は自分が投稿する数日前に、下記のブログの作者もサンプルサイズ計算のためのShinyアプリを投稿していました。

www.searchdiscovery.com

このアプリのコードを読んで、アイデアをいくつかもらい、自身のShinyアプリにも追加で実装しました。この記事でも、結果を誤解されないように丁寧に項目を精査している旨が書かれており、非常に参考になりました。

結果発表

4/5にRStudioから結果が発表されました。

blog.rstudio.com

当初の予定では、3/22までに発表すると予定されていましたが、予想以上に投稿数があったたため、発表日を延長したみたいです。

上記の公式ブログにも各種統計情報が掲載されていますが、136個の投稿があり、4人のWinnerが選ばれました！

選ばれたアプリをぱっと眺めているだけでも、Shinyでどうやって動いてるんだ？と思うものがあり、見てるだけで非常に楽しいです。一度は目を通すと勉強になるかと思います。

気になったShiny App

69 Love Songs: A Lyrical Analysis

Best Design ということでWinnerに選ばれたアプリです。開くとわかりますが、フォントといい、可視化の色使いといい、クールな見た目のアプリです。

ぱっと見て複雑な処理はそこまで多くなさそうなので、どうやって実装しているかをあとでチェックしたいと思います。

committedtotape.shinyapps.io

Pet records

こちらもWinnerに選ばれたアプリです。自身のペットの医療やワクチンのトラッキングアプリのようです。アイデアがユニークなのと、見た目のビジュアルも美しく、見ていて楽しくなるアプリです。

jennadallen.shinyapps.io

R Package Explorer

開くとわかりますが、もはやShinyアプリの見た目ではありません笑。

HTML Templateを駆使しているとのことですが、RのcomponentをどのようにHTMLの中に入れてコードを書いているのか気になりますので、こちらも要チェックです。

nz-stefan.shinyapps.io

ubeRideR

自身のuberの走行データを用いて可視化しているアプリです。こちらもHTML Templateを使用しているとのことですが、Shinyアプリの一線を超えた見た目に驚きました。

vivekkatial.shinyapps.io

おわりに

Shiny Contestによって、世界中からさまざまなアイデアを持ったShiny Appアプリが集まってきました。提出する前にすでに投稿済みのアプリを眺めていましたが、非常にユニークなアプリが多く、見ているだけで楽しかったです。

投稿されたものについては、ほぼすべての実装がRStudio Cloud上でソースコードが公開され、すぐに実行することができるようになっています。これを機に、気になったShinyアプリを見つけ、ソースコードを追うなどして深くShinyを勉強できるかと思います。

また、一からShinyを学びたい人は、今は非常に日本語の資料も増えてきています。

特に、@Np_Ur_ さんの100本ノックやShiny Advent CalendarやShiny本からはじめると非常にスムーズに学べるかと思います。

www.randpy.tokyo

qiita.com

次回のShinyContestでもなにか出せるようにネタを作っておこうと思います。そして、日本からもどんどん提出していきましょう。

参考

私が実装するにあたり、既存のABテストに関わるShinyアプリをいくつか参考にしました。

RStudio conf 2019で発表していたABテストのモニタリングツールをShinyで作っている話です。 Building an A/B Testing Analytics System with R and Shiny
ABテスト用にサンプルサイズの計算結果をもとにシミュレーションしてくれるアプリです。 https://gallery.shinyapps.io/CampaignPlanner_v3/

2018-12-31

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

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

習慣
モノ
メディアやアプリ
2019年の導入予定

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 Product

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

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

大和屋すくすくチェアプラステーブル付ナチュラル 7か月~

発売日: 2017/10/13
メディア: Baby Product

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

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

シャープ過熱水蒸気オーブンレンジ 2段調理 31L レッド RE-SS10B-R

メディア: ホーム&キッチン

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

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

バンキンス油が落ちるスタイ【日本正規品】スーパービブ柔らかくて軽量洗濯機で洗えてすぐ乾くお食事用防水ビブ 6~24ヶ月 Dinos(グリーン) S-109

メディア: Baby Product

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

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

象印炊飯器 5.5合 IH式極め炊きブラウン NP-VQ10-TA

メディア: ホーム&キッチン

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

メディアやアプリ

ゲームオブスローンズ

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

Kindle Unlimited (無料体験のみ)

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

Grammarly

www.grammarly.com

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

2019年の導入予定

マンション

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

Amazon Echo でのスマートな生活

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

子供用のおもちゃ

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

2018-12-02

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

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

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

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

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

github.com

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

f:id:gingi99:20181202225504p:plain

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

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

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

参考

2018-11-12

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

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

以下のShinyappsで公開中

Correlation Viewer

コードはこちら

github.com

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

Rで架空データの発生

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

2018-10-30

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

人工知能システムのプロジェクトがわかる本企画・開発から運用・保守まで (AI & TECHNOLOGY)

作者: 本橋洋介
出版社/メーカー: 翔泳社
発売日: 2018/02/15
メディア: 単行本（ソフトカバー）
この商品を含むブログ (2件) を見る

この本を読んだ目的

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

書評

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

備忘メモ＋感想

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

分析の基本的な話

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

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

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

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

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

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

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

予測結果や精度の確認

新対象の追加

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

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

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

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

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

回帰問題での評価指標

平均誤差

平均誤差率

最大誤差値

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

上振れ誤差率

下振れ誤差率

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

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

データ量の決定（例：どれくらい過去のデータを使うか）

モデルの更新方法の決定（例：バッチかオンラインか）

学習データが少ないときの対応（例：抽象度が高いデータを使う）

異常値処理方法の決定

よくある話でした

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

精度の日々の確認

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

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

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

　過学習してる

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

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

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

2018-10-28

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

失敗しないデータ分析・AIのビジネス導入: プロジェクト進行から組織づくりまで

作者: 株式会社ブレインパッド,太田満久,井上佳,今津義充,中山英樹,上総虎智,山?裕市,薗頭隆太,草野隆史
出版社/メーカー: 森北出版
発売日: 2018/07/13
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

この本を読んだ目的

Twitterで良いと見て
AIのビジネス導入とか考えるえらい人にこの本読んでとおすすめできるように
ビジネス導入のつらみは大雑把にはわかってるつもりでしたが、体系的に読んで、知らなかったことをまとめておく（自分の言葉で言えるようにする）ため

書評

ブレインパッドのノウハウが凝縮されているような本でした。コンサルの本らしく期待通り体系的にまとまっててとても良かった。データ活用したいとか言ってる人にはぜひ一度読んでもらうのが良いと感じました。

備忘メモ＋感想

1章　AI導入はなぜ失敗するのか

データ分析プロジェクトの7つのリスク

1.分析の進め方として時間と成果が比例しないリスク

2.データの量や質が不十分なリスク

3.データへ依存するリスク

4.データのトレンド変質に関するリスク

5.分析結果に関するリスク

6.分析結果が活用されにくいリスク

7.システム化するときのリスク

このリスクとかあるある。案外最初の1とかってリスクとして提言したことなかったなー

２章　データ分析の基礎を押さえる

データ分析をビジネスに適用する際に注意すべきポイント

1.分析遂行前に業務におけるユースケースや必要な入出力情報、必要精度や評価指標を明確にする

2.初期段階で、概念検証（PoC）段階を設け、適用可能性やリスクを把握する

3.ビジネス適用に際しては、人の判断の入る余地を残す

4.必要なデータを収集、分析する環境を確保する

1章であげたリスクを回避するポイントが上記4つ。人の判断の入る余地を残すは大事だなと思うので、AI適用には、HCI的な知識は必要だなと日々感じる。

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

ビジネス適用上の問題点

1.ビジネス理解

2.データの理解・準備

3.評価指標の選択

4.ビジネスインパクトの算出

データ分析は「すべてはデータから始まる」というボトムアップ的な特性から、全体感を失いがちである。

そのため、結果をどう活用するのかという大局的なビジネス的観点に絶えず立ち返ることが必要

なるほど、ボトムアップ的な特性が強いから、全体感を失いやすいのかという整理に納得しました。

３章　データ分析の仕事の流れを理解する

プロジェクト立ち上げ -> PoC -> ビジネス適用

この流れがデフォルトですよね

PoCを実施する理由

データ分析プロジェクトは不確実なことが多い。プロジェクトの目的・目標の実現可能性を評価するため

PoCってとくにデータ分析プロジェクトに特別多いことではないと思いますが、結局は不確実性が強いプロジェクトに役立つということかなと感じています

４章　プロジェクト立ち上げ

【ゴール設計】

1.プロジェクトの目的の設定

-ビジネスの理解

-分析結果の活用法検討

2.データ利活用で解決可能な目標の設定

【アセスメント】

3.活用されるデータの収集と概要把握

4.スコープの設定

5.プロジェクトメンバーの選定と役割の設定

例：

-目的：ECサイト内での売上向上

-目標：データから顧客の理解を深め、レコメンドアルゴリズムを洗練させることでCTRを1%向上させる

良いですね。新たな分析案件がはじまるときは、上のフレームワークにあてはめてみようと思いました。

５章　PoC

揃えておくべき認識

1.分析結果はどのようにビジネスに活用されるのか

　レベル1 : 結果を人が見て、意思決定の参考情報にする

　レベル2 : 意思決定は人が行うが、意思決定者に具体的行動を提案する

　レベル3 : 意思決定を含めた自動化を行う

2.何が対象か

3.どんな出力値が必要か

4.モデルにはどの程度解釈性が必要か

5.分析結果をどのように評価するか

6.利用するデータに制約はあるか

7.処理時間に制約はあるか

8.環境面の制約はあるか

これも自分のフレームワークにできそうでした。個人的には、時間的制約と意思決定者自体の不確実性度合い（笑）なんかも必要と感じました

６章　ビジネス適用

PoCとビジネス適用の違い

1.PoCは実験用のコードである = コードの品質を高める

2.システムや業務フローに関する検証 = デプロイするときの実行環境を意識する

3.常時更新されるデータ = 随時流れるリアルデータに適用することを意識する

これは普段から意識してることです。PoCの段階で、上記が発生することを知ってPoCをやるかやらないかで、ビジネス適用に進むスピードも全然違うので、特に気をつけています

PoCでできたモデルを実環境に乗せるためにエンジニアの後任者に渡す場合、ドキュメントに残すのは詳細に必要。

理由：なぜこの処理が必要とされるか？なぜこの特徴が必要されるか？などの理由により、当初の意図が伝わらず、謎の処理が残っていくことになる。

まさによくある機械学習の負債話。。

機械学習システムと普通のシステムとの違い

1.外部データへの依存と暗黙のフィードバック

2.挙動が確率的である

3.実装が複雑になりやすい

挙動が確率的という言い方は、学習データに応じてモデルも確率的に変わるという見方があるからなのかなーと考えました

７章　データ活用する組織を作る

組織論は組織によるところが多すぎるーーと思ってるのですが、「分析をスケールさせる＝人を学習させていく」ことがデータ分析組織を作る考え方の前提にあるというのが、普通の組織とは違い難しいところかなと改めて感じました

2018-08-26

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$ 。