Nltk: "पायथन पार्टीशनर" को शामिल करके मल्टी वर्ड एक्सप्रेशंस के टोकनाइजेशन में सुधार करें

इस पर/इस पर एक छोटा नोट/परिशिष्ट, चूंकि:
ए) मैंने प्रारंभिक पोस्ट में इसका उल्लेख करने की उपेक्षा की; तथा
बी) यह उल्लेख योग्य लगता है:
पायथन पार्टिशनर पहले से ही एनएलटीके का उपयोग करता है।

विभाजनकर्ता का सुझाव देने के लिए धन्यवाद; मैंने इसे पहले नहीं देखा था। कागज के आधार पर, ऐसा लगता है कि यह MWE-लेबल वाले प्रशिक्षण डेटा n-ग्राम संभावनाओं और बड़े शाब्दिक संसाधनों (मुख्य रूप से विक्षनरी/विकिपीडिया से निकाले गए) पर निर्भर करते हुए MWE विभाजन करता है। अधिकांश सांख्यिकीय दृष्टिकोणों के विपरीत, यह महंगी गणना से बचा जाता है, अनिवार्य रूप से अधिकांश कार्यों को आवृत्ति गणना और शब्दकोश लुकअप के लिए स्थगित कर देता है। यह टूल 18 PARSEME भाषाओं का समर्थन करता है, जिसमें अंग्रेज़ी और विभिन्न यूरोपीय भाषाएँ शामिल हैं।

अगर इसे एनएलटीके में जोड़ा जाना है, तो यह कितना बड़ा होगा? पार्टिशनर रेपो>100MB है। यदि बड़ी डेटा फ़ाइलें हैं, तो मुझे लगता है कि उपयोगकर्ता को अनुरोध करने के लिए nltk.download() का उपयोग करना होगा।

सिस्टम को चलाने के लिए बड़े डेटा संसाधनों को मेमोरी में लोड करने में समय लगना चाहिए—क्या यह केवल कुछ सेकंड या उससे अधिक समय है?

ध्यान दें कि यह ऑर्थोग्राफ़िक लेक्सिकल इकाइयों के संदर्भ में मानक "टोकनाइज़ेशन" से काफी आगे जाता है, इसलिए यह मूल टोकननाइज़ेशन या लेमेटाइज़ेशन (#1214) का विकल्प नहीं है।

दुर्भाग्य से, मुझे कम से कम निकट भविष्य के लिए समय की कमी और पार्टिशनर के साथ परिचालन अनुभव की कमी के कारण इन सवालों को पास करना होगा। माफ़ करना! लेकिन शायद या तो @jakerylandwilliams या @andyreagan उन सवालों का जवाब दे सकते हैं

धन्यवाद @no-identd और @nschneid तक पहुँचने के लिए; मुझे खुशी है कि मॉड्यूल रुचिकर है। वर्तमान में हम Python 3 के लिए कुछ बैक एंड, डेटा और मॉडल सुधार पर काम कर रहे हैं। यदि वर्तमान संस्करण को nltk में लाना समझ में आता है तो मुझे लगता है कि इसे लागू करना काफी सरल होगा।

@nschneid , मॉडल का आपका आकलन सही है। बड़ी डेटा फ़ाइलों में कुछ सेकंड लग सकते हैं; लोड पर एकमात्र अंतराल जो मैंने देखा है वह EN विकिपीडिया डेटा सेट के लिए है, लेकिन इस संसाधन को प्रदर्शन के लिए अपेक्षाकृत कम लागत पर अनिवार्य रूप से तत्काल लोड के लिए छोड़ा जा सकता है। विकिपीडिया को छोड़ने के लिए डिफ़ॉल्ट EN लोड सेट करना शायद समझ में आता है।

मुझे चर्चा को आगे बढ़ाने और कोई अन्य प्रश्न पूछने में प्रसन्नता हो रही है।

@jakerylandwilliams @nschneid यदि हम विकिपीडिया को छोड़ देते हैं और यहां तक ​​कि nltk द्वारा डिफ़ॉल्ट डाउनलोडर का उपयोग करते हैं, तो यह python2 और python3 के साथ संगत है। मैं पार्टिशनर कोड की मल्टीप्लेटफार्म स्वतंत्रता (पायथन 2 और पायथन 3) के लिए मदद कर सकता हूं।

वास्तव में, यदि https://github.com/jakerylandwilliams/partitioner पहले से ही पायथन में एक कार्यशील पैकेज है, तो कोड को पोर्ट/पुन: लागू करने की आवश्यकता नहीं हो सकती है। उपयोगकर्ता आसानी से टोकननाइज़र का उपयोग सीधे पार्टीशनर बनाने के लिए कर सकते हैं।

यदि हम MWE जैसी "अच्छी चीजें" चाहते हैं, तो हम पार्टीशनर से गजेटियर ले सकते हैं, किसी तरह पूरे पार्टीशनर रेपो को NLTK में पोर्ट करने के बजाय MWE संसाधन को पैकेज कर सकते हैं। यदि पार्टीशनर के अनुरक्षक अपने पीपीआई पैकेज के बजाय एनएलटीके में कोड बनाए रखना चाहते हैं, तो मुझे लगता है कि यह तीसरे पक्ष के पायथन पुस्तकालयों से कोड पोर्ट करने के प्रयास के लायक है।

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

@alvations और @NeelShah18 , मैं सहमत हूं कि एनएलटीके संरचना और कोडिंग मानदंडों के अनुसार गजेटियर और एमडब्ल्यूई सेगमेंटेशन संसाधन को बाहर निकालना और फिर से पैकेजिंग करना एकीकरण के लिए सबसे अधिक समझ में आता है। https://github.com/jakerylandwilliams/partitioner के अंदर कुछ मॉडल और उपयोगिताओं हैं और एनएलटीके के लिए शायद सबसे उपयुक्त एक का उल्लेख धागे के शीर्ष पर @ no-identd द्वारा किया गया था:

https://noisy-text.github.io/2017/pdf/WNUT01.pdf

यदि यह रुचि का है, तो मैं निश्चित रूप से कुछ आवश्यक कार्यों के निष्पादन में मदद कर सकता हूं।

मैं