Наскільки R масштабує завдання для класифікації тексту? [зачинено]

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

Я, швидше за все, зіткнувся з великими розмірними даними (~ 300k розмірів). Я дивлюся на використання SVM та Random Forest, зокрема, як алгоритми класифікації.

Чи може R бібліотеки масштабуватися до мого розміру проблеми?

Спасибі.

EDIT 1: Просто для уточнення, мій набір даних може мати 1000-3000 рядків (можливо, трохи більше) та 10 класів.

EDIT 2: Оскільки я дуже новачок у R, я попрошу плакати, де це можливо, бути більш конкретними. Наприклад, якщо ви пропонуєте робочий процес / трубопровід, будь ласка, обов'язково вкажіть R бібліотеки, які беруть участь у кожному кроці, якщо це можливо. Деякі додаткові вказівники (на приклади, зразок коду тощо) будуть глазур'ю торта.

EDIT 3: По-перше, дякую всім за ваші коментарі. По-друге, я вибачаюся, можливо, я мав би дати більше контексту для проблеми. Я новачок у R, але не стільки в класифікації тексту. Я вже зробив попередню обробку (стримування, видалення стоп-слова, перетворення tf-idf тощо) на моїй частині моїх даних за допомогою пакету tm , просто щоб зрозуміти щось. Тм був настільки повільним, навіть приблизно на 200документах, що я переймався масштабуванням. Тоді я почав грати з FSelector і навіть це було дуже повільно. І це той момент, коли я зробив свій ОП.

EDIT 4: Мені просто прийшло в голову, що я маю 10 класів і близько ~ 300 навчальних документів на клас, і я фактично будую матрицю termXdoc з усього навчального набору, що призводить до дуже високої розмірності. Але як щодо зведення кожної проблеми класифікації 1-з-к до ряду проблем бінарної класифікації? Це значно зменшило б кількість навчальних документів (і, отже, розмірність) на кожному з етапів k-1, чи не так? Тож такий підхід хороший? Як вона порівнюється за точністю зі звичайною багатокласовою реалізацією?

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

1. Перед обробкою розглянемо нормалізацію лексем слова. openNLP(для якого є пакет R) - один маршрут.
2. Для обробки тексту загальним кроком попередньої обробки є нормалізація даних через tf.idfтермін "* зворотна частота документа" - детальніше див. Запис у Вікіпедії . Існують і інші більш новітні нормалізації, але це метод хліба з маслом, тому важливо це знати. Ви можете легко реалізувати його в R: просто зберігати (docID, wordID, freq1, freq2), де freq1 - це кількість разів, коли слово, індексоване wordID, з’явилося в даному документі, а freq2 - це # документ, в якому він з’являється. Не потрібно зберігати цей вектор для слів, які не відображаються в даному документі. Тоді просто візьміть freq1 / freq2 і у вас є ваше значення tf.idf.
3. Після обчислення значень tf.idf ви можете працювати з повною розмірністю даних або відфільтрувати ті слова, які по суті є неінформативними. Наприклад, будь-яке слово, яке відображається лише в одному документі, не дасть великого розуміння. Це може значно зменшити розмірність. Враховуючи невелику кількість досліджуваних документів, ви можете виявити, що доцільно зменшити розміри до 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 байт!

Алгоритми та їх реалізація мають значення, особливо якщо вони реалізовані дуже погано стосовно структур даних та складності обчислень. Якщо ви реалізуєте власні алгоритми, просто подбайте. Якщо використовується інший код, застосовується емпатор застереження, як це робиться в будь-якому середовищі.

Для R вам потрібно буде врахувати:

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

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

Що стосується цієї мірності, то вона вже не особливо велика. # Спостережень матиме більший вплив, але ви можете розділити свої дані для адаптації до використання оперативної пам’яті, тому насправді не надто турбуватися.

Я погоджуюся з Crayola, що кількість рядків тут має вирішальне значення. Для РФ вам знадобиться щонайменше в 3 рази більше оперативної пам’яті, ніж вага вашої набору даних, і, мабуть, багато часу (така кількість атрибутів зазвичай вимагає багато дерев у лісі - і зауважте, що паралельна реалізація РФ у R немає).

Щодо SVM, я сумніваюся, що це гарна ідея боротися з розмірами 300k, тоді як ви, мабуть, можете розробити функцію ядра, яка буде еквівалентна вашим дескрипторам тексту.

EDIT: Матриця 3k x 30k (реальна) займала б щось на зразок 7Gb, тому все, що вам потрібно зробити RF (використовуючи randomForest) за цими даними, - це комп'ютер з 16 Гб оперативної пам’яті, трохи удачі та зовсім небагато часу або просто комп'ютер з 24 ГБ ОЗУ і зовсім небагато часу.