चैट, अर्क: जटिल चैटबॉट्स की वास्तुकला

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


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

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


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


ये सबसे स्पष्ट पहलुओं में से कुछ हैं, और स्लैंग, शब्दजाल, हास्य, कटाक्ष, वर्तनी और उच्चारण त्रुटियां, संक्षिप्तता और अन्य मुद्दे हैं जो इस क्षेत्र में काम करना मुश्किल बनाते हैं।

इन समस्याओं को हल करने के लिए, हमने एक बॉट विकसित किया जो दृष्टिकोण के एक सेट का उपयोग करता है। हमारे सिस्टम के AI भाग में एक डायलॉग मैनेजर, रिकग्निशन सर्विस और महत्वपूर्ण जटिल माइक्रोसर्विसेज होते हैं जो विशिष्ट समस्याओं को हल करते हैं: इंटेंट क्लासिफायर, एफएक्यू-सर्विस, स्मॉल टॉक।

बातचीत शुरू करें। संवाद प्रबंधक


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

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

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


"मैंने पहले ही सब कुछ कह दिया!"


मान लीजिए कि हम उपयोगकर्ता से नाम पूछते हैं, और एक संदेश में वह अपनी जन्मतिथि, नाम, लिंग, वैवाहिक स्थिति, पता, या अपने ड्राइवर के लाइसेंस की एक फोटो भेजेगा। सिस्टम सभी प्रासंगिक डेटा को निकालेगा और संबंधित नोड्स को बंद करेगा, अर्थात जन्म तिथि और लिंग के बारे में सवाल नहीं पूछा जाएगा।

"वैसे ..."


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

उन सवालों पर वापस जाना संभव है जो उपयोगकर्ता पहले ही उत्तर दे चुके हैं। इसके लिए, सिस्टम क्लाइंट से प्रत्येक संदेश प्राप्त होने पर ग्राफ के स्नैपशॉट को बचाता है।

विकल्प क्या हैं?


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

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

"चलो तय करते हैं।" मान्यता सेवा


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

मान्यता प्रबंधक


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

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

संदर्भ के आधार पर, एक्सट्रैक्टर्स का स्टार्ट-अप ऑर्डर भिन्न हो सकता है। यह दृष्टिकोण हमें पूरी सेवा पर भार को कम करने की अनुमति देता है।

एक्सट्रैक्टर्स


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

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

मशीन लर्निंग के साथ हमारे माइक्रोसेरेवल्स का उपयोग करके (एक्सट्रैक्टर इस सेवा को एक संदेश भेजते हैं, कभी-कभी इसे अपने पास मौजूद जानकारी के साथ पूरक करते हैं और परिणाम वापस करते हैं)।

  • पीओएस टैगिंग का उपयोग, सिंथेटिक पार्सिंग, सिमेंटिक पार्सिंग (उदाहरण के लिए, क्रिया द्वारा उपयोगकर्ता के इरादे का निर्धारण)
  • पूर्ण-पाठ खोज का उपयोग करना (संदेश में मशीन के मेक और मॉडल को खोजने के लिए इस्तेमाल किया जा सकता है)
  • रेगुलर एक्सप्रेशंस और रिस्पॉन्स पैटर्न का उपयोग करना
  • तृतीय-पक्ष API का उपयोग (जैसे Google मैप्स API, SmartyStreets, आदि)
  • वाक्यों के लिए एक शब्दशः खोज (यदि किसी व्यक्ति ने शीघ्र ही "हां" जवाब दिया, तो आशय की खोज करने के लिए एमएल-एल्गोरिदम के माध्यम से इसे पारित करने का कोई मतलब नहीं है)।
  • हम अर्क में तैयार प्राकृतिक भाषा प्रसंस्करण समाधान का भी उपयोग करते हैं।

विकल्प क्या हैं?


हमने एनएलटीके, स्टैनफोर्ड कोरएनएलपी और स्पासी लाइब्रेरियों को देखा। जब आप NLP समीक्षा शुरू करते हैं, तो NLTK Google SERPs में सबसे पहले बाहर निकलता है। यह प्रोटोटाइप समाधान के लिए बहुत अच्छा है, इसकी व्यापक कार्यक्षमता है और यह काफी सरल है। लेकिन इसका प्रदर्शन खराब है।

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

परिणामस्वरूप, हम SpaCy पर बस गए, क्योंकि इसमें हमारे लिए पर्याप्त कार्यक्षमता है और लपट और गति का इष्टतम अनुपात है। SpaCy लाइब्रेरी NLTK की तुलना में दर्जनों गुना तेज चलती है और बहुत बेहतर शब्दकोश प्रदान करती है। हालांकि, यह स्टैनफोर्ड कोरएनएलपी की तुलना में बहुत आसान है।

फिलहाल, हम पाठ से मापदंडों की प्राथमिक मान्यता के अनुसार, टोकन का उपयोग, संदेशों के वैश्वीकरण (बिल्ट-इन प्रशिक्षित न्यूरल नेटवर्क का उपयोग) के लिए करते हैं। चूँकि लाइब्रेरी में हमारी पहचान की ज़रूरतों का केवल 5% शामिल है, इसलिए हमें कई कार्यों को जोड़ना पड़ा।

"यह हुआ करता था ..."


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

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

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

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

इसलिए हमने मान्यता सेवा को पूरी तरह से फिर से लिखने का फैसला किया, इसे दो तार्किक भागों में विभाजित किया गया: छोटा, हल्का चिमटा और मान्यता प्रबंधक, जो प्रक्रिया का प्रबंधन करेगा।

"तुम क्या चाहते हो?" इंटेंट क्लासिफायर


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

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

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

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

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

"वे हमेशा इस बारे में पूछते हैं।" पूछे जाने वाले प्रश्न


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

स्टैनफोर्ड स्क्वैड डाटासेट पर प्रशिक्षित कई मॉडल हैं। वे तब अच्छी तरह से काम करते हैं जब FAQ पाठ से उपयोगकर्ता के प्रश्न के शब्द शामिल होते हैं। मान लीजिए कि अक्सर पूछे जाने वाले प्रश्न कहते हैं: "फ्रोडो ने कहा कि वह रिंग को मोर्डोर तक ले जाएगा, हालांकि उसे वहां का रास्ता नहीं पता था।" अगर उपयोगकर्ता पूछता है: "फ्रोडो रिंग कहाँ ले जाएगा?", सिस्टम जवाब देगा: "मोर्डर्स को।"

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

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

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

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

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

"और बात करो?" छोटी सी बात


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

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

ट्रेनिंग


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

फिर भी, हमारा बॉट पहले से ही ट्यूरिंग टेस्ट पास करने के लिए तैयार लगता है। कुछ उपयोगकर्ता उसके साथ एक गंभीर बातचीत शुरू करते हैं, यह मानते हुए कि वे एक बीमा एजेंट के साथ बात कर रहे हैं, और एक ने भी बॉस को शिकायत करने की धमकी देना शुरू कर दिया जब बॉट ने उसे गलत समझा।

योजनाओं


अब हम दृश्य भाग पर काम कर रहे हैं: स्क्रिप्ट का पूरा ग्राफ और GUI का उपयोग करके इसे लिखने की क्षमता प्रदर्शित करना।

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

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

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



यह लेख सर्गेई कोंड्रैट्युक और मिखाइल कज़कोव के साथ लिखा गया था अपने प्रश्नों को टिप्पणियों में लिखें, हम उन पर अधिक व्यावहारिक सामग्री तैयार करेंगे।

Source: https://habr.com/ru/post/hi429638/


All Articles