Представление «хорошо» и «плохо» решается произвольными пересечениями между независимыми аннотаторами. То, что попало в пересечение, наш корпус.
Честно говоря, мне ещё не доводилось видеть лингво-интерфейсы не для лингвистов (опять же, эксперты), которые успешно работают. А сделать нелингвистами корпус как раз можно.
Дебаггинг и там, и там несколько ужасен и приводит в трепет: а не подпортил ли я другой важный кейс?
Но если вернуться к теме статьи, то хочется подытожить, что:
1) задачи компьютерной лингвистики интересные и очень непростые. Но не такие далёкие: на расстоянии вытянутой руки;
2) 100% качественных методов ещё не изобрели, как и сам искусственный интеллект. Но приемлемые методы есть, а иначе как объяснить IBM Watson, вложения Facebook/Google/… в deep learning и то, почему в поиске без лингвистике не обойтись?
Самое главное — пробудить интерес к этой области. Что, надеюсь, хотя бы отчасти, делает эта публикация.
Ох, тут тоже буду спорить. Я давно за соединение методов rule-based и машинного обучения, а не за борьбу лагерей.
— Начало философствования. — Правила известны только разработчику или команде людей. И то, как они контролируются и влияют на остальные правила ещё нужно доказать. Поэтому понадобится «золотой» постоянно изменяющийся сет и набор метрик. Плюс золотые глаза, просматривающие проблемные кейсы и исправляющие систему «изнутри».
В машинном обучении можно эффективно (см. научные публикации) использовать, например MTurk и cross-валидацией между аннотаторами добиться отличного корпуса, близкого к экспертной работе. Растущий качественный корпус даёт всё больший охват предметной области. Отсюда растущее качество, контролируемое «извне».
— Конец философствования. —
Я бы не советовал использовать такую систему для серьёзых, тем боле коммерческих приложений.
Это всего лишь тьюториал по взаимодействию с библиотекой машинного обучения на примере анализа тональности. 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
После Вашей просьбы я сделал случайную выборку из 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
Мне кажется, чтобы спорить с сохранением достоинства и уважения к собеседнику, нужно отойти от агрессии и спокойно разобраться в терминах. В формальном представлении естественного языка выделяют уровни: от графематического, к уровню слов, далее уровень словосочетаний (вроде прил.+сущ.), потом синтаксис, который в некоторых работах тесно связан с семантикой, далее прагматика. Продолжать в обе стороны можно сколько угодно и предлагать подчас ортогональные подходы и видения. Здесь намерено пропущены многие детали, вдруг они сподвигнут читающего эти строки заглянуть поглубже в литературу.
Но так или иначе есть упомянутая прагматика. Когда Вы приводите пример с «Размер определяет замер», под этим есть прагаматика. tlando (и я здесь присоединюсь) честно призналась, что не знает, что из этого главнее. Почему так? Просто потому, что ни она, ни я не владеем базой знаний по этому конкретному предмету. Знание может выражаться как в формальном виде, например, мы могли бы узнать это в учебном заведении на лекции, либо в неформальном, например, если бы эту фразу часто произносили в нашем детстве. Но во фразе «Мать любит дочь», если опустить интонационную окраску (а её отстутствие нередкость в печатном или оцифрованном тексте), то вполне разумно допустить, что Мать — субъект, а дочь — объект предложения (т.е. мать главнее). Это допущение разумно в силу принятого порядка слов в русском языке + некоторого языкового чутья, которое каждый из нас приобрёл в силу того или иного уровня образования.
А теперь представьте, что перед Вами стоит задача научить систему (парсер) корректно распознавать такие случаи. Что же делать? Один из подходов — гоняться за правдой и «догнав» её (например, во сне), вбить это в свою систему, чтобы затем претендовать на беспрекословную правильность. А можно выдавать все варианты (и мать любит, и дочь). Что получается в этом случае? Очевидная вещь. Сложность прагматической резолюции смысла перетекает в систему, которая будет пользоваться выводом Вашего парсера. Вы, как создатель, парсера, заверите своих клиентов, что обманывать не собираетесь и решаете только задачу синтаксического разбора. А Ваши клиенты будут думать дальше, в зависимости от задачи, которую решают. Выбор сугубо за Вами, как за создателем.
Как говорят в английском, point is, что многое зависит от задачи, которую перед собой ставите вы, как создатель парсера.
добавлю, что несмотря на все неоднозначности при сравнительной оценке парсеров, конкурс был весьма полезным с точки зрения проверки систем на большом корпусе предложений: порядка 60 тысяч. Это даёт основания делать более статистически устойчивые оценки, чем при тестировании в «герметичных условиях».
Надеюсь, конкурс продолжится и улучшится в следующем году и будет представлено больше разнообразных систем!
Наш проект SemanticAnalyzer Group здесь. См. демо + Проект на основе синтактико-семантического анализатора по машинному переводу: MTEngine (проекту нужны волонтёры, приходите, будет интересно :) ).
основа: правила и словарь Зализняка. Эта система не ставит задачей выявить верную часть речь и другие характеристики. Она даёт все возможные (известные алгоритму) варианты.
То, что делаете Вы, больше похоже на попытку сделать разбор предложения по составу, т.е. синтаксис.
К сожалению, в приведенной статье говорят не об этом. В новом релизе ввели баг, из-за которого могут неверно скомпилироваться циклы. А это делает нестабильным не только софт больших компаний
А в итоге — ваш магазин физически присутствует где?
Поясню свой первый вопрос, я его задал специально в «чайниковсоком» варианте. Вопрос касается user interface. Задача авторов таких сервисов сделать так, чтобы за первые 10 секунд стало понятно, что это. Как здесь: vark.com/ask. Задать или ответить на вопрос. Всё. Если я захочу узнать детали (а прежде этого мне нужно заинтересоваться, вот почему нужна лаконичность дизайна), то я полезу вглубь.
У вас хороший, eye-candy дизайн, но не хватает лаконичности. Это, конечно, моё мнение, как пользователя, а не эксперта.
Честно говоря, мне ещё не доводилось видеть лингво-интерфейсы не для лингвистов (опять же, эксперты), которые успешно работают. А сделать нелингвистами корпус как раз можно.
Дебаггинг и там, и там несколько ужасен и приводит в трепет: а не подпортил ли я другой важный кейс?
Но если вернуться к теме статьи, то хочется подытожить, что:
1) задачи компьютерной лингвистики интересные и очень непростые. Но не такие далёкие: на расстоянии вытянутой руки;
2) 100% качественных методов ещё не изобрели, как и сам искусственный интеллект. Но приемлемые методы есть, а иначе как объяснить IBM Watson, вложения Facebook/Google/… в deep learning и то, почему в поиске без лингвистике не обойтись?
Самое главное — пробудить интерес к этой области. Что, надеюсь, хотя бы отчасти, делает эта публикация.
— Начало философствования. — Правила известны только разработчику или команде людей. И то, как они контролируются и влияют на остальные правила ещё нужно доказать. Поэтому понадобится «золотой» постоянно изменяющийся сет и набор метрик. Плюс золотые глаза, просматривающие проблемные кейсы и исправляющие систему «изнутри».
В машинном обучении можно эффективно (см. научные публикации) использовать, например MTurk и cross-валидацией между аннотаторами добиться отличного корпуса, близкого к экспертной работе. Растущий качественный корпус даёт всё больший охват предметной области. Отсюда растущее качество, контролируемое «извне».
— Конец философствования. —
Это всего лишь тьюториал по взаимодействию с библиотекой машинного обучения на примере анализа тональности. Kick-start, после которого заинтересовавшиеся пойдут делать более глубокое исследование и ставить эксперименты. А насчёт серьёзных-несерьёзных, я позволю себе поспорить (см. результаты ниже).
У rule-based систем такая же зависимость и устаревание ;) Вопрос ещё в том, как тренировка происходит. Например, в одной из систем я делал фичи на синтаксических шаблонах и они были более устойчивыми, потому что слова too good или not that bad так быстро не устаревают.
По-хорошему, нужно выделять test корпус. Но за неимением оного на kaggle n-fold очень даже подходит. Это всего лишь инструмент, позволяющий определить приблизительное качество на данный момент. Ну в конце концов, можно и глазками качество смотреть, но увы, это не масштабируется.
Хороший верный комментарий. Но ещё раз повторюсь: цель данной статьи не показать прорывной метод для анализа тональности, а продемонстировать работу с библиотекой, ввести маломальскую терминологию и показать отправную точку. Классический такой тьюториал. Если кто-то из уважаемых читателей после этой статьи напишет хороший классификатор, хорошо работающий для их текстов, можно считать задачу выполненной :)
Но я не поленился посчитать распределение меток по классам. Оно действительно неравномерное (явление ожидаемое): позитивных больше, негативных меньше, нейтральные отсутствуют (в силу имплементации):
Я сбалансировал распределение:
и получил ещё лучше качество:
После Вашей просьбы я сделал случайную выборку из imdb (positive + negative тексты) и получил такую производительность (после разогрева JVM тем же тестом):
Но так или иначе есть упомянутая прагматика. Когда Вы приводите пример с «Размер определяет замер», под этим есть прагаматика. tlando (и я здесь присоединюсь) честно призналась, что не знает, что из этого главнее. Почему так? Просто потому, что ни она, ни я не владеем базой знаний по этому конкретному предмету. Знание может выражаться как в формальном виде, например, мы могли бы узнать это в учебном заведении на лекции, либо в неформальном, например, если бы эту фразу часто произносили в нашем детстве. Но во фразе «Мать любит дочь», если опустить интонационную окраску (а её отстутствие нередкость в печатном или оцифрованном тексте), то вполне разумно допустить, что Мать — субъект, а дочь — объект предложения (т.е. мать главнее). Это допущение разумно в силу принятого порядка слов в русском языке + некоторого языкового чутья, которое каждый из нас приобрёл в силу того или иного уровня образования.
А теперь представьте, что перед Вами стоит задача научить систему (парсер) корректно распознавать такие случаи. Что же делать? Один из подходов — гоняться за правдой и «догнав» её (например, во сне), вбить это в свою систему, чтобы затем претендовать на беспрекословную правильность. А можно выдавать все варианты (и мать любит, и дочь). Что получается в этом случае? Очевидная вещь. Сложность прагматической резолюции смысла перетекает в систему, которая будет пользоваться выводом Вашего парсера. Вы, как создатель, парсера, заверите своих клиентов, что обманывать не собираетесь и решаете только задачу синтаксического разбора. А Ваши клиенты будут думать дальше, в зависимости от задачи, которую решают. Выбор сугубо за Вами, как за создателем.
Как говорят в английском, point is, что многое зависит от задачи, которую перед собой ставите вы, как создатель парсера.
Надеюсь, конкурс продолжится и улучшится в следующем году и будет представлено больше разнообразных систем!
Статья про сравнение парсеров тут.
слайды здесь.
брат брату брат
зомби зомби зомби
задачка на определение «других характеристик»
P.S. Это всё можно отнести к «вырожденным случаям» статистически, конечно. Но учитывать их стоит, хотя бы для понимания сложности задач nlp.
То, что делаете Вы, больше похоже на попытку сделать разбор предложения по составу, т.е. синтаксис.
Если идти от статистики, то есть ещё одна система (PhD thesis):
www.cis.hut.fi/projects/morpho/
semanticanalyzer.info/blog/demo/
Поясню свой первый вопрос, я его задал специально в «чайниковсоком» варианте. Вопрос касается user interface. Задача авторов таких сервисов сделать так, чтобы за первые 10 секунд стало понятно, что это. Как здесь: vark.com/ask. Задать или ответить на вопрос. Всё. Если я захочу узнать детали (а прежде этого мне нужно заинтересоваться, вот почему нужна лаконичность дизайна), то я полезу вглубь.
У вас хороший, eye-candy дизайн, но не хватает лаконичности. Это, конечно, моё мнение, как пользователя, а не эксперта.