سوالات معماری که بهترین عاملان هوش مصنوعی را برای هتلها و مهماننوازی از رباتهای گفتگوی پایلوت که هرگز به تولید نمیرسند، جدا میکند
سوالات معماری که عوامل هوش مصنوعی برتر را برای هتلها و مهماننوازی از رباتهای گفتگوی پایلوت که بیصدا شکست میخورند، متمایز میکند.
فعالان مهماننوازی که یک یا دو پایلوت عامل هوش مصنوعی را تجربه کردهاند، درس دشواری آموختهاند که از نمایشهای اولیه واضح نبود. کیفیت مکالمه یک عامل در محیط آزمایشی تقریباً هیچ چیزی در مورد اینکه آیا آن عامل به مرحله تولید خواهد رسید یا خیر، به شما نمیگوید. سیستمهای تولیدی که ترافیک واقعی مهمانان و عملیات ذخیرهسازی در سیستمهای مدیریت ملک را مدیریت میکنند، دارای ویژگیهای معماری مشترکی هستند که رباتهای گفتگوی پایلوت فاقد آنها هستند. بهترین عوامل هوش مصنوعی برای هتلها و مهماننوازی آنهایی نیستند که به خوبی نمایش داده میشوند. آنها آنهایی هستند که از سوالات معماری جان سالم به در میبرند و اپراتورها تنها پس از مرگ بیصدای یک پایلوت، یاد میگیرند که این سوالات را بپرسند.
این متدولوژی، سوالات معماری را بررسی میکند که عوامل تولیدی را از پایلوتها جدا میسازد. این سوالات به ترتیبی سازماندهی شدهاند که یک اپراتور هنگام ارزیابی هر فروشنده یا هر پیشنهاد ساخت داخلی باید آنها را بپرسد. اپراتورهایی که این سوالات را قبل از امضای قرارداد یا شروع یک پروژه میپرسند، از گرانترین حالتهای شکست در استقرارهای هوش مصنوعی اتوماسیون مهماننوازی جلوگیری میکنند، و اپراتورهایی که از آنها صرفنظر میکنند، معمولاً درسها را به روش دشوار، از طریق پایلوتهایی که بودجه مصرف میکنند و چیزی به مرحله تولید نمیرسانند، میآموزند.
نحوه مدیریت وضعیت عامل در مکالمات و کانالها
اولین سوال معماری مربوط به وضعیت است. مهمانی که ساعت ۲ بعد از ظهر در مورد ورود زودهنگام با ملک پیام میفرستد، ساعت ۴ بعد از ظهر با پذیرش تماس میگیرد تا پیگیری کند، و ساعت ۵ بعد از ظهر وارد لابی میشود، انتظار دارد مکالمه ادامه پیدا کند نه اینکه از نو آغاز شود. عاملانی که نمیتوانند وضعیت را در کانالها و در طول زمان حفظ کنند، تقریباً بلافاصله در این آزمون شکست میخورند، و حالت شکست به گونهای برای مهمان قابل مشاهده است که به تجربه برند آسیب میزند.
مدیریت وضعیت در سطح معماری نیازمند یک زمینه مهمان پایدار است که توسط هر تعامل در هر کانال بهروز رسانی میشود و در آغاز هر تعامل جدید توسط عامل قابل پرسوجو است. لایه پایداری باید از راهاندازی مجدد فرآیندها، ارتقاء مدلها و قطعیهای یکپارچهسازی جان سالم به در ببرد. رابط پرسوجو باید به اندازهای سریع باشد که عامل بتواند زمینه مرتبط را بدون ایجاد تأخیر قابل درک بازیابی کند. منطق بهروزرسانی باید تضادها را به آرامی مدیریت کند، زمانی که چندین کانال همزمان در حال نوشتن در یک زمینه مهمان هستند.
رباتهای گفتگوی پایلوت معمولاً وضعیت را در یک مکالمه واحد با انتقال متن در اعلان مدیریت میکنند، که برای تعاملات کوتاه کار میکند و برای هر سفر مهمانی که بیش از چند نوبت طول میکشد، شکست میخورد. عاملان در سطح تولید، وضعیت را به یک ذخیرهسازی پایدار خارجی میکنند که به عنوان بخشی از معماری در نظر گرفته میشود و نه یک فکره پسین. اپراتورها هنگام ارزیابی یک عامل باید قبل از پذیرش هر ادعایی در مورد پیوستگی بین کانالها، درخواست مشاهده طرح وضعیت، لایه پایداری و منطق حل تضاد را داشته باشند.
چه اتفاقی میافتد زمانی که سیستم مدیریت املاک در دسترس نیست
سوال دوم معماری مربوط به اتفاقاتی است که در طول قطعیهای سیستم مدیریت املاک (PMS) رخ میدهد. سیستمهای مدیریت املاک هتلها برای پنجرههای نگهداری، قطعیهای غیرمنتظره و رویدادهای مهاجرت آفلاین میشوند. عاملانی که برای هر عملیات به تماسهای همزمان با سیستم مدیریت املاک وابسته هستند، در طول این پنجرهها شکست میخورند و حالت شکست در بدترین لحظات ممکن برای مهمانان قابل مشاهده است.
عاملان در سطح تولید، الگوی تابآوری را پیادهسازی میکنند که امکان ادامه عملیات را در طول قطعیهای سیستم مدیریت املاک فراهم میآورد، با کاهش آرام قابلیتهایی که به دادههای PMS زمان واقعی وابسته هستند و عملیات ذخیرهسازی در صف که هنگام بازگشت PMS به دسترسپذیری اجرا میشوند. صف باید پایدار باشد، عملیات ذخیرهسازی باید غیرقابل برگشت (idempotent) باشد، و منطق تطبیق باید تضادهایی را که هنگام صفبندی چندین عملیات علیه یک رزرو در طول یک قطعی طولانیمدت ایجاد میشوند، مدیریت کند.
سیستمهای پایلوت معمولاً هیچ مفهومی از مدیریت قطعی PMS ندارند زیرا دموها در یک محیط آزمایشی پایدار اجرا میشوند. اپراتورها هنگام ارزیابی یک عامل باید از فروشنده بخواهند رفتاری را در طول یک قطعی شبیهسازیشده PMS نشان دهد، با توجه ویژه به نحوه مدیریت عملیات صفبندی شده، نحوه تطبیق ارتباطات با مهمانان و نحوه بازیابی عامل پس از برگشت سیستم PMS به حالت آنلاین.
نحوه طراحی مدیریت استثنا در سه لایه
سومین سؤال معماری مربوط به مدیریت استثنا است. عملیات مهماننوازی جریان پیوستهای از استثناها را تولید میکند که یک عامل باید آنها را مدیریت کند، از رزروهای بیش از حد و اختلافات نرخ تا نگهداری VIP و اختلالات بلوک گروهی. عاملانی که سعی در مدیریت هر استثنا در خود مدل دارند، شکست میخورند زیرا مدلهای زبانی برای منطق قطعی استثنا طراحی نشدهاند، و عاملانی که هر استثنا را به یک انسان واگذار میکنند، شکست میخورند زیرا هزینه انسانی تزش اتوماسیون را از بین میبرد.
عاملان در سطح تولید، یک معماری سه لایه برای مدیریت استثناها اجرا میکنند که بار کاری را بین حل خودکار، حل با نظارت و ارجاع انسانی توزیع میکند. لایه حل خودکار، استثناهای روتین را از طریق قوانین قطعی که عامل بدون دخالت مدل در تصمیمگیری فراخوانی میکند، مدیریت میکند. لایه حل با نظارت، استثناهایی را مدیریت میکند که نیاز به قضاوت دارند اما از الگوهای اثباتشده پیروی میکنند، با مدل که راهحلی را پیشنهاد میکند و یک انسان آن را تأیید یا اصلاح میکند. لایه ارجاع انسانی، استثناهای جدیدی را مدیریت میکند که از ابتدا نیاز به قضاوت انسانی دارند، با عامل که زمینه و توصیهها را ارائه میدهد و تصمیم نمیگیرد.
سیستمهای پایلوت معمولاً یک لایه واحد دارند که هر چیزی را که یک سوال ساده نیست، ارجاع میدهد. نرخ ارجاع به واقعیت عملیاتی غالب تبدیل میشود، زمانی که پایلوت از محیط آزمایشی به تولید میرود، و هزینه انسانی مدیریت ارجاعات، روایت صرفهجویی را که استقرار را توجیه میکرد، از بین میبرد. اپراتورها هنگام ارزیابی یک عامل باید طبقهبندی استثنا، منطق مسیریابی و نرخ ارجاع را که در استقرارهای تولیدی اندازهگیری شده است، و نه در محیطهای پایلوت، درخواست کنند.
آیا منطق یکپارچهسازی در داخل یا خارج از عامل قرار دارد
سوال چهارم معماری مربوط به محل قرارگیری منطق یکپارچهسازی است. عاملانی که منطق یکپارچهسازی را درون اعلان مدل قرار میدهند، در ابتدا ساخت آنها آسانتر است و با رشد سطح یکپارچهسازی، نگهداری آنها غیرممکن میشود. عاملانی که منطق یکپارچهسازی را به یک لایه سرویس خارجی میکنند که مدل از طریق رابطهای تعریف شده به آن فرا میخواند، در ابتدا ساخت آنها دشوارتر است و با تکامل مدل عملیاتی، قابل نگهداری باقی میمانند.
تمایز معماری اهمیت دارد زیرا سطوح یکپارچهسازی مهماننوازی بزرگ و همیشه در حال تکامل هستند. مهاجرت یک سیستم مدیریت املاک، تغییر یک مدیر کانال، یا ارتقاء یک پلتفرم وفاداری نباید نیاز به بازسازی عامل را داشته باشد. اگر منطق یکپارچهسازی درون اعلان قرار گیرد، هر تغییر زیرساختی به یک پروژه مهندسی اعلان تبدیل میشود. اگر منطق یکپارچهسازی در یک لایه سرویس قرار گیرد، تغییرات زیرساختی به لایه سرویس محدود میشوند و عامل بدون تغییر در برابر یکپارچهسازی جدید به کار خود ادامه میدهد.
سیستمهای پایلوت غالباً منطق یکپارچهسازی را در اعلان جای میدهند زیرا معماری سادهتر به نظر میرسد و موارد استفاده اولیه، بار نگهداری را تحت فشار قرار نمیدهند. اپراتورها هنگام ارزیابی یک عامل باید درخواست مشاهده نمودار معماری یکپارچهسازی را داشته باشند و بهطور خاص بپرسند که عامل چگونه با مهاجرت سیستم مدیریت املاک سازگار میشود. فروشندگانی که پاسخ میدهند این مهاجرت نیازی به تغییر عامل ندارد، معماری در سطح تولید را نشان میدهند. فروشندگانی که بازسازی قابل توجهی را توصیف میکنند، معماری در سطح پایلوت را آشکار میسازند.
چگونه عامل تصمیم میگیرد کدام مدل را برای کدام وظیفه فراخوانی کند
سوال پنجم معماری مربوط به مسیریابی مدل است. عاملان مهماننوازی در سطح تولید، هر تعامل را از طریق تواناترین مدل اجرا نمیکنند. آنها وظایف مختلف را بر اساس هزینه، تأخیر و الزامات قابلیت به مدلهای مختلف هدایت میکنند و مدل گرانتر را تنها زمانی استفاده میکنند که وظیفه واقعاً به آن نیاز داشته باشد.
یک تعامل پیامرسانی مهمان که شامل جستجوی رزرو و پاسخ به سوالی در مورد امکانات هتل است، میتواند با هزینه کم بر روی یک مدل کوچک و سریع اجرا شود. تصمیم مدیریت درآمد که شامل تجزیه و تحلیل نرخهای رقابتی، پیشبینی اشغال و ریسک بلوک گروهی است، باید بر روی یک مدل تواناتر اجرا شود زیرا کیفیت تصمیمگیری مهم است و حجم آن بسیار کمتر است. منطق مسیریابی که وظایف را بین مدلها توزیع میکند، یک بخش مهم از معماری است که سیستمهای تولیدی را از نمونههای اولیه جدا میکند.
سیستمهای پایلوت معمولاً همه چیز را روی یک مدل اجرا میکنند زیرا معماری سادهتر است و پیامدهای هزینه هنوز مشخص نیست. اپراتورها هنگام ارزیابی یک عامل باید درباره منطق مسیریابی مدل بپرسند و به طور خاص بپرسند که چند درصد از تعاملات بر روی هر سطح از مدل اجرا میشود. فروشندگانی که به مسیریابی مدل فکر نکردهاند، نشان میدهند که سیستم خود را در مقیاس بزرگ اجرا نکردهاند.
مسیر حسابرسی چه چیزی را ثبت میکند و چگونه جستجو میشود
سوال ششم معماری مربوط به مسیر حسابرسی است. عاملان مهماننوازی که با رزروها، پرداختها و اطلاعات مهمانان سروکار دارند، باید یک مسیر حسابرسی تولید کنند که الزامات کنترل داخلی، الزامات استاندارد برند و الزامات نظارتی را برآورده کند. مسیر حسابرسی باید ثبت کند که عامل چه کاری انجام داده است، چرا انجام داده است، به کدام دادهها دسترسی داشته است و چه چیزی را در سیستمهای پاییندستی تغییر داده است.
مسیرهای حسابرسی در سطح تولید، کل تاریخچه تعامل، منطق عامل در هر نقطه تصمیمگیری، دادههای دسترسی یافته و تغییر یافته، و فراخوانیهای یکپارچهسازی انجام شده به سیستمهای خارجی را ثبت میکنند. دادههای حسابرسی به گونهای قابل پرسوجو هستند که به اپراتورها اجازه میدهد حوادث خاص را بررسی کنند، الگوها را در حوادث شناسایی کنند و درخواستهای حسابرسان را بدون بازسازی دستی برآورده سازند.
سیستمهای پایلوت معمولاً رونوشتهای مکالمه را ثبت میکنند و چیز دیگری نه. حسابرسی که میپرسد چرا یک تغییر نرخ خاص انجام شده است یا چرا یک پروفایل مهمان خاص بهروزرسانی شده است، متوجه میشود که سیستم نمیتواند به این سوال پاسخ دهد. اپراتورها هنگام ارزیابی یک عامل باید نمونهای از مسیر حسابرسی را برای یک تعامل پیچیده چند مرحلهای مشاهده کنند و به طور خاص بپرسند که دادههای حسابرسی چگونه از گردش کارهای تحقیقاتی پشتیبانی میکنند.
نحوه مدیریت اطلاعات قابل شناسایی شخصی و دادههای پرداخت توسط عامل
سوال هفتم معماری مربوط به نحوه مدیریت دادههای حساس است. عوامل مهماننوازی ناگزیر به اطلاعات قابل شناسایی شخصی (PII) و دادههای پرداخت دسترسی دارند، و تصمیمات معماری پیرامون نحوه جریان این دادهها از طریق عامل، تعیین میکند که آیا اپراتور میتواند سیستم را در مرحله تولید مستقر کند بدون اینکه مقررات حفاظت از دادهها یا استانداردهای امنیتی صنعت پرداخت را نقض کند.
عاملان در سطح تولید، حداقلسازی دادهها را در سطح معماری پیادهسازی میکنند، با دادههای حساس که قبل از ورود به زمینه مدل، توکنسازی یا ماسک میشوند و با تفکیک واضح بین لایه استدلال عامل و سیستمهای رکورد که دادههای حساس واقعی را نگه میدارند. مدل هرگز اطلاعات پرداخت خام، اطلاعات گذرنامه خام یا اطلاعات قابل شناسایی شخصی خام را نمیبیند، مگر در شرایط محدود و با ثبت صریح.
سیستمهای پایلوت غالباً دادههای حساس را از طریق اعلان مدل منتقل میکنند زیرا معماری سادهتر است و پیامدهای نظارتی هنوز مشخص نیست. اپراتورها هنگام ارزیابی یک عامل باید نمودار جریان دادهها را درخواست کنند، به طور خاص بپرسند که چه دادههای حساسی وارد زمینه مدل میشوند، و شواهدی را که معماری استانداردهای امنیتی صنعت پرداخت و مقررات حفاظت از دادههای قابل اجرا را برآورده میکند، مطالبه کنند.
آیا عامل بدون توقف قابل بهروزرسانی است
سوال هشتم معماری مربوط به مکانیزمهای استقرار و بهروزرسانی است. عاملان مهماننوازی به طور مداوم در حال اجرا هستند، و بهروزرسانیهایی که نیاز به توقف عملیات دارند، اختلالاتی را برای مهمانان ایجاد میکنند که اپراتور نمیتواند آن را بپذیرد. معماری باید از استقرار بهروزرسانیهای عامل بدون آفلاین کردن سیستم پشتیبانی کند، با برگشتپذیری ایمن در صورتی که استقرار، رفتار غیرمنتظرهای را معرفی کند.
سیستمهای در سطح تولید، الگوهای استقراری را پیادهسازی میکنند که به نسخههای جدید عامل اجازه میدهد در کنار نسخههای موجود اجرا شوند، با ترافیک که به تدریج به نسخه جدید هدایت میشود و با قابلیت برگشت فوری در صورت کاهش معیارهای کیفیت. زیرساخت استقرار به عنوان بخشی از معماری عامل در نظر گرفته میشود و نه یک فکره پسین عملیاتی، و اپراتورها میتوانند بهروزرسانیهای عامل را با همان اطمینانی که از هر سیستم تولیدی دیگری انتظار دارند، منتشر کنند.
سیستمهای پایلوت معمولاً با خاموش کردن نسخه موجود و راهاندازی یک نسخه جدید مستقر میشوند، که برای محیطهای آزمایشی قابل قبول است و برای تولید غیرقابل قبول. اپراتورها هنگام ارزیابی یک عامل باید در مورد معماری استقرار بپرسند و به طور خاص بپرسند که یک بهروزرسانی چگونه منتشر میشود و یک مشکل چگونه برگردانده میشود.
عامل چگونه رفتار میکند زمانی که مدل زیربنایی آپدیت میشود
سوال نهم معماری مربوط به رفتار ارتقاء مدل است. مدلهای زبانی زیربنایی که عاملان مهماننوازی را پشتیبانی میکنند، به طور مکرر توسط ارائهدهندگان مدل بهروزرسانی میشوند، و این بهروزرسانیها میتوانند رفتار عامل را به طرق ظریف و گاهی چشمگیر تغییر دهند. عاملان در سطح تولید شامل یک چارچوب تست رگرسیون هستند که تغییرات رفتاری را قبل از رسیدن به مهمانان شناسایی میکند، و عاملان در سطح پایلوت معمولاً تغییرات را زمانی کشف میکنند که مهمانان شکایت میکنند.
چارچوب تست رگرسیون باید شامل مجموعهای نماینده از تعاملات باشد که عامل باید بهدرستی آنها را مدیریت کند، به همراه مقایسه خودکار رفتار عامل در نسخههای مدل. این چارچوب باید قبل از استقرار هر بهروزرسانی مدل در مرحله تولید، اجرا شود، و مقایسه باید هرگونه تغییر رفتاری را برای بررسی انسانی علامتگذاری کند.
اپراتورها هنگام ارزیابی یک عامل باید بپرسند که آیا فروشنده یک چارچوب تست رگرسیون را نگهداری میکند و باید درخواست مشاهده مجموعه تست را داشته باشند. فروشندگانی که مجموعه تست ندارند، سطحی از ریسک را به عهده میگیرند که استقرار در مرحله تولید نمیتواند آن را بپذیرد، و اپراتورهایی که بدون اصرار بر این محافظت، استقرار را انجام میدهند، خودشان آن ریسک را جذب میکنند.
چه چیزی را اپراتور میتواند بدون دخالت فروشنده تغییر دهد
سوال دهم معماری مربوط به کنترل اپراتور است. مدلهای عملیاتی مهماننوازی به طور مداوم در حال تغییر هستند و عامل باید با این تغییرات سازگار شود بدون اینکه به یک تعامل دائمی خدمات حرفهای تبدیل شود. معماری باید کنترل معنیداری بر رفتار عامل به اپراتور بدهد بدون اینکه برای تغییرات روتین نیاز به دخالت فروشنده باشد.
عاملان در سطح تولید، رابطهای پیکربندی را در معرض دید قرار میدهند که به اپراتورها امکان میدهد منطق مسیریابی، آستانههای ارجاع، الگوهای پاسخ و پارامترهای یکپارچهسازی را بدون نوشتن کد یا ثبت درخواستهای تغییر با فروشنده تغییر دهند. رابط پیکربندی خود یک قطعه معماری است که نیاز به طراحی دقیق دارد، و اپراتورهایی که اهمیت آن را دست کم میگیرند، در نهایت هزینه خدمات حرفهای فروشنده را برای تغییراتی که باید خودشان بتوانند انجام دهند، میپردازند.
سیستمهای پایلوت معمولاً برای هر تغییری فراتر از تنظیمات ظاهری، نیاز به دخالت فروشنده دارند. اپراتورها هنگام ارزیابی یک عامل باید بپرسند که چه چیزی را خودشان میتوانند تغییر دهند و به طور خاص درخواست مثالهایی از تغییراتی را داشته باشند که سایر اپراتورها از طریق رابط پیکربندی انجام دادهاند. پاسخ صادقانه، دامنه واقعی کنترل اپراتور را آشکار میکند.
چگونه معماری از پورتفولیوی چندملکی و چندبرندی پشتیبانی میکند
سوال یازدهم معماری مربوط به مقیاسپذیری پورتفولیو است. اپراتورهایی که چندین ملک یا چندین برند را اداره میکنند، به یک معماری نیاز دارند که در جاهایی که مناسب است از انسجام در سطح پورتفولیو و در جاهایی که مورد نیاز است از سفارشیسازی خاص ملک یا برند پشتیبانی کند. معماری باید بین پیکربندی که باید در سراسر پورتفولیو به ارث برده شود و پیکربندی که باید در سطح ملک یا برند سفارشی شود، تمایز قائل شود.
معماریهای پورتفولیوی در سطح تولید، یک مدل وراثت را پیادهسازی میکنند که به پیشفرضهای سطح پورتفولیو اجازه میدهد در سطح برند و در سطح ملک لغو شوند، با قوانین اولویتبندی واضح و قابلیت مشاهده پیکربندی مؤثر در هر سطح. رابط مدیریت به اپراتورهای پورتفولیو اجازه میدهد تغییراتی را ایجاد کنند که به طور مناسب منتشر شوند و به اپراتورهای ملک اجازه میدهد تغییراتی را ایجاد کنند که به ملک خود محدود بمانند.
سیستمهای پایلوت معمولاً مدل پورتفولیو ندارند و باید به طور مستقل در هر ملک مستقر شوند. اپراتورهایی که یک عامل را برای استقرار پورتفولیو ارزیابی میکنند باید در مورد مدل وراثت، اولویت پیکربندی و رابط مدیریتی که از مدیریت در سراسر پورتفولیو پشتیبانی میکند، سوال کنند.
آیا کل معماری مستند و قابل نگهداری است
دوازدهمین و آخرین سوال معماری مربوط به مستندسازی و قابلیت نگهداری است. عاملان در سطح تولید با جزئیاتی مستند شدهاند که به مهندسان جدید اجازه میدهد سیستم را بدون مشورت با سازندگان اصلی درک کنند، با نمودارهای معماری، مشخصات یکپارچهسازی، مراجع پیکربندی و راهنماهای عملیاتی که با تکامل سیستم بهروز نگه داشته میشوند.
اهمیت مستندات به این دلیل است که اپراتورهای مهماننوازی کارکنان مهندسی را تغییر میدهند، شرکای مشاوره را تغییر میدهند و گاهی نگهداری عامل را به صورت داخلی انجام میدهند. اپراتورهایی که به سیستمهای بدون مستندات وابسته هستند، گروگان سازندگان اصلی میشوند، و اپراتورهایی که بر مستندات در سطح تولید اصرار دارند، آزادی تغییر فروشنده یا انجام کار به صورت داخلی را در صورت لزوم حفظ میکنند.
سیستمهای پایلوت معمولاً با جزئیاتی مستند شدهاند که برای سازندگان اصلی کافی است تا سیستم را نگهداری کنند و برای هیچ کس دیگری کافی نیست. اپراتورها هنگام ارزیابی یک عامل باید درخواست مشاهده مستندات را داشته باشند و به طور خاص بپرسند که آیا مستندات به یک تیم مهندسی جدید اجازه میدهد نگهداری را بدون زمان قابل توجهی برای آشنایی با سیستم به عهده بگیرند. پاسخ صادقانه نشان میدهد که آیا سیستم برای تولید ساخته شده است یا برای نمونه اولیه.
جمعبندی دوازده سوال در یک چارچوب ارزیابی
دوازده سوال معماری بالا یک چارچوب ارزیابی منسجم را تشکیل میدهند که اپراتورها میتوانند برای تمایز استقرارهای عامل مهماننوازی در سطح تولید از پروژههای ربات گفتگوی در سطح پایلوت استفاده کنند. این چارچوب یک چک لیست نیست که فروشندگان آن را پاس یا رد کنند. این مجموعهای از سوالات است که پاسخهای صادقانه آنها، بلوغ واقعی معماری و احتمال واقعی رسیدن استقرار به مرحله تولید را نشان میدهد.
اپراتورهایی که هر دوازده سوال را قبل از امضای قرارداد یا شروع یک ساخت داخلی میپرسند، از پرهزینهترین حالتهای شکست در استقرارهای هوش مصنوعی مهماننوازی جلوگیری میکنند. این سوالات نقاط ضعف معماری را آشکار میکنند که دموها پنهان میکنند، پیشنهادهای فروشندگان مبهم میکنند و محیطهای پایلوت نمیتوانند آنها را تحت فشار قرار دهند. این سوالات همچنین مکالمات تدارکاتی را با واقعیت عملیاتی همسو میکنند، که همان شکافی است که اکثر پایلوتهای شکستخورده در آن قرار میگیرند.
بهترین عاملان هوش مصنوعی برای هتلها و مهماننوازی سیستمهایی هستند که به این دوازده سوال با محتوا و نه با زبان بازاریابی پاسخ میدهند. فروشندگانی که میتوانند طرح وضعیت، الگوی تابآوری، معماری مدیریت استثنا، لایه سرویس یکپارچهسازی، منطق مسیریابی مدل، مسیر حسابرسی، نمودار جریان داده، مکانیزمهای استقرار، مجموعه تست رگرسیون، رابط پیکربندی، مدل وراثت پورتفولیو و مستندات تولید را نشان دهند، در حال اثبات این هستند که یک سیستم تولیدی واقعی ساختهاند. فروشندگانی که از این سوالات طفره میروند، در حال آشکار ساختن این هستند که یک دمو ساختهاند.
اپراتورهایی که در حال ارزیابی عاملان هوش مصنوعی برای عملیات هتل، عاملان هوش مصنوعی خدمات مهمان، عاملان هوش مصنوعی برای پذیرش هتل، عاملان هوش مصنوعی مدیریت درآمد، عاملان هوش مصنوعی برای بخش اداری هتل، یا هر دسته دیگری از هوش مصنوعی اتوماسیون مهماننوازی هستند، باید دوازده سوال معماری را به عنوان معیارهای دروازه برای هر تصمیم تدارکات در نظر بگیرند. پایلوتهایی که در این سوالات شکست میخورند هرگز به تولید نمیرسند. پایلوتهایی که این سوالات را پاس میکنند، زیرساخت تولیدی میشوند که عملیات مهماننوازی را برای دهه آینده اجرا میکند.
کار معماری دشوارتر از کار دمو است، و مکالمات معماری کمتر از نمایشهای هوش مصنوعی مکالمهای هیجانانگیز هستند که فروشندگان ترجیح میدهند با آنها شروع کنند. اپراتورهایی که بر مکالمات معماری اصرار دارند، استقرارهای تولیدی را به دست میآورند که صرفهجویی، افزایش درآمد و بهبود تجربه مهمان را که وعدههای اولیه داده بودند، ارائه میدهند. اپراتورهایی که از مکالمات معماری صرفنظر میکنند، پایلوتهایی را به دست میآورند که بیصدا میمیرند و بودجههایی را که بیصدا ناپدید میشوند.
چرا دوازده سوال در طول چرخه عمر استقرار با هم ترکیب میشوند
دوازده سوال معماری به صورت جداگانه وجود ندارند. آنها در طول چرخه عمر استقرار به گونهای با هم ترکیب میشوند که اپراتورها معمولاً تنها پس از شکست یک پایلوت به دلیل ضعفهایی که به صورت همزمان به دو یا سه سوال برمیگردد، اهمیت آن را درک میکنند. شکستهای مدیریت وضعیت با شکستهای مدیریت استثنا تعامل دارند زیرا استثناهایی که چندین نوبت را در بر میگیرند به وضعیت نیاز دارند. شکستهای معماری یکپارچهسازی با شکستهای مسیریابی مدل تعامل دارند زیرا تصمیمات مسیریابی به پاسخهای یکپارچهسازی بستگی دارند. شکستهای مستندسازی هر شکست دیگری را تشدید میکنند زیرا مشکلات تشخیص داده نشده دائمی میشوند.
اثر ترکیبی به همین دلیل است که اپراتورهایی که دوازده سوال را به عنوان یک چک لیست تلقی میکنند، سوالاتی را که به صورت جداگانه کمتر فوری به نظر میرسند، کماهمیت جلوه میدهند. سوال مربوط به استقرار بدون توقف و سوال مربوط به پیکربندی قابل تغییر توسط اپراتور اغلب در طول تدارکات ثانویه به نظر میرسند و در طول اولین تغییر عمده مدل عملیاتی پس از راهاندازی، اولیه میشوند. اپراتورهایی که هر سوال را جدی میگیرند، در نهایت استقرارهایی را به دست میآورند که تغییرات مدل عملیاتی را به آرامی جذب میکنند. اپراتورهایی که از سوالات به ظاهر ثانویه صرفنظر میکنند، در نهایت استقرارهایی را به دست میآورند که برای هر تغییر نیاز به ارجاع به فروشنده دارند.
بنابراین، این چارچوب به اپراتورهایی پاداش میدهد که معماری را به عنوان یک پورتفولیو و نه یک لیست در نظر میگیرند. پیشنهاد فروشنده یا ساخت داخلی که در هر دوازده سوال نمره خوبی میگیرد، مستحق بررسی جدی است. فروشندهای که در هشت مورد نمره خوبی میگیرد و در چهار مورد ضعیف عمل میکند، نشان میدهد که استقرار در مرحله تولید در کدام نقاط شکست خواهد خورد، و شکستها دقیقاً در همان چهار حوزهای ظاهر میشوند که در طول ارزیابی نمره پایینی گرفتهاند.
درباره TFSF Ventures
TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایهگذاری است که زیرساخت عامل هوشمند را از طریق سه ستون یکپارچه در کسبوکارها مستقر میکند: زیرساخت عاملانه، ریلهای پرداخت غیرسنتی، و یک موتور سرمایهگذاری کامل. TFSF با ۲۷ سال سابقه در پرداخت و نرمافزار، در سطح جهانی فعالیت میکند و با روش استقرار ۳۰ روزه به ۲۱ صنعت خدمات میدهد. برای اطلاعات بیشتر به https://tfsfventures.com مراجعه کنید.
ارزیابی رایگان هوش عملیاتی را انجام دهید
به چند سوال کوتاه در مورد کسبوکار خود پاسخ دهید. یک طرح سفارشی استقرار هوش مصنوعی (AI) شامل توصیههای عامل، معماری و یک نقشه راه خاص برای عملیات خود را ظرف ۲۴ تا ۴۸ ساعت دریافت کنید. بدون تماس فروش. بدون تعهد. فقط داده. شروع کنید در https://tfsfventures.com/assessment
Originally published at https://tfsfventures.com/blog/the-architecture-questions-that-separate-the-best-ai-agents-for-hotels
Written by TFSF Ventures Research