سامانه ممکن است بدون خطای فنی کار کند و در عین حال پاسخهای کمکیفیتتری بدهد. سالمبودن سرور، معادل سالمماندن کاربرد نیست.
سه نوع تغییر
نسخهٔ مدل یا تنظیمات ممکن است عوض شود. دادهٔ ورودی میتواند از نظر کیفیت یا جمعیت تغییر کند. کاربران نیز ممکن است از ابزار برای کاری فراتر از هدف اولیه استفاده کنند. برای فهم افت عملکرد، این تغییرها باید قابل ردیابی باشند.
چارچوب NIST؛ چارچوب مدیریت ریسک هوش مصنوعی ریسک را موضوعی در طول چرخهٔ استفاده میبیند. پیشنهاد اجرایی این نوشته، دفتر تغییرات و مجموعهٔ آزمون ثابت برای بررسی نسخههاست.
نمونهٔ کنترل نسخه
در یک پروژهٔ فرضی، مجموعهای از نمونههای نماینده با موارد دشوار و پاسخهای مرجع نگه داشته میشود. پیش از تغییر نسخه، خروجی جدید و قبلی روی همان موارد مقایسه میشوند. این آزمون همهٔ وضعیتهای واقعی را پوشش نمیدهد، اما بعضی پسرفتها را پیش از انتشار نشان میدهد.
خطاهای تازهٔ واقعی نیز میتوانند پس از بررسی به مجموعهٔ آزمون اضافه شوند. مراقب باشید مجموعهٔ آزمون فقط از موارد آسان یا فقط از خطاهای شناختهشده تشکیل نشود.
پایش قابل اقدام
برای هر شاخص، مسئول و واکنش تعریف کنید. اگر خطا افزایش یافت، چه کسی بررسی میکند و چه زمانی استفاده محدود میشود؟ نرخ پاسخگویی، زمان بازبینی، نوع خطا و شکایت کاربر اطلاعات متفاوتی میدهند.
گزارش دورهای باید تغییرهای اعمالشده و علت تصمیم را نگه دارد. بدون این سابقه، بازگشت به نسخهٔ قبلی یا فهم علت یک مشکل دشوار میشود؛ حتی اگر نمودار دسترسپذیری سرویس همیشه سبز باشد.
منابع این یادداشت
- NIST؛ چارچوب مدیریت ریسک هوش مصنوعی www.nist.gov
- FDA؛ شفافیت ابزارهای پزشکی مبتنی بر یادگیری ماشین www.fda.gov
دکتر میلاد جلالی
بنیانگذار ریسرچ ادیتور و محتوانگار. کار من به پژوهش، آموزش هوش مصنوعی و برندینگ پزشکی متصل است.
رزومه و سوابق ↖پروژهها ↖
