Худкий и крукий

Худкий и лучхой — в некотором смысле антонимы.

Другие прилагательные, построенные анализатором, которые могут быть антонимами представленным в задаче словам, — блидкий, нидкий, раньхой.

Ответ на задание 1.

Программе были переданы прилагательные не в положительной, а в сравнительной степени.

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

Для того чтобы получить такие результаты, программа следовала следующим правилам:

-ше → -хой
-же → -дкий
-че → -кий
-ще → -стый

Ответ на задание 2.

Программе были переданы слова:

высокий, далёкий, крутой, хороший, поздний, простой, плохой.

Обратите внимание, что сравнительные степени слов хороший и плохой — супплетивны, то есть в сравнительной степени они образуются от другого корня, нежели в положительной степени. Для слова дальше (*дальхой) положительная степень образуется от слова далёкий, а не дальний.

Ответ на задание 3.

В качестве образцов для выведения правил, на которые ориентировался TreeTagger, могли выступать следующие пары прилагательных:

Для слов выхой, дальхой и лучхой:

дольше → долгий, тоньше → тонкий.

Для слов поздкий, худкий:

реже → редкий, глаже → гладкий, жиже → жидкий.

Для слова крукий:

мягче → мягкий, крепче → крепкий, жарче → жаркий.

Для слова простый:

чище → чистый, толще → толстый.

После решения этой задачи у вас могут возникнуть сразу три логичных вопроса: зачем нужны морфологические анализаторы, как они устроены и, ещё раз, зачем нужны морфологические анализаторы, если они работают так плохо? Давайте разбираться по порядку.

Стоит начать с того, что в этой задаче мы показали вам только один из компонентов TreeTagger, который восстанавливает начальные формы слов. В лингвистике их ещё называют леммами, отсюда и название этого компонента — лемматизатор. Помимо него, TreeTagger умеет делать морфологический разбор, строить структуру предложения (искать зависимые слова) и много чего ещё. С большинством из этих задач он справляется успешнее, да и из выдачи лемматизатора мы специально отобрали не самые лучшие примеры.

К помощи морфологических анализаторов лингвисты прибегают, когда нужно обработать большие объёмы текста, которые сложно разметить вручную (например, в корпусах — о них можно прочитать в послесловии к задаче Sketch Engine). Полученные данные потом используют для лингвистических исследований — или передают в другую программу, которая, например, учит компьютер выделять из текстов нужные словосочетания или даже писать тексты. При этом чем больше информации известно про каждое предложение или даже слово — тем лучше, поскольку это даёт компьютеру больше знаний об особенностях словоформ, а людям помогает, например, дополнительно уточнять критерии поиска словосочетаний.

Кроме того, у всех программ для анализа текста — в особенности у лемматизаторов — есть ещё одна важная сфера применения, которой мы пользуемся каждый день, — это поиск. Допустим, вы хотите найти все новости о Венере: вам будет интересна и «В кислотных облаках Венеры нашли намеки на жизнь», и «Россия может отправить миссию на Венеру в 2027 году» и «Венера или Марс. Какая из планет лучше подходит для колонизации?» — ведь мы с вами понимаем, что за разными формами слова стоит одна и та же планета, хотя для поисковой системы это три разные строки среди миллиардов других строк в её памяти. И вот тут на помощь приходит лемматизатор, с помощью которого поисковик сначала ставит все слова в заголовке в начальную форму, потом делает то же самое для нашего запроса «новости о Венере» (рис. 1), и, наконец, находит соответствие между словами и выдаёт вам заголовки со всеми формами названия планеты (подробнее об этом можно прочитать в послесловии к задаче Что гуглят Малыш и Карлсон). Да, лемматизаторам при сохранении слов не важен регистр — в них всё хранится строчными буквами.

Рис. 1. Анализ слова. Полёт нормальный

Если вы дочитали досюда, поздравляем: сейчас вы узнаете про один из ключевых механизмов — можно сказать, даже про сердце Яндекса. Да, это морфологический анализатор, и скриншот именно его работы вы только что увидели. Он называется MyStem, и его для поисковика написал один из сооснователей Яндекса, Илья Сегалович, ещё в 2003 году (теперь вы представляете, насколько он важен для системы?), а несколькими годами позже Яндекс опубликовал его для использования всеми желающими. Кроме него и TreeTagger для русского языка есть ещё pymorphy2, и все они немного различаются, но кое-что общее между ними есть: каждый из них хранит внутри себя словарь существующих в русском языке слов со всеми их формами в определённом виде. А вот в чём между ними разница:

• TreeTagger — тот, который в задаче, — анализирует подготовленный список слов языка, где каждой форме слова сопоставлено начальное значение. Помимо записи слов в словарь, он смотрит на различающиеся окончания слов (речь здесь и далее о произвольных частях словоформы без нескольких начальных букв, а не о морфеме) и запоминает эти попарные соответствия: например, для пары «чаще — частый» он запомнит «ще → стый», отрезав совпадающие ча- в началах слов. Когда TreeTagger анализирует слово, он смотрит на его правую часть и выбирает из своего списка соответствий самую длинную подстроку, совпадающую с тем, на что заканчивается слово для разбора. Поскольку он хранит только один вариант соответствия, то, если одно и то же окончание на самом деле может соответствовать нескольким разным начальным формам, TreeTagger неизбежно будет ошибаться. Именно так получились слова из задачи, а я приведу ещё пару, продолжив свой пример: гуще он разберёт как густый, а слаще — как сластый.
• MyStem устроен принципиально иначе: он запоминает все формы слов с их морфологическими разборами и складывает их в довольно хитрую структуру: все слова разворачиваются в обратную сторону, после чего составляется граф — некоторое подобие схемы, где записаны все существующие пути от конца к началу слова. Звучит непонятно, поэтому давайте я проиллюстрирую это примером: обозначим конец слова как $, а начало — как ^. Все пути в нашем графе начинаются из точки $: пойдём из неё в точку Т, потом — в точку О, и затем — в точку К. Из этой точки мы можем прийти в точку ^ — это значит, что существует слово кот (напоминаю, слова у нас в перевёрнутом виде!). А вот в точку Ь мы прийти не можем — в русском нет ни одного слова, которое бы в любой форме заканчивалось на -ькот. Зато мы можем прийти в точку Е, но из неё, например, в ^ прийти уже нельзя — потому что слово антрекот есть, а слова екот нет.
  
  Таким образом, при обработке вновь введённого слова MyStem переворачивает его и пытается пройти соответствующий путь в своём графе. Если получается — значит, слово есть в словаре, и лемма для него известна (MyStem хранит в памяти также пару «путь — лемма»). А если не получается, то есть слова в словаре не нашлось, MyStem находит известные ему словоформы, которые заканчиваются так же, как заканчивается вновь введённое слово, и восстанавливает начальную форму по тем же правилам, по которым начальная форма восстанавливается для этих найденных словоформ. Кстати, исходная версия MyStem основана на формах и разборах слов из Грамматического словаря русского языка, созданного А. А. Зализняком.
• pymorphy2 работает с незнакомыми словами похоже — он тоже подбирает совпадающие окончания из своей памяти. Технически он устроен немного по-другому: он хранит в графе слова в прямом порядке, а не в перевёрнутом, и ограничивает поиск окончаний пятью символами, но это всё не так важно — интереснее, что в нём применяется пара дополнительных трюков. Во-первых, он знает несколько распространённых префиксов, которые часто добавляются к словам, — например, анти- или сверх-. Если начало слова совпало с таким префиксом, а то, что остаётся, совпадает со словоформой из словаря, то pymorphy2 просто добавляет такой префикс к уже известной словарной лемме. Автор, правда, подчёркивает, что есть префиксы, которые меняют морфологические свойства, — по- и наи-, и их pymorphy2 по этой причине игнорирует. Кроме того, такой же трюк pymorphy2 пытается проделать и с несуществующими префиксами: допустим, если у нас в словаре нет слова ковид, но есть слово вид, то pymorphy2 (верно) предположит, что ковид склоняется так же, хотя в русском нет и никогда не было приставки ко-. Другое дело — со словом тиндер: хотя в словаре есть похожая словоформа тендер, но словоформ индер, ндер и так далее нет, поэтому pymorphy придётся вернуться к уже описанному алгоритму, схожему с тем, что у MyStem.

Внимательный читатель уже мог заметить, что MyStem и pymorphy2, в отличие от TreeTagger, умеют делать разборы для несуществующих слов — таких, которые не встречались им в словарях и текстах. В этом, на самом деле, есть реальная необходимость — это не просто прикольное дополнение, чтобы работать со штуками вроде глокой куздры или хливких шорьков: во-первых, с каждым годом появляется множество абсолютно новых слов (знали ли в 2017-м про тиктокеров, а в 2012-м — про зум-колл?), а во-вторых — и без них хватает словообразования (попробуйте к любому существительному добавить приставку псевдо-) и имён собственных (какой именительный падеж у Киану Ривза?). Кроме того, и MyStem, и pymorphy2 умеют определять вероятность правильной догадки, основываясь на том, насколько часто подобные окончания встречались в обучающем словаре (в случае pymorphy2), или на анализе длины совпавших окончаний, частотности исходных слов и т. п. (в случае MyStem, но тут мы точно не знаем, как именно).

Может сложиться впечатление, что по итогу и MyStem, и pymorphy2 обучаются работать если не идеально, то близко к тому, и уж точно всегда анализируют слова лучше, чем TreeTagger. Но это не совсем так (рис. 2):

Рис. 2. Не только у людей трудности с интерпретацией треков Little Big

И здесь мы логичным образом подходим к последнему вопросу: если лемматизаторы и морфологические анализаторы нередко допускают такие забавные ошибки, то зачем вообще их использовать? Ответов тут тоже несколько. Во-первых, точности в 100% невозможно добиться практически никогда, и часто лингвистам оказывается достаточно точности в 98%, 95%, даже 90%, которая вполне покрывается всеми нашими алгоритмами. Во-вторых, иногда это и не страшно: какая разница, что в базе данных поисковика Зендая превратилась в зендать, ведь при этом Зендая или даже Зендаю в запросе пользователя тоже превратятся в зендать, и мы всё равно успешно найдём нужный документ про Зендаю и покажем именно его. Наконец, на вооружении у крупных компаний, вроде того же Яндекса, давно стоят более мощные версии анализаторов, чем те, что доступны публично. Так, даже для давно опубликованного MyStem неизвестен исходный код (есть доступ только к программе в двоичном формате — поэтому, например, я написал выше, что мы не знаем, как именно он определяет наиболее предпочтительную лемму) — чего уж говорить о том, какие механизмы стоят за текущим движком поиска Яндекса или Google. Это могут быть усовершенствованные версии свободно доступных анализаторов, могут быть какие-то нейросетевые решения, но скорее всего это сложная комбинация из вышеперечисленных и ещё нескольких более простых механизмов. Раскрывать внутренности своих механизмов компаниям совсем невыгодно — ведь от качества их работы напрямую зависит качество поиска и, соответственно, прибыль, а алгоритмы при этом постоянно совершенствуются, да и конкуренты не дремлют.

Ясно одно: хотя средства, с которыми работают лингвисты, — это результат многих часов кропотливой работы и многих дней дальнейшего совершенствования, они также всегда будут неиссякаемым источником нелепых ошибок — в конце концов, мы ведь и сами ошибаемся. Но, хоть идеал и недостижим, качество работы алгоритмов обработки естественного языка растёт от года к году — во многом благодаря небольшим дополнениям предыдущих наработок, улучшениям существующих алгоритмов и свежим идеям от новых поколений исследователей. Так что если у вас при чтении этого послесловия возникли мысли, как сделать описанные алгоритмы лучше, — это замечательно! Ждём вас в тёплой компании компьютерных лингвистов:)

Задача использовалась на II туре XLIX Московской традиционной олимпиады по лингвистике (2019).

Авторы задачи — Евгений Лапин и Устинья Кошелева.
Автор послесловия — Иван Торубаров.