Всегда было интересно узнать, а так же подчерпнуть новых идей из реально существующих проектов. Были ли у Яндекса публикации по данной тематике или есть возможность указать материалы, лежащии в основе данной вышестоящей системы?
А можно вкратце, описать принципы лежащие в постобработке (связке фактов)? Ведь более менее сложное предложение на русском языке представляет собой достаточно сложную схему речевых шаблонов (из которых парсер формирует факты) и которые могут по-разному свзываться в рамках предложения (дру с другом, согласовываться по времени, отмечать степень влияния друг на друга и т.д.)
Татьяна, хотел спросить: а если выполняется ли какая-либо дополнительная обработка данных после извлечения фактов Томита-парсером? Просто если он сможет выдернуть из текста достаточно фактов о людях — не значит, что их можно склеивать просто по близости расположения.
Но такие правила (с небольшими изменениями) действуют не во всех информационных доменах – при изменении правил оформления документов или наборного персонала требуется вносить изменения для повышения качества выделения предложений.
Это обобщённый алгоритм, который работает на большинстве тектов, но не гарантирует корректность на всех. Тут как раз та самая ситуация со сменой наборного персонала или стиля написания текста.
Существуют статистические методики на основе анализа последовательности частей речи из которых состоит текст для определения границ предложения. Но сама цель анализа подобных безграмотных предложений достаточно сомнительна — если человек не может составить корректное предложение, то информационная ценность такого текста достаточно низка.
Заметил, что авторы большинства комментов на посты модульному тестированию делятся на 2 части: те кто убеждают делать тестирование и описывают преимущества и те, кто делать их не хочет и описывает сложности и тщетность этой работы.
Сразу вспоминаетсы высказывание: «Кто хочет делать работу — найдёт средства, кто не хочет — найдёт отговорки».
Суть в том, что спорь не спорь — время покажет кто прав: у тех, у кого нет тестирования, судьба одна: сложно поддерживаемый код, долгие периоды внесения изменений, «хрупкость» кода, низкий потолок роста численности команды или вечное написание маленьких программ, где есть код, который «только работает».
Полагаю подобных вещей происходить не будет: JSON это не XML, а XML это не JSON. Заменить одно другим без потери в чём-то невозможно: где-то потеряете гибкость структурах, где-то потеряете лёгкость извлечения данных, где-то потеряете во взаимодействии между разными системами, где-то потреяете в скорости обработки и объёме. Области использования, хоть и пересекаются в некоторых областях, не одни и те же.
Проверить вручную 1000 записей оказалось не так сложно. Заняло это порядка 2-3 часов (почти нечего по сравнению с 3 днями основной работы).
В явном виде хранятся для решения проблем чередования букв в корне при склонениях и подобных проблем.
Но не хочу вводить в заблуждение — ЭТА база используется лишь для хранения оригиналов, простоты редактирования и для облегчения сбора статистики. Для работы морф. модуля строится специальное дерево.
1) Суть записей N/2 в том, что они отражают не оптимальный или худший случай, а средний.
2) Не хочу обижать, но для тех, кто более-менее знаком со струтурами данных, используемых в обработке – эти названия должны быть знакомы. Выбор – извлечение элемента по ключу.
3) Верно – поправил.
4) Дерево бинарного поиска (BST) строится по довольно чётким и давно определённым правилам. По хэширование согласен, но написать хотел всё же про структуры.
Вот что делает невнимательность! Фраза была «Подняв БЫ его…»
Я забросил HMM таггер года 2 назад. Тогда корректно разрешалось около 60% неизвестных слов. Знаю, что сейчас HMM таггеры работающие на триграммах достигают правильного разрешения 80-85% неизвестных слов. Для английского – 95-98%.
Текущий алгоритм разрешает около 25-30% неизвестных слов (надеюсь это связано с его недоделанностью, а не с ошибкой в самой идее).
Вопрос прямо по существу.
Попробую ответить так же:
Использовал HMM как средство борьбы с омонимией (был в своё время проект на C). Но в связи с недостатком размеченных данных для обучения он слишком часто давал сбои на русском тексте. Подняв его сейчас и «обучив» доступными данными точность предсказания можно было бы поднять до приемлемой. Но я пошёл другим путём – омонимию снимаю на более высоком уровне.
HMM можно использовать как средства выявления ошибок/опечаток, для определения авторства текста (на более-менее больших объёмах), при распознавании текстов можно использовать как средство корректировки ошибок распознавания (те же очепятки). Но сам этим никогда не занимался.
Лучший результат, конечно, даст разрешение на более высоком уровне с использованием контекста и анализом синтаксиса предложения. Но готовых сравнительных данных нет – модуль в работе (и готов будет не скоро). Но у него есть и свои минусы: скорость работы, сложность самого алгоритма, необходимость описания правил.
А вы пробовали это сделать? Он доступен только для онлайн-поиска.
Надо сказать тут Вы меня поймали.
В своей разработке я не использую HMM – хоть это и сильно бьёт по производительности.
Послав в своё время запрос в «ruscorpora» по поводу предоставления доступа к их данным не через веб-интерфейс, мною был получен следующий ответ:
Просим прощения за поздний ответ.
Пока мы не выдаём Национальный корпус или его части для оффлайновой обработки, но мы работаем над соответствующей лицензией. Как только она появится, мы Вам сообщим.
С уважением,
разработчики Национального корпуса.
Не сказать, чтобы это был неожиданный ответ. Возможно, мы в своё время и получим доступ к их данным с использованием другого интерфейса но, скорее всего это потребует раскрытия кода продукта, либо части ответственной за морфологический анализ.
Мы в своё время с коллегами рассматривали вопрос о формировании собственного корпуса (с ограниченным доступом через веб-сервисы SOAP/REST), сформированного с использованием собственного морфоанализатора, но для этого его ещё требуется довести до ума и поднять скорость работы. Вопрос отложили до мая 2011.
Разумеется. Можно использовать не последние 1 или 2 слова, а 3 и больше. Но это потребует более крупного объёма обучающих данных. В противном случае каких-то комбинаций просто не будет и тэггер будет выдавать нулевую вероятность или вероятность однажды встреченной комбинации. Плюс большое время обучения тэггера думаю при увеличении размера «хвоста» время будет увеличиваться на порядке. Плюс увеличится время работы самого тэггера. Тут приходится выбирать между минусами и точностью «предсказания» в зависимости от конкретных требований к работе тэггера.
Да и ситуация в России с размеченными корпусами гораздо хуже, чем в остальных странах. Их просто мало.
Опрос пришлось закрыть, так как он не выполняет той функции, что я рассчитывал на него возложить (по моей же вине). Но буду рад узнать Ваше мнение в виде комментариев.
Насколько я понимаю тематика для многих очень интересная, но слишком э… «труднопроходимая» в связи с требованиями к знаниям из совершенно другой области, чем той, в которой большинство IT-специалистов специалисты.
Это обобщённый алгоритм, который работает на большинстве тектов, но не гарантирует корректность на всех. Тут как раз та самая ситуация со сменой наборного персонала или стиля написания текста.
Сразу вспоминаетсы высказывание: «Кто хочет делать работу — найдёт средства, кто не хочет — найдёт отговорки».
Суть в том, что спорь не спорь — время покажет кто прав: у тех, у кого нет тестирования, судьба одна: сложно поддерживаемый код, долгие периоды внесения изменений, «хрупкость» кода, низкий потолок роста численности команды или вечное написание маленьких программ, где есть код, который «только работает».
* yajl-ruby — binding для Ruby
* yajl-objc — binding для Objective-C
* YAJL — binding для IO
* py-yajl, yajl-py — binding для Python
* yajl-js — binding для node.js
* lua-yajl — binding для lua
* ooc-yajl — binding для ooc
* yajl-tcl — binding для tcl
В явном виде хранятся для решения проблем чередования букв в корне при склонениях и подобных проблем.
Но не хочу вводить в заблуждение — ЭТА база используется лишь для хранения оригиналов, простоты редактирования и для облегчения сбора статистики. Для работы морф. модуля строится специальное дерево.
2) Не хочу обижать, но для тех, кто более-менее знаком со струтурами данных, используемых в обработке – эти названия должны быть знакомы. Выбор – извлечение элемента по ключу.
3) Верно – поправил.
4) Дерево бинарного поиска (BST) строится по довольно чётким и давно определённым правилам. По хэширование согласен, но написать хотел всё же про структуры.
Я забросил HMM таггер года 2 назад. Тогда корректно разрешалось около 60% неизвестных слов. Знаю, что сейчас HMM таггеры работающие на триграммах достигают правильного разрешения 80-85% неизвестных слов. Для английского – 95-98%.
Текущий алгоритм разрешает около 25-30% неизвестных слов (надеюсь это связано с его недоделанностью, а не с ошибкой в самой идее).
Попробую ответить так же:
Надо сказать тут Вы меня поймали.
В своей разработке я не использую HMM – хоть это и сильно бьёт по производительности.
Послав в своё время запрос в «ruscorpora» по поводу предоставления доступа к их данным не через веб-интерфейс, мною был получен следующий ответ:
Не сказать, чтобы это был неожиданный ответ. Возможно, мы в своё время и получим доступ к их данным с использованием другого интерфейса но, скорее всего это потребует раскрытия кода продукта, либо части ответственной за морфологический анализ.
Мы в своё время с коллегами рассматривали вопрос о формировании собственного корпуса (с ограниченным доступом через веб-сервисы SOAP/REST), сформированного с использованием собственного морфоанализатора, но для этого его ещё требуется довести до ума и поднять скорость работы. Вопрос отложили до мая 2011.
Да и ситуация в России с размеченными корпусами гораздо хуже, чем в остальных странах. Их просто мало.
Насколько я понимаю тематика для многих очень интересная, но слишком э… «труднопроходимая» в связи с требованиями к знаниям из совершенно другой области, чем той, в которой большинство IT-специалистов специалисты.