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

30

Я пытаюсь ускорить работу с 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, не так ли? Так этот подход хорош? Как это сравнивается с точки зрения точности с обычной многоклассовой реализацией?

Энди
источник
1
300k размеры с сколько строк? К сожалению, объекты R должны находиться в памяти (по крайней мере, если вы не планируете серьезную настройку, в основном требующую от вас переписать эти алгоритмы самостоятельно). Это означает, что, скажем, с 8 гигабайтами оперативной памяти, я не думаю, что вы можете хранить более нескольких сотен рядов с 300-тысячными колонками.
crayola
@crayola: количество строк может варьироваться от 1000 до 3000.
Энди
2
Объекты R не должны быть в памяти. Отображение памяти очень просто. 300к габариты не проблема. Я также предполагаю, что ваши данные редки, так как это имеет место почти со всеми текстовыми проблемами.
Итератор
Я только что заметил комментарий выше: только 1000-3000 строк? Это очень мало. Можете ли вы объяснить, каков ваш корпус? Пакет писем? Описания пакетов в CRAN? У вас может быть больше статистических проблем с P >> N, чем с какими-либо проблемами хранения.
Итератор
1
@Iterator: у нас есть некоторые образовательные ресурсы (курсовые работы, эссе и т. Д.), Которые мы хотим классифицировать.
Энди

Ответы:

17

Как и просили в комментарии, вот несколько указателей для этапов обработки. Ряд инструментов можно найти в представлении задач 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.

Итератор
источник
+1 Хороший ответ; Мне только любопытно, почему вы говорите, что небольшое количество доков подразумевает меньшее количество важных переменных - не кажется ли это слишком подходящим?
Я не уверен, что понимаю, что вы имеете в виду. Сохранять их - это, конечно, переобучение, поэтому эти переменные будут исключены при любой разумной регуляризации. Кроме того, словарный запас (P) увеличивается с количеством документов или образцов (N), поэтому первый раз, когда термин появляется, не очень много указывает. Продолжайте добавлять документы, и тогда повторение термина в документах станет информативным.
Итератор
@Iterator: Спасибо за ваш ответ. Так prcompи / или вы princompбудете масштабировать данные такого рода? Также я только отредактировал свой вопрос и добавил дополнительную информацию.
Энди
Нет, они, скорее всего, не будут масштабироваться при попадании в столбцы 300К :) (Просто чтобы указать: в этом случае X'X будет иметь записи 90B - проблема с хранилищем.) Вместо этого сначала отфильтруйте по tf.idf. Если существует только, скажем, 10 различных классов, то небольшого, кратного 10, должно быть достаточно для большей размерности для разделения классов. Итак, 1000 измерений должно быть более чем достаточно. Оба метода PCA (кстати, я рекомендую prcomp) будут в порядке.
Итератор
После того, как вы ограничите 1000 измерений или, возможно, еще несколько (например, 2K), и проведете PCA, вы можете взять проекции, скажем, на 100 измерений (что может быть излишним, но в этом мало вреда), а затем выполнить классификацию. На данный момент ничего особенного не происходит.
Итератор
5

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

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

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

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

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

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

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

Итератор
источник
3

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

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

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


источник
Ну, я определенно собирался сделать выбор функций (хи-квадрат, основанный на энтропии), но опять же я не смог найти библиотеку R, которая бы подходила для этой задачи. Учитывая все это, правильно ли тогда говорить, что, возможно, мне следует начать искать решения без R?
Энди
1
«Обратите внимание, что нет параллельной реализации RF в R». Это только частично правильно, поскольку foreachпакет хорошо сочетается с randomForestпакетом. Я думаю, что есть один такой пример в виньетке для foreach. (Или, может быть doMC.)
crayola
@ Энди Дело в том, что если не считать переписывания алгоритмов на языке программирования низкого уровня, я не уверен, какое программное обеспечение сможет применять эти алгоритмы к вашим данным. Если бы я был в вашей ситуации, я бы предпочел придерживаться R и переписать части так randomForest, чтобы он запрашивал случайно выбранные столбцы, например, из базы данных SQL на каждой итерации (так, чтобы все измерения размером 300 Кб никогда не имели бы быть в баране). Но это, вероятно, в основном потому, что я знаю больше о R, чем о других возможных вариантах.
crayola
Что именно вы имеете в виду, утверждая, что вы не можете найти библиотеку, которая бы подходила для этого? Подобные фильтры - это базовая алгебра, они должны работать без проблем (при условии, что у вас достаточно ОЗУ).
@crayola Правда, но объединяющаяся часть ужасна. Более того, это не параллель с разделением и записью, так что в этом случае это может быть болезненно (если не невозможно).