Trajectory-driven Influential Billboard Placement (KDD 2018) 読んだ
KDD 2018 | Trajectory-driven Influential Billboard Placement
街頭広告をどのように選ぶかに取り組む。
問題設定としては
- 緯度経度で構成される軌跡 (trajectory) の集合
- 緯度軽度とコストで構成される街頭広告 (billboard) の集合
- 総予算
が与えられ、
- 軌跡 のいずれかの点が街頭広告 の半径 に入った時、確率 で影響を受ける (influenced)
- 街頭広告集合 に対する軌跡 への影響を とする
とするときに影響が最大になるように広告を選ぶ問題を解く。
方針としては「実データにおける多くの軌跡は短い領域の中に存在する」という観測にもとづき、同じ軌跡になるべくクラスタが被らないように街頭広告をクラスタリングして解く。
DP の話が出てきたので読むのを止めた。
こういう話結構昔からやられてそうだけど最適化の世界はよくわからない。詳しい人に解説してほしい。 (論文中では半径を考慮しなきゃいけないところが既存手法で対応していないらしい)
Customized Regression Model for Airbnb Dynamic Pricing (KDD 2018) 読んだ
KDD 2018 | Customized Regression Model for Airbnb Dynamic Pricing
民泊サービス Airbnb において, host (部屋を提供する人,ホスト) に対して「この値段で部屋を貸すと良い」と価格を提案する機能を実装するための技術.
- 予約 (booking) が入るかどうかの予測を行う
- その上で最適な価格を提示する
という二つの方法を取る.
この論文の貢献は以下の二つ.
- 価格の決定方法を評価する指標を提案していること
- その指標にもとづき価格を提示するモデルを学習する方法を考えたこと
なぜ需要の推定が難しいか
「価格を決定する」というのは非常に古典的な問題.一般的には需要関数を求めて面積が最大となるような価格 を提案する.このとき,需要関数は価格のみの関数 である.
しかし, Airbnb では需要は価格だけではなく,時刻 およびその物件を識別する ID によって決まる である.それぞれの要因は次のような要素で構成される.
- 時刻による違い
- 季節性やイベントによって需要が異なる
- 現在時刻と予約を予測したい時刻との差が短ければ短いほど予約されにくい (表示期間が短ければ短いほど予約されにくいという話?)
- 物件による違い
- すべての部屋がほぼ同じであるホテルとは異なり, Airbnb にある物件はすべて異なっている (一般的な物件に加え,城やツリーハウス,船がある).これだけでも需要が大きく変わってくる.
- もし似たような物件に絞ったとしても,レビューが良いほうが需要が高いだろう
- 近隣物件の需要が高まっているのなら,高評価の物件はより高い価格を提示しても利用率を下げることなく予約が入るだろう.
予約推定モデル
まずは予約されるかどうか推定するモデルを構築する.
特徴量には
- 物件特徴量 : 物件の価格,部屋の種類,収容人数,ベッドルームやバスルームの数,アメニティ,場所,レビュー,過去の利用率,「今すぐ予約」が可能か,など
- 時間的特徴量 : 季節性 (何月何日か,何曜日か),予約状況 (チェックインからチェックアウトまでの期間など),予測日から推定対象の日付までの差など
- 需要・供給のダイナミクス : 近隣の予約可能な物件数,検索者数など
モデルは GBM を使う.ひとつの GBM を推定するのではなく,物件の密度に応じて区画を分け,adaptive sampling を行いながら別々の GBM を学習することで AUC がより良い値になった.
このモデルを需要関数代わりに使うとどうなるか
この予約推定モデルを価格の関数としてみなすことで需要関数として扱うことができる.この関数をそのまま使って収益最大化を A/B テストしてみたが失敗した.
この関数を需要関数としてそのまま使うことには以下の三つの問題があった.
- データがスパースであること : データにおいて価格は大きく変化していない.たとえば 150 ドルの部屋に対して 50 ドル未満や 500 ドルを設定している人はいない.そのため,平均的な価格のデータばかり集まってしまう.
- 物件がそれぞれユニークすぎること
- 特徴量の依存性 : 予約推定モデルにおいて用いた特徴量のうち価格と相関を持つものがあるためうまく働かない.
価格提示モデル
最適な価格と提示価格の関係,オフラインでの評価指標
ここからがこの論文の一番おもしろいところ.
そもそも「最適な (optimal)価格」とは一体どういうことでしょうか.いま手元にあるデータには,「ある価格の物件に予約が入ったかどうか」しかわからず,このデータで学習をしてもただの「現状の価格推定モデル」が得られるだけです.「真に最適な価格」は神様しか知りません.
そこで,真に最適な価格 が存在するとして,実際の価格 とモデルによって提示する価格 との関係を考えると以下のように整理できる.
- もし物件が予約されて だった場合,もしホストがモデルに従っていた場合には 分だけ損をすることになる.なのので でなければならない
- もし物件が予約されずに だった場合,もっと安ければより予約される確率が高まっただろう.よって でなければならない.
- もし物件が予約されて だった場合,もしホストがモデルに従っていた場合 (値上げしていた場合) でも予約が入ったかどうかはわからない
- もし物件が予約されずに だった場合,ホストがモデルに従っていればより予約される確率が高かっただろう.しかし安すぎるとホストが損をしてしまう.
これらの関係を踏まえて,prec-recall の 表のように
- a : かつ予約された
- b : かつ予約されなかった
- c : かつ予約された
- d : かつ予約されなかった
として次の 5 つの指標を考える.これらの指標はオフラインでのモデルの評価に用いる.
- Price Decrease Recall (PDR) : d / (b + d), 予約されなかった中で,安く提案できていた割合
- Price Decrease Precision (PDP) : d / (c + d), 安く提案できていた中で,予約されなかった割合
- Price Increase Recall (PIR) : a / (a + c), 予約された中で,高く提案できていた割合
- Price Increase Precision (PIP) : a / (a + b), 高く提案できていた中で,予約された割合
- Booking Regret (BR) : の全予約での median
Price Decrease は「より安く提案できていたか」すなわち予約確率をより上げられていたかについて, Price Increase は「より高く提案できていたか」すなわちホストがより収益絵を得られたかについて考えている.
BR は提案によって収益が落ちていたであろう度合いを表している.
検証したところ,これらの指標の中での PDR と BR は実ビジネスでの指標と高い相関を持つことがわかった.特に,PDR は booking gain (予約数?)と相関を持ち,低い BR による価格提案はよりホストの収益を増加させていることがわかる.じゃあ PDR と BR だけを見て最適化すればいいかというとそういうわけにもいかない.なぜなら PDR と BR はトレードオフにあるからだ (安い価格を提案すると PDR は改善するが BR は悪化する).
モデル,目的関数
まず特徴量として
- ホストによって設定された価格
- 予約推定モデルによる確率
- 予約推定モデルでは捉えきれなかった市場の需要を示す変数
を入れる.
ここで,目的関数として SVR での insensitive loss (ε許容誤差) のように幅を持たせた新しい損失を提案する.何度も言っているように,「最適な価格」というのを我々は知ることができないけれど,ビジネス的な観点から「最適な価格はこの範囲内に入るだろう」ということはわかるのでそれを損失関数に反映する.
目的関数は次の関数の最小化である.
ここで は i が予約されていたかどうかを示す二値変数, は推定したいモデル,.
はそれぞれ
とする.このとき である定数.
これが何を意味しているかというと,
- 予約されている時は価格の下限を ,上限を とし,その範囲内であれば損失を 0
- 予約されていない時は価格の下限を ,上限を とし,その範囲内であれば損失を 0
という形の非対称な損失を考える.
需要に基づく価格設定
更に価格提示のためのモデルを考える.以下のような仮説を置く.
- 同じ物件ならば予約確率と価格には相関がある.よって予約確率で価格を変化させる.
- 予約予測モデルでは捉えられなかった需要の兆候が容易に反映できるようにする
- 代表的な価格を中心にしてそこからの増加・減少分を学習する
これを踏まえ次のようなモデルを作る.
P はホストによって設定された代表的な価格,は予約確率, は類似した物件で作ったクラスタにおける追加の特徴量から構築した需要の度合いを正規分布で正規化したもの.
は価格の増減をコントロールするパラメータ, は を出す時の微調整パラメータ.が与えられるとこの関数は に対して単調増加する. は定数.
学習
とはいえこれだけだと値が壊れるので
となるような制約を加える.
また,需要が乏しい物件には
という制約を加える.
あとは SGD で学習.
PDR の話のあたり,「真の値が存在しない時にどういう数字を作れば改善してるかどうか考えられるか」の話が一番おもしろかった.気力が尽きたので の話のあたりはよくわかってない (例えば additional な demand signal とは何か,とか).
声優統計コーパスのバランス文を男性が読み上げた音声ファイルが公開されました
声優統計コーパスのパラレルコーパスとして,東京大学猿渡研究室によるJSUT (Japanese speech corpus of Saruwatari-lab., University of Tokyo)がありました.
このたび,nico-opendata 音声読み上げデータセットが Dwango Media Village によって公開されました.
nico-opendata 音声読み上げデータセットは Dwango Media Village の男性研究員が声優統計コーパスのバランス文 100 文を読み上げた音声ファイルです.上記ページでは統計的声質変換に関するサーベイも記述されています.声質変換についてわかっていなかったので非常に参考になりました.
また,同研究員が音学シンポジウム2018で発表を行った「畳込みニューラルネットワークを用いた音響特徴量変換とスペクトログラム高精細化による声質変換」について,発表内容,ソースコード,および,統計的声質変換を実際に行ったデモ音声が公開されています.
せっかくなのでこれを機に様々な人々が思い思いの音声コーパスを公開する時代になると面白いと思います.
Pixie: A System for Recommending 3+ Billion Items to 200+ Million Users in Real-Time (WebConf 2018) 読んだ
[1711.07601] Pixie: A System for Recommending 3+ Billion Items to 200+ Million Users in Real-Time
Pinterest における推薦の論文.Jure Leskovec が last author に入っているのでとりあえず読む. WWW が WebConf に名前が変わったのが悲しい.
概要
超大規模なサービスである Pinterest においてリアルタイムな推薦を実現する Pixie について説明する.
手法
Pinterest ではユーザは Board の下にそれぞれの pin を保存する.実現したいのは直近のユーザの行動によって得られた pin と重みの集合であるクエリ Q に対して適した pin を推薦したい.
基本的な方針は pin と Board を二部グラフとみなしてそのグラフ上をランダムウォークする.
ランダムウォークの基礎
クエリ が 1 つだけで重みがない場合のランダムウォークについて考えてみると,二部グラフ上の かららスタートして 回二部グラフ上をランダムに渡り歩き,それぞれの pin を訪問回数 順に並び替えて返せばいい.
この手法を次に説明するように発展させていく.
ランダムウォークにバイアスをかける
まずはただランダムに遷移するのではなく,ユーザごとにバイアスをかけることを考える.隣接ノードを uniform に選ぶのではなく,ユーザごとの特徴量に従って遷移するノードを PersonalizedNeighbor(E, U) という関数で選ぶ.この関数についてはこれ以上の説明がないので詳細は不明.
複数のクエリと重みを扱う
クエリとして複数の pin とそれぞれの重みを扱う (重みはその pin に対してユーザがどういう行動をとったか,およびその行動が発生してからの経過時間にもとづいて決まるらしいが詳細な説明無し).
基本的には各クエリごとにランダムウォークを行い,クエリごとの pin の訪問回数 を保存する.
ここで重要なのは,各クエリにおいてランダムウォークの回数 を変えて とすることである.クエリの次数が大きければ大きいほどランダムウォークの回数は多くする.
と思ったらより効率的にするために early stopping を導入する.これは最低 個の pin に最低 回訪問したらランダムウォークを打ち切るというもの.これによって精度はそのままに計算時間が倍の速さになった.
(early stopping するなら重みの形はどうでもいいのだろう)
Multi-hit Booster
ただ足し合わせるのではなく, として複数のクエリから訪問されている pin を重く評価する.
ML Ops Study #2 参加した
ML Ops Study #2 - connpass
申し込んだら当たったので参加した.皆さんみたいにちゃんとした機械学習や深層学習がしてみたかった.
機械学習プロジェクトを頑健にする施策: ワークフロー、仮想化、品質向上、知識移譲 etc
機械学習プロジェクトを頑健にする施策 ML Ops Study #2 // Speaker Deck
- 機械学習プロダクトは脆い.原因とその対策.
- 実験スクリプトが動かない
- 動かし方がわからない
- make や Luigi を使う
- 実行環境構築は docker でやる
- Home - Cookiecutter Docker Science
- 動かし方がわからない
- 実験スクリプトが理解できない,実験した人がいなくなる
- ソフトウェアエンジニアリングをちゃんとする
- ソフトウェアエンジニアが書いてリサーチャーがレビューする
- コードの整理は実験をした本人がやる
- この話,金融機関における数理モデル研究から実用化に至るノウハウなどが(もしあるのならば)参考になるのではないかと思った
- テストもちゃんと書く
- 実験スクリプトが動かない
質疑で「リサーチャーは Jupyter notebook が精一杯だったりする.リサーチャーがソフトウェアエンジニアの,ソフトウェアエンジニアがリサーチャーの素養がある程度ないと難しいのではないか」みたいな質問があり, Cookpad 社は両方素養がある人ばかりなのでコードレビューも問題無いという返答があった.Jupyter notebook ですらまともに使うことができない低レベルの人間なのでとても参考になった.
「Github や Qiita に公開されている機械学習系のコードは品質がひどくて動かない事が多い」という話で自分を除く皆さんが笑顔になっていた.
ドローン点検・測量を機械学習を使って圧倒的に簡単にしました
声優統計コーパスの利用事例暫定まとめ
日本声優統計学会 にて声優統計コーパスを公開してほぼ一年.個人団体を問わず問い合わせのメールを頂いている.
しかしよく考えたら Google Analytics の設定をまともに書いていなかったせいでどれぐらいダウンロードされたのか全く計測できていない.せめて,検索して見つけた範囲で利用されているブログ記事を集めた.
声優統計コーパスを使ってみる - 驚異のアニヲタ社会復帰への道
声優統計コーパスをアライメントしてみる | Hiho's Blog
日本声優統計学会の公開データを使って声優さんの声認識 – 京都の技術者ロードローラーさんのブログ
声優統計コーパスを使ったWaveNet音声合成/歌声合成に挑戦します - Monthly Hacker's Blog
声優統計のデータを使った、簡単なGMM声質変換のデモノートブック - Jupyter Notebook
@__dhgrs__さんからの指摘にもあるように,公式でアラインメントを提供すべきなのだろうと思っているけれどなかなか時間がない.今回言及した記事でも行われていたり,この方も行っていたりとあるにはあるのだけど,なかなか追いきれていないのと音声周りの知見がやはりまだ無いままなのでどうやるのが良さそうなのかよくわかっていない.
Shinnosuke Takamichi (高道 慎之介) - JSUT
また,これはブログ記事ではないけれど,東大猿渡研究室の高道助教によって作成されたコーパスに voiceactress100 として声優統計コーパスと互換のある音声が含まれている.
このコーパスは [1711.00354] JSUT corpus: free large-scale Japanese speech corpus for end-to-end speech synthesis という形で論文にもなっている. Reference に [11] y_benjo and MagnesiumRibbon とあるのがいい.
その他,このように利用しているなどあったら教えて欲しい.とても嬉しい.
Dynamic Word Embeddings for Evolving Semantic Discovery (WSDM 2018) 読んだ
概要
[1703.00607] Dynamic Word Embeddings for Evolving Semantic Discovery
word embedding の時系列変化が見たい(これどこかの論文でも見た気がする).
例えば, apple という単語は昔は果物が連想されるだけだったが,今ではテクノロジー企業も連想されるだろう.
例えば, trump という人名だって「不動産」 -> 「テレビ」 -> 「共和党」と連想するものが時間と共に変化するだろう.
そういうのが見たい.
問題は,従来の embedding の方法は学習時に回転を考慮しないため,異なる時点での embedding を対応付けることができない.そこで,従来手法では,
- 各時点での embedding を学習する
- 時点ごとの embedding を対応付ける alignment を解く
という二段階のアプローチを行っていた.
この論文の手法は,全時点での embedding を解きながら embedding の時間変化に伴う滑らかさを正則化項として追加することで alignment を分割して説かなくて済む.
手法
ある時点での embedding については skip-gram や CBoW ではなく, PPMI (positive pointwise mutual information) 行列を行列分解することで獲得する.
結論から先に書くと,時点 における PPMI matrix を とし,分解後行列を とすると,最小化すべき目的関数は
となる.一項目は embedding そのものの誤差の最小化,二項目は embedding の正則化,三項目が時点間での滑らかさのコスト関数.で時点間の embedding がどれだけ近いかをコントロールする.
これにより,全ての embedding が全時点を考慮した状態で推定が可能となる,と著者らは主張している.
非常にシンプルな話.
勾配まで論文中に示してあるので実装も簡単にできそう.