Заставить парсер Stanford CoreNLP отдавать приоритет метке S на корневом уровне

Приветствую вас, эксперты НЛП!

Я использую программный пакет Stanford CoreNLP для анализа группы интересов, используя самую последнюю версию (3.9.2) англоязычных моделей JAR, загруженную с Страница загрузки CoreNLP. Я получаю доступ к парсеру через интерфейс Python из модуля NLTK nltk.parse.corenlp. Вот отрывок из верхней части моего основного модуля:

import nltk
from nltk.tree import ParentedTree
from nltk.parse.corenlp import CoreNLPParser

parser = CoreNLPParser(url='http://localhost:9000')

Я также запускаю сервер, используя следующий (довольно общий) вызов из терминала:

java -mx4g -cp "*" edu.stanford.nlp.pipeline.StanfordCoreNLPServer
-annotators "parse" -port 9000 -timeout 30000

Парсер, который CoreNLP выбирает по умолчанию (когда доступна полная английская модель), является парсером Shift-Reduce (SR), который иногда утверждается, что он более точен и быстрее, чем синтаксический анализатор CoreNLP PCFG. Что касается импрессионизма, я могу подтвердить это на собственном опыте, когда я имею дело почти исключительно с текстом Википедии.

Тем не менее, я заметил, что часто синтаксический анализатор ошибочно выбирает синтаксический анализ того, что на самом деле является полным предложением (то есть конечным матричным предложением), вместо этого в качестве вспомогательной составляющей, часто NP. Другими словами, синтаксический анализатор должен выводить S метку на корневом уровне (ROOT (S ...)), но что-то в сложности синтаксиса предложения подталкивает синтаксический анализатор к утверждению, что предложение не является предложением (ROOT (NP ...)) и т. Д.

Анализ таких проблемных предложений также всегда содержит другую (обычно явную) ошибку ниже по дереву. Ниже приведены несколько примеров. Я просто вставлю несколько верхних уровней каждого дерева, чтобы сэкономить место. Каждое из них является вполне приемлемым английским предложением, поэтому синтаксический анализ должен начинаться с (ROOT (S ...)). Однако в каждом случае вместо S используется какая-то другая метка, а остальная часть дерева искажается.

НП: По оценкам, из-за простуды ежегодно пропускается 22–189 миллионов учебных дней. (ROOT (NP (NP An estimated 22) (: --) (S 189 million school days are missed annually due to a cold) (. .)))

FRAG: Более трети людей, обращавшихся к врачу, получили рецепт на антибиотик, что может повлиять на устойчивость к антибиотикам. (ROOT (FRAG (NP (NP More than one-third) (PP of people who saw a doctor received an antibiotic prescription, which has implications for antibiotic resistance)) (. .)))

UCP: кофе - это сваренный напиток, приготовленный из обжаренных кофейных зерен, семян ягод определенных видов Coffea. (ROOT (UCP (S Coffee is a brewed drink prepared from roasted coffee beans) (, ,) (NP the seeds of berries from certain Coffea species) (. .)))

Наконец, вот мой вопрос, который, как я полагаю, доказывает, что приведенные выше данные являются полезными: Учитывая, что мои данные содержат незначительное количество фрагментов или иным образом неправильно сформированных предложений, как я могу наложить ограничение высокого уровня на синтаксическом анализаторе CoreNLP, так что его алгоритм дает приоритет назначению узла S непосредственно под ROOT?

Мне любопытно узнать, излечит ли такое ограничение при обработке данных (которое известно, чтобы удовлетворить его) и другие мириады болезней, наблюдаемых в произведенных синтаксических анализах. Насколько я понимаю, решение заключается не в указании ParserAnnotations.ConstraintAnnotation. Было бы это?


person tarskiandhutch    schedule 27.11.2018    source источник


Ответы (1)


Вы можете указать, что определенный диапазон должен быть отмечен определенным образом. Таким образом, вы можете сказать, что весь диапазон должен быть на букве «S». Но я думаю, что это нужно делать в Java-коде.

Вот пример кода, который показывает установку ограничений.

https://github.com/stanfordnlp/CoreNLP/blob/master/itest/src/edu/stanford/nlp/parser/shiftreduce/ShiftReduceParserITest.java

person StanfordNLPHelp    schedule 03.12.2018
comment
Спасибо, @StanfordNLPHelp. Последующий вопрос: действительно ли введение такого ограничения заставит синтаксический анализатор повторно взвесить все свои варианты, чтобы весь синтаксический анализ изменился соответствующим образом? Или он просто выдаст тот же синтаксический анализ, заменив верхний узел меткой «S»? (Последнее, конечно, также можно было бы сделать постфактум, просто отредактировав вывод синтаксического анализа; это не то, что меня интересует.) - person tarskiandhutch; 12.12.2018
comment
Я думаю, он возвращает наиболее вероятный синтаксический анализ, соответствующий ограничению - person StanfordNLPHelp; 13.12.2018
comment
Хорошо, так что, по-видимому, первое. Еще раз спасибо, @StanfordNLPHelp. - person tarskiandhutch; 17.12.2018
comment
К сожалению, эта стратегия не улучшает эти синтаксические анализы. Я, наконец, реализовал указанное ограничение, и результат точно такой же, за исключением того, что узел S был вставлен между узлом ROOT и остальной частью результата без ограничений. То есть для примера с кофе исходный синтаксический анализ был (ROOT (UCP (S) (,) (NP) (.))) - теперь это (ROOT (S (UCP (S) (,) (NP)) (.))). Для справки, мое ограничение: ParserConstraint constraint = new ParserConstraint(0, sentenceLength, "S"); - person tarskiandhutch; 14.01.2019