وسایل نقلیه خودران، ربات‌های صنعتی و ناوگان پهپادها از کتاب‌های قانون صلب و دستی که سیستم‌های خلبان خودکار قدیمی را هدایت می‌کردند، پیروی نمی‌کنند. آن‌ها از حجم عظیمی از داده‌ها یاد می‌گیرند، به این معنی که رفتار آن‌ها احتمالی (probabilistic) است، نه قطعی (deterministic). یک خلبان خودکار سنتی در هواپیما، از طریق منطق کدنویسی‌شده‌ی صریح به ورودی‌های حسگر واکنش نشان می‌دهد، اما یک مدل یادگیری ماشین از طریق الگوهایی که در طول آموزش استنباط کرده است، واکنش نشان می‌دهد. همین تمایز، فرآیند تأیید (verification) را بسیار دشوارتر می‌کند و دقیقاً به همین دلیل است که جامعه یادگیری ماشین به جای تست‌های موردی (ad-hoc)، به سمت چارچوب‌های تضمین ساختاریافته حرکت کرده است.

چرا تضمین یادگیری ماشین غیرقابل مذاکره است

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

خطاها در یادگیری ماشین خودران همیشه از کدهای آشکارا بد ناشی نمی‌شوند. آن‌ها می‌توانند از شکاف‌ها در داده‌های آموزشی، تغییرات محیطی غیرمنتظره، یا پیش‌بینی‌های بیش از حد مطمئن در موارد خاص (edge cases) نشأت بگیرند. سازمان‌هایی که با اجزای ML مانند ماژول‌های نرم‌افزاری استاندارد برخورد می‌کنند و تصور می‌کنند یک مجموعه تست واحد (unit test) کافی است، خیلی دیر متوجه می‌شوند که دقت آزمایشگاهی به ایمنی در دنیای واقعی تبدیل نمی‌شود. شما به یک استاندارد سیستماتیک نیاز دارید که ریسک‌های منحصربه‌فرد رفتار آموخته‌شده را پوشش دهد. این همان شکافی است که چارچوب AMLAS برای پر کردن آن طراحی شده است.

AMLAS در واقع چه مواردی را پوشش می‌دهد

AMLAS که مخفف Assurance of Machine Learning for use in Autonomous Systems (تضمین یادگیری ماشین برای استفاده در سیستم‌های خودران) است، یک رویکرد سرتاسری (end-to-end) برای تأیید این موضوع ارائه می‌دهد که آیا اجزای آموخته‌شده برای استقرار در شرایط حساس (high-stakes) مناسب هستند یا خیر. این چارچوب با ایمنی به عنوان یک موضوع ثانویه یا یک مرحله نهایی قبل از انتشار برخورد نمی‌کند، بلکه فعالیت‌های تضمین را در چرخه حیات سیستم می‌بافد.

این چارچوب بر سه ستون عملی تمرکز دارد:

روش‌های تأیید برای مدل‌های ML. این فراتر از معیارهای استاندارد تقسیم آموزش-تست مانند دقت (accuracy) یا امتیاز F1 است. تضمین در چارچوب AMLAS می‌پرسد که آیا مدل در مرزهای تصمیم‌گیری به‌طور قابل پیش‌بینی رفتار می‌کند، چگونه به ورودی‌های خارج از توزیع (out-of-distribution) پاسخ می‌دهد، و آیا امتیازهای اطمینان آن، شاخص‌های قابل اعتمادی برای عدم قطعیت واقعی هستند یا خیر. از مهندسان انتظار می‌رود که مدل را با نمونه‌های خصمانه (adversarial examples) مورد بررسی قرار داده و آن را در برابر ورودی‌های حوزه‌هایی که کمی خارج از مجموعه آموزشی هستند، تحت تست فشار (stress-test) قرار دهند. هدف، رسیدن به کمال نیست؛ بلکه به دست آوردن شواهد کافی برای دانستن این است که چه زمانی می‌توان به مدل اعتماد کرد و چه زمانی نمی‌توان.

پروتکل‌های ایمنی برای اقدامات خودران. یک مدل ادراکی آموخته‌شده، داده‌ها را به نرم‌افزار برنامه‌ریزی و کنترل که سخت‌افزار فیزیکی را حرکت می‌دهد، منتقل می‌کند. AMLAS مستلزم آن است که این اقدامات پایین‌دستی شامل حفاظ‌ها (guardrails) باشند. حتی اگر یک شبکه عصبی یک شیء را اشتباه طبقه‌بندی کند، وسیله نقلیه یا ربات نباید از نظر فیزیکی قادر به اجرای مسیری باشد که محدودیت‌های سخت (hard constraints) را نقض می‌کند. این ممکن است به معنای محدودیت‌های گشتاور در بازوهای رباتیک، محدودیت‌های جغرافیایی (geofencing) برای پهپادها، یا کریدورهای ترمز اجباری برای وسایل نقلیه زمینی باشد. سیستم خودران به لایه‌های معماری نیاز دارد که از تبدیل شدن یک خطای تک‌مدلی به یک رویداد فیزیکی غیرقابل کنترل جلوگیری کند.

روش‌هایی برای کاهش عدم قطعیت. عدم قطعیت در یادگیری ماشین به اشکال مختلفی ظاهر می‌شود. عدم قطعیت آلئاتوریک (aleatoric uncertainty) که نویز ذاتی در خوانش‌های حسگر یا محیط‌ها است، و عدم قطعیت اپیستمیک (epistemic uncertainty) که بازتاب‌دهنده چیزی است که مدل هنوز نمی‌داند. AMLAS مشوق روش‌هایی است که هر دو را کمی‌سازی و مدیریت می‌کنند. تکنیک‌ها می‌توانند شامل روش‌های گروهی (ensemble methods) باشند که در آن چندین مدل، عدم توافق را به عنوان یک علامت هشدار اعلام می‌کنند، یا لایه‌های اعتبارسنجی ورودی که داده‌های شناخته‌شده برای ایجاد رفتار نامنظم را رد می‌کنند. ممکن است نتوانید عدم قطعیت را به طور کامل حذف کنید، اما می‌توانید از اقدام کورکورانه سیستم بر اساس آن جلوگیری کنید.

مسیری عملی برای ایجاد اعتماد

چارچوب‌ها تنها زمانی اهمیت دارند که تیم‌ها آن‌ها را به مرحله اجرا درآورند. AMLAS زمانی به بهترین شکل به عمل تبدیل می‌شود که سازمان‌ها یک توالی منضبط را دنبال کنند.

پیش از جمع‌آوری حتی یک مجموعه داده، اهداف ایمنی خود را تعریف کنید. در مهندسی نرم‌افزار سنتی، ابتدا نیازمندی‌ها تعیین می‌شوند. پروژه‌های یادگیری ماشین اغلب این روند را معکوس می‌کنند و با ایمنی به عنوان مسئله‌ای برخورد می‌کنند که باید پس از آموزش مدل حل شود. این عادت را تغییر دهید. با یک «دامنه طراحی عملیاتی» (operational design domain) شفاف شروع کنید. سیستم تحت چه شرایطی کار خواهد کرد؟ نرخ شکست قابل تحمل برای هر خطر چقدر است؟ کدام شکست‌ها مستلزم مداخله فوری انسان است؟ پاسخ به این سوالات در مراحل اولیه، همه‌چیز را، از جمع‌آوری داده‌ها گرفته تا معماری مدل، شکل می‌دهد.

مدل‌های خود را در برابر داده‌هایی که بازتاب‌دهنده آشفتگی‌های واقعی عملیاتی هستند، آزمایش کنید. بنچمارک‌های آزمایشگاهی آرامش‌بخش هستند، اما فریبنده می‌باشند. یک ربات انبار که منحصراً با تصاویر بارکد بی‌نقص آموزش دیده است، زمانی که برچسب‌ها چروکیده، با نورپردازی ضعیف یا پوشیده از جرم باشند، شکست خواهد خورد. یک پهپاد خودگردان که فقط در هوای مساعد آزمایش شده، با درخشش نور و بادهای شدید دچار مشکل خواهد شد. شما به لاگ‌های محیط‌های استقرار واقعی نیاز دارید، از جمله موارد حاشیه‌ای (edge cases) کلافه‌کننده‌ای که هرگز در مجموعه‌داده‌های منتخب ظاهر نمی‌شوند. آزمایش‌های «حالت سایه» (shadow mode) را اجرا کنید؛ جایی که سیستم خودگردان تصمیمات را به موازات اپراتورهای انسانی می‌گیرد اما هنوز کنترل سخت‌افزار را در دست ندارد. لاگ‌ها را با دقت مقایسه کنید.

عملکرد را پس از استقرار به‌طور مداوم نظارت کنید. دنیا ثابت نمی‌ماند. تغییرات فصلی نور، سطوح فرسوده جاده، طراحی‌های جدید بسته‌بندی و الگوهای متغیر ترافیک شبکه همگی می‌توانند مدلی را که زمانی عالی عمل می‌کرد، تضعیف کنند. سیستمی برای پایش (telemetry) راه‌اندازی کنید که اعتماد به پیش‌بینی، رانش توزیع ورودی و نرخ حوادث را ردیابی کند. آستانه‌هایی تعیین کنید که در صورت تغییر رفتار، باعث فعال شدن بازبینی انسانی یا محدودیت‌های عملیاتی موقت شود. یک مدل، محصولی ایستا نیست که آن را ارسال کنید و فراموش کنید؛ بلکه مؤلفه‌ای است که از لحظه مواجهه با دنیای واقعی، فرسوده می‌شود.

حقیقت تلخ درباره اعتبارسنجی در دنیای واقعی

بسیاری از تیم‌ها خود را متقاعد می‌کنند که امتیاز بالای اعتبارسنجی نشان‌دهنده آمادگی است. اما این‌طور نیست. اعتبارسنجی در دنیای واقعی مستلزم پذیرش شرایط دشوار است. این یعنی پرواز پهپادها در شرایط باد شدید، کار کردن ربات‌های انبار در شیفت شب زمانی که لامپ‌ها در حال چشمک زدن هستند، و قرار دادن مدل‌های ادراکی در معرض برچسب‌های خصمانه (adversarial stickers) روی تابلوهای راهنمایی و رانندگی. اگر محیط آزمایش شما مرتب و قابل پیش‌بینی به نظر می‌رسد، شما در حال آزمایش نیستید؛ بلکه در حال تمرین هستید.

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

حفظ صداقت سیستم‌ها در طول زمان

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

حلقه‌های بازخورد ساختاریافته ایجاد کنید. هر موردی را که مدل در آن اعتماد به نفس پایینی نشان می‌دهد یا اپراتورهای انسانی در آن مداخله می‌کنند، ثبت (log) کنید. از این لاگ‌ها برای بازآموزی یا تنظیم دقیق (fine-tune) دوره‌ای مدل استفاده کنید، اما هر به‌روزرسانی را از طریق همان دروازه‌های تضمینی که برای نسخه اصلی اعمال شده بود، اعتبارسنجی کنید. با به‌روزرسانی‌های مدل با همان احتیاطی برخورد کنید که در تعویض یک سیستم ترمز مکانیکی با یک طراحی جدید به کار می‌برید.

نتیجه‌گیری اصلی

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

برای بررسی فنی کامل راهنمای AMLAS، جزئیات اصلی را اینجا بخوانید: https://dev.to/paperium/guidance-on-the-assurance-of-machine-learning-in-autonomous-systems-amlas-f9

اگر می‌خواهید درباره استراتژی‌های تضمین کیفیت بحث کنید و نکات کاربردی را با جامعه‌ای که روی مشکلات مشابه کار می‌کند تبادل کنید، به گفتگو در اینجا بپیوندید: https://t.me/GyaanSetuAi