kelijah

Будет в ближайшем релизе. Сделал его как учебное пособие по составлению правил синтаксического разбора предложений.


( Read more... )

Две взаимосвязанные идеи. Есть много use cases, где они очень помогут. А вводимая с их реализацией дополнительная нагрузка на движок невелика. Поэтому надеюсь сделать следующее.


( Read more... )

Делал этот словарь для проверки корректной обработки юникода несколько лет тому назад.

Попробовал сегодня собрать его - а он шельмец возьми и соберись. Объем конечно не очень впечатляющий, около 125 тысяч слов, включая торговые марки и прочее.

Борьба была беспощадная, но результат радует.

Итак, в сухом остатке - для грамматического движка сделан и выполнен многопоточный нагрузочный тест. Это когда несколько (от 3х до 11) потоков одновременно вызывают sol_MorphologyAnalysis и sol_SyntaxAnalysis для одного экземпляра загруженного словаря, и сравнивают результаты для примерно 6000 эталонных английских предложений.

Раньше такой тест у меня был только для MS Windows варианта движка (32 и 64 битные dll). Он отлично выявляет всю грязь в коде с точки зрения доступа из множества потоков. Особенно это касается кэшей для данных в SQL хранилище. Когда десять потоков запрашивают какой-либо кэш в режиме читателя, а один поток, не найдя нужные данные, хочет стать писателем и подгрузить что-то из БД, любая ерунда с синхронизацией очень быстро разрушает кучу и валит систему.

Под Linux тест использует "голые" pthread_xxx, я решил обойтись без ООП-оберток, чтобы не тащить в тесты дополнительные внешние зависимости. В целом все просто, принципиалтьных отличий от win-specific функций

В целом, под Linux нашлось несколько ошибок. В частности, пришлось переработать использование мьютексов, перевести часть в рекурсивный режим. Ну и самое главное - чтобы открытое соединение с SQLite базой нормально обслуживало множество параллельных потоков, пришлось и под Linux открывать БД с помощью sqlite3_open_v2 с флагом SQLITE_OPEN_FULLMUTEX.

Не обошлось и без некоторого шаманизма. Древняя версия libsqlite3 под моим линуксом отказалась выполнять sqlite3_open_v2, и я решил обновиться до текущей версии 3.7.11. Под Win либа скомпилировалась и заработала без каких-либо проблем. А под Linux неожиданно всплыла ошибка там, где я никак ее не ожидал.

При сборке словаря на одном из этапов, при выгрузке данных в sqlite-базу, попытка зафиксировать транзакцию через commit приводила к "disk I/O error". Проверка диска, анализ свободного пространства в tmpfs и на рабочих дисках ничего не дал. Попробовал для глючащей БД задавать PRAGMA temp_store=MEMORY, с нулевым результатом. И только через несколько часов выяснилось - новая версия SQLite отказывается нормально работать с файлом БД, размещенным на примонтированном NTFS разделе. Либо поддержка NTFS диска в этом дистре Линукса бажная и некоторые важные для ACID i/o функции не работают, либо вообще NTFS под линуксом теперь рассматривается ядром SQLite как моветон, в общем перенос создаваемой БД на родной линуксовый раздел всё исправил.

Теперь можно будет 1) зафиксировать в относительно близком времени текущий релиз SDK словаря 2) сделать наконец-то третий вариант SDK - полноценный серверный, пока только для MySQL, со словарем в MySQL и доступом через процедурный API solarix_grammar_engine_mysql.dll, то есть с полноценной поддержкой морфологического анализа и прочих вещей, недоступных в SQL-словаре.

Для платформ Win 32bit и 64bit собрал все компоненты (компилятор словаря, DLL движка и прочее) и прогнал тесты:

1. Морфологический разбор для ~4500 предложений и построение синтаксических деревьев для ~1300 предложений на русском языке. Многопоточный вариант - 11 потоков одновременно выполняют вызовы sol_MorphologyAnalysis и sol_SyntaxAnalysys для одного загруженного экземпляра словаря.

2. Аналогично для английского словаря. Примерно 5200 предложений для морфологического анализа, около 5000 предложений для синтаксического разбора, и многопоточный тест.

Что еще осталось.

1. Сборка и тесты на Linux.

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

Добавил к ядро анализатора последний модуль из запланированных для версии 11.

Его задача - помогать делать выбор между вариантами построения синтаксического дерева при наличии неоднозначности. Пример неоднозначности для русского языка:

Я пью чай с друзьями
Я пью чай с пирожными

Аналогично для английского:

I chase rabbits in the field.

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

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

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

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

Залил двуязычный словарь на тестовый сервер, чтобы можно было погонять его вживую:

I give you the books I found in the classroom
We have said nothing to anybody about you


( Скриншоты с результатами... )

Ближайшие:

1. Закончить с английским парсером.
2. Полная переделка русского синтаксического анализатора на новый движок, испытанный на английском, отказ от детерминированного автомата и правил переписывания.
3. Минимальный анализатор для французского языка (пара простейших паттернов) в качестве пояснения теоретической начинки парсера нисходящего анализа. (Исходники французского парсера войдут в SDK, исходники русского и английского парсеров видимо будут закрытые).

Среднесрочные:

1. Автогенерация правил (HMM) по размеченному корпусу; ver. 2
2. Новый лексер v.2 с глубокой интеграцией с анализатором, учетом текущего контекста и ожиданий.
3. Tree scorer для синтаксического анализатора.
4. Возможно - введение в движок правил переписывания недерминированности, которая там была в самой первой версии, но потом была убрана из-за проблем с эффективностью.

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

Сам алгоритм парсинга сделан потоковым. То есть он получает из исходного предложения первое слово и сразу начинает делать предположения о структуре и дальнейших ожидаемых конструкциях.

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

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

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

На перспективу - вместо текстового лексера можно будет реализовать модуль распознавания устной речи или OCR. В обоих случаях они будут работать в контексте грамматического парсера, то есть иметь информацию о том, какие множества слов ожидаются на входе.