"Psychopathy Prediction Based on Twitter Usage"で1位になりました

6月の終わりに終了したので既に4ヶ月以上前の話だが、kaggleで開催されていたデータサイエンスのコンペティションで1位になった。

• Psychopathy Prediction Based on Twitter Usage - Kaggle

このコンペティションはその名のとおり、twitterの使い方からそのユーザーの"Psychopathy"を予測するというものである。もう一つの Personality Prediction Based on Twitter Stream - Kaggle ではその他の"Personality"の予測を行っていた。

問題は、その予測対象の"Psychopathy"や"Personality"とはいったい何なのかということだが、正直に言って正しく説明できるほど理解できていないため、詳細は以下の記事とそこからリンクされている論文ドラフト*1を参照していただきたい。記事に書かれているが、この論文はICMLA 2012で発表されるそうだ。

• Are you what you Tweet? OPF releases Twitter experiment results | no free hunch
• Predicting Dark Triad Personality Traits from Twitter usage and a linguistic analysis of Tweets（論文ドラフトPDF）

以下は、このコンペティションについて書かれたブログやニュース記事である*2。

• Is Data Science Scary? | no free hunch
• Using Twitter To Identify Psychopaths - Forbes
• Study: Twitter analysis can be used to detect psychopathy (Wired UK)
• Kaggle’s algorithms show machines are getting too good at judging humans | VentureBeat

実際の予測モデルについては、先述した論文ドラフトにも書かれている*3が、gradient boosted treeをbaggingして用いた。具体的には、Random Forestのようにサンプルと特徴量を全体からランダムに一定の割合選択し、Rのgbmパッケージを用いてgradient boosted treeを複数作成、それらの予測値を平均して最終的な予測値とした。主な参考文献は以下。

• Bagging gradient-boosted trees for high precision, low variance ranking models
• BagBoo: a scalable hybrid bagging-the-boosting model

モデルと並んで重要なのは特徴量（素性）だが、こちらは与えられたデータセットに含まられているものを全て用いており、作成や選択などについて特別な前処理は行わず、学習過程で何を用いるかはモデルに任せた。

このように比較的シンプルな手法を用いたため*4、1位になったのは手法が優れていたというよりも、小さめのコンペティションで競争率が高くなかったことと、以下の記事に書かれているように上位陣が過学習を起こしていたことが大きな原因であろう。

• The Dangers of Overfitting or How to Drop 50 spots in 1 minute | no free hunch

このようにあまり複雑なことはしていないため必要ないとは思うが、今回のコンペティションへの参加は完全にプライベートな時間に行っており、私が所属する組織や業務上知りえた知識は用いていないことを念のため記しておく。これについては所属する組織の承認も得ている*5。

このコンペティションで1位になった直後はkaggleのユーザーランキングでも10位以内に入っていたのだが、しばらく放置しているうちにずいぶんと落ちてしまった。時間があればまたコンペティションには参加したいが、業務の方でやりたいことorやるべきことが多いということと、kaggleでコンペティションの開催が閑散期に入ってしまったということから、次の参加はいつになるのかまだ未定。

*1:ACKNOWLEDGEMENTに記述されている所属はなぜか間違っている。

*2:以下の記事でも私の職種に関する記述がなぜか間違っている。

*3:V. MACHINE LEARNING RESULTS

*4:この手のコンペティションでは素性やモデルの種類を変えてモデルを複数作成しそれらをstackingするのが定番であり、もう一つの"Personality"の方でもそうだった。

*5:上司や承認者の皆さんが非常に理解のある方たちで助かった。奨励もしていただいた。

WSDM2012勉強会に参加してきました

WSDM2012勉強会に参加させていただきました。発表資料など詳細は以下にまとまっているようです。主催者、発表者、会場確保・設営をしてくださった皆さま、とても勉強になりました、ありがとうございました。

• WSDM2012勉強会で発表しました #wsdm2012 - nokunoの日記
• WSDM2012読書会を開催しました & Overcoming Browser Cookie Churn with Clustering読んだ - 糞ネット弁慶

実は今回このような形の勉強会に初めて参加したので、感じたことなどを少しメモしておく。

@nokunoさん Finding Your Friends and Following Them to Where You Are

会場では後半、ベストペーパーなのにこんな評価で大丈夫か、という話があった。位置情報をよく有効にしてtweetしているユーザに絞って学習・評価をしているので、そんなものでいいのかという話。誰かが日本用のデータセットを作って公開してくれると面白そう。

@tsubosakaさん Finding the Right Consumer: Optimizing for Conversion in Display Advertising Campaigns

事前に薦められて予習していたので落ち着いて聞くことができた。会場では広告関連の研究は大企業でなければできないのか、という質問があったが、最近は小さな広告配信会社でもad networkを通してユーザを特定できない形で（？）情報を取得できるので、それほど大きくなくてもできるかも、という話だった。広く広告関連の話でいうと、KDD Cup2012のtrack2が"Predict the click-through rate of ads given the query and user information."と検索連動広告のCTRを予測する話なので、少しデータは大きめだが個人でも少し試すということはできると思う。

@y_benjoさん Overcoming Browser Cookie Churn with Clustering

ツールバーの情報を使って評価しているあたりが少し気になるという話があった。結果の図を見ると、提案手法ではprecision1.0でrecallが0.4、precision0.95でrecallが0.53くらいあるので、例えば不正利用者を特定するためなどに使うといいのかなと思った。個人的に気になったのは、最近いろいろ問題になっているスマートフォンに適用しようとすると、同じユーザと端末でもキャリアの回線（3GとかLTE）と自宅や公衆の無線LAN回線でIPが変わるので難しそうだなというところ。OSやブラウザのバージョンも端末標準のものだとそれほどバリエーションがなさそうなので結構同じものになってしまいそう。

@smlyさん When Will It Happen? Relationship Prediction in Heterogeneous Information Networks

いつグラフに新しいエッジができるのかを推定するという話。個人的にはグラフでのリンク予測とかの話を聞くと、Infinite Relational ModelやMarkov logic network関連（Pedro Domings）のStatistical Predicate InventionやSemantic Network Extractorなどのrelationの話を思い出すけど、あまり関係ないかも。

@john_a_dreamsさん Correlating Financial Time Series with Micro-Blogging Data

評価のシミュレーションが、1日の始値で買って終値で全部売るという設定だったので、1日の中でも安値や高値を考えるとどうなるのかという話があった。単純にデータを増やすだけではだめで、やはりデータの質を担保することが大事そうというのがなるほどという気がした。発表を聞いた印象では、質の高いtweetをするユーザを特定する手法と組み合わせると面白そうだなと感じた。

@sleepy_yoshiさん Learning to Rank with Multi-Aspect Relevance for Vertical Search

Learn to Rankで精度を争うのは、SIGIR 2011で発表されたLambdaMART+baggingの手法で一段落したのではないかという発言がとても印象的だった。hinge lossの2乗の形は、いわゆるL2-SVMなどで使われている形（参考: A Dual Coordinate Descent Method for Large-scale Linear SVM）かなと思った。gradientとprojectionの話は昔から使われている古典的な手法ということが話されていた（google:projected gradientで検索すると思っていた以上に古くからある話のようだ）。提案手法はランキングで2つ以上の指標をどう組み合わせるべきか悩む場合は多いと思うので、なかなか適用範囲が広そうだと感じた。ちなみにペアワイズのデータを作るというのはランキング学習だけでなく、positiveデータが少ない場合の分類問題にも効果があるらしい（参考: Detecting Adversarial Advertisements in the Wildの3.2.2）ので、もっと幅広く使われていいのではないかと思う。

その他として、やっぱり聞いているだけよりも発表したほうが面白そうだな、とか、質問に答えてくれたらお礼とかいったほうがいいんじゃないかな、とか、皆PCでいろいろメモしているみたいだったけどあまりハッシュタグつけてtweetとかしないんだな、と思った（職場のストリームに慣れすぎなのかもしれない）。あと、会社内だと具体的な応用方法について話せるんだけど、今回はそれができなかったので少し消化不良な感じが残った。

そんなわけで、近いうちにスピーカーとして勉強会に参加したいところ。

Top-k retrievalのアルゴリズムを書いてみた（tiny topk）

最近top-k retrievalの話を少し聞いたので、簡単にコードを書いてみた。いつものように恥もなくgithubで公開している。

cpp-ToyBox-TinyTopK(github)

Top-k retrievalを簡単に説明すると、転置インデックスに対してdisjunctiveなクエリで問い合わせて（OR検索）スコアの上位k件を取得したいという話である。詳細は"[IR] 転置インデックスとtop-k query - tsubosakaの日記"がとてもわかり易いので、そちらを参照していただきたい。

Top-k retrievalではvector space modelでのdot product（もちろんcosineやBM25なども同様）を考えるので、同じ原理でコサイン距離でのk-nearest neighborや線形分類器のtop-kマルチラベル分類を行うことができたりと、（実用的に使う場面があるかどうかは別として）それなりに適用できる範囲は広いのではないかと思う。

今回のtiny topkは"Evaluation Strategies for Top-k Queries over Memory-Resident Inverted Indexes"と同じように、インデックスを全てメモリ上に載せることを前提としているので、あまり多くのドキュメントを扱えないので注意が必要。posting listを圧縮して持つ実装にすればそれなりの量を扱えるはず。検索アルゴリズムとしてはnaiveなTAAT、naiveなDAAT、WANDを実装した。max_scoreのアルゴリズムも実装してみたかったのだが、ちょうど良さそうなデータ構造が思いつかなかった。

以下、benchmarkディレクトリにあるプログラムで速度を計測した結果である。なおデータとしては手元にあったLIBSVM datasetsのa1aとnews20、rcv1.multiclassを用いた。そのため、実際のドキュメントのデータとは異なり、あまり参考にはならないかもしれない。

$ time ./bench_tinytopk ~/data/a1a.t ~/data/a1a.txt 
document num: 30956, query num: 1605
TAAT    3.354257 sec    2.089880 msec/req
DAAT    29.734377 sec   18.526092 msec/req
WAND    21.928297 sec   13.662490 msec/req

real    0m55.686s
user    0m52.679s
sys     0m2.820s


$ time ./bench_tinytopk ~/data/news20 ~/data/news20.t
document num: 15935, query num: 3993
TAAT    2.894727 sec    0.724950 msec/req
DAAT    40.442991 sec   10.128473 msec/req
WAND    46.316534 sec   11.599433 msec/req

real    1m33.483s
user    1m26.665s
sys     0m6.572s


$ time ./bench_tinytopk ~/data/rcv1_test.multiclass ~/data/rcv1_train.multiclass_1000 
document num: 518571, query num: 1000
TAAT    70.841805 sec   70.841805 msec/req
DAAT    530.754437 sec  530.754437 msec/req
WAND    587.605763 sec  587.605763 msec/req

real    23m47.418s
user    21m32.297s
sys     2m10.936s

全体的に悲しいくらいの速度しか出なかった。三つのアルゴリズムの比較では、naiveなTAATが同じくnaiveなDAATやWANDを大きく引き離す結果となった。DAATとWANDでは各posting listのイテレータが指す中で最小idのドキュメントを探索するためにヒープ木を使っているのだが、そこらへんの実装がいまいちなのかもしれない。DAATとWANDを比較すると、スキップが発生して高速なはずのWANDが三つ中一つのデータでのみ優れた結果となった。こちらもposting listのスキップに、単純にstd::lower_boundを使っているだけのため、実装が残念なだけのような気がする。

int/doubleを文字列に変換する際の速度など

C++でintやdoubleなどの数を文字列（charの配列もしくはstd::string）にしたい時、もしくはその逆で文字列をintやdoubleにしたい時がある。一般的にそのような処理はファイル入出力などと合わせて行われるため、それほど速度を気にすることはなく、むしろ安全な処理を選択することが多いと思う。

そんなわけで、これまではC++のstreamやboost::lexical_castを使っていたのだけれど、これらの時間がかかる処理より速いであろうsnprintfやatoi/strtol、strtodなどとどれほど差があるのかを調べてみた。

以下がざっと書いた速度計測結果。実行は仮想マシン（VMWare）上のUbuntu 11.10で行った。何度か測定したところ細かい誤差はあったが、ある程度の傾向は見えたように思う。単純にintをループ内でインクリメンタルする処理を比較対象とした。また、memcpyでintを単純にバイナリとしてcharの配列にコピーする処理も試してみた。

$ g++ -o bench1 bench1.cpp -O3 -march=native

$ time ./bench1 
int -> str snprintf: 1.556647(+0.621571)
int -> str sstream : 1.575977(+0.640901)
int -> str boost   : 1.587728(+0.652652)
int -> str my_itoa : 1.000906(+0.065830)
str -> int atoi    : 1.133539(+0.198462)
str -> int sstream : 1.711099(+0.776023)
str -> int boost   : 2.245375(+1.310299)
dbl -> str snprintf: 2.106724(+1.171648)
dbl -> str sstream : 3.047715(+2.112639)
dbl -> str boost   : 4.116544(+3.181467)
str -> dbl strtod  : 1.500768(+0.565692)
str -> dbl sstream : 2.616993(+1.681917)
str -> dbl boost   : 3.475305(+2.540229)
memcpy(int)        : 0.953762(+0.018685)
increment          : 0.935076(+0.000000)

real    0m45.122s
user    0m24.250s
sys     0m20.457s

intを文字列に変換する際は、snprintf、std::stringstream、boost::lexical_castの3つではそれほど差は見られなかった。自作のmy_itoaはそれなりに高速だが危険な気がするので使いどころが限られるだろう。逆に文字列からintへの変換はstd::stringstreamやboost::lecical_castと比較してatoiが高速だった。strtol+static_castも試してみたがatoiとほぼ同じ速度だった。

doubleを文字列にする場合、intの場合とは異なり、snprintfが他の二つに比べて高速に動作した。反対に文字列をdoubleとして解釈する場合もstrtodが速い。ただし今回の測定では0.0から1.0の間の数しか扱っていないので、その他の場合どう変化するかは分からない。

少し意外だったのは、int/double両方において、snprintfで数を文字列にするよりもatoiやstrtodで文字列を数に変換するほうが速いということだった（数回計測したがこの傾向は変わらなかった）。

以下計測用いたコード。

DOM Based Content Extraction via Text Densityのbindingを書いたよ

SIGIR 2011のDOM Based Content Extraction via Text Densityが、シンプルなアルゴリズムながら良さそうな結果を示していたので、著者のコードを改変してSWIGでPerlとPythonのbindingを作った。
下手な英文メールにも関わらず、コードの利用を快く認めて下さったFei Sunさん、ありがとうございます！

cpp-ContentExtractionViaTextDensity - GitHub

これは何をするものかというと、タイトルどおり、DOMツリー上でText Densityという指標を用いてウェブページの本文抽出を行うもの。機械学習とかではなく、単純に決められた方法で計算されたText Densityを用いるだけのシンプルなアルゴリズムである。

Text DensityはDOMノードごとに計算され、シンプルにテキストの文字数をタグの数で割ったものである。またComposite Text Densityはアンカータグの数やアンカーテキストの文字数を用いて計算される値も提案されている。著者の書いたコードを見ると、このComposite Text Densityの計算方法はいろいろ試した中からいい結果を選んだようだ。

機械学習を用いた本文抽出の手法としては、「WebDB Forum 2011 で「 CRF を使った Web 本文抽出」を発表してきました - Mi manca qualche giovedi`?」などが最近では話題に上がったのかなと思う。良さそうな素性を考え、データを用意して機械学習すればいいのだが、対象が多岐に渡る場合は学習データを用意するのが面倒なので、この手法やExtractContentのように、学習データが不要でそこそこの結果が得られる手法もそれなりに需要はあるのではないだろうか。逆に言えば、高い精度が必要ならば、対象をある程度制限するか、学習データを何らかの方法で大量に作成する（クラウドソーシングとかユーザのフィードバックとか？）必要があるのかもしれない。

プログラムのビルドや実行にはHTML Tidyやそのbindingが必要。 使い方は、適当にコードやMakefileを見てもらえば何となく分かっていただけると思う。
以下、fetch_and_extract.plを使って得られた、ニュースページで本文抽出の結果のテキスト（抽出結果のDOMに含まれるテキストを単純に連結したもの）。ニュースページは比較的うまく抽出できるが、それでもやはりゴミが混じってしまっている。

IJCAI2011メモ

TwitterでつぶやいたIJCAI2011の論文についてのメモ。全てMachine Learning関連。

Improving Performance of Topic Models by Variable Grouping

Latent Dirichlet AllocationでGibbs samplingを行う際、変数の数が増えるとサンプルを広範囲から取ることが難しくなり、局所解に陥ることがある。そこで、変数をグループ化してサンプリングを効率的に行うという手法を提案していた。同じような考えとしてblock samplingを挙げ、トピックの数が増えた時には変数をグループ化するアプローチの方が効率的であると主張している。

LDAではtoken（文書においては単語が相当）ごとにトピックが割り振られるが、gLDAではグループごとにトピックが割り振られ、各tokenはどのトピックに属するかによって、tokenのトピックが決定される（generativeな説明ではない）。サンプリングも同様に、あるtokenがどのグループに属するかと、あるグループがどのトピックに属するかを考える。同じ種類のtokenは同じグループに属しやすくなるが、必ずしもそうなるわけではない。グループの数の選び方はまだヒューリスティックなもののようだ。image segmentationのAZP、collaborative filteringのBiLDAをそれぞれ上記のようにグループ化したgAZPとgBiLDAが示されていた。

本文を読む限りでは、手軽な方法でよいパフォーマンスを得られているように見えた。

Multi-Label Classification Using Conditional Dependency Networks

大雑把に言うと、マルチラベル分類問題において、それぞれのラベル間の関係も考慮しましょうという話。conditional dependncy networksという名前を聞くと身構えてしまうが、実際の手続きは複雑ではない。各ラベルごとにバイナリ分類器を作成する際に他のラベル情報を用いて学習を行う。単純化すると、他のラベルの情報もfeatureとして用いるということ。ただしこの方法だと予測の際には他のラベルの情報が不明であるため、Gibbs samplingを用いた予測を行う。

バイナリ分類器には確率モデルであるlogistic regressionを用いているが、SVMのような非確率モデルを用いる方法についても述べられている。実験では単純なlogistic regression/SVMとこの手法を適用した場合の比較が行われており、やはりSVMを用いた方がlogistic regressionよりも良い結果を得られていた。

学習は既存の学習器を用いることができるので手軽そうだが、予測には時間がかかりそうである。

Ball Ranking Machine for Content-Based Multimedia Retrieval

pairwiseなランキング学習手法であるRanking SVMをMinimal Enclosing Ballの問題として解くというアイディア。これにより、学習時間とsupport vectorの数を減らすことができると主張している。

SVMをMinimal Enclosing Ballの問題として扱うという部分は、おそらくCore Vector Machinesそのものだと思われる。ランキング学習ではよく線形モデルが用いられるので、線形カーネルSVMであれば高速に解く手法が他にもいくつかあると思うが、この手法ではimageやvideoのランキング学習を対象としており、このような場合はfeatureの性質からカーネルを用いることができる本手法が良さそうな印象を受けた。SVMの高速化手法は数多く提案されており、Ranking SVMとの組み合わせでどのようなパフォーマンスを示すのか気になるところである。

Distribution-Aware Online Classifiers

オンライン分類器であるPassive Aggressive(PA)において、ユークリッド距離ではなくマハラノビス距離を（制約を満たすように）最小化するようにパラメータ更新を行うPassive Aggressive Mahalanobis(PAM)が提案されていた。これによりPAとは異なり、Confidence Weighted(CW) linear classifierのように分散共分散行列が必要になる。

論文中でもPAM2とAdaptive Regularization Of Weight vectors(AROW)との類似性が指摘されているのだが、実験ではPA2とCWとの比較に留まっていたのが気になった。分散共分散行列を対角行列で近似した効率的な計算方法はCWでの知見を適用できると述べられていた。

A General MCMC Method for Bayesian Inference in Logic-Based Probabilistic Modeling

Turing-complete probablilistic modeling languageのPRISMでMCMCを行う手法が提案されていた。PRISMはBayesian networkやPCFGをモデリングすることができる言語であり、explanation graph上で確率計算を行う。提案手法はPCFGでのMetropolis Hastings samplingを一般化してexplanation graph上でサンプリングを行う。

Active Online Classification via Information Maximization

情報量を最大化するようにオンライン分類を行う手法が提案されていた。学習は基本的にNaiveBayesのように頻度カウンティングなので容易なのだが、分類の際に全てのクラスとの情報量を計算する必要があり、計算コストは大きそうである。能動学習は、情報量が最大となるクラスと、二番目に大きくなるクラスの値が少ない時にラベル付けを依頼するというアプローチ。

恐らくInformation Maximization Clusteringの考えをオンライン能動学習に適用したものだと思われる。実験ではPerceptron, PassiveAggressive, AROWとそれぞれのaverage版と比較されていて、全てのデータセットにおいて提案手法が比較的robustであると主張している。ただし比較に用いられている評価指標がマクロ平均なのが少し気になった。実装は比較的容易なようなので、バッチ版を試してみたい。

Learning to Rank under Multiple Annotators

タイトルのとおり、ランキング学習に用いるデータ作成を複数のアノテータが担当する際、各アノテータのラベル付け（クエリとドキュメントのペアに対するスコア付け）の信頼性を考慮しましょうという話。ナイーブなアプローチとしては、まず真のスコアを推定した後にランキング学習を行うという方法が考えられるが、その両方をEMで同時に行う手法が提案されていた。

実験ではラベルにノイズを加えたデータに対する上記の2つの手法と、真のスコアが与えられたときのListMLEが比較されていた。提案手法が真価を発揮するのはAmazon Mechanical Turkなどのクラウドソーシングを用いたときなのかなという印象を受けた。

LIFT: Multi-Label Learning with Label-Specific Features

マルチラベル学習において、各ラベルで学習に用いるfeatureはそのラベル特有なものにしましょうというアイディア。肝心のラベル特有のfeatureは、ラベルに対してpositiveとnegativeのデータをそれぞれk-meansでクラスタリングし、各クラスタの中心とデータの距離のベクトルを用いる。クラスタ数はpositiveとnegativeのデータ数の少ない方に係数をかけた数としている。論文中では距離としてユークリッド距離を用いていたが、もっと洗練されたmetricも考えられると述べられていた。

ラベル特有のfeatureを使うというアイディアはなるほどと思うのだが、クラスタの中心との距離とするのがなぜいいのかはあまりよく理解できなかった。ラベル特有のfeatureを作成した後に用いるバイナリ学習器は任意のものを用いることができ、実験では線形カーネルのLIBSVMが採用されていた。

downhill simplexでNDCG最適化

ここのところ、周囲でランキング学習への興味が高まっているような気がする。

ランキング学習の一手法として、A Stochastic Learning-To-Rank Algorithm and its Application to Contextual Advertisingでは、ランキングの評価指標の一つであるNDCGを最大化するようなパラメータを推定するアプローチを取っている。この手法では、NDCGは微分することができないのでdownhill simplexを用いて最適化を行うのだが、その際に局所解に陥りにくくするためsimulated annealingの考えを取り入れている。

このannealingの部分の具体的なアルゴリズムが良くわからなかったので、単純なdownhill simplexではどれほどの結果が出るか試してみた。

データセットとしては先の論文と同じLETOR 3.0を、パラメータの推定には以下のPerlスクリプトを用いた。

• rank_by_simplex.pl
• DownhillSimplex.pm

それぞれのデータセットのQueryLevelNormのデータを用いた。それぞれのFoldのtrain.txtでNDCG@10を最大化するパラメータを推定し、そのパラメータを用いてtest.txtをランキング、評価した。downhill simplexのパラメータは全て初期値を使ったので、vail.txtは用いていない。

結果評価には配布されている評価ツール（Eval-Score-3.0.pl）を用いた。ただし、そのままでは動作しなかったため、以下の変更を加えている。

$ diff Eval-Score-3.0.pl{.orig,}
193c193
<         if ($lnFea =~ m/^(\d+) qid\:([^\s]+).*?\#docid = ([^\s]+)$/)
---
>         if ($lnFea =~ m/^(\d+) qid\:([^\s]+).*?\#docid = ([^\s]+)/)

以下がTD2004, NP2004, HP2004, OHSUMEDでの結果である。TD2003, NP2003, HP2003は時間の関係上行っていない。他手法の結果はBaselines on LETOR3.0で見ることができる。

印象としては良くもなく悪くもないといったところ。NDCG annealingの具体的な評価値はわからないが、論文のグラフから読み取れる限りでは、やはりannealingを加えることにより、より良い結果を得られているようだ。ただしdownhill simplex単体でも、初期の頂点集合の選び方を賢くやることによってある程度良い値が得られるのではないかと考える。

TD2004

Folds   NDCG@1 NDCG@2 NDCG@3 NDCG@4 NDCG@5 NDCG@6 NDCG@7 NDCG@8 NDCG@9 NDCG@10
Fold1   0.5333 0.4333 0.3774 0.3571 0.3443 0.3286 0.3221 0.3218 0.3045 0.2938
Fold2   0.4667 0.3667 0.3747 0.3787 0.3824 0.3819 0.3672 0.3765 0.3674 0.3558
Fold3   0.4000 0.3667 0.3107 0.2717 0.2682 0.2675 0.2725 0.2828 0.2779 0.2887
Fold4   0.2667 0.2667 0.2986 0.3335 0.3505 0.3353 0.3423 0.3402 0.3476 0.3539
Fold5   0.4667 0.3333 0.3173 0.2880 0.2963 0.2879 0.3036 0.3212 0.3319 0.3257
average 0.4267 0.3533 0.3357 0.3258 0.3283 0.3202 0.3216 0.3285 0.3259 0.3236

Folds   P@1    P@2    P@3    P@4    P@5    P@6    P@7    P@8    P@9    P@10
Fold1   0.5333 0.4333 0.3556 0.3167 0.2933 0.2667 0.2571 0.2583 0.2296 0.2133
Fold2   0.4667 0.3667 0.3778 0.3833 0.3867 0.3778 0.3429 0.3500 0.3259 0.3000
Fold3   0.4000 0.3667 0.2889 0.2333 0.2267 0.2222 0.2286 0.2417 0.2296 0.2400
Fold4   0.2667 0.2667 0.3111 0.3500 0.3600 0.3222 0.3238 0.3083 0.3111 0.3067
Fold5   0.4667 0.3333 0.3111 0.2667 0.2800 0.2667 0.2952 0.3167 0.3259 0.3067
average 0.4267 0.3533 0.3289 0.3100 0.3093 0.2911 0.2895 0.2950 0.2844 0.2733

Folds   MAP
Fold1   0.2015
Fold2   0.2237
Fold3   0.1967
Fold4   0.2290
Fold5   0.2155
average 0.2133

NP2004

Folds   NDCG@1 NDCG@2 NDCG@3 NDCG@4 NDCG@5 NDCG@6 NDCG@7 NDCG@8 NDCG@9 NDCG@10
Fold1   0.2667 0.6000 0.6421 0.7421 0.7421 0.7421 0.7421 0.7421 0.7421 0.7421
Fold2   0.6000 0.6333 0.6674 0.7134 0.7530 0.7659 0.7659 0.7659 0.7659 0.7659
Fold3   0.5333 0.8667 0.8667 0.9000 0.9000 0.9258 0.9258 0.9258 0.9258 0.9258
Fold4   0.6000 0.7333 0.7333 0.7667 0.7667 0.7667 0.7904 0.7904 0.7904 0.7904
Fold5   0.5333 0.6667 0.7508 0.7841 0.7841 0.7841 0.7841 0.7841 0.7841 0.7841
average 0.5067 0.7000 0.7321 0.7813 0.7892 0.7969 0.8017 0.8017 0.8017 0.8017

Folds   P@1    P@2    P@3    P@4    P@5    P@6    P@7    P@8    P@9    P@10
Fold1   0.2667 0.3000 0.2222 0.2167 0.1733 0.1444 0.1238 0.1083 0.0963 0.0867
Fold2   0.6000 0.3333 0.2444 0.2167 0.2000 0.1778 0.1524 0.1333 0.1185 0.1067
Fold3   0.5333 0.4333 0.2889 0.2333 0.1867 0.1667 0.1429 0.1250 0.1111 0.1000
Fold4   0.6000 0.3667 0.2444 0.2000 0.1600 0.1333 0.1238 0.1083 0.0963 0.0867
Fold5   0.5333 0.3667 0.2889 0.2333 0.1867 0.1556 0.1333 0.1167 0.1037 0.0933
average 0.5067 0.3600 0.2578 0.2200 0.1813 0.1556 0.1352 0.1183 0.1052 0.0947

Folds   MAP
Fold1   0.5109
Fold2   0.6742
Fold3   0.7278
Fold4   0.6937
Fold5   0.6619
average 0.6537

HP2004

Folds   NDCG@1 NDCG@2 NDCG@3 NDCG@4 NDCG@5 NDCG@6 NDCG@7 NDCG@8 NDCG@9 NDCG@10
Fold1   0.6000 0.7000 0.7000 0.7833 0.7833 0.8091 0.8091 0.8091 0.8091 0.8091
Fold2   0.6000 0.7333 0.7594 0.7786 0.7786 0.8044 0.8239 0.8239 0.8239 0.8239
Fold3   0.6667 0.8667 0.8667 0.8667 0.8667 0.8667 0.8667 0.8667 0.8667 0.8667
Fold4   0.6000 0.6333 0.7385 0.8052 0.8052 0.8052 0.8052 0.8052 0.8052 0.8052
Fold5   0.4000 0.6333 0.6333 0.6833 0.6833 0.7091 0.7329 0.7329 0.7329 0.7329
average 0.5733 0.7133 0.7396 0.7834 0.7834 0.7989 0.8075 0.8075 0.8075 0.8075

Folds   P@1    P@2    P@3    P@4    P@5    P@6    P@7    P@8    P@9    P@10
Fold1   0.6000 0.3667 0.2444 0.2333 0.1867 0.1667 0.1429 0.1250 0.1111 0.1000
Fold2   0.6000 0.4000 0.2889 0.2500 0.2000 0.1778 0.1714 0.1500 0.1333 0.1200
Fold3   0.6667 0.4667 0.3111 0.2333 0.1867 0.1556 0.1333 0.1167 0.1037 0.0933
Fold4   0.6000 0.3333 0.2889 0.2500 0.2000 0.1667 0.1429 0.1250 0.1111 0.1000
Fold5   0.4000 0.3333 0.2222 0.2000 0.1600 0.1444 0.1333 0.1167 0.1037 0.0933
average 0.5733 0.3800 0.2711 0.2333 0.1867 0.1622 0.1448 0.1267 0.1126 0.1013

Folds   MAP
Fold1   0.6955
Fold2   0.7065
Fold3   0.7731
Fold4   0.7028
Fold5   0.5715
average 0.6899

OHSUMED

Folds   NDCG@1 NDCG@2 NDCG@3 NDCG@4 NDCG@5 NDCG@6 NDCG@7 NDCG@8 NDCG@9 NDCG@10
Fold1   0.3939 0.4242 0.4163 0.4113 0.4025 0.3753 0.3842 0.3786 0.3695 0.3766
Fold2   0.5079 0.4722 0.5136 0.5196 0.4976 0.4886 0.4828 0.4719 0.4685 0.4663
Fold3   0.6349 0.5000 0.4996 0.4786 0.4745 0.4633 0.4555 0.4626 0.4585 0.4497
Fold4   0.5873 0.5476 0.4886 0.4707 0.4633 0.4673 0.4725 0.4741 0.4711 0.4760
Fold5   0.6508 0.6190 0.5886 0.5757 0.5549 0.5394 0.5328 0.5264 0.5115 0.5114
average 0.5550 0.5126 0.5013 0.4912 0.4786 0.4668 0.4656 0.4627 0.4558 0.4560

Folds   P@1    P@2    P@3    P@4    P@5    P@6    P@7    P@8    P@9    P@10
Fold1   0.5455 0.5455 0.5152 0.4773 0.4455 0.3939 0.3961 0.3807 0.3586 0.3591
Fold2   0.6667 0.5952 0.6190 0.6071 0.5619 0.5317 0.5102 0.4881 0.4762 0.4667
Fold3   0.7619 0.6429 0.6508 0.6310 0.6286 0.6111 0.5986 0.5952 0.5714 0.5429
Fold4   0.7143 0.6905 0.6032 0.5952 0.5714 0.5873 0.5850 0.5833 0.5767 0.5810
Fold5   0.7143 0.7143 0.6825 0.7024 0.6667 0.6270 0.6190 0.6131 0.5873 0.5810
average 0.6805 0.6377 0.6141 0.6026 0.5748 0.5502 0.5418 0.5321 0.5140 0.5061

Folds   MAP
Fold1   0.3434
Fold2   0.4488
Fold3   0.4684
Fold4   0.5067
Fold5   0.4631
average 0.4461

2011-08-14追記
HP2003, NP2003, TD2003の結果を追加した。

HP2003

Folds   NDCG@1 NDCG@2 NDCG@3 NDCG@4 NDCG@5 NDCG@6 NDCG@7 NDCG@8 NDCG@9 NDCG@10
Fold1   0.7333 0.7333 0.7438 0.7438 0.7438 0.7438 0.7438 0.7438 0.7649 0.7649
Fold2   0.8333 0.9000 0.8920 0.8920 0.8920 0.8920 0.9039 0.9039 0.9039 0.9039
Fold3   0.8333 0.8667 0.8467 0.8406 0.8650 0.8632 0.8632 0.8632 0.8632 0.8632
Fold4   0.7000 0.8000 0.8210 0.8324 0.8467 0.8467 0.8527 0.8527 0.8527 0.8527
Fold5   0.6000 0.6167 0.6533 0.6699 0.6986 0.6986 0.7031 0.7031 0.7137 0.7137
average 0.7400 0.7833 0.7914 0.7958 0.8092 0.8089 0.8133 0.8133 0.8197 0.8197

Folds   P@1    P@2    P@3    P@4    P@5    P@6    P@7    P@8    P@9    P@10
Fold1   0.7333 0.4000 0.2778 0.2083 0.1667 0.1389 0.1190 0.1042 0.1000 0.0900
Fold2   0.8333 0.5167 0.3444 0.2583 0.2067 0.1722 0.1524 0.1333 0.1185 0.1067
Fold3   0.8333 0.5167 0.3444 0.2583 0.2267 0.1889 0.1619 0.1417 0.1259 0.1133
Fold4   0.7000 0.4500 0.3222 0.2500 0.2067 0.1722 0.1524 0.1333 0.1185 0.1067
Fold5   0.6000 0.3500 0.2667 0.2167 0.1867 0.1556 0.1381 0.1208 0.1111 0.1000
average 0.7400 0.4467 0.3111 0.2383 0.1987 0.1656 0.1448 0.1267 0.1148 0.1033

Folds   MAP
Fold1   0.7489
Fold2   0.8638
Fold3   0.8002
Fold4   0.7671
Fold5   0.6476
average 0.7655

NP2003

Folds   NDCG@1 NDCG@2 NDCG@3 NDCG@4 NDCG@5 NDCG@6 NDCG@7 NDCG@8 NDCG@9 NDCG@10
Fold1   0.4333 0.5333 0.6385 0.6552 0.6695 0.6695 0.6933 0.6933 0.6933 0.6933
Fold2   0.5000 0.6667 0.7298 0.7464 0.7608 0.7608 0.7727 0.7727 0.7727 0.7727
Fold3   0.5667 0.6667 0.7087 0.7254 0.7326 0.7455 0.7692 0.7692 0.7692 0.7792
Fold4   0.6000 0.7667 0.8087 0.8087 0.8087 0.8087 0.8206 0.7873 0.7873 0.7873
Fold5   0.6333 0.6833 0.7569 0.7986 0.7986 0.7986 0.8105 0.8105 0.8105 0.8105
average 0.5467 0.6633 0.7285 0.7469 0.7540 0.7566 0.7732 0.7666 0.7666 0.7686

Folds   P@1    P@2    P@3    P@4    P@5    P@6    P@7    P@8    P@9    P@10
Fold1   0.4333 0.2667 0.2333 0.1833 0.1533 0.1278 0.1190 0.1042 0.0926 0.0833
Fold2   0.5000 0.3333 0.2556 0.2000 0.1667 0.1389 0.1238 0.1083 0.0963 0.0867
Fold3   0.5667 0.3500 0.2556 0.2000 0.1667 0.1444 0.1333 0.1167 0.1037 0.0967
Fold4   0.6000 0.3833 0.2778 0.2083 0.1667 0.1389 0.1238 0.1042 0.0926 0.0833
Fold5   0.6333 0.3500 0.2778 0.2333 0.1867 0.1556 0.1381 0.1208 0.1074 0.0967
average 0.5467 0.3367 0.2600 0.2050 0.1680 0.1411 0.1276 0.1108 0.0985 0.0893

Folds   MAP
Fold1   0.5714
Fold2   0.6427
Fold3   0.6734
Fold4   0.7133
Fold5   0.7230
average 0.6648

TD2003

Folds   NDCG@1 NDCG@2 NDCG@3 NDCG@4 NDCG@5 NDCG@6 NDCG@7 NDCG@8 NDCG@9 NDCG@10
Fold1   0.3000 0.2500 0.2140 0.2019 0.1821 0.1819 0.1817 0.1943 0.2069 0.2138
Fold2   0.3000 0.3500 0.3740 0.3702 0.3435 0.3340 0.3457 0.3345 0.3253 0.3322
Fold3   0.4000 0.2500 0.3055 0.3116 0.3058 0.3238 0.3313 0.3382 0.3512 0.3873
Fold4   0.2000 0.3000 0.3315 0.3536 0.3797 0.3689 0.3607 0.3726 0.3760 0.3727
Fold5   0.6000 0.4000 0.3281 0.2757 0.2462 0.2546 0.2540 0.2537 0.2534 0.2591
average 0.3600 0.3100 0.3106 0.3026 0.2915 0.2926 0.2947 0.2986 0.3026 0.3130

Folds   P@1    P@2    P@3    P@4    P@5    P@6    P@7    P@8    P@9    P@10
Fold1   0.3000 0.2500 0.2000 0.1750 0.1400 0.1333 0.1286 0.1375 0.1556 0.1600
Fold2   0.3000 0.3500 0.3667 0.3500 0.3000 0.2667 0.2571 0.2250 0.2000 0.2000
Fold3   0.4000 0.2000 0.2333 0.2000 0.1600 0.1667 0.1571 0.1500 0.1556 0.1600
Fold4   0.2000 0.2500 0.2333 0.2250 0.2400 0.2000 0.1714 0.1625 0.1556 0.1400
Fold5   0.6000 0.4000 0.3000 0.2250 0.1800 0.2000 0.1857 0.1875 0.1889 0.1900
average 0.3600 0.2900 0.2667 0.2350 0.2040 0.1933 0.1800 0.1725 0.1711 0.1700

Folds   MAP
Fold1   0.1623
Fold2   0.2528
Fold3   0.3392
Fold4   0.2882
Fold5   0.1650
average 0.2415