Nltk: مناقشة: إحياء نموذج Ngram

سيكون من الجيد أن يكون لديك مكتبة n-gram عاملة في NLTK. تحتوي SRILM على بعض أغلفة Python للاستدلال ، لكن لديها ترخيصًا مقيدًا. يحتوي KenLM على غلاف Python لإجراء الاستدلال ، ولكنه يحتوي على تبعيات في التجميع. لا يوجد دعم للتقدير. لذلك لا توجد حاليًا أدوات n-gram تم اختبارها جيدًا في Python NLP.

anttttti شكرًا على التعليقات ، أشعر بدافع كبير لإرسال تصحيح مع رؤية كل هذا الطلب على الميزة :)

هل لديك أي أفكار حول المشكلات المحددة التي قمت بنشرها؟

تكون طرق التنعيم المتقدمة سهلة التنفيذ بمجرد أن تفهم أنها تختلف فقط في كيفية تعريف الخصم والاستيفاء. تجعل الأوراق السابقة والكثير من أوصاف الكتب المدرسية النماذج تبدو أكثر تعقيدًا مما هي عليه ، لأن الناس لم يفهموا الروابط في وقت سابق. لا ينبغي أن تكون هناك حاجة لوحدات منفصلة ، فقط تكوين للتجانس. لم يتم استخدام نماذج التراجع الأقدم التي لم يتم تطبيعها بشكل صحيح في هذه الأيام ، راجع "A Bit of Progress in Language Modeling" لجوشوا جودمان للحصول على ملخص رائع. تلخص http://arxiv.org/pdf/1602.02332.pdf الصفحة 63 بعض الخيارات للخصم والاستيفاء لحالة unigram ، وتستخدم النماذج ذات الترتيب الأعلى نفس الشيء بشكل متكرر. يعتبر Kneser-Ney أكثر صعوبة قليلاً مع التراجع المعدّل.

التنعيم ليس بهذه الأهمية بالنسبة لمعظم الاستخدامات. مع وجود بيانات كافية ، حتى أن Kneser-Ney المحسنة ليست أفضل من Stupid Backoff. لذا فإن مجرد الحصول على n-grams عالية الترتيب المتوفرة في Python مع أي تجانس أساسي سيكون أمرًا رائعًا. يجب أن يعمل Lidstone أو Jelinek-Mercer لكل طلب بشكل جيد تمامًا.

المشكلة 1) الشيء الوحيد الذي أعتقد أنه سيكون مفيدًا للغاية هو أن يكون لديك أداة مساعدة لبناء المفردات والرقابة على رموز OOV. سيؤدي ذلك إلى تصحيح العديد من الأخطاء السخيفة التي أحبطت المستخدمين بالإصدارات القديمة. أرفق بعض الكود الذي يفعل ذلك (لا تتردد في استخدامه أو نسخه)
lm.txt

العدد 2 أ) أعتقد أنه لا يزال من المفيد أن يكون لديك Kneser-Ney ؛ يتم تدريسها بشكل شائع ومن المفيد أن يكون لها تطبيق مرجعي.
المشكلة 2 ب) أشعر بالقلق من أن اقتران ProbDist يجعل هذا الأمر أكثر تعقيدًا مما يجب أن يكون. قد يكون من الأسهل الاحتفاظ بتقدير الاحتمال ضمن نموذج اللغة لأشياء مثل KN. بالنسبة إلى الطرز الأخرى ، قد يكون من الجيد استخدام ProbDist.

anttttti "

ezubaric "_Issue 2b) أشعر بالقلق من أن اقتران ProbDist يجعل هذا الأمر أكثر تعقيدًا مما يجب أن يكون _"

على الرغم من أنني لم ألقي نظرة على هذا الرمز منذ فترة ، فإن إحساسي هو أن كلا العبارتين صحيحتان.

إذا كنت أتذكر بشكل صحيح ، فسيتم تطبيع ConditionalProbDist (وبشكل عام ProbDist) مبكرًا جدًا لاستخدامه في نماذج ngram المتجانسة. على سبيل المثال ، بينما نعلم مدى احتمالية وجود كلمة في سياق معين ، فإننا نواجه صعوبة في التفكير في السياقات نفسها (أعتقد أن التصحيح السابق حاول تصحيح هذه المشكلة - على الرغم من بذل قصارى الجهود ، كان الأمر قليلًا [https: //github.com/nltk/nltk/pull/800]).

IMHO ، تم تصميم كل شيء بشكل طفيف.

تضمين التغريدة

IMHO ، تم تصميم كل شيء بشكل طفيف.

آمين لذلك! لقد كنت أحاول أن أجعل هذا العمل إلى الأبد الآن (لقد قدمت # 800 ونعم ، لم يكن أنيقًا على الإطلاق) وبدأت أيضًا أعتقد أن هناك عددًا كبيرًا جدًا من الأجزاء المتحركة لتكون معقولة.

ezubaric شكرًا جزيلًا على هذا الملف ، فأنا

استنادًا إلى كل هذه التعليقات ، إليك وجهة نظري الجديدة حول هيكل الوحدة. لدينا فئة واحدة فقط: model.ngram.NgramModelCounter .

هذا في الأساس عبارة عن عدة عدادات FreqDist مجتمعة في واجهة واضحة. يتألف التدريب _ ببساطة من العد المتكرر لعدد النغرام بالإضافة إلى تتبع حجم المفردات (مع احتمال "إنهاء" بعض هذه الأعداد لمنع التحديثات بعد انتهاء التدريب). alvations أعلم أنك ترغب في تنفيذ ثلاثي لهذا ، ولكن أعتقد أنه يمكننا البدء بعداد تكراري غير فعال في الوقت الحالي وإعادة تشكيل الواجهة الخلفية لاحقًا لأنه لا ينبغي أن يؤثر على الواجهة كثيرًا.

والأهم، هذه الفئة لا يتعامل مع الاحتمالات على الإطلاق. هذا من شأنه أن يجعل الأمور أبسط بكثير وفي نفس الوقت أكثر مرونة. كل ما يحتاجه أي شخص لإضافة الاحتمالات هو استخدام طريقة OOP المفضلة لديه (مثل الميراث أو التركيب) لكتابة فئة تستخدم سمات NgramModel لإنشاء طريقة prob() .

إذا كان لدي وقت ، فسأرسل مثالًا واحدًا (أو اثنين!) لكيفية إضافة الاحتمالات إلى NgramModelCounter.

ماذا الناس يعتقدون؟

@ Copper-Head وجود واجهة مشابهة لـ KenLM قدر الإمكان سيكون جيدًا للتكامل في المستقبل: https://github.com/kpu/kenlm/blob/master/python/example.py

أعتقد أنه بعد إصدار مستقر من NgramModel من NLTK ، يمكنني محاولة إعادة بناء غلاف kenlm لاستخدام واجهة مماثلة مثل واجهات NLTK ، مثل ما فعلناه مقابل scikit-learn .

ستساعد هذه الوظيفة في الحشو أيضًا: https://github.com/nltk/nltk/blob/develop/nltk/util.py#L381

أعتقد أن ما يقترحه @ Copper-Head هو فئة تحسب الأحجام الأحادية ، والبيجرامات ، والتريجرامات ، وما إلى ذلك بطريقة منسقة يسهل استهلاكها بواسطة نماذج اللغة النهائية. في هذه الحالة ، أعتقد أن واجهة برمجة تطبيقات kenlm لا تنطبق بعد. (قد أكون مخطئًا ، ولكن من المثال المنشور ، لا يبدو أن صفقات kenlm API في أعداد الترددات الأولية)

أعتقد أنه من المفيد أيضًا التفكير في الحد الأدنى من واجهة برمجة تطبيقات نموذج اللغة التي تستهلك عدد نانوغرام. كما يقترح @ Copper-Head ، ستكون هذه فئة فرعية ، أو الأفضل من ذلك ، واجهة منفصلة تمامًا (تسمح بتطبيقات مختلفة إلى حد كبير مثل https://www.projectoxford.ai/weblm). هنا ، أعتقد أنه قد يكون من المعقول اعتماد واجهة برمجة تطبيقات kenlm ، ولكن أعتقد أن واجهة _any_ ngram LM يجب أن تكون بسيطة بما يكفي بحيث يمكن كتابة المحولات بسهولة.

أعتقد أن الحد الأدنى من واجهة برمجة تطبيقات ngram يحتاج حقًا فقط إلى طرق (1) لحساب الاحتمال الشرطي للرمز المعطى في سياق أو تسلسل ، و (2) تقرير عن حجم وتركيب المفردات المعروفة. يمكن حساب معظم كل شيء آخر عبر الطرق المساعدة ، بما في ذلك حسابات الاحتمال المشترك ، وكذلك توليد اللغة. قد يكون هؤلاء المساعدون جزءًا من الواجهة وقد لا يكونون كذلك.

حسنًا ، نقطة مثيرة للاهتمام. أتساءل عما إذا كان تتبع هذه التهم الخاصة بـ GT قد يؤدي إلى إبطاء التدريب قليلاً وغير ضروري لذلك بالنسبة للأشخاص الذين لا يرغبون في استخدام هذا التنعيم المعين. أعتقد أنه قد يكون من المنطقي القيام بالحد الأدنى في فئة NgramCounter ثم تمديد تدريبها ببساطة (أو __init__ ) في فئة فرعية متخصصة لـ Good-Turing ، أو حتى في تنفيذ ngram API الموجهة نحو حساب احتمالات Good-Turing.
لكني أجلس فقط لأكتب بعضًا من هذه الأشياء ، لذا ربما لن ينتهي الأمر إلى أن يصبح مشكلة في النهاية.

عذرًا ، يبدو أنني حذفت منشورًا عن طريق الخطأ. لملء السياق المفقود للقراء في المستقبل: أعتقد أنه سيكون من الجيد النظر في تقنيات التنعيم الشائعة عند تصميم NgramModelCounter API. على سبيل المثال ، السماح للمستخدمين بالاستعلام عن عدد _الأنواع_ التي تمت ملاحظتها مرة واحدة أو مرتين أو N مرة أمر مهم لتنعيم Good-Turing (بالإضافة إلى تجانس Witten-Bell وما إلى ذلك)

تحرير: يبدو أن فئة FreqDist لديها بالفعل بعض من هذا (انظر: FreqDist.hapaxes و FreqDist.r_Nr) أتساءل عما إذا كان من الممكن إعادة تصميمها؟ أو إذا كان يجب أن يكون FreqDist هو نقطة البداية.

تعجبني فكرة امتلاك كائن counts فقط والذي يمكن بعد ذلك الاستعلام عنه بالفئات الفرعية التي تنفذ طرق تجانس محددة.

قلقي الوحيد هو أن التدريب سيواجه مشكلات إذا لم تكن لدينا القدرة على إصلاح المفردات مبكرًا: لن يكون متسقًا مع عمليات تدريب LM القياسية ، وسيؤدي تتبع جميع المفردات إلى تفجير الذاكرة (وهو ما كان مشكلة كبيرة مع LM القديم أيضًا).

وأشار. لدي أفكار حول كيفية معالجة هذا. سأقوم بنشر العلاقات العامة في وقت لاحق اليوم.

تم رفع PR # 1351 !! إحضار الأسئلة / nitpicks :)

@ Copper-Head - إلى أي مدى نحن بعيدون عن القدرة على دمج هذا مرة أخرى في الفرع الرئيسي؟

بالنظر إلى قائمة المهام الخاصة بي ، أقول إنني بحاجة إلى 2-3 أيام من العمل المركز.
بالنظر إلى أنني عدت إلى العمل على هذا في وقت فراغي من المدرسة والعمل النهاري ، سأمنحه في أي مكان ما بين أسبوعين وشهر قبل أن أنتهي من جميع المشكلات المعلقة. هذا بطبيعة الحال لا يأخذ في الاعتبار الأشياء العشوائية التي قد يتم لفت انتباهي إليها في ذلك الوقت.

@ Copper-Head @ jacobheil و NLTK المستخدمون / المطورين المهتمين بنماذج لغة N-gram.

تمامًا مثل تسجيل الوصول في الحالة الحالية للوحدة الفرعية model .

• هل تعتقد أنه جاهز لدفعه إلى فرع التطوير / الرئيسي؟
• هل لا يزال موضوعًا يتابعه الناس بنشاط ويريدون رؤيته على NLTK؟

أعتقد أنه بالتأكيد يستحق التواجد في NLTK ؛ إنه جزء أساسي مني
تعليم البرمجة اللغوية العصبية.

هل NLTK يدعم LMs العميق الآن؟ هل واجهة برمجة التطبيقات هذه متوافقة مع ذلك؟

جوردان بويد-جرابر

الصوت: 920.524.9464
[email protected]

http://boydgraber.org

في الثلاثاء 3 أكتوبر 2017 الساعة 11:32 مساءً ، كتب alvations [email protected] :

@ النحاس رئيس https://github.com/copper-headjacobheil
https://github.com/jacobheil ومستخدمي NLTK / المطورين المهتمين بـ
نماذج اللغة N-gram.

تمامًا مثل التحقق من الحالة الحالية للوحدة الفرعية النموذجية.

• هل تعتقد أنه جاهز لدفعه إلى التطوير / الماجستير
  فرع؟
• هل لا يزال موضوعًا يتابعه الناس بنشاط ويريدون مشاهدته
  NLTK؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/nltk/nltk/issues/1342#issuecomment-334041035 ، أو كتم الصوت
الخيط
https://github.com/notifications/unsubscribe-auth/AAhoqh5oxzo2Y9mp88I8uwy4lmyNz9Amks5sovxngaJpZM4H4nGe
.

مرحباً - أود استخدام الميزة "القديمة" لنموذج اللغة في NLTK. ما هو أحدث إصدار لا يزال يحتوي على نموذج اللغة المدرب مسبقًا (للغة الإنجليزية)؟

بالنسبة لأولئك الذين يعثرون على هذا الخيط ، لقد جمعت نوعًا ما وحدة فرعية تحتوي على كود النموذج القديم.

https://github.com/sleepyfoxen/nltk_model

stevenbird أعتقد أنه يمكننا إغلاق هذا أخيرًا :)

للحصول على تعليقات ملموسة حول التنفيذ الحالي ، يمكن للأشخاص فتح قضايا منفصلة.

@ النحاس رئيس نعم أوافق. تهانينا! :)