بانک، بیمارستان و کارخانه از هوش مصنوعی یک چیز نمی خواهند

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

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

از هدف شروع کنیم

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

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

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

فناوری مشابه، اجرای متفاوت

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

به همین دلیل نباید از یک ارائه دهنده فقط بپرسیم «آیا نمونه مشابهی در صنعت ما دارید؟» باید بپرسیم «آن نمونه دقیقا چه مسئله ای را حل کرده، چه کنترلی داشته و از کجا معلوم شده موفق بوده؟» نام صنعت به تنهایی مدرک کافی نیست.

تجربه دیگران را ترجمه عملی کنید

وقتی درباره یک پروژه موفق می خوانید، چهار نکته را برای سازمان خودتان بازنویسی کنید: مسئله اصلی، داده لازم، تغییر در کار روزانه و معیار نتیجه. بعد ببینید کدام فرض ها در محیط شما برقرار نیستند.

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

یک فناوری، سه تعریف متفاوت از موفقیت

تصور کنید سامانه ای در کارخانه خرابی دستگاه را پیش بینی می کند. اگر هشدار اشتباه باشد، شاید تیم تعمیرات یک بررسی اضافی انجام دهد؛ اگر خرابی واقعی را نبیند، توقف خط تولید رخ می دهد. در بیمارستان، همان مفهوم «پیش بینی» ممکن است با سلامت بیمار و تصمیم پزشک ارتباط پیدا کند. در بانک، یک مدل می تواند بر دسترسی فرد به اعتبار اثر بگذارد. پس حتی وقتی الگوریتم از نظر فنی شبیه است، خطای قابل قبول و نوع نظارت کاملا متفاوت خواهد بود. انتقال بی بررسی تجربه یک صنعت به صنعت دیگر، نادیده گرفتن همین تفاوت است.

در هر سه محیط باید بدانیم تصمیم نهایی با چه کسی است و چه شواهدی برای آن لازم است. مهندس تعمیرات ممکن است از ترکیب هشدار و بازدید فنی استفاده کند. پزشک نیازمند شواهد بالینی و نظارت تخصصی است. کارشناس ریسک بانکی باید با قواعد مصوب، کیفیت داده و امکان توضیح تصمیم کار کند. فناوری به تنهایی نمی تواند این چارچوب های حرفه ای و مسئولیت ها را تعریف کند.

از پرونده موفق فقط فناوری را برنداریم

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

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

در خدمات عمومی، عدالت و دسترسی مهم اند

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

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

در صنعت، فاصله مدل و محیط واقعی زیاد است

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

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

در خدمات مالی، امکان رسیدگی به تصمیم حیاتی است

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

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

الگو را در مقیاس کوچک بیازمایید

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

مراقب مثال های نمایشی باشید

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

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

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