Nltk: Menggabungkan pemecah kalimat, tokenizer, dan/atau lemmatizer yang lebih akurat untuk bahasa Inggris?

+1 @nschneid Sebagian besar pekerjaan Rebecca ada di HPSG yang ingin saya integrasikan ke dalam NLTK tetapi ini sulit. @goodmami , @fcbond dan grup DELPH-IN telah melakukan beberapa pekerjaan dengan https://github.com/delph-in/pydelphin

Mungkin pembungkus python ke Repp mungkin bernilai kode =)

Ada satu di tokenization kata , dan ini dan ini di pemisahan kalimat.

Melihat mengutip makalah, saya melihat ini dan ini untuk berbagai genre teks web. Juga ini untuk domain berita.

@nschneid setelah beberapa trawl pada kode REPP, ada cukup banyak aturan LISP yang ditulis dalam file terpisah. Mungkin hal pertama yang bisa kita coba adalah mengatur semuanya menjadi satu file teks dan kemudian menulis pembungkus untuk membaca aturan ini. Atau mungkin hanya membungkus seluruh alat itu sendiri mungkin lebih mudah seperti yang kami lakukan dengan 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, .)

Mungkin ada kendala di rantai alat saat mencapai parser HPSG juga. Mungkin langsung menggunakan ACE http://sweaglesw.org/linguistics/ace/ menggunakan antarmuka pyDelphin akan lebih baik.

Di samping catatan ada juga ini dari toolkit Moses MT: https://github.com/moses-smt/mosesdecoder/tree/master/scripts/tokenizer . Untuk ini, akan lebih baik untuk memiliki konsistensi yang lebih baik antara nltk.translate dan mosesdecoder

Demi referensi, ada juga tokenizer Penn Treebank , seni tokenisasi dan tokenizer bio/medis

@alvations Saya tidak berpikir kita akan mendapatkan banyak dengan menggunakan parser penuh seperti ACE hanya untuk tokenization, kecuali jika Anda juga ingin analisis morfologi, atau deteksi kata ganti, atau lingkup quantifier, atau sesuatu yang lain. Saya tidak berpikir akan terlalu sulit untuk mengimplementasikan tokenizer REPP di pyDelphin yang tidak memerlukan tata bahasa atau parser lengkap (lihat delph-in/pydelphin#43 yang baru dibuat), atau mungkin implementasi seperti itu bisa berupa modul mandiri (yaitu terpisah dari pyDelphin), yang akan membuatnya lebih mudah untuk dimasukkan ke dalam NLTK.

Tetapi REPP pada dasarnya hanyalah sebuah sistem ekspresi reguler dengan beberapa tambahan, jadi saya pikir keuntungan utama untuk NLTK adalah bahwa ia dapat menggunakan sistem yang dikembangkan untuk tata bahasa DELPH-IN. Namun, makalah yang ditautkan oleh @nschneid mengatakan bahwa Dridan dan Oepen "menghilangkan [d] dua pertiga dari kesalahan tokenisasi yang tersisa" pada data PTB dibandingkan dengan sistem off-the-shelf berkinerja terbaik pada saat itu dengan menggunakan REPP. Pada catatan terkait, Fokkens et al.

@nschneid untuk saat ini, solusi paling sederhana tampaknya membungkus REPP dan membaca file output seperti alat pihak ketiga lainnya di NLTK. Tampaknya cukup sederhana dan ada beberapa implementasi. Saya tidak yakin yang mana yang harus dipilih mengingat beragam solusi: http://stackoverflow.com/questions/34416365/unpacking-tuple-like-textfile

Implementasi mana yang harus kita gunakan untuk membungkus REPP di NLTK?

@goodmami Sementara itu opsi yang lebih lambat tetapi lebih mudah dipertahankan adalah menulis ulang LISP + Perl + Boost regex tapi saya pikir kita bisa menyimpan ini di pyDelphin sebagai gantinya. Beberapa catatan: http://stackoverflow.com/questions/34048609/converting-c-boost-regexes-to-python-re-regexes Ini akan lambat bagi saya dan juga saya sedang menyelesaikan pekerjaan PhD saya. Saya akan mencoba yang terbaik saat bepergian dengan kereta api/bus yang seharusnya menghabiskan waktu dalam mencoba port regex =)

Saya tidak keberatan dengan REPP, tetapi mungkin perlu mengeksplorasi alat lain yang ada di luar sana.

Misalnya, https://github.com/armatthews/TokenizeAnything ditulis dengan Python dan mengklaim melakukan sesuatu yang masuk akal untuk sebagian besar bahasa. (Ini adalah implementasi yang cukup muda, tetapi didasarkan pada https://github.com/redpony/cdec/blob/master/corpus/tokenize-anything.sh , yang telah ada selama beberapa waktu.) @armatthews , menurut Anda apakah ide yang baik untuk memasukkannya ke dalam NLTK?

Pertanyaan lain yang lebih luas adalah opsi/fungsi apa yang kami ingin didukung oleh tokenizer. Misalnya, saya pikir akan berguna untuk memiliki:

• pilihan untuk memisahkan clitics seperti "'s" dan "n't" atau tidak dalam bahasa Inggris ( --no_english_apos dalam TokenizeAnything)
• offset kembali ke string asli

+1 untuk TokenizeAnything. Ada juga https://github.com/jonsafari/tok-tok dari @jonsafari.

Saya telah menulis pembungkus kecil untuk REPP: https://github.com/alvations/nltk/blob/repp/nltk/tokenize/repp.py . Akan melakukan PR setelah modul translate lebih stabil.

Port tok-tok.pl ke python: https://github.com/alvations/nltk/blob/repp/nltk/tokenize/toktok.py juga.

@alvations jadi Anda membungkus biner REPP alih-alih mengimplementasikan prosesor REPP? Maka akan lebih baik untuk memberikan tautan ke tempat seseorang bisa mendapatkan biner seperti itu. Dan saya belum pernah menggunakan biner REPP secara langsung --- apakah Anda tahu betapa portabelnya itu?

@goodmami Saya akan memasang informasi di https://github.com/nltk/nltk/wiki/Installing-Third-Party-Software begitu saya punya waktu untuk melakukan PR. Saya menulis bungkusnya saat terjebak di kereta tanpa wifi =)

Saya tidak yakin apakah REPP berfungsi di luar linux, mungkin kita harus bertanya kepada rebecca atau stefan apakah mereka sudah mencoba menginstal REPP di windows/mac. Saya masih ingin menerapkan kembali REPP di beberapa titik, tetapi saya tidak dapat memberikan waktu sebanyak itu untuk beberapa saat lagi.

Jika ada orang lain yang tertarik untuk mengimplementasikan kembali/membungkus tokenizers/stemmers/lemmatizers lain, saya akan menyarankan daftar alat berikut yang akan membuat good-first-contribution ke NLTK.

• Tokenizer + detokenizer Musa
• Gajah
• Tokenisasikan Apapun

Maaf saya salah menekan tutup masalah. Sekarang sudah dibuka kembali.

Sekarang dengan Musa tokenizer dan detokenizer bekerja (#1551, #1553), setiap jiwa pemberani ingin mencoba mengimplementasikan kembali Elephant dengan sklearn ?

Dari #1860, sepertinya TreebankTokenizer yang kami gunakan sebagai default word_tokenize() agak ketinggalan jaman dan penguraian URL dan tanggal tidak benar-benar didukung.

Melihat lebih dekat regex TreebankTokenizer dan regex MosesTokenizer, tidak ada solusi yang mudah.

Untuk TreebankTokenizer , mungkin lebih mudah untuk memisahkan titik dua dari koma di https://github.com/nltk/nltk/blob/develop/nltk/tokenize/treebank.py#L76

Bagi Musa, sepertinya tokenizer default tidak peduli untuk menyatukan angka:

$ 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

Mungkin, kita perlu mempertimbangkan tokenizer yang lebih modern sebagai default NLTK word_tokenize() ?

Mungkin, kita perlu mempertimbangkan tokenizer yang lebih modern sebagai default NLTK word_tokenize() ?

Pertimbangkan # 2202? :)

Juga, sebagai catatan, bug saat ini (maksud saya #1214) tampaknya melewatkan label tokenizerizer

@alvations masih hilang labelnya :p