#銀座VR に WebVR で行けるようにしてみた

5月に発売されたスタンドアローン(ひも無し) VR ヘッドセットの Oculus Go が想像通りの良いものだったので、会社で100人くらいにかぶせて回ったり、Unity や WebVR でなんかちょこちょこ作ってみたりということを最近している。

7/7 に銀座VR という、VR で作ったものを持ち寄るイベントがあるって直前で気づく。
銀座SIXでマーロウのプリンを買って帰ると言ったら簡単に参加許可が下りたので、のこのこ出かけてきた。


一体型VR限定イベント、つまり発売されたばかりの Oculus Go と Mirage Solo がメインターゲットということで時間が足りなかったか、未完成とかコンセプト重視な展示が中心だったかな。
一体型VRの最大のメリットでもある「持ち寄りやすさ」を活かすような展示があって、みんなが自分の Oculus Go を首から下げて歩いている……というの期待しちゃったりして、一応自分の Oculus Go を持ち込んだりもしてたのだが、カバンから出す機会もついぞなかった。無念。
そう思うなら自分で作れということだな。


こういうイベントは見るだけより自分も展示側で参加するほうが絶対に楽しいしんで、次があれば考えたいかも。
今回は間に合うわけもなかったけど、とりあえず Richo THETA で 360度写真を何枚か撮ったので、それをバーチャルツアー的に見せる VR コンテンツを作ってみた。
VR ヘッドセットで見るのが前提(Oculus Go で動作確認、他のヘッドセットでも動くことを期待するコードを書いたつもり)だが、PC や iPad でも見れる。


ブラウザでリンクを開くと、VR ヘッドセットの場合はブラウザ右下のゴーグルをクリックすると VR モードになり、会場の360度写真の中に入る。
自分の下を見ると会場マップがあるので、緑のマーカーをコントローラーで選択すると、その位置に移動する(写真が切り替わる)。

PCの場合は画面をドラッグすると視線の向きを変えられる。同様に下の方にマップがあるので、クリックで移動する。

iPad は、本体を掲げてぐるぐる周りを見ると、その向きの写真が表示される。移動は下向けてマップをタップ。


360度写真を見る&地図をポイントして移動するだけ。
VR コンテンツとしては簡素すぎるが、これでも十分雰囲気を味わえる。
各展示が再生できたり、出展者の Oculus Rooms の入口があったりしたら、ほんとに現地に行かなくても済むようになるかもw


マップを下においたのは思いつきといくつかの事情からの苦肉の策で、正直操作はしにくい。
でもマップと写真の向きがあっていることで、会場がどんな場所かすごく想像しやすくなっている……と思ったのだがどうだろう(身贔屓?)。


こういった VR コンテンツを作るなら、選択肢としては

のどっちか。

Unity は導入と配布のハードルがかなり高いが、ノウハウたんまり、エコシステム充実(アセットストア)、高パフォーマンスと、本格的なものを作るなら正直一択に近い。
でも、もともと Web 屋さんだった身としては、WebVR の可能性をできるだけ追求したいところ。というわけで Mozilla 謹製 WebVR フレームワーク A-Frame をがんばって使ってみている。
しかしかなりの発展途上で、ぶっちゃけ上の VR コンテンツを作るだけでも明文化されていないノウハウをかき集めたり自分で見つけ出したりしないといけない。とはいえ、コンテンツの配布が極めて容易という特大のメリットは捨てがたい。


今回の VRツアーみたいのが HTML+JS 70行程度で書けるのも WebVR の良いところだろう。
Unity だと開発環境を作るだけで何時間かかかるし、変更のたびにかかるコンパイル時間もバカにならない。


というわけで WebVR にも確実に需要はあるので、現時点でいくつかある A-Frame を使うノウハウについては、別途まとめるつもり。

「Chainer による実践深層学習」の気づいたこといくつか

Chainer v2による実践深層学習

Chainer v2による実践深層学習

Chainer について書かれた数少ない本。
この9月に v2 対応版が出た。が、v3 リリース秒読みの時期に……というツラミはある*1
深層学習ライブラリは現状「泳ぎ続けなければ死ぬ」(アップデート止まったら、終わったのかな? とか思っちゃう)ので、宿命的にしょうがないのかな。


社内でこの本の読書会とかしており、ちょいちょい間違いを見つけてしまう。
細かいのはもういいかなとは思うんだが(全部書いてたら正直キリがない)、せっかくの Chainer 本、読者が誤解すると事故が起きそうなちょっと大きめの間違いを放置するのはもったいないので、ここにメモしておく。
自分で読んだのは RNN 以降なので、主にその範囲。


以下、章・ページやリスト名などの表記は v1 版だが、v2 版でも残っていれば特定は難しくないと思う。
手元にあるのは v1 版で、v2 版では直ってるかもしれない。が、ちら見した感じでは残ってそうだった……。
ちなみに著者の新納先生のサイトに Erratta も出ているので参考に。見つけた間違いはほとんど載っていないが……。

7.7 Chainer による LSTM の実装(p98-99)


LSTM をあえて基本的な部品だけで実装する、本書の白眉。


lstm0.py のパラメータ宣言部で、式 Wx+Rh+b を実装するのに W 用の L.Linear と R 用の L.Linear を宣言しているが、両方がバイアス項を持つため、ダブってしまっている。Wx+Rh+a+b という状態。
致命的な悪さはおそらくしないだろうが、メリットは何もない*2ので、片方に nobias=True をつけて、バイアス項を一本化するべきだろう。
学習時間も 5% ほど短くなる。

class MyLSTM(chainer.Chain):
    def __init__(self, v, k):
        super(MyLSTM, self).__init__(
            embed = L.EmbedID(v, k),
            Wz = L.Linear(k, k, nobias=True),
            Wi = L.Linear(k, k, nobias=True),
            Wf = L.Linear(k, k, nobias=True),
            Wo = L.Linear(k, k, nobias=True),
            Rz = L.Linear(k, k),
            Ri = L.Linear(k, k),
            Rf = L.Linear(k, k),
            Ro = L.Linear(k, k),
            W = L.Linear(k, v),
        )

7.7 Chainer による LSTM の実装(p100)

また学習の部分は素の RNN のものと同じでよいのですが、計算時間がかなりかかります。RNN の学習には unchain_backward() という関数を使うことで改善されます。これは長い系列を学習する際に、古い情報を捨てて、計算時間を改善するのに使います。ここでは文の長さが 30 を超える場合に、この関数を起動することにします。


と記述されているが、残念ながらここでの使い方では unchain_backward は全く効果がない。
本書の lstm0.py で unchain_backward を入れたり削ったりしたときに性能が変わったように見えたとしても、それはおそらく初期値の乱数の影響である。


unchain_backward は、L.LSTM のような「前時刻の隠れユニットや記憶の状態をメンバーとして保持しておき、各時刻ごとに __call__ を呼ぶ」タイプの実装を前提として設計されている。RNN のグラフの横方向の辺を切って、計算グラフを小さくするために、例えば 30 時刻ごとに unchain_backward を発行する。加えて、公式のサンプルを含め、多くの LSTM 実装では「1系列=全データをつなげたもの」なので、切らないと大変なことになる。


しかし、本書の lstm0.py は「__call__ には系列全体を渡す。隠れユニットや記憶の状態は __call__ の先頭でローカル変数として宣言&初期化する」タイプの実装となっている。したがって、前の __call__ のあとに unchain_backward を発行しようがしまいが、次の __call__ が呼ばれたときは計算グラフは切れている。


ちなみに本書では「1系列=1文」であり、truncate しなくても死なない。が、隠れユニットが 100 次元しか無いので、適切に切ったほうがおそらく性能は高くなるだろう。
しかし lstm0.py で truncate したいと思っても、学習ループ(特に backward 発行)と時刻のループが別れてしまっているので、簡単な改造では難しそう。同等ではないが、 __call__ の中で、30時刻ごとに h.unchain() と c.unchain() を発行すれば、近いものになるのかな?

8.5 Attention の導入(p123)


Encoder の各時刻の隠れベクトルを Decoder に渡すためのリスト gh を作る部分の説明。

リスト gh に Encoder 側の \tilde{h}_i を順番に追加しています。
(中略)
gh に \tilde{h}_i を追加する際に、明示的に np.copy を使っていますが、おそらく必要ありません。そのまま ht.data[0] を渡しても問題ないとは思いますが、念のためコピーしました。


コピーしちゃダメーーー!!!


.data やそのコピーではなく Variable のまま渡さないと、せっかくの計算グラフが切れてしまう。
Decoder に渡す変数(もともとの Attention では隠れユニットを渡すが、最近のモデルでは Encoder の出力を渡すのが流行っている?)の計算グラフを切ってしまうと、「Attention にも有効なように Encoder が符号化してくれる」という Attention の嬉しさの一つが消えてしまう。


というわけで、コピーしないで、Variable のまま渡しましょう。

*1:ちなみに v1 版も、Chainer v2 が出た後の出版、しかも v1.10 準拠だった……

*2:aとbが最適解を持たないというデメリットはある

無限関係モデル(Infinite Relational Model)の紹介資料+実装


サイボウズ・ラボでは社内向けの機械学習勉強会を 2012年から週1ペースで継続している(前身の PRML 読書会も合わせれば 2011年から)。割り振られた担当者が、書籍や論文など読んだり、実装してみた話などを紹介している。


例えば今年の4月以降の勉強会のネタをピックアップするとこんな感じ。明らかに「いわゆる機械学習」周辺にすら含みようがないネタもポロポロあるが、「機械について学習」くらいまで拡大解釈している、ことにしてほしい(苦笑)。

  • プライバシー保護データマイニング
  • 並行実行制御
  • 強化学習
  • 状態空間モデル
  • 秘密計算(暗号化したまま各種演算)
  • 確率論
  • seq2seqで計算
  • Attention
  • End-to-End Memory Networks
  • WebAssembly
  • 複雑ネットワーク
  • "Why does deep and cheap learning work so well?"
  • "Sliding right into disaster"


この勉強会の資料は一部公開されている。西尾さんの強化学習や、光成さんの暗号系などなど。


中谷も当勉強会で機械学習自然言語処理のネタを紹介してきたのだが、資料はほとんど公開してなかった。口頭の説明やその場での書き込み前提とか、著作権的な配慮が足りてないとか、内部データを使っちゃってるとか、セキララな毒舌が炸裂してるとか、要は内部勉強会なことに甘えて作りがユルかった。
まあでもやっぱりもったいないので、先週から資料を人に見せられるレベルまで改訂して公開週間を始めた。第1弾が Memory Networks で、第2弾がこの無限関係モデル(Infinite Relational Model)。



無限関係モデルは2年くらい前(↓このあたりのブログ記事を書いていた頃)にやったので、上の最近の勉強会ネタリストにはない。


古いネタを掘り起こしてきたのは、実装があるものを優先したため。


この実装では、スライドでも説明しているとおり、ベルヌーイ分布をポアソン分布に替えた「0/1 じゃない関係解析」版を実装してみている。
が、ポアソン分布が外れ値に弱いので、ちょっと多い項目があると1要素のクラスタを作ってしまい、残念ながら使い物にならなかった。負の二項分布あたりを使いたいところだが、全情報付き事後分布を閉じた形で書き下せないだろう……。
CRP を Stick Breaking で書き直して、トピック数の上限入れて、Stan あたりで解かせてみるというのも考えたけど、ちょっと大きくなるだけで死ぬよな。まずはモデルとして意味があるか検証する、ってならアリかもしれない。


「古いネタ」なんて言っちゃったが、引き続き「続・わかりやすいパターン認識」はノンパラベイズについてきちんと詳解してくれている希少な和書だろう。続パタ以外となると、今なら佐藤一誠さんの「ノンパラメトリックベイズ」(MLP青シリーズ)があるので、もう1つ選択肢がある? でも続パタとは難易度がかなり違うので、読者層は重ならないかもしれない(と、えらそうに評してみたが、買っただけでまだ読んでない。ごめん)。


ノンパラベイズ、というかトピックモデルは昨今の深層学習ブームに押されまくっているが、内部の構造を想像しながらモデリングする楽しさは(一般的な)深層学習には無いものなので、またそのうち揺り戻しが来るかも?


というわけで次の資料公開週間は、実装があるので GAN あたりかな(トピックモデル推しの舌の根も乾かぬうちに……)。
GAN の記事や資料はすでに溺れるほどあるのであまり意味ないかもしれないが、Conditional GAN をやってる人は少ないっぽいので、そのあたりはちょっとおもしろいかもしれない。

End-to-End Memory Networks の勉強会資料+補足


前記事で End-to-End Memory Networks の実装を公開してたが、さらに社内勉強会の資料も公開する。
モデルもわかるように一応説明したつもり。



以下、前記事で書き忘れたこと+補足。

  • 実装は CPU / GPU 両対応している。が、GPU の方が遅い(苦笑)。たぶんデータの渡し方が悪い&モデルが小さいので、演算時間がオーバーヘッドを上回れないのだろう。データの渡し方を工夫すれば改善するだろうが、Random Noise がどうせ台無しにするので、そこを頑張るのはやめた。
  • 質問と記憶から応答情報を生成するのが基本。その応答情報を新しい質問とみなしてフィードバックすることで RNN 的な多層ネットワークを構成することができる。表現力が上がる……のかな? 実装では層の数をオプションで指定できるようにしているので、1層と3層で傾向がどのように変わるのか確認してみるのも面白いかもしれない。

End-to-End Memory Networks を実装してみた

久しぶりの更新。


学生さんが好きなものを開発するのを支援するサイボウズ・ラボユースという制度が始まってもう7年目。
先日、4年ぶりにラボユース合宿が開催された。

詳しくはリンク先の記事を見てもらいたいが、要は、泊まり込みで朝から晩までみっちりコードを書きまくり、夜も思う存分プログラミング談義な合宿に参加できるということ。朝昼晩のごはんもついてる。温泉もある(※開催地による)。もちろん費用はサイボウズ持ち。

サイボウズ・ラボユースは通年募集、まだまだ応募できる。興味あればぜひ。宣伝終わり。


さて、合宿にはサイボウズ・ラボの社員ものこのこついていく。
いろいろ話したり、指導したりもするのだが、やっぱりコードを書いている時間が一番長い。
しかしせっかくの合宿という場なのに、いつもと同じコードを書くのは芸がない。
そこで Memory Networks を実装してみることにした。


実は Memory Networks が、あまり好きではない。むしろ嫌いかもw。
だからこそ、食わず嫌いに陥らないために、いつもと違う雰囲気の中で実装してみようという志なわけだ。
と偉そうに言ってみたが、論文をろくに精読もしていない状態から3日間で実装するのはさすがに無謀で、合宿後も結構みっちりコード書いたり実験したりする羽目に(苦笑)。


Memory Networks とは、記憶した知識から質問にふさわしい情報を取り出し、回答を生成するモデル。
直接的には質問応答問題だが、汎用人工知能に発展させたいという野望が見え隠れしている。
日本語ならこちらのブログ記事か、MLP シリーズの「深層学習による自然言語処理」か。


前者はかなり詳しいが、さすがにこの記事だけで実装できるわけではなく、元論文を読む必要がある。
代表的な論文はこちらの3本だろう。

  • Weston, Jason, Sumit Chopra, and Antoine Bordes. "Memory networks." arXiv preprint arXiv:1410.3916 (2014).
  • Sukhbaatar, Sainbayar, Jason Weston, and Rob Fergus. "End-to-end memory networks." Advances in neural information processing systems. 2015.
  • Kumar, Ankit, et al. "Ask me anything: Dynamic memory networks for natural language processing." International Conference on Machine Learning. 2016.


素の Memory Networks は、「記憶にあるどの知識を参照するべきか」という情報が質問に付いているという前提のモデルである。
さすがにそれはちょっとなー、という人には、「どの知識を参照するべきか」も一緒に学習する End-to-End Memory Networks がある。
ネットワークの大きさも手頃で、3日間で実装するにはちょうどいいだろう(できなかったが)。


さらに発展した Dynamic Memory Networks では、「人間の推論はいきなり回答が出てくるのではなく、段階を踏んでいる」ことをモデルに組み込んだ。
End-to-End Memory Networks を実装してみて、その苦手なタスクを目の当たりにすれば、なるほど、そっちへ発展させたくなる気持ちがよくわかる。

End-to-End Memory Networks


ここで End-to-End Memory Networks の詳細に踏み込んだら、いつまでたっても実装の話に入れない。
社内勉強会用に End-to-End Memory Networks の資料を作ったので、モデルの概略は後ほどそちらを公開するときに語ることにする。
ここではモデルは既知として、実装によって確認できた知見をメインにしよう。


End-to-End Memory Networks のモデルそのものはシンプルかつ小さいので、モデルを記述するだけなら、どの深層学習ライブラリでも 10行ちょいで書けるだろう。
ただし、それだけでは全く性能が出ない。そこでさまざまな「工夫」を追加で施すことになる。

  • Temporal Encoding
  • Random Noise
  • Position Encoding
  • Linear Start
  • 勾配の切り詰め


素朴な End-to-End Memory Networks では、知識は記憶に追加されるだけであり、質問との関連を推定するときに時刻は考慮しない。
しかしそれでは、"Sandra moved to the garden." と "Sandra journeyed to the bathroom." という2つの知識の記憶があるとき、"Where is Sandra?" と質問されても、どっちの知識が今の Sandra の情報を表しているのかわからない。
そこで「記憶の知識の時刻と、質問時の時刻の差」の情報を組み込むのが Temporal Encoding だ。
これを入れないと、笑っちゃうくらい性能が出ない(タスクによってはランダムと同等まで落ちる)ので、Temporal Encoding は必須である。


ただし、Memory Networks の理想の姿であれば、知識が入ってきたときに「Sandra は garden に行った」という記憶を「 garden に行った後、bathroom に行った」に更新(Generalization)するべきなのだろう。
そこをモデル化していないツケを Temporal Encoding というヒューリスティックで払ってるわけだ。


Random Noise は、記憶の系列に 10% の確率で 0 ベクトルを挿入して時刻をずらすことで、Temporal Encoding が特定の訓練データに過適合するのを防ぐ。
論文ではかなり効果があるようだが、手元の実験ではいくつかのタスクで汎化性能がちょっこり上がった? くらいの印象。


素朴な End-to-End Memory Networks では「単語ベクトルの総和」を文のベクトルとするのだが、それだけでは "Mary handed the football to John." と "John passed the football to Mary." がほとんど区別できない。Position Encoding は単語ベクトルを加算するときに、ベクトルの要素ごとに単語の文中の位置に応じた重みを与えることで、単語の位置の情報を文ベクトルに落とし込む。


\displaystyle m_{ik}=\sum_j \left\{\left(1-\frac jJ\right)-\frac kd\left(1-\frac{2j}J\right)\right\}\left({\boldsymbol Ax}_{ij}\right)_k


ここで x_ij は i 番目の文の j 番目の単語(1-hot vector)、A は単語を分散表現ベクトルに変換する行列、J は文長(単語数)、d は分散表現の次元、k=1,…,d は分散表現ベクトルの要素インデックス。
この式は次のように変形することで、固定長の演算に落とし込むことができる。


\displaystyle m_{ik}=\left(1-\frac kd\right)\left({\boldsymbol A}\sum_j{\boldsymbol x}_{ij}\right)_k+\left(\frac{2k}d-1\right)\left({\boldsymbol A}\sum_j\frac jJ{\boldsymbol x}_{ij}\right)_k


データに対しては、単語頻度行列を単純和 \sum_j{\boldsymbol x}_{ij} と重み付き和 \sum_j\frac jJ{\boldsymbol x}_{ij} の2つをあらかじめ計算しておけばよい。
文を RNN とかでベクトル化すればこんな工夫はしなくていいだろうが、学習がテキメンに重くなる。
この手法ならネットワークの大きさを固定できるので、速度的には大幅に有利だろう。


Linear Start は、質問と各記憶の関連度を確率に落とし込むソフトマックス層がネットワークの中間にあるのだが、これを学習の初期に取り除いてしまうという手法。
学習が早くなり、local minimum に捕まりにくい……と論文は言うのだが、正直効果は実感できなかった。
validation loss が上昇したらソフトマックス層を挿入して本来のモデルに戻すので、Linear Start するしないはせいぜい初期値の影響程度。上述の固定長で実装すればかなり高速に学習できてしまうので、初期値を変えて何回かトライする&ちょっと長めに Epoch 回すくらいで十分 Linear Start を上回れるんじゃないの?


学習については、"No momentum or weight decay was used." と書かれており、生 SGD を使うことが明示されている。
しかし学習率を 1e-5 以下にしても、かなりの頻度であっさり inf に飛ぶ。特に上の Linear Start を組み込んだら、inf に飛ばずに学習できる方がまれになる。そこで、backward 後に、各パラメータごとに勾配のノルムが 40 を超えていたら、スカラー倍して 40 に納める、という強引な変換を入れる。
こんなの初めて見たんだけど、アリなのかな? GAN の学習が不安定なのとか、これでうまくいく割合が増えたり?


ただ、そんな勾配の切り詰めなんかしなくても、Adam でさっくり学習できたりする(苦笑)*1。まあ、Momentum 系特有の乱高下はちょいちょい起きるけど。


あとは学習率を細かく変えるとか、ミニバッチは 32 とか、指定されてるけど、そのへんはネグった。
というわけで実装はこちら。


当初、ベクトルを計算するところで文の長さに応じた処理が必要になると思って Chainer を選んだのだが、固定長で済むので Tensorflow と使うべきだった。スパース行列もサポートしているし。無念。
Chainer から Tensorflow への移植がどんなものかという興味もあるので、気が向いたら Tensorflow で実装し直すかもしれない。たぶん、そんなに大変じゃない。

bAbI データセット
https://research.fb.com/downloads/babi/


データセットは bAbI。Facebook が Memory Networks のために作った?
ごくごく単純な文法と、ごくごく小さな語彙セットで構成され、しかも回答は1単語という、名前の通りとても簡単な質問応答データセット。20 のタスクが用意されているが、否定文を含むのはその中の1つだけだったり。
リンク先から bAbI Tasks Data 1-20 (v1.2) をダウンロードして展開(ファイル名は tasks_1-20_v1-2.tar.gz )、e2emn.py を実行すると Task 1 で学習・推論する。
他のタスクに変えたり、上述の工夫を On/Off したり、Adam で学習したりもできるので、ヘルプ見て。


Task 1〜20 それぞれについて、初期値を変えて5回学習、それぞれ一番良いエラー率を拾ったものがこちら。
論文に合わせて、BoW(Temporal Encodingのみ)と、Position Encoding, Linear Start, Random Noise を順に有効にしていったものについて実験している。
大勢には影響ないだろうと思って validation=test にしてる。手抜き。



細かいところは色々違ってるが、かなり論文に近い結果が再現できた?
違いを産んでいるのは、やっぱりミニバッチを実装していないことかもしれない。
トライしなかったわけではないのだが、ソフトマックス層の幅がデータごとに違うのをうまく実装するのがめんどくさくなって、半日くらいであきらめてしまった。

*1:Adam の本来のアルゴリズムのおかげなのか、Chainer の Adam 実装のおかげなのかはわかってない。

コサイン類似度が高いベクトルはどれくらい似ているか(岩波データサイエンス刊行イベントより)

岩波データサイエンス vol.2 の発刊を記念して、刊行トークイベント「統計的自然言語処理 - ことばを扱う機械」が 3月3日 に開催されました。


イベントの様子はニコニコ動画さんで生中継されましたが、その録画は YouTube で公開させてもらっています。


トークイベント「統計的自然言語処理ーことばを扱う機械」(岩波データサイエンス Vol.2 刊行記念) - YouTube


自然言語処理に詳しい人でも詳しくない人でもおもしろい本&イベントになったので、ぜひ一度手にとって見てもらえると嬉しいです。
よくわからないけどちょっと味見してみようかなという人には、賀沢さんの招待講演がユーモアたっぷりですので、まずはそれを笑って楽しんでみては。


以上、1ヶ月遅れ(刊行からは2ヶ月遅れ……)の宣伝終わり。


さて、上記イベントで東北大の岡崎先生が、ご発表の冒頭で word2vec で "Tokyo" と "Osaka" のベクトルが似てるという話をしてくださった。

word2vec によって学習した300次元のベクトルそれぞれをplotして、
「結構似てませんか」
「びっくりしたんですけど、視覚で見ても結構似てるなとわかる」
「このくらいの(コサイン)類似度(0.84)だと視覚的に見てもわかるんだな」


(岡崎先生の発表動画より)


とやらかす(失礼)と、会場はドッと受けていたわけだが、実際見た目よく似てる(よね?)。


まあ「見た感じ似てる」とかいうのは主観的過ぎるし、人間の習性的にどうしても「違い」に目が行ってしまうかもしれないが、ピークの位置と大きさはほぼ重なっており、少なくともコサイン類似度が高いことには納得できるのではないだろうか。


そう言われてみて遅まきながら気づいたのだが、高次元でコサイン類似度が大きいというのは、実は「めちゃめちゃ似ている」んじゃあないだろうか。
言語処理っぽいことをしてれば、コサイン類似度をクラスタリングとか判別とかに使うわけで、そのとき 0.6 くらいの値しか出ないと、なんか小さいなあとか思っちゃってたけど、 0.6 くらいでも実は「結構かなり似ている」んじゃあないだろうか。


ランダムな2つのベクトルのコサイン類似度はどういう分布になるのだろう。


まず2次元空間で考える。
2次元球の周囲(つまり円)の上で、とりあえず適当なしきい値としてコサイン類似度が 1/2 以上になるのは、それはあるベクトルの±60度の中にもう1つのベクトルが入る場合である。
よって、コサイン類似度>1/2 となる確率は 1/3 だ。


3次元空間だと、3次元球の表面上を考えて、(cosθ>=1/2な面積) / (球の面積) でその確率は 1/4、と少し減る。


4次元以上の一般の n 次元空間でその確率を求めるには一般の n 次元球の表面積(の一部)を計算する必要がある。
ちょっと考えてみたが、めんどくさい方法しか思いつかなかったので、サンプリングで解かせることにした。
1000000 サンプルのうちコサイン類似度が 1/2 を超える割合を求めると、

  • 10 次元 では 0.06 (約 1/17)、
  • 20 次元 では 0.01 (約 1/100)、
  • 30 次元 では 0.0021 (約 1/480)、
  • 40 次元 では 0.00042 (約 1/2400)

と、どんどん少なくなっていき、100 次元 では、1000000個サンプリングした中にコサイン類似度が 1/2 以上になる点はなかった。


こうしてみると、300次元でコサイン類似度が 0.84 とか、もしそれがランダムに取ったベクトルだったなら、宝くじに当たるとか言うレベルの話ではないくらい珍しい現象であることがわかる。


コサイン類似度の分布も見てみよう。
上から 2次元、3次元、4次元、10次元、20次元、30次元、40次元、100次元だ。




2次元ではむしろ ±1 の周辺に多く分布しているのが、高次元になればなるほど、ランダムな2つのベクトルのコサイン類似度は 0 の近辺に大きく偏って集中していくことがよくわかる。
300次元の世界では、適当に取った2つのベクトルはほぼ直交している!


人間は2次元3次元までしか直接的には知覚できないので、どうしても2次元3次元あたりの感覚をそのまま高次元にも当てはめてしまいがちだが(次元の呪いの正体)、この分布を見るとコサイン類似度についてもその感覚が非常に危険であることがよく分かる。
今度からコサイン類似度で 0.6 とかいう値になっても「0.6 しかない」ではなく「0.6 もある!」と思うようにしよう。

岩波データサイエンス Vol.2

岩波データサイエンス Vol.2

「続・わかりやすいパターン認識」13章「共クラスタリング」の無限関係モデル(IRM)の数式について #ぞくパタ

ということを1年近く前につぶやいたりしてたのだが、オーム社のサイトで「続・わかりやすいパターン認識」(以降「ぞくパタ」)の正誤表がちゃんと公開されていることに最近ようやく気づいた。

上のツイートで言っている式 (6.9) ももちろん修正されているし、以下の記事で書いていた8章の問題点もことごとく手当されている。すばらしす。

まあこのツイートやらブログやらを参考にしてもらえたかどうかは定かではないわけだが、どこかで間違いを指摘しておくと反映される可能性がある、というのは勇気づけられる話。


話は変わって、2014/12 から開催されていた「続・わかりやすいパターン認識」読書会が先月めでたく最終回を迎えた、っぽい。

「ぽい」というのは、最後の2回に参加できなかったから。
まあもともと興味のある回にとびとびにしか参加してなかったわけだが、12章後半はある意味ディリクレ過程混合モデルの実装編で、この本のクライマックスだったから是非参加したかった。13章の無限関係モデル(IRM)も一応参加してみたかったところ。


というわけで参加できなかったフォローというか腹いせというか、で無限関係モデルを実装でもしてやろうと思って本を読み始めたのだが……。


まだ読んでいる人が少ないせいだろうか、少なくない数式が結構大胆に間違っている。
まあ、だいたいどの間違いも一目見て間違っていることはわかる(左辺に j がないのに、右辺に消えない j が残っている、とか)ので、抜き打ちの演習みたいなものか。
「これくらい計算できるよね?」という読者への親心を無下にするのも心苦しいが、見つけてしまった間違いはじゃんじゃん指摘してしまおう。


というわけで、この記事はぞくパタ13章の数式の誤りを淡々と指摘するだけの記事であり、IRM(Infinite Relational Model) がなにかわかるような記事ではないので、あらかじめ。


まずは p284 の式 (13.8)。右辺の分母に n が現れているが、実は n なんてどこにも定義されていない。
n_i^1 とか n_{(k,+)(i,j)} とか、そういうややこしいのはいろいろ定義されている*1からだまされるかもしれないが、ワナである。
この n の位置に入るのは、s_k^1 の個数なので正しくは K である。


P(s_k^1=\omega_i^1|{\boldsymbol s}_{-k}^1)=\begin{cases}\frac{n_i^1}{K-1+\alpha}\hspace{3ex}&(\text{existing cluster})\\\frac{\alpha}{K-1+\alpha} & (\text{new cluster})\end{cases}


次は同じ p284 (13.9) 式の新規クラスタのときの式。G_0({\bf\theta}_{i,+}) という記号が出てくる。
11章12章でさんざん見てきたので、ついうっかり知ってる記号だと思ってしまったかもしれないが、これも未定義である。
G_0 は11章12章ではディリクレ過程の基底分布として使われていた記号だが、13章では2次元の構造を持つクラスタを素のディリクレ過程ではモデリングできず、CRP(中華料理店過程)でモデリングされているため、そもそもディリクレ過程自体が出てこない。


「ディリクレ過程だったら基底分布にあたるもの」なら p281-282 にて導入されているベータ分布が相当する。
では G_0 はベータ分布なのだろうと解釈すると (13.9) 式で困ったことになる。


G_0(\theta)={\rm Be}(\theta;a,b)


G_0 はパラメータθ(スカラー)の分布であり、それを束ねた {\bf\theta}_{i,+} (ベクトル)の分布ではないので、G_0({\bf\theta}_{i,+}) という書き方は厳密には間違いとなる。
と、なんかややこしげに書いてしまったが、解決方法は簡単。G_0 じゃなくて単に P({\bf\theta}_{i,+}) と書いて同時分布にしてしまえばいい。厳密に考えても何の問題もなく、当たり障りもない。いや、この本の表記だと小文字 p か。


次、p287 (13.26) 式。左辺に j がないのに、右辺に消えない j が残る。
これは \prod 忘れなので、単純に正解を記そう。(13.9) 式と同じく未定義 n も手当すると、場合分けの式それぞれ次のようになる。


\displaystyle\frac{n_i^1}{K-1+\alpha}\prod_j\frac{B\left(n_{(+,+)(i,j)}+a,\;\tilde{n}_{(+,+)(i,j)}+b\right)}{B\left(n_{(-k,+)(i,j)}+a,\;\tilde{n}_{(-k,+)(i,j)}+b\right)}


\displaystyle\frac{\alpha}{K-1+\alpha}\prod_j\frac{B\left(n_{(k,+)(i,j)}+a,\;\tilde{n}_{(k,+)(i,j)}+b\right)}{B(a,\;b)}


(13.27) 式も同様なので、略。ただし、n は L になる。
もっとも、K-1+α も L-1+α も k や l に依存せず、どうせ全部足して1にするときに消えてしまうから、どちらにせよ実装では省略してしまってよかったりする(笑)。


最後、p288 (13.28)式。 k,l が消えずに残る。これも \prod 忘れ。
例によって未定義 G_0 があるので、これも p(\theta_{ij}) と直してあげつつ、2行目の式だけ正しく書きなおすとこうなる。


\displaystyle =P({\bf s}^1)P({\bf s}^2)\prod_{i=1}^{c^1}\prod_{j=1}^{c^2}\int\prod_{k:s_k^1=\omega_i^1\\l:s_l^2=\omega_j^2}P(R_{kl}|\theta_{ij})p(\theta_{ij})d\theta_{ij}


見つけた間違いはこれで打ち止めだが、2点蛇足。


その1。
この本の積分はちゃんと閉じた形式に計算しつくされており、実装者は自分で計算する必要がほとんどなくてすばらしいのだが、本文最後の積分であるこの \int\prod_{k:s_k^1=\omega_i^1\\l:s_l^2=\omega_j^2}P(R_{kl}|\theta_{ij})p(\theta_{ij})d\theta_{ij} だけは計算されていない。
ここまでの計算が全部できていたらこれくらい朝飯前(誇張抜き)なので、例によって抜き打ち演習として残しておいてもいいんだけど、せっかく全部の積分がやっつけられているのに雑魚一匹だけ残しておくのもなんだよなあ。というわけで、計算してしまおう。


\int\prod_{k:s_k^1=\omega_i^1\\l:s_l^2=\omega_j^2}P(R_{kl}|\theta_{ij})p(\theta_{ij})d\theta_{ij}=\frac{B\left(n_{(+,+)(i,j)}+a,\;\tilde{n}_{(+,+)(i,j)}+b\right)}{B(a,\;b)}


その2。
p288 に「P(s^1), P(s^2) は式 (11.11) のイーウェンスの抽出公式で求める」とある。そういえば 12章でもほぼ同じ文言を見た(p265)。
というわけで式 (11.11)「だけ」で P(s) 類が計算できる……と思ったらこれがワナだったりする。


式(11.11)をよく見てみよう。


P_E(n_1,\cdots,n_c)=\cdots


左辺は P(s) ではなく P(n_1,\cdots,n_c) なのである。実は、P(s) は並べ替えの自由度の分、確率はこれより下がる。
心配しなくても大丈夫、P(s) と P(n_1,\cdots,n_c) の変換式は式 (11.17) としてちゃんと載っている。
というわけで「P(s^1), P(s^2) は式 (11.11) のイーウェンスの抽出公式と式 (11.17) で求める」だと親切である。


と、あれこれ書いたが、当然、ここに書いてあることにも誤りが含まれている可能性はある。もし間違いなどあればご指摘歓迎。
IRM 実装編はまた今度。


【追記】
社内勉強会の資料公開した。

無限関係モデル (続・わかりやすいパターン認識 13章)
https://www.slideshare.net/shuyo/infinite-relational-model

【/追記】

*1:n_i^1n_{(k,+)(i,j)} では数えている対象が異なるので、個人的にはどちらかは m とか記号を変えて欲しかった。