بعد از راه اندازی سامانه هوش مصنوعی، مسئول نتیجه چه کسی است؟
در این یادداشت
لحظه تحویل یک پروژه معمولا روشن است: نسخه منتشر شده، آموزش انجام شده و مدیر پروژه گزارش پایان کار می دهد. اما برای هوش مصنوعی، این تازه آغاز یک مسئولیت بلندمدت است. داده عوض می شود، رفتار کاربران تغییر می کند و حتی کیفیت یک پاسخ که دیروز درست بوده ممکن است فردا افت کند.
اگر بپرسیم «این سامانه مال کیست؟» و پاسخ بشنویم «تیم فناوری آن را ساخته»، هنوز جواب کافی نگرفته ایم. سازنده سیستم لزوما صاحب تصمیمی نیست که سیستم پشتیبانی می کند.
چهار مسئولیت را از هم جدا کنیم
نخست، مالک کسب و کار باید بداند سیستم چرا وجود دارد و چه نتیجه ای باید ایجاد کند. اگر خروجی دیگر به کار کاربران نمی آید، او مسئول بازنگری هدف است.
دوم، مالک داده مسئول تعریف و اعتبار اطلاعات مهم است. وقتی دستورالعمل یا تعریف شاخص تغییر می کند، باید مسیر مشخصی برای اطلاع رسانی و به روزرسانی وجود داشته باشد.
سوم، مالک فنی مسئول پایداری، امنیت، ثبت رخدادها و تغییرات نرم افزار است. این نقش باید بتواند کیفیت سامانه را مشاهده و در زمان مشکل مداخله کند.
چهارم، کاربر یا تایید کننده انسانی باید بداند در کدام نقطه اختیار تصمیم دارد و چه چیزی را باید بررسی کند. اگر مسئولیت را روی کاغذ به او بدهیم ولی شواهد لازم را نشان ندهیم، پاسخ گویی واقعی شکل نمی گیرد.
در شرکت کوچک ممکن است یک نفر چند نقش را داشته باشد. اشکالی ندارد، به شرط آنکه خود نقش ها گم نشوند.
پایش فقط نمودار بالا بودن سرویس نیست
ممکن است سامانه همیشه در دسترس باشد و هر درخواست را در دو ثانیه پاسخ دهد، ولی پاسخ هایش به تدریج نامعتبر شوند. بنابراین پایش فنی و پایش کیفیت هر دو لازم اند. مثلا درصد خطای پاسخ های نمونه برداری شده، میزان ارجاع به کارشناس و تعداد اصلاح های کاربران می توانند نشانه های مهمی باشند.
در سامانه های مبتنی بر اسناد، تغییر نسخه منابع باید باعث آزمون دوباره سوال های مرتبط شود. در مدل های پیش بینی، تغییر الگوی داده ورودی و فاصله نتیجه پیش بینی با واقعیت باید زیر نظر باشد. شاخص دقیق برای هر کاربرد متفاوت است.
روزی که سیستم درست کار نمی کند
برای آن روز از پیش برنامه داشته باشید. چه کسی می تواند دسترسی را محدود کند؟ کاربران چگونه از مشکل باخبر می شوند؟ آیا فرایند جایگزین دستی وجود دارد؟ چه شواهدی لازم است تا سیستم دوباره فعال شود؟
من این پرسش ها را نشانه بدبینی نمی دانم. در یک کسب و کار بالغ، برای قطع برق و خرابی شبکه برنامه داریم؛ برای خطای سامانه هوشمند هم باید برنامه داشته باشیم.
تحویل واقعی یعنی توانایی اداره کردن
قبل از بستن پروژه، یک روز فرضی را تمرین کنید: مدیر محصول یا برنامه نویس اصلی در دسترس نیست، سند مهم تغییر کرده و کاربران چند پاسخ مشکوک گزارش داده اند. آیا تیم می داند چه کند؟ اگر نه، هنوز انتقال دانش و مالکیت تمام نشده است.
مالکیت محصول با پایان پروژه آغاز می شود
در پروژه های معمول نرم افزاری هم نگهداری مهم است، اما سامانه هوش مصنوعی دشواری تازه ای دارد: رفتار آن به داده، تنظیمات، مدل و نوع استفاده کاربران وابسته است. ممکن است هیچ کدی تغییر نکرده باشد اما با تغییر داده های ورودی، کیفیت پاسخ افت کند. بنابراین تحویل پروژه فقط به معنای نصب نسخه نهایی نیست. سازمان باید بتواند کیفیت خروجی را ببیند، مشکل را دسته بندی کند و درباره اصلاح یا توقف تصمیم بگیرد.
فرض کنید دستیار داخلی برای پاسخ به سوال های منابع انسانی راه اندازی شده است. سه ماه بعد مقررات مرخصی تغییر می کند. چه کسی سند تازه را تایید و منتشر می کند؟ چه کسی مطمئن می شود سند قدیمی از مرجع پاسخ کنار رفته است؟ چه کسی نمونه سوال های مرتبط را دوباره آزمایش می کند؟ اگر پاسخ این سوال ها مشخص نباشد، سامانه حتی بدون نقص فنی می تواند اطلاعات نادرست ارائه کند.
نظارت ریسک را به چهار مسئولیت وصل کنید
در کنار مالک کسب و کار، مالک داده، تیم فنی و کاربر یا تاییدکننده انسانی، باید نظارت بر کنترل و ریسک هم صاحب مشخص داشته باشد. این نظارت یک مسئولیت مکمل است، نه جایگزین نقش انسانی در بررسی یا تایید تصمیم. در شرکت کوچک ممکن است یک نفر چند نقش داشته باشد، اما باید بداند در هر موقعیت از کدام اختیار استفاده می کند. مبهم بودن مسئولیت، هنگام رخداد از کمبود فناوری خطرناک تر است.
در کنار این نقش ها، باید اختیار تصمیم روشن باشد. چه کسی می تواند یک قابلیت را متوقف کند؟ چه کسی تغییر مدل را تایید می کند؟ چه کسی به شکایت کاربر پاسخ می دهد؟ اگر هر تغییر کوچک نیازمند تصمیم چند کمیته نامشخص باشد، تیم به تدریج از فرایند رسمی فاصله می گیرد. اگر هیچ نظارتی نباشد، خطر تغییرات کنترل نشده بالا می رود. راه حل، تعریف سطح اختیار متناسب با حساسیت هر تغییر است.
این اختیارها را در یک فهرست کوتاه از تغییرهای مهم ثبت کنید و برای هر کدام جانشین تعیین کنید. وابستگی به یک فرد، حتی اگر مسئول اصلی کاملا آگاه باشد، در زمان مرخصی یا جابه جایی شغلی می تواند خدمت را متوقف کند.
آزمون ها را با تغییر کاربران به روز کنید
مجموعه آزمون اولیه ممکن است فقط نیازهای یک واحد یا یک دوره را پوشش دهد. با ورود کاربران تازه، پرسش ها و خطاهای محتمل هم تغییر می کنند. نمونه های واقعی را با رعایت حریم خصوصی به مجموعه ارزیابی اضافه کنید و پس از تغییر منبع، نسخه یا گروه کاربری، آزمون های مرتبط را دوباره اجرا کنید. هدف حفظ کیفیت روی نیازهای در حال تغییر است، نه نمره گرفتن همیشگی روی سوال های قدیمی.
فرایند تغییر نسخه باید قابل بازگشت باشد
به روزرسانی مدل، تغییر دستورها یا تغییر روش بازیابی می تواند در یک بخش کیفیت را بهتر و در بخش دیگر بدتر کند. برای همین هر تغییر مهم باید پیش از انتشار روی نمونه های ثابت و سناریوهای واقعی آزمایش شود. سپس می توان آن را ابتدا برای گروه محدودی فعال کرد و نتیجه را سنجید. اگر شاخص های حساس افت کردند، راه بازگشت به نسخه قبلی باید آماده باشد. انتشار بدون قابلیت عقب نشینی، تصمیمی پرخطر است.
ثبت نسخه نیز اهمیت دارد. وقتی کاربر درباره پاسخ هفته گذشته شکایت می کند، باید بدانیم کدام مدل، کدام اسناد و کدام تنظیمات در آن زمان استفاده شده اند. بدون این اطلاعات، بررسی علت بیشتر به حدس تبدیل می شود. نگهداری تاریخچه مناسب شاید در آغاز پروژه کار اضافی به نظر برسد، اما هنگام اختلاف یا ممیزی بسیار ارزشمند است.
بودجه نگهداری را از ابتدا ببینید
بعضی پروژه ها برای ساخت بودجه دارند اما برای اداره شدن نه. هزینه پایش، اصلاح داده، بازآموزی کارکنان، پاسخ به رخداد و بازبینی کیفیت پس از انتشار ادامه پیدا می کند. اگر بودجه فقط تا روز راه اندازی باشد، سازمان سامانه ای تحویل می گیرد که به تدریج از نیاز واقعی فاصله می گیرد. بهتر است مالک کسب و کار پیش از تصویب پروژه، هزینه بلندمدت و ظرفیت لازم برای پشتیبانی را بپذیرد.
در نهایت معیار تحویل را تغییر دهیم. به جای آنکه بگوییم «مدل راه افتاد»، بپرسیم «آیا سازمان می تواند آن را بدون حضور دائمی سازنده، ایمن و باکیفیت اداره کند؟» پاسخ به این سوال نشان می دهد پروژه واقعا به محصول تبدیل شده یا فقط یک نمایش طولانی تر بوده است.
گزارش کیفیت باید به اقدام برسد
فرض کنید تیم ماهانه نشان می دهد دقت دستیار از ۹۲ به ۸۸ درصد رسیده است. این عدد هشدار می دهد، اما به تنهایی نمی گوید چه باید کرد. شاید اسناد تازه وارد شده اند، شاید کاربران پرسش های متفاوتی مطرح می کنند یا شاید تغییر کوچکی در روش جست و جو رخ داده است. باید خطاها بر اساس نوع مسئله، گروه کاربر و نسخه سیستم بررسی شوند. سپس برای هر علت محتمل، مسئول اصلاح و آزمون مجدد مشخص شود.
در کنار روند کیفیت، تجربه کاربران را نیز ببینید. ممکن است میانگین نتیجه ثابت باشد اما یک گروه خاص با مشکل جدی روبه رو شده باشد. گزارش کلی چنین تفاوتی را پنهان می کند. همچنین لازم است درخواست هایی را که کاربر به روش دستی برگردانده ثبت کنیم؛ این موارد اغلب سرنخ ضعف واقعی محصول هستند.
در جلسه بهره برداری، فقط نپرسید سامانه چند ساعت فعال بوده است. بپرسید این ماه کدام تصمیم بر اساس بازخورد کاربران گرفته شده، چه خطایی دیگر تکرار نشده و کدام خطر همچنان باز است. این پرسش ها مالکیت خدمت را از عنوان سازمانی به رفتار قابل مشاهده تبدیل می کنند.
هوش مصنوعی باید از پروژه هیجان انگیز به خدمت قابل اتکا تبدیل شود. تفاوت این دو در مسئولیتی است که بعد از روز افتتاحیه باقی می ماند.