آیا تخصص در انتخاب یک cnn برای دیتاست خودمون لازم هست ؟

Question

سلام عرض ادب
دوستان فرضا من یک دیتاستی دارم مثلا دیتاست سگ و گربه یا انواع گیاهان یا هر دیتاست دیگه ایی که خودم تهیه کردم.
فرض کنید الان SOTA کلاسیفیکشن مثلا معماری x میباشد روی امیج نت . و بنده هم به عنوان application به قضیه نگاه میکنم در واقع فقط استفاده کننده از معماری های پیش آموزش دیده شده هستم.
سوالم این هست که آیا واقعا باید در انتخاب cnn برای دیتاست خودمون باید تجربه و تخصص خاصی داشته باشیم اینکه چه cnn ایی برای فلان دیتاست یا فلان کلاس بندی ها مناسب هست ؟ یعنی اینکه ممکن هست الان یک cnn ایی که sota امیج نت هست و نسبت به یک cnn ایی که sota فرضا سال 2016 بود بدتر عمل کند برای دیتاست خودمون ؟
سوال دوم : فرضا یکی از این cnn ها برای دیتاست خودمون انتخاب شد آیا باز هم نیازی هست در انتخاب optimizer ها نیز تخصص داشته باشیم ؟ یعنی اینکه فلان optimizer ممکن هست برای فلان دیتاستی که نوعش فلانه خوب کار کند ؟ یا اینکه نه optimizer که برای یک cnn انتخاب شده در واقع بهترین گزینه مخصوص اون cnn می باشد ؟
کلا منظورم اینکه موقع ایی که بصورت application از cnn استفاده میشه باید در انتخاب cnn و optimizer و ... هم حرفه داشته باشیم یا اینکه sota کلاسیفیکشن روی امیج نت با مشخصاتی که داره بهترین گزینه برای هر دیتاستی هست سوا از اینکه چقدر پارامتر داره چقدر فضا اشغال میکنه و اینکه زمان predication اش چقدر باشد فقط تنها ملاک ما دقت باشد.

Answer 1

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

Comments

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

---

سلام
اول در مورد کسایی که معماری طراحی میکنن. اینطور نیست که اونها معماری رو بر اساس ایمیج نت طراحی کنن. اونها یک طرح و ایده رو پیاده میکنن و اول از نظر مفهومی چک میکنن وقتی اکی بود یه فاز کوچیک تست مییگرن اکی بود حالا میرن رو ایمیج نت. بعد برای ایمیج نت "تنظیم"ش میکنن. اگه کامنت قبلی دقت کنی نوشتم مثلا معماری دنزنت هم تو ایمیجنت هم تو سیفار۱۰ خیلی عالی کار میکنه. چون مفهومی که استفاده کرده خیلی خوب داره جواب میده. اما قرار نیست معماری ای که مختص گرفتن بهترین نتیجه رو ایمیج نت ساخته شده بدون تغییر برای کاربرد دیگه ای انتظار داشته باشیه "بهترین" خروجی یا بهینه ترینش رو بده . خیلی از معماری ها رو حساب سعی و خطا بدست اومدن. اما وقتی شما زیاد کار کنی به یه دانش یا بهتر بگم به شهود عینی میرسی از اینکه چه اتفاقی داره رخ میده مشکل چیه و چطور برای رفع اون مشکل باید حرکت کرد. خیلی از معماری های جدید از این جهت بوجود اومدن و محققایی که پشتشون هستن آدمهای با تجربه و با دانشی هستن. و اینم بگم هنوز خیلی کارهای دیگه مونده که کسی نکرده چون همه افراد دسترسی به سخت افزار خوب ندارن. من میتونم به یقین بگم شما بعنوان مثال اگه یه سخت افزار یا زیرساخت مناسب داشته باشی و بشینی همینطور ترین کنی (البته نه بی هدف) کم کم به تمامی مواردی که در  مقاله های گوگل نت و رزنت و... اومده میرسی . یک سیر طبیعی هست. پس این یک نکته که هر دو حالت رو داریم.

یک نکته دیگه اینه که همیشه همه مفاهیم رو این اصل استوار نیست که هر لایه از حداکثر توانش استفاده کنه! هرچند این دلخواه ماست اما همه ایده ها حول این قضیه نیست. تو قضیه ترین شبکه ها مشکلات مختلفی هست. خیلی از ایده ها در درجه اول برداشتن و یا برطرف کردن یه مشکله یا حداقل کم کردن اون! وقتی یک مشکل حل بشه میبینیم بهبود داریم. برای همین بعضی مشکلها همه جا یا وجود ندارن یا خیلی bold‌ نیستن و اینجاس که اون "مفهوم" دیگه مثل قبل بهبودی رو حاصل نمیکنه و چه بسا خودش یکسری داستان اضافه کنه که عطاش رو بشه به لقاش بخشید (هر راه حلی ممکنه یکسری سربار یا مشکل جدید اضافه کنه که تو بعضی حالتها مشکلی نباشه و به چشم نیاد یا بیاد اما قابل توجیه باشه اما در حالات دیگه برعکس بشه قضیه) برای همین دونستن این قضیه میتونه خیلی کمک کنه بما که ببینم هدف چی بوده و ما چطور میتونیم بهره خودمون رو ببریم (سوای پیاده سازی اونها)

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

در مورد بخش دوم آفرین یه نکته مهم همینه دقیقا که یه دیتاست بزرگتر نیازهاش فرق میکنه و دقیقا یه بحث اورفیتینگ و... هست. برای همین میبینیم که نیاز به تنظیمات خیلی مهمه. یک معماری اگه بر مبنای درستی طراحی و بدرستی هم پیاده سازی بشه باید بتونه در سناریوهای مختلف بخوبی عمل بکنه. بعضی موارد در دیتاست های کوچیکتر صادق نیستن و دقیقا به مشکلاتی که گفتی بر میخورن. شما قصد داری یک راه حل ارایه کنی. اگر قرار باشه معماری انتخاب بشه که روی دیتاست های کوچیک خوب کار نکنه اون بدرد نمیخوره. حتی اگه استیت او در ارت ایمیج نت یا گنده تر از اونو داشته باشه. اگر بگیم بخاطر اورفیتینگ هست باید یک مدل کوچکتر مناسب اون دیتاست جدید طراحی بشه اگر باز این مشکل باشه نشونگر غیربهینه بودن اون معماریه برای اون کاربرد مورد نظر.
اینجا بحث قیاس بین بهتر بودن یا بدتر بودن یه معماری نسبت به اون یکی نیست. این بین شاید بنظر نیاد اما خیلی داستان هست. من اینو در جواب شما گفتم که چطوری میشه یه معماری یه جا خوب کار کنه یه جا نه. و اینکه نیاز به تنظیم داریم اخر یا نه. ربطی به بحث نداره اما SimpleNet هیچوقت بطور واقعی رو ایمیج نت مثل رزنت ترین نشد (نه با همون پیش پردازش ها و نه حتی با تعداد پارامترهای مشابه) برای همین من مطرحش نکردم. در قیاسش با سیفار۱۰ هم از نظر تعداد پارامتر و سربار پردازشی مساوی با فاصله زیاد رزنت و wrn‌ و...رو پشت سر گذاشته (البته نسخه دومش) که نشونگر اینه بیسی که معماری مبتنی بر اون هست صحیح بوده. آیا در دیتاست های بزرگتر به همین خوبیه؟‌ بستگی به تنظیم و تست داره تا مشخص بشه)

در مورد بحث سادگی معماری باید دقت کنی این هیچ ربطی به بهتر یا بدتر بودن نداره که چون یک معماری ساده است پتانسیلش رو نداره. یک نمونه خوب همین مواردی بود که صحبت کردیم تو سیفار10/100 (با تعداد پارامتر یکسان و یا متفاوت معماری پیچیده تر(مثل رزنت ) از یه معماری ساده تر تو یه دیتاست کوچیک بدتر عمل میکنه.) یک نمونه تو زمینه ایمیج نت معماری موبایل نت هست که طرح بسیار ساده ای داره و دقت بسیار خوبی ارایه میکنه و بسیار بهینه اس.
حالا بخش اول فرمایش شما:‌درسته نمیشه رو همه چیز تست کرد. اما باید به اندازه کافی تست داشت. معماری های مختلفی بیرون هست که رو دیتاست های مختلفی ترین و تست شدن میشه با نگاه کردن به اونها دید یک معماری (بهتره بگیم یه مفهوم جدید که پیاده سازی شده ) در حالتهای نزدیک به کاربرد ما چطوری کار میکنن.
مثلا اگه من دیتاستم کوچیکه میرم ببینم یک معماری که انتخاب کردم (مثلا دنزنت) علاوه بر نتایج عالیش ایا رودیتاست های کوچیک هم خوب کار میکنه؟ میبینم اره!‌ پس این انتخاب منه. و میرم رو تست و تنظیمش برای کار خودم.
نکته بعدی سوال کردن از بقیه اس. این باعث میشه کسی اطلاع و یا تجربه ای داشته باشه بتونه بهتر معرفی کنه.
نکته اخر هم اینکه بعد مدتی شما تجربه بدست میاری و وقتی یک مقاله میخونی متوجه میشی کانسپتش چقدر پتانسیل داره خوبه یا نه و اگه خوبه میشینی خودت بر اون اساس طراحی میکنی و یه یه معماری خاص منظوره خیلی خوب پیاده میکنی.

---

ممنون از شما