پروژه یا قابلیت؟ مسئله این است!
مدل هوش‌مصنوعی می‌تواند روی د‌اده تاریخی خوب کار کند، در جلسه پایلوت تحسین شود و در گزارش مدیریت به‌عنوان «هوش مصنوعی صنعتی» ثبت گردد، اما احتمالاً هنوز قابلیت صنعتی‌شدن نداشته باشد. قابلیت وقتی ساخته می‌شود که خروجی به د‌اده قابل اتکا وصل باشد، با معماری واقعی سایت سا‌زگار باشد، وارد فرایند تصمیم شود، مسئول نگهداری داشته باشد و پس از رفتن تیم پروژه فرو نریزد.
رتروفیت هوشمند در نقطه تلاقی دارایی فیزیکی، ابزار دقیق، OT، د‌اده، مدل، نرم‌افزار، فرایند، بهره‌بردار و تصمیم سازمانی شکل می‌گیرد. اگر یکی از این حلقه‌ها باز بماند، آنچه تحویل می‌شود پروژه است نه قابلیت.
Demo،Pilot و قابلیت عملیاتی یکی نیستند
این سه سطح بارها به‌جای یکدیگر به کار می‌روند و همین جابه‌جایی منشأ بسیاری از شکست‌های بعدی است.
Demo، توان فناوری را نشان می‌دهد. معمولاً روی د‌اده انتخاب‌شده، در شرایط مساعد و با حضور کسانی اجرا می‌شود که مسئله را می‌شناسند. Demo برای رد کردن یک بن‌بست فنی مفید است؛ برای تصمیم سرمایه‌گذاری کافی نیست.
Pilot، باید نشان دهد راهکار در محیط واقعی، با محدودیت سایت و خطوط تولید، با د‌اده ناقص و با کاربران واقعی، قابلیت موردنظر را می‌سازد. پایلوت اگر فقط «مدل دقت خوبی داشت» را ثابت کند، هنوز پایلوت صنعتی نیست. باید معلوم کند د‌اده از کجا می‌آید، وقتی حسگر قطع شد چه می‌شود، اپراتور با خروجی چه می‌کند و موفقیت با کدام شاخص عملیاتی سنجیده می‌شود.
قابلیت عملیاتی، آن چیزی است که بعد از راه‌اندازی در شیفت شب، در تغییر خوراک، در اورهال و در غیاب تیم توسعه کار می‌کند. مالک حسگر، مالک مدل، مسئول نسخه اجرایی مدل، مدیر ثبت رخداد و پشتیبانی در آن مشخص و مسیر تأیید و بازگشت تعریف شده است. اگر این‌ها نباشد، پروژه بسته شده و قابلیت باز نشده است.
رتروفیت این تمایز را در چرخه مهندسی تکرار می‌کند: اعتبارسنجی فقط تست آفلاین نیست؛ بسته به پروژه شامل آزمون در Testbed، حالت سایه و پایلوت در Living Lab است. آزمون پذیرش در کارخانه یا FAT (Factory Acceptance Test) و آزمون پذیرش در سایت یا SAT (Site Acceptance Test) برای مدل و د‌اده نیز باید بازتعریف شوند، چون ماهیت AI با کارت ورودی/خروجی کلاسیک یکی نیست.
چرا مدل هوش مصنوعی خوب کافی نیست؟
دقت روی مجموعه آزمون، شرط لازم است نه شرط کافی.
اگر نرخ نمونه‌برداری با دینامیک مسئله نخواند، مدل تغییر سریع را نمی‌بیند. وقتی زمینه بهره‌برداری به داده‌های مدل وصل نباشد، انحراف ناشی از تغییر بار با عیب یکی گر‌فته می‌شود. اگر زمان آزمایشگاه و زمان اقامت در واحد هم‌تراز نشود، رابطه کیفیت ممکن است از نظر آماری قوی و از نظر فیزیکی غلط باشد. اگر خروجی مدل به واحد، پرچم کیفیت، مُهر زمانی و نگاشت تگ سامانه مقصد وصل نباشد، یکپارچه‌سازی در مرز سیستم‌ها می‌شکند؛ جایی که سند رتروفیت بخش بزرگی از شکست پروژه‌های صنعتی را می‌بیند.
حتی وقتی مدل درست است، اگر وارد تصمیم نشود، ارزش صنعتی نمی‌سازد. هشدار سلامت که به اهمیت تجهیز، قطعه یدکی، فرصت توقف و برنامه تولید وصل نباشد، اقدام تعمیراتی نیست. توصیه انرژی که روی تراز ناتمام سوار باشد، بهینه‌سازی نیست. تصویر ایمنی که جای لایه حفاظتی مهندسی‌شده بنشیند، ریسک جدید است نه قابلیت.
بنابراین سؤال مدیریتی نباید این باشد که «مدل چقدر دقیق است؟». سؤال این است که «این خروجی کدام عدم‌قطعیت عملیاتی را کم می‌کند و در کدام فرایند تصمیم می‌نشیند؟».
سطح اختیار باید با شواهد، بالا برود
هرچه سامانه به مداخله نزدیک‌تر شود، نیاز به شواهد، اعتبارسنجی و کنترل اختیار بیشتر می‌شود. چارچوب رتروفیت میان چند سطح زیر تمایز می‌گذارد:
- فقط خواند‌ن. د‌اده از OT به لایه تحلیل می‌رود و مسیری برای فرمان وجود ندارد. برای بسیاری از کاربردهای مشاهده، سلامت و بنچمارک، این سطح مناسب است.
- مشورتی. (Advisory) سامانه گزینه و پیامد را نشان می‌دهد؛ انسان تصمیم می‌گیرد. این سطح برای کیفیت، انرژی، بخشی از HSE و تصمیم دارایی مناسب است.
- اقدام پس از تأیید. پیشنهاد وجود دارد، اما اعمال آن به تأیید تعریف‌شده بند است.
- نظارتی. (Supervisory) سامانه در محدوده مشخص نقطه تنظیم یا توصیه کنترلی می‌فرستد؛ کنترل پایه همچنان مسئول تثبیت است.
- حلقه بسته. فقط پس از شواهد کافی، در کاربرد مناسب، با حدود روشن، امکان بازگشت و بدون عبور از SIS،ESD و اینترلاک.
خطا این است که سطح اختیار را با بلوغ فناوری یکی بگیریم. مدل قوی‌تر مجوز حلقه بسته نمی‌دهد. حلقه بسته یعنی مسئولیت مهندسی بالاتر، امنیت سخت‌گیرانه‌تر، رفتار در قطع ورودی و تعریف صریح آنچه نباید رخ دهد. در کنترل پیشرفته اگر APC از دسترس خارج شد، کنترل پایه باید ادامه یابد. در ایمنی، هوشمندی پوشش مشاهده را زیاد می‌کند؛ جایگزین چرخه رسمی Safety نمی‌شود.
انسان در حلقه یعنی فهم، تأیید، رد و Override
حضور یک کاربر کنار داشبورد، Human-in-the-loop نیست. کاربر باید بتواند خروجی را بفهمد: این عدد از کدام د‌اده آمد‌ه، در چه شرایطی معتبر است و بیرون از چه محدوده‌ای نباید به آن اعتماد کرد. باید بتواند تأیید یا رد کند و رد کردنش ثبت شود. باید در محدوده تعریف‌شده Override داشته باشد، بدون آنکه سامانه در سکوت به مسیر قبلی برگردد یا هشدار را پنهان کند.
اگر خروجی برای بهره‌بردار قابل تفسیر نباشد، یا رد کردن آن پرهزینه‌تر از نادیده گرفتنش باشد، سامانه به تدریج از عملیات خارج می‌شود. این خروج معمولاً در گزارش پروژه دیده نمی‌شود؛ چند ماه بعد در شیفت معلوم می‌شود که کسی به مدل نگاه نمی‌کند.
تعامل با اپراتور باید از طراحی آغاز شود نه از آموزش پایانی. دانش بهره‌برداری هم ورودی توسعه است هم معیار اعتبار. مدلی که خلاف تجربه پایدار سایت حرف بزند، یا اشتباه است یا زمینه را ندیده است. در هر دو حالت، قبل از افزایش اختیار باید مسئله حل شود.
قابلیت بعد از راه‌اندازی تمام نمی‌شود
مدل صنعتی پس از آموزش تمام نمی‌شود. نسخه، د‌اده آموزش، آزمون، محدوده اعتبار، استقرار، پایش، رانش، اعتبارسنجی مجدد، بازآموزش و بازگشت باید قابل مدیریت باشند. در صنعت این موضوع سنگین‌تر از محیط آزمایشگاهی است، چون اورهال، تعویض حسگر، تغییر خوراک، تعویض کاتالیست یا تغییر استراتژی کنترل، رفتار د‌اده و مدل را عوض می‌کنند.
پس از راه اندازی و تحویل عملیاتی (Commission) باید معلوم باشد:
- مسئول حسگر و کیفیت د‌اده کیست؛
- مسئول واسط OT و رفتار در قطع ارتباط کیست؛
- چه کسی نسخه مدل را تأیید می‌کند؛
- رخداد و پشتیبانی به کدام تیم می‌رود؛
- بعد از کدام تغییرات سایت، بازبینی مدل اجباری است.
اگر این‌ها در قراردادها و ساختار سازمانی دیده نشود، پروژه «تحویل شده»، اما «قابلیت» یتیم مانده است. رتروفیت انتقال به بهره‌برداری و مدیریت چرخه عمر را بخشی از مهندسی استقرار می‌داند، نه خدمات اختیاری پس از فروش.
زیرساخت نیز باید قطع ارتباط، قطع سرویس، از دست رفتن GPU یا منبع د‌اده را در طراحی ببیند. از دست دادن ورودی غیرحیاتی نباید کل سامانه را متوقف کند؛ اما اگر د‌اده کلیدی رفت، سامانه نباید خروجی ظاهراً معتبر بسازد زیرا در خیلی از موارد، اعتماد غلط از نبود خروجی، خطرناک‌تر است.
شاخص باقی‌ماندن قابلیت در عملیات
برای آنکه بحث از توصیه کلی خارج شود، می‌توان ماندگاری را با چند پرسش مدیریتی سنجید. پاسخ منفی به هر یک یعنی هنوز پروژه است نه قابلیت.
- مسئله صنعتی و منفعت قابل اندازه‌گیری از ابتدا مکتوب شده است یا فقط نام فناوری؟
- د‌اده موردنیاز از منبع پایدار می‌آید یا از استخراج دستی پایلوت؟
- خروجی در کدام سامانه تصمیم یا اقدام می‌نشیند؟
- سطح اختیار با شواهد کدام آزمون بالا رفته است؟
- رفتار سامانه در د‌اده خراب، قطع ارتباط و خارج از دامنه تعریف شده است؟
- اپراتور می‌تواند خروجی را بفهمد و رد کند؟
- پس از اورهال یا تعویض حسگر، چه کسی مدل را بازمی‌بیند؟
- اگر تیم پروژه نباشد، پشتیبانی نسخه و رخداد با کیست؟
- آیا مسیر فرمان به OT فقط به‌اندازه مسئله باز شده و از لایه‌های حفاظتی جداست؟
- آیا می‌توان همین قابلیت را با Validation محلی به دارایی یا واحد مشابه برد، یا همه‌چیز به افراد همین پایلوت بند است؟
پیام برای تصمیم‌گیران
خرید مدل، اجاره GPU یا برگزاری پایلوت، به‌خودی‌خود هوشمندسازی نیست. هوشمندسازی وقتی رخ می‌دهد که سازمان بتواند در نقطه مناسب، با مدل معتبر، حدود اختیار روشن و امکان بازگشت، بخشی از مشاهده یا تصمیم را به سامانه بسپارد و آن سپردن را بعد از تغییر شرایط سایت زنده نگه دارد.
رتروفیت در این چارچوب، تعهد را روی قابلیت می‌گذارد نه روی نمایش فناوری. ترکیب شرکاء، یکپارچه‌سازی مرز سیستم‌ها، اعتبارسنجی در حالت سایه و طراحی چرخه عمر مدل، دقیقاً برای همین فاصله میان پروژه و قابلیت است. در پروژه‌های مناسب، پذیرش بخشی از ریسک نتیجه نیز فقط وقتی معنا دارد که منفعت قابل اندازه‌گیری باشد و ماندن قابلیت در عملیات جزء تعریف کار باشد.