Компьютерная лингвистика

Собираю статистику структуры предложений.
В предложениях выделяются именные группы, чтобы свести варианты аргументов глагола к общему знаменателю.
После обработки примерно 50 миллионов предложений вижу такой top 30 шаблонов (решетка отделяет NP-чанки и прочие токены):
( Collapse )Обратите внимание на два стоящих рядом шаблона:

1414    NP,Ins#является#NP,Nom,Sing#.
1233    NP,Nom,Sing#является#NP,Ins#.

В них именные группы зеркально отображены относительно глагола, а частоты (ранги?) очень близки.
Редкий случай действительно свободного порядка ИГ для глагола. Для других глаголов носители языка явно тяготеют к тому или иному положению подлежащего, дополнения или PP, возможно используя "неканоничный" порядок для передачи особых "сигналов".

Любой ML'щик время от времени делает две вещи - меняет работу и свой deeplearning фреймвок (js-фронтэндеры понимающе улыбнутся). Работу я поменял в прошлом году, теперь настало время посмотреть на модный PyTorch.

Серьезно говоря, единственная фишка питорча, ради которой захотелось его освоить - хайповые динамические графы. С их помощью делать GAN'ы должно быть намного проще, чем в keras'е, где приходится выкручиваться с необучаемыми частями графа и т.д.

Для разминки сделал на питорче сиамскую рекуррентную сетку, определяющую синонимичность двух фраз. Пример датасета лежит тут, это часть текущего 220-тысячного корпуса.
Старая реализация модели на Keras с кучей экспериментального мусора - тут.
Реализация на PyTorch - тут.
( Collapse )

В ходе экспериментов с оптимизацией загрузки словаря в проекте ruword2tags столкнулся с неожиданным эффектом.
Контекст такой:
( Collapse )
5) Неожиданный эффект заключается в том, что во 2й версии питона pickle.load работает примерно 60 секунд, в 3й - 6 секунд.

Вспомнил первый курс института, матан для решения одной из задачек. Час времени утром до начала работы, несколько листов, две ручки и четыре маркера:
( Collapse )
И поле битвы:
( Collapse )

Соревнование по определению похожести вопросов закончилось, теперь можно поизучать чужие решения. И пересмотреть еще раз некоторе нюансы в своем решении тоже.

Итак, есть один признак, который я добавил в датасет, не ожидая особого эффекта. Но он оказался достаточно сильным, и это странно.

Вот топ списка фич, выдаваемых xgboost и отсортированных в порядке убывания веса:

( Collapse )

Выделенные болдом признаки kenlm_* представляют из себя оценки достоверности фрагментов фразы. Они вычисляются с помощью предварительно построенной языковой н-грамной модели KenLM. Вычисление делается вот так:

( Collapse )

То есть берем начало вопроса из нескольких слов. Значения для начальных фрагментов длиной в 8, 16 и 32 слова вычисляются отдельно. Вычисляем оценку для первого вопроса, для второго, сохраняем их в датасете, а также добавляем разницу оценок. Учитывая логарифмический характер оценок, мы фактически определяем относительную оценку.

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

Но тем не менее xgboost в ходе построения деревьев на каком-то уровне делает вывод, что выгода от учета значения kenlm-фичи больше, чем, например учет похожести предложений на базе информации в WordNet (синонимия и так далее) - см. положение фичи wordnet_sim_0.

Продолжаем обработку статистики. Собираем сочетания глагола (сказуемое или деепричастный оборот) с группой предлог+существительное.
У существительного могут быть атрибуты и дополнения, их в данной статистике мы не учитываем.
Top-100  по абсолютной частоте:

( Collapse )

У меня появляется ощущение, что по мере роста обработанного корпуса, создаваемые кластеры становятся более осмысленными.

Хотя даже на уровне 700-800 Мб в utf-8 фактор исходников слишком значителен.

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

( Collapse )

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

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

Можно ли одним SQL запросом увидеть список связанных слов с учетом рекурсивного характера алгоритма обхода?

Для решения нужно использовать такую полезную вещь, как Common Table Expressions и их разновидность для рекурсивного обхода деревьев - см. http://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL. Само по себе CTE является просто локально определенным и именованным view в рамках конкретного запроса, вводимым с помощью ключевого слова with. Если добавить сюда возможность внутри CTE сослаться в FROM на это же самое CTE, то получается полноценное решение задачи без каких-либо процедурных костылей.

Вот запрос, работающий в FireBird версии 2.5 (насчет более ранних версий нужно проверять, но скорее всего в 2.1 этот фокус тоже работает):

( Collapse )

В нисходящем парсере сейчас реализован "традиционный" порядок связывания подлежащего и сказуемого. А именно - глагол, который является headword в глагольном сказуемом, становится корнем, подлежащее привязывается к нему ребром типа SUBJECT.

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

Итак, вот пример предложения:

Стёклышко ловило луч солнца, подбрасывало его как на ладони и кидало в самую неожиданную сторону

Одно подлежащее, три глагольных сказуемых, каждое со своими уточняющими ветками.

Если идти обычным путем, то получается вот такой граф:

( Collapse )

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

Далее - пример разбора на слова цепочки ЯМЫЛАРАМУ. Верхний регистр тут использован потому, что обычно языки с таким типом сегментации не имеют различия символов по верхнему-нижнему регистру, и в силу некоторых внутренних решений натуральным считается верхний регистр.

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

( Collapse )