ویرگول
ورودثبت نام
Mohammad Sadegh Heidari
Mohammad Sadegh Heidari
خواندن ۸ دقیقه·۳ سال پیش

انتخاب عاقلانه اتومیشن، هوش مصنوعی، ماشین لرنینگ یا انسان!

خیلی از ما (مخصوصا فعالان استارتاپی و پیگیران روند های تکنولوژی محور در دنیا) اخیرا علاقه زیادی به مفاهیم اتومیشن، هوش مصنوعی، ماشین لرنینگ و .. پیدا کرده ایم؛ مفاهیمی که هر چه پیچیده تر و مرموزترند ظاهرا جذاب ترند.
و مشکل از آنجایی شروع میشود که همه این مفاهیم باید در خدمت ایجاد راه حل سریعتر، کم هزینه تر و کم خطا تر باشند. اما گاهی دقیقا برعکس می‌شود.
آیا واقعا اتومیشن، هوش مصنوعی یا ماشین لرنینگ بهترین انتخاب برای حل مساله من است؟



بگذارید توضیح مختصری بدهم.
تقریبا دو سال پیش پروژه رادار361 که یک موتور جستجوی هتل، اقامتگاه و پرواز است را کلید زدیم. رادار361 در واقع به جمع آوری اطلاعات هتل،اقامتگاه و پرواز ها از وبسایت های فروشنده مختلف میپردازد و به کاربران امکان مشاهده ۱۰۰ درصد موجودی بازار و انتخاب ارزان ترین فروشنده را می‌دهد.( اگر فکر میکنید در وبسایت‌های رزرواسیون موجود جامعیت اطلاعات در میان است سخت در اشتباهید، به عنوان مثال وبسایت بزرگی مانند اسنپ تریپ کمتر از ۷۰ درصد هتل های ایران را نمایش و به شما امکان رزرو میدهد و برخی از فروشندگان بزرگ مانند علاالدین، هتلیار و .. کمتر از ۴۰ تا ۵۰ درصد هتل های موجود در ایران را پوشش می‌دهند. در بازار اقامتگاه ها هم بزرگترین فروشندگان مثل وبسایت شب، اتاقک و .. در خوشبینانه ترین شرایط کمتر از ۵ درصد گزینه های موجود در بازار را به شما نشان میدهند و ..!)
خب در ابتدای کلید زدن این پروژه با چالش های جدی در طراحی سیستم و یکپارچه سازی اطلاعات _برای بهبود تجربه کاربری در انتخاب بهترین گزینه و مناسب ترین قیمت برای کاربران از میان گزینه های متعدد_ و همچنین دسته بندی اطلاعات _برای شفافیت و بهینه سازی استفاده از اطلاعات در سیستم های مرتبط با هوش تجاری و تجاری سازی تحلیل داده ها مواجه بودیم.

رادار361 پس از هر بار جستجوی کاربران برای مشاهده پروازها و لیست قیمت فروشندگانشان، برای هر تاریخ بر اساس شماره پرواز لیست قیمت فروشندگان مختلف را مرتب سازی می‌کند اما مساله برای هتل بسیار پیچیده تر بود.

ما در گام اول باید اطلاعات هتل های مختلف را که شامل تصاویر، نظرات، امکانات، آدرس و .. بود همچنین قیمت و آپشن های مربوط به اتاق های مختلف هر هتل را از وبسایت های رزرواسیون مختلف جمع آوری می‌کردیم. پس جمع آوری اولیه ما با حدود ۸ هزار هتل و بیش از ۶۰ هزار اتاق مواجه بودیم که به نوعی بسیاری تکراری بودند. مثلا یک وبسایت "هتل عباسی اصفهان" و یکی دیگر "مهمانسرای عباسی اصفهان" و دیگری "مهمانسرای شاه عباس اصفهان" را به کاربرانشان نشان میدادند!

هتل عباسی اصفهان در وبسایت اقامت 24
هتل عباسی اصفهان در وبسایت اقامت 24
نام هتل عباسی در وبسایت رسمی هتل
نام هتل عباسی در وبسایت رسمی هتل

یا یکی "اتاق دوتخته دابل" و دیگری "اتاق ۲ نفره چسبیده به هم" را به کاربران جهت رزرو نمایش میدادند! اما در واقع همه این موارد تکراری یکی بودند! برای کاربر و ما، لیستی از هتل های غیر تکراری و نوع اتاق های هر یک که برای هر اتاق لیست قیمت و آپشن های فروشندگان مختلف موجود باشد، مطلوب ترین حالت برای مقایسه یکجا و انتخاب راحت تر بود.

در واقع اتاق ها در فروشندگان مختلف باید به یک گروه اتاق با لیستی از قیمت فروشندگان مختلفش تبدیل می‌شد.

نمایی از گروه بندی اتاق ها در وبسایت رادار۳۶۱
نمایی از گروه بندی اتاق ها در وبسایت رادار۳۶۱


بنابراین عملیاتی تحت عنوان "نظیرسازی" یا همان Mapping را در سیستم تعریف کردیم. اما مساله اصلی این بود که این تعداد اتاق و هتل را چگونه باید نظیر کرد؟
راهکار اولیه ما همان غایت آمال عارفان(!) و محبوب دل همه ما مشتاقان تکنولوژی بود! یعنی اتوماتیک سازی فرآیند!
بنابراین شروع به طراحی الگوریتمی کردیم که بتواند اتوماتیک گزینه ها را یکی کند. برای اینکار از مشابهت رشته ها کمک گرفتیم، و موارد با درصد بالا را به صورت اکسلی دو به دو خروجی گرفتیم، در این مدل نام هتل و .. حذف میشدند و بقیه رشته مشابهت داده میشد. اکسل نهایی توسط اوپراتور اصلاح شده و به تیم فنی برگردانده میشد. تا اینجای کار فرآیند بسیار خوب پیش رفت، به کمک خودکارسازی فنی فرآیند نزدیک 8 هزار هتل را به گزینه های بسیار نزدیک هم تقسیم کرده و با مروری توسط اوپراتور، سریعا موارد یکسان را در سیستم جستجو و یکی میکردیم. پس از تایید نظیرسازی هم با زدن یک دکمه فعالسازی، مثلا اطلاعات "کاروانسرای عباسی اصفهان" از یک وبسایت را با "هتل عباسی اصفهان" که از یک وبسایت دیگر بود یکی کرده و در یک صفحه به کاربر نشان میدادیم.
تجربه موفق اول، ما را به سمت تجربه ناموفق و اشتباه بعدی سوق داد! یعنی نظیرسازی هوشمند اتاق ها !

نام اتاق ها شامل عدد و حروف (مثلا اتاق دو تخته و ۲ تخته) ، بر خلاف نام هتل ها شامل نام فارسی و فینگیلیش انگلیسی (مثلا اتاق دوتخته دابل و دوتخته چسبیده به هم) و آپشن هایی که در توضیحات باید میامدند اما وبسایت های مختلف به علت نداشتن فیلد مستقل آپشن برای آن اتاق، توضیحات را در تایتل آورده بودند (مثلا اتاق دوتخته بدون پنجره اقامت ۶ ساعته همراه با صبحانه نهار شام!) بودند. تعداد گزینه ها برای بررسی ۲ به ۲ زیاد بود و جایگشت خطی اکسل به سبک نمونه قبلی حتی به صورت رندوم برای ما قابل ارزیابی نبود، چرا که بیش از ۶۰ هزار اتاق چگونه باید رندوم و با دقت نسبتا خوب ۲ به ۲ بررسی میشدند؟ همچنین برای ما شیوه مقایسه و رفتار کاربر جهت بهینه سازی نظیرسازی اتاق ها مهم بود، مثلا برای کاربر تفاوت لیست قیمت اتاق دوتخته و اتاق دوتخته اقامت کوتاه مدت مهم است، چرا که برای کاربری که به دنبال رزرو یک شب کامل میگردد، ترکیب لیست قیمتی با دو گزینه فوق، رضایت بخش نیست. نتیجه آن که فرآیند موجود برای بهینه سازی مدل اتوماتیک نظیرسازی اتاق ها، تقریبا دو هفته زمان خالص از تیم گران(!) فنی و تقریبا ۲ ماه زمان غیر منسجم از تیم فنی و محصول گرفت و در نهایت پروژه با شکستی به علل فوق (گزینه های متنوع، استثنائات زیاد و اهمیت رفتار و خواست کاربر واقعی برای انتخاب بهترین ها، استفاده از فارسی و فینگیلیس و عدد و پسوند و پیشوند های زیاد و متنوع به صورت همزمان) مواجه شد.
مشکل دیگر در این مسیر آن بود که ارزیابی هر روزه تصمیم سیستم یا آپدیت های اتفاقی و کاهش خطاهای دیده نشده در الگوریتم قبلی، با آمدن آپدیت اتاق های جدید یا اضافه شدن وبسایت های جدید به پوشش موتور جستجوی ما، ممکن بود الگوریتم فوق را دچار استثنائات جدید و هزینه های جدید برای بهینه سازی الگوریتم کند.

تصمیم مشخص بود، ما به سمت نظیرسازی دستی رفتیم! برای این کار لیست اتاق های هتل های مختلف را دقیقا با همان شیوه ای که کاربر در وبسایت ما می‌بیند در پنل مدیریت برای اوپراتور های خودمان پیاده سازی کردیم (تا تقریبا به رفتار و خواست کاربر واقعی برای انتخاب بهترین ها دستیابیم) همچنین برای بهبود سرعت نظیرسازی توسط کاربران تعدادی فیلتر مربوط به پارامتر هایی که مشابهت و تفاوت ها را نمایان تر میکردند شانل ظرفیت اتاق ها، تامین کنندگان و .. گذاشتیم و راهی آسان مثل درگ و دراپ برای اصلاح هر انچه اوپراتور میبیند قراردادیم. همچنین فیلد فعال بودن اتاق و تایید اتاق را به هر اتاق اضافه کردیم تا در صورتی که اتاق جدیدی اضافه شد غیرفعال باشد و در صورتی که اتاق جدید توسط اوپراتور نظیر نشده بود به صورتی گویا رنگ اتاق و گروه هتلی که داری اتاق های تایید نشده است تغییر کند تا در یک نگاه اوپراتور به اتاق تایید نشده هدایت شود.

در نهایت برای ارزیابی و رفع خطاها، انتظارمان از خروجی ابن نظیرسازی اطلاعات را که تعدد فروشندگان برای یک گروه اتاق، تلورانس کم قیمت فروشندگان مختلف داخل یک گروه اتاق و .. بود را به داشبوردی تبدیل کردیم که اشتباهات اوپراتوهای ما رو پس از نظیرسازی اشتباه نمایان تر می‌کرد.

حاصل، کیفیتی بسیار بالاتر، هزینه ای بسیار پایین تر (نزدیک ۳ هفته کار با هزینه از تیم غیر فنی و ارزان تر) و سرعت کلی بیشتر، و انعظاف برای تغییرات آتی و تصمیمات لحظه ای ما با توجه به بررسی رفتار کاربران بود. این مساله دیگر نیاز به تغییر الگوریتم ها، تغییر کدها و صبر کردن برای اعمال روی سیستم و بررسی هر باره باگ ها نداشت. به طوری که با افزوده شدن ۲ وبسایت فروشنده دیگر ظرف مدت یک هفته به کمک یک اوپراتور همه اطلاعات جدید با هدایت سیستم و کمک سیستم به اوپراتور نظیرسازی شد.

نتیجه آنکه: برای استفاده از اتومیشن، هوش مصنوعی یا ..،اولین قدم تعریف درست مساله ، پارامتر های موثر در حل مساله ، حجم داده مورد بحث، رویه حل گام به گام مساله، و در نهایت شیوه عیب یابی و مانیتور مسیر طی شده برای جبران خطاهای احتمالی است.

برای ما

تعریف مساله: نظیرسازی اتاق هایی که در وبسایت های رزرواسیون مختلف قیمت متفاوتی دارند و نام آن ها دارای پارامترهای عددی و فارسی و انگلیسی و آپشن ها و ..

پارامترهای موثر در حل مساله: نام اتاق ها، ظرفیت(عدد)، فیلد مستقل آپشن اتاق در صورت وجود، قیمت رزرو اتاق در یک روز مشخص، فروشنده

حجم داده های مورد بحث:

۶۰ هزار اتاق که با تقسیم در ۲ هزار هتل موجود به طور میانگین ۳۰ اتاق در هر هتل وجود دارد. بنابراین یک اوپراتور میتواند ۳۰ داده را با تفکیک هایی تشخیص و تقسیم بندی کند. (اگر این داده ها ۶۰ هزار داده یکجا بود چنین اتفاقی ممکن نبود)

رویه حل گام به گام مساله: نمایش اتاق ها به صورت گروه هایی در ابتدا شامل یک اتاق که امکان جا به جایی اتاق از گروهی به گروه دیگر وجود داشته باشد، همچنین نشان گذاری اتاق های نظیرسازی نشده و نشان گذاری تایید یا عدم تایید اوپراتور برای آنکه بتواند اوپراتور در یک نگاه موارد نظیرسازی نشده یا مورد شک را در یک نگاه ببیند. و در نهایت ایجاد لیستی از هتل ها که اتاق های نظیرسازی نشده دارند به این جهت که اوپراتور با مشاهده تنها هتل های دارای اتاق نظیرسازی نشده، سریعا به مقصود برسد.

در نهایت شیوه عیب یابی: ایجاد داشبوردی جهت مانیتور گروه های اتاق با تلورانس های خیلی زیاد در لیست قیمت آن ها(به عنوان مثال تلورانس ارزان ترین فروشنده و گران ترین فروشنده اگر ۲۰۰ درصد باشد یک احتمال جدی نظیرسازی اشتباه یک اتاق ۱ تخته با ۲ تخته است) که به پیدا کردن مشکلات واضح فرآیند ما کمک می‌کند.

نکته پایانی:

رادار۳۶۱ ، سرویس نظیرسازی اطلاعات را برای وبسایت های رزرواسیون که به دنبال اطلاعات استاندارد هتل های ایران و اتاق های آن ها برای راه اندازی وبسایت های جدید یا اتصال به تامین کنندگان دیگر هستند به سرویس گیرندگان ارائه می‌دهد. این سرویس یعنی نظیرسازی یا مپینگ در ابعاد جهانی توسط سرویس دهندگانی مثل GIATA ارائه می‌گردد. طبیعتا سرویس گیاتا از هوش مصنوعی برای نظیرسازی اطلاعات میلیون ها هتل و اتاق استفاده می‌کند. در واقع وقتی تعداد داده ها تغییر می‌کند صرفه پیاده سازی روال های هوش مصنوعی نسبت به اوپراتور انسانی هم تغییر می‌کند.

امیدوارم این تجربه بتواند کمکی در انتخاب بهتر شما داشته باشد ..

ابر دادهbig dataautomationماشین لرنینگartificial intelligence
مدیرمحصول رادار۳۶۱ | تحلیلگر ارشد کسب و کار مستربلیط | فارغ التحصیل مکانیک امیرکبیر و MBA علامه طباطبایی
شاید از این پست‌ها خوشتان بیاید