Nltk: चर्चा: एनग्राम मॉडल को पुनर्जीवित करना

एनएलटीके में कार्यशील एन-ग्राम पुस्तकालय होना अच्छा होगा। SRILM में अनुमान के लिए कुछ पायथन रैपर हैं, लेकिन इसके पास प्रतिबंधात्मक लाइसेंस है। केनएलएम में अनुमान लगाने के लिए एक पायथन रैपर है, लेकिन इसकी संकलन में निर्भरता है। न तो अनुमान के लिए समर्थन है। तो वर्तमान में पाइथन एनएलपी के लिए कोई अच्छी तरह से परीक्षण किया गया एन-ग्राम उपकरण उपलब्ध नहीं है।

@anttttti प्रतिक्रिया के लिए धन्यवाद, मैं इस सुविधा की मांग को देखते हुए एक पैच सबमिट करने के लिए बहुत प्रेरित महसूस करता हूं :)

क्या मेरे द्वारा पोस्ट की गई विशिष्ट समस्याओं के बारे में आपके कोई विचार हैं?

एक बार जब आप समझ जाते हैं कि वे केवल छूट और प्रक्षेप को परिभाषित करने के तरीके में भिन्न हैं, तो उन्नत चौरसाई विधियों को लागू करना सरल है। पहले के कागजात और पाठ्यपुस्तक के अधिकांश विवरण मॉडल को उनकी तुलना में अधिक जटिल बनाते हैं, क्योंकि लोग पहले के कनेक्शनों को नहीं समझते थे। अलग मॉड्यूल की आवश्यकता नहीं होनी चाहिए, केवल चौरसाई का विन्यास। पुराने बैकऑफ़ मॉडल जिन्हें सही ढंग से सामान्यीकृत नहीं किया गया था, इन दिनों उपयोग नहीं किया जाता है, एक महान सारांश के लिए जोशुआ गुडमैन की "ए बिट ऑफ़ प्रोग्रेस इन लैंग्वेज मॉडलिंग" देखें। http://arxiv.org/pdf/1602.02332.pdf पृष्ठ 63 एक यूनिग्राम मामले के लिए छूट और प्रक्षेप के लिए कुछ विकल्पों को सारांशित करता है, उच्च क्रम मॉडल उसी पुनरावर्ती रूप से उपयोग करते हैं। संशोधित बैकऑफ़ के साथ Kneser-Ney थोड़ा अधिक कठिन है।

अधिकांश उपयोगों के लिए चौरसाई इतना महत्वपूर्ण नहीं है। पर्याप्त डेटा के साथ अनुकूलित Kneser-Ney भी Stupid Backoff से बेहतर नहीं है। तो बस किसी भी बुनियादी चौरसाई के साथ पाइथन में उपलब्ध उच्च-क्रम एन-ग्राम अच्छा होगा। प्रत्येक आदेश के लिए लिडस्टोन या जेलिनेक-मर्सर पूरी तरह से ठीक काम करना चाहिए।

अंक 1) एक बात जो मुझे लगता है कि बहुत उपयोगी होगी, वह है शब्दावली बनाने और ओओवी टोकन को सेंसर करने के लिए उपयोगिता। यह कई मूर्खतापूर्ण त्रुटियों को ठीक करेगा जो पुराने संस्करणों के साथ उपयोगकर्ताओं को निराश करती हैं। मैं कुछ कोड संलग्न कर रहा हूं जो ऐसा करता है (उपयोग या कॉपी करने के लिए स्वतंत्र महसूस करें)
एलएम.txt

अंक 2ए) मुझे लगता है कि केसर-ने का होना अभी भी उपयोगी है; यह आमतौर पर सिखाया जाता है और संदर्भ कार्यान्वयन के लिए यह उपयोगी होता है।
अंक 2बी) मुझे चिंता है कि ProbDist को युग्मित करना इसे आवश्यकता से कहीं अधिक जटिल बना देता है। केएन जैसी चीजों के लिए भाषा मॉडल के भीतर संभाव्यता अनुमान रखना आसान हो सकता है। अन्य मॉडलों के लिए, ProbDist का उपयोग करना ठीक हो सकता है।

@anttttti "

@ezubaric "_Issue 2b) मुझे चिंता है कि ProbDist को युग्मित करने से यह आवश्यकता से कहीं अधिक जटिल हो जाता है_"

हालाँकि मैंने कुछ समय से इस कोड को नहीं देखा है, लेकिन मेरा मानना ​​है कि ये दोनों कथन सत्य हैं।

अगर मुझे सही ढंग से याद है, तो कंडीशनलप्रोबडिस्ट (और आमतौर पर प्रोबडिस्ट) को स्मूथ एनग्राम मॉडल में उपयोग के लिए बहुत जल्दी सामान्यीकृत किया जाता है। उदाहरण के लिए, जबकि हम जानते हैं कि किसी दिए गए संदर्भ में किसी शब्द की कितनी संभावना है, हमें स्वयं संदर्भों के बारे में तर्क करने में कठिनाई होती है (मेरा मानना ​​​​है कि पहले के पैच ने इस मुद्दे को ठीक करने का प्रयास किया था - सर्वोत्तम प्रयासों के बावजूद, यह थोड़ा गड़बड़ था [https: //github.com/nltk/nltk/pull/800])।

आईएमएचओ, पूरी चीज इंजीनियर से थोड़ी अधिक है।

@afourney

आईएमएचओ, पूरी चीज इंजीनियर से थोड़ी अधिक है।

तथास्तु ऐसा ही हो! मैं इस काम को हमेशा के लिए बनाने की कोशिश कर रहा हूं (मैंने # 800 जमा किया और हाँ, यह बिल्कुल भी सुरुचिपूर्ण नहीं था) और मुझे यह भी लगने लगा है कि इसके लिए उचित होने के लिए बहुत सारे चलने वाले हिस्से हैं।

@ezubaric उस फ़ाइल के लिए एक गुच्छा धन्यवाद, मैं पूरी तरह से रिफैक्टरिंग के लिए अपनी भावना उधार ले रहा हूं।

इन सभी फीडबैक के आधार पर, यहाँ मॉड्यूल संरचना पर मेरा नया दृष्टिकोण है। हमारे पास सिर्फ एक वर्ग है: model.ngram.NgramModelCounter ।

यह मूल रूप से एक स्पष्ट इंटरफ़ेस में संयुक्त कई FreqDist काउंटर हैं। _Training_ में केवल ngrams की संख्या को पुनरावर्ती रूप से गिनना और साथ ही साथ वोकैब आकार का ट्रैक रखना शामिल है (संभावित रूप से "अंतिम रूप से" इनमें से कुछ को प्रशिक्षण के बाद अपडेट को रोकने के लिए गिना जाता है)। @alvations मुझे पता है कि आप इसके लिए एक

महत्वपूर्ण बात है, इस वर्ग के सभी पर संभावनाओं के साथ सौदा नहीं करता है। इससे चीजों को काफी सरल और साथ ही अधिक लचीला बनाना चाहिए। संभावनाओं को जोड़ने के लिए सभी को अपनी पसंदीदा ओओपी विधि (उदाहरण के लिए विरासत या संरचना) का उपयोग करने की ज़रूरत है, जो एक वर्ग लिखने के लिए NgramModel की विशेषताओं का उपयोग करके अपनी prob() विधि का निर्माण करता है।

अगर मेरे पास समय है तो मैं एक (या दो!) उदाहरण प्रस्तुत करूंगा कि कैसे NgramModelCounter में संभावनाओं को जोड़ने से काम हो सकता है।

आप लोगों का क्या विचार है?

@ कॉपर-हेड जितना संभव हो सके केनएलएम के समान इंटरफेस भविष्य के एकीकरण के लिए अच्छा होगा: https://github.com/kpu/kenlm/blob/master/python/example.py

मुझे लगता है कि एनएलटीके से NgramModel एक स्थिर संस्करण के बाद, मैं एनएलटीके के समान इंटरफेस का उपयोग करने के लिए kenlm रैपर को दोबारा करने की कोशिश कर सकता हूं, जैसे हमने scikit-learn ।

यह फ़ंक्शन पैडिंग में भी मदद करेगा: https://github.com/nltk/nltk/blob/develop/nltk/util.py#L381

मुझे लगता है कि @ कॉपर-हेड जो सुझाव दे रहा है वह एक ऐसा वर्ग है जो यूनिग्राम, बिग्राम, ट्रिग्राम इत्यादि को समन्वित तरीके से गिनता है जो डाउनस्ट्रीम भाषा मॉडल द्वारा उपभोग करने के लिए सुविधाजनक है। उस स्थिति में, मुझे लगता है कि kenlm API अभी तक लागू नहीं होता है। (मैं गलत हो सकता हूं, लेकिन पोस्ट किए गए उदाहरण से, यह कच्चे आवृत्ति गणना में केनएलएम एपीआई सौदों की तरह नहीं दिखता है)

मुझे लगता है कि यह न्यूनतम भाषा मॉडल एपीआई पर विचार करने योग्य भी है जो उन एनग्राम गणनाओं का उपभोग करता है। जैसा कि @ कॉपर-हेड सुझाव देता है, यह एक उपवर्ग होगा, या बेहतर अभी तक, एक पूरी तरह से अलग इंटरफ़ेस (https://www.projectoxford.ai/weblm जैसे बहुत अलग कार्यान्वयन के लिए अनुमति देता है)। यहाँ, मुझे लगता है कि kenlm API को अपनाना उचित हो सकता है, लेकिन लगता है कि _any_ ngram LM इंटरफ़ेस इतना सरल होना चाहिए कि एडेप्टर को आसानी से लिखा जा सके।

मुझे लगता है कि एक न्यूनतम एनग्राम एपीआई को वास्तव में केवल (1) एक संदर्भ या अनुक्रम दिए गए टोकन की सशर्त संभावना की गणना करने के तरीकों की आवश्यकता होती है, और (2) ज्ञात शब्दावली के आकार और मेकअप पर रिपोर्ट। अन्य सभी चीजों की गणना सहायक विधियों के माध्यम से की जा सकती है, जिसमें संयुक्त संभाव्यता की गणना, साथ ही साथ भाषा निर्माण भी शामिल है। ये सहायक इंटरफ़ेस का हिस्सा हो भी सकते हैं और नहीं भी।

हम्म, दिलचस्प बिंदु। मुझे आश्चर्य है कि जीटी के लिए उन गणनाओं का ट्रैक रखने से प्रशिक्षण थोड़ा धीमा हो सकता है और अनावश्यक रूप से उन लोगों के लिए जो उस विशेष चिकनाई का उपयोग नहीं करना चाहते हैं। मुझे लगता है कि यह मूल NgramCounter वर्ग में न्यूनतम करने के लिए और अधिक समझ में आता है और फिर गुड-ट्यूरिंग के लिए विशेष उप-वर्ग में अपने प्रशिक्षण (या __init__ ) विधि का विस्तार करता है, या यहां तक ​​​​कि एक में भी गुड-ट्यूरिंग संभावनाओं की गणना की दिशा में तैयार एनग्राम एपीआई का कार्यान्वयन।
लेकिन मैं केवल इस सामान में से कुछ को लिखने के लिए बैठा हूं, इसलिए हो सकता है कि यह अंत में कोई समस्या न हो।

क्षमा करें, ऐसा लगता है कि मैंने गलती से कोई पोस्ट हटा दी है। भविष्य के पाठकों के लिए लापता संदर्भ को भरने के लिए: मुझे लगता है कि NgramModelCounter API को डिज़ाइन करते समय सामान्य चौरसाई तकनीकों पर विचार करना अच्छा होगा। उदाहरण के लिए, गुड-ट्यूरिंग स्मूथिंग (साथ ही विटन-बेल स्मूथिंग, आदि) के लिए उपयोगकर्ताओं को एक बार, दो बार, या N बार देखे गए _species_ की संख्या को क्वेरी करने की अनुमति देना महत्वपूर्ण है।

संपादित करें: ऐसा लगता है कि FreqDist वर्ग में पहले से ही इनमें से कुछ है (देखें: FreqDist.hapaxes और FreqDist.r_Nr) मुझे आश्चर्य है कि क्या इसे फिर से तैयार किया जा सकता है? या अगर फ्रीकडिस्ट शुरुआती बिंदु होना चाहिए।

मुझे केवल एक काउंट ऑब्जेक्ट रखने का विचार पसंद है जिसे तब उपवर्गों के साथ पूछताछ की जा सकती है जो विशिष्ट चौरसाई विधियों को लागू करते हैं।

मेरी एकमात्र चिंता यह है कि प्रशिक्षण में समस्याएँ होंगी यदि हमारे पास शब्दावली को जल्दी ठीक करने की क्षमता नहीं है: यह मानक LM प्रशिक्षण प्रक्रियाओं के अनुरूप नहीं होगा, और सभी शब्दावली को ट्रैक करने से मेमोरी ब्लो हो जाएगी (जो कि एक थी पुराने एलएम के साथ भी बड़ी समस्या)।

विख्यात। मेरे पास इस बारे में विचार हैं कि इसे कैसे संबोधित किया जाए। मैं आज बाद में एक पीआर पोस्ट करूँगा।

जनसंपर्क #1351 ऊपर है !! प्रश्न/निपिक्स पर लाओ :)

@ कॉपर-हेड - हम इसे वापस मुख्य शाखा में विलय करने में सक्षम होने से कितनी दूर हैं?

मेरी टू-डू सूची को देखते हुए, मैं कहूंगा कि मुझे 2-3 दिनों के केंद्रित कार्य की आवश्यकता है।
यह ध्यान में रखते हुए कि मैं स्कूल और दिन के काम से अपने खाली समय में इस पर काम करने के लिए वापस आ गया हूं, मैं इसे सभी _my_ बकाया मुद्दों के साथ 2 सप्ताह और एक महीने के बीच कहीं भी दूंगा। यह स्वाभाविक रूप से यादृच्छिक सामान को ध्यान में नहीं रखता है जो उस समय मेरे ध्यान में लाया जा सकता है।

@ कॉपर-हेड @jacobheil और एनएलटीके उपयोगकर्ता/देव जो एन-ग्राम भाषा मॉडल में रूचि रखते हैं।

model सबमॉड्यूल की वर्तमान स्थिति पर चेक-इन करना पसंद करते हैं।

• क्या आपको लगता है कि यह इसे विकसित/मास्टर शाखा में धकेलने के लिए तैयार है?
• क्या यह अभी भी एक ऐसा विषय है जिसका लोग सक्रिय रूप से अनुसरण करते हैं और एनएलटीके पर देखना चाहते हैं?

मुझे लगता है कि यह निश्चित रूप से एनएलटीके में होने लायक है; यह एक मुख्य हिस्सा है जब मैं
एनएलपी पढ़ाओ।

क्या एनएलटीके अब गहरे एलएम का समर्थन कर रहा है? क्या यह एपीआई इसके साथ संगत है?

जॉर्डन बॉयड-ग्रैबर

आवाज: 920.524.9464
[email protected]

http://boydgraber.org

मंगल, 3 अक्टूबर, 2017 में 11:32 बजे पर, alvations [email protected] लिखा है:

@ कॉपर-हेड https://github.com/copper-head @jacobheil
https://github.com/jacobheil और NLTK उपयोगकर्ता/देव जो इसमें रुचि रखते हैं
एन-ग्राम भाषा मॉडल।

मॉडल सबमॉड्यूल की वर्तमान स्थिति पर चेक-इन करना पसंद करते हैं।

• क्या आपको लगता है कि यह इसे विकसित/मास्टर में धकेलने के लिए तैयार है?
  डाली?
• क्या यह अभी भी एक ऐसा विषय है जिसका लोग सक्रिय रूप से अनुसरण करते हैं और इस पर देखना चाहते हैं
  एनएलटीके?

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/nltk/nltk/issues/1342#issuecomment-334041035 , या म्यूट करें
सूत्र
https://github.com/notifications/unsubscribe-auth/AAhoqh5oxzo2Y9mp88I8uwy4lmyNz9Amks5sovxngaJpZM4H4nGe
.

नमस्ते - मैं एनएलटीके में भाषा मॉडल की "पुरानी" विशेषता का उपयोग करना चाहूंगा। नवीनतम संस्करण क्या है जिसमें अभी भी पूर्व-प्रशिक्षित भाषा मॉडल (अंग्रेजी के लिए) है?

इस धागे को खोजने वालों के लिए, मैंने पुराने मॉडल कोड वाले एक सबमॉड्यूल को एक साथ जोड़ दिया है।

https://github.com/sleepyfoxen/nltk_model

@stevenbird मुझे लगता है कि हम इसे अंत में बंद कर सकते हैं :)

मौजूदा क्रियान्वयन पर ठोस प्रतिक्रिया के लिए लोग अलग-अलग मुद्दे खोल सकते हैं।

@ कॉपर-हेड हाँ मैं सहमत हूँ। बधाई हो! :)