खोज क्वेरी लिखते समय प्रत्येक उपयोगकर्ता के पास कभी भी टाइपो होता है। टाइपकोस को सही करने वाले तंत्रों की अनुपस्थिति अप्रासंगिक परिणामों को जारी करने की ओर ले जाती है, या उनकी अनुपस्थिति के लिए भी। इसलिए, खोज इंजन को अधिक उपयोगकर्ता-उन्मुख बनाने के लिए, इसमें त्रुटि सुधार तंत्र बनाए जाते हैं।



पहली नज़र में टाइपो को ठीक करने का काम, बल्कि जटिल लगता है। लेकिन अगर आप कई तरह की त्रुटियों से शुरू करते हैं, तो समाधान को लागू करना मुश्किल हो सकता है। सामान्य तौर पर, टाइपो सुधार को संदर्भ-स्वतंत्र और संदर्भ-संवेदनशील (जहां शब्दकोश पर्यावरण को ध्यान में रखा जाता है) में विभाजित किया गया है। पहले मामले में, प्रत्येक शब्द के लिए त्रुटियों को अलग से ठीक किया जाता है, दूसरे में - संदर्भ को ध्यान में रखते हुए (उदाहरण के लिए, संदर्भ-स्वतंत्र मामले में वाक्यांश "वह घर गई" के लिए, प्रत्येक शब्द के लिए सुधार अलग-अलग होता है, जहां हम "वह घर गए" मिल सकता है। और दूसरे मामले में, सही सुधार "वह घर चला गया" देगा।

रूसी-भाषी उपयोगकर्ता के खोज प्रश्नों में, त्रुटियों के चार मुख्य समूहों को केवल संदर्भ-स्वतंत्र सुधार के लिए अलग किया जा सकता है [ 1 ]:
1) स्वयं शब्दों में त्रुटि ( mr → hi कहो), इस श्रेणी में सभी प्रकार के चूक, सम्मिलन और पत्रों की अनुमति शामिल हैं - 63.7%,
2) शब्दों की निरंतर वर्तनी - 16.9%,
3) विकृत लेआउट (ghbdtn → hi) - 9.7%,
4) लिप्यंतरण (privet → hi) - १.३%,
5) मिश्रित त्रुटियां - 8.3%।



उपयोगकर्ता लगभग 10-15% मामलों में टाइपो बनाते हैं। इसी समय, 83.6% अनुरोधों में एक त्रुटि, 11.7% - दो, 4.8% - तीन से अधिक है। 26% मामलों में प्रसंग महत्वपूर्ण है।

ये आंकड़े 10,000 प्रश्नों के आधार पर 2013 में यैंडेक्स दैनिक लॉग बैक से एक यादृच्छिक नमूने के आधार पर संकलित किए गए थे। सार्वजनिक डोमेन में 2008 के लिए यैंडेक्स से बहुत पहले की प्रस्तुति है, जो आंकड़ों के समान वितरण को दर्शाती है [ 2 ]। इससे हम यह निष्कर्ष निकाल सकते हैं कि खोज प्रश्नों की त्रुटियों का वितरण, औसतन, समय के साथ नहीं बदलता है।

सामान्य तौर पर, टाइपो सुधार तंत्र दो मॉडलों पर आधारित होता है: त्रुटि मॉडल और भाषा मॉडल। इसके अलावा, एक संदर्भ-स्वतंत्र सुधार के लिए, केवल त्रुटि मॉडल का उपयोग किया जाता है, और संदर्भ-निर्भर सुधार में, दो का उपयोग एक साथ किया जाता है। त्रुटि मॉडल आम तौर पर या तो संपादकीय दूरी (लेवेन्सहाइटिन, दमेराउ-लेवेनशेटिन दूरी, विभिन्न भार कारक, साउंडेक्स के समान तरीके आदि) को भी यहां जोड़ा जा सकता है - इस मामले में, दूरी को भारित कहा जाता है) , या ब्रिल-मूर मॉडल, जो एक पंक्ति से दूसरी पंक्ति में संक्रमण की संभावनाओं पर काम करता है। ब्रिल और मूर ने अपने मॉडल को और अधिक परिपूर्ण के रूप में स्थान दिया, हालांकि, नवीनतम स्पेलर्यूवल प्रतियोगिताओं में से एक में, डेमारू-लेवेन्शेटिन दृष्टिकोण ने एक बेहतर परिणाम दिखाया [ 3 ], इस तथ्य के बावजूद कि डेमेरू-लेवेन्शेटिन दूरी (स्पष्टीकरण स्पष्ट नहीं है ) ऑफ-गार्ड आँकड़ों के बारे में एक पूर्व सूचना का उपयोग नहीं करता है। । यह अवलोकन विशेष रूप से सांकेतिक है यदि दीपपावलोव पुस्तकालय में ऑटो-करेक्टर्स के अलग-अलग कार्यान्वयन के लिए एक ही प्रशिक्षण ग्रंथों का उपयोग किया गया था।

जाहिर है, एक संदर्भ-संवेदनशील सुधार की संभावना ऑटो-सुधारक के निर्माण को जटिल बनाती है, क्योंकि त्रुटि मॉडल के अलावा, एक भाषा मॉडल की आवश्यकता को जोड़ा जाता है। लेकिन अगर आप टाइपो के आंकड़ों पर ध्यान देते हैं, तो written सभी गलत तरीके से लिखे गए खोज प्रश्नों को संदर्भ के बिना ठीक किया जा सकता है। इससे पता चलता है कि कम से कम एक संदर्भ-स्वतंत्र ऑटो-सुधारक का लाभ बहुत महत्वपूर्ण हो सकता है।

इसके अलावा, अनुरोधों में टाइपो को सही करने के लिए एक संदर्भ-संवेदनशील सुधार बहुत संसाधन-गहन है। उदाहरण के लिए, यैंडेक्स के भाषणों में से एक में, शब्दों की संख्या (यूनीग्राम) की तुलना में शब्दों के टाइपो (बिगोग्राम) को सही करने के लिए जोड़े की सूची 10 बार अलग-अलग थी, फिर ट्रिगर्स के बारे में क्या? जाहिर है, यह काफी हद तक प्रश्नों की परिवर्तनशीलता पर निर्भर करता है। यह थोड़ा अजीब लगता है जब ऑटो-करेक्टर प्रस्तावित कंपनी के उत्पाद की आधी मेमोरी लेता है, जिसका उद्देश्य वर्तनी की समस्या को हल करने पर केंद्रित नहीं है। तो सॉफ्टवेयर उत्पादों के खोज इंजन में संदर्भ-संवेदनशील सुधारों को लागू करने का मुद्दा बहुत विवादास्पद हो सकता है।

पहली नज़र में, किसी को यह आभास हो जाता है कि किसी भी प्रोग्रामिंग लैंग्वेज के लिए कई तैयार समाधान हैं, जिनका उपयोग एल्गोरिदम के संचालन के विवरण में बहुत अधिक विसर्जन के बिना किया जा सकता है, जिसमें वाणिज्यिक सिस्टम भी शामिल है। लेकिन व्यवहार में, उनके समाधान का विकास जारी है। उदाहरण के लिए, अपेक्षाकृत हाल ही में, जूम ने खोज प्रश्नों के लिए भाषा मॉडल का उपयोग करते हुए टाइपोस को सही करने का अपना निर्णय लिया [ 4 ]। क्या टर्नकी समाधान की उपलब्धता के साथ स्थिति वास्तव में कठिन है? यह अंत करने के लिए, जहाँ तक संभव हो, मौजूदा समाधानों का एक व्यापक अवलोकन किया गया है। समीक्षा शुरू करने से पहले, हम यह तय करेंगे कि ऑटो-करेक्टर की गुणवत्ता की जांच कैसे की जाती है।

गुणवत्ता नियंत्रण

ऑटो-करेक्टर की गुणवत्ता की जाँच का मुद्दा बहुत विवादास्पद है। सत्यापन के लिए एक सरल तरीका प्रेसिजन और रिकॉल के माध्यम से है। आईएसओ मानक के अनुसार, सटीकता और पूर्णता शुद्धता (अंग्रेजी में "corectness") के पूरक हैं।



पूर्णता (रिकॉल) की गणना निम्न प्रकार से की जाती है: सही शब्दों की एक सूची ऑटो-करेक्टर (Total_list_true) को सबमिट की जाती है, और ऑटो-करेक्टर को सही मानने वाले शब्दों की संख्या (Spellchecker_true), सही शब्दों की कुल संख्या (Total_list_true) से विभाजित होती है, को पूर्णता माना जाएगा।

$$

$$स्मरण = {Spellchecker \ _true \ ओवर कुल \ _list \ _true}$$

सटीकता (परिशुद्धता) का निर्धारण करने के लिए, गलत शब्दों की एक सूची (Total_list_false) को ऑटो-करेक्टर के इनपुट के लिए आपूर्ति की जाती है, और उन शब्दों की संख्या, जिन्हें ऑटो-करेक्टर गलत मानता है (Spell_checker_false), जिसे गलत शब्दों की कुल संख्या (Total_list_false) से विभाजित किया गया है, सटीकता के रूप में परिभाषित किया गया है।

$$

$$परिशुद्धता = {Spellchecker \ _false \ over कुल \ _list \ _false}$$

आम तौर पर ये मीट्रिक कैसे सूचनात्मक होते हैं और वे कैसे उपयोगी हो सकते हैं, प्रत्येक स्वतंत्र रूप से निर्धारित करता है। सब के बाद, वास्तव में, इस परीक्षण का सार यह है कि शब्द को प्रशिक्षण शब्दकोश में चेक किया गया है। शुद्धता को अधिक स्पष्ट मीट्रिक माना जा सकता है, जिसके अनुसार गलत शब्दों के परीक्षण सेट से प्रत्येक शब्द के लिए स्वत: सुधारक प्रतिस्थापन उम्मीदवारों की एक सूची बनाता है जिसके लिए इस गलत शब्द को सुधारा जा सकता है (ध्यान रखें कि ऐसे शब्द हो सकते हैं जो प्रशिक्षण शब्दकोश में निहित नहीं हैं) । मान लीजिए कि प्रतिस्थापन उम्मीदवारों की ऐसी सूची का आकार 5 है। इस तथ्य के आधार पर कि सूची का आकार 5 है, 6 समूह बनाए जाएंगे, जिनमें से एक में हम निम्नलिखित सिद्धांत के अनुसार अपना प्रत्येक मूल गलत शब्द डालेंगे: 1 समूह में - यदि प्रतिस्थापन उम्मीदवारों की सूची, सही शब्द जिसे हम माना जाता है वह 1 में है, 2 में है, अगर यह 2 है, आदि, और अंतिम समूह में, यदि माना जाता है कि सही शब्द प्रतिस्थापन उम्मीदवारों की सूची में नहीं है। बेशक, अधिक शब्द 1 समूह में गिर गए और 6 वें में कम, बेहतर ऑटो-सुधारक काम करता है।

लेखकों ने लेख [ 5 ] में विचार किए गए दृष्टिकोण पर विचार किया, जिसमें संदर्भ-स्वतंत्र ऑटो-सुधारक एक पूर्वाग्रह के साथ आईएसओ मानक की तुलना में थे। यह अन्य गुणवत्ता मूल्यांकन विधियों के लिंक भी प्रदान करता है।

एक ओर, यह दृष्टिकोण सकल आँकड़ों पर आधारित नहीं है, जो ब्रिल - मूर त्रुटि मॉडल [ 6 ] या डेमेरू - लेवेन्शेटिन भारित दूरी त्रुटि मॉडल पर आधारित हो सकता है।

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

फिर प्रशिक्षण शब्दकोश में शब्दों की पूरी सूची के लिए प्रयोगों की एक श्रृंखला आयोजित की गई (एक विशेष टाइपो की संभावना के अनुसार गलत लोगों के लिए प्रशिक्षण शब्द के शब्द सही किए गए) । औसतन, 75% मामलों में ऑटो-रेक्टर सही ढंग से शब्दों को सही करता है। एक शक के बिना, यह संख्या कम हो जाएगी जब शिक्षण शब्दकोश को संपादकीय दूरी के करीब शब्दों के साथ फिर से भर दिया जाता है, शब्द रूपों की एक विशाल विविधता। भाषा मॉडल के साथ पूरक करके इस समस्या को हल किया जा सकता है, लेकिन यह ध्यान में रखा जाना चाहिए कि आवश्यक संसाधनों की मात्रा में काफी वृद्धि होगी।

तैयार समाधान

रेडी-मेड समाधानों के विचार को अपने स्वयं के उपयोग पर ध्यान केंद्रित करने के साथ किया गया था, और ऑटो-सुधारकर्ताओं को प्राथमिकता दी गई थी कि तीन योग्यताएं:
1) कार्यान्वयन भाषा,
2) लाइसेंस का प्रकार,
3) अद्यतनशीलता।

उत्पाद विकास में, जावा को सबसे लोकप्रिय में से एक माना जाता है, इसलिए पुस्तकालयों की खोज करते समय इसे प्राथमिकता दी गई थी। प्रासंगिक लाइसेंस से: MIT, सार्वजनिक, अपाचे, BSD। अद्यतन क्षमता - अंतिम अद्यतन से 2 वर्ष से अधिक नहीं। खोज के दौरान, अतिरिक्त जानकारी दर्ज की गई थी, उदाहरण के लिए, समर्थित प्लेटफ़ॉर्म के बारे में, आवश्यक अतिरिक्त प्रोग्राम, अनुप्रयोग सुविधाएँ, पहले उपयोग के लिए संभावित कठिनाइयाँ, आदि। सूत्रों के मूल और उपयोगी संसाधनों के साथ लिंक लेख के अंत में दिए गए हैं। सामान्य तौर पर, यदि उपरोक्त मानदंडों तक सीमित नहीं है, तो मौजूदा समाधानों की संख्या बड़ी है। आइए मुख्य लोगों पर एक संक्षिप्त नज़र डालें, और केवल कुछ पर अधिक ध्यान दें।

ऐतिहासिक रूप से, सबसे पुराने ऑटो- करेक्टर्स में से एक, इस्सेल (इंटरनेशनल स्पेल) है, जो 1971 में असेंबलर में लिखा गया था, बाद में सी में स्थानांतरित कर दिया गया और त्रुटियों के एक मॉडल के रूप में दमरेउ-लेवेन्शेटिन संपादकीय दूरी का उपयोग करता है। उसके लिए, रूसी में एक शब्दकोश भी है। इसके बाद, उन्हें दो ऑटो सुधारकों हंसेल (पूर्व में मायस्पेल ) और एस्पेल द्वारा बदल दिया गया था। दोनों C ++ में कार्यान्वित किए जाते हैं और GPL लाइसेंस के तहत वितरित किए जाते हैं। हंसेल जीपीएल / एमपीएल द्वारा भी कवर किया गया है और इसका उपयोग ओपनऑफिस, लिब्रे ऑफिस, गूगल क्रोम और अन्य उपकरणों में टाइपो को सही करने के लिए किया जाता है।

इंटरनेट और ब्राउज़रों के लिए बहुत सारे जेएस समाधान हैं (इसमें शामिल हैं: नोडहून-वाक्य , nspell , नोड- मार्कडाउन-स्पैन्चेक , प्रूफ़रीडर , स्पेलचेक -एपीआई - हुनस्पैन ऑटो पर आधारित समाधान का एक समूह; सुधारक ; ग्रंट -स्पेल - नोडोड्स के लिए - yaspeller- yaspeller-; सीआई - Yandex.Speller ऑटो- सुधारक के लिए आवरण, एमआईटी के तहत वितरित; रूसो - जेएस में लाइटवेट प्रूफरीडर - वर्तनी के लिए उपयोग किया जाता है)।

भुगतान किए गए समाधानों की श्रेणी में शामिल हैं: स्प्लेलेक्स ; स्रोत कोड वर्तनी परीक्षक - एक डेस्कटॉप अनुप्रयोग के रूप में; जेएस के लिए: नैनोस्पेल ; जावा के लिए: कीओटी रैपिडस्पेल स्पेलसीचर , जेस्पेल एसडीके , विंटरट्री (विंटरट्री यहां तक ​​कि $ 5000 के लिए सोर्स कोड खरीद सकते हैं)।

पीटर नॉरविग ऑटो-करेक्टर का व्यापक रूप से उपयोग किया जाता है, जिसके लिए पायथन कोड सार्वजनिक रूप से लेख " स्पेलिंग करेक्टर कैसे लिखें " [ 7 ] में उपलब्ध है। इस सरल समाधान के आधार पर, अन्य भाषाओं में ऑटो- कॉनक्टेक्टर्स का निर्माण किया गया था, उदाहरण के लिए: नॉरविग-स्पेल-चेक , स्काला-नोर्विग-स्पेल-चेक (स्काला पर), टॉय-स्पेलिंग- करेक्टर - गोलांग स्पेलचेक (जीओ पर), pyspellchecker (पायथन पर) । बेशक, यहां हम भाषा मॉडल और संदर्भ-संवेदनशील सुधार के बारे में बात नहीं कर रहे हैं।

पाठ संपादकों के लिए, विशेष रूप से VIM के लिए vim-dialect बनाया, vim-ditto - एक सार्वजनिक लाइसेंस के तहत वितरित किया गया; नोटपैड ++ के लिए C ++, GPL लाइसेंस में DspellCheck द्वारा विकसित; Emacs के पास स्वचालित रूप से भाषाओं का पता लगाने के लिए एक उपकरण है, जिसे एक सार्वजनिक लाइसेंस के तहत वितरित, अनुमान-भाषा कहा जाता है।

खोज दिग्गजों से अलग सेवाएं हैं: Yandex.Speller - यैंडेक्स से, इसके लिए आवरण के बारे में ऊपर उल्लेख किया गया था, Google- एपीआई-वर्तनी-जावा (क्रमशः, Google से)।

जावा के लिए नि: शुल्क पुस्तकालय: लाइसगेटूल (एलजीपीएल के तहत लाइसेंस प्राप्त), ल्यूसीन पाठ खोज पुस्तकालय के साथ एकीकृत करता है और भाषा मॉडल के उपयोग की अनुमति देता है, जावा संस्करण 8 की आवश्यकता है; Jazzy ( Aspell का एक एनालॉग) LGPLv2 के तहत लाइसेंस प्राप्त है और 2005 के बाद से अपडेट नहीं किया गया है, और 2013 में GitHub में पोर्ट किया गया था। इस ऑटो-करेक्टर की समानता में, एक अलग समाधान बनाया गया था [ 8 ]; जोरथो (जावा ऑर्थोग्राफी) को जीपीएल के तहत वितरित किया जाता है और गैर-वाणिज्यिक प्रयोजनों के लिए विशेष रूप से वाणिज्यिक लोगों के लिए - एक अतिरिक्त शुल्क के लिए मुफ्त उपयोग की अनुमति देता है; जसपेल (बीएसडी के तहत लाइसेंस प्राप्त है और 2005 से अपडेट नहीं किया गया है); ओपन सोर्स जावा सुझाव - 2013 से अपडेट नहीं किया गया है, सॉफ्टकोरमेशन एलएलसी द्वारा वितरित किया गया है और व्यावसायिक उपयोग की अनुमति देता है; LuceneSpellChecker एक Lucene autocorrector है जो जावा में लिखा गया है और अपाचे लाइसेंस के तहत वितरित किया गया है।

एक लंबे समय के लिए, वुल्फ गार्ब ने टाइपोस के साथ निपटा, उन्होंने एल्गोरिदम सिम्सेल (एमआईटी लाइसेंस के तहत) और लिनस्पेल (एलजीपीएल के तहत) को सी # कार्यान्वयन [ 9 ] के साथ प्रस्तावित किया जो त्रुटि मॉडल के लिए दमरेउ-लेवेंसटेइन दूरी का उपयोग करते हैं। उनके कार्यान्वयन की ख़ासियत यह है कि इनपुट शब्द के लिए संभावित त्रुटियों को उत्पन्न करने के चरण में, सभी प्रकार के विलोपन, आवेषण, प्रतिस्थापन और क्रमपरिवर्तन के बजाय केवल विलोपन का उपयोग किया जाता है। पीटर नॉरविग के ऑटो-करेक्टर के कार्यान्वयन की तुलना में, दोनों एल्गोरिदम इस वजह से तेजी से काम करते हैं, जबकि अगर डेमेरू-लेवेंसाइट की दूरी दो से अधिक हो जाती है, तो गति में वृद्धि काफी बढ़ जाती है। इसके अलावा, इस तथ्य के कारण कि केवल विलोपन का उपयोग किया जाता है, शब्दकोश गठन का समय कम हो जाता है। दो एल्गोरिदम के बीच अंतर यह है कि लिनेसेल मेमोरी में अधिक किफायती है और खोज की गति में धीमी है, सिम्सेल - इसके विपरीत। बाद के संस्करण में, SymSpell स्पेलिंग-स्पेलिंग त्रुटियों को ठीक करता है। भाषा मॉडल का उपयोग नहीं किया जाता है।

भाषा मॉडल के साथ काम करने वाले ऑटो- करेक्टर्स के उपयोग और संदर्भ-संवेदी-संवेदनशील टाइपोस को सही करने के लिए सबसे हालिया और होनहारों में Yandex.Speller , JamSpell [ 10 ], DeepPavlov [ 11 ] शामिल हैं। अंतिम 2 को स्वतंत्र रूप से वितरित किया जाता है: जेम्सेल (एमआईटी), दीपपावलोव (अपाचे के तहत)।

Yandex.Speller कैटबॉस्ट एल्गोरिथ्म का उपयोग करता है, कई भाषाओं के साथ काम करता है और सभी प्रकार की त्रुटियों को ठीक करता है, यहां तक ​​कि संदर्भ को भी ध्यान में रखते हुए। एकमात्र समाधान ने पाया कि गलत लेआउट त्रुटियों और लिप्यंतरण को सही करता है। समाधान में बहुमुखी प्रतिभा है, जो इसे लोकप्रिय बनाती है। इसका नुकसान यह है कि यह एक दूरस्थ सेवा है, और प्रतिबंधों और उपयोग की शर्तों के बारे में यहां पाया जा सकता है [ 12 ]। सेवा सीमित संख्या में भाषाओं के साथ काम करती है; आप स्वयं शब्दों को जोड़ नहीं सकते हैं और सुधार प्रक्रिया का प्रबंधन कर सकते हैं। RuSpellEval प्रतियोगिता के परिणामों के अनुसार संसाधन [ 3 ] के अनुसार, इस ऑटो-करेक्टर में सुधार की उच्चतम गुणवत्ता दिखाई दी। जैम्पेल सबसे तेजी से ज्ञात ऑटो- करेक्टर (C ++ कार्यान्वयन) है, अन्य भाषाओं के लिए तैयार बाइंडर हैं। केवल शब्दों में त्रुटियों को ठीक करता है और एक विशिष्ट भाषा के साथ काम करता है। आप यूनीग्राम और बिगग्राम के स्तर पर समाधान का उपयोग नहीं कर सकते। स्वीकार्य गुणवत्ता प्राप्त करने के लिए, एक बड़े प्रशिक्षण पाठ की आवश्यकता होती है।
दीपपावलोव के पास कुछ अच्छे अभ्यास हैं, हालांकि, इन समाधानों के एकीकरण और अपने स्वयं के उत्पाद में बाद के समर्थन में कठिनाई हो सकती है, क्योंकि उनके साथ काम करने के लिए एक आभासी वातावरण को जोड़ने और पायथन 3.6 के पुराने संस्करण का उपयोग करने की आवश्यकता होती है। दीपपावलोव ऑटो- करेक्टर्स के तीन तैयार-किए गए कार्यान्वयन का विकल्प प्रदान करता है, जिनमें से दो में ब्रिल-मूर त्रुटि मॉडल का उपयोग किया जाता है और दो भाषा मॉडल में। यह केवल वर्तनी की त्रुटियों को ठीक करता है, और दमरेउ-लेवेन्शेटिन दूरी के आधार पर त्रुटियों के एक मॉडल के साथ विकल्प निरंतर लेखन की त्रुटियों को ठीक कर सकता है।

मैं टाइपिंग को सही करने के लिए आधुनिक दृष्टिकोणों में से एक का उल्लेख करूंगा, जो शब्दों के वेक्टर प्रतिनिधित्व (वर्ड एंबेडिंग) के उपयोग पर आधारित है। इसका लाभ यह है कि इसका इस्तेमाल संदर्भ के आधार पर शब्दों को सही करने के लिए ऑटो-करेक्टर बनाने के लिए किया जा सकता है। इस दृष्टिकोण के बारे में अधिक विवरण यहां पाया जा सकता है [ 13 ]। लेकिन खोज प्रश्नों के टाइपो को सही करने के लिए इसका उपयोग करने के लिए, आपको प्रश्नों का एक बड़ा लॉग जमा करना होगा। इसके अलावा, मॉडल स्वयं मेमोरी खपत के मामले में काफी कैपेसिटिव हो सकता है, जो उत्पाद में एकीकरण की जटिलता को प्रभावित करेगा।

Naumen चॉइस

जावा के लिए तैयार समाधानों में से, ल्यूसीन से एक ऑटो-सुधारक (अपाचे से लाइसेंस के तहत वितरित) चुना गया था। आपको शब्दों में टाइपो को सही करने की अनुमति देता है। सीखने की प्रक्रिया तेज है: उदाहरण के लिए, एक विशेष शब्दकोश डेटा संरचना का गठन - 3 मिलियन लाइनों के लिए एक सूचकांक - एक इंटेल कोर i5-8500 3.00GHz प्रोसेसर, 32 Gb RAM, Lucene 8.0.0 पर 30 सेकंड था। पहले के संस्करणों में, समय 2 गुना अधिक हो सकता है। प्रशिक्षण शब्दकोश का आकार 3 मिलियन लाइनें (~ 73 एमबी txt-file) है, सूचकांक संरचना ~ 235 एमबी है। त्रुटि मॉडल के लिए, आप Jaro-Winkler, Levenshtein, Damerau-Levenshtein, N-Gram की दूरी चुन सकते हैं, यदि आवश्यक हो, तो आप अपना खुद का जोड़ सकते हैं। यदि आवश्यक हो, तो भाषा मॉडल [ 14 ] को जोड़ना संभव है। मॉडल 2001 से ज्ञात हैं, लेकिन सार्वजनिक डोमेन में प्रसिद्ध आधुनिक समाधानों के साथ उनकी तुलना नहीं मिली। अगला कदम उनके काम की जांच करना है।

परिणामस्वरूप ल्यूसीन आधारित समाधान केवल शब्दों में त्रुटियों को ठीक करता है। उचित अनुवाद तालिका के माध्यम से किसी भी ऐसे समाधान के लिए विकृत कीबोर्ड लेआउट के सुधार को जोड़ना मुश्किल नहीं है, जिससे अप्रासंगिक आउटपुट की संभावना 10% तक कम हो सकती है (टाइपो आंकड़ों के अनुसार)। इसके अलावा, जुड़े हुए 2 शब्दों और लिप्यंतरण के अलग-अलग लेखन को जोड़ना आसान है।

समाधान के मुख्य नुकसान जावा के ज्ञान की आवश्यकता, विस्तृत उपयोग के मामलों और विस्तृत प्रलेखन की कमी है, जो डेटा-विज्ञान विशेषज्ञों के लिए समाधान के विकास की गति में कमी से परिलक्षित होता है। इसके अलावा, 2 से अधिक की दमरेउ-लेवेनशेटिन के साथ टाइपोस को ठीक नहीं किया गया है। फिर, अगर हम गलत विवरण के आंकड़ों से आगे बढ़ते हैं, तो 5% मामलों में एक शब्द में 2 से अधिक त्रुटियां अक्सर कम होती हैं। क्या एल्गोरिथ्म को जटिल करने की आवश्यकता है, विशेष रूप से, स्मृति की खपत में वृद्धि, उचित है? यह पहले से ही ग्राहक के मामले पर निर्भर करता है। यदि अतिरिक्त संसाधन हैं, तो उनका उपयोग क्यों नहीं किया जाता है?

किफायती ऑटो करेक्टर के लिए मुख्य संसाधन :

• 30 सबसे अच्छा खुला स्रोत वर्तनी परियोजना
  
• तीन जावा ओपन सोर्स स्पेल चेकर्स में कानूनी शब्दों का मूल्यांकन: हंसेल, बेसिक सुझाव, और जज़ी
  
• वर्तनी परीक्षक: जावा शब्दावली
  
• nlp - जावा स्पेल चेकर लाइब्रेरी की तलाश
  
• Open source spell checking library for Java
  

1. . .
   
   
2. .
3. DeepPavlov.
4. Joom.
5. Dall'Oglio P. Evaluation of legal words in three Java open source spell checkers: Hunspell, Basic Suggester, and Jazzy
6. Eric B. and Robert M. An Improved Error Model for Noisy Channel Spelling Correction
7. Norvig P. How to Write a Spelling Corrector
8. Jazzy
9. Garbe W. SymSpell vs. BK-tree: 100x faster fuzzy string search & spell checking
10. Jamspell.
11. DeepPavlov. Automatic spelling correction pipelines
12. «API .»
13. Singularis. ,
14. Apache Lucene.