Natural Language Processing *

Привет, меня зовут Наталья, я работаю в Яндексе разработчиком в группе извлечения фактов. Весной мы рассказали о том, что такое Томита-парсер и для чего он используется в Яндексе. А уже этой осенью исходники парсера будут выложены в открытый доступ.

В предыдущем посте мы пообещали рассказать, как пользоваться парсером и о синтаксисе его внутреннего языка. Именно этому и посвящен мой сегодняшний рассказ.

Прочитав этот пост, вы узнаете, как составляются словари и грамматики для Томиты, а также, как извлекать с их помощью факты из текстов на естественном языке. Та же информация доступна в формате небольшого видеокурса.

В докладе рассказывается о том, как мы извлекаем сущности (например, имена людей и географические названия) из текстов и запросов. А также об извлечении фактов, т.е. связей между объектами. Мы рассмотрим несколько подходов к решению этих задач: формулирование правил, составление словарей всевозможных объектов, машинное обучение.

Лекция рассчитана на старшеклассников — студентов Малого ШАДа, но и взрослые смогут с ее помощью восполнить некоторые пробелы.

http://video.yandex.ru/users/e1coyot/view/4/

В далеком 2009 году на хабре уже была статья "Кузявые ли бутявки.." про pymorphy — морфологический анализатор для русского языка на Python (штуковину, которая умеет склонять слова, сообщать информацию о части речи, падеже и т.д.)

В 2012м я начал потихоньку делать pymorphy2 (github, bitbucket) — думаю, самое время представить эту библиотеку тут: pymorphy2 может работать в сотни раз быстрее, чем pymorphy (втч без использования C/C++ расширений) и при этом требовать меньше памяти; там лучше словари, лучше качество разбора, лучше поддержка буквы ё, проще установка и более «честный» API. Из негатива — не все возможности pymorphy сейчас реализованы в pymorphy2.

Эта статья о том, как pymorphy2 создавался (иногда с довольно скучными техническими подробностями), и сколько глупостей я при этом наделал; если хочется просто все попробовать, то можно почитать документацию.

Sentiment analysis (по-русски, анализ тональности) — это область компьютерной лингвистики, которая занимается изучением мнений и эмоций в текстовых документах. Недавно на хабре появилась статья про использование машинного обучения для анализа тональности, однако, она была настолько плохо составлена, что я решил написать свою версию. Итак, в этой статье я постараюсь доступно объяснить, что такое анализ тональности, и как реализовать подобную систему для русского языка.

В прошлый раз (почти год назад) мы определяли части речи в русском тексте, производили морфологический анализ слов. В этой статье мы пойдем на уровень выше, к синтаксическому анализу целых предложений.

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

"Мама мыла раму":

(предложение
    (именная гр. (сущ мама))
    (глаг. гр. (глаг мыла)
        (именная гр. (сущ раму)))
    (. .)))

Это называется синтаксическим деревом предложения. В графическом виде его можно представить следующим образом (в упрощенном виде):

Пусть, дано предложение “Съешьте еще этих мягких французских булок, да выпейте чаю.”, в котором нам нужно определить часть речи для каждого слова:

[('съешьте', 'глаг.'), ('еще', 'нареч.'), ('этих', 'местоим. прил.'), ('мягких', 'прил.'), ('французских', 'прил.'), ('булок', 'сущ.'), ('да', 'союз'), ('выпейте', 'глаг.'), ('чаю', 'сущ.')]

Зачем это нужно? Например, для автоматического определения тегов для блог-поста (для отбора существительных). Морфологическая разметка является одним из первых этапов компьютерного анализа текста.

(Части 1, 2, 3) В четвёртой части мы поговорим о проверке грамматики за пределами токенизированных передложений.

Как уже упоминалось, разбиение предложения на токены и POS-разметка уже позволяют создать простой инструмент проверки грамматической корректности текста. По крайней мере, LanguageTool плагин к Open Office работает именно так. Очевидно, что массу ошибок можно выловить на уровне размеченных токенов. Однако также очевидно, что не менее обширные классы ошибок остаются за пределами возможностей нашего модуля. Взять хотя бы такую простую вещь как согласование подлежащего и сказуемого: «дама любил собак», «любил собак дама», «собак дама любил»… как составить паттерн для правила «сказуемое должно иметь тот же род, что и подлежащее?» Даже для английского языка с более-менее чётким порядком слов это трудно, говорить о русском и вовсе не приходится.

(Часть 1, Часть 2) В прошлый раз я преждевременно упомянул токенизацию; теперь можно поговорить и о ней, а заодно и о маркировке частей речи (POS tagging).

Предположим, мы уже выловили все ошибки (какие догадались выловить) на уровне анализа текста регулярными выражениями. Стало быть, пора переходить на следующий уровень, на котором мы будем работать с отдельными словами предложения. Разбиением на слова занимается модуль токенизации. Даже в столь простой задаче есть свои подводные камни. Я даже не говорю о языках вроде китайского и японского, где даже вычленение отдельных слов текста нетривиально (иероглифы пишут без пробелов); в английском или в русском тоже есть над чем подумать. Например, входит ли точка в слово-сокращение или представляет собой отдельный токен? («др.» — это один токен или два?) А имя человека? «J. S. Smith» — сколько здесь токенов? Конечно, по каждому пункту можно принять волевое решение, но в дальнейшем оно может привести к различным последствиям, и это надо иметь в виду.

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

(Часть 1) Сегодня мы поговорим об уровнях понимания текстов нашей системой, о том, какие ошибки правописания отловить просто, какие не очень просто, а какие запредельно сложно.

Начнём с того, что текст можно рассматривать с двух точек зрения: либо как простую последовательность слов, пробелов и знаков препинания, либо как сеть связанных между собой синтактико-семантическими зависимостями понятий. Скажем, в предложении «я люблю больших собак» можно расставить слова в любом порядке, при этом структура связей между словами будет одна и та же:

Читавшие мои предыдущие публикации знают, что пишу я достаточно редко, но обычно сериями. Хочется собраться с мыслями на заданную тему и разложить их по полочкам, не втискивая себя в прокрустово ложе одной короткой статейки.

На сей раз появился новый повод поговорить об обработке текстов (natural language processing то бишь). Я разрабатываю модуль проверки правописания для одной конторы. На выходе должна получиться функциональность, аналогичная встроенной в MS Word, только лучше :) Не могу пока назвать себя крупным специалистом в этой области, но стараюсь учиться. В заметках постараюсь рассказать о том, куда движется наш проект, как устроен тот или иной этап обработки текста. Может, в комментариях услышу что-нибудь новое/интересное и для себя. Если проекту с этого будет польза — прекрасно. Как минимум, устаканю данные у себя в голове, а это тоже неплохо.

(Первые части: 1 2 3 4 5 6 7 8 9). Как говорилось в известной рекламе, «вы не ждали, а мы пришли» :)

За время, прошедшее после публикации девятой части, я прочитал одну хорошую книжку по теме (в to-read списке ещё парочка), множество статей, а также пообщался с несколькими специалистами. Соответственно, накопился новый объём материала, заслуживающий отдельной заметки. Как обычно, знакомлю других, параллельно структурирую знания для себя.

Сразу прошу прощения: эта часть для чтения и понимания достаточно трудна. Ну да, как говорится, не всё коту масленица. Сложным задачам соответствуют сложные тексты :)

(Первые части: 1 2 3 4 5 6 7 8). Да возрадуются минусующие, сегодня представляю вниманию читателей последнюю, по всей видимости, часть «Заметок». Как и предполагалось, мы поговорим о дальнейшем семантическом анализе; также я порассуждаюю немного о том, чем в принципе можно заняться в нашей области и какие есть трудности «научно-политического» характера.

(Первые части: 1 2 3 4 5 6 7). В этой части я расскажу о синтактико-семантическом анализаторе — как я его вижу. Обратите, кстати, внимание на часть 7 — она до главной страницы не добралась, так что не уверен, что все интересующиеся её видели.

(Первые части: 1 2 3 4 5 6). Как и обещал вчера, продолжаем обсуждать XDG и движемся к следующим темам. Возможно, мы двигаемся слишком быстро, и действительно имело бы смысл публиковать одну статью раз в два-три дня, чтобы оставалось время всё обсудить. Но, наверно, пока «бензин есть», я буду продолжать писать. А потом можно будет вернуться и обговорить ранее освещённые вопросы. Мне кажется, что в компьютерной лингвистике разные темы настолько тесно связаны друг с другом, что разговор об одной из них без связи с другими малопродуктивен. А мы ещё не обо всём беседовали, так что лучше охватить взглядом как можно больше аспектов компьютерного анализа текста, а потом уже рассуждать о конкретике в рамках общей картины происходящего.

(Первые части: 1 2 3 4 5). Надеюсь, разговор о естественном языке читателей ещё не утомил! По-моему, тематика действительно интересная (хотя популярность топиков явно идёт на убыль :) ). Что ж, посмотрим, на сколько частей меня ещё хватит. Думаю, экватор мы уже прошли, но три-четыре темы затронуть ещё можно.

На сей раз заметка полностью посвящена проекту XDG/XDK, который я пытаюсь изучать на досуге. Назвать себя специалистом по XDG пока ещё не могу. Но потихоньку двигаюсь.

Что ж, продолжим. (Первые части: 1 2 3 4). Долго выбирал, что будет лучше для следующей темы — пофилософствовать о прагматике языка или поговорить конкретно об алгоритмах разбора. Учитывая, что предыдущая часть была неформальной, решил всё-таки переключиться на конкретику, а там посмотрим.

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

(Начало: 1, 2, 3) На сей раз хочу немного отвлечься и порассуждать (а точнее, похоливарить) на тему статистических алгоритмов и вообще «обходных путей» компьютерной лингвистики.
В первых частях нашего разговора речь шла о «классическом пути» анализа текста — от слов к предложениям, от предложений к связному тексту. Но в наше безумное время появились и соблазны решить проблему «одним махом», найдя, если угодно, баг в системе или «царскую дорогу».

(Начало: 1, 2) Что ж, подходим к самому интересному — разбору предложений. Тема эта многогранна и многоуровнева, так что подступиться к ней не очень просто. Но ведь трудности лишь закаляют :) Да и выходные, текст пишется легко…

Начнём с такого понятия, как синтаксический анализ предложений (по-английски parsing). Суть этого процесса состоит в построении графа, «каким-либо образом» отражающего структуру предложения.

Хотя в первой части я и говорил, что не собираюсь останавливаться на морфологии, видимо, совсем без неё не получится. Всё-таки обработка предложений сильно завязана на предшествующий морфологический анализ.

В преддверии Нового года решил начать небольшой цикл статей, посвящённых наиболее интересующему меня лично направлению в обработке текстов на естественном языке. (То есть NLP в заголовке означает natural language processing — ваш К.О.) Синтаксический анализ, семантика, машинный перевод, поиск смысла слова в контексте — в общем, вся радость компьютерного лингвиста :)

Наверно, сразу имеет смысл определиться с уровнем изложения. Я сам пытаюсь заниматься компьютерной лингвистикой (с переменными успехами). Постараюсь рассказать о том, что конкретно волнует, чего уже можно, чего пока нельзя, и над чем как раз сейчас надо работать. Быть может, эти статьи помогут мне самому отструктурировать информацию в голове и опираться на уже готовую структуру в новом году. А если у читателей появятся свои идеи или мысли о сотрудничестве — ещё лучше.