Насколько хорошо R масштабируется для текстовых задач классификации? [закрыто]

Я пытаюсь ускорить работу с R. Я в конечном итоге хочу использовать библиотеки R для классификации текста. Мне было просто интересно, что люди думают о масштабируемости R, когда дело доходит до классификации текста.

Я, скорее всего, столкнусь с данными большого размера (~ 300 тыс. Измерений). Я рассматриваю использование SVM и Random Forest, в частности, в качестве алгоритмов классификации.

Будут ли библиотеки R масштабироваться до размера моей проблемы?

Спасибо.

РЕДАКТИРОВАТЬ 1: Просто чтобы уточнить, мой набор данных, вероятно, будет иметь 1000-3000 строк (возможно, немного больше) и 10 классов.

РЕДАКТИРОВАТЬ 2: Поскольку я очень плохо знаком с R, я буду просить плакаты быть более конкретными, где это возможно. Например, если вы предлагаете рабочий процесс / конвейер, пожалуйста, не забудьте упомянуть библиотеки R, участвующие в каждом шаге, если это возможно. Некоторые дополнительные указатели (к примерам, образцу кода и т. Д.) Будут обледенением.

РЕДАКТИРОВАТЬ 3: Во-первых, спасибо всем за ваши комментарии. И во-вторых, я прошу прощения, возможно, я должен был дать больше контекста для проблемы. Я новичок в R, но не так много, чтобы классифицировать текст. Я уже выполнил предварительную обработку (определение стволов, удаление стоп-слов, преобразование tf-idf и т. Д.) Для какой-то части своих данных с помощью пакета tm , просто чтобы почувствовать вещи. tm был настолько медленным даже на 200docs, что я беспокоился о масштабируемости. Затем я начал играть с FSelector, и даже это было очень медленно. И это тот момент, когда я сделал свой ОП.

РЕДАКТИРОВАТЬ 4: Мне только что пришло в голову, что у меня есть 10 классов и около 300 учебных документов на класс, и я фактически строю матрицу termXdoc из всего учебного набора, что приводит к очень высокой размерности. Но как насчет того, чтобы свести каждую задачу классификации 1 из k к серии задач двоичной классификации? Это значительно сократило бы количество учебных документов (и, следовательно, размерности) на каждом из этапов k-1, не так ли? Так этот подход хорош? Как это сравнивается с точки зрения точности с обычной многоклассовой реализацией?

Как и просили в комментарии, вот несколько указателей для этапов обработки. Ряд инструментов можно найти в представлении задач CRAN для обработки естественного языка . Вы также можете захотеть взглянуть на эту бумагу на tm(добыча текста) пакета для R .

1. Перед обработкой рассмотрим нормализацию слова токенов. openNLP(для которого есть пакет R) это один маршрут.
2. Для обработки текста обычным этапом предварительной обработки является нормализация данных через tf.idfтермин «частота * обратная частота документа» - для получения более подробной информации см. Статью в Википедии . Существуют и другие, более недавние нормализации, но это метод с использованием хлеба, поэтому важно знать об этом. Вы можете легко реализовать это в R: просто store (docID, wordID, freq1, freq2), где freq1 - это количество раз, когда слово, проиндексированное wordID, появилось в данном документе, а freq2 - это количество документов, в которых оно появляется. Нет необходимости хранить этот вектор для слов, которые не появляются в данном документе. Затем просто возьмите freq1 / freq2, и вы получите значение tf.idf.
3. После вычисления значений tf.idf вы можете работать с полной размерностью ваших данных или отфильтровывать те слова, которые по существу неинформативны. Например, любое слово, которое появляется только в 1 документе, не даст много понимания. Это может существенно снизить размерность. Учитывая небольшое количество проверяемых документов, вы можете обнаружить, что уместно сокращение только до 1 КБ.
4. Я бы не стал повторно центрировать данные (например, для PCA), но вы можете с легкостью хранить данные в матрице терминов (где записи теперь являются значениями tf.idf), используя разреженные матрицы, как это поддерживается Matrixпакетом.

На данный момент у вас есть хорошо предварительно обработанный набор данных. Я бы рекомендовал продолжить работу с инструментами, указанными в представлении задач CRAN или в пакете интеллектуального анализа текста. Кластеризация данных, например, путем проецирования на первые 4 или 6 основных компонентов, может быть очень интересна для вашей группы при построении данных.

Еще одна вещь: вы можете обнаружить, что уменьшение размерности по принципу PCA (*) может быть полезным при использовании различных методов классификации, так как вы по существу агрегируете связанные слова. Первые 10-50 основных компонентов могут быть все, что вам нужно для классификации документов, учитывая ваш размер выборки.

(*) Примечание: PCA - это только первый шаг. Это может быть очень интересно для кого-то, только начинающего с анализа текста и PCA, но в конечном итоге вы можете обнаружить, что это немного неприятно для разреженных наборов данных. В качестве первого шага, однако, взглянуть на него, особенно с помощью prcompи princompфункций.

Обновление: я не указал предпочтения в этом ответе - я рекомендую, prcompа не princomp.

Во-первых, добро пожаловать! Обработка текста - это очень весело, и делать это в R становится все проще.

Короткий ответ: да - инструменты в R теперь достаточно хороши для работы с такими данными. На самом деле, нет ничего особенного в R, C ++, Groovy, Scala или любом другом языке, когда речь идет о хранении данных в оперативной памяти: каждый язык хранит 8-байтовый двойной разряд с плавающей запятой ... ждите этого ... ждите этого. .. 8 байт!

Алгоритмы и их реализация имеют значение, особенно если они реализованы очень плохо в отношении структур данных и сложности вычислений. Если вы реализуете свои собственные алгоритмы, просто позаботьтесь. При использовании другого кода применяется Caveat emptor, как и в любой среде.

Для R вам необходимо учитывать:

1. Ваше представление данных (посмотрите на разреженные матрицы, особенно в Matrixпакете)
2. Хранение данных (возможно, отображено в памяти, используется bigmemoryили ff; или распределено, используя Hadoop)
3. Ваше разбиение данных (сколько вы можете разместить в оперативной памяти, зависит от того, сколько у вас оперативной памяти)

Последний пункт действительно под вашим контролем.

Когда дело доходит до этой размерности, она больше не особенно велика. Количество наблюдений окажет большее влияние, но вы можете разделить свои данные, чтобы приспособить их к использованию ОЗУ, так что особо беспокоиться не о чем.

Я согласен с crayola, что количество рядов здесь имеет решающее значение. Для RF вам потребуется по крайней мере в 3 раза больше оперативной памяти, чем вес вашего набора данных, и, вероятно, много времени (для такого количества атрибутов обычно требуется много деревьев в лесу - и обратите внимание, что параллельная реализация RF в R отсутствует).

Что касается SVM, я сомневаюсь, что это хорошая идея - бороться с размерами 300 КБ, хотя вы, вероятно, можете разработать функцию ядра, которая будет эквивалентна вашим дескрипторам текста.

РЕДАКТИРОВАТЬ: матрица 3k x 30k (реальная) занимала бы что-то вроде 7Gb, поэтому все, что вам нужно сделать RF (используя randomForest) для этих данных, это компьютер с 16 ГБ ОЗУ, немного удачи и совсем немного времени или просто компьютер с 24 ГБ ОЗУ и совсем немного времени.