Комментарии 39
Также мы проанализировали проблему взаимосвязи пунктуации и парсинга и пришли к выводу, что в нашем случае пунктуацию перед синтаксическим парсингом лучше удалять.
А как в таких случаях быть с «казнить нельзя помиловать»?
Если в речи это может обозначено небольшой паузой, то в письменном тексте нет.
Спасибо, отличный вопрос. Я так понимаю, речь идёт о конкретном примере — количественный ответ дан в табличке.
Во-первых, таких примеров, как следует из таблички, не то чтобы много, так что это немножко утрированный пример.
Во-вторых, в отсутствие пунктуации наш главный помощник — порядок слов. Можно надеяться, что выбор парсером того, что все-таки нельзя делать, будет основан на том, в каком порядке обычно идут зависимые от «нельзя» инфинитивы в обычных текстах.
Пунктуация, если она, конечно, установлена верно, четко обозначает заложенный в текст смысл. Вы же ее полностью удаляете и полагаетесь на авось то, как обычно используются слова в предложениях. Я могу вам гарантировать определенный процент неверного распознавания.
Все проценты (не)верного распознавания указаны в таблице выше (последней таблице выше).
А вообще — зависит от того, как с пунктуацией в ваших текстах и соответствует ли она тому, на чём происходило обучение.
Если вы обучаетесь на правильных текстах, а работаете на «неправильных» (где пунктуации нет или где она расставлена неверно, это, к сожалению, в веб-текстах происходит сплошь и рядом) — то числа показывают, что в таком случае пунктуация скорее мешает из-за несоответствия трейна и теста.
Если же вы работаете на правильных текстах — то она будет вам помогать, опять же см. ту же табличку.
А вообще — зависит от того, как с пунктуацией в ваших текстах и соответствует ли она тому, на чём происходило обучение.
Если вы обучаетесь на правильных текстах, а работаете на «неправильных» (где пунктуации нет или где она расставлена неверно, это, к сожалению, в веб-текстах происходит сплошь и рядом) — то числа показывают, что в таком случае пунктуация скорее мешает из-за несоответствия трейна и теста.
Если же вы работаете на правильных текстах — то она будет вам помогать, опять же см. ту же табличку.
Текст без знаков пунктуации — это мусор. Но всё зависит от поставленной задачи. Если задача — разбирать простые предложения, без причастных оборотов, без вложенностей, без обращений, без прямой речи, без цитат — то наверное можно обойтись простейшим парсером.
api.ispras.ru
Случайно отправил одну ссылку, щас еще заминусят)
Вообще вопрос синтаксического анализа русского языка весьма интересен, хотелось бы видеть отдельные статьи о проблематике анализа.
Ссылка выше — разработка ИСПРАНʼа — российского института
Случайно отправил одну ссылку, щас еще заминусят)
Вообще вопрос синтаксического анализа русского языка весьма интересен, хотелось бы видеть отдельные статьи о проблематике анализа.
Ссылка выше — разработка ИСПРАНʼа — российского института
Ну вот я раскрыл, что мог.
Разработку глянул, спасибо, жаль, нет никаких деталей — это обученная модель? Если да, то как обучалась? Или просто сборник примеров из синтагруса, размеченных руками?
Отдельно обидно, что разметка осталась из синтагруса в исходном формате разметки, хотя можно воспользоваться версией синтагруса в conllu
Разработку глянул, спасибо, жаль, нет никаких деталей — это обученная модель? Если да, то как обучалась? Или просто сборник примеров из синтагруса, размеченных руками?
Отдельно обидно, что разметка осталась из синтагруса в исходном формате разметки, хотя можно воспользоваться версией синтагруса в conllu
«директора пришли на встречу»
Даже тут можно найти целых два контекста :)
Это может быть как «директорА (они) пришли на встречу», так и «дирЕктора пришли на встречу (сам он идти не хотел, вот его и «пришли»)».
вообще да )
хотя второй все-таки ненормативный, вряд ли такое будет в обучающем корпусе
хотя второй все-таки ненормативный, вряд ли такое будет в обучающем корпусе
Еще более частая вариация реально встречающаяся в жизни — «дирЕктора ушли», т.е. его уволили. В этой фразе может быть как прошлое время, так и повелительное наклонение.
kirdin как в этом случае будет рассматриваться повелительное наклонение без знака "!"? Восклицательный или вопросительный знак заменяется на концевую точку?
kirdin как в этом случае будет рассматриваться повелительное наклонение без знака "!"? Восклицательный или вопросительный знак заменяется на концевую точку?
не понял. Форма «ушли», очевидно, не является формой повелительного наклонения.
Повелительное наклонение от «уйти» — это «уйди» или «уйдите».
По поводу замен на концевую точку. UDPipe-токенизатор (равно как и прочие описанные в посте токенизаторы) берут на вход сырой текст и токенизируют его, ничего не меняя. Так что меняться ничего не будет даже в предложении типа «директор, уйди».
Повелительное наклонение от «уйти» — это «уйди» или «уйдите».
По поводу замен на концевую точку. UDPipe-токенизатор (равно как и прочие описанные в посте токенизаторы) берут на вход сырой текст и токенизируют его, ничего не меняя. Так что меняться ничего не будет даже в предложении типа «директор, уйди».
директора «пришли» на встречу — вот в таком виде вполне подходит ваш 2-й вариант.
Одному мне кажется, что сбербанк занимается все время, чем то не тем?
Зададим небольшое предложение: «Переведи маме сто рублей». Результат заставляет схватиться за голову.
С «мамой» поинтереснее: «мама» оказалась в предложном падеже и стала вершиной этого предложения.
А не в дательном?
>Однажды нам понадобилось выбрать синтаксический парсер для работы с русским языком
Вот удивительно — но нам тоже :) При этом у нас немного специфические данные, а именно адреса, которых много (десятки миллионов минимум).
Вы возможно спросите, зачем тут NLP? Если в двух словах, то тут все просто — адреса надо сравнивать, искать по ним, геокодировать, в общем — работать с ними. И если с задачей нормализации (и далее сравнения) как-то справляется Фактор, то с геокодированием все хуже. Вот типичный пример — ArcGIS успешно находит в своих справочниках улицу 8 Марта в Москве, но категорически не хочет находить улицы 3 Интернационала (коих множество в нашей стране). Зато находит улицу 3-го Интернационала. Не находит улицу «имени академика Н.И.Вавилова», но знает про существование просто «улицы Вавилова» в том же городе. Очень просто сделать из 3-го просто 3, но обратная задача уже требует понимания, к чему именно в предложении относится числительное (например, 3-я улица Строителей).
С другой стороны, чтобы собрать из слов «шоссе» и «Энтузиастов» и «Варшавское» «шоссе» полный адрес, в котором порядок слов будет различным, нужно знать, в какой форме у нас слова Энтузиастов и Варшавское.
В общем, это немного специфичная, но все же вполне задачка типа NLP. При этом данные большие, поэтому в качестве инструмента Spark. Соответственно, инструмент хочется на Java/Scala, в крайнем случае — PySpark (хотя тут уже мороки с интеграцией в имеющиеся модели на Java будет многовато).
В итоге в вашем тексте лично мне категорически не хватило технических деталей. Скажем, платформы, на которой это все работает (я только про Stanford знаю, что это Java, и даже его немножко пробовал, если это конечно Stanford NLP).
Вот удивительно — но нам тоже :) При этом у нас немного специфические данные, а именно адреса, которых много (десятки миллионов минимум).
Вы возможно спросите, зачем тут NLP? Если в двух словах, то тут все просто — адреса надо сравнивать, искать по ним, геокодировать, в общем — работать с ними. И если с задачей нормализации (и далее сравнения) как-то справляется Фактор, то с геокодированием все хуже. Вот типичный пример — ArcGIS успешно находит в своих справочниках улицу 8 Марта в Москве, но категорически не хочет находить улицы 3 Интернационала (коих множество в нашей стране). Зато находит улицу 3-го Интернационала. Не находит улицу «имени академика Н.И.Вавилова», но знает про существование просто «улицы Вавилова» в том же городе. Очень просто сделать из 3-го просто 3, но обратная задача уже требует понимания, к чему именно в предложении относится числительное (например, 3-я улица Строителей).
С другой стороны, чтобы собрать из слов «шоссе» и «Энтузиастов» и «Варшавское» «шоссе» полный адрес, в котором порядок слов будет различным, нужно знать, в какой форме у нас слова Энтузиастов и Варшавское.
В общем, это немного специфичная, но все же вполне задачка типа NLP. При этом данные большие, поэтому в качестве инструмента Spark. Соответственно, инструмент хочется на Java/Scala, в крайнем случае — PySpark (хотя тут уже мороки с интеграцией в имеющиеся модели на Java будет многовато).
В итоге в вашем тексте лично мне категорически не хватило технических деталей. Скажем, платформы, на которой это все работает (я только про Stanford знаю, что это Java, и даже его немножко пробовал, если это конечно Stanford NLP).
Спасибо за отклик!
Ну, если сюда еще и технические детали впихивать, то текст совсем разбухнет. Целевая аудитория все-таки nlp-шники, которые что-то слышали про синтаксический парсинг, для них, думаю, техника ясна.
Если вкратце — весь пайплайн на питоне. UDPipe написан на плюсах, но есть питонская обертка. У удпайпа есть неплохой мануал, ссылка есть в тексте.
Стэнфорд — это не тот Стэнфорд, кстати, а вот этот (и тоже на питоне если что).
github.com/tdozat/Parser-v2
web.stanford.edu/~tdozat/files/TDozat-CoNLL2017-Paper.pdf
и в соревновании 2018 года уже третья версия использовалась
github.com/tdozat/Parser-v3
Ну, если сюда еще и технические детали впихивать, то текст совсем разбухнет. Целевая аудитория все-таки nlp-шники, которые что-то слышали про синтаксический парсинг, для них, думаю, техника ясна.
Если вкратце — весь пайплайн на питоне. UDPipe написан на плюсах, но есть питонская обертка. У удпайпа есть неплохой мануал, ссылка есть в тексте.
Стэнфорд — это не тот Стэнфорд, кстати, а вот этот (и тоже на питоне если что).
github.com/tdozat/Parser-v2
web.stanford.edu/~tdozat/files/TDozat-CoNLL2017-Paper.pdf
и в соревновании 2018 года уже третья версия использовалась
github.com/tdozat/Parser-v3
>При этом у нас немного специфические данные, а именно адреса, которых много (десятки миллионов минимум).
> При этом данные большие, поэтому в качестве инструмента Spark.
Вот тут поясните пожалуйста, каким образом 10 миллионов строк из 100 символов это большие данные (да даже если миллиард).
Это нормальное количество данных для моделей, и есть куча способов справиться с ними, не используя Spark.
Но да, вам нужна высокая точность, поэтому наверняка у вас там громадная система на правилах и миллион различных тестов для обнаружения регрессий.
> При этом данные большие, поэтому в качестве инструмента Spark.
Вот тут поясните пожалуйста, каким образом 10 миллионов строк из 100 символов это большие данные (да даже если миллиард).
Это нормальное количество данных для моделей, и есть куча способов справиться с ними, не используя Spark.
Но да, вам нужна высокая точность, поэтому наверняка у вас там громадная система на правилах и миллион различных тестов для обнаружения регрессий.
>Это нормальное количество данных для моделей, и есть куча способов справиться с ними, не используя Spark.
Так речь не о том, что нет других способов. Речь о том, что у нас такой способ основной, и поэтому NLP хотелось бы встроить в этот процесс. И эти 10 миллионов — это часть процесса, а не весь.
>да даже если миллиард
Пятьдесят миллионов адресов (разумеется не одних, а скажем в виде предложений по недвижимости — с указанием этажей, площадей и прочего), для определенности — это порядка 200 гигабайт. Миллиард будет порядка терабайтов — т.е. конечно совсем не так и много, но в общем и не мало. Тут проблемы слегка в другом.
Попробуйте пропихнуть 10 миллионов скажем через геокодер. А лучше покажите мне такой геокодер, который умеет параллелить вычисления примерно как спарк. Я не знаю про такие, а имеющийся ArcGIS еще и денег хочет за каждое ядро. И поэтому скажем обратный геокодер у меня уже самописный на спарке, который работает быстрее ArcGIS на несколько порядков, хотя и не такой точный.
Так речь не о том, что нет других способов. Речь о том, что у нас такой способ основной, и поэтому NLP хотелось бы встроить в этот процесс. И эти 10 миллионов — это часть процесса, а не весь.
>да даже если миллиард
Пятьдесят миллионов адресов (разумеется не одних, а скажем в виде предложений по недвижимости — с указанием этажей, площадей и прочего), для определенности — это порядка 200 гигабайт. Миллиард будет порядка терабайтов — т.е. конечно совсем не так и много, но в общем и не мало. Тут проблемы слегка в другом.
Попробуйте пропихнуть 10 миллионов скажем через геокодер. А лучше покажите мне такой геокодер, который умеет параллелить вычисления примерно как спарк. Я не знаю про такие, а имеющийся ArcGIS еще и денег хочет за каждое ядро. И поэтому скажем обратный геокодер у меня уже самописный на спарке, который работает быстрее ArcGIS на несколько порядков, хотя и не такой точный.
Ок, ладно, пусть Spark у нас за map-reduce и job queue, но у него же есть клиент на питоне, к которому можно подключить уже ML / DL?
Интеллектуальность требует выч. ресурсов, и перемещая софт ближе к БД вы может и ускоряетесь, но существенно усложняете модификацию и дальнейшие улучшения вашего решения. Почитайте про красную зону оптимизации: habr.com/company/jugru/blog/338732
>Пятьдесят миллионов адресов (разумеется не одних, а скажем в виде предложений по недвижимости — с указанием этажей, площадей и прочего), для определенности — это порядка 200 гигабайт.
Ага, и, допустим, вы всё это зачем-то гоняете через себя каждый час/день, руками улучшая правила. Поздравляю, вы переизобрели Machine Learning, только вместо машины правила модифицирует не алгоритм, а вы сами. Увы, в некоторых областях приходится так делать, выжимая дополнительные проценты качества и дополнительную скорость, но ничего хорошего в этом нет. А со временем будет лишь хуже: правил будет ещё больше, и вы в них потеряетесь, а качество перестанет расти.
Интеллектуальность требует выч. ресурсов, и перемещая софт ближе к БД вы может и ускоряетесь, но существенно усложняете модификацию и дальнейшие улучшения вашего решения. Почитайте про красную зону оптимизации: habr.com/company/jugru/blog/338732
>Пятьдесят миллионов адресов (разумеется не одних, а скажем в виде предложений по недвижимости — с указанием этажей, площадей и прочего), для определенности — это порядка 200 гигабайт.
Ага, и, допустим, вы всё это зачем-то гоняете через себя каждый час/день, руками улучшая правила. Поздравляю, вы переизобрели Machine Learning, только вместо машины правила модифицирует не алгоритм, а вы сами. Увы, в некоторых областях приходится так делать, выжимая дополнительные проценты качества и дополнительную скорость, но ничего хорошего в этом нет. А со временем будет лишь хуже: правил будет ещё больше, и вы в них потеряетесь, а качество перестанет расти.
>Ага, и, допустим, вы всё это зачем-то гоняете через себя каждый час/день,
Это вы все сами придумали, я ничего такого не говорил. В том числе и про правила, которые кто-то улучшает руками. Вот интересно, откуда вы вообще такое взяли в моем комментарии? Я даже близко ничего такого не имел в виду, и ничего такого у нас нет.
>Ок, ладно, пусть Spark у нас за map-reduce и job queue, но у него же есть клиент на питоне, к которому можно подключить уже ML / DL?
В том-то и дело, что я не хочу подключать никакого клиента на питоне, когда у спарка у самого есть SparkML. Я хочу решение на Java/Scala, включающее NLP для русского языка — в форме адресов.
Это вы все сами придумали, я ничего такого не говорил. В том числе и про правила, которые кто-то улучшает руками. Вот интересно, откуда вы вообще такое взяли в моем комментарии? Я даже близко ничего такого не имел в виду, и ничего такого у нас нет.
>Ок, ладно, пусть Spark у нас за map-reduce и job queue, но у него же есть клиент на питоне, к которому можно подключить уже ML / DL?
В том-то и дело, что я не хочу подключать никакого клиента на питоне, когда у спарка у самого есть SparkML. Я хочу решение на Java/Scala, включающее NLP для русского языка — в форме адресов.
>В том числе и про правила, которые кто-то улучшает руками.
«И поэтому скажем обратный геокодер у меня уже самописный на спарке, который работает быстрее ArcGIS на несколько порядков, хотя и не такой точный. » — а этот обратный геокодер у вас не на правилах? Ну тогда я вас недопонял. Я предположил, вы промолчали, а потом через коммент вдруг говорите «а с чего вы это взяли».
>В том-то и дело, что я не хочу подключать никакого клиента на питоне, когда у спарка у самого есть SparkML.
Ну, это называется NIH. Вместо того, чтобы пользоваться лучшими решениями, вам хочется всё взять и переписать на своей платформе. Осталось только непонятно, действительно ли нужно это вашему бизнесу, или нужно только лично вам.
«И поэтому скажем обратный геокодер у меня уже самописный на спарке, который работает быстрее ArcGIS на несколько порядков, хотя и не такой точный. » — а этот обратный геокодер у вас не на правилах? Ну тогда я вас недопонял. Я предположил, вы промолчали, а потом через коммент вдруг говорите «а с чего вы это взяли».
>В том-то и дело, что я не хочу подключать никакого клиента на питоне, когда у спарка у самого есть SparkML.
Ну, это называется NIH. Вместо того, чтобы пользоваться лучшими решениями, вам хочется всё взять и переписать на своей платформе. Осталось только непонятно, действительно ли нужно это вашему бизнесу, или нужно только лично вам.
>а этот обратный геокодер у вас не на правилах?
Зачем вообще в обратном геокодере правила? Обратный геокодер — это практически чистая геометрия. Вы про что вообще?
Вы все время строите какие-то догадки, вместо того, чтобы уточнить.
>Вместо того, чтобы пользоваться лучшими решениями, вам хочется всё взять и переписать на своей платформе.
Кто вам сказал, какое из них лучшее? Ни одно из решений в данной области не является готовым из коробки. У каждого есть плюсы и минусы. Другая платформа — очевидный жирный минус, потому что на внедрение нужно время и деньги. То, на внедрение которого нужно больше времени, автоматически начинает проигрывать по стоимости и по времени внедрения.
>действительно ли нужно это вашему бизнесу, или нужно только лично вам.
Видите ли, дело в том, что мы все это уже проходили. Не лично, а в компании. И я могу заранее сказать, что просто переписывание готовых решений в направлении spark->pyspark (т.е. с «минимальными» якобы изменениями) — это уже немаленькая никому не нужная работа, и почти заведомые тормоза в итоге, и сильно увеличенное время развертывания.
Думаете, нашему бизнесу нужно, чтобы проекты внедрялись подольше? Агащаз.
Зачем вообще в обратном геокодере правила? Обратный геокодер — это практически чистая геометрия. Вы про что вообще?
Вы все время строите какие-то догадки, вместо того, чтобы уточнить.
>Вместо того, чтобы пользоваться лучшими решениями, вам хочется всё взять и переписать на своей платформе.
Кто вам сказал, какое из них лучшее? Ни одно из решений в данной области не является готовым из коробки. У каждого есть плюсы и минусы. Другая платформа — очевидный жирный минус, потому что на внедрение нужно время и деньги. То, на внедрение которого нужно больше времени, автоматически начинает проигрывать по стоимости и по времени внедрения.
>действительно ли нужно это вашему бизнесу, или нужно только лично вам.
Видите ли, дело в том, что мы все это уже проходили. Не лично, а в компании. И я могу заранее сказать, что просто переписывание готовых решений в направлении spark->pyspark (т.е. с «минимальными» якобы изменениями) — это уже немаленькая никому не нужная работа, и почти заведомые тормоза в итоге, и сильно увеличенное время развертывания.
Думаете, нашему бизнесу нужно, чтобы проекты внедрялись подольше? Агащаз.
>И я могу заранее сказать, что просто переписывание готовых решений в направлении spark->pyspark (т.е. с «минимальными» якобы изменениями) — это уже немаленькая никому не нужная работа, и почти заведомые тормоза в итоге, и сильно увеличенное время развертывания.
А один кусок нельзя использовать через pyspark? Я не говорил про переписывание готового, я недопонимаю, почему нельзя лингвистику подключить через pyspark, а остальное оставить где оно было.
А один кусок нельзя использовать через pyspark? Я не говорил про переписывание готового, я недопонимаю, почему нельзя лингвистику подключить через pyspark, а остальное оставить где оно было.
Ну почему же нельзя? Можно.
Только pyspark это же не решение для того, чтобы писать одно приложение одновременно на java/scala/python. Тут либо-либо, если вы запустили pyspark — то вы «готовите ему данные, запускаете», «ждете пока закончится», и «читаете результаты из файла».
Тем более что лингвистика — это все-таки не атомарный результат, а какое-нибудь дерево разбора, или типа того, обмениваться ими через файлы — то еще развлечение.
А если глобально, то вот скажем пост рассказывает какие бывают проблемы в общем случае. И как они решаются через REST. В целом это подход мне очень близок, но он совсем не универсальный, и масштабируется совсем не так просто, как чистый спарк, где мы на днях распараллелили некую медленную хрень, выполнявшую 15 запросов в секунду, и получили 40 миллионов в час, не прилагая усилий.
Только pyspark это же не решение для того, чтобы писать одно приложение одновременно на java/scala/python. Тут либо-либо, если вы запустили pyspark — то вы «готовите ему данные, запускаете», «ждете пока закончится», и «читаете результаты из файла».
Тем более что лингвистика — это все-таки не атомарный результат, а какое-нибудь дерево разбора, или типа того, обмениваться ими через файлы — то еще развлечение.
А если глобально, то вот скажем пост рассказывает какие бывают проблемы в общем случае. И как они решаются через REST. В целом это подход мне очень близок, но он совсем не универсальный, и масштабируется совсем не так просто, как чистый спарк, где мы на днях распараллелили некую медленную хрень, выполнявшую 15 запросов в секунду, и получили 40 миллионов в час, не прилагая усилий.
Каждому чайнику чайником по чайнику.
Довольно интересная штучка этот udpipe, но вот установить его для питона под Windows оказалось довольно сложным делом (автоматом не ставится), так что пришлось таки приложить те самые «сверхусилия»…
Там надо либо убирать из setup.py gcc-шные опции, чтобы VSC его успешно скомпилил (не пробовал).
Либо компилить каким-либо gcc подфиксив уже в самом питоне (т.к. там после 3.4 поддержка кончается :( ) distutils. (пробовал, взлетело).
При этом в любом случае надо либо ручками собрать «полуфабрикат» необходимый для инсталяции в питон, либо генерить его на Linux-овой машине.
Там надо либо убирать из setup.py gcc-шные опции, чтобы VSC его успешно скомпилил (не пробовал).
Либо компилить каким-либо gcc подфиксив уже в самом питоне (т.к. там после 3.4 поддержка кончается :( ) distutils. (пробовал, взлетело).
При этом в любом случае надо либо ручками собрать «полуфабрикат» необходимый для инсталяции в питон, либо генерить его на Linux-овой машине.
Посмотрел список из 60 языков. Недостаток: нет эсперанто. Надо было начинать с простого, логичного и выразительного языка. Кроме того, на эсперанто можно переводить почти дословно (в google об этом догадываются, но у них, пока, другие задачи), с роботом на эсперанто можно было бы полноценнее общаться, да и обучить его было бы намного проще.
А для каких задач можно использовать полученное дерево?
Я бы выделил несколько направлений.
1) В модели BoW «банкомат съел карту» и «карта съела банкомат» — одинаковые вещи. Деревья помогут Вам их различить.
2) Вы можете использовать синтаксическую роль токена как метрику важности токена (условно, подлежащее важнее определения) и имплементировать веса в какой-нибудь классификатор.
3) Синтаксические правила и ограничения полезны в определении правильности грамматики фразы при порождении речи.
4) Наконец, в конкурсах типа «ответов на вопросы по тексту» синтаксические группы (их +- можно выделить на основании дерева) помогают выделить нужный кусок.
1) В модели BoW «банкомат съел карту» и «карта съела банкомат» — одинаковые вещи. Деревья помогут Вам их различить.
2) Вы можете использовать синтаксическую роль токена как метрику важности токена (условно, подлежащее важнее определения) и имплементировать веса в какой-нибудь классификатор.
3) Синтаксические правила и ограничения полезны в определении правильности грамматики фразы при порождении речи.
4) Наконец, в конкурсах типа «ответов на вопросы по тексту» синтаксические группы (их +- можно выделить на основании дерева) помогают выделить нужный кусок.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Изучаем синтаксические парсеры для русского языка