يتوقع المستخدمون ، بعد أن تحدثوا مع مساعدين صوتيين أذكياء ، من روبوتات الدردشة. إذا كنت تقوم بتطوير روبوت للأعمال ، فإن التوقعات أعلى من ذلك: يريد العميل أن يتبع المستخدم السيناريو المطلوب والمسبق مسبقًا ، ويريد المستخدم من الروبوت أن يجيب بذكاء ويفضل أن يجيب على الأسئلة المطروحة بشكل ذكي ويفضل أن يساعد في حل المشكلات ، وأحيانًا ما يدعم الحديث الصغير.
نقوم بعمل روبوتات الدردشة باللغة الإنجليزية التي تتواصل مع المستخدمين من خلال قنوات مختلفة - Facebook Messenger و SMS و Amazon Alexa والويب. الروبوتات لدينا تحل محل خدمات الدعم ووكلاء التأمين وتكون قادرة على الدردشة فقط. كل من هذه المهام تتطلب نهج التنمية الخاصة بها.
في هذه المقالة ، سنخبرك عن الوحدات التي تتكون منها خدمتنا ، وكيفية صنع كل منها ، والنهج الذي اخترناه ولماذا. سنشارك خبرتنا في تحليل الأدوات المختلفة: عندما لا تكون الشبكات العصبية التوليدية هي الخيار الأفضل ، فلماذا نستخدم Word2vec بدلاً من Doc2vec ، ما هو سحر ورعب ChatScript وما إلى ذلك.
للوهلة الأولى ، قد يبدو أن المشاكل التي نحلها تافهة إلى حد ما. ومع ذلك ، في مجال معالجة اللغات الطبيعية ، هناك عدد من الصعوبات المرتبطة بالتنفيذ الفني والعامل البشري.
- يتكلم مليار شخص اللغة الإنجليزية ، ويستخدمها كل متحدث أصلي بطريقتهم الخاصة: هناك العديد من اللهجات وميزات الكلام الفردية.
- العديد من الكلمات والعبارات والتعابير غامضة: مثال نموذجي في هذه الصورة.
- يتطلب التفسير الصحيح لمعنى الكلمات السياق. ومع ذلك ، فإن البوت الذي يسأل العميل لتوضيح الأسئلة لا يبدو رائعًا مثل السؤال الذي يمكنه التبديل إلى أي موضوع بناءً على طلب المستخدم والإجابة على أي سؤال.
- في كثير من الأحيان في الكلام الحي والمراسلات ، إما أن يهمل الناس قواعد النحو أو يجيبوا لفترة وجيزة بحيث يكاد يكون من المستحيل استعادة بنية الجملة.
- في بعض الأحيان ، للإجابة على سؤال المستخدم ، من الضروري مقارنة طلبه بنصوص الأسئلة الشائعة. في الوقت نفسه ، تحتاج إلى التأكد من أن النص الموجود في الأسئلة الشائعة هو بالفعل الجواب ، ولا يحتوي فقط على عدة كلمات تتطابق مع الطلب.
هذه ليست سوى بعض من أكثر الجوانب وضوحًا ، وهناك عامية ، ومصطلحات ، وروح دعابة ، وسخرية ، وأخطاء إملائية ونطقية ، واختصارات وغيرها من القضايا التي تجعل من الصعب العمل في هذا المجال.
لحل هذه المشاكل ، قمنا بتطوير بوت يستخدم مجموعة من الأساليب. يتكون جزء الذكاء الاصطناعي من نظامنا من مدير الحوار وخدمة التعرف والخدمات الدقيقة المعقدة المهمة التي تحل مشاكل معينة: Intent Classifier و FAQ-service و Small Talk.
ابدأ محادثة. مدير الحوار
مهمة Dialog Manager في البوت هي محاكاة برمجية للتواصل مع وكيل مباشر: يجب أن توجه المستخدم من خلال سيناريو محادثة إلى هدف مفيد.
للقيام بذلك ، أولاً ، اكتشف ما يريده المستخدم (على سبيل المثال ، احسب تكلفة التأمين على السيارات) ، وثانيًا ، اكتشف المعلومات الضرورية (العنوان وبيانات المستخدم الأخرى ، وبيانات حول السائقين والسيارات). بعد ذلك ، يجب أن تقدم الخدمة إجابة مفيدة - املأ النموذج وأعط العميل نتيجة هذه البيانات. في الوقت نفسه ، يجب ألا نسأل المستخدم عما أشار إليه بالفعل.
يسمح لك Dialog Manager بإنشاء مثل هذا السيناريو: وصفه برمجيًا ، والبناء من الطوب الصغير - قضايا أو إجراءات محددة يجب أن تحدث في نقطة معينة. في الواقع ، السيناريو هو رسم بياني موجه ، حيث تكون كل عقدة رسالة ، سؤال ، إجراء ، والحافة تحدد ترتيب وشروط الانتقال بين هذه العقد ، إذا كان هناك اختيار متعدد للانتقال من عقدة إلى أخرى.
الأنواع الرئيسية للعقد
- العقد تنتظر حتى تصل إلى قائمة الانتظار وستظهر في الرسائل.
- العقد التي تنتظر من المستخدم إظهار نية معينة (على سبيل المثال ، اكتب: "أريد الحصول على تأمين").
- العقد التي تنتظر البيانات من المستخدم للتحقق منها وحفظها.
- عقد لتنفيذ التصميمات الحسابية المختلفة (الحلقات ، الفروع ، إلخ).
إذا تم إغلاق العقدة ، فلن يتم نقل التحكم إليها بعد الآن ، ولن يرى المستخدم السؤال الذي تم طرحه بالفعل. وبالتالي ، إذا قمنا بإجراء بحث متعمق في مثل هذا الرسم البياني للعقدة المفتوحة الأولى ، فإننا نتلقى سؤالًا يجب طرحه على المستخدم في وقت معين. في المقابل ، الإجابة على الأسئلة التي يولدها مدير الحوار ، سيغلق المستخدم تدريجياً جميع العقد في الرسم البياني ، وسيعتبر أنه نفذ النص البرمجي الموصوف. بعد ذلك ، على سبيل المثال ، نقدم للمستخدم وصفًا لخيارات التأمين التي يمكننا تقديمها.
"لقد قلت كل شيء بالفعل!"
لنفترض أننا نطلب من المستخدم اسمًا ، وفي رسالة واحدة سيعطي أيضًا تاريخ ميلاده أو اسمه أو جنسه أو حالته الاجتماعية أو عنوانه أو يرسل صورة لرخصة قيادته. سيستخرج النظام جميع البيانات ذات الصلة ويغلق العقد المقابلة ، أي لن يتم طرح أسئلة حول تاريخ الميلاد والجنس.
"بالمناسبة ..."
يوفر مدير الحوار أيضًا القدرة على التواصل في وقت واحد حول العديد من المواضيع. على سبيل المثال ، يقول أحد المستخدمين: "أريد الحصول على تأمين". ثم ، دون إنهاء هذا الحوار ، يضيف: "أريد أن أدفع مقابل سياسة مرفقة سابقًا". في مثل هذه الحالات ، يحفظ مدير الحوار سياق الموضوع الأول ، وبعد الانتهاء من البرنامج النصي الثاني ، يعرض استئناف الحوار السابق من المكان الذي تمت مقاطعته.
من الممكن العودة إلى الأسئلة التي سبق أن أجب عنها المستخدم. لهذا ، يحفظ النظام لقطة الرسم البياني عند استلام كل رسالة من العميل.
ما هي الخيارات؟
بالإضافة إلى نهجنا ، نظرنا في نهج AI آخر لتنفيذ مدير الحوار: يتم تغذية نية المستخدم ومعلماته لمدخلات الشبكة العصبية ، ويولد النظام نفسه الحالات المقابلة ، السؤال التالي الذي سيتم طرحه. ومع ذلك ، في الممارسة العملية ، تتطلب هذه الطريقة إضافة نهج قائم على القاعدة. ربما يكون خيار التنفيذ هذا مناسبًا للسيناريوهات التافهة - على سبيل المثال ، لطلب الطعام ، حيث تحتاج إلى الحصول على ثلاث معلمات فقط: ما يريد المستخدم طلبه ، ومتى يريد استلام الطلب وأين يتم إحضاره. ولكن في حالة السيناريوهات المعقدة ، كما هو الحال في موضوعنا ، لا يزال هذا بعيد المنال. في الوقت الحالي ، لا تستطيع تقنيات تعلُم الآلة توجيه المستخدم نوعيًا إلى الهدف في سيناريو معقد.
تمت كتابة Dialog Manager في Python ، إطار عمل Tornado ، حيث تمت كتابة جزء AI الخاص بنا في البداية كخدمة واحدة. تم اختيار لغة يمكن من خلالها تحقيق كل هذا دون إنفاق الموارد على التواصل.
"دعنا نقرر". خدمة الاعتراف
إن منتجنا قادر على التواصل من خلال قنوات مختلفة ، ولكن جزء الذكاء الاصطناعي مستقل تمامًا عن العميل: يأتي هذا الاتصال فقط في شكل نص وكيل. يقوم مدير الحوار بنقل السياق واستجابة المستخدم وجمع البيانات إلى خدمة التعرف المسؤولة عن التعرف على نية المستخدم واسترجاع البيانات اللازمة.
اليوم ، تتكون خدمة الاعتراف من جزأين منطقيين: مدير الاعتراف ، الذي يدير خط التعرف ، والمستخرجين.
مدير الاعتراف
مدير الاعتراف مسؤول عن جميع المراحل الأساسية للتعرف على معنى الكلام: الرمز المميز ، lemmatization ، إلخ. كما أنه يحدد ترتيب المستخرجين (الأشياء التي تتعرف على الكيانات والسمات في النصوص) التي سيتم من خلالها تخطي الرسالة ، وتقرر متى تتوقف عن الاعتراف والعودة النتيجة النهائية. يسمح لك هذا بتشغيل المستخرجات الضرورية فقط بالترتيب المتوقع.
إذا سألنا عن اسم المستخدم ، فمن المنطقي التحقق أولاً من ما إذا كان الاسم موجودًا في الإجابة. جاء الاسم ، ولم يعد هناك نص مفيد - مما يعني أنه يمكن إكمال التعرف في هذه الخطوة. لقد جاءت بعض الكيانات المفيدة الأخرى ، مما يعني أنه يجب استمرار الاعتراف. على الأرجح ، أضاف الشخص بعض البيانات الشخصية الأخرى - وفقًا لذلك ، تحتاج إلى تشغيل أداة الاستخراج لمعالجة البيانات الشخصية.
اعتمادًا على السياق ، قد يختلف ترتيب بدء تشغيل المستخرجين. يتيح لنا هذا النهج تقليل الحمل بشكل كبير على الخدمة بأكملها.
النازعون
كما ذكر أعلاه ، فإن المستخرجين قادرون على التعرف على كيانات وسمات معينة في النصوص. على سبيل المثال ، يتعرف مستخرج واحد على أرقام الهواتف ؛ آخر يحدد ما إذا كان الشخص أجاب إيجابًا أو سلبًا على سؤال ؛ الثالث - يتعرف على العنوان في الرسالة ويتحقق منه ؛ الرابع بيانات عن سيارة المستخدم. تمرير رسالة من خلال مجموعة من المستخرجين - هذه هي عملية التعرف على رسائلنا الواردة.
من أجل التشغيل الأمثل لأي نظام معقد ، من الضروري الجمع بين الأساليب. لقد التزمنا بهذا المبدأ عند العمل على مستخرجين. سأسلط الضوء على بعض مبادئ العمل التي استخدمناها في المستخرجين.
باستخدام خدماتنا الصغيرة مع التعلم الآلي في الداخل (يرسل المستخرجون رسالة إلى هذه الخدمة ، ويكملونها أحيانًا بالمعلومات التي لديهم ويعيدون النتيجة).
- استخدام علامات نقطة البيع ، التحليل النحوي ، التحليل الدلالي (على سبيل المثال ، تحديد نية المستخدم من خلال الفعل)
- استخدام البحث عن النص الكامل (يمكن استخدامه للعثور على طراز الجهاز وطرازه في الرسائل)
- استخدام التعبيرات العادية وأنماط الاستجابة
- استخدام واجهات برمجة التطبيقات التابعة لجهات خارجية (مثل API لخرائط Google و SmartyStreets وما إلى ذلك)
- البحث الحرفي عن الجمل (إذا أجاب أحد الأشخاص بـ "نعم" بعد قليل ، فلا فائدة من تمريرها من خلال خوارزميات ML للبحث عن النية).
- نستخدم أيضًا حلول معالجة اللغة الطبيعية الجاهزة في المستخرجين.
ما هي الخيارات؟
نظرنا في مكتبات NLTK و Stanford CoreNLP و SpaCy. يسحب NLTK أولاً في Google SERPs عندما تبدأ مراجعة NLP. إنه رائع جدًا لحلول النماذج الأولية ، ولديه وظائف واسعة وبسيطة للغاية. لكن أدائها ضعيف.
ستانفورد CoreNLP لديه ناقص خطير: فهو يسحب آلة جافا الافتراضية مع وحدات كبيرة جدًا ومكتبات مدمجة ويستهلك الكثير من الموارد. بالإضافة إلى ذلك ، من الصعب تخصيص الإخراج من هذه المكتبة.
نتيجة لذلك ، استقرنا في SpaCy ، لأنه يحتوي على وظائف كافية لنا ولديه النسبة المثلى من الخفة والسرعة. تعمل مكتبة SpaCy أسرع بعشرات المرات من NLTK وتقدم قواميس أفضل بكثير. ومع ذلك ، فهو أسهل بكثير من Stanford CoreNLP.
في الوقت الحالي ، نستخدم spaCy للترميز ، وتوجيه الرسائل (باستخدام الشبكة العصبية المدربة المدمجة) ، والاعتراف الأساسي بالمعلمات من النص. نظرًا لأن المكتبة تغطي فقط 5٪ من احتياجات التعرف لدينا ، كان علينا إضافة العديد من الوظائف.
"كان عليه أن يكون ..."
لم تكن خدمة الاعتراف دائمًا عبارة عن هيكل من جزأين. كانت النسخة الأولى هي الأكثر تافهة: لقد تناوبنا باستخدام مستخرجين مختلفين وحاولنا أن نفهم ما إذا كانت هناك أي معلمات أو نوايا في النص. حتى أن الذكاء الاصطناعي لم يكن رائحته هناك - لقد كان نهجًا قائمًا بالكامل على القواعد. كانت الصعوبة هي أن نفس النية يمكن التعبير عنها بأعداد كبيرة من الطرق ، والتي يجب وصف كل منها في القواعد. في هذه الحالة ، من الضروري مراعاة السياق ، حيث قد تتطلب عبارة المستخدم نفسها ، اعتمادًا على السؤال المطروح ، إجراءات مختلفة. على سبيل المثال ، من الحوار: "هل أنت متزوج؟" - "بالفعل عامين" ، يمكنك أن تفهم أن المستخدم متزوج (المعنى المنطقي). ومن الحوار "إلى متى تقود هذه السيارة؟" - "سنتان بالفعل" تحتاج إلى استخراج قيمة "سنتان".
منذ البداية ، فهمنا أن دعم الحلول المستندة إلى القواعد يتطلب الكثير من الجهد ، ومع زيادة عدد النوايا المدعومة ، سيزداد عدد القواعد بشكل أسرع بكثير من حالة النظام المستند إلى ML. ومع ذلك ، وجهة نظر الأعمال. كنا بحاجة إلى تشغيل MVP ، سمح لنا النهج القائم على القواعد بالقيام بذلك بسرعة. لذلك ، استخدمناها ، وعملنا بالتوازي على نموذج ML للتعرف على النوايا. بمجرد ظهوره وبدأ في إعطاء نتائج مرضية ، بدأوا تدريجياً في الابتعاد عن النهج القائم على القواعد.
في معظم حالات استخراج المعلومات ، استخدمنا ChatScript. توفر هذه التقنية لغتها التعريفية الخاصة التي تسمح لك بكتابة قوالب لاستخراج البيانات من لغة طبيعية. بفضل WordNet ، فإن هذا الحل قوي للغاية تحت غطاء المحرك (على سبيل المثال ، يمكنك تحديد "لون" في قالب التعرف ، و WordNet يتعرف على أي مفهوم تضييق ، مثل "أحمر"). لم نر النظير في ذلك الوقت. لكن ChatScript مكتوب بشكل خاطئ للغاية وعربات التي تجرها الدواب ، مع استخدامه يكاد يكون من المستحيل تنفيذ منطق معقد.
في النهاية ، تم تجاوز العيوب ، وتنازلنا عن ChatScript لصالح مكتبات البرمجة اللغوية العصبية في Python.
في الإصدار الأول من خدمة التعرف ، وصلنا إلى الحد الأقصى للمرونة. أدى إدخال كل ميزة جديدة إلى إبطاء النظام بأكمله بشكل كبير.
لذلك قررنا إعادة كتابة خدمة الاعتراف بالكامل ، وتقسيمها إلى جزأين منطقيين: مستخرجون صغيرون وخفيفون ومدير الاعتراف ، الذي سيدير العملية.
"ماذا تريد؟" مصنف النية
لكي يتمكن البوت من التواصل بشكل كافٍ - لتوفير المعلومات الضرورية عند الطلب وتسجيل بيانات المستخدم - من الضروري تحديد نية (نية) المستخدم بناءً على النص المرسل إليه. قائمة النوايا التي يمكننا من خلالها التفاعل مع المستخدمين محدودة بمهام العمل الخاصة بالعميل: قد يكون الهدف هو معرفة شروط التأمين ، وملء معلومات عن نفسك ، والحصول على إجابة لسؤال متكرر ، وما إلى ذلك.
هناك العديد من المقاربات لتصنيف المقاصد استنادًا إلى الشبكات العصبية ، على وجه الخصوص ، LSTM / GRU المتكرر. لقد أثبتوا أنفسهم في الدراسات الحديثة ، ولكن لديهم عيب مشترك: هناك حاجة إلى عينة كبيرة جدًا للتشغيل السليم. على كمية صغيرة من البيانات ، من الصعب تدريب هذه الشبكات العصبية ، أو أنها تنتج نتائج غير مرضية. وينطبق الشيء نفسه على إطار عمل Fast Text (قمنا بمراجعته لأنه حل متطور لمعالجة العبارات القصيرة والمتوسطة).
عينات التدريب لدينا عالية الجودة للغاية: تتكون مجموعات البيانات من فريق بدوام كامل من اللغويين الذين يجيدون اللغة الإنجليزية ويعرفون تفاصيل مجال التأمين. ومع ذلك ، فإن عيناتنا صغيرة نسبيًا. حاولنا تمييعها بمجموعات البيانات العامة ، لكن تلك ، باستثناءات نادرة ، لم تتطابق مع تفاصيلنا. حاولنا أيضًا اجتذاب مستقلين مع Amazon Mechanical Turk ، ولكن تبين أن هذه الطريقة أيضًا غير عاملة: كانت البيانات التي أرسلوها ضعيفة جزئيًا ، وكان يجب فحص العينات مرتين.
لذلك ، كنا نبحث عن حل يعمل على عينة صغيرة. تم توضيح الجودة الجيدة لمعالجة البيانات من خلال المصنف Random Forest ، الذي تم تدريبه على البيانات التي تم تحويلها إلى نواقل نموذج حقيبة الكلمات. باستخدام التحقق المتقاطع ، اخترنا المعلمات المثلى. من بين مزايا نموذجنا السرعة والحجم ، فضلاً عن السهولة النسبية للنشر وإعادة التدريب.
في عملية العمل على Intent Classifier ، أصبح من الواضح أنه بالنسبة لبعض المهام ، فإن استخدامه ليس هو الأمثل. افترض أن المستخدم يريد تغيير الاسم المشار إليه في التأمين أو رقم السيارة. من أجل أن يقوم المصنف بتحديد هذه النية بشكل صحيح ، يجب على المرء أن يضيف يدويًا إلى مجموعة البيانات جميع عبارات القالب المستخدمة في هذه الحالة. وجدنا طريقة أخرى: لإنشاء مستخرج صغير لخدمة التعرف ، التي تحدد النية من خلال الكلمات الرئيسية وأساليب البرمجة اللغوية العصبية ، واستخدام Intent Classifier للعبارات غير القياسية التي لا تعمل فيها الطريقة مع الكلمات الرئيسية.
"إنهم يسألون دائما عن هذا." التعليمات
لدى العديد من عملائنا أقسام الأسئلة الشائعة. من أجل أن يتلقى المستخدم هذه الإجابات مباشرة من برنامج الدردشة الآلي ، كان من الضروري توفير حل من شأنه أ) التعرف على طلب الأسئلة الشائعة ؛ ب) سيجد الإجابة الأكثر صلة في قاعدة بياناتنا ويصدرها.
هناك عدد من النماذج المدربة على مجموعة بيانات ستانفورد SQUAD. تعمل بشكل جيد عندما يحتوي نص الإجابة من الأسئلة الشائعة على الكلمات من سؤال المستخدم. لنفترض أن الأسئلة الشائعة تقول: "قال فرودو أنه سيأخذ الخاتم إلى موردور ، على الرغم من أنه لم يكن يعرف الطريق إلى هناك." إذا سأل المستخدم: "أين سيأخذ فرودو الخاتم؟" ، سيرد النظام: "إلى موردور".
كان السيناريو الخاص بنا ، كقاعدة عامة ، مختلفًا. على سبيل المثال ، لطلبين متشابهين - "هل يمكنني الدفع؟" و "هل يمكنني الدفع عبر الإنترنت؟" يجب أن يستجيب البوت بشكل مختلف: في الحالة الأولى ، قدم للشخص طريقة للدفع ، في الإجابة الثانية - نعم ، يمكنك الدفع عبر الإنترنت ، هنا هو عنوان الصفحة.
تركز فئة أخرى من الحلول لتقييم تشابه المستندات على الإجابات الطويلة - على الأقل بضع جمل ، من بينها تحتوي على معلومات تهم المستخدم. لسوء الحظ ، في الحالات التي تحتوي على أسئلة وإجابات قصيرة ("كيف أدفع عبر الإنترنت؟" - "يمكنك الدفع باستخدام PayPal") فإنها تعمل بشكل غير مستقر للغاية.
الحل الآخر هو نهج Doc2vec: يتم تقطير النص الكبير إلى تمثيل متجه ، والذي يتم مقارنته بعد ذلك بمستندات أخرى في نفس الشكل ويتم الكشف عن معامل التشابه. يجب أيضًا إزالة هذا النهج: فهو يركز على النصوص الطويلة ، لكننا نتعامل بشكل أساسي مع أسئلة وإجابات من جملة أو جملتين.
استند قرارنا على خطوتين. أولاً: باستخدام التضمين ، قمنا بترجمة كل كلمة في جملة إلى متجهات باستخدام نموذج Google Word2vec.
بعد ذلك ، أخذنا في الاعتبار متوسط المتجه لكل الكلمات ، ويمثل جملة واحدة في شكل متجه واحد. الخطوة الثانية ، أخذنا متجه السؤال ووجدنا في قاعدة بيانات الأسئلة الشائعة ، المخزنة في نفس نموذج المتجه ، أقرب إجابة إلى حد معين ، في حالتنا ، جيب التمام.وتشمل المزايا سهولة التنفيذ ، وقابلية التوسعة السهلة للغاية ، والتفسير البسيط إلى حد ما. العيوب هي فرصة تحسين ضعيفة: هذا النموذج من الصعب تعديله - إما أنه يعمل بشكل جيد في معظم حالات المستخدم الخاصة بك ، أو عليك التخلي عنه."وتحدث؟" حديث صغير
في بعض الأحيان يكتب المستخدم شيئًا غير ذي صلة تمامًا ، على سبيل المثال: "الطقس جيد اليوم". لم يتم تضمين هذا في قائمة النوايا التي تهمنا ، لكننا ما زلنا نريد الإجابة بشكل هادف ، مع إظهار ذكاء نظامنا.بالنسبة لمثل هذه القرارات ، يتم استخدام مجموعة من الأساليب الموضحة أعلاه: فهي تستند إما إلى حلول بسيطة جدًا تستند إلى قواعد أو شبكات عصبية مولدة. أردنا الحصول على نموذج أولي مبكرًا ، لذلك أخذنا مجموعة بيانات عامة من الإنترنت واستخدمنا نهجًا مشابهًا جدًا للطريقة المستخدمة في الأسئلة الشائعة. على سبيل المثال ، كتب أحد المستخدمين شيئًا عن الطقس - وباستخدام خوارزمية تقارن تمثيلات متجهية لجملتين بمقياس جيب تمام معين ، نبحث عن جملة في مجموعة البيانات العامة ستكون قريبة من موضوع الطقس قدر الإمكان.تدريب
الآن ليس لدينا هدف لإنشاء روبوت سيتم تدريبه على كل رسالة يتم تلقيها من العملاء: أولاً ، كما تظهر التجربة ، هذه هي طريقة وفاة الروبوت (تذكر كيف اضطر IBM Watson إلى محو القاعدة لأنه بدأ في التشخيص باستخدام حصيرة وتمكن روبوت تويتر من مايكروسوفت من أن يصبح عنصريًا في يوم واحد فقط). ثانياً ، نسعى جاهدين لإغلاق مهام شركات التأمين بشكل نوعي قدر الإمكان ؛ روبوت التعلم الذاتي ليس مهمة عملنا. لقد كتبنا عددًا من الأدوات للغويين وأوامر ضمان الجودة ، والتي يمكنهم من خلالها إعادة تدريب الروبوتات يدويًا من خلال استكشاف الحوارات والمراسلات مع المستخدمين أثناء ما بعد الإشراف.ومع ذلك ، يبدو الروبوت الخاص بنا بالفعل جاهزًا لاجتياز اختبار تورينج. يبدأ بعض المستخدمين محادثة جادة معه ، معتقدين أنهم يتحدثون مع وكيل تأمين ، حتى أن أحدهم بدأ في تهديد شكوى إلى الرئيس عندما أساء البوت فهمه.الخطط
الآن نحن نعمل على الجزء المرئي: عرض الرسم البياني بأكمله للبرنامج النصي والقدرة على إنشائه باستخدام واجهة المستخدم الرسومية.من جانب خدمة التعرف ، نقدم تحليلًا لغويًا للتعرف على معنى كل كلمة في الرسالة وفهمها. سيؤدي ذلك إلى تحسين دقة التفاعل واستخراج البيانات الإضافية. على سبيل المثال ، إذا قام شخص ما بملء تأمين السيارات وذكر أن لديه منزل غير مؤمن عليه ، فسيتمكن البوت من تذكر هذه الرسالة وتمريرها إلى المشغل للاتصال بالعميل وتقديم تأمين على المنزل.ميزة أخرى في العمل هي معالجة التعليقات. بعد الانتهاء من الحوار مع البوت ، نسأل المستخدم عما إذا كان يحب الخدمة. إذا اعتبر تحليل المشاعر أن مراجعة المستخدم إيجابية ، فإننا ندعو المستخدم لمشاركة رأيه على الشبكات الاجتماعية. إذا أظهر التحليل أن رد فعل المستخدم كان سلبيًا ، يوضح برنامج التتبُّع ما هو الخطأ ، ويصلح الإجابة ، ويقول: "حسنًا ، سنصلح ذلك" ، ولا يعرض مشاركة المراجعة في ساحة المشاركات.أحد مفاتيح إجراء التواصل مع البوت قدر الإمكان هو جعل البوت معياري وتوسيع نطاق التفاعلات المتاحة له. نحن نعمل على ذلك. ربما بسبب هذا ، كان المستخدم على استعداد لاتخاذ روبوتنا بإخلاص لوكيل التأمين. الخطوة التالية: تأكد من أن الشخص يحاول شكر الروبوت.
المقالة كُتبت مع سيرجي كوندراتيوك وميخائيل كازاكوف . اكتب أسئلتك في التعليقات ، سنقوم بإعداد المزيد من المواد العملية عليها.