نویسنده: آرش غازی
هوش مصنوعی باید در نقشه اولیه نرمافزار حضور داشته باشد
به باور من، در طراحی نسل جدید نرمافزارها باید یک پرسش بنیادی را کنار پرسشهای مربوط به داده، امنیت و تجربه کاربر قرار دهیم: کدام بخش از کار را خود نرمافزار میتواند بفهمد، تحلیل کند و در محدودهای مشخص انجام دهد؟ منظورم افزودن یک چتبات به گوشه صفحه نیست. منظور، استفاده کارآمد از هوش مصنوعی بهعنوان یکی از پایههای طراحی است؛ پایهای که میتواند تقسیم کار میان انسان و نرمافزار را تغییر دهد.
سالها نرمافزار را ابزاری برای ثبت، جستوجو و نمایش اطلاعات ساختهایم. کاربر داده را وارد میکند، گزارش میگیرد، میان چند صفحه جابهجا میشود و در نهایت خودش رابطهها را پیدا میکند و اقدام بعدی را انجام میدهد. این الگو هنوز در بسیاری از موقعیتها مفید است، اما نباید تنها الگوی ذهنی ما برای ساخت محصول جدید باقی بماند. نرمافزار میتواند بخشی از این فاصله میان «اطلاعات موجود» و «کار انجامشده» را بر عهده بگیرد.
این تغییر در نرمافزارهای صنعتی اهمیت بیشتری دارد؛ جایی که داده فراوان است، زمان تصمیم محدود است و پیامد خطا میتواند از یک تجربه کاربری نامناسب فراتر برود. بنابراین همانقدر که باید جسورانه فرصتها را ببینیم، باید دقیق و مسئولانه درباره حدود اختیار سیستم تصمیم بگیریم.
تفاوت یک قابلیت جانبی با یک اصل طراحی
وقتی هوش مصنوعی را قابلیت جانبی میبینیم، ابتدا تمام گردش کار را میسازیم و در پایان میپرسیم کجا میتوان یک پنجره گفتگو اضافه کرد. اما وقتی آن را در معماری اولیه در نظر میگیریم، از ابتدا میپرسیم چرا کاربر باید این مرحله را دستی انجام دهد، چه شواهدی برای تصمیم لازم است و کدام اقدام را میتوان با کنترل مناسب به سیستم سپرد.
برای مثال، تفاوت مهمی میان «پرسیدن وضعیت سفارش» و «تشخیص خطر تأخیر سفارش، بررسی علت، آمادهکردن گزینههای جبران و ایجاد کار پیگیری برای مسئول مربوط» وجود دارد. هر دو ممکن است رابط گفتگو داشته باشند، ولی ارزش اصلی دومی از اتصال به فرایند میآید، نه از روان بودن جملههایش. پنجره گفتگو میتواند یکی از راههای تعامل باشد؛ نباید خودِ تعریف هوشمندی باشد.
این نگاه به معنی استفاده از مدل زبانی برای همه مسائل نیست. محاسبه قطعی، قانون روشن، مدل آماری، بهینهسازی، بینایی ماشین و قضاوت انسانی هرکدام جای خود را دارند. طراحی خوب ابزار را از مسئله انتخاب میکند. اگر یک قاعده ساده کار را قابل اتکاتر و کمهزینهتر انجام میدهد، پیچیده کردن آن با هوش مصنوعی امتیاز محسوب نمیشود.
فرصت اصلی فقط خودکار کردن کارهای فعلی نیست
بخشی از فرصت، انجام کارهایی است که قبلاً انسان انجام میداد: مرور گزارش شیفت، دستهبندی درخواست، مقایسه اسناد یا پیگیری اختلاف میان چند سامانه. اما بخش دیگری از فرصت در کارهایی است که به دلیل حجم، هزینه یا دشواری، اساساً بهصورت منظم انجام نمیشدند. این بخش دوم نباید از دید طراح پنهان بماند.
بررسی همزمان روند چندین متغیر فرایندی، مرور سابقه طولانی توقفها در کنار یادداشتهای اپراتور، یا مقایسه پیوسته برنامه تولید با محدودیتهای در حال تغییر، ممکن است از ظرفیت بررسی دستی روزانه خارج باشد. با داده مناسب و روش اعتبارسنجی روشن، میتوان امکان انجام بخشی از این تحلیلها را بررسی کرد. امکانپذیر شدن یک کار البته با اثبات ارزش اقتصادی و ایمنی آن یکسان نیست.
به همین دلیل، در جلسه تحلیل نیاز فقط نمیپرسم «امروز چه کاری انجام میدهید؟». پرسش مهم دیگر این است: «چه کاری را دوست داشتید انجام دهید، اما همیشه به دلیل کمبود وقت یا دشواری کنار گذاشتهاید؟». پاسخ به این پرسش میتواند نیازهایی را آشکار کند که در فهرست فرمها و گزارشهای فعلی دیده نمیشوند.
در صنعت، واحد طراحی باید فرایند باشد، نه صفحه
در یک کارخانه، مسئله معمولاً داخل یک فرم محصور نیست. کیفیت محصول، وضعیت ماشین، مواد اولیه، برنامه تولید و تجربه اپراتور به هم وابستهاند. اگر نرمافزار فقط این دادهها را در جزیرههای جدا ذخیره کند، اضافه کردن یک مدل هوشمند به یکی از جزیرهها لزوماً دید یکپارچه ایجاد نمیکند. ارتباط داده و معنای رویداد باید در طراحی مشخص باشد.
در مطلب NIST درباره پایش هوشمند فرایندهای تولید، اهمیت بررسی اثرها در سطح کل سامانه، کیفیت داده و آزمون در محیط کنترلشده مطرح شده است. نکتهای که برای بحث ما اهمیت دارد این است که رفتار یک جزء بهتنهایی تمام داستان فرایند را توضیح نمیدهد.
از این منظر، طراحی نرمافزار صنعتی باید مسیر «رویداد، شواهد، تحلیل، اقدام و نتیجه» را پوشش دهد. اگر سیستم فقط هشدار بسازد اما معلوم نباشد چه کسی باید چه کاری انجام دهد، آخرین حلقه همچنان گم است. هشدار بیشتر، بدون مسئول و اقدام قابل پیگیری، الزاماً به عملیات بهتر منجر نمیشود.
سه نمونه از نرمافزاری که کار را جلو میبرد
نگهداری تجهیزات: از نشانه غیرعادی تا کار قابل بررسی
در یک سناریوی فرضی، سامانه تغییر غیرمعمولی در داده تجهیز میبیند. بهجای صدور یک پیام مبهم، سابقه تعمیر، شرایط کار و گزارشهای مرتبط را کنار هم میگذارد و یک پرونده بررسی آماده میکند. مسئول نگهداری شواهد را میبیند، پیشنهاد را تأیید یا رد میکند و نتیجه بررسی ثبت میشود. مدل نباید صرفاً از مشاهده یک همبستگی، علت خرابی را قطعی اعلام کند.
ارزش این طراحی در کوتاه کردن مسیر رسیدن از نشانه به بررسی مسئولانه است. حتی اگر تصمیم نهایی با متخصص باقی بماند، جمعآوری شواهد و ایجاد کار پیگیری میتواند بخشی از وظیفه نرمافزار باشد. این مثال شرح قابلیت قابل طراحی است، نه ادعای استقرار یا نتیجه یک پروژه مشخص.
کنترل کیفیت: از تصویر مشکوک تا پیگیری مستند
در سناریویی دیگر، یک مدل بینایی ماشین مورد مشکوکی را برای بازبینی علامت میزند. نرمافزار باید تصویر، شناسه قطعه، زمان، دسته تولید و تصمیم بازبین را به هم متصل نگه دارد. موارد نامطمئن به مسیر بررسی بروند و نتیجه آنها برای ارزیابی بعدی قابل استفاده باشد. حذف تصویر مشکوک از صف، بدون ثبت تصمیم، یادگیری عملیاتی را از بین میبرد.
اینجا هم هدف فقط نمایش درصد اطمینان نیست. باید بدانیم کدام قطعه نیاز به بررسی دارد، چه کسی مسئول است و نتیجه چه اثری بر گردش کار مجاز میگذارد. معیار پذیرش نیز باید روی داده نماینده محیط واقعی تعریف شود، نه چند تصویر انتخابشده برای یک نمایش جذاب.
برنامهریزی: از گزارش تأخیر تا گزینههای قابل مقایسه
فرض کنید تأخیر یک ماده اولیه، برنامه چند سفارش را تحت تأثیر قرار داده است. نرمافزار میتواند گزینههای برنامهریزی را با توجه به قواعد و محدودیتهای ثبتشده آماده کند و اثر هر گزینه را نشان دهد. مسئول برنامهریزی همچنان درباره تعارضهای تجاری و تعهد به مشتری تصمیم میگیرد؛ اما لازم نیست تمام دادههای پراکنده را دوباره دستی جمع کند.
در این مثال، مدل زبانی ممکن است توضیح یا خلاصه تولید کند، ولی رعایت ظرفیت، موجودی و قواعد قطعی باید در سازوکار مناسب کنترل شود. متن قانعکننده نباید جای بررسی امکان اجرای برنامه را بگیرد. ترکیب درست اجزا مهمتر از نام مدل مورد استفاده است.
معماری باید اجازه اقدام بدهد، اما نه اختیار نامحدود
اگر قرار است هوش مصنوعی فقط متن تولید نکند، نرمافزار به مسیرهای اجرایی مشخص نیاز دارد. ایجاد درخواست بررسی، آمادهکردن پیشنویس دستور کار یا پیشنهاد تغییر برنامه باید از رابطهای محدود و قابل ثبت انجام شود. دسترسی مستقیم و نامحدود مدل به تمام دادهها و عملیات، میانبری خطرناک است، نه نشانه بلوغ محصول.
برای هر اقدام، ورودی مجاز، پیششرط، سطح دسترسی، نیاز به تأیید و نتیجه قابل مشاهده تعریف شود. اجرای دوباره نباید کار تکراری بسازد. اگر سرویس مقصد در دسترس نیست، وضعیت باید معلوم بماند و مسیر بازیابی وجود داشته باشد. اینها مسائل پایه مهندسی نرمافزارند که با حضور AI مهمتر میشوند، نه کماهمیتتر.
در سطح رابط کاربر نیز باید فرق پیشنهاد، پیشنویس و اقدام انجامشده دیده شود. کاربر نباید از یک جمله کلی برداشت کند که عملیاتی اجرا شده، در حالی که سیستم فقط پیشنهاد داده است. شفافیت وضعیت، بخشی از اعتمادپذیری است و باید از طراحی اولیه وارد محصول شود.
انسان باید در جای درست فرایند بماند
منظور از کاهش کار دستی، حذف مسئولیت انسان نیست. میتوان کار جستوجو، جمعآوری، تطبیق و آمادهسازی را به سیستم سپرد و ظرفیت متخصص را برای استثنا، قضاوت و تصمیم مهم آزاد کرد. اما نوشتن عبارت «با تأیید انسان» هم کافی نیست؛ فرد باید زمان، اطلاعات و اختیار واقعی برای بازبینی داشته باشد.
در چارچوب مدیریت ریسک هوش مصنوعی NIST، نسخه ۱٫۰، تعریف مسئولیتها و مدیریت ریسک در طول چرخه عمر اهمیت دارد. در طراحی صنعتی، این اصل را باید به نقشهای روشن، ثبت تصمیم و امکان توقف عملکرد هوشمند تبدیل کنیم. ارجاع به یک چارچوب، جای آزمون و شواهد اجرای کنترلها را نمیگیرد.
برای اقدامهایی که روی تجهیزات یا ایمنی اثر دارند، مدل احتمالاتی نباید جای کنترلهای مستقل ایمنی و منطق تأییدشده را بگیرد. حدود عملیاتی و مسیر توقف باید توسط متخصصان حوزه تعریف شوند. میتوان از پیشنهاد و اجرای آزمایشی بدون اثر شروع کرد؛ گسترش اختیار باید پس از ارزیابی و متناسب با پیامد خطا باشد.
کیفیت محصول را با کار انجامشده بسنجیم
تعداد گفتگوها یا طول پاسخها معیار کافی برای موفقیت نیست. باید دید چه میزان از گردش کار با کیفیت قابل قبول پیش رفته، چند بار مداخله لازم بوده و چه خطاهایی ایجاد شده است. هزینه مصرف، زمان بازبینی و بار پشتیبانی هم در ارزیابی حضور دارند. یک سامانه پرحرف که کار بیشتری برای تیم میسازد، به هدف نرسیده است.
پیشنهاد من شروع از یک فرایند محدود و قابل سنجش است. وضعیت فعلی را ثبت کنید، خروجی مورد انتظار را تعریف کنید، مدتی پیشنهادهای سیستم را بدون اجرای خودکار بررسی کنید و بعد درباره اختیار محدود تصمیم بگیرید. داده نامناسب یا فرایند مبهم را با افزایش پیچیدگی مدل جبران نکنید؛ اول مسئله پایه را حل کنید.
این رویکرد به معنی انتظار برای شرایط کامل نیست. به معنی انتخاب قدمی است که بتوان نتیجهاش را دید، خطایش را شناخت و در صورت نیاز از آن برگشت. معماری نسل جدید باید چنین یادگیری تدریجی را ممکن کند، نه اینکه سازمان را از روز اول به تصمیمی غیرقابل بازگشت وابسته سازد.
جمعبندی: هوشمندی باید در تقسیم کار دیده شود
به باور من، یکی از پایههای اصلی طراحی نسل جدید نرمافزار این است که از ابتدا نقش مؤثر هوش مصنوعی را در انجام کارها بررسی کنیم. نه همه مسائل به AI نیاز دارند و نه هر اقدام باید خودکار شود؛ اما ساخت نرمافزار صرفاً بر اساس تقسیم کار گذشته، میتواند فرصتهای مهم را از بین ببرد. پرسش اصلی دیگر فقط «کاربر کجا کلیک کند؟» نیست؛ «چرا هنوز لازم است این کار را کاربر انجام دهد؟» هم باید پرسیده شود.
در صنعت، پاسخ خوب به این پرسش از کنار هم قرار گرفتن شناخت فرایند، داده معتبر، ابزار مناسب و کنترل مسئولانه میآید. نرمافزار آینده را نباید با تعداد پاسخهایش تعریف کنیم؛ باید ببینیم چه کار مفیدی را با شواهد روشن و اختیار درست به نتیجه میرساند.
برای ادامه بحث، خدمات هوش مصنوعی ایزیساز و توسعه نرمافزار سفارشی را ببینید. اگر در سازمان شما کاری به دلیل دشواری یا حجم زیاد انجام نمیشود، از طریق تماس با ایزیساز همان فرایند را مطرح کنید؛ نقطه شروع مناسب، شناخت کار است، نه انتخاب یک چتبات.
تصویرسازی اختصاصی برای این یادداشت.