Nltk: Включить более точный разделитель предложений, токенизатор и / или лемматизатор для английского языка?

+1 @nschneid Большая часть работы Ребекки связана с HPSG, которую я хотел бы интегрировать в NLTK, но это крепкий орешек. @goodmami , @fcbond и группа DELPH-IN проделали некоторую работу с https://github.com/delph-in/pydelphin

Возможно, обертка Python для Реппа может стоить кода =)

Есть одно по токенизации слова , и то и это по разделению предложений.

Глядя на цитирующие статьи, я вижу то и это для различных жанров веб-текста. Также это для новостной области.

@nschneid после некоторого изучения кода REPP оказалось довольно много правил LISP, написанных в отдельном файле. Возможно, первое, что мы могли бы попробовать, - это организовать их все в один текстовый файл, а затем написать оболочку для чтения этих правил. Или, возможно, проще просто обернуть весь инструмент, как то, что мы сделали с nltk.tag.stanford :

alvas<strong i="8">@ubi</strong>:~/repp$ cat test.txt
Tokenization is widely regarded as a solved problem due to the high accuracy that rulebased tokenizers achieve. 
But rule-based tokenizers are hard to maintain and their rules language specific. 
We show that high accuracy word and sentence segmentation can be achieved by using supervised sequence labeling on the character level combined with unsupervised feature learning. 
We evaluated our method on three languages and obtained error rates of 0.27 ‰ (English), 0.35 ‰ (Dutch) and 0.76 ‰ (Italian) for our best models.

alvas<strong i="9">@ubi</strong>:~/repp$ cat test.txt|src/repp -c erg/repp.set 
Tokenization is widely regarded as a solved problem due to the high accuracy that rulebased tokenizers achieve .
But rule-based tokenizers are hard to maintain and their rules language specific .
We show that high accuracy word and sentence segmentation can be achieved by using supervised sequence labeling on the character level combined with unsupervised feature learning .
We evaluated our method on three languages and obtained error rates of 0.27 ‰ ( English ) , 0.35 ‰ ( Dutch ) and 0.76 ‰ ( Italian ) for our best models .

alvas<strong i="10">@ubi</strong>:~/repp$ cat test.txt|src/repp -c erg/repp.set --format triple
(0, 12, Tokenization)
(13, 15, is)
(16, 22, widely)
(23, 31, regarded)
(32, 34, as)
(35, 36, a)
(37, 43, solved)
(44, 51, problem)
(52, 55, due)
(56, 58, to)
(59, 62, the)
(63, 67, high)
(68, 76, accuracy)
(77, 81, that)
(82, 91, rulebased)
(92, 102, tokenizers)
(103, 110, achieve)
(110, 111, .)

(0, 3, But)
(4, 14, rule-based)
(15, 25, tokenizers)
(26, 29, are)
(30, 34, hard)
(35, 37, to)
(38, 46, maintain)
(47, 50, and)
(51, 56, their)
(57, 62, rules)
(63, 71, language)
(72, 80, specific)
(80, 81, .)

(0, 2, We)
(3, 7, show)
(8, 12, that)
(13, 17, high)
(18, 26, accuracy)
(27, 31, word)
(32, 35, and)
(36, 44, sentence)
(45, 57, segmentation)
(58, 61, can)
(62, 64, be)
(65, 73, achieved)
(74, 76, by)
(77, 82, using)
(83, 93, supervised)
(94, 102, sequence)
(103, 111, labeling)
(112, 114, on)
(115, 118, the)
(119, 128, character)
(129, 134, level)
(135, 143, combined)
(144, 148, with)
(149, 161, unsupervised)
(162, 169, feature)
(170, 178, learning)
(178, 179, .)

(0, 2, We)
(3, 12, evaluated)
(13, 16, our)
(17, 23, method)
(24, 26, on)
(27, 32, three)
(33, 42, languages)
(43, 46, and)
(47, 55, obtained)
(56, 61, error)
(62, 67, rates)
(68, 70, of)
(71, 75, 0.27)
(76, 77, ‰)
(78, 79, ()
(79, 86, English)
(86, 87, ))
(87, 88, ,)
(89, 93, 0.35)
(94, 95, ‰)
(96, 97, ()
(97, 102, Dutch)
(102, 103, ))
(104, 107, and)
(108, 112, 0.76)
(113, 114, ‰)
(115, 116, ()
(116, 123, Italian)
(123, 124, ))
(125, 128, for)
(129, 132, our)
(133, 137, best)
(138, 144, models)
(144, 145, .)

Возможно, есть ограничения в цепочке инструментов, когда они достигают парсера HPSG. Возможно, было бы лучше напрямую использовать ACE http://sweaglesw.org/linguistics/ace/ с использованием интерфейса pyDelphin .

Кстати, это также из набора инструментов Moses MT: https://github.com/moses-smt/mosesdecoder/tree/master/scripts/tokenizer . Для них было бы хорошо иметь лучшую согласованность между nltk.translate и mosesdecoder

Для справки есть также токенизатор Penn Treebank , искусство токенизации и био / медицинские токенизаторы.

@alvations Я не думаю, что мы ACE, только для токенизации, если вам не нужен морфологический анализ, определение местоимения, область действия квантификатора или что-то еще. Я не думаю, что было бы так уж сложно реализовать токенизатор REPP в pyDelphin , который не требует полных грамматик или парсеров (см. Недавно созданный delph-in / pydelphin # 43), или, возможно, такая реализация могла бы быть автономный модуль (т.е. отдельный от pyDelphin), который упростил бы включение в NLTK.

Но REPP - это, по сути, просто система регулярных выражений с некоторыми дополнительными тонкостями, поэтому я думаю, что основным преимуществом для NLTK является то, что он может использовать системы, разработанные для грамматик DELPH-IN. Однако в документе, на который ссылается @nschneid, говорится, что Дридан и Oepen «устраняют [d] две трети оставшихся ошибок токенизации» в данных PTB по сравнению с самой производительной системой на тот момент с помощью REPP. В связи с этим Fokkens et al.

@nschneid на данный момент, самое простое решение - это упаковка REPP и чтение выходных файлов, как и другие сторонние инструменты в NLTK. Это кажется достаточно простым и существует несколько реализаций. Я не уверен, какой из них выбрать, учитывая разнообразие решений: http://stackoverflow.com/questions/34416365/unpacking-tuple-like-textfile

Какую реализацию мы должны использовать для обертывания REPP в NLTK?

@goodmami Между тем, более медленным, но простым в обслуживании вариантом является переписывание регулярных выражений LISP + Perl + Boost, но я думаю, что мы можем сохранить это в pyDelphin вместо этого. Некоторые примечания: http://stackoverflow.com/questions/34048609/converting-c-boost-regexes-to-python-re-regexes Это будет медленным для меня, так как я заканчиваю свою докторскую работу. Я буду стараться изо всех сил, путешествуя по поездам / автобусам, которые должны убить некоторое время, пытаясь перенести регулярные выражения =)

У меня нет особых возражений против REPP, но, возможно, стоит изучить другие существующие инструменты.

Например, https://github.com/armatthews/TokenizeAnything написан на Python и утверждает, что делает что-то разумное для большинства языков. (Это довольно молодая реализация, но она основана на https://github.com/redpony/cdec/blob/master/corpus/tokenize-anything.sh, который существует уже некоторое время.) @Armatthews , как вы думаете, это было бы неплохо включить его в НЛТК?

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

• возможность разделить клитики, такие как "s" и "n't", или не на английском языке ( --no_english_apos в TokenizeAnything)
• смещается обратно в исходную строку

+1 за TokenizeAnything. Также есть https://github.com/jonsafari/tok-tok от @jonsafari.

Я написал небольшую оболочку для REPP: https://github.com/alvations/nltk/blob/repp/nltk/tokenize/repp.py. Сделаю PR, когда модули translate станут более стабильными.

Также перенесен tok-tok.pl в python: https://github.com/alvations/nltk/blob/repp/nltk/tokenize/toktok.py .

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

@goodmami Я бы разместил информацию на https://github.com/nltk/nltk/wiki/Installing-Third-Party-Software, как только у меня будет время для пиара. Обертку написал пока застрял в поезде без wifi =)

Я не уверен, работает ли REPP вне Linux, возможно, нам придется спросить Ребекку или Стефана, пытались ли они установить REPP на Windows / Mac. В какой-то момент я все еще хотел бы повторно реализовать REPP, но я не могу выделить столько времени еще какое-то время.

Если кто-то еще заинтересован в повторной реализации / упаковке других токенизаторов / стеммеров / лемматизаторов, я бы предложил следующий список инструментов, которые превратят good-first-contribution в NLTK.

• Токенизатор Moses + детокенизатор
• Слон
• Токенизировать что угодно

Извините, я закрыл проблему по ошибке. Сейчас он снова открыт.

Теперь, когда токенизатор и детокенизатор Moses работают (# 1551, # 1553), любой смельчак захочет попробовать заново реализовать Elephant с помощью sklearn ?

Начиная с # 1860, похоже, что TreebankTokenizer, который мы используем по умолчанию word_tokenize() , довольно устарел, а анализ URL и дат на самом деле не поддерживается.

Если присмотреться к регулярным выражениям TreebankTokenizer и MosesTokenizer, простого решения не существует.

Для TreebankTokenizer было бы проще отделить двоеточия от запятых на https://github.com/nltk/nltk/blob/develop/nltk/tokenize/treebank.py#L76

Для Моисея похоже, что токенизатор по умолчанию не заботился о сохранении чисел вместе:

$ echo 'This is a sentence with dates like 23/12/1923 and 05/11/2013, and an URL like https://hello.world.com' > test.in

$ ~/mosesdecoder/scripts/tokenizer/tokenizer.perl -l en < test.in 
This is a sentence with dates like 23 / 12 / 1923 and 05 / 11 / 2013 , and an URL like https : / / hello.world.com

Может, стоит рассмотреть более современный токенизатор в качестве NLTK default word_tokenize() ?

Может, стоит рассмотреть более современный токенизатор в качестве NLTK default word_tokenize() ?

Рассмотрим №2202? :)

Также следует отметить, что текущая ошибка (я имею в виду # 1214), похоже, пропускает метку токенизатора.

@alvations по- прежнему отсутствует метка: p