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

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

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

از روز اول به روز صدم فکر کنید

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

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

مقیاس فقط تعداد کاربر نیست

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

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

معیار خروج از مرحله آزمایش

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

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

درباره مسئولیت صریح باشیم

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

فاصله نمونه نمایشی با محصول واقعی

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

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

کیفیت را روی زندگی روزمره بسنجیم

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

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

مالک خدمت و مالک مدل یک نفر نیستند

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

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

هزینه واقعی با مقیاس عوض می شود

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

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

چرخه اصلاح را پس از انتشار حفظ کنید

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

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

آیا کاربر می تواند به روش قبلی برگردد؟

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

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

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