توسعۀ دستیار هوش مصنوعی در رسا با طراحی مکالمه شروع می‌شود.
در فرایند طراحی مکالمه، دربارۀ این‌ها سؤال می‌شود:
طراحی مکالمه گام بسیار مهمی است که به شما کمک می‌کند تا مقصود و کاربردپذیری (usability) دستیارتان را بهتر درک کنید.
بهترین راه برای شروع طراحی مکالمه این است که به چیزهایی که از قبل دربارۀ مخاطب بالقوۀ خود می‌دانید رجوع کنید.
برای مثال:
اطلاعاتی نظیر این‌ها به شما کمک می‌کند تا رایج‌ترین سؤال‌هایی را که ممکن است مخاطب بالقوه از دستیار شما بپرسد تعریف کنید.
در حالت کلی، طراحی مکالمه کاری چالشی است، چراکه در زندگی واقعی، مکالمه‌ها معمولاً از تعاملات رفت‌وبرگشتی زیادی شکل می‌گیرند؛
به همین دلیل، توصیه می‌شود در مراحل اولیه به مکالمه‌های ساده اکتفا کنید و دستیارتان را توسعه دهید و آن را در اولین فرصت در اختیار کاربرانتان قرار دهید.
همان‌طور که در مطلب اول به‌اختصار اشاره شد، بخش درک زبان طبیعی مبتنی بر دو مفهوم اینتنت و انتیتی عمل می‌کند.
تعریف اینتنت و انتیتی‌ها در رسا در فایل nlu.yml انجام می‌شود. قالب تعریف انتیتی به این صورت است:
[entity_name] (entity_type)
نکته‌هایی که در زمان ایجاد مجموعۀ تعلیم باید به آنها دقت کنید:
واضح است که هرچه تعداد نمونه‌ها بیشتر باشد بهتر است، اما هم‌زمان باید اطمینان پیدا کنید داده‌ای که برای تعلیم مدل به کار گرفته می‌شود دادۀ باکیفیتی باشد.
نیازی نیست که تمامی تنوع‌های هر ورودی بخصوص را بنویسید تا اینتنت را تعلیم دهید.
برای اینکه دستیار شما بتواند اینتنتها را درک کند و انتیتی‌ها را استخراج کند (همان‌طور که اشاره شد، این‌ها در فایل NLU تعریف می‌شوند)، باید یک مدل بسازید.
این کار در ماژول درک زبان طبیعی، از طریق تعریف کردن پایپ‌لاین پردازش، انجام می‌شود.
پایپ‌لاین را می‌شود به‌عنوان دنباله‌ای از گام‌های پردازشی در نظر گرفت که برای استخراج ویژگی‌های خاص متن و تعلیم مؤلفه‌های بخصوصی استفاده می‌شود که به مدل اجازه می‌دهد تا الگوهای زیرین را از مثال‌های ارائه‌شده یاد بگیرد.
با استفاده از رسا، شما هم می‌توانید پایپ‌لاین شخصی‌شده‌ای بسازید و هم می‌توانید از پایپ‌لاین‌های از پیش پیکربندی‌شده استفاده کنید.
دو نمونه از پایپ‌لاین‌های از پیش پیکربندی‌شدۀ موجود در رسا در شکل ۱ نشان داده شده است.
در این مطلب، جزئیات گام‌های این پایپ‌لاین‌ها را بیان نمی‌کنیم، صرفاً به چند قانون سرانگشتی برای انتخاب پایپ‌لاین مناسب برای کاربرد شما اشاره می‌کنیم:
ساختن و پیکربندی کردن هر پایپ‌لاین کاری است که معمولاً از مجموعه‌ای از گام‌های رو به جلو و رو به عقب (رفت و برگشت) تا زمان رسیدن به بهترین نتایج تشکیل می‌شود.
هرچه دادۀ تعلیم بیشتری داشته باشید و بیشتر دربارۀ آنها یاد بگیرید، می‌توانید مدل‌های بهتری بسازید.
داده مهم‌ترین بخش ساخت مدل‌های NLU خوب است. با داشتن دادههای کافی و خوب می‌توانید اطمینان حاصل کنید که تمامی مؤلفه‌هایی که در پایپ‌لاین تعریف کرده‌اید به‌خوبی تعلیم دیده‌اند و مدل شما کاری را که انتظار می‌رود انجام می‌دهد.
در انتهای این بخش، به بررسی پرسش‌های متداول توسعه‌دهندگان و پاسخ آنها می‌پردازیم:
بله.
برخی اوقات، بعضی اینتنتها به‌صورت درخور توجهی، حجم نمونۀ بیشتری نسبت به سایر کلاس‌ها دارند. در یادگیری ماشین به این مسئله، class imbalance می‌گویند و ممکن است روی مدل تأثیر بگذارد و باعث شود که مدل ضعیف عمل کند. چند کار هست که می‌توانید برای حل این مسئله انجام دهید.
خیر، چون علامت‌گذاری‌ها به‌عنوان توکن استخراج نمی‌شوند و در نتیجه، به‌عنوان ویژگی‌های مدل در نظر گرفته نمی‌شوند؛ به همین دلیل، علامت‌گذاری روی خروجی intent classification یا NER تأثیر نمی‌گذارد.
این مسئله به وظیفۀ در حال انجام بستگی دارد. به‌صورت پیش‌فرض، NER به کوچک و بزرگ بودن کاراکترها حساس است، NER توکن‌ها را همان‌طور که هستند (با حروف کوچک و بزرگ) می‌گیرد.
در نقطۀ مقابل، intent classification به‌صورت پیش‌فرض، به کوچک یا بزرگ بودن کاراکترها حساس نیست، چراکه featurizer هر چیزی را به حروف کوچک تبدیل می‌کند.
در این صورت برای مدل خیلی سخت است که بین این اینتنتها (کلاس‌ها) تمایز قائل شود.
با وجود این خیلی مهم است که در زمان ساخت مجموعۀ تعلیم مراقب باشید. معمولاً ایجاد اینتنت‌های جدید ضروری نیست، چراکه نمونه‌ها ممکن است توسط انتیتی‌ها از هم تفکیک شوند.
در شکل‌های ۲ و ۳، نمونه‌ای از ادغام دو اینتنت و تفکیک آنها از طریق انتیتی نشان داده شده است.
برای این منظور، به‌جای دو اینتنت مجزای نام و تاریخ، می‌توانیم یک اینتنت اطلاعات در نظر بگیریم که نوع انتیتی آن در هر نمونه متمایز است.
در ادامه و در دادههای تعلیم dialogue management می‌توانید story pathهای مختلفی تعریف کنید، بر حسب اینکه NLU چه انتیتی‌ای را استخراج کرده است.
اگرچه ازنظر تکنیکی می‌توانید چنین کاری کنید، اما در واقع انجام این کار مزیتی ندارد، چراکه باتوجه‌به نحوۀ کار کردن رسا در حال حاضر، پیش‌بینی‌های آخرین مدل intent classification مشخص‌شده، همواره برنده خواهد شد.
در دنیای واقعی، غلط‌های املایی در ورودی‌های کاربر چیزی است که نمی‌توان از آن اجتناب کرد، اما کارهای کمی هست که می‌توانید انجام دهید تا این مسئله را دور بزنید یا آن را کاهش دهید.
یکی از کارهایی که می‌توانید بکنید پیاده‌سازی نوعی spell checker شخصی‌سازی‌شده و اضافه کردن آن به پیکربندی پایپ‌لاین شخصی‌سازی‌شده‌تان است. این راه خیلی خوبی برای اصلاح غلط‌های املایی در انتیتی‌های استخراج‌شده است. کار دیگری که می‌توانید بکنید این است که نمونه‌هایی با غلط املایی در دادههای تعلیمتان اضافه کنید تا مدل شما آنها را هم بردارد و ببیند.
با ساخت مدل‌های NLU، دستیار شما قادر خواهد بود تا ورودی‌های کاربر را بفهمد.
از طریق مدیریت دیالوگ، دستیار شما درحالی‌که زمینۀ مکالمه را حفظ می‌کند، می‌تواند به مکالمه پاسخ بدهد.
همان‌طور که در بخش اول این مجموعه مطالب بیان شد، در حال حاضر رایج‌ترین روش ساخت دستیارهای هوشمند مکالمه‌ای در بازار از طریق استفاده از مجموعه‌ای از قوانین یا یک ماشین حالت است. این رویکرد مدیریت کردن مسیر موردانتظار را خیلی ساده می‌کند.
اما در مکالمۀ طبیعی، انحراف از این مسیر موردانتظار اجتناب‌ناپذیر است و امکان ندارد شما بتوانید قوانینی برای همۀ انحراف‌های احتمالی از مسیر مکالمه بنویسید.
در صورت استفاده از ماشین حالت، زمانی که مکالمۀ کاربر از مسیر موردانتظار منحرف می‌شود، دستیار شما از کار می‌افتد که این مسئله به خلق تجربۀ کاری ناامیدکننده‌ای منجر می‌شود.
چالش دیگر استفاده از ماشین حالت این است که وقتی مسئله بزرگ می‌شود، کار کردن با دستیارهای مبتنی بر قوانین خیلی دشوار است، چراکه مدیریت کردن، نگهداری و دیباگ کردن مجموعۀ عظیمی از قوانین خیلی دشوار است و با گذشت زمان دشوارتر می‌شود؛
به همین دلیل، رسا رویکرد کاملاً متفاوتی برای مدیریت دیالوگ انتخاب کرده است.
رسا به‌جای ایجاد قوانین و تحمیل کردن آنها به کاربران، از یادگیری ماشین استفاده می‌کند تا از روی دادههای مکالمه‌ای نمونه، الگوهای مکالمه‌ای را یاد بگیرد و پیش‌بینی کند که در هر وضعیت بخصوص، باتوجه‌به زمینه و تاریخچۀ مکالمه و جزئیات دیگر، دستیار چطور باید پاسخ دهد.
مؤلفه‌ای که در رسا مسئولیت مدیریت دیالوگ را به عهده دارد Core نامیده می‌شود.
در توسعۀ دستیار هوش مصنوعی مکالمه‌ای با استفاده از رسا، همه‌چیز از دادههای تعلیم شروع می‌شود. در مدیریت دیالوگ، این داده‌ها، stories نامیده می‌شود: مکالمه‌ای مثالی بین کاربر و دستیار که در قالبی خاص نوشته شده است.
این فرمت بسیار ساده است. ورودی‌های کاربر در قالب اینتنت و انتیتی‌های متناظر بیان می‌شود، درحالی‌که پاسخ‌های دستیار در قالب action nameها بیان می‌شود.
در کل، دو نوع action وجود دارد که در رسا می‌توانید از آنها استفاده کنید: Utterances و Custom Actions.
در رسا، Utteranceها پیام‌های hardcodeشده‌ای هستند که بازو/ دستیار می‌تواند با کمک آنها به کاربر پاسخ بدهد.
از طرف دیگر، custom actions می‌تواند دربردارندۀ مجموعه‌ای کد شخصی باشد که قابلیت اجرا شدن دارد.
تعلیم ماژول مدیریت دیالوگ هم مثل تعلیم ماژول NLU به مجموعۀ متنوعی از نمونه‌های تعلیم نیاز دارد، به همین دلیل است که stories در دادههای تعلیم شما باید انواع تغییر جهت‌های دیالوگ را پوشش دهد.
درحالی‌که قانون مشخصی وجود ندارد که برای تعلیم ماژول مدیریت دیالوگ و ساخت یک مدل خوب به چه تعداد نمونۀ تعلیم نیاز دارید، یک نکتۀ مهم که باید به خاطر بسپارید این است که دستیار شما باید در کوتاه‌ترین زمان ممکن، شروع به یاد گرفتن از کاربران واقعی کند.
توصیه می‌شود ابتدا روی ساخت نوعی برنامۀ کاربردی ساده تمرکز کنید، برنامه‌ای کاربردی که بتواند مسیر موردانتظار و شاید هم برخی انحراف‌ها از مسیر موردانتظار را به‌خوبی مدیریت کند و دستیار شما را در کوتاه‌ترین زمان ممکن در دسترس کاربران قرار دهد، چراکه مکالمه‌هایی که با کاربران واقعی اتفاق می‌افتد، بهترین دادۀ تعلیمی است.
یک جزء بسیار مهم دیگر در ساخت مدل مدیریت دیالوگ دامنه است.
دامنه جهانی را تعریف می‌کند که دستیار در آن جهان کار می‌کند. دستیار می‌تواند چه اینتنت و انتیتی‌هایی را بفهمد؟ دستیار باید آماده باشد تا به چه custom actionها و utteranceهایی پاسخ بدهد؟ آن utteranceها چطور به نظر می‌رسند؟ دستیار باید در طول مکالمه، چه اطلاعاتی را به خاطر بسپارد و در هر زمینۀ بخصوص به کار بگیرد؟
شکل ۴ اجزای تشکیل‌دهندۀ دامنه را نشان می‌دهد.
فایل دامنه سه جزء اصلی دارد که برای ساخت هر دستیاری با استفاده از پلتفرم رسا ضروری هستند:
جزئیات این بخش باید از مدل NLU بیاید.
نکته: انتیتی‌ها هم باید در فایل domain آورده شوند.
فهرست همۀ utteranceها و custom actionهایی که دستیار باید از آنها استفاده کند تا به کاربر پاسخ بدهد.
اینجا جایی است که می‌توانید پاسخ‌های حقیقی‌ای را تعریف کنید که دستیار، وقتی که یک utterance بخصوص پیش‌بینی شده است، باید ارائه کند.
مشخص کردن پاسخ‌ها از دو طریق اضافه کردن قالب‌های پاسخ به فایل دامنه یا از طریق custom actionها انجام می‌شود.
ممکن است هر utterance بیش از یک قالب داشته باشد و پاسخ ممکن است از پاسخ‌های سادۀ متنی فراتر برود (استفاده از تصاویر، دکمه‌ها و...).
بخش دیگری که در فایل domain وجود دارد و برای مدیریت دیالوگ با رسا خیلی مهم است بخش slots است.
در رسا، Slotها حافظۀ دستیار شما هستند و دستیار شما را قادر می‌سازند که جزئیات مهم را به خاطر بسپارد و زمانی که مکالمه به پیش می‌رود، از این slotها در زمینه‌ای بخصوص استفاده کند.
مقادیر slotها تا زمانی که ریست نشوند در حافظه نگهداری می‌شوند.
در این مجموعه مطالب، به معرفی انواع slotهایی که در رسا موجود است و کاربرد هرکدام نمی‌پردازیم.
در رسا، ماژول‌های مدیریت دیالوگ از طریق dialogue policies تعریف می‌شوند.
سیاست مؤلفه‌ای است که مسئول تصمیم‌گیری دربارۀ این مسئله است که دستیار در مرحلۀ بعدی باید چطور پاسخ دهد.
سیاست‌های تعلیم ممکن است به‌سادگیِ تقلید کردن مدل از مکالمه‌هایی باشد که با استفاده از آنها تعلیم دیده است یا الگوریتم‌های یادگیری ماشین کاملاً پیچیده‌ای باشد که قابلیت دارند اقدام بعدی را بر اساس بسیاری از جزئیات مثل سابقۀ مکالمه، زمینه و اطلاعات دیگر پیش‌بینی کنند.
پیکربندی سیاست شما ممکن است متشکل از چندین سیاست مختلف باشد؛ در این صورت، سیاست با بیشترین اطمینان از پیش‌بینی خود برنده می‌شود. اگر چندین سیاستْ اقدام بعدی را با امتیاز اطمینان یکسان پیش‌بینی کنند، سیاستی برنده می‌شود که policy priority بالاتری دارد.
در این مجموعه مطالب، به معرفی انواع هایپرپارامترهای سیاست و همچنین انواع سیاست‌هایی که در رسا موجود است و کاربرد هرکدام نمی‌پردازیم.
