Rはテキスト分類タスクにどれだけうまく対応できますか？[閉まっている]

私はRの速度を上げようとしています。最終的にはテキストの分類にRライブラリを使用したいと思います。テキストの分類を行う際に、Rの拡張性に関して人々の経験はどうなっているかと思っていました。

高次元のデータ（〜30万次元）に遭遇する可能性があります。特に分類アルゴリズムとしてSVMとランダムフォレストを使用することを検討しています。

Rライブラリは問題のサイズに合わせて拡張できますか？

ありがとう。

編集1：明確にするために、私のデータセットには1000〜3000行（おそらくもう少し）と10のクラスがありそうです。

編集2：私はRに非常に新しいので、可能な限りより具体的になるようにポスターを要求します。たとえば、ワークフロー/パイプラインを提案している場合は、可能であれば各ステップに関係するRライブラリを必ず言及してください。いくつかの追加のポインター（例、サンプルコードなど）がケーキに着氷します。

編集3：まず、あなたのコメントをありがとう。第二に、私は謝罪します。おそらく、この問題についてもっと多くの文脈を与えたはずです。私はRには慣れていませんが、テキストの分類にはそれほど慣れていません。物事の感触をつかむために、tmパッケージを使用して、データの一部で前処理（ステミング、ストップワードの削除、tf-idf変換など）を既に実行しています。tmは約200のドキュメントでも非常に遅いため、スケーラビリティについて心配しました。それから私はFSelectorで遊び始めましたが、それでも本当に遅かったです。そして、それが私がOPを作ったポイントです。

編集4：10個のクラスとクラスごとに約300個のトレーニングドキュメントがあり、実際にはトレーニングセット全体からtermXdocマトリックスを構築しているため、非常に高い次元が発生しました。しかし、すべての1-out-of-k分類問題を一連のバイナリ分類問題に減らすのはどうでしょうか？これにより、k-1の各ステップでトレーニングドキュメントの数（したがって次元数）が大幅に削減されます。このアプローチは良いものですか？精度の点で、通常のマルチクラス実装とどのように比較されますか？

— アンディ
ソース

300k dimensions with how many rows? Unfortunately, R objects must be in memory (at least unless you consider major tweaking, basically requiring you to rewrite these algorithms yourself). That means that with, say, 8 gigs of ram, I don't think you can store more than a few hundred rows with 300k columns.

— crayola

@crayola : Number of rows can vary from 1000-3000.

— Andy

Rオブジェクトはメモリ内にある必要はありません。メモリマッピングは非常に簡単です。300kの寸法は問題ではありません。また、ほとんどすべてのテキストの問題がそうであるように、データがまばらであると思います。

— イテレーター

上記のコメントに気付きました：1000-3000行のみ？それは非常に小さいです。コーパスとは何か説明できますか？メールのバッチ？CRANのパッケージの説明？ストレージの問題よりもP >> Nの方が統計上の問題が多い場合があります。

— イテレーター

@Iterator：分類したい教育リソース（学期論文、エッセイなど）があります。

— アンディ

回答:

As requested in a comment, here are some pointers for processing steps. A number of tools may be found at the CRAN Task View for Natural Language Processing. You may also want to look at this paper on the tm (text mining) package for R.

Prior to processing, consider normalization of the word tokens. openNLP (for which there is an R package) is one route.
For text processing, a common pre-processing step is to normalize the data via tf.idf -- term frequency * inverse document frequency - see the Wikipedia entry for more details. There are other more recent normalizations, but this is a bread and butter method, so it's important to know it. You can easily implement it in R: just store (docID, wordID, freq1, freq2) where freq1 is the count of times the word indexed by wordID has appeared in the given document and freq2 is the # of documents in which it appears. No need to store this vector for words that don't appear in a given document. Then, just take freq1 / freq2 and you have your tf.idf value.
tf.idf値を計算した後、データの完全な次元で作業するか、本質的に情報価値のない単語を除外できます。たとえば、1つのドキュメントにしか表示されない単語はあまり洞察を与えません。これにより、次元が大幅に低下する場合があります。調査対象のドキュメントの数が少ないことを考えると、1Kの次元に縮小することが適切であることがわかります。
データの再センタリング（PCAなど）はしませんが、Matrixパッケージでサポートされているスパースマトリックスを使用して、データを用語マトリックス（エントリは現在tf.idf値）に簡単に保存できます。

この時点で、うまく処理されたデータセットができました。CRANタスクビューまたはテキストマイニングパッケージで引用されているツールを使用することをお勧めします。たとえば、最初の4つまたは6つの主成分に投影することによるデータのクラスタリングは、データがプロットされるときにグループにとって非常に興味深い可能性があります。

もう1つ、PCA（*）に沿った次元削減は、関連する単語を本質的に集約しているため、さまざまな分類方法を使用する場合に役立つことがあります。サンプルサイズを考えると、最初の10-50主成分は、文書分類に必要なものすべてです。

(*) Note: PCA is just a first step. It can be very interesting for someone just starting out with text mining and PCA, but you may eventually find that it is a bit of a nuisance for sparse data sets. As a first step, though, take a look at it, especially via the prcomp and princomp functions.

Update: I didn't state a preference in this answer - I recommend prcomp rather than princomp.

— Iterator
ソース

+1 Nice answer; I'm only curious why do you say that small number of docks imply lower number of important variables -- doesn't it seem a bit overfitty?

I'm not sure I understand what you mean. To keep them is overfitting, certainly, so these variables would be eliminated in any reasonable regularization. Moreover, vocabulary (P) grows with # of documents or samples (N), so the first time a term appears is not indicative of much. Keep adding docs and then recurrence of a term across docs will become informative.

— Iterator

@Iterator : Thanks for your answer. So prcomp and/or princomp will scale to this kind of data you reckon? Also I just edited my question and added some additional information.

— Andy

No, these likely won't scale when you hit 300K columns. :) (Just to point out: X'X in that case will have 90B entries - a storage problem.) Instead, filter by tf.idf first. If there are only, say, 10 distinct classes, then a small multiple of 10 should be adequate for a larger dimensionality for separating the classes. So, 1000 dimensions should be more than enough. Both PCA methods (btw, I recommend prcomp) will be fine.

— Iterator

Once you limit to 1000 dimensions or perhaps a few more (e.g. 2K), and do PCA, you may take the projections onto say 100 dimensions (which may be overkill, but there's little harm in this) and then do classification. At this point, there's nothing too exciting going on.

— Iterator

First, welcome! Text processing is lots of fun, and doing it in R is getting easier all the time.

The short answer: yes - the tools in R are now quite good for dealing with this kind of data. In fact, there's nothing special about R, C++, Groovy, Scala, or any other language when it comes to data storage in RAM: every language stores an 8 byte double float in...wait for it...wait for it... 8 bytes!

特にデータ構造と計算の複雑さに関して非常に不十分に実装される場合、アルゴリズムとその実装は重要です。独自のアルゴリズムを実装する場合は、注意してください。他のコードを使用する場合は、他の環境と同様に、注意事項が適用されます。

Rについては、以下を考慮する必要があります。

データ表現（特にMatrixパッケージ内のスパース行列を見てください）
データストレージ（おそらく、Hadoop を使用してマップされた、bigmemoryまたはff;または分散されたメモリ）
データのパーティション化（RAMにどれだけ収まるかは、RAMの容量に依存します）

最後のポイントは本当にあなたの管理下にあります。

When it comes to this dimensionality, it's not particularly big anymore. The # of observations will be more of an impact, but you can partition your data to adjust for RAM usage, so there's not really much to get too worried about.

— Iterator
ソース

I agree with crayola that the number of rows is crucial here. For RF you will need at least 3x more RAM than your dataset weights and probably a lot of time (such number of attributes usually requires a lot of trees in the forest -- and note that there is no parallel implementation of RF in R).

About SVM, I doubt it is a good idea to fight with 300k dimensions while you probably can develop a kernel function that will be equivalent to your descriptors of text.

EDIT: 3k x 30k (real) matrix would occupy something like 7Gb, so all you need to do RF (using randomForest) on this data is a computer with 16GB RAM, some luck and quite a bit of time or just a computer with 24GB RAM and quite a bit of time.

Well I was certainly going to do feature selection (chi squared, entropy based) but again I could not find any R library that would scale for this task either. Taking all this into account, is it correct then to say that perhaps I should start looking at non-R solutions?

— Andy

"note that there is no parallel implementation of RF in R". That is only partially correct, as the foreach package plays nicely with the randomForest package. I think there is one such example in the vignette for foreach. (Or maybe doMC.)

— crayola

@Andy The thing is, short of rewriting the algorithms in a low level programming language, I'm not sure what software will be able to apply these algorithms to your data. If I were in your situation, I guess I would stick to R and rewrite parts of randomForest such that it would query the randomly chosen columns from, for example, an SQL database at each iteration (such that the whole 300k dimensions wouldn't ever have to be in ram). But that's probably mainly because I know more about R than about the other possible options.

— crayola

What do you precisely mean by claiming you couldn't found a library that would scale for that? Filters like this are basic algebra they should work without problems (provided you have enough RAM).

@crayola True, but the merging part is awful. Moreover it is not shared-mem parallelism, so it would be probably painful (if not impossible) in this setting.