Khosh Aghbat Amir Hossein
دانشجوی برق صنعتی دانشگاه علمیکاربردی، فعال در برق ساختمان و هوشمندسازی
2 یادداشت منتشر شدههوش مصنوعی مولد در کارگاه برق: دستیار روزمره یا مرجع تصمیم؟
هوش مصنوعی مولد در کارگاه برق: دستیار روزمره یا مرجع تصمیم؟
امیرحسین خوش عاقبت
مهندس برق و دانشجوی برق صنعتی؛ فعال اجرایی برق و هوشمندسازی ساختمان در مشهد؛ دارای مدرک اپراتوری هوش مصنوعی
در پایان یک روز کاری، یادداشت های بازدید، مشخصات تجهیزات و فهرست نواقص روی میز مجری برق جمع شده اند؛ اما هنوز گزارش تحویل آماده نیست. اینجا می توان از هوش مصنوعی مولد برای مرتب کردن اطلاعات و تهیه پیش نویس کمک گرفت؛ نه برای تایید ایمنی تاسیسات. مرز کاربرد آن همین تفاوت است: تولید و سازمان دهی پیشنهاد، با پذیرش مسئولیت تصمیم فنی یکی نیست.
محاسبات و کنترل دوباره: مسیر حل را بخواهیم، نه فقط جواب را
کاربرد پیشنهادی در محاسبات روزمره، تبدیل داده های پراکنده به جدولی قابل کنترل است: نام مدار، مشخصات بار، طول مسیر، اطلاعات کابل و داده های نامشخص. درخواست مفید این نیست که «برای این مدار کابل انتخاب کن»؛ بهتر است بگوییم: «ورودی های لازم، فرض ها، روابط مورد استفاده و موارد نیازمند مراجعه به مرجع را جدا کن؛ هیچ داده ای را حدس نزن.»
خروجی را می توان برای کشف ورودی های جاافتاده، بررسی واحدها و تنظیم برگه محاسبه به کار گرفت. بااین حال، نمایش فرمول و مراحل حل، تضمین صحت نیست. موسسه ملی استاندارد و فناوری آمریکا در سند «چارچوب مدیریت ریسک هوش مصنوعی: نمایه هوش مصنوعی مولد»، به شماره NIST AI 600-1، تصریح می کند که مدل ممکن است علاوه بر پاسخ نادرست، استدلال و ارجاع ظاهرا توجیه کننده نیز تولید کند.
بنابراین، در محاسبات حفاظتی و مسائل ایمنی، خروجی باید با مرجع معتبر و محاسبه مستقل راستی آزمایی شود. مستقل یعنی رابطه و داده ها دوباره بررسی و محاسبه با روشی جداگانه انجام شود؛ پرسیدن «مطمئنی؟» از همان مدل، کنترل مستقل نیست. انتخاب نهایی تجهیزات حفاظتی یا تایید ایمنی مدار نباید صرفا بر پاسخ گفت وگویی تکیه کند.
خواندن استاندارد و مستندات: خلاصه ای با نشانی قابل پیگیری
برای مطالعه مقررات، بهتر است متن مشخص را در اختیار ابزار بگذاریم، نه اینکه از حافظه آن شماره بند بخواهیم. برای نمونه، در مطالعه مبحث سیزدهم مقررات ملی ساختمان، «طرح و اجرای تاسیسات برقی ساختمان ها»، ویرایش سوم ۱۳۹۵، باید نسخه مورد استفاده پروژه مشخص باشد. نام و ویرایش این سند در مشخصات انتشار آن قابل بررسی است.
درخواست کاربردی چنین است: «از متن پیوست، الزامات مرتبط با موضوع را استخراج کن؛ کنار هر مورد، شماره بند، صفحه و عبارت اصلی را بیاور؛ توضیح خودت را از نقل قول جدا بنویس.» سپس مهندس باید هر ارجاع را در اصل سند باز کند. طبق گزارش یادشده، ارجاعات تولیدشده نیز ممکن است ساختگی باشند؛ وجود شماره بند در پاسخ، دلیل وجود آن بند نیست.
همین روش برای دفترچه نصب و برگه مشخصات تجهیزات هوشمندسازی مناسب است. نام دقیق محصول و نسخه مستند را ثبت کنیم و از ابزار بخواهیم محدودیت ها، شرایط نصب و موارد نامعلوم را جدا کند. خلاصه باید راهنمای مراجعه باشد، نه جایگزین دستورالعمل سازنده.
گزارش و صورت جلسه تحویل: بازنویسی شواهد، نه ساختن واقعیت
برای تهیه گزارش، داده های ثبت شده را با قالب مشخص به ابزار بدهیم: محل، تاریخ، شناسه مدار یا تجهیز، مشاهده، نتیجه آزمون واقعا انجام شده، نقص و اقدام پیگیری. دستور اصلی این باشد: «هیچ مشاهده، عدد، آزمون یا تاییدیه ای اضافه نکن؛ داده ناموجود را با عبارت ثبت نشده مشخص کن.»
در صورت جلسه تحویل نیز باید میان «نصب شده»، «بازرسی شده»، «آزمون شده» و «تاییدشده» تمایز بگذاریم. استاندارد IEC 60364-6:2016 با عنوان فارسی «تاسیسات الکتریکی فشار ضعیف بخش ۶: صحه گذاری»، الزامات صحه گذاری اولیه و دوره ای تاسیسات را پوشش می دهد؛ تولید متن گزارش، اجرای این فرایند نیست.
بازبین انسانی باید متن نهایی را با یادداشت ها و نتایج واقعی تطبیق دهد. همچنین، پیش از بارگذاری مدارک، اطلاعات شخصی و داده های حساس پروژه را حذف یا پوشانده و مجوز استفاده از سرویس را بررسی کنیم؛ افشای داده و اطلاعات حساس از ریسک های شناسایی شده هوش مصنوعی مولد است.
چک لیست و عیب یابی اولیه: یک مثال کارگاهی
سناریوی زیر فرضی است، نه گزارش یک پروژه واقعی: هنگام تحویل یک ساختمان مسکونی در مشهد، کارفرما می گوید روشنایی راه پله گاهی به فرمان سامانه هوشمند پاسخ نمی دهد. مجری، شرح نشانه، زمان وقوع، تغییرات اخیر، نقشه موجود و راهنمای تجهیزات را جمع می کند و از هوش مصنوعی می خواهد پرسش های تکمیلی و جدول ثبت بررسی تهیه کند.
خروجی مطلوب، تشخیص قطعی خرابی نیست؛ فهرستی برای جلوگیری از فراموشی اطلاعات است:
مشکل کجا و در چه شرایطی مشاهده شده است؟
آیا فرمان دستی و فرمان سامانه رفتار یکسانی دارند؟
پیش از شروع مشکل چه تغییری ثبت شده است؟
کدام اطلاعات یا مدارک هنوز در دسترس نیست؟
هر بررسی چه نتیجه ای داشته و چه کسی آن را ثبت کرده است؟
بررسی عملی باید مطابق روش ایمن و توسط فرد واجد صلاحیت انجام شود؛ پاسخ مدل مجوز کار روی مدار برق دار یا دست کاری حفاظت نیست. این احتیاط مهم است، زیرا گزارش موسسه ملی استاندارد و فناوری آمریکا، تولید توصیه های خطرناک و اتکای بیش ازحد انسان به خروجی مدل را از ریسک های آن می داند.
پس از ثبت نتایج، می توان از ابزار خواست گزارش عیب یابی را تنظیم کند؛ اما علت نهایی باید به شواهد متکی باشد، نه به خوش بیانی پاسخ.
یادگیری سریع: از توضیح اولیه تا مراجعه هدفمند
برای آشنایی با موضوع تازه، درخواست را محدود و پروژه محور بنویسیم: «این مفهوم را برای مجری برق توضیح بده؛ پیش نیازها، اصطلاحات، خطاهای رایج و پرسش هایی را که باید از مستند سازنده پاسخ بگیرم جدا کن.» سپس توضیحات فنی را با منبع اصلی تطبیق دهیم و ابهام ها را پیش از اجرا برطرف کنیم.
قاعده عملی این است: هرچه پیامد خطا جدی تر باشد، اتکا به متن تولیدشده باید کمتر و کنترل مستقل بیشتر باشد. در کار روزمره، جایگاه مناسب این ابزار، دستیار تهیه پیش نویس، سازمان دهی داده و صورت بندی پرسش است؛ تصمیم ایمنی باید بر مقررات قابل اعمال، مستند معتبر، محاسبه مستقل و شواهد واقعی استوار بماند.
جمع بندی
هوش مصنوعی مولد را برای مرتب کردن داده ها، تهیه پیش نویس گزارش، ساخت چک لیست و روشن کردن پرسش های فنی به کار بگیریم. ورودی ها و موارد نامعلوم را مشخص کنیم و اجازه ندهیم ابزار، اطلاعات ثبت نشده را به متن اضافه کند. خلاصه استانداردها و توضیحات آموزشی را با اصل مستند تطبیق دهیم و هر خروجی مرتبط با حفاظت و ایمنی را با مرجع معتبر و محاسبه مستقل راستی آزمایی کنیم. گزارش نهایی و تصمیم اجرایی باید بازتاب شواهد واقعی باشند، نه صرفا پاسخ منسجم مدل.
منابع:
۱. موسسه ملی استاندارد و فناوری آمریکا؛ «چارچوب مدیریت ریسک هوش مصنوعی: نمایه هوش مصنوعی مولد»، سند NIST AI 600-1؛ ۲۰۲۴.
۲. وزارت راه و شهرسازی، دفتر مقررات ملی ساختمان؛ «مبحث سیزدهم مقررات ملی ساختمان: طرح و اجرای تاسیسات برقی ساختمان ها»، ویرایش سوم؛ ۱۳۹۵.
۳. کمیسیون بین المللی الکتروتکنیک؛ «تاسیسات الکتریکی فشار ضعیف بخش ۶: صحه گذاری»، استاندارد IEC 60364-6:2016؛ ۲۰۱۶.