مشکلات استفاده از دو فیلتر 2*2 بجای یک فیلتر 3*3 و استفاده از فیلترهای نامتقارن چیست؟

Question

با سلام
در ورژن 3 google-net مبحث استفاده 2 تا 2*2 بجای یک 3*3 چه مشکلاتی را به دنبال داره؟
شبکه دچار گرسنگی پردازشی میشه یعنی چی؟
مشکلی به نام PLD در این مبحث یعنی چه؟

مشکل استفاده از فیلترهای نامتقارن که سربار پردازشی رو خوب کم میکنن چیه؟ و اگر تعداد عملیات اعشاری یک شبکه زیاد باشه چه اتفاقی میفته؟
متشکرم

Answer 1

سلام .
یک بحث این بود که خب هر فیلتر بزرگتر رو با چند فیلتر کوچکتر جایگزین کنیم . دیدیم این مبحث روی فیلترهای 5در5 و 7در7 با 3در3 بخوبی جواب داده. بعد مطرح میشه خود 3در3 رو آیا با یه فیلتر کوچکتر میشه جایگزین کرد یا نه . جواب بله بود.
به دو صورت میشد این کارو کرد . 1. با دوتا فیلتر 2در2 و یا فیلتر نامتقارن 1در3 و 3در1 . از بین این دوتا دیدیم که گزینه دوم سربار کمتری داشت در نتیجه توسط مقاله این پیشنهاد شد.
بعدا ما گفتیم که هرچند این صحیحه اما اعمال این قضیه در سراسر شبکه خوب نیست چون عمق شبکه رو حداقل دو برابر میکنه (اگر فیلترپایه 3در3 باشه) و وقتی عمق شبکه افزایش پیدا کنه و بودجه پردازشی ما محدود باشه با مشکل PLD یا گرسنگی پردازشی در سطح لایه ها مواجه میشیم و نیاز به افزایش بودجه هست. از طرفی گفتیم وقتی قرار به افزایش بودجه پردازشی باشه اولین کار و بهترین کار اینه که اون رو در معماری فعلی لحاظ کنیم و عموما این باعث دقت بهتری میشه خصوصا اگه بصورت تدریجی شبکه رو طراحی کرده باشیم .
از طرف دیگه عمق زیاد بحث دیگردیشن رو داره که در رزنت دیدیم چه راه حلی ارائه شد براش و یا بعدش دنزنت رو داشتیم
و به همین صورت برای اینکه یک مقدار بهینه سربار و دقت رو داشته باشیم بهتره که از مواردی که باعث میشه اون بحث توسعه تدریجی خدشه دار بشه پرهیز کنیم .
باز از همه اینها گذشته دیدیم که کورولیشن در شبکه حائز اهمیت هست و هرچند فاصله بین 2در2 و 3در3 نسبت به فاصله اون با 1در1 کمتر هست ولی باز 3در3 بهتر بوده و از نظر بهینه سازی ها هم 3در3 سرعت بهتری رو ارائه میکنه
در مورد فیلترهای نا متقارن هم تاثیر اونها در شبکه های چند مسیره تا بحال تست شده و در حالتهای معمول بخوبی روش بحث نشده . هرچند در مقاله های قبلی گفته شده دقتشون مناسبه اما نسبت به حالت متقارن چیزی که من تا بحال دیدم همیشه کمتر بوده که میشه به اون بحث کورولیشن مرتبطش کرد .
دقت کنید که بحث این نبوده که اینها استفاده نشن بحث این بوده که ایا "همه جا" اینطور باشه یا نه و بحث های مرتبط با کورولیشن چطور بوده و کدوم حالت بهترین دقت رو بعنوان مثال ارائه میکنه (سوای سربار و...) تا اینطور فرد به یک شهودی برسه تا در زمان طراحی با دلیل و شهود کافی از هر تکنیکی به فراخور مساله استفاده کنه.
عملیات اعشاری زیاد باشه یعنی پردازنده بیشتر مشغول میشه یعنی latency بالاتر میره یعنی بیشتر طول میکشه یک کار انجام بشه برای همین ایده آل ما اینه که یک کار در سریعترین زمان ممکن انجام بشه یعنی کمترین میزان سربار پردازشی رو داشته باشه.

Comments

سلام
خیلی ممنون آقای مهندس
فقط یه سوال برام پیش اومد اینکه فرمودید  از مواردی که باعث میشه اون بحث توسعه تدریجی خدشه دار بشه پرهیز کنیم . مثلا چه مواردی و استفاده از فیلترهای نامتقارن که منجر به عمق زیاد و پیش آمدن مساله کاهش دقت آموزشی میشن با ایده ایی مثل بلوک های رزنت برای تقریب تابع همانی برای لایه بهینه به بعد چه مشکلی بوجود میاره که میفرمایید  از مواردی که باعث میشه اون بحث توسعه تدریجی خدشه دار بشه پرهیز کنیم؟
متشکرم

---

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

---

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

---

سلام. simplenet توضیح زیادی نداره خیلی خلاصه فقط گفتم اونجا. توضیحات اصلی که تو کارگاه ارائه شد مربوط به مقاله جدید ما بود تحت عنوان  Toward principled design of deep convolutional networks که فعلا تحت ریویو ایمیج ترنزکشن هست. البته ما دو سه هفته دیگه به احتمال خیلی زیاد تو ارکایو سابمیتش کنیم اونوقت میتونید مقاله اصلی رو بخونید و بله اونجا توضیح زیاد داده شده.