Pull to refresh

Comments 78

Это последний из недостающих компонентов для создания русского Ватсона. Ура!
Мне кажется, Вы чересчур оптимистичны по поводу Томиты, у нее достаточно ограничений.
Во-первых, лиха беда начало. Во-вторых, на первый взгляд, не так уж сильно Томита уступает SPARQL, который использует Ватсон.
Ох нет, SPARQL же совсем про другое — это хитрые запросы к базе данных. А Томита — это инструмент для доставания фактов из текста, т.е. очень упрощенно, для создания базы фактов.
Я лажанулся, и не успел поправить комментарий. Имелся в виду, конечно же, не сам SPARQL, а ту часть Ватсона, которая как раз извлекает факты из документов (или он пользуется уже готовой базой, которая хз как составлена? в таком случае, у вас всё существенно круче).

Попробую еще раз: Ватсон = (1) Извлечение фактов из документов + (2) морфологический поиск по базе + (3) байесовский вывод. Третий компонент не завязан на естественном языке, для второго есть решения для русского языка (не мне вам напоминать ;) ), не хватало только (1). Томита, если я все правильно понял, закрывает этот пробел.
IBM довольно туманно рассказывает о том, как пополняется база Ватсона. Но думаю, что не обошлось без майнинга из обычных текстов. Другое дело, что для извлечения фактов есть масса разных подходов, далеко не всегда rule-based, который и представляет Томита, является оптимальным.
Да, я так и не смог найти никакой информации о том, как же все-таки появляется база узлов, которая обрабатывается Ватсоном. Но при любом раскладе, rule-based лучше, чем руки-based, которым сейчас пользуются в этой области для русских текстов
Затем и выкладываем :)
Это вряд ли, но для формализации медицинских текстов и (в дальнейшем) их перевода между мировыми языками должен подойти.
Я собираюсь попробовать это в ближайшее время.
Не совсем подходящий инструмент.
Почему — я сам не работал, а знакомые решали аналогичную задачу и вроде как решили, но инструментами, которые пытаются работать глубже — со смыслом языка, а не только со структурой предложений. Томита-парсер давал в общем качественную картинку, но иногда были такие ошибки, которые могли критично сказаться на здоровье больного, и исправить их мог только врач, знакомый как с основами физиологии так и с историей болезни.
Простите, а не подскажете, что это за инструменты работающие на уровне смыслов?
Молодцы, что назвали хороший проект без ругани и наркотиков.
Если меня в письме пошлют подальше, то Яндекс сумеет определить, куда именно…
Покажет на карте и внесёт путешествие в календарь
И предложит заказать билеты
У нас в проекте, Томита парсер используется для определения «эмоционального окраса» текста. Очень удобная вещь!
Могли бы вы привести пример эмоционального окраса текста?
Моё сообщение выше. Тональная оценка «позитив», допишем к нему еще одно предложение «я без ума от этого парсера!» — определим эмоцию «восхищение». Все просто:)
Если можно, пару вопросов:
1. а какова скорость работы этой штуки?
т.е. сколько текста (в кб/сек) она сможет окрасить?
2. Что будет, если в одном тексте есть и позитив и негатив?
На очень сложны грамматиках скорость порядка 80 мб/час.
1. Замеры делали в самом начале разработки. 5.тыс «рыбных» комментариев(1 комментарий ~ 400 символов) с 20 простыми цепочками обработались за ~10сек
2. Тональная оценка выводится исходя из баллов по шкале.
Расскажите, пожалуйста, подробнее! Нам очень интересно :)
Ведем разработку сервиса мониторинга социальных медиа. Для определения тональности, было решено использовать метод машинного обучения. Тут-то томита парсер с цепочками и пришелся как нельзя кстати, сэкономив нам кучу времени:-)
Не очень понятно, как Томита может вам помочь с определением тональности машинным обучением. Найти окрашенные слова в тексте и так можно. Машинное обучение вы можете сделать и по размеченным текстам (а такие есть?). Томита же разбирает цепочки слов по правилам. Что это позволяет вам определить?
Расскажите, пожалуйста что за сервис. Ну и как успехи было бы тоже интересно узнать.
Перед нами сейчас похожая задача стоит.
Интересно, а вы подаёте ему на вход словарь эмоционально окрашенных слов (хороший, удобный,..) или Томита сам их знает и понимает цвет и степень окраски?
В Томиту зашит только морфологический словарь, всю остальную информацию нужно подавать на вход, а потом интерпретировать самостоятельно.
Помимо русского и украинского языков могут ли задаваться правила для работы с другими языками, напиример, английским, немецким, а может быть китайкским?
Чтобы включить новый язык, нужно подключить морфологию этого языка. Мы не можем по разным причинам сейчас выкладывать морфологии других языков. Китайский вообще устроен по другому, чтобы он заработал надо что-то специальное делать.

В общем, когда выложим в open source, все желающие смогут сами подключать другие языки.
Жаль, буду надеяться, что английский и другие языки появится вскоре после появления сорцов, уж очень интересно выглядит.
Для английского есть бесконечное количество похожих инструментов. Самый известный, наверное, — это GATE, в составе которого есть язык описания грамматик JAPE. И еще StanfordNLP — пакет машиннообучаемых обработчиков, которые можно тренировать на своих данных.
После слов «планируем отдать эту технологию в open source» пролистал вниз, поставил плюсик и лишь потом вернулся и дочитал. Спасибо!

Остаётся всего один неоднозначный момент.

Изменятся ли условия использования после открытия кода? Анализатор хорошо работает уже сейчас, однако последняя часть пункта 3.2 текущего лицензионного соглашения запрещает любое более-менее практическое применение «Томиты».
Про лицензию мы думаем и совещаемся с юристами. К сожалению, пока больше ничего не могу сказать.
UFO just landed and posted this here
Задание с финала школьной олимпиады Китая 2018 года по хакерству:
— сгенерируйте предложение, на разбор которого парсер с указанной грамматикой потратит более 32ГБ памяти.
Уже было, «Зенитные кодексы Аль-Эфесби».
Имел дело с Томита-Парсером, вставлю свои пять копеек как «простой пользователь». Эта штука несомненно одна из самых крутых технологий, которая имеется у Яндекса, это подтверждают в личной беседе все связанные с ней яндексоиды. Но у этого есть и обратная сторона — полноценную Томиту Яндекс уж очень навряд ли откроет для всех желающих, и здесь их можно понять. Та Томита, что выложена на всеобщее обозрение, во-первых отстает на много версий от той, что используется внутри компании (это обычная практика), во-вторых даже беглое чтение документации намекает, что множество крутых фич в общедоступной версии вырезано наживую. «Открытый» Томита-Парсер нужен Яндексу чтобы показать кусочек наикрутейшей технологии, а потом собрать сливки — для компании это очень правильный шаг, а вот к «отдать в опенсорс» я отношусь скептически. Возможно отдадут базовую функциональность в виде GLR-анализатора и оберток к нему, уже будет неплохо. Надеюсь ее хотя бы причешут до нормального демона, а пока это лишь очень клевая игрушка для тех, кто «в теме».

Наткнулся на Томита-Парсер я тогда, когда собирал материал для своей диссертации. Мне как раз понадобился инструмент извлечения фактов и Томита очень понравилась. Вдохновившись ей я даже написал свою небольшую библиотечку на Python, которую выложил на гитхаб: github.com/vas3k/python-glr-parser

Она в каком-то роде повторяет базовую (открытую) функциональность Томиты, проект молодой, нисколько не является конкурентом или opensource-версией Томиты, написан так сказать «для себя» и для собственного диплома. Но в области обработки естественного языка в России так мало всего написано, потому возможно кто-то захочет попробовать, поучаствовать или кого-то просто вдохновит идея.
Та Томита, что выложена на всеобщее обозрение, во-первых отстает на много версий от той, что используется внутри компании (это обычная практика)


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

во-вторых даже беглое чтение документации намекает, что множество крутых фич в общедоступной версии вырезано наживую


Это тоже не так. Есть некоторые фичи, которые недокументированны. Но только потому, что они работают не совсем так, как должны.

Возможно отдадут базовую функциональность в виде GLR-анализатора и оберток к нему, уже будет неплохо.


Мы собираемся, если уж открывать, то практически все. С точностью до определенных фичей из морфологии.
Это тоже не так. Есть некоторые фичи, которые недокументированны. Но только потому, что они работают не совсем так, как должны.

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

Возможно дело в недостатке документации, если в опенсорс-проектах всегда можно почитать код, то здесь можно полагаться только на документацию. Например те же алгоритмы выделения ФИО и другие описаны скомкано, у меня не получилось их заюзать.

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

Я пока скептичен, но вы не поверите как я буду рад ошибаться! Открывайте, я представляю объем вкусняшек, которые можно будет оттуда вытащить и уже истекаю слюнями.
Помета geo-agr абсолютно бесполезна без гео-данных, к которым она привязана. А их мы никогда не будем открывать из-за проблем с лицензированием. Ну и вообще, они слишком ценные, чтобы их раздавать просто так :)

Алгоритм выделения ФИО как раз относится к тем вещам, которые работают не так, как должны.

Надеюсь, что Вы не разочаруетесь :)
Геоданные можно нагенерировать из Википедии или из OpenStreetMap. Так что если в документации не описано, какой формат поддерживает geo-agr, это, наверно, неправильно.
Надо будет либо убрать пока помету, либо пример сделать нормальный. Второй вариант мне больше нравится.
Сырцы??? Что значит «в бинарном виде»? На кой ляд?
Подготовка к открытию исходных кодов уже началась, но процесс этот не такой быстрый, как нам бы хотелось, и, скорее всего, продлится до конца этого года.… любой желающий может воспользоваться [Томита-парсером] уже сейчас: бинарные файлы доступны для скачивания.
Является ли Томита родственником разработок aot.ru/? Год назад я пытался использовать их наработки. Интересовал модуль построения семантического графа. К сожалению, так и не смог его собрать. Единственное что получилось — автоматическое склонение ФИО на C#.
Да, в некоторой степени является.
Буквально на днях получилось собрать АОТ для Linux/x64, там буквально в одном-двух местах нужно подправить #include. Могу выслать Вам патч.

Впрочем, если Вас интересует не синтаксический, а сугубо морфологический анализ или стемминг — рекомендую воспользоваться библиотекой LanguageTool. Наработки АОТ для русского языка туда уже вошли.

Если же вас интересует просто стемминг — то можно вообще взять Hunspell.
Простите за офтоп, но картинкой навеяло: на словах ты Лев Толстой, после парса — бот простой.
В свете появления такого инструмента думаю неплохо бы напомнить об открытом неделю назад конкурсе Фонда перспективных исследований посвященному интеллектуальным сервисам и технологиям поиска информации в сети. Там как раз есть пункты где парсер однозначно пригодится, например:
— технологий умного поиска (формирование ответов на конкретные вопросы), смыслового (контекстного) анализа запроса и результатов поиска;


Страничка конкурса: fpi.gov.ru/activities/ideas/search
Татьяна, а без статичных грамматик пробовали? По себе знаю, что составление таких правил — то еще удовольствие. Сейчас ведь появились уже всякие вкусные вещи типа рекуррентных сверточных сетей, с которыми можно автоматически строить грамматики (т.е. деревья разбора).
Все зависит от задачи, от возможностей нанять асессоров и т.д. и т.п.
Есть простые типы данных, например адреса, которые проще описать ручными правилами, чем обучать сети на большой разметке. Т.е. правила обойдутся дешевле.
Есть более сложные случаи, когда дешевле и эффективней разметить корпус и обучить на нем.
Иногда имеет смысл делать что-то среднее, простые случаи брать ручными грамматиками, переферийные — обучением.
Добрый день,

Насколько я понимаю парсер заточен на работу с украинским и русским языками, скажите пожалуйста а возможно ли его так же заточить например на французский или голландский? Если да то не могли бы вы объяснить что для этого нужно. Спасибо.
Выбор языков зависит исключительно от имеющейся морфологии. По разным причинам мы не можем отдавать морфологии других языков. Поэтому прямо сейчас сделать что-то осмысленное с французским и голландским не получится.
Когда мы выложим парсер с исходным кодом, там будет возможность подключить любую другую морфологию самостоятельно.
Интересная технология. Скажите пожалуйста, правильно ли я понимаю, что используя её, можно создать систему оценки соответствия произвольной фразы по заданному словарю, включащему объекты и возможные действия над ними? Т.е. в контексте управления «умным домом» не привязывать пользователя к определённому формату общения с системой, а пытаться самостоятельно определить, соответствует ли произнесённая фраза какой-либо команде, поддерживаемой системой.
Система предназначена для выделения смысловых предописанных цепочек из обычного теста. Ее можно использовать и для выделения команд. Степень соответсвия она не умеет оценивать, для этого нужно будет писать свой постпроцессинг.
А почему правила описываются каким-то AnyWord<h-reg1, l-quoted>, а не регулярным выражением?
Потому что ими можно описать больше, чем регулярными выражениями.
Татьяна, хотел спросить: а если выполняется ли какая-либо дополнительная обработка данных после извлечения фактов Томита-парсером? Просто если он сможет выдернуть из текста достаточно фактов о людях — не значит, что их можно склеивать просто по близости расположения.
Конечно производится, постобработка — наше всё. :)
В зависимости от задачи мы тем или иным способом стараемся верифицировать данные, которые принес нам парсер.
А можно вкратце, описать принципы лежащие в постобработке (связке фактов)? Ведь более менее сложное предложение на русском языке представляет собой достаточно сложную схему речевых шаблонов (из которых парсер формирует факты) и которые могут по-разному свзываться в рамках предложения (дру с другом, согласовываться по времени, отмечать степень влияния друг на друга и т.д.)
Зависит от задачи.
Когда мы извлекали информацию о персонах из СМИ, то за извлечением фактов стояла огромная машина с кластеризацией, она верифицировала факты из разных источников, склеивала дубли и еще много всего делала.
Всегда было интересно узнать, а так же подчерпнуть новых идей из реально существующих проектов. Были ли у Яндекса публикации по данной тематике или есть возможность указать материалы, лежащии в основе данной вышестоящей системы?
Публикация была одна, но я не могу ее найти. Есть моя старая лекция: nlpseminar.ru/archive/lecture32/, к сожалению ничего получше не нашлось.
Можно конечно выполнить ещё более высокую абстракцию, типа «парсер результатов анализа парсера», но это уже что-то на уровне фактов-смысла, а не синтаксиса-морфологии. При этом возможность четкого декларативного описания подобных вещей мне представляется достаточно сложным вопросом. Или это был достаточно механический, статистический способ решения на базе машинного обучения?
Мне трудно так абстрактно рассуждать, поскольку действительно все зависит от задачи.
Итоговые факты же типизируются априори и выдаются в структурированном виде, это значит, что перепарсивать их уже незачем. Их можно фильтровать, кластеризовать, классифицировать, делать сложные умозаключения и т.д. и т.п.
Постараюсь посмотреть в ближайшее время видео по представленной ссылке, но похоже у меня немного другое понимание факта, извлекаемого парсером. В разрабатываемых прототипах факты, извлекаемые из предложения «Мэр города Саратов 22 июня посетил для открытия выставки местного художника краеведческий музей города» были чем-то вроде «ДолжностноеЛицо», «ПрибылКудаТо», «ОргМероприятие», «Дата», которые после этого можно было связать в некие связки «Кто-Где-Когда» как раз с помощью парсинга 2-го уровня.
В Вашем варианте под фактами, извлекаемыми на 1-м уровне, понимаются такие результаты как уже «Кто-то посетил Что-то», получаемые с помощью достаточно широкого набора правил. Верно?
Ну да, это скорее просто именованные сущности, а факт — это именованная сущность + атрибут или несколько именованных сущностей и отношения между ними.
Но Томита подходит для извлечения и того, и другого.
Вопрос по практическому использованию парсера: ф-л программы очень богатый, как и сам язык — соответственно для создания реальных наборов грамматик для жизненных ситуаций (которые (грамматики) д.б. достаточно большими) необходимо что-то вроде среды разработки/отладки. Тот ф-л отладки, что есть в распространяемой сборке совсем небольшой. Есть ли такой продукт внутри Яндекса? МОжно посмотреть хотя бы на скриншоты?
Такого инструмента нет. Среднестатистический томита-писатель привыкает с notepad++ за неделю-другую. Компилятор обычно довольно внятно описывает ошибки, если они произошли при компиляции. А для отладки выхода грамматик есть pretty output — он описан в документации.
В документации (в разделе про выделение ключевых слов) есть упоминание про алгоритм выделения ФИО. Можно узнать, на базе чего он основан (о ключевых моментах реализации)?
Отбой. Если кому интересно Яндекс некоторое время назад опубликовал исходные тексты tomita парсера (http://github.com/yandex/tomita-parser). Надо признать кода очень много и изучить его работы изнутри будет достаточно интересно, но касательно заданного вопроса вывод такой: используются данные из mystem и достаточно большое кол-во правил (код на C++).
Sign up to leave a comment.