🙆🏼 👴🏼 🙎 हमने समर्थन सवालों के जवाब देने के लिए कृत्रिम बुद्धिमत्ता कैसे सिखाई। अनुभव यैंडेक्स। टेक्सी 🐝 🥢 👨🏾‍🤝‍👨🏻

कोई आदर्श सेवाएं नहीं हैं - कभी-कभी उपयोगकर्ता के पास तकनीकी सहायता के बारे में प्रश्न होते हैं। यह कहना कठिन है कि ऐसे मामलों में टेम्पलेट बॉट प्रतिकृतियों के संयोजन को जोड़ने की कोशिश करना अधिक अप्रिय है जो समस्या को हल कर सकता है, या एक विशेषज्ञ की प्रतिक्रिया की प्रतीक्षा कर सकता है जो आपके साथ पहले से ही आधे दिन तक संपर्क में रहेगा।

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

क्यों कुछ भी स्वचालित?

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

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

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

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

कहाँ से शुरू करें?

मान लीजिए आप भाग्य से बाहर हैं: ड्राइवर नहीं पहुंचा और संपर्क में नहीं आया। आपके संपर्क Yandex.Taxi समर्थन का क्या होगा?

समस्याओं को और भी तेज़ी से हल करने के लिए क्या अनुकूलित किया जा सकता है? पहले चरण से शुरू करते हैं , जहां टिकट दो लाइनों में से एक पर जाता है। प्रारंभ में, विकल्प क्वेरी में कीवर्ड पर निर्भर करता था - यह काम करता था, लेकिन निर्धारण की सटीकता कम थी। इसे ठीक करने के लिए, क्लासिक न्यूरल नेटवर्क मॉडल-एनकोडर BERT पर आधारित एक क्लासिफायर ने मदद की।

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

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

इस विचार का परीक्षण करने के लिए, एक sujest विकसित किया गया था - एक संकेत प्रणाली जो वर्तमान अनुरोध का जवाब देने के लिए सहायक कर्मचारियों को 3 सबसे पसंदीदा विकल्प प्रदान करती है:

प्रयोग सफल रहा: 70% मामलों में, ऑपरेटरों ने प्रस्तावित संदेशों में से एक को चुना, जिसने प्रतिक्रिया समय को 10% तक कम कर दिया। पहली पंक्ति को पूरी तरह से स्वचालित करने का समय लगता है।

योजना चाहिए।फ्रंट लाइन कर्मचारी क्या करता है ?

पाठ को पढ़ता है, उपचार के विषय को परिभाषित करता है।
यात्रा की जानकारी की जाँच करता है।
पहले दो बिंदुओं को ध्यान में रखते हुए, तैयार उत्तरों में से एक का चयन करता है।

घुसने का एक उदाहरण। दिया गया: एक व्यथित उपयोगकर्ता के लिए एक पाठ अनुरोध, कुछ यात्रा की जानकारी, एक देखभाल सहायक कर्मचारी।

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

ऑटो-उत्तर प्रणाली को क्या करना चाहिए?

सब एक जैसे। यहां तक कि जवाब के लिए मुख्य आवश्यकताएं नहीं बदलेंगी:

गुणवत्ता

यदि उपयोगकर्ता आवेदन के बारे में शिकायत करता है, तो कार को धोने के लिए ड्राइवर से पूछने का वादा करने की कोई आवश्यकता नहीं है। यह समझने के लिए पर्याप्त नहीं है कि समस्या क्या है, किसी को विस्तार से वर्णन करना चाहिए कि इसे कैसे हल किया जाए। विशेष रूप से

गति
यदि स्थिति गंभीर है और जवाब अभी महत्वपूर्ण है।

लचीलापन और मापनीयता।

एक तारांकन के साथ कार्य: हालांकि टैक्सी के साथ एक समर्थन प्रणाली का निर्माण शुरू हो गया है, परिणाम को अन्य सेवाओं में स्थानांतरित करना उपयोगी है: उदाहरण के लिए Yandex.Food या Yandex.Lavka। यही है, जब समर्थन तर्क बदल रहा है - प्रतिक्रिया टेम्पलेट, कॉल के विषय, आदि - मैं महीनों में नहीं, दिन में सिस्टम को फिर से कॉन्फ़िगर करना चाहता हूं।

इसे कैसे लागू किया जाता है

चरण 1. हम एमएल का उपयोग करके पाठ का विषय निर्धारित करते हैं।

सबसे पहले, हमने संदर्भों के विषयों के एक पेड़ को संकलित किया और उन्हें नेविगेट करने के लिए क्लासिफायरियर को प्रशिक्षित किया। लगभग 200 संभावित समस्याएं थीं: यात्रा के साथ (ड्राइवर नहीं आया), आवेदन के साथ (मैं कार्ड संलग्न नहीं कर सकता), कार (गंदी कार), आदि के

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

BERT दो कार्यों पर पूर्व-प्रशिक्षित पाठ के साथ पूर्व-प्रशिक्षित है। पहले में, 15% टोकन को बेतरतीब ढंग से [MASK] से बदल दिया जाता है, और नेटवर्क, संदर्भ के आधार पर, प्रारंभिक टोकन की भविष्यवाणी करता है - यह मॉडल को "प्राकृतिक-दिशात्मकता" प्रदान करता है। दूसरा कार्य हमें प्रस्तावों के बीच संबंध निर्धारित करना सिखाता है: क्या दो प्रविष्टियाँ एक पंक्ति में प्रस्तुत की गई थीं या पूरे पाठ में बिखरी हुई थीं?

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

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

, : , — ;
, . , . , , , .

चरण 2. हम यात्रा के बारे में जानकारी के साथ काम करते हैं: हम प्रत्येक टेम्पलेट के लिए व्यावसायिक नियम लिखते हैं।

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

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

नियम: payment_type" कार्ड "और लेन-देन_स्टैटस" clear_success "और transaction_sum == order_cost है

केवल ग्राहक सहायता टेम्पलेट्स के लिए, हमारे विशेषज्ञ पहले ही 1.5 हजार से अधिक नियमों को पूरा कर चुके हैं।

स्टेज 3. हम उत्तर चुनते हैं: हम टेम्प्लेट के लिए उपयुक्त पाठ विषयों और व्यावसायिक नियमों को जोड़ते हैं।

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

वैसे, Yandex.Taxi में ड्राइवरों के साथ बातचीत की प्रक्रिया बिल्कुल नहीं बदलती है: मॉडल केवल ऑपरेटर के लिए वांछित टेम्पलेट का चयन करता है और स्वतंत्र रूप से उपयोगकर्ता को जवाब देता है।

अंतिम रूप

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

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

और फिर से उदाहरण के लिए। ग्राहकों की सबसे लोकप्रिय विशलिस्ट में से शीर्ष (और हम कोड लिखे बिना उनके साथ कैसे व्यवहार करते हैं):

टैक्सी में शांत ऑटो उत्तर हैं: मैं यैंडेक्स में एक ही चाहता हूं।

हमारे सिस्टम में किसी भी समर्थन को जोड़ने के लिए, आपको चार सरल चरणों की आवश्यकता है:

ग्रंथों के लिए एक विषय वृक्ष बनाएं;
पैटर्न के साथ प्रत्येक विषय का मिलान करें;
हमारे व्यवस्थापक पैनल में टेम्पलेट्स के साथ नियमों का एक सेट भरें;
उपयोगकर्ता के अनुरोधों और समर्थन उत्तरों के बीच एक पत्राचार तालिका प्रदान करें।

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

समर्थन का तर्क बदल गया है, हम नए नियम चाहते हैं

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

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

हमने एक नया विषय जोड़ा, हम मॉडल को बदलना चाहते हैं, हमें कल काम करने के लिए सब कुछ चाहिए।

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

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

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

हम मैट्रिक्स का विश्लेषण करते हैं: सिंक न करें, ब्रेक न करें

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

हालांकि, हम कितनी भी कोशिश कर लें, मशीन सीखने के तरीके कभी-कभी बेतुकी प्रतिक्रियाएँ पैदा करते हैं। मॉडल के अगले अद्यतन के बाद, हमने ऐसा मामला पकड़ा:

उपयोगकर्ता: चालक के लिए धन्यवाद, कार समय पर पहुंची, चालक ने अच्छा किया, सब कुछ पूरी तरह से चला गया! समर्थन
: हम ड्राइवर को दंडित करेंगे, यह फिर से नहीं होगा।

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

भविष्य के लिए निष्कर्ष और योजनाएं

स्वचालित प्रतिक्रिया प्रणाली को जोड़ने के बाद, हमने उपयोगकर्ता के अनुरोधों का अधिक तेज़ी से जवाब देना शुरू कर दिया और वास्तव में जटिल मामलों पर अधिक से अधिक ध्यान देना चाहिए जिनके लिए विस्तृत जांच की आवश्यकता होती है। हमें उम्मीद है कि यह हमें Yandex.Taxi की गुणवत्ता में सुधार करने में मदद करेगा और अप्रिय घटनाओं की संख्या को कम करेगा।

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