تبریک می گویم! شما مدل یونیکورن را به کار گرفته اید. مدل شما باید 24x7 بدون هیچ مشکلی اجرا شود. برای اطمینان از این کار، باید خط لوله یادگیری ماشینی (ML) خود را نظارت کنید.
یک طرح داده بنویسید تا داده های خام را تأیید کند
برای نظارت بر داده های خود، باید به طور مداوم آن ها را در برابر مقادیر آماری مورد انتظار با نوشتن قوانینی که داده ها باید رعایت کنند، بررسی کنید. به این مجموعه قوانین ، طرح واره داده می گویند. با دنبال کردن مراحل زیر یک طرح داده را تعریف کنید:
دامنه و توزیع ویژگی های خود را درک کنید. برای ویژگی های طبقه بندی شده، مجموعه مقادیر ممکن را درک کنید.
درک خود را در طرح داده رمزگذاری کنید. در زیر نمونه هایی از قوانین آمده است:
- اطمینان حاصل کنید که رتبه‌بندی‌های ارسالی توسط کاربر همیشه در محدوده 1 تا 5 باشد.
- بررسی کنید که کلمه the بیشترین استفاده را داشته باشد (برای یک ویژگی متن انگلیسی).
- بررسی کنید که هر یک از ویژگی‌های دسته‌بندی به مقداری از مجموعه ثابتی از مقادیر ممکن تنظیم شده باشد.
داده های خود را در برابر طرح داده آزمایش کنید. طرح شما باید خطاهای داده ای مانند:
- ناهنجاری ها
- مقادیر غیرمنتظره متغیرهای طبقه بندی شده
- توزیع داده های غیرمنتظره
تست های واحد را برای تایید مهندسی ویژگی بنویسید
در حالی که داده‌های خام شما ممکن است از طرح داده عبور کند، مدل شما روی داده‌های خام آموزش نمی‌دهد. در عوض، مدل شما بر روی داده‌هایی که ویژگی‌های مهندسی شده‌اند آموزش می‌دهد. به عنوان مثال، مدل شما به جای داده‌های عددی خام، بر روی ویژگی‌های عددی نرمال‌شده تمرین می‌کند. از آنجایی که داده‌های مهندسی شده می‌توانند بسیار متفاوت از داده‌های ورودی خام باشند، باید داده‌های مهندسی ویژگی‌ها را جدا از بررسی‌های خود در داده‌های ورودی خام بررسی کنید.
تست های واحد را بر اساس درک خود از داده های مهندسی ویژگی بنویسید. به عنوان مثال، می توانید تست های واحد را برای بررسی شرایطی مانند موارد زیر بنویسید:
- همه ویژگی‌های عددی، به عنوان مثال، بین 0 و 1 مقیاس‌بندی می‌شوند.
- بردارهای کدگذاری شده یک داغ فقط حاوی صفرهای 1 و N-1 هستند.
- توزیع داده ها پس از تبدیل با انتظارات مطابقت دارد. به عنوان مثال، اگر با استفاده از Z-scores نرمال سازی کرده اید، میانگین امتیاز Z باید 0 باشد.
- موارد پرت مانند پوسته پوسته شدن یا برش داده می شوند.
معیارها را برای برش های داده مهم بررسی کنید
یک کل موفق گاهی اوقات یک زیر مجموعه ناموفق را پنهان می کند. به عبارت دیگر، یک مدل با معیارهای کلی عالی هنوز ممکن است پیش بینی های وحشتناکی را برای موقعیت های خاص انجام دهد. به عنوان مثال:
مدل تک شاخ شما در کل عملکرد خوبی دارد، اما هنگام پیش‌بینی صحرای صحرا ضعیف عمل می‌کند.
اگر شما از آن دسته مهندس هایی هستید که از یک AUC عالی راضی هستید، ممکن است متوجه مشکلات مدل در صحرای صحرا نشوید. اگر پیش‌بینی خوب برای هر منطقه مهم است، باید عملکرد هر منطقه را دنبال کنید. به زیرمجموعه‌های داده‌ها، مانند داده‌های مربوط به صحرای صحرا، برش داده می‌گویند.
داده های مورد علاقه را شناسایی کنید. سپس معیارهای مدل را برای این برش های داده با معیارهای کل مجموعه داده خود مقایسه کنید. بررسی عملکرد خوب مدل شما در تمام برش‌های داده به حذف سوگیری کمک می‌کند. برای اطلاعات بیشتر به Fairness: Evaluating for Bias مراجعه کنید.
از معیارهای دنیای واقعی استفاده کنید
معیارهای مدل لزوماً تأثیر مدل شما را در دنیای واقعی اندازه گیری نمی کنند. به عنوان مثال، تغییر یک هایپرپارامتر ممکن است AUC یک مدل را افزایش دهد، اما این تغییر چگونه بر تجربه کاربر تأثیر گذاشت؟ برای اندازه‌گیری تأثیر دنیای واقعی، باید معیارهای جداگانه‌ای تعریف کنید. به عنوان مثال، می‌توانید از کاربران مدل خود نظرسنجی کنید تا تأیید کنید که در زمانی که مدل پیش‌بینی می‌کرد که آنها واقعاً یک تکشاخ را دیده‌اند.
چولگی در خدمت آموزش را بررسی کنید
انحراف ارائه آموزش به این معنی است که داده های ورودی شما در طول آموزش با داده های ورودی شما در ارائه متفاوت است. جدول زیر دو نوع مهم کج را توضیح می دهد:
| تایپ کنید | تعریف | مثال | راه حل |
|---|---|---|---|
| انحراف طرحواره | آموزش و ارائه داده های ورودی با طرح یکسانی مطابقت ندارد. | در حالی که مدل شما به آموزش بر روی داده های قدیمی ادامه می دهد، قالب یا توزیع داده های ارائه شده تغییر می کند. | از همین طرح برای اعتبارسنجی آموزش و ارائه داده ها استفاده کنید. اطمینان حاصل کنید که به طور جداگانه آماری را که توسط طرح شما بررسی نشده است، مانند کسری از مقادیر از دست رفته، بررسی کنید. |
| کج بودن ویژگی | داده های مهندسی شده بین آموزش و خدمت متفاوت است. | کد مهندسی ویژگی بین آموزش و سرویس دهی متفاوت است و داده های مهندسی متفاوتی تولید می کند. | مشابه انحراف طرحواره، قوانین آماری یکسانی را در آموزش و ارائه داده های مهندسی شده اعمال کنید. تعداد ویژگی‌های اریب شناسایی‌شده و نسبت نمونه‌های اریب به ازای هر ویژگی را ردیابی کنید. |
دلایل انحراف در سرویس آموزشی می تواند ظریف باشد. همیشه در نظر بگیرید که چه داده هایی در زمان پیش بینی در دسترس مدل شما هستند. در طول آموزش، فقط از ویژگی‌هایی استفاده کنید که هنگام سرویس در دسترس خواهید بود.
تمرین: درک خود را بررسی کنید
فرض کنید یک فروشگاه آنلاین دارید و می‌خواهید پیش‌بینی کنید که در یک روز چقدر درآمد خواهید داشت. هدف ML شما پیش بینی درآمد روزانه با استفاده از تعداد مشتریان به عنوان یک ویژگی است.
پاسخ: مشکل این است که شما در زمان پیش بینی، قبل از تکمیل فروش روز، تعداد مشتریان را نمی دانید. بنابراین، این ویژگی مفید نیست، حتی اگر این ویژگی به شدت درآمد روزانه شما را پیش بینی کند. به همین ترتیب، هنگامی که یک مدل را آموزش میدهید و معیارهای ارزیابی شگفتانگیزی را دریافت می‌کنید (مانند 0.99 AUC )، به دنبال این نوع ویژگی‌ها باشید که می‌توانند در برچسب شما نفوذ کنند.
نشتی برچسب را بررسی کنید
نشت برچسب به این معنی است که برچسب‌های حقیقت زمینی شما که می‌خواهید پیش‌بینی کنید، به طور ناخواسته وارد ویژگی‌های آموزشی شما شده‌اند. تشخیص نشت برچسب گاهی اوقات بسیار دشوار است.
تمرین: درک خود را بررسی کنید
فرض کنید شما یک مدل طبقه بندی باینری برای پیش بینی اینکه آیا یک بیمار جدید در بیمارستان سرطان دارد یا خیر، ساخته اید. مدل شما از ویژگی هایی مانند موارد زیر استفاده می کند:
- سن بیمار
- جنسیت بیمار
- شرایط پزشکی قبلی
- نام بیمارستان
- علائم حیاتی
- نتایج آزمون
- وراثت
برچسب به شرح زیر است:
- بولی: آیا بیمار سرطان دارد؟
شما داده ها را با دقت تقسیم بندی می کنید و مطمئن می شوید که مجموعه آموزشی شما به خوبی از مجموعه اعتبار سنجی و مجموعه آزمایشی شما جدا شده است. این مدل در مجموعه اعتبار سنجی و مجموعه تست بسیار خوب عمل می کند. معیارها فوق العاده هستند متأسفانه، این مدل در دنیای واقعی روی بیماران جدید عملکرد وحشتناکی دارد.
پاسخ: یکی از ویژگی های مدل نام بیمارستان است. بیمارستان های خاصی در درمان سرطان تخصص دارند. در طول آموزش، مدل به سرعت متوجه شد که بیمارانی که در بیمارستانهای خاصی منصوب می‌شوند به احتمال زیاد سرطان دارند. بنابراین، نام بیمارستان به یک ویژگی بسیار سنگین تبدیل شد.
در زمان استنباط، اکثر بیماران هنوز به یک بیمارستان اختصاص داده نشده بودند. به هر حال، هدف این مدل تشخیص وجود یا عدم وجود سرطان و سپس استفاده از آن تشخیص برای اختصاص بیمار به بیمارستان مناسب بود. در نتیجه، در طول استنباط، ویژگی نام بیمارستان هنوز در دسترس نبود و مدل مجبور شد بر ویژگی‌های دیگر تکیه کند.
پایش سن مدل در سراسر خط لوله
اگر داده‌های ارائه‌شده با گذشت زمان تکامل می‌یابند اما مدل شما مرتباً آموزش داده نمی‌شود، در این صورت شاهد کاهش کیفیت مدل خواهید بود. زمان از زمانی که مدل بر روی داده های جدید آموزش داده شد را پیگیری کنید و یک سن آستانه برای هشدارها تعیین کنید. علاوه بر نظارت بر سن مدل در هنگام خدمت، شما باید سن مدل را در سراسر خط لوله کنترل کنید تا غرفه های خط لوله را بگیرید.
تست کنید که وزن‌ها و خروجی‌های مدل از نظر عددی پایدار هستند
در طول تمرین مدل، وزنه ها و خروجی های لایه شما نباید NaN (نه یک عدد) یا Inf (بی نهایت) باشد. تست هایی بنویسید تا مقادیر NaN و Inf وزن ها و خروجی های لایه خود را بررسی کنید. علاوه بر این، آزمایش کنید که بیش از نیمی از خروجی های یک لایه صفر نباشد.
نظارت بر عملکرد مدل
پیش بینی کننده ظاهر تکشاخ شما بیش از حد انتظار محبوب بوده است! شما درخواست های پیش بینی زیادی و حتی داده های آموزشی بیشتری دریافت می کنید. فکر می کنید این عالی است تا زمانی که متوجه شوید که مدل شما حافظه و زمان بیشتری برای آموزش می گیرد. شما تصمیم می گیرید با دنبال کردن این مراحل عملکرد مدل خود را زیر نظر بگیرید:
- عملکرد مدل را بر اساس نسخه‌های کد، مدل و داده ردیابی کنید. چنین ردیابی به شما امکان می دهد علت دقیق هر گونه کاهش عملکرد را مشخص کنید.
- مراحل آموزش را در هر ثانیه برای نسخه مدل جدید در برابر نسخه قبلی و در برابر یک آستانه ثابت آزمایش کنید.
- با تعیین آستانه ای برای استفاده از حافظه، نشت حافظه را برطرف کنید.
- زمان‌های پاسخ API را نظارت کنید و صدک‌های آنها را ردیابی کنید. در حالی که زمان پاسخ API ممکن است خارج از کنترل شما باشد، پاسخ‌های آهسته به طور بالقوه می‌توانند معیارهای ضعیفی در دنیای واقعی ایجاد کنند.
- بر تعداد سوالات پاسخ داده شده در هر ثانیه نظارت کنید.
کیفیت مدل زنده را روی داده های ارائه شده آزمایش کنید
شما مدل خود را تایید کرده اید. اما اگر سناریوهای دنیای واقعی، مانند رفتار تک شاخ، پس از ثبت اطلاعات اعتبارسنجی شما تغییر کند، چه؟ سپس کیفیت مدل ارائه شده شما کاهش می یابد. با این حال، آزمایش کیفیت در ارائه خدمات سخت است زیرا داده های دنیای واقعی همیشه برچسب گذاری نمی شوند. اگر داده‌های ارائه‌شده شما برچسب‌گذاری نشده‌اند، این آزمایش‌ها را در نظر بگیرید:
مدل هایی را بررسی کنید که سوگیری آماری قابل توجهی در پیش بینی ها نشان می دهند. به طبقه بندی: تعصب پیش بینی مراجعه کنید.
معیارهای دنیای واقعی را برای مدل خود دنبال کنید. برای مثال، اگر هرزنامه ها را طبقه بندی می کنید، پیش بینی های خود را با هرزنامه های گزارش شده توسط کاربر مقایسه کنید.
اختلاف احتمالی بین آموزش و ارائه داده ها را با ارائه یک نسخه مدل جدید بر روی کسری از درخواست های خود کاهش دهید. همانطور که مدل سرویس جدید خود را تأیید می‌کنید، به تدریج همه درخواست‌ها را به نسخه جدید تغییر دهید.
با استفاده از این تست‌ها، به یاد داشته باشید که کاهش ناگهانی و آهسته کیفیت پیش‌بینی را کنترل کنید.
تصادفی سازی
خط لوله تولید داده خود را قابل تکرار کنید. فرض کنید می‌خواهید یک ویژگی اضافه کنید تا ببینید چگونه بر کیفیت مدل تأثیر می‌گذارد. برای یک آزمایش منصفانه، مجموعه داده های شما باید به جز این ویژگی جدید یکسان باشد. با این روح، مطمئن شوید که هر گونه تصادفی سازی در تولید داده را می توان قطعی کرد:
- مولدهای اعداد تصادفی (RNG) خود را بکارید . Seding تضمین می‌کند که RNG هر بار که آن را اجرا می‌کنید مقادیر یکسانی را با همان ترتیب خروجی می‌دهد و مجموعه داده شما را دوباره ایجاد می‌کند.
- از کلیدهای هش ثابت استفاده کنید. هش کردن یک روش متداول برای تقسیم یا نمونه برداری از داده ها است. می توانید هر مثال را هش کنید و از عدد صحیح به دست آمده برای تصمیم گیری در مورد تقسیم مثال استفاده کنید. هر بار که برنامه تولید داده را اجرا می کنید، ورودی های تابع هش شما نباید تغییر کند. برای مثال، اگر می‌خواهید هش‌های خود را در صورت تقاضا دوباره ایجاد کنید، از زمان فعلی یا یک عدد تصادفی در هش خود استفاده نکنید.
رویکردهای قبلی هم برای نمونه گیری و هم برای تقسیم داده های شما اعمال می شود.
ملاحظاتی برای هش کردن
دوباره تصور کنید که در حال جمع‌آوری عبارت‌های جستجو و استفاده از هش برای گنجاندن یا حذف عبارت‌ها هستید. اگر کلید هش فقط از پرس و جو استفاده می کرد، در طول چند روز داده، یا همیشه آن عبارت را درج می کنید یا همیشه آن را حذف می کنید. همیشه شامل کردن یا حذف کردن یک پرس و جو بد است زیرا:
- مجموعه آموزشی شما مجموعه ای از پرس و جوهای متنوع کمتری را مشاهده می کند.
- مجموعه های ارزیابی شما به طور مصنوعی سخت خواهند بود، زیرا با داده های آموزشی شما همپوشانی ندارند. در واقع، در زمان ارائه خدمات، مقداری از ترافیک زنده را در داده های آموزشی خود مشاهده خواهید کرد، بنابراین ارزیابی شما باید منعکس کننده آن باشد.
درعوض، می‌توانید در Query + date هش کنید، که منجر به هش متفاوتی در هر روز می‌شود.
