pymorphy2
pymorphy2 copied to clipboard
kmike
Есть мысль расширить опции компиляции словаря
Я тут уже писал в предыдущих заявках , что есть потребность некоторые связи слов и сокращений оставлять в dawg словаре, а некоторые нет (скажем килограмм-кг, оставить, а век-в убрать). Сейчас я так понял в коде словаря просто все связи FULL-CONTRACTED отбрасываются. Соответственно хочется сделать так что бы мы могли управлять списком связей которые не идут в словарь и те которые идут, а так же что бы те которые идут можно было тоже персонально перечислить. Вопрос:
- на сколько это видится полезным остальным что бы код потом был обратно принят
- в каком формате это лучше делать? Создать еще одну опцию и передавать ей xml? Если xml, то какого вида? предполагаю что-то типа
<allowed_type_links>
<type_link type_id="21">
<link id="1234"/>
</type_link>
</allowed_type_links>
или может лучше более плоскую структуру?
<allowed_type_links>
<link id="1234" type_id="21"/>
</allowed_type_links>
Сейчас мне вот не совсем понятно на сколько исходный словарь постоянен в плане id? Не меняются ли id у одних и тех же сущностей (в частности связей) со временем от версиии к версии?
Я по прежнему не понимаю, в чём проблема наличия сокращений в словаре. У сокращений же, кстати, есть специальный тег, да?
2018-03-30 12:00 GMT+07:00 V-ctor [email protected]:
Я тут уже писал в предыдущих заявках , что есть потребность некоторые связи слов и сокращений оставлять в dawg словаре, а некоторые нет (скажем килограмм-кг, оставить, а век-в убрать). Сейчас я так понял в коде словаря просто все связи FULL-CONTRACTED отбрасываются. Соответственно хочется сделать так что бы мы могли управлять списком связей которые не идут в словарь и те которые идут, а так же что бы те которые идут можно было тоже персонально перечислить. Вопрос:
- на сколько это видится полезным остальным что бы код потом был обратно принят
- в каком формате это лучше делать? Создать еще одну опцию и передавать ей xml? Если xml, то какого вида? предполагаю что-то типа
<allowed_type_links> <type_link type_id="21"> </type_link> </allowed_type_links>
или может лучше более плоскую структуру?
<allowed_type_links> </allowed_type_links>
Сейчас мне вот не совсем понятно на сколько исходный словарь постоянен в плане id? Не меняются ли id у одних и тех же сущностей (в частности связей) со временем от версиии к версии?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kmike/pymorphy2/issues/109, or mute the thread https://github.com/notifications/unsubscribe-auth/AABShAFJ79bYKr3XCsoqfNarF6PX4RzLks5tjbwBgaJpZM4TBTQe .
-- Best regards, Yuri V. Baburov, Skype: yuri.baburov
Проблема такая что лемматизация слова "век" выдаст нам кроме всего прочего сокращения "вв" и "в", вот "вв" хорошее доброе сокращение, а "в" не очень ибо это и предлог. Поскольку потом весь этот набор уходит в ElasticSearch и инфы и том предлог/сокращение, на сколько я понимаю, уже не передается, то у нас происходит в нем неверное индексирование и неверный поисковый запрос , итог неверная выдача. Ввели слово "век", получили все записи где есть слово "век" , а так же предлог "в".
А какое отношение имеет pymorphy к тому, что потом этот набор уходит в ElasticSearch ? Разве вы не можете добавить проверку и убрать леммы типа "сокращение" из результатов поиска?
@V-ctor , все сокращения "одинаково хороши". "вв" - это "века", получается что для "14-15 вв" ваш поиск поймет, что это века, а "20 в" уже не поймет. Вам либо надо ко всем сокращениям добавлять точку принудительно (на уровне кода между Pymorphy2 и Elastics), либо вообще не учитывать сокращения.
@buriy , так я и пишу, что мы не можем все сокращения отбросить, часть нужных и хороших, не сбивающих с толку. Формально PyMorphy не имеет отношения к ElasticSearch, просто коли у нас он выбран в качестве морфологического анализатора на ElasticSearch (через порт-плагин jmorphy), то он отвечает за морфологический анализ, а поскольку учета контекста там нет, то имеем кучу ложных срабатываний.
@insolor Сокращения хороши, но в итоге имеем множество ложных срабатываний там где сокращения совпадают или с отдельными словами или имеют одинаковое сокращение от разных слов, например строение - стр и страница - стр. При вводе стр получим все упоминания про строения и страницы. Было решено что какие-то связи оборвем в словаре, а какие-то оставим. Например, аналитики проведя изучение по корпусам текстов или еще как пришли к выводу что стр в связке со страницей употребляется чаще чем со строением, соотв. оставляем страница-стр, рвем строение-стр. Да теперь по стр не находим строения. Но чем-то приходится жертвовать.
@V-ctor можно такой вариант использовать: убирать все сокращения из выдачи Pymorphy2, сделать свою табличку сокращений, и по ней искать сокращения.
Ну и потом сейчас в коде compile.py есть такие строки:
EXCLUDED_LINK_TYPES = set(['7', '21', '23', '27'])
for link_start, link_end, type_id in links: if type_id in EXCLUDED_LINK_TYPES: continue
т.е. по умолчанию сейчас при компиляции эти связи итак не попадают в словарь, просто это хардкодом, я же предлагаю сделать это в виде внешних настроек , передаваемых через параметры. Чем плохо?
На всякий случай еще раз обращу внимание, что доработки делаться будут мной. Просто хотелось бы что бы код потом был принят обратно.
@V-ctor ок, давайте попробуем сначала . Зачем вам самому компилировать словари? Чтобы увеличить скорость, убрав оттуда часть информации? Ведь иначе вы можете сделать все действия по "отбраковке" после поиска по скомпилированному словарю, но если вы уберёте часть информации, то вы не сможете ей воспользоваться. Или я неправильно вас понял, и информация о том, что "слово является сокращением и требует после себя точки в тексте" вашему коду не поступает, а доступны только варианты "в" и "век" для "в" и различить их нельзя? (Аналогично с другими признаками: того#Geox не должно быть написано с маленькой буквы, вася#Name не может начинаться с маленькой буквы, а КПРФ#Abbr должно быть написано большими буквами.)
@kmike проверил по предпоследней версии:
- я не могу с помощью pymorphy отличить КПРФ#партия, МГУ# от в#век и вв#века , а для них синтаксические характеристики должны различаться! "кпрф" , "мгу" и "в" имеют Fixd и Abbr, "вв" только Abbr. (дополнительно кпрф имеет признаки "Orgn" и Sgtm").
ср#сравнить имеет Abbr, ср#среда -- Fixd Abbr
Где логика? Как этим предлагается воспользоваться?
Предлагаю ввести дополнительный тег для понятия "сокращение", иначе пользователи не смогут нормально пользоваться сокращениями.
@buriy , смотрите 1 Да у нас большие объемы обработки данных до миллиона статей в сутки и не хотелось бы вводить дополнительные задержки на постобработку 2 Точки в выдче Pymorphy нет, т.е. даем на вход слово "век", имеем все возможные леммы включая "в" (да она помечена как сокращение), но у нас дальше весь этот набор лемм уже без аттрибутов уходит в эластик, соотв он найдет по всем вхождениям "век" и "в". Осутствие точки понятно ее в словаре нет. 3 Потом , наличие точки не решило бы всех проблем т.к. одно и то же сокращение может иметь несколько разных полных форм скажем "г" это и год и господин и город и грамм. Без контекста опять же не можем отличить, а контекст не учитывается. 4 Но и да инфы о том сокращение это или нет не поступает, поступает просто набор лемм по которым можно искать и/или индексировать текст.
Обычно такие частотные и короткие слова, как "в", заносят в стоп-список: https://www.elastic.co/guide/en/elasticsearch/guide/current/stopwords.html . Но я ничего не имею против выноса EXCLUDED_LINK_TYPES в опцию.
