2017-08-07

ざっくばらんメモ_2：kaggle、ceres::LocalParameterizaion、アジャイル

kaggle zillow challenge

現在のコード

前回までは複数のモデルを学習して得たモデルの予測値の平均（アンサンブル？）を用いていた。

今回はそのアンサンブルするモデルを追加する事にする。

Gaussian Process Regression:メモリエラー、見送り

KNearest Regressor:OKだがとても重い

Kernel Ridge Regression:メモリエラー、見送り

Support Vector Regression:OKだがとても重い

Random Forest:OK

Linear Regression:OK

全てsklearnからのモデルを利用。

パラメータはとりあえず試しなので、基本はデフォルト設定を利用した。

ひとまずOKかつ重くもないRandom ForestとLinear Regressionを加えて

試したところ：0.0677271-> 0.0664433。

OKだが重いモデルも適用したところ0.0659825（やっとサンプルベンチマークを超えられた

Adaboost、GradientBoostも追加したところ0.0655690

次に、stackingを試してみる。

これはベースモデルの予測結果を特徴抽出結果と捉えて入力に加える事で、性能を向上させる手法である。

大雑把な手法は以下である：

１．trainデータをsplitして得たtrain_fold, test_foldの組み合わせに対して、train_foldで

　　訓練したモデルでtest_foldを予測した結果を元のtrainデータに足したものをtrain_meta

　　として保存。これを各ベースモデルに対して行う。

２．続いてtrainデータを全て利用して学習したモデルでtestデータを予測した結果を

　　元のtestデータに足してものをtest_metaとして保存。これを各ベースモデルに対し行う。

３．train_metaへ学習を行い、test_metaへ予測を行った結果を最終結果とする。

ー結果0.0656203でstackingしない時より性能が落ちてしまう。

現状のstackingは2foldで行っていたので、追加して５foldで試してみる。

結果：0.0656738で改善せず。

もしかすると、stackingは今回の問題ではあまり効果がないのかもしれない。

むしろ各月毎に予測しなくてはいけないのに、全て同じ値を用いている方が大きな問題かもしれない。

ceresのLocalParameterization

ceresで良く使われるLocalParameterizationの意味について。

ある対象の状態を定めるパラメータは、最適化時にはoverparameterizedな場合が多い。

例えば３次元空間内で描かれるある球面上に存在する点のパラメータを考えた時、

ある点周りの微小移動に関していえば、その接面上の移動を考えれば十分であり、

法線方向の移動は無視しても問題ない。

その場合、実際に扱う次元は接面上の２次元空間のみであり、最適化がしやすくなる。

こうした考え方を適用可能にするのがLocalParameterizationである。実際は、与えられているパラメータブロックに対して、

微小移動に対する計算を関数として与える事が必要になる。

しかし基本的な微小移動関数はすでに定義されているので、それをただ用いるのが

一番良いやり方ではある。

アジャイル？な開発プロセスについて

twitterか何かに流れていたのだが、

四輪自動車を作成する事を考えた時、直接車の車輪や車体などの部品を作り上げて最後に合体させるのではなく、

まず相対的にシンプルな自転車から初めて、次に二輪自動車、最後に四輪自動車というふうに

発展させていく事が良いという図があった。

たしかに直接四輪自動車の部品を１つ１つ作り上げて合体させる場合、合体させるまで「走る」という機能を

機械に持たせる事ができない。

つまり、実現したい機能が「走る」事に関連している場合、それを最低限実現する機械（自転車）を開発して、

その後は「走る」機能を発展・改善していくプロセスを辿る方が良いという事になる。

これはシステム統合テスト（あるいは早期の市場でのテスト）のしやすさを言っているだと思っているが、

あるいは何か機能（「走る」）を作る時に、それを実現する機械を大きく１つ作れば良いと考えるのではなく、

その機能に関してどのようなユースケースがあるかを全て吟味して、発見したユースケース間をパスを

繋いでいくように細かく作っていく方がビジネス的にチャンスも多く良いという事かもしれない。

研究などにおいても大テーマを小テーマに分割して、各小テーマを論文として量産し食い繋ぎつつ、

最も重要な大テーマに迫っていくというのは良くある話ではある。

2017-07-30

ざっくばらんメモ１：kaggle、脳科学とAI、ゲームとAI

kaggle zillow challenge

ーtruncation

logerrorに対してtruncation、1, 99 percentileでの切り捨てを行う。

結果0.0762954。

続いて他の変数にもtruncationを追加。

追加したのは（finishedsquarefeet12、calculatedfinishedsquarefeet、taxamount）

精度は大きく下がってしまった（0.0762954 -> 0.1232041）

truncationを全く行わない場合：0.2457573。ますます悪くなる。

適度なtruncationが重要？ひとまずlogerrorのみにtruncationを行う。

ーnormalization

normalizationを追加：0.0762954 -> 0.0699197へ改善。normalizationはデフォで追加に。

ーextreme treeとのアンサンブル

extreme treeを使った結果との平均を取るアンサンブルを利用

結果：0.0699197 -> 0.0677271へ改善。

アンサンブルはやはり効果があると思われる。

今後もモデルの追加とstacking, blendingなどのテクニックを追加していくと良さそう。

しかしまだまだ最下位に近いので大きな改善を目指さないときつそうである。

Neuroscience-Inspired Artificial Intelligence

DeepMindのDemis Hassabisが主著者の論文。

ニューロサイエンスとAIの関係性と将来性について述べたもの。

しっかりと読んではいないが、主にDeepMindの研究紹介になっているもよう。

結論の部分が唯一印象に残っていて、

「ニューロサイエンスそれ自体はAIに解を与えるものではないが、そこで観測された現象に対する

アルゴリズム的な興味を与え、AI分野における研究指針を与えるという意味で有用」

というような事を書いているのが面白く感じた。

関連する話として、最近ではCVPR2017であった講演

James J. DiCarlo, The Science of Natural intelligence (NI): Reverse Engineering Primate Visual Perception

にて、画像を一瞬見せてそれが何か分類させるタスクを人にさせた所、

タスクの難易度が上がるほど分類精度を上げるために画像を見せる時間を上げる必要がある事が分かったそうである。

この事実は聴衆をインスパイアしたそうで質問者が殺到していた。

今後はこれに関する研究が増えるのかもしれない。

ただ、すでに幾人かの研究者が同じCVPRで関連研究を提案していた。

例えばアルゴリズムにフィードバック構造をつける事でタスク（の難易度等）に応じて

適応的に推論プロセスを発展させていける構造が提案されている。

ーFeedback Networks、http://feedbacknet.stanford.edu/

ゲームとAIとヒューマンインタラクション

現状のゲームベースの研究でメインなのはAIと環境とのインタラクションな気がしている。

実際学習モデルも環境からのフィードバックを元に行動を決定したりしている。

この環境の部分をもっと直接的に人に変える事はまだまだ難しいのだろうか。

例えばデータに関していえばMMOなどのたくさんの人とAIが入り混じる環境を用いればもっと効率よく

正解データが作り出せる期待がある。

正解データが大量に作り出せる土壌がそろえば、研究はかなりやりやすくなるので、

AIのヒューマンインタラクションをもっと広い土壌で学習できないだろうか。

現状は文書ベースの会話のみに終始しており、ゲーミフィケーションもあまり

聞いたことがない（知らないだけかもしれないが）。

2016-04-02

異常検知のアンサンブル

異常検知、特に教師なし設定における異常検知問題において、アンサンブル手法というものはあまりない。この論文曰く、教師なしの場合、各検知手法の精度評価や各手法毎の多様性についての評価が難しい事が大きな原因らしい。

しかし興味深かったのが、この論文では、大量のラベルなしデータに対し教師なし異常検知モデルを複数学習させて、その出力をデータの特徴量に加えた少量のラベルありデータを用いた教師あり異常検知モデルを学習すると性能が良いとの事であった。

どちらかというとkaggleとかで良くやられているstackingだがblendingだかと似ている。

2016-03-12

Rademacher Complexityの考え方

understanding machine learningに出てくるrademacher complexityの導入がなんかしっくり来た。

まずある分布DよりデータSが与えられた時、representativenessという指標を次のように定義する。

${ \displaystyle \sup_{f \in \mathcal{F}} \hspace{1mm} (L_D (f) - L_S (f) ), }$

${ \displaystyle L_D (f) = E_{z \approx \mathcal{D}} \left[f(z)) \right], L_S (f) = \frac{1}{m} \sum^{m}_{i=1} f(z_i). }$

ここで、Fは仮説クラスHが与えられている時、あるサンプルを入力として損失を出力する写像集合。この指標が０に近いほどデータSによる損失計算が真の分布に基づく損失に迫っているため、正しい評価ができている事になる

ところで真の分布Dは分からないので、実際にこの指標を評価する場合は、交差検定と似たようなノリでデータを切り分けて以下のように近似する。

${ \displaystyle \sup_{f \in \mathcal{F}} \hspace{1mm} (L_{S_2} (f) - L_{S_1} (f) ), }$

S1とS2の切り分け方に関しては、σ1,..,σmを導入しσi=1ならS1、σi=-1ならS2とする。さらにσの値は{1,-1}の２値一様分布からサンプルされると仮定する。すると上の表現はもう少し一般化され次のようになる。

${ \displaystyle \frac{1}{m} E _{\sigma \in \left\{1,-1 \right\}} \left[ \sup_{f \in \mathcal{F}} \sum^{m}_{i=1} \sigma_i f(z_i) \right] }$

これでrademacher complexityが出てくる。

2016-03-12

Rivalry of Two Families of Algorithms for Memory-Restricted Streaming PCA

Rivalry of Two Families of Algorithms for Memory-Restricted Streaming PCAを読む

概要

通常のデータに対するバッチ処理をベースとしたPCAと違い、ストリームデータに対するPCAは、その問題設定から制約があり、従来手法の通りではうまくいかない。

その制約として挙げられるのは主にデータが逐次的に与えられるため、モデルを更新する必要がある事と、リソースの問題でメモリ制約が存在する事、がある。またPCAそのものを評価する場合においても、一般的に再構成誤差のみに注目した評価が行われるが、実際は各主成分がどのように学習されたかについても評価する必要がある。これをスペクトル誤差と呼ぶ。

この問題に対しては２種類のアプローチが存在する。１つ目は確率勾配法に基づいて逐次的に最適化する手法（SPCA）だが、これは主成分が１つの場合のみ収束性が保証されている。２つ目はデータブロック毎にべき乗法に基づき共分散行列のべき乗を求め、それを用いて主成分（固有値）を求める手法である（BPCA）。この時各ブロック毎の経験共分散行列の積により共分散行列のべき乗を近似するのが鍵である。しかしデータブロックサイズを決定する必要があり、それは簡単ではない。

結局のところ、SGDのPCAは一般的な次元における収束の証明がなされておらず、BPCAはブロックサイズが決定できず、実際問題どちらを採用するのが良いのかもわからない。本論では、これら問題に対する対処を提案する。

本論では、１つ目の確率勾配法に基づく手法において、主成分数が１つより多い一般的な場合においても収束性を示す。また２つ目のデータブロックに対するべき乗法においては、ブロックサイズを自動で決定する手法を提案し、その利用によりより良い収束性が得られる事を示す。

どちらの提案手法も基本的なアプローチとして、対象とする共分散行列の固有ベクトル（固有値）をどれだけ効率よく計算できるかを考えている。最適化時における各更新ステップでは、SPCAでは１サンプル毎にSGDの要領に沿って固有ベクトルの推測値を更新し、BPCAでは各ブロックに対して、一度に上記SGDと似た要領で固有ベクトルの推測値を更新する。