آزمایشها یک پروژه را به سمت دوام میآورند. آنها فرضیه هایی قابل آزمایش و تکرار هستند. هنگام اجرای آزمایشها، هدف این است که با ارزیابی انواع معماریها و ویژگیهای مدل، بهبودهای مستمر و تدریجی ایجاد کنیم. هنگام آزمایش، می خواهید کارهای زیر را انجام دهید:
عملکرد پایه را تعیین کنید. با ایجاد یک متریک پایه شروع کنید. خط مبنا به عنوان یک چوب اندازه گیری برای مقایسه آزمایش ها با آن عمل می کند.
در برخی موارد، راه حل غیر ML کنونی می تواند اولین متریک پایه را ارائه دهد. اگر در حال حاضر راه حلی وجود ندارد، یک مدل ML با معماری ساده، چند ویژگی ایجاد کنید و از معیارهای آن به عنوان خط پایه استفاده کنید.
تغییرات کوچک و تکی ایجاد کنید. در هر زمان فقط یک تغییر کوچک ایجاد کنید، به عنوان مثال، در هایپرپارامترها، معماری یا ویژگی ها. اگر تغییر مدل را بهبود بخشد، معیارهای آن مدل به خط پایه جدیدی برای مقایسه آزمایشهای آینده تبدیل میشوند.
در زیر نمونههایی از آزمایشهایی هستند که یک تغییر کوچک ایجاد میکنند:
- شامل ویژگی X باشد.
- از 0.5 dropout در اولین لایه پنهان استفاده کنید.
- تبدیل log ویژگی Y را بگیرید.
- نرخ یادگیری را به 0.001 تغییر دهید.
پیشرفت آزمایش ها را ثبت کنید. به احتمال زیاد باید آزمایش های زیادی انجام دهید. آزمایشهایی با کیفیت پیشبینی ضعیف (یا خنثی) در مقایسه با خط پایه هنوز برای ردیابی مفید هستند. آنها سیگنال می دهند که کدام رویکرد کار نمی کند. از آنجایی که پیشرفت معمولاً غیرخطی است، مهم است که نشان دهید با برجسته کردن همه راههایی که یافتید که کار نمیکنند - علاوه بر پیشرفت در افزایش کیفیت پایه، روی مشکل کار میکنید.
از آنجایی که هر آموزش کامل روی یک مجموعه داده دنیای واقعی میتواند ساعتها (یا روزها) طول بکشد، آزمایشهای مستقل متعددی را به صورت همزمان اجرا کنید تا فضا را سریع کشف کنید. همانطور که به تکرار ادامه می دهید، امیدواریم به سطح کیفیتی که برای تولید نیاز دارید نزدیکتر و نزدیکتر شوید.
نویز در نتایج تجربی
توجه داشته باشید که ممکن است در نتایج تجربی با نویزهایی روبرو شوید که ناشی از تغییرات مدل یا دادهها نیست، که تعیین اینکه آیا تغییری که انجام دادهاید واقعاً مدل را بهبود داده است یا خیر، دشوار است. موارد زیر نمونه هایی از چیزهایی هستند که می توانند در نتایج تجربی نویز ایجاد کنند:
ترکیب داده ها: ترتیب ارائه داده ها به مدل می تواند بر عملکرد مدل تأثیر بگذارد.
مقداردهی اولیه متغیر: نحوه مقداردهی اولیه متغیرهای مدل نیز می تواند بر عملکرد آن تأثیر بگذارد.
موازی سازی ناهمزمان: اگر مدل با استفاده از موازی سازی ناهمزمان آموزش داده شود، ترتیب به روز رسانی قسمت های مختلف مدل نیز می تواند بر عملکرد آن تأثیر بگذارد.
مجموعههای ارزیابی کوچک: اگر مجموعه ارزیابی خیلی کوچک باشد، ممکن است نشاندهنده عملکرد کلی مدل نباشد و تغییرات ناهمواری در کیفیت مدل ایجاد کند.
اجرای چندین بار آزمایش به تأیید نتایج آزمایشی کمک می کند.
مطابق با شیوه های آزمایشی
تیم شما باید با مجموعهای از شیوهها و مصنوعات، درک روشنی از چیستی «آزمایش» داشته باشد. شما اسنادی می خواهید که موارد زیر را مشخص کند:
مصنوعات. مصنوعات یک آزمایش چیست؟ در بیشتر موارد، یک آزمایش یک فرضیه آزمایش شده است که می تواند بازتولید شود، معمولاً با ثبت فراداده (مانند ویژگی ها و فراپارامترها) که نشان دهنده تغییرات بین آزمایش ها و نحوه تأثیر آنها بر کیفیت مدل است.
شیوه های کدنویسی آیا همه از محیط های آزمایشی خود استفاده خواهند کرد؟ متحد کردن کار همه در کتابخانه های مشترک چقدر ممکن (یا آسان) خواهد بود؟
تکرارپذیری و ردیابی استانداردهای تکرارپذیری چیست؟ به عنوان مثال، آیا تیم باید از همان شیوههای خط لوله داده و نسخهسازی استفاده کند، یا اینکه فقط نمودارها را نشان میدهد خوب است؟ چگونه داده های تجربی ذخیره می شوند: به عنوان پرس و جوهای SQL یا به عنوان عکس های فوری مدل؟ گزارشهای مربوط به هر آزمایش کجا مستند میشوند: در یک سند، یک صفحه گسترده یا یک CMS برای مدیریت آزمایشها؟
پیش بینی های اشتباه
هیچ مدل دنیای واقعی کامل نیست. سیستم شما چگونه پیش بینی های اشتباه را مدیریت می کند؟ از همان ابتدا در مورد نحوه برخورد با آنها فکر کنید.
یک استراتژی بهترین عملکرد، کاربران را تشویق می کند تا به درستی پیش بینی های اشتباه را برچسب گذاری کنند. به عنوان مثال، برنامههای ایمیل، ایمیلهای طبقهبندیشده اشتباه را با ورود کاربران ایمیل به پوشه هرزنامه خود و همچنین برعکس، ضبط میکنند. با گرفتن برچسب های حقیقت زمینی از کاربران، می توانید حلقه های بازخورد خودکار برای جمع آوری داده ها و بازآموزی مدل طراحی کنید.
توجه داشته باشید که اگرچه نظرسنجیهای تعبیهشده با رابط کاربری بازخورد کاربر را دریافت میکنند، دادهها معمولاً کیفی هستند و نمیتوانند در دادههای آموزش مجدد گنجانده شوند.
یک راه حل انتها به انتها را اجرا کنید
در حالی که تیم شما در حال آزمایش بر روی مدل است، ایده خوبی است که شروع به ساخت بخش هایی از خط لوله نهایی کنید (اگر منابع لازم برای انجام این کار را دارید).
ایجاد قطعات مختلف خط لوله - مانند دریافت داده و بازآموزی مدل - انتقال مدل نهایی به تولید را آسانتر میکند. به عنوان مثال، دریافت یک خط لوله سرتاسر برای دریافت داده ها و ارائه پیش بینی ها می تواند به تیم کمک کند تا مدل را در محصول ادغام کرده و آزمایش کاربر در مراحل اولیه را آغاز کند.
عیب یابی پروژه های متوقف شده
ممکن است در سناریوهایی باشید که پیشرفت یک پروژه متوقف شود. شاید تیم شما روی یک آزمایش امیدوارکننده کار کرده باشد اما هفتهها در بهبود مدل موفق نبوده است. چه کاری باید انجام دهید؟ در زیر برخی از رویکردهای ممکن وجود دارد:
راهبردی. ممکن است لازم باشد مشکل را دوباره قالب بندی کنید. پس از گذراندن زمان در مرحله آزمایش، احتمالاً مشکل، داده ها و راه حل های ممکن را بهتر درک می کنید. با دانش عمیق تر از دامنه، احتمالاً می توانید مشکل را با دقت بیشتری چارچوب بندی کنید.
به عنوان مثال، شاید در ابتدا می خواستید از رگرسیون خطی برای پیش بینی یک مقدار عددی استفاده کنید. متأسفانه، داده ها برای آموزش یک مدل رگرسیون خطی قابل دوام به اندازه کافی خوب نبودند. شاید تجزیه و تحلیل بیشتر نشان دهد که می توان با پیش بینی اینکه آیا یک مثال بالاتر یا پایین تر از یک مقدار خاص است، مشکل را حل کرد. این به شما امکان میدهد مشکل را به عنوان یک طبقهبندی باینری مجدداً قاب بندی کنید.
اگر پیشرفت کندتر از حد انتظار است، تسلیم نشوید. بهبودهای تدریجی در طول زمان ممکن است تنها راه حل مشکل باشد. همانطور که قبلاً ذکر شد، انتظار نداشته باشید که میزان پیشرفت هفته در طول هفته یکسان باشد. اغلب، تهیه یک نسخه آماده برای تولید یک مدل به زمان زیادی نیاز دارد. بهبود مدل می تواند نامنظم و غیرقابل پیش بینی باشد. دورههای پیشرفت آهسته را میتوان با افزایشهایی در بهبود یا برعکس دنبال کرد.
فنی. زمانی را صرف تشخیص و تجزیه و تحلیل پیش بینی های اشتباه کنید. در برخی موارد، میتوانید با جداسازی چند پیشبینی اشتباه و تشخیص رفتار مدل در آن موارد، مشکل را پیدا کنید. برای مثال، ممکن است مشکلاتی را در معماری یا داده ها کشف کنید. در موارد دیگر، دریافت داده های بیشتر می تواند کمک کننده باشد. ممکن است سیگنال واضحتری دریافت کنید که نشان میدهد در مسیر درستی قرار گرفتهاید، یا ممکن است نویز بیشتری تولید کند که نشان میدهد مشکلات دیگری در این رویکرد وجود دارد.
اگر روی مشکلی کار میکنید که به مجموعه دادههای برچسبگذاری شده توسط انسان نیاز دارد، ممکن است بدست آوردن یک مجموعه داده برچسبدار برای ارزیابی مدل دشوار باشد. منابعی را برای دریافت مجموعه داده هایی که برای ارزیابی نیاز دارید، بیابید.
شاید هیچ راه حلی ممکن نباشد. رویکرد خود را در جعبه زمان تنظیم کنید، اگر در بازه زمانی پیشرفت نکرده اید، متوقف شوید. با این حال، اگر یک بیانیه مشکل قوی دارید، احتمالاً راه حل را تضمین می کند.