NL2API: वेब एपीआई के लिए प्राकृतिक भाषा इंटरफेस बनाना

नमस्कार, हेब्र! अभी हाल ही में, हमने प्राकृतिक भाषा इंटरफेस के बारे में संक्षेप में बात की । खैर, आज हमने संक्षेप में नहीं बताया है। कटौती के तहत आपको वेब-एपीआई के लिए एनएल 2एपीआई बनाने के बारे में पूरी कहानी मिलेगी। रिसर्च के हमारे सहयोगियों ने फ्रेमवर्क के लिए प्रशिक्षण डेटा एकत्र करने के लिए एक अनूठा तरीका आजमाया। अब सम्मिलित हों!

अमूर्त

जैसे-जैसे इंटरनेट एक सेवा-उन्मुख वास्तुकला की ओर विकसित होता है, सॉफ्टवेयर इंटरफेस (एपीआई) डेटा, सेवाओं और उपकरणों तक पहुंच प्रदान करने के तरीके के रूप में तेजी से महत्वपूर्ण होते जा रहे हैं। हम वेब सेवाओं पर ध्यान केंद्रित करते हुए एपीआई (NL2API) के लिए एक प्राकृतिक भाषा इंटरफ़ेस बनाने के मुद्दे पर काम कर रहे हैं। NL2API समाधान के कई संभावित लाभ हैं, उदाहरण के लिए, आभासी सहायकों में वेब सेवाओं के एकीकरण को आसान बनाने में मदद करना।

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

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

परिचय

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


चित्र 1. जोड़े "एनएल कमांड (बाएं) और एपीआई कॉल (दाएं)" इकट्ठे हुए
हमारे ढांचे, और IFTTT के साथ तुलना। GET- संदेश और GET- ईवेंट क्रमशः ईमेल और कैलेंडर ईवेंट खोजने के लिए दो वेब APIs हैं। एपीआई को विभिन्न मापदंडों के साथ कहा जा सकता है। हम पूरी तरह से मानकीकृत एपीआई कॉल पर ध्यान केंद्रित करते हैं, जबकि IFTTT साधारण मापदंडों के साथ एपीआई तक सीमित है।

आमतौर पर, एपीआई का उपयोग विभिन्न प्रकार के सॉफ़्टवेयर में किया जाता है: डेस्कटॉप एप्लिकेशन, वेबसाइट और मोबाइल एप्लिकेशन। वे एक ग्राफिकल यूजर इंटरफेस (जीयूआई) के माध्यम से उपयोगकर्ताओं की सेवा भी करते हैं। जीयूआई ने कंप्यूटरों के लोकप्रियकरण में एक महान योगदान दिया है, लेकिन जैसे-जैसे कंप्यूटर प्रौद्योगिकी विकसित हुई है, इसकी कई सीमाएं तेजी से प्रकट होती हैं। एक ओर, जैसे-जैसे डिवाइस छोटे, अधिक मोबाइल और स्मार्ट होते जाते हैं, स्क्रीन पर ग्राफिक डिस्प्ले की आवश्यकताएं लगातार बढ़ रही हैं, उदाहरण के लिए, पोर्टेबल उपकरणों या IoT से जुड़े उपकरणों के संबंध में।

दूसरी ओर, उपयोगकर्ताओं को विभिन्न सेवाओं और उपकरणों के लिए विभिन्न विशेष GUI के अनुकूल होना पड़ता है। जैसे ही उपलब्ध सेवाओं और उपकरणों की संख्या बढ़ती है, प्रशिक्षण और उपयोगकर्ता अनुकूलन की लागत भी बढ़ती है। प्राकृतिक भाषा इंटरफेस (NLI), जैसे कि Apple सिरी और Microsoft Cortana वर्चुअल असिस्टेंट, जिन्हें कन्वर्सेशनल या डायलॉग इंटरफेसेस (CUIs) भी कहा जाता है, सर्वर सेवाओं और उपकरणों की एक विस्तृत श्रृंखला के लिए एकल बुद्धिमान उपकरण के रूप में महत्वपूर्ण क्षमता प्रदर्शित करता है।

इस पत्र में, हम एपीआई (NL2API) के लिए एक प्राकृतिक भाषा इंटरफ़ेस बनाने की समस्या पर विचार करते हैं। लेकिन, आभासी सहायकों के विपरीत, ये सामान्य-उद्देश्य एनएलआई नहीं हैं,
हम विशिष्ट वेब APIs के लिए NLIs बनाने के लिए दृष्टिकोण विकसित कर रहे हैं, अर्थात् ESPN1 मल्टीस्पोर्ट्स सेवा जैसी वेब सेवाएँ APIs। ऐसे NL2API वितरित विकास को सक्षम करके सामान्य-प्रयोजन NLIs की स्केलेबिलिटी समस्या को हल कर सकते हैं। एक आभासी सहायक की उपयोगिता काफी हद तक इसकी क्षमताओं की चौड़ाई पर निर्भर करती है, अर्थात, यह सेवाओं की संख्या पर समर्थन करती है।

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

उदाहरण 1. दो उदाहरण चित्र 1 में दिखाए गए हैं। एपीआई को विभिन्न मापदंडों के साथ कहा जा सकता है। ईमेल खोज एपीआई के मामले में, उपयोगकर्ता विशिष्ट गुणों द्वारा ईमेल फ़िल्टर कर सकते हैं या कीवर्ड द्वारा ईमेल खोज सकते हैं। NL2API का मुख्य कार्य NL कमांड को संबंधित API कॉल में मैप करना है।

टास्क। प्रशिक्षण डेटा का संग्रह एनएलआई इंटरफेस और उनके व्यावहारिक अनुप्रयोग के विकास में अनुसंधान से जुड़े सबसे महत्वपूर्ण कार्यों में से एक है। NLIs नियंत्रित प्रशिक्षण डेटा का उपयोग करते हैं, जो NL2API के मामले में शब्दार्थों का अध्ययन करने के लिए "NL कमांड - API कॉल" के जोड़े होते हैं और अभिप्रेरित रूप से अभ्यावेदन के लिए अप्रत्यक्ष रूप से मैप एनएल कमांड का अध्ययन करते हैं। प्राकृतिक भाषा बहुत लचीली है, इसलिए उपयोगकर्ता एपीआई कॉल का वाक्यात्मक रूप से अलग-अलग तरीकों से वर्णन कर सकते हैं, अर्थात, पैराफ़्रासिंग होता है।

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

हालांकि, अगर एपीआई समर्थित नहीं है या पूरी तरह से समर्थित नहीं है, तो स्थिति को ठीक करने का कोई तरीका नहीं है। इसके अलावा, इस तरह से एकत्र किया गया प्रशिक्षण डेटा कई मापदंडों के साथ उन्नत आदेशों का समर्थन करने के लिए लागू नहीं है। उदाहरण के लिए, हमने महीने के लिए ईमेल खोजने के लिए Microsoft API कॉल लॉग्स का अनाम विश्लेषण किया और पाया कि उनमें से लगभग 90% दो या तीन मापदंडों (लगभग समान राशि) का उपयोग करते हैं, और ये पैरामीटर काफी विविध हैं। इसलिए, हम एपीआई के मानकीकरण के लिए पूर्ण समर्थन प्रदान करने और उन्नत एनएल कमांड को लागू करने का प्रयास करते हैं। वर्तमान में एक विशिष्ट एपीआई के लिए प्रशिक्षण डेटा एकत्र करने की एक सक्रिय और अनुकूलन योग्य प्रक्रिया को तैनात करने की समस्या अनसुलझे बनी हुई है।

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

हम वेब एपीआई के लिए एक मध्यवर्ती अर्थ प्रतिनिधित्व का उपयोग करने का सुझाव देते हैं, ताकि अनावश्यक जानकारी के साथ एनएलआई को अधिभार न डालें। (२) प्रशिक्षण डेटा का एक सेट। हम क्राउडसोर्सिंग के आधार पर नियंत्रित प्रशिक्षण डेटा प्राप्त करने के लिए एक नया दृष्टिकोण प्रदान करते हैं। (3) NL2API। हम दो NL2API मॉडल भी प्रस्तुत करते हैं: एक भाषा-आधारित निष्कर्षण मॉडल और एक आवर्तक तंत्रिका नेटवर्क मॉडल (Seq2Seq)।

इस काम के प्रमुख तकनीकी परिणामों में से एक भीड़-भाड़ पर आधारित NL2API के लिए प्रशिक्षण डेटा के सक्रिय संग्रह के लिए एक मौलिक रूप से नया दृष्टिकोण है - हम NL कमांड्स के साथ तुलना करते समय एपीआई कॉल को एनोटेट करने के लिए दूरस्थ अधिकारियों का उपयोग करते हैं। यह आपको प्रदान करके तीन डिज़ाइन लक्ष्यों को प्राप्त करने की अनुमति देता है: (1) कस्टमिज़ेबिलिटी। आपको यह निर्दिष्ट करने में सक्षम होना चाहिए कि किस एपीआई के लिए कौन से पैरामीटर का उपयोग करना है और कितना डेटा इकट्ठा करना है। (२) कम लागत। क्राउडसोर्सिंग श्रमिकों की सेवाएं विशिष्ट विशेषज्ञों की सेवाओं की तुलना में सस्ता परिमाण का एक आदेश है, यही कारण है कि उन्हें काम पर रखा जाना चाहिए। (३) उच्च कोटि का। प्रशिक्षण डेटा की गुणवत्ता को कम नहीं किया जाना चाहिए।

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

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

दूसरे, आपको यह समझने की आवश्यकता है कि केवल उन एपीआई कॉल को कैसे परिभाषित और एनोटेट करना है जो एनएल 2 एपीआई सीखने के लिए वास्तविक मूल्य हैं। पैरामीटर के दौरान उठने वाला "कॉम्बिनेटरियल विस्फोट" इस तथ्य की ओर जाता है कि एक एपीआई के लिए भी कॉल की संख्या काफी बड़ी हो सकती है। सभी कॉल को एनोटेट करने का कोई मतलब नहीं है। हम क्राउडसोर्सिंग प्रक्रिया के कार्यान्वयन के लिए एक मौलिक रूप से नए पदानुक्रमित संभावित मॉडल की पेशकश करते हैं (खंड 3.2 देखें)। जानकारी प्राप्त करने के उद्देश्य से भाषा मॉडलिंग के साथ समानता से, हम मानते हैं कि एनएल कमांड इसी एपीआई कॉल के आधार पर उत्पन्न होते हैं, इसलिए इस "पीढ़ी" प्रक्रिया को पंजीकृत करने के लिए प्रत्येक एपीआई कॉल के लिए भाषा मॉडल का उपयोग किया जाना चाहिए।

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

बेशक, परिकलित भाषा मॉडल आदर्श से बहुत दूर हैं, अन्यथा हम पहले ही NL2API बनाने की समस्या को हल कर चुके होते। फिर भी, गैर-निर्दिष्ट एपीआई कॉल के लिए भाषा मॉडल का ऐसा एक्सट्रपलेशन हमें एपीआई कॉल के संपूर्ण स्थान के साथ-साथ प्राकृतिक भाषा और एपीआई कॉल की बातचीत का एक समग्र दृष्टिकोण देता है, जो हमें क्राउडसोर्सिंग प्रक्रिया का अनुकूलन करने की अनुमति देता है। धारा 3.3 में, हम एपीआई कॉल को अलग पहचान देने में मदद करने के लिए चुनिंदा एनोटेटिंग के लिए एक एल्गोरिथ्म का वर्णन करते हैं, जो कि उनके भाषा मॉडल के बीच विसंगति को अधिकतम करने के लिए है।

हम Microsoft ग्राफ़ API API2 पैकेज से दो परिनियोजित API के लिए अपना ढांचा लागू करते हैं। हम प्रदर्शित करते हैं कि यदि प्रस्तावित दृष्टिकोण का उपयोग किया जाता है तो उच्च-गुणवत्ता वाले प्रशिक्षण डेटा को न्यूनतम लागत पर एकत्र किया जा सकता है। हम यह भी दिखाते हैं कि हमारा दृष्टिकोण क्राउडसोर्सिंग में सुधार करता है। इसी तरह की लागत पर, हम बेहतर प्रशिक्षण डेटा एकत्र करते हैं, बेसलाइन से काफी अधिक है। नतीजतन, हमारे NL2API समाधान उच्च सटीकता प्रदान करते हैं।

सामान्य तौर पर, हमारे मुख्य योगदान में तीन पहलू शामिल हैं:

• हम NL2API की समस्याओं का अध्ययन करने वाले पहले लोगों में से एक थे और खरोंच से NL2API बनाने के लिए एक व्यापक रूपरेखा का प्रस्ताव किया।
• हमने इस प्रक्रिया को अनुकूलित करने के लिए क्राउडसोर्सिंग और मौलिक रूप से नए पदानुक्रमिक संभाव्यता मॉडल का उपयोग करके प्रशिक्षण डेटा के संग्रह के लिए एक अनूठा दृष्टिकोण प्रस्तावित किया।
• हमने अपने ढांचे को वास्तविक वेब एपीआई पर लागू किया और प्रदर्शित किया कि खरोंच से पर्याप्त प्रभावी NL2API समाधान बनाया जा सकता है।

तालिका 1. OData क्वेरी पैरामीटर।

प्रस्तावना

रेस्टफुल एपीआई

हाल ही में, वेब APIs जो REST आर्किटेक्चरल स्टाइल, यानी RESTful API का अनुपालन करते हैं, अपनी सादगी के कारण अधिक से अधिक लोकप्रिय हो रहे हैं। RESTful API का उपयोग स्मार्टफोन और IoT डिवाइस पर भी किया जाता है। रेस्टफुल एपीआई यूआरआई के माध्यम से संबोधित संसाधनों के साथ काम करते हैं और सरल HTTP कमांड का उपयोग करके ग्राहकों की एक विस्तृत श्रृंखला के लिए इन संसाधनों तक पहुंच प्रदान करते हैं: GET, PUT, POST, आदि। हम मुख्य रूप से RESTful API के साथ काम करेंगे, लेकिन मूल तरीकों का उपयोग किया जा सकता है। और अन्य एपीआई।

उदाहरण के लिए, RESTful API के लिए लोकप्रिय Open Data Protocol (OData) लें और क्रमशः Microsoft ग्राफ़ API पैकेज (चित्र 1) से दो वेब API का उपयोग ईमेल और उपयोगकर्ता कैलेंडर ईवेंट के लिए किया जाता है। ओडटा में संसाधन संस्थाएं हैं, जिनमें से प्रत्येक संपत्तियों की एक सूची के साथ जुड़ा हुआ है। उदाहरण के लिए, संदेश इकाई - एक ईमेल - जिसमें विषय (विषय), जैसे (से), isRead (पढ़ा), प्राप्त दिनांक (प्राप्ति का समय और समय), आदि जैसे गुण हैं।

इसके अलावा, ओडटा क्वेरी मापदंडों के एक सेट को परिभाषित करता है, जिससे आप संसाधनों पर उन्नत जोड़तोड़ कर सकते हैं। उदाहरण के लिए, फ़िल्टर पैरामीटर आपको किसी विशिष्ट प्रेषक या विशिष्ट तिथि पर प्राप्त पत्रों से ईमेल की खोज करने की अनुमति देता है। अनुरोध पैरामीटर जो हम उपयोग करेंगे, उन्हें तालिका 1 में प्रस्तुत किया गया है। हम एक कमांड के रूप में HTTP कमांड और इकाई (या संस्थाओं का सेट) के प्रत्येक संयोजन को उदाहरण के लिए, GET- संदेश - ईमेल के लिए खोजते हैं। उदाहरण के लिए, किसी भी मानकीकृत अनुरोध, FILTER (isRead = False) को एक पैरामीटर कहा जाता है, और एक एपीआई कॉल पैरामीटर की सूची के साथ एक एपीआई है।

NL2API

एनएलआई का मुख्य कार्य एक बयान (एक प्राकृतिक भाषा में एक कमांड) की तुलना एक औपचारिक औपचारिक प्रतिनिधित्व के साथ करना है, उदाहरण के लिए, तार्किक आधार या हमारे मामले में ज्ञान एपीआई या वेब एपीआई के लिए SPARQL प्रश्न। जब अप्रासंगिक विवरणों से विचलित हुए बिना सिमेंटिक मैपिंग पर ध्यान केंद्रित करना आवश्यक होता है, तो एक मध्यवर्ती सिमेंटिक प्रतिनिधित्व आमतौर पर उपयोग किया जाता है ताकि लक्ष्य के साथ सीधे काम न करें। उदाहरण के लिए, दहनशील श्रेणीबद्ध व्याकरण का व्यापक रूप से डेटाबेस और ज्ञान के आधार के लिए एनएलआई बनाने में उपयोग किया जाता है। एब्सट्रैक्शन के लिए एक समान दृष्टिकोण NL2API के लिए भी बहुत महत्वपूर्ण है। URL सम्मेलनों, HTTP हेडर और प्रतिक्रिया कोड सहित कई विवरण, NL2API को मुख्य समस्या - अर्थ मैपिंग को हल करने से "विचलित" कर सकते हैं।

इसलिए, हम एपीआई फ्रेम के नाम के साथ RESTful APIs (चित्र 2) के लिए एक मध्यवर्ती दृश्य बनाते हैं; यह दृश्य फ्रेम के शब्दार्थ को दर्शाता है। एपीआई फ्रेम में पांच भाग होते हैं। HTTP Verb (HTTP कमांड) और संसाधन एक RESTful API के लिए मूल तत्व हैं। रिटर्न प्रकार आपको समग्र एपीआई बनाने की अनुमति देता है, अर्थात, अधिक जटिल ऑपरेशन करने के लिए कई एपीआई कॉल को संयोजित करें। आवश्यक पैरामीटर एपीआई में सबसे अधिक बार PUT या POST कॉल में उपयोग किए जाते हैं, उदाहरण के लिए, ई-मेल भेजने के लिए संदेश का पता, हेडर और बॉडी आवश्यक पैरामीटर हैं। वैकल्पिक पैरामीटर अक्सर एपीआई में जीईटी कॉल में मौजूद होते हैं, वे सूचना अनुरोध को कम करने में मदद करते हैं।

यदि आवश्यक पैरामीटर गायब हैं, तो हम एपीआई फ्रेम को क्रमबद्ध करते हैं, उदाहरण के लिए: GET-messages {FILTER (isRead = False), SEARCH ("PhD एप्लिकेशन"), COUNT ()}। एक एपीआई फ्रेम को नियतात्मक और वास्तविक एपीआई कॉल में परिवर्तित किया जा सकता है। रूपांतरण प्रक्रिया के दौरान, उपयोगकर्ता आईडी, स्थान, दिनांक और समय सहित आवश्यक प्रासंगिक डेटा जोड़ा जाएगा। दूसरे उदाहरण में (चित्र 1), एपीआई पैरामीटर में अब मूल्य एपीआई फ्रेम के वास्तविक एपीआई कॉल में रूपांतरण के दौरान संबंधित कमांड के निष्पादन की तारीख और समय से बदल दिया जाएगा। इसके अलावा, एक एपीआई फ्रेम और एक एपीआई कॉल की अवधारणाओं का परस्पर उपयोग किया जाएगा।


चित्रा 2. एपीआई फ्रेम। ऊपर: प्राकृतिक भाषा टीम बीच में: फ़्रेम एपीआई। नीचे: एपीआई कॉल।


3. .

NL2API . API , ( 3.1), ( 3). API, ( 3.2), ( 3.3).


4. . : . : .

API

API API. , , API, API . , Boolean, (True/False).

, Datetime, , today this_week receivedDateTime. , API (, ) API API.

, API . . , TOP, ORDERBY. , Boolean, isRead, ORDERBY . « » API API.

API. API . API API ( 4). ( HTTP, , ). , ⟨sender → NP[from]⟩ , from «sender», — (NP), .

(V), (VP), (JJ), - (CP), , (NP/NP), (PP/NP), (S) . .

, API , RESTful API OData — « » . 17 4 API, ( 5).

, API. ⟨t1, t2, ..., tn → c[z]⟩, , z API, cz — . 4. API , S, G4, API . C , , - «that is not read».

, . , VP[x = False] B2, B4, x. x VP, B2 (, x is hasAttachments → «do not have attachment»); JJ, B4 (, x is isRead → «is not read»). («do not read» or «is not have attachment») .

हम उपरोक्त दृष्टिकोण का उपयोग करके बड़ी संख्या में एपीआई कॉल उत्पन्न कर सकते हैं, लेकिन क्राउडसोर्सिंग का उपयोग करके उन सभी को एनोटेट करना आर्थिक रूप से संभव नहीं है। इसलिए, हम क्राउडसोर्सिंग के लिए एक पदानुक्रमित संभावित मॉडल का प्रस्ताव करते हैं जो आपको यह तय करने में मदद करता है कि एपीआई कॉल को एनोटेट किया जाना चाहिए। जहां तक ​​हम जानते हैं, एनएलआई इंटरफेस बनाने के लिए क्राउडसोर्सिंग का उपयोग करने का यह पहला संभावित मॉडल है, जो हमें प्राकृतिक भाषा अभ्यावेदन और औपचारिक शब्दार्थ संरचना निरूपण के बीच की बातचीत के मॉडलिंग के अनूठे और पेचीदा कार्य को हल करने की अनुमति देता है। विशेष रूप से सिमेंटिक संरचना के औपचारिक अभ्यावेदन और विशेष रूप से एपीआई कॉल प्रकृति में रचनात्मक हैं। उदाहरण के लिए, z12 = GET-Messages {COUNT (), FILTER (isRead = False)} में z1 = GET-संदेश {FILTER (isRead = False)} और z2 = GET-Messages (COUNT) ()} शामिल हैं (ये उदाहरण अधिक विस्तृत हैं) आगे चर्चा)।


चित्रा 5. सिमेंटिक नेटवर्क। Ith लेयर में i पैरामीटर के साथ API कॉल होते हैं। पसलियाँ रचनाएँ हैं। वर्टीकल पर प्रायिकता वितरण संबंधित भाषा के मॉडल को चिह्नित करता है।

हमारे अध्ययन के प्रमुख परिणामों में से एक यह पुष्टि थी कि ऐसी संरचना का उपयोग क्राउडसोर्सिंग प्रक्रिया को मॉडल करने के लिए किया जा सकता है।

सबसे पहले, हम एपीआई कॉल मापदंडों के एक सेट के आधार पर रचना को परिभाषित करते हैं।

परिभाषा 3.1 (रचना)। एपीआई और एपीआई कॉल का एक सेट लें
अगर हम r (z) को z के लिए मापदंडों के एक सेट के रूप में परिभाषित करते हैं, तो एक रचना है अगर और केवल अगर हिस्सा है

एपीआई कॉल के कंपोजिटिव रिलेशनशिप के आधार पर, आप सभी एपीआई कॉल को एक एकल श्रेणीबद्ध संरचना में व्यवस्थित कर सकते हैं। समान संख्या में मापदंडों के साथ एपीआई कॉल को एक परत के कोने के रूप में दर्शाया जाता है, और रचनाओं का प्रतिनिधित्व किया जाता है
परतों के बीच निर्देशित पसलियों। हम इस संरचना को एक अर्धचालक नेटवर्क (या सीमेश) कहते हैं।

सूचना पुनर्प्राप्ति में भाषा मॉडलिंग के आधार पर दृष्टिकोण के अनुरूप, हम मानते हैं कि एक भाषा मॉडल की विशेषता वाले एक स्टोकेस्टिक प्रक्रिया का उपयोग करके एक एपीआई जेड कॉल से संबंधित बयान उत्पन्न होते हैं। । सरल बनाने के लिए, हम शब्दों की संभावनाओं पर ध्यान केंद्रित करते हैं, इस प्रकार जहाँ एक शब्दकोश को दर्शाता है।

ऐसे कारणों के लिए जो थोड़ी देर बाद स्पष्ट हो जाएंगे, मानक भाषा यूनीग्राम मॉडल के बजाय, हम बर्नौली वितरण (बर्नौली का बैग, बीओबी) के एक सेट का उपयोग करने का सुझाव देते हैं। प्रत्येक बर्नौली वितरण एक यादृच्छिक चर डब्ल्यू से मेल खाती है, यह निर्धारित करते हुए कि शब्द w z के आधार पर उत्पन्न वाक्य में दिखाई देता है या नहीं, और BoB वितरण सभी शब्दों के लिए बर्नौली वितरण का एक सेट है । हम उपयोग करेंगे के लिए एक छोटी संकेतन के रूप में ।

मान लीजिए हमने बयानों का एक (बहु) सेट बनाया है z के लिए,
BoB वितरण के लिए अधिकतम संभावना अनुमान (MLE) आपको w युक्त बयानों का चयन करने की अनुमति देता है:



उदाहरण 2. उपरोक्त API कॉल z1 के बारे में, मान लें कि हमें दो कथन u1 = "बिना पढ़े ईमेल मिले" और u2 = "ईमेल जो पढ़े नहीं गए हैं", फिर u = {u1, u2}। pb ("ईमेल" | z) = 1.0, क्योंकि "ईमेल" दोनों कथनों में मौजूद है। इसी प्रकार, pb ("अपठित" | z) = 0.5 और pb ("मीटिंग" | z) = 0.0 |

सिमेंटिक नेटवर्क में, शीर्ष स्तर पर तीन बुनियादी ऑपरेशन होते हैं:
एनोटेशन, लेआउट और इंटरपोलेशन।

ANNOTATE ( एनोटेट करने के लिए) का अर्थ है कथन एकत्र करना क्राउडसोर्सिंग का उपयोग करके वर्टेक्स जेड के विहित कमांड को पैराप्रेशेज करना और अनुभवजन्य वितरण का मूल्यांकन करना अधिकतम संभावना विधि।

COMPOSE (रचना) अपेक्षित वितरण की गणना करने के लिए रचनाओं के आधार पर एक भाषा मॉडल प्राप्त करने की कोशिश करता है । जैसा कि हम प्रायोगिक रूप से दिखाते हैं, Z के लिए एक रचना है। यदि हम इस धारणा से आगे बढ़ते हैं कि संबंधित कथनों को समान संरचना संबंध द्वारा विशेषता है, तो पर रखी जानी चाहिए :



जहां च एक रचना कार्य है। BoB वितरण के लिए, संरचना समारोह इस तरह दिखेगा:



दूसरे शब्दों में, यदि ui एक कथन zi है, तो u एक कथन है शब्द रचना यू का है, तब शब्द का संबंध यू से नहीं है। अगर और केवल अगर यह किसी भी ui से संबंधित नहीं है। जब z की कई रचनाएँ होती हैं, तो ise x की गणना अलग से की जाती है और फिर औसत की जाती है। मानक भाषा यूनिग्राम मॉडल एक प्राकृतिक संरचना संबंधी कार्य नहीं करता है। शब्द संभावनाओं को सामान्य करने की प्रक्रिया में, वाक्यों की लंबाई शामिल होती है, जो बदले में, एपीआई कॉल की जटिलता को ध्यान में रखती है, समीकरण (2) में विघटन का उल्लंघन करती है। यही कारण है कि हम BoB वितरण की पेशकश करते हैं।

उदाहरण 3. मान लीजिए कि हमने पहले उल्लिखित एपीआई कॉल के लिए एक एनोटेशन तैयार किया z1 और z2, जिनमें से प्रत्येक में दो कथन हैं: = {"बिना पढ़े ईमेल खोजें", "ऐसे ईमेल जो पढ़े नहीं जाते हैं"} और = {"मेरे पास कितने ईमेल हैं", "ईमेल की संख्या का पता लगाएं"}। हमने भाषा मॉडल का मूल्यांकन किया और । रचना ऑपरेशन मूल्यांकन करने की कोशिश कर रही है बिना पूछे । उदाहरण के लिए, शब्द "ईमेल" के लिए, pb ("ईमेल" | z1) = 1.0 और pb ("ईमेल" | z2) = 1.0, इसलिए यह समीकरण (3) से आता है जो pb ("ईमेल" | z12) = है। 1.0, अर्थात्, हम मानते हैं कि यह शब्द z12 के किसी भी कथन में शामिल किया जाएगा। इसी तरह, pb ("find" | z1) = 0.5 और pb ("find" | z2) = 0.5, इसलिए pb ("ढूँढें" | z12) = 0.75 | किसी शब्द को किसी भी z1 या z2 से उत्पन्न होने का एक अच्छा मौका है, इसलिए z12 के लिए इसकी संभावना अधिक होनी चाहिए।

बेशक, बयान हमेशा संयुक्त रूप से नहीं होते हैं। उदाहरण के लिए, शब्दार्थ संरचना के एक औपचारिक प्रतिनिधित्व में कई तत्वों को एक प्राकृतिक भाषा में एक शब्द या वाक्यांश में व्यक्त किया जा सकता है, इस घटना को sublexic संरचना कहा जाता है। ऐसा ही एक उदाहरण चित्र 3 में दिखाया गया है, जहाँ तीन पैरामीटर - TOP (1), FILTER (अभी शुरू करें), और ORDERBY (शुरू, asc) - एकल शब्द "अगला" द्वारा दर्शाया गया है। हालांकि, एपीआई कॉल को एनोटेट किए बिना ऐसी जानकारी प्राप्त करना असंभव है, इसलिए समस्या स्वयं चिकन और अंडे की समस्या से मिलती-जुलती है। इस तरह की जानकारी के अभाव में, डिफ़ॉल्ट धारणा का पालन करना उचित है कि बयान एपीआई कॉल के रूप में एक ही रचनात्मक संबंध की विशेषता है।

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

INTERPOLATE (इंटरपोलेशन) z के बारे में सभी उपलब्ध जानकारी को जोड़ती है, अर्थात् एनोटेट किया गया शब्द z और रचनाओं से प्राप्त जानकारी है, और अधिक सटीक अनुमान प्राप्त करता है प्रक्षेप द्वारा और ।



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

अगला, हम सिमेंटिक नेटवर्क अपडेट एल्गोरिथम, अर्थात् गणनाओं का वर्णन करते हैं सभी z (एल्गोरिथ्म 1) के लिए, भले ही केवल कोने का एक छोटा हिस्सा एनोटेट किया गया हो। हम मान लेते हैं कि मूल्य पहले से ही सभी एनोटेटेड साइटों के लिए अपडेट किया गया है। ऊपर से नीचे जाने पर, हम क्रमिक रूप से गणना करते हैं और प्रत्येक शीर्ष के लिए z। सबसे पहले, आपको ऊपरी परतों को अपडेट करने की आवश्यकता है ताकि आप निचले स्तर के कोने के अपेक्षित वितरण की गणना कर सकें। हमने सभी रूट वर्टिकल को एनोटेट किया है, इसलिए हम गणना कर सकते हैं सभी कोने के लिए।

एल्गोरिथम 1. सिमेंटिक मेष के नोड वितरण को अपडेट करें

3.3 क्राउडसोर्सिंग ऑप्टिमाइज़ेशन

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

कई कार्यक्षेत्रों के साथ एक सिमेंटिक नेटवर्क पर विचार करें। हमारा काम पुनरावृत्ति प्रक्रिया के भीतर कोने का एक सबसेट निर्धारित करना है क्राउडसोर्सिंग श्रमिकों द्वारा एनोटेट किया जाना है। पहले किए गए वर्चस्व को राज्य राज्य कहा जाएगा,
फिर हमें नीति नीति खोजने की आवश्यकता है वर्तमान स्थिति के आधार पर प्रत्येक अघोषित वर्टेक्स का मूल्यांकन करने के लिए।

प्रभावी नीतियों की गणना करने के लिए दृष्टिकोणों की चर्चा में आने से पहले, मान लीजिए कि हमारे पास पहले से ही एक है और साथ के तरीकों का वर्णन करने के लिए हमारे क्राउडसोर्सिंग एल्गोरिथ्म (एल्गोरिथम 2) का उच्च-स्तरीय विवरण दें। अधिक विशेष रूप से, हम पहले Z (पंक्ति 3) में सभी कोने के वितरण का मूल्यांकन करने के लिए सभी रूट कोने की व्याख्या करते हैं। प्रत्येक पुनरावृत्ति पर, हम शीर्ष वितरण (पंक्ति 5) को अपडेट करते हैं, गणना करते हैं
सिमेंटिक नेटवर्क (लाइन 6) की वर्तमान स्थिति के आधार पर एक नीति, अधिकतम रेटिंग (लाइन 7) के साथ अननोनॉटेड वर्टेक्स का चयन करें, और वर्टेक्स और नए राज्य (लाइन 8) में परिणाम का एनोटेट करें। व्यावहारिक रूप से, आप कार्यकुशलता बढ़ाने के लिए एक पुनरावृत्ति के हिस्से के रूप में कई शीर्षकों की व्याख्या कर सकते हैं।


चित्रा 6. विभेदक वितरण। z12 और z23 अध्ययन के तहत कोने की जोड़ी का प्रतिनिधित्व करते हैं। w एक अनुमान है जो d (z12, z23) के आधार पर गणना की जाती है, और पुनरावृति प्रत्येक पुनरावृत्ति में दोगुनी हो जाती है। शीर्ष के लिए अनुमान z12 और z23 (इसलिए अंतर) से इसके अनुमानों का पूर्ण अंतर होगा। z2 को 0 का स्कोर मिलता है क्योंकि यह z12 और z23 के लिए सामान्य अभिभावक इकाई है; इस मामले में एनोटेशन z12 और z23 की विशिष्टता सुनिश्चित करने के मामले में बहुत कम उपयोग होगा।

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

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

सबसे पहले, हम लक्ष्य का निर्धारण करेंगे, जिसके आधार पर नोड्स की सूचना सामग्री का मूल्यांकन किया जाएगा। जाहिर है, हम चाहते हैं कि अलग-अलग एपीआई कॉल अलग-अलग हों। सिमेंटिक नेटवर्क में, इसका मतलब है कि वितरण विभिन्न चोटियों में स्पष्ट अंतर हैं। शुरू करने के लिए, हम प्रत्येक वितरण प्रस्तुत करते हैं एक एन-आयामी वेक्टर की तरह जहाँ n = | | - शब्दकोश का आकार। वेक्टर दूरी d की एक निश्चित मीट्रिक d (हमारे प्रयोगों में हम वैक्टर pL1 के बीच की दूरी का उपयोग करते हैं) का अर्थ है , अर्थात्, दो वितरणों के बीच की दूरी उनके वितरण के बीच की दूरी के बराबर है।

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



जहाँ यदि हम आरोही क्रम में दूरी से नोड्स के सभी जोड़ों को रैंक करते हैं, तो पहले के के जोड़े के अंक।

एल्गोरिथ्म 2. एक नीति के साथ Iteratively एक अर्थ जाल को एनोटेट



एल्गोरिथ्म 3. कंप्रेशर प्रपोजल के आधार पर कंप्यूट पॉलिसी



एल्गोरिथ्म 4. एक स्रोत नोड से सभी उसके मूल नोड्स के लिए पुनरावर्ती प्रचार



एनोटेशन के बाद उच्च सूचना सामग्री के साथ कार्यक्षेत्र संभावित रूप से content के मूल्य में वृद्धि करते हैं। इस मामले में परिमाणीकरण के लिए, हम एक विभेदक वितरण रणनीति का उपयोग करने का प्रस्ताव करते हैं। यदि जोड़े की एक जोड़ी के बीच की दूरी छोटी है, तो हम उनके सभी मूल कोने की जाँच करते हैं: यदि पैरेंट वर्टेक्स एक जोड़ी के लिए सामान्य है, तो इसे कम रेटिंग मिलनी चाहिए, क्योंकि एनोटेशन से दोनों कोने के लिए समान परिवर्तन होंगे।

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

ऐसी स्थिति का एक उदाहरण चित्र 6 में दिखाया गया है, और इसकी एल्गोरिथ्म एल्गोरिथ्म है। 3. एक अनुमान के रूप में, हम एक निरंतर (पंक्ति 6) से बंधे नोड दूरी के पारस्परिक लेते हैं, इसलिए शीर्ष जोड़ी के जोड़ सबसे अधिक प्रभाव डालते हैं। जब जोड़ की एक जोड़ी के साथ काम करते हैं, तो हम एक साथ अपने प्रत्येक मूल शीर्ष (पंक्ति 9, 10 और एल्गोरिथ्म) के लिए प्रत्येक शीर्ष का मूल्यांकन प्रदान करते हैं। एक अननोनॉटेड वर्टेक्स का एक अनुमान, वर्टिकल के सभी जोड़े के ऊपर जोड़ के साथ वर्टिकल के वर्टिकल पेयर के अनुमानों में पूर्ण अंतर है (पंक्ति 12)।

प्राकृतिक भाषा इंटरफ़ेस

प्रस्तावित ढांचे का मूल्यांकन करने के लिए, एकत्रित डेटा का उपयोग करके NL2API मॉडल को प्रशिक्षित करना आवश्यक है। फिलहाल, समाप्त NL2API मॉडल उपलब्ध नहीं है, लेकिन हम उन्हें एपीआई में लागू करने के लिए अन्य क्षेत्रों से दो परीक्षण किए गए एनएलआई मॉडल का पालन कर रहे हैं।

भाषा मॉडल निष्कर्षण मॉडल

ज्ञान के आधार के लिए एनएलआई के क्षेत्र में हाल के घटनाक्रमों के आधार पर, हम अपनी शर्तों के लिए भाषा मॉडल (एलएम) के आधार पर निष्कर्षण मॉडल को अनुकूलित करने के लिए सूचना निष्कर्षण की समस्या के संदर्भ में एनएल 2 एपीआई के निर्माण पर विचार कर सकते हैं।

यू कहने के लिए, आपको यू के लिए सबसे अच्छे मैच के साथ सिमेंटिक नेटवर्क में एक एपीआई जेड कॉल खोजने की आवश्यकता है। पहले हम BoB के वितरण को बदलते हैं भाषा unigram मॉडल के लिए एपीआई z के प्रत्येक कॉल:



जहाँ हम योगात्मक चौरसाई का उपयोग करते हैं, और 0 ≤ smooth the 1 चौरसाई पैरामीटर है। उच्च मूल्य अधिक से अधिक शब्दों का वजन जो अभी तक विश्लेषण नहीं किया गया है। एपीआई कॉल को उनके लघुगणकीय संभावना द्वारा क्रमबद्ध किया जा सकता है:



(एक समान प्राथमिकता वितरण के लिए एक समान विषय)



उच्चतम रेटेड एपीआई कॉल को सिमुलेशन परिणाम के रूप में उपयोग किया जाता है।

Seq2Seq rephrase मॉड्यूल

एनएलआई के लिए मॉडल के रूप में तंत्रिका नेटवर्क अधिक व्यापक होते जा रहे हैं, जबकि Seq2Seq मॉडल इस उद्देश्य के लिए दूसरों की तुलना में बेहतर है, क्योंकि यह आपको स्वाभाविक रूप से चर लंबाई के इनपुट और आउटपुट दृश्यों को संसाधित करने की अनुमति देता है। हम इस मॉडल को NL2API के लिए अनुकूलित करते हैं।

इनपुट अनुक्रम के लिए ई , मॉडल सभी संभावित आउटपुट अनुक्रमों के लिए सशर्त संभाव्यता वितरण p (y | x) का अनुमान लगाता है । टी और टी की लंबाई अलग-अलग हो सकती है और किसी भी मूल्य पर ले जा सकती है। NL2API में, x आउटपुट स्टेटमेंट है। y एक क्रमबद्ध एपीआई कॉल या इसकी विहित कमांड हो सकती है। हम लक्ष्य आउटपुट दृश्यों के रूप में विहित कमांड का उपयोग करेंगे, जो वास्तव में हमारी समस्या को एक रीफ़्रेशिंग समस्या में बदल देता है।

नियंत्रित पुनरावृत्ति इकाइयों (GRU) के साथ एक आवर्तक तंत्रिका नेटवर्क (RNN) के रूप में कार्यान्वित एनकोडर पहले x को निश्चित आकार के वेक्टर के रूप में प्रस्तुत करता है,



जहां आरएन एन जीआरयू को पूरे इनपुट अनुक्रम में लागू करने के लिए एक संक्षिप्त प्रतिनिधित्व है, मार्कर द्वारा मार्कर, अंतिम छिपे हुए राज्य के आउटपुट के बाद।

डिकोडर, जो कि GRN के साथ एक RNN भी है, प्रारंभिक स्थिति के रूप में h0 लेता है और राज्यों के अनुक्रम को उत्पन्न करने के लिए आउटपुट अनुक्रम y, मार्कर द्वारा मार्कर को संसाधित करता है,



आउटपुट लेयर प्रत्येक डिकोडर स्टेट को इनपुट वैल्यू के रूप में लेता है और डिक्शनरी डिस्ट्रीब्यूशन जेनरेट करता है आउटपुट मान के रूप में। हम बहु-परिवर्तनशील लॉजिस्टिक फ़ंक्शन सॉफ्टमैक्स के बाद के एफाइन ट्रांसफ़ॉर्म का उपयोग करते हैं:



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

esperimenty

प्रायोगिक तौर पर, हम निम्नलिखित शोध विषयों का अध्ययन करते हैं: [PI1]: क्या हम उचित मूल्य पर उच्च गुणवत्ता वाले प्रशिक्षण डेटा एकत्र करने के लिए प्रस्तावित ढांचे का उपयोग कर सकते हैं? [PI2]: क्या अर्थ नेटवर्क अधिकतम संभावना आकलन की तुलना में भाषा मॉडल का अधिक सटीक मूल्यांकन प्रदान करता है? [PI3]: क्या अंतर वितरण रणनीति क्राउडसोर्सिंग दक्षता में सुधार करती है?

क्राउडसोर्सिंग

-API Microsoft — GET-Events GET-Messages — . API, API ( 3.1) . API 2. , Amazon Mechanical Turk. , API .

. API 10 , 10 . 201 , . 44 , 82 , 8,2 , , , . , 400 , 17,4 %.

(, ORDERBY a COUNT parameter) (, , ). . NLI. , , [1] . .

, , , , API (. 3). API . , . 61 API 157 GET-Messages, 77 API 190 GET-Events. , , API (, ) , , .


2. API.


3. : ().

, , . , α = 0,3, LM β = 0,001. K, , 100 000. , , Seq2Seq — 500. ( ).

NLI, . .

. , , . LM: , . , . ROOT — . TOP2 = ROOT + 2; TOP3 = TOP2 + 3. .

4. LM (MLE) , , . , , , MLE .

MLE, , - , . API . 16 API (ROOT) LM SeMesh Seq2Seq API (TOP2) , 500 API (TOP3).

, , , , ( 3.2) . , GET-Events , GET-Messages. , GET-Events
, , , .


4. . LM, Seq2Seq, . , .

LM + , , θem with । , , ROOT, । , , . MLE. , , [2] .

0,45 0,6: , NLI . , API. API (. 7) , RNN , . .

. : |u | α. - LM ( 7). , |u | < 10, 10 . GET-Events, GET-Messages .

, , , . , , . , α, ([0.1, 0.7]). α , , .

(DP) . API . 50 API, , NL2API .

, . LM, . . , ( 5.1), API .


7. .


8. . : GET-Events. : GET-Messages

breadth first (BF), . . . API , API .

8. NL2API API DP . 300 API, Seq2Seq, DP 7 % API. , . , DP API, NL2API. , , [3] .

- . - (NLI) . NLI . , , . .

NLI , -, API . NL2API : API , - , . . API REST .

NLI. NLI « ». , Google Suggest API, API IFTTT. NLI, . , .

NLI, . NLI , . , , .

API . , -API. .

-API. , -API. , -API API, -API . NL2API , , API.

- -API (NL2API) NL2API . NL2API . : (1) . , , ? (2) .

? (3) NL2API. , API. (4) API. API? (5) : NL2API ?