Weka проект для задачи распознавания тональности (сентимента)

[romka777]

Спасибо за статью.
Какая производительность этого решения?

[DKey]

Пожалуйста.

После Вашей просьбы я сделал случайную выборку из imdb (positive + negative тексты) и получил такую производительность (после разогрева JVM тем же тестом):

Testing on 1000 samples, 23626 words, 122403 characters...
Time 82 ms.
Speed 1492.719512195122 chars/ms
Speed 288.1219512195122 words/ms

[tezer]

Я бы не советовал использовать такую систему для серьёзых, тем боле коммерческих приложений.
Во-первых, анализ тональности, построенный на машинном обучении, очень зависим от предметной сферы, в которой он был натренирован (так называемая domain-dependency). Более того, даже без смены предметной сферы модели тональности очень быстро устаревают и через, скажем, месяц ваша модель начнёт «чудить». Общая ошибка — верить результатам n-fold cross validation. Да, на том же корпусе результаты будут вполне приемлимые (ок 80%), но к реальной жизни это, увы, никакого отношения не имеет.
Во-вторых, самая большая ошибка сообщать результат по всем трём классам сразу. Обычно нейтральный класс очень многочисленный и самый простой «классификатор», который всё относит к этому классу, легко набирает и 90%. Если у вас корпус сбалансирован по трём классам, то это, скорее всего, очень далеко от жизни — крайне редко мне попадались такие предметные области, где все три класса распределенны одинаково. Как правило, нейтральные высказывания заметно более частотны. Либо наоборот — есть «ругательные» темы, где негатив зашкаливает, а есть «хвалебные» темы, где «солнце, радость, пазитифф»))
Есть, конечно, шанс, что на очень большом корпусе можно обучить систему чему-то полезному, но рзметка такого корпуса обойдётся влетит в копеечку (мягко говоря). Так что если хотите серьёзный анализ тональности, забудьте про машинное обучение. По крайней мере в её классической форме, педставленной здесь уважаемым автором.

[DKey]

Я бы не советовал использовать такую систему для серьёзых, тем боле коммерческих приложений.

Это всего лишь тьюториал по взаимодействию с библиотекой машинного обучения на примере анализа тональности. Kick-start, после которого заинтересовавшиеся пойдут делать более глубокое исследование и ставить эксперименты. А насчёт серьёзных-несерьёзных, я позволю себе поспорить (см. результаты ниже).

Во-первых, анализ тональности, построенный на машинном обучении, очень зависим от предметной сферы, в которой он был натренирован (так называемая domain-dependency). Более того, даже без смены предметной сферы модели тональности очень быстро устаревают и через, скажем, месяц ваша модель начнёт «чудить».

У rule-based систем такая же зависимость и устаревание ;) Вопрос ещё в том, как тренировка происходит. Например, в одной из систем я делал фичи на синтаксических шаблонах и они были более устойчивыми, потому что слова too good или not that bad так быстро не устаревают.

Общая ошибка — верить результатам n-fold cross validation. Да, на том же корпусе результаты будут вполне приемлимые (ок 80%), но к реальной жизни это, увы, никакого отношения не имеет.

По-хорошему, нужно выделять test корпус. Но за неимением оного на kaggle n-fold очень даже подходит. Это всего лишь инструмент, позволяющий определить приблизительное качество на данный момент. Ну в конце концов, можно и глазками качество смотреть, но увы, это не масштабируется.

Во-вторых, самая большая ошибка сообщать результат по всем трём классам сразу. Обычно нейтральный класс очень многочисленный и самый простой «классификатор», который всё относит к этому классу, легко набирает и 90%. Если у вас корпус сбалансирован по трём классам, то это, скорее всего, очень далеко от жизни — крайне редко мне попадались такие предметные области, где все три класса распределенны одинаково. Как правило, нейтральные высказывания заметно более частотны. Либо наоборот — есть «ругательные» темы, где негатив зашкаливает, а есть «хвалебные» темы, где «солнце, радость, пазитифф»))

Хороший верный комментарий. Но ещё раз повторюсь: цель данной статьи не показать прорывной метод для анализа тональности, а продемонстировать работу с библиотекой, ввести маломальскую терминологию и показать отправную точку. Классический такой тьюториал. Если кто-то из уважаемых читателей после этой статьи напишет хороший классификатор, хорошо работающий для их текстов, можно считать задачу выполненной :)

Но я не поленился посчитать распределение меток по классам. Оно действительно неравномерное (явление ожидаемое): позитивных больше, негативных меньше, нейтральные отсутствуют (в силу имплементации):

Added 34345 instances
Of which 27273 positive instances, 7072 negative instances

Я сбалансировал распределение:

Added 14144 instances
Of which 7072 positive instances, 7072 negative instances

и получил ещё лучше качество:

Correctly Classified Instances       11976               84.6719 %
Incorrectly Classified Instances      2168               15.3281 %
Kappa statistic                          0.6934
Mean absolute error                      0.2109
Root mean squared error                  0.3347
Relative absolute error                 42.1894 %
Root relative squared error             66.9461 %
Coverage of cases (0.95 level)          98.1123 %
Mean rel. region size (0.95 level)      78.7719 %
Total Number of Instances            14144

[tezer]

Я понимаю, что тьюториал, понимаю, что kick-start)) Проблема лишь в том, что он, по моему скромному мнению, он не в ту сторону kick делает)
Правила, конечно, тоже могут устареть, но их гораздо легче контроллировать)

[DKey]

Ох, тут тоже буду спорить. Я давно за соединение методов rule-based и машинного обучения, а не за борьбу лагерей.

— Начало философствования. — Правила известны только разработчику или команде людей. И то, как они контролируются и влияют на остальные правила ещё нужно доказать. Поэтому понадобится «золотой» постоянно изменяющийся сет и набор метрик. Плюс золотые глаза, просматривающие проблемные кейсы и исправляющие систему «изнутри».

В машинном обучении можно эффективно (см. научные публикации) использовать, например MTurk и cross-валидацией между аннотаторами добиться отличного корпуса, близкого к экспертной работе. Растущий качественный корпус даёт всё больший охват предметной области. Отсюда растущее качество, контролируемое «извне».
— Конец философствования. —

[tezer]

По поводу MTurk есть большие сомнения. Были жалобы на качество разметки (именно по тональности — уж слишком разные у людей представления о том, что такое «хорошо» и что такое «плохо»). Кроме того, помню корпуса, по которым было где-то только около 20% совпадений между аннонтаторами. Создание корпусов — тот ещё геморрой… А для систем анализа тональности на ML этот геморрой не пройдёт никогда. Это я на своём опыте чётко понял.
Я тоже за мир и дружбу между лагерями, но пока не очень представляю, как их «скрестить». В этой связи было бы интересно почитать про опыты с паттернами в машинном обучении. Правда, их тоже нужно делать гибкими (не регексах, например), и много. Так может получится, что просто сделать правилаполучится дешевле.
Про золотые глаза и касту посвящнных я с не совсем согласен. Эта проблема решается довольно просто — созданием «человеческого» интерфейса у редактора правил. Задаче вполне решаемая и разовая. И да, тестовый корпус нужен. А когда он не нужен, если речь идёт об автоматической обработке текста?
Кстати, как машинное обучение решает названные проблемы? Для поиска ошибок глаз нужен такой же «золотой»… Только понять, как их исправить сможет не всякий, даже не всякий автор такой системы. Потому что копаться в дампе модели и смотреть, какие веса каких фич сыграли свою гадкую роль в дикой ошибке класификации, — занятие не для слабонервных)
И про растущий корпус не согласен)) Расти он, конечно, будет, только лучше он станет (если станет) ой как не скоро… Либо он должен расти пропорционально количеству обрабатываемых данных. А это ОЧЕНЬ дорого.

[DKey]

Представление «хорошо» и «плохо» решается произвольными пересечениями между независимыми аннотаторами. То, что попало в пересечение, наш корпус.

Честно говоря, мне ещё не доводилось видеть лингво-интерфейсы не для лингвистов (опять же, эксперты), которые успешно работают. А сделать нелингвистами корпус как раз можно.

Дебаггинг и там, и там несколько ужасен и приводит в трепет: а не подпортил ли я другой важный кейс?

Но если вернуться к теме статьи, то хочется подытожить, что:

1) задачи компьютерной лингвистики интересные и очень непростые. Но не такие далёкие: на расстоянии вытянутой руки;
2) 100% качественных методов ещё не изобрели, как и сам искусственный интеллект. Но приемлемые методы есть, а иначе как объяснить IBM Watson, вложения Facebook/Google/… в deep learning и то, почему в поиске без лингвистике не обойтись?

Самое главное — пробудить интерес к этой области. Что, надеюсь, хотя бы отчасти, делает эта публикация.

[tezer]

Создание корпуса просто на произвольных пересечениях, конечно, хорошо, но беда в том, что часто аннотаторы, мягко говоря, плевать хотели на задание и описание классов) Найти качественного ответственного аннотатора — тот ещё квест)) Я таких практически любил и готов был на них жениться, лишь бы куда-нибудь не ушли))
И да, за пост спасибо. Написано чётко и ясно. Моё несогласие с рядом тезисов вполне может быть субъективным)
Ждём новых публикаций на эту тему.