RBM学習結果の可視化

MNIST文字画像データを与えて、エッジの重みを可視化するというのをやってみました。

自分で書いたjuliaのコードは学習がうまくいかなかったので、「ゆるふわ Restricted Boltzmann Machine」のコードでやってみました。

実行結果

(step1)

(step2)

(step5)

(step10)

(step50)

気になること

  • それっぽい出力ではあるけど、deep learning tutorialにあるこの画像と違う
  • 「ゆるふわ」さんのコードを実行すると僕の書いたJuliaより数十倍実行速度が速い

何が原因なのか、引き続き調べてみます。

近況

  • 安宅和人著「イシューからはじめよ」が最近のバイブル
    • 実作業する前に「意味のあるゴール」を決める習慣づけ
  • アドテク
    • Rでモデリング
      • CTR/CVR予測
      • ブランド・カテゴリ選好度の数値化
    • （純広告2.0的な）大手メディア向けSSP
      • オウンドメディアCMSとネイティブ広告エクスチェンジ
      • 代理店からツール利用料を徴収し、メディアにデータ使用料をバック
    • コンサル業務は粛々と。一千万円超の案件の提案資料作ったりとか
    • あとは知人の事業の手伝いでアフィリエイトサーバ作ったりとか
  • Kaggle
    • サブミット３回くらい。まだベースラインを超えられず。
      • 工夫したのはベースライン手法との切り替え判断をNNで学習とか
  • ポーカーの思考エンジン
    • openholdembotのインストール途中まで
    • banditアルゴリズムの実験場として使う
  • Deeplearning
  • グリッドコンピューティング
    • WebCL+WebWorkerのサンプル作ってみた
    • SAP/HANAやQlickView的なことをその辺のPCで
    • DeeplearningをJuliaで一通りできたらWebCL化
  • 有限要素法
    • FreeFEM++インストールとサンプル実行してみた
    • ソボレフ空間のさわりを少し
    • FEM使ったアプリの企画
      • 音の合成：楽器の物理シミュレータ
      • ストレス解消：カメラで撮る→仮想世界で壊す
      • 調理レクチャ：魚の焼き方とかをリアルに
  • 分子動力学
    • GROMACSインストールしてマニュアル読み中
    • アルゴンの沸点を計算するのが最初の目標
    • ナノテク調べた。人工光合成と電池開発をやりたい
  • センサーデータマイニング / Intener Of Things
    • スマホアプリの企画
      • 万歩計（歩数とか消費カロリーとか姿勢推定とか）
      • 環境音チェッカー(ストレス度xx％とか出てくる)
  • 統計や機械学習の理論の勉強
    • フィッシャー情報量とか十分統計量とか
    • もう少しで渡辺澄夫先生の本が読めそう
  • ベイズ
    • BUGS Book買ってちょっとずつ読み進めてる。
  • その他
    • ベルタランフィ著「一般システム理論」買った。GWに読む。
    • Topcoderは最近SRMが無いのでやってない。

I hate those who involve in "passive arguments", but ...

たまに見かける嫌いな人のタイプ。

こちらが何か具体的な例を挙げると、

「それって端的にいうとどういうことです？」

と具体例の吟味をせずに抽象論をリクエスト。

逆にこちらが抽象的な命題を持ち出すと

「たとえば？」

とすかさず具体例の提示をリクエスト。

こういう人と議論すると、抽象化と具体化の行き来がキャパシティを超えて、匙を投げたような形で相手に議論をあずけたくなっちゃいそうになるけど、それだと嫌なので、僕はこういう人と話すときは自分の頭の体操だとおもって、すべてのリクエストを打ち返す。

相手に振り回されながら抽象論と具体例を行き来することで、僕の頭はどんどん鍛えられていくのだ。

ブランド選好度のベイズ推定（ざっくり）

ブランディングの数値化に向けてWinBUGSを使ったtoy modelを作ってみた。ECサイトの商品購入ログからユーザのブランド選好度を確率分布として出す、というもの。

RとWinBUGSのコード一式はChiral's Gistに置いてあります。

モデル化

商品閲覧/購入ログがN個あり、i番目のログが、

  • x_{i,1} : 価格, スカラー量（ドル）
  • x_{i,2} : 対象ブランドの有無, 0 or 1
  • y_i : 購入したかどうか, 0 or 1

で表されているとする。

で、商品購入モデルを

  • y_i \sim Bernoulli(p_i)
  • logit(p_i) = a + b_1*x_{i,1} + b_2*x_{i,2}

と仮定する。

見ての通りベイズロジスティック回帰モデルです。b_1が価格への反応度で、b_2がブランドへの反応度を表す。aはオフセットを補正する的なもの。

実験

極端な２つのデータセットを考える。

  • データセットA: ブランド選好度が高そうなAさん
  • データセットB: バーゲンセールが好きそうなBさん

以下のようなダミーデータを手で作った。(N=10)

i 1 2 3 4 5 6 7 8 9 10
価格 100 120 90 100 80 70 200 100 150 110
ブランド 0 1 0 1 0 0 1 0 0 0
購入(Aさん) 0 1 0 1 0 1 1 1 0 0
購入(Bさん) 1 0 1 0 1 1 0 0 1 1

結果

パラメータ推定結果。まずブランド好きな人のデータセットA

価格への反応度(b[1])がマイナスに振れて、ブランド反応度(b[2])がプラスに振れている。ワシは金に糸目は付けん！ブランドじゃ！！と言わんばかりですね。

続いてお買い得重視な人のデータセットB

データセットAとは逆にブランド反応度（b[2]）はマイナスに振れています。価格反応度はゼロ付近で、オフセット(a)がプラスに振れてますね。
これはこのモデルが誤差項を含まず、偶然の変動成分を全部オフセットに押し付けているせいでそうなったんじゃないかな。

というわけで

「そうなるモデルにそういうデータを与えたらそう推定された」というトートロジー感にあふれるエントリでしたが、これを改良していって実データを使ってぜひモデルの洗練化などやってみたいです。

ダミーデータのtoy modelで出来ることとしては、これを階層ベイズモデルにするというのがありそう。最初階層ベイズモデルを試してみたのですがオーバーフローしたり収束しなかったりと、何も考えずにいると動かないことが分かったのでとりあえずシンプルな１階層のベイズロジスティック回帰でやりました。

続きが出たらまた書きます。ある程度のところで製品化（有料のWebAPIサービス）したいです。まだまだよちよち歩きという感じですが、ドメイン特化型のデータドリブンマーケティングという事業をやりたい。

出した実績や成果以上に知識とスキルがあることは恥ずかしい

僕は勉強することがすごく好きなので時間があるとつい色んなものを学んでしまう。

それで人生がとても充実するし、なるべく業務に遠からぬ分野を学ぼうとしているので精神的な安定にもつながっている。

しかし、今日オフィスまでの道を歩きながら、ふと思った。

「知識やスキルがあるということは、恥ずかしいことなのではないか？」

人生の時間は有限だ。だから知識やスキルの蓄積に時間を使うと、そのぶん成果や実績を出すのに使う時間が減ってしまう。

もちろん、実績を出しながらスキルを付けられる状態が最高だ。「実績を伴わない練習や訓練はスキルとは呼べない」という厳しい話もあるくらいだ。

そうはいっても、知識が増えるということは本当に面白いし、やめられないんだよなぁ。。

「ソフトウェアを作るのが意外と難しい」理由を再説明してみる

トラックバック＆感想。

これ共感しますね。

このテーマ、僕も一家言ぶちたい願望があるので、ちょっと僕の言葉で言い換えてみます。

ソフトウェア以外にも顧客の注文なり社会的な要請なりを受けて創造されるものってあると思います。

  • CMの音楽を作曲する
  • 美術館を建造する
  • 注目があつまるフェルマー予想を証明する

といった感じに。

作曲の場合、発注者が作曲家にリクエストする内容はどんな感じでしょうか。納期と予算はまずあって、ウキウキする感じ、とか荘厳な感じとか、ポップな感じとか、曲の長さとかクライマックスがこの辺にくるとか、使う楽器とかは専門的なのであまり注文つけられないかな、とか、そういう感じでしょうか。ざっくりとしたリクエストを投げて、いくつか作ってもらってイメージに合うものを採用するというプロセスをふむと思います。

美術館の建造でしたら、予算と納期、ロケーションと広さ、建立の背景、所蔵する美術品、管理する学芸員はどんな人たちかとか、想定客はどういう人かとか、そういう感じでしょうか。

フェルマー予想はそもそも予想したのがフェルマーという数学者なので要請の発端がすでに専門家です。ただ有名なので一般人も巻き込んで注目が集まっていた。これについては作り方（証明の仕方）に注文を付けるのはかなり難しいでしょう。

さて、ソフトウエアの開発は上記の作曲、建築、数学（の定理証明）と同様に「専門知識にもとづく制約がついて回る度合い」がかなり強いものだと思います。中でも数学はとくにそうですけど、ソフトウェア開発もその数学がもつ制約の強さに似たものがあると思います。

建築はパース図のような完成イメージ図を事前に共有したりしますが、ソフトウェアもGUIレベルではモックアップやデザインカンプの共有は可能です。しかし機能的な振る舞いということになると、事前に共有するのはとても難しい。それこそ図ではなく言葉で認識の一致を確認するしかないですが、そうすると上記記事にあるとおりソフトウェアの振る舞いを表現するボキャブラリが双方に要ることになります。それは発注者が専門家ではない場合は難しいです。

そして、ソフトウェア開発の難しさと面白さは、作曲と建築と数学がもつ難しさと面白さのそれぞれをちょっとずつ持っているところにあるとも思います。

作曲における「感性とスコアが一体」という性質は、ソフトウェアにおけるユーザビリティと機能の関係と近いです。

建築における「物理的制約下での設計」という性質は、ソフトウェアももとはハードウェアという物理系の上で動かす現象ですから物理的制約が入ったうえで目的のものをビルドアップするという共通性があります。

数学がもつ「個別具体的な厳密さと抽象化」という性質は、ソフトウェアにおいても、厳密なビット演算に従って演繹的に動作するというコンピュータの普遍的な基礎があったうえで目的の抽象的なタスクを実現しなければならないという本質があるので、同様について回る性質でしょう。

これらをまとめて言い表すとしたら、「トップダウンがボトムアップに依拠するタスク」ということになると思います。

ディレクションというのはトップダウンです。注文を付ける、リクエストを投げるというのもトップダウンです。そのトップダウンのプロセスが、ボトムアップの制約から自由に解き放たれているタスクであれば問題ないですが、ここで挙げた３つのタスクやソフトウェア開発というタスクはその制約がかなり強いため、ディレクターとスタッフの間のコミュニケーションが非常に重要です。

ただ、人工知能技術が発展して、このあたりの状況が一変する可能性も十分あると思われるので、そうなったときにソフトウェア（すなわち人工知能）を作る側の立場でいられるように引き続き頑張っていきたいです。