Nltk: Diskusi: Membangkitkan Model Ngram

Akan menyenangkan memiliki perpustakaan n-gram yang berfungsi di NLTK. SRILM memiliki beberapa pembungkus Python untuk inferensi, tetapi memiliki lisensi terbatas. KenLM memiliki pembungkus Python untuk melakukan inferensi, tetapi memiliki dependensi dalam kompilasi. Keduanya tidak memiliki dukungan untuk estimasi. Jadi saat ini tidak ada alat n-gram teruji yang tersedia untuk Python NLP.

@anttttti Terima kasih atas umpan baliknya, saya merasa sangat termotivasi untuk mengirimkan tambalan melihat semua permintaan untuk fitur ini :)

Apakah Anda memiliki pemikiran tentang masalah spesifik yang saya posting?

Metode pemulusan lanjutan mudah diterapkan setelah Anda memahami bahwa metode tersebut hanya berbeda dalam cara pendiskontoan dan interpolasi didefinisikan. Makalah sebelumnya dan banyak deskripsi buku teks membuat model tampak lebih rumit daripada yang sebenarnya, karena orang tidak memahami hubungannya dengan baik sebelumnya. Seharusnya tidak ada kebutuhan untuk modul terpisah, hanya konfigurasi perataan. Model backoff lama yang tidak dinormalisasi dengan benar tidak digunakan akhir-akhir ini, lihat "Sedikit Kemajuan dalam Pemodelan Bahasa" Joshua Goodman untuk ringkasan yang bagus. http://arxiv.org/pdf/1602.02332.pdf halaman 63 merangkum beberapa pilihan untuk pendiskontoan&interpolasi untuk kasus unigram, model orde tinggi menggunakan yang sama secara rekursif. Kneser-Ney sedikit lebih rumit dengan backoff yang dimodifikasi.

Smoothing tidak terlalu penting untuk sebagian besar penggunaan. Dengan data yang cukup, bahkan Kneser-Ney yang dioptimalkan tidak lebih baik dari Stupid Backoff. Jadi hanya memiliki n-gram orde tinggi yang tersedia di Python dengan pemulusan dasar apa pun akan menyenangkan. Lidstone atau Jelinek-Mercer untuk setiap pesanan harus bekerja dengan baik.

Masalah 1) Satu hal yang menurut saya akan sangat berguna adalah memiliki utilitas untuk membangun kosakata dan menyensor token OOV. Itu akan memperbaiki banyak kesalahan konyol yang membuat pengguna frustrasi dengan versi lama. Saya melampirkan beberapa kode yang melakukan itu (jangan ragu untuk menggunakan atau menyalin)
lm.txt

Edisi 2a) Saya pikir masih berguna untuk memiliki Kneser-Ney; itu biasanya diajarkan dan berguna untuk memiliki implementasi referensi.
Masalah 2b) Saya khawatir bahwa kopling ProbDist membuat ini jauh lebih rumit dari yang seharusnya. Mungkin lebih mudah untuk menjaga estimasi probabilitas dalam model bahasa untuk hal-hal seperti KN. Untuk model lain, mungkin tidak masalah menggunakan ProbDist.

@anttttti "

@ezobaric "_Masalah 2b) Saya khawatir bahwa kopling ProbDist membuat ini jauh lebih rumit daripada yang seharusnya_"

Meskipun saya belum melihat kode ini dalam beberapa saat, perasaan saya adalah bahwa kedua pernyataan ini benar.

Jika saya ingat dengan benar, ConditionalProbDist (dan lebih umum ProbDist) dinormalisasi terlalu dini untuk digunakan dalam model ngram yang dihaluskan. Misalnya, sementara kami tahu seberapa besar kemungkinan sebuah kata dalam konteks tertentu, kami mengalami kesulitan untuk menalar konteks itu sendiri (saya yakin tambalan sebelumnya mencoba untuk memperbaiki masalah ini -- meskipun ada upaya terbaik, itu agak kludgy [https: //github.com/nltk/nltk/pull/800]).

IMHO, semuanya sedikit direkayasa.

@afourney

IMHO, semuanya sedikit direkayasa.

Amin untuk itu! Saya sudah mencoba untuk membuat ini bekerja selamanya sekarang (saya mengirimkan #800 dan ya, itu tidak elegan sama sekali) dan saya juga mulai berpikir ada terlalu banyak bagian yang bergerak sehingga tidak masuk akal.

@ezobaric terima kasih banyak untuk file itu, saya benar-benar meminjam semangatnya untuk refactoring.

Berdasarkan semua umpan balik ini, inilah pandangan baru saya tentang struktur modul. Kami hanya memiliki satu kelas: model.ngram.NgramModelCounter .

Ini pada dasarnya adalah beberapa penghitung FreqDist digabungkan dalam antarmuka yang jelas. _Training_ hanya terdiri dari penghitungan jumlah ngram secara rekursif serta melacak ukuran vocab (dengan kemungkinan "menyelesaikan" beberapa penghitungan ini untuk mencegah pembaruan setelah pelatihan selesai). @alvations Saya tahu Anda ingin implementasi trie untuk ini, tapi saya pikir kita bisa mulai dengan penghitung rekursif yang tidak efisien untuk saat ini dan refactor backend nanti karena seharusnya tidak terlalu memengaruhi antarmuka.

Yang terpenting, kelas ini tidak berurusan dengan probabilitas sama sekali . Itu seharusnya membuat segalanya lebih sederhana dan pada saat yang sama lebih fleksibel. Semua orang perlu lakukan untuk menambahkan probabilitas adalah menggunakan metode OOP favorit mereka (misalnya pewarisan atau komposisi) untuk menulis kelas yang menggunakan atribut NgramModel untuk membangun metode prob() .

Jika saya punya waktu, saya akan mengirimkan satu (atau dua!) contoh bagaimana menambahkan probabilitas ke NgramModelCounter bisa bekerja.

Apa yang kalian pikirkan?

@Copper-Head memiliki antarmuka yang mirip dengan KenLM sebanyak mungkin akan baik untuk integrasi di masa mendatang: https://github.com/kpu/kenlm/blob/master/python/example.py

Saya pikir setelah versi stabil NgramModel dari NLTK habis, saya dapat mencoba memfaktorkan ulang kenlm wrapper untuk menggunakan antarmuka yang mirip dengan yang NLTK, seperti yang kami lakukan untuk scikit-learn .

Fungsi ini juga akan membantu dalam padding: https://github.com/nltk/nltk/blob/develop/nltk/util.py#L381

Saya pikir apa yang disarankan @Copper-Head adalah kelas yang menghitung unigram, bigram, trigram, dll. dengan cara terkoordinasi yang nyaman untuk dikonsumsi oleh model bahasa hilir. Dalam hal ini, saya pikir kenlm API belum berlaku. (Saya mungkin salah, tetapi dari contoh yang diposting, sepertinya API kenlm tidak menangani jumlah frekuensi mentah)

Saya pikir ini juga bermanfaat mempertimbangkan API model bahasa minimal yang menggunakan jumlah ngram tersebut. Seperti yang disarankan @Copper-Head, ini akan menjadi subkelas, atau lebih baik lagi, antarmuka yang sepenuhnya terpisah (memungkinkan implementasi yang sangat berbeda seperti https://www.projectoxford.ai/weblm). Di sini, saya pikir mungkin masuk akal untuk mengadopsi API kenlm, tetapi menurut saya antarmuka _any_ ngram LM harus cukup sederhana sehingga adaptor dapat dengan mudah ditulis.

Saya pikir API ngram minimal benar-benar hanya membutuhkan metode untuk (1) menghitung probabilitas bersyarat dari token yang diberikan konteks atau urutan, dan (2) melaporkan ukuran dan susunan kosakata yang diketahui. Hampir semua hal lain dapat dihitung melalui metode pembantu, termasuk perhitungan probabilitas bersama, serta generasi bahasa. Pembantu ini mungkin atau mungkin bukan bagian dari antarmuka.

Hmm, poin yang menarik. Saya bertanya-tanya apakah melacak jumlah itu untuk GT mungkin memperlambat pelatihan sedikit dan tidak perlu bagi orang-orang yang tidak ingin menggunakan perataan khusus itu. Saya pikir mungkin lebih masuk akal untuk melakukan minimum di kelas NgramCounter dan kemudian cukup memperluas metode pelatihannya (atau __init__ ) dalam subkelas khusus untuk Good-Turing, atau bahkan dalam implementasi ngram API yang diarahkan untuk menghitung probabilitas Good-Turing.
Tapi saya hanya duduk untuk menulis beberapa hal ini, jadi mungkin pada akhirnya tidak akan menjadi masalah.

Maaf, sepertinya saya tidak sengaja menghapus postingan. Untuk mengisi konteks yang hilang untuk pembaca masa depan: Saya pikir akan baik untuk mempertimbangkan teknik pemulusan umum saat merancang NgramModelCounter API. Misalnya, mengizinkan pengguna untuk menanyakan jumlah _spesies_ yang diamati sekali, dua kali, atau N kali penting untuk perataan Good-Turing (serta perataan Witten-Bell, dll.)

Sunting: Sepertinya kelas FreqDist sudah memiliki beberapa dari ini (lihat: FreqDist.hapaxes dan FreqDist.r_Nr) Saya ingin tahu apakah itu dapat digunakan kembali? Atau jika FreqDist harus menjadi titik awal.

Saya suka ide hanya memiliki objek counts yang kemudian dapat ditanyakan dengan subclass yang mengimplementasikan metode smoothing tertentu.

Satu-satunya kekhawatiran saya adalah bahwa pelatihan akan memiliki masalah jika kita tidak memiliki kemampuan untuk memperbaiki kosakata lebih awal: itu tidak akan konsisten dengan proses pelatihan LM standar, dan melacak semua kosakata akan menyebabkan memori meledak (yang merupakan masalah besar dengan LM lama juga).

Dicatat. Saya punya ide bagaimana mengatasi ini. Saya akan memposting PR hari ini.

PR #1351 sudah habis!! Ajukan pertanyaan / nitpicks :)

@Copper-Head – seberapa jauh kita bisa menggabungkan ini kembali ke cabang utama?

Melihat daftar tugas saya, saya akan mengatakan bahwa saya membutuhkan 2-3 hari kerja yang terfokus.
Mengingat bahwa saya kembali mengerjakan ini di waktu luang saya dari sekolah dan pekerjaan sehari-hari, saya akan memberikannya antara 2 minggu dan sebulan sebelum saya selesai dengan semua masalah _saya_ yang luar biasa. Ini tentu saja tidak memperhitungkan hal-hal acak yang mungkin menarik perhatian saya pada waktu itu.

@Copper-Head @jacobheil dan pengguna/pengembang NLTK yang tertarik dengan model bahasa N-gram.

Sama seperti check-in pada status submodule model .

• Apakah Anda pikir itu siap untuk mendorongnya ke cabang develop/master?
• Apakah ini masih menjadi topik yang secara aktif dikejar dan ingin dilihat orang di NLTK?

Saya pikir itu pasti berharga di NLTK; itu adalah bagian inti dari ketika saya
mengajar NLP.

Apakah NLTK mendukung LM yang dalam sekarang? Apakah API ini kompatibel dengan itu?

Jordan Boyd-Graber

Suara: 920.524.9464
[email protected]

http://boydgraber.org

Pada Selasa, 3 Oktober 2017 pukul 23.32, alvations [email protected] menulis:

@Copper-Head https://github.com/copper-head @jacobheil
https://github.com/jacobheil dan pengguna/devs NLTK yang tertarik
Model bahasa N-gram.

Sama seperti check-in pada status submodule model saat ini.

• Apakah Anda pikir itu siap untuk mendorongnya ke pengembangan/master?
  cabang?
• Apakah ini masih menjadi topik yang secara aktif dikejar dan ingin dilihat orang?
  NLTK?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/nltk/nltk/issues/1342#issuecomment-334041035 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAhoqh5oxzo2Y9mp88I8uwy4lmyNz9Amks5sovxngaJpZM4H4nGe
.

Hai - Saya ingin menggunakan fitur model bahasa "lama" di NLTK. Apa versi terbaru yang masih memiliki model bahasa pra-latihan (untuk bahasa Inggris)?

Bagi mereka yang menemukan utas ini, saya telah menyusun submodul yang berisi kode model lama.

https://github.com/sleepyfoxen/nltk_model

@stevenbird Saya pikir kita bisa menutup ini akhirnya :)

Untuk umpan balik konkret tentang implementasi yang ada, orang-orang dapat membuka masalah terpisah.

@Copper-Head ya saya setuju. Selamat! :)