Все это замечательно, но есть суровые реалии. Министерство финансирует вуз в зависимости от количества студентов. Кроме того, сейчас последствия очередной демографической ямы. Следствия из этого, я думаю, понятны.
Это все очень сложно. Вообще есть такой проект — nlpub.ru ведет его eveel. Но вот использовать все вместе составляет довольно большие технические трудности. Например, есть открытая морфология АОТ, с другой стороны — есть открытая часть НКРЯ (национального корпуса русского языка) с морфологической разметкой. Казалось бы, взять — и фактически готовый POS-теггер. Но в АОТ приняты одни соглашения, в НКРЯ — другие, в СинТагРусе (корпус с синтаксической разметкой) — третьи. Их частично можно преобразовывать между собой, но во многом требуется преобразование руками.
С другой стороны — многие разработки закрыты, причем как коммерческие, так и академические. И разработчики ими делятся не очень охотно. Это тоже понятно — разработка лингвистических ресурсов трудоемко.
Но задача несколько отличается от perfect hash. Надо по строке получать нормальную форму и морфологические характеристики. Это тоже занимает достаточно много места.
Я вот сейчас поставил cmph, прогнал просто список словоформ. Получил, что данные для хеша занимают 21Мб. Время построения — сходное с построением минимального КА. Минимальный КА занимает меньше даже без особой экономии памяти.
Преимущество автомата как раз в том, что его можно менять. В ЭТАПе как раз так и сделано. Есть словарь, который правят лингвисты, он также хранится в виде КА. И КА изменяется на лету без перестроения всего автомата.
Опять же, не было задачи ужать все до минимальных размеров. При желании автомат можно упаковать очень сильно. Например, если переходы изпользовать дельта и varint кодирование для меток переходов. В общем все, что описано в www.aclweb.org/anthology/W/W09/W09-1505.pdf
Кажется, что дело в деталях. В случае GATE используется обычная минимизация ДКА с некоторыми тонкостями для представления групп.
Для weighted на первый взгляд нужны совершенно другие алгоритмы.
Про эквивалентность — ну вот подход ЭТАПа — построение классического трансдюсера, но если сделать из него КА, который на конечном состоянии выдаст нормальную форму, то он будет сильно большего размера.
И с трансдюсерами кажется отдельная задача — детерминирование по входному/выходному символу.
Просто к чему я это все. У меня на гитхабе там рядом выдрана из GATE работа с общим КА(удаление эпсилон-переходов, НКА -> ДКА, минимизация ДКА). Но для трансдюсеров, тем более с весами, нужны другие алгоритмы.
Кстати, под трансдюсерами разные люди понимают разные вещи. Ты, если я правильно понимаю, говоришь по weighted FST. А вот разработчики GATE трансдюсером называют обычный КА, с финальным состоянием которого ассоциированы некие действия.
Да, все правильно. Пост про представление данных для фактически первого шага анализа. Это даже не описание полного морфологического анализа, поскольку там есть свои особенности.
Обычно анализ текста выглядит примерно так: токенизация, морфологический анализ, [другие стадии анализа].
Вот эти другие стадии анализа бывают очень разными. Следующая классическая стадия — синтаксический анализ. Но он очень ресурсоемкий как с точки зрения построения системы, так и с точки зрения ресурсов для анализа. Во многих случаях достаточно поверхностного анализа на основе списков слов — газетиров. Это фактически тот же морфологический словарь, но другого назначения. Например это — личные имена, фамилии, названия городов, улиц, железнодорожных станций, станций метро. Эти списки тоже надо как-то компактно представлять. А для более-менее приемлемого качества выделения такого рода объектов достаточно простых шаблонных правил вида: [Имя] [Фамилия] или [Фамилия] [Имя] [Отчество]. Эти правила — фактически регулярные выражения, только не над символами строки, а над словами текста. Этот подход используется, например в GATE и позволяет достаточно хорошо выделять объекты.
Мне хотелось написать пост по одной конкретной теме. Например, есть совершенно другая тема — разрешение частеречной омонимии — POS Tagging, на котором обычно и выбирается одна из альтернативных форм слова. (Но, например, в системе ЭТАП-3 другой принцип — там омонимия разрешается одновременно с синтаксическим анализом).
Обычно, если слово есть в словаре, то оно анализируется только по словарю.
Если его там нет, то практически во всех системах есть в том или ином виде предиктивный анализ, который пробует разборать разными способами:
Разобрать слово по композитам.
Возможно, отрезать некий префикс, так, чтобы усеченное слово было в словаре. Обычно есть настройки на длину оставшегося слова, чтобы слова типа «а» не попадали в разбор
Предсказание по окончаниям. Например, предсказание по: 2м буквам основы, суффиксу(если есть) и окончанию.
Ну и возможны вариации вроде фильтрации по частям речи (например маловероятно, что неизвестное слово — частица или предлог), по статистике — отбрасываем редкие и исключительные варианты (вряд ли неизвестный глагол будет изменяться так же как «быть»).
Но все это обычно не отменяет следующий шаг — выбор одного варианта из нескольких. (Например, разбор слова «мыла» как глагола в «мама мыла раму»).
Композиты кажется нужны для довольно узкого круга задач.
Можно, как в АОТ, отрезать приставки. т.е. «паротепловозостроительный» разобрать по аналогии с «строительный». И лемма в этом случае тоже корректно строится.
Ну или брать композитные части максимальной длины, ну и ограничить формы, которые могут участвовать в словобразовании. Собственно, так сделано в ЭТАПе.
Да, emacs хорош для языков, которым не нужна IDE. Я успешно использовал emacs для Common Lisp — потому что есть slime. С переменным успехом для C/C++ — как ни странно, Visual Studio местами сильно удобнее по части автодополнения. Для Java — да, плохо.
Я бы сказал, что emacs хорошо подходит тогда, когда для написания кода достаточно более-менее поверхностного анализа.
Сейчас пишу на Java в Eclipse, настроил чтоб он максимально был похож на emacs. Но вот для JVM-like языков я бы не согласился заново перейти на emacs.
Интересно, как они работу распределяли. Когда каждый пишет свою главу — все достаточно просто. Кажется достаточно сложным мержить изменения одного файла — что бы правки разных людей не приводили к стилистическим ошибкам.
С другой стороны — многие разработки закрыты, причем как коммерческие, так и академические. И разработчики ими делятся не очень охотно. Это тоже понятно — разработка лингвистических ресурсов трудоемко.
Но странно, что там реализован только алгоритм для отсортированных строк. В основной статье как раз два алгоритма: для отсоритрованных и нет.
Я реализовывал алгоритм, который работает без предварительной сортировки входных данных.
Но задача несколько отличается от perfect hash. Надо по строке получать нормальную форму и морфологические характеристики. Это тоже занимает достаточно много места.
Я вот сейчас поставил cmph, прогнал просто список словоформ. Получил, что данные для хеша занимают 21Мб. Время построения — сходное с построением минимального КА. Минимальный КА занимает меньше даже без особой экономии памяти.
Преимущество автомата как раз в том, что его можно менять. В ЭТАПе как раз так и сделано. Есть словарь, который правят лингвисты, он также хранится в виде КА. И КА изменяется на лету без перестроения всего автомата.
Опять же, не было задачи ужать все до минимальных размеров. При желании автомат можно упаковать очень сильно. Например, если переходы изпользовать дельта и varint кодирование для меток переходов. В общем все, что описано в www.aclweb.org/anthology/W/W09/W09-1505.pdf
Для weighted на первый взгляд нужны совершенно другие алгоритмы.
Про эквивалентность — ну вот подход ЭТАПа — построение классического трансдюсера, но если сделать из него КА, который на конечном состоянии выдаст нормальную форму, то он будет сильно большего размера.
И с трансдюсерами кажется отдельная задача — детерминирование по входному/выходному символу.
Просто к чему я это все. У меня на гитхабе там рядом выдрана из GATE работа с общим КА(удаление эпсилон-переходов, НКА -> ДКА, минимизация ДКА). Но для трансдюсеров, тем более с весами, нужны другие алгоритмы.
Кстати, под трансдюсерами разные люди понимают разные вещи. Ты, если я правильно понимаю, говоришь по weighted FST. А вот разработчики GATE трансдюсером называют обычный КА, с финальным состоянием которого ассоциированы некие действия.
Обычно анализ текста выглядит примерно так: токенизация, морфологический анализ, [другие стадии анализа].
Вот эти другие стадии анализа бывают очень разными. Следующая классическая стадия — синтаксический анализ. Но он очень ресурсоемкий как с точки зрения построения системы, так и с точки зрения ресурсов для анализа. Во многих случаях достаточно поверхностного анализа на основе списков слов — газетиров. Это фактически тот же морфологический словарь, но другого назначения. Например это — личные имена, фамилии, названия городов, улиц, железнодорожных станций, станций метро. Эти списки тоже надо как-то компактно представлять. А для более-менее приемлемого качества выделения такого рода объектов достаточно простых шаблонных правил вида: [Имя] [Фамилия] или [Фамилия] [Имя] [Отчество]. Эти правила — фактически регулярные выражения, только не над символами строки, а над словами текста. Этот подход используется, например в GATE и позволяет достаточно хорошо выделять объекты.
Мне хотелось написать пост по одной конкретной теме. Например, есть совершенно другая тема — разрешение частеречной омонимии — POS Tagging, на котором обычно и выбирается одна из альтернативных форм слова. (Но, например, в системе ЭТАП-3 другой принцип — там омонимия разрешается одновременно с синтаксическим анализом).
Если его там нет, то практически во всех системах есть в том или ином виде предиктивный анализ, который пробует разборать разными способами:
Ну и возможны вариации вроде фильтрации по частям речи (например маловероятно, что неизвестное слово — частица или предлог), по статистике — отбрасываем редкие и исключительные варианты (вряд ли неизвестный глагол будет изменяться так же как «быть»).
Но все это обычно не отменяет следующий шаг — выбор одного варианта из нескольких. (Например, разбор слова «мыла» как глагола в «мама мыла раму»).
Можно, как в АОТ, отрезать приставки. т.е. «паротепловозостроительный» разобрать по аналогии с «строительный». И лемма в этом случае тоже корректно строится.
Ну или брать композитные части максимальной длины, ну и ограничить формы, которые могут участвовать в словобразовании. Собственно, так сделано в ЭТАПе.
Да, emacs хорош для языков, которым не нужна IDE. Я успешно использовал emacs для Common Lisp — потому что есть slime. С переменным успехом для C/C++ — как ни странно, Visual Studio местами сильно удобнее по части автодополнения. Для Java — да, плохо.
Я бы сказал, что emacs хорошо подходит тогда, когда для написания кода достаточно более-менее поверхностного анализа.
Сейчас пишу на Java в Eclipse, настроил чтоб он максимально был похож на emacs. Но вот для JVM-like языков я бы не согласился заново перейти на emacs.
А про организацию — все ArrayList так устроены, как следует из названия :-)
Коллекции, похожие на sdk удобно использовать когда заранее не знаешь, сколько элементов будет.