Transformer

یکی از لایه های پیچیده ای هست که درکش برای من مشکل بود.
به خاطر تفاوت زیادی که با لایه های قبلی مثل CNN و دیگر لایه ها داشت.

اما این ریسورس ها درکش رو برای من ساده تر کرد.

The Illustrated Transformer - Jay Alammar
Transformer Explainer

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

Attention Is All You Need

در ضمن. میدونستید که Transformer فقط برای text نیست؟

Vision Transformer
داخل این معماری ما با استفاده از یک لایه CNN تصویر رو به تکه های متعددی تبدیل میکنیم و Flatten میکنیم تا تبدیل به یه Sequence برای پاس دادن به Transformer بشه.

یکی از استفاده های باحالی از Transformer ها بود خارج از LLM.
و اتفاقا خودم دارم پیادش میکنم طبق این ریسورس.

معماری State of The Art هست و هر روز دارن راهی پیدا میکنن که بهترش کنن..

مقاله تحقیقاتی که این روش رو معرفی کرد:
An Image is Worth 16x16 Words: Transformers for Image Recognition at Scale

Vision Transformer Explained - Papers With Code

اشتباهات (Errata):
البته دقیق بخوایم بگیم SOTA نیست و paper جدید هم نیست (با سرعتی که داریم تو فیلد یادگیری عمیق جلو میریم) ولی معماری های بیس ViT هستن که در حال حاظر تو فیلد Classification بهترین عملکرد رو دارن.

SOTA = State of The Art
یعنی آخرین و بهترین ها تو هر حوزه ای

واسه اینکه ببینید چه مدل هایی بهترین هستن تو هر دیتاست و فیلد حتما وبسایت Paperswithcode رو سری بزنید.

بلاگ پستی که خیلی باهاش حال کردم.
مسیر یادگیری Machine Learning و Deep Learning اش رو برای همه ما به اشتراک گذاشته و منابع و ریفرنس های خیلی خوبی رو معرفی کرده که از کیفیت بالایی برخوردارن.

اگر دنبال منابع خوب و با کیفیت هستید حتما به این سری بزنید.

https://www.mrdbourke.com/ml-resources/

همینطور اینجا هم کلی منابع خوبی میشه پیدا کرد.

نکته: این پست رو Daniel Bourke زمانی ساخت که میخواست کامل از صفر شروع کنه و بدون دانشگاه Machine Learning و Deep Learning رو یاد بگیره نوشته.

یکسری آدما کلا اینطوری ان که همزمان که یاد میگیرن به اشتراک میزارن. خودمم همینطوری.

https://www.mrdbourke.com/aimastersdegree/

چالش برنامه نویسی Advent of Code از ۱ دسامبر شروع میشه.

یکی از چالش های خیلی معروف سالیانه هست که از سال ۲۰۱۵ شروع شده و برنامه نویسای زیادی توش شرکت میکنن.

تم کریسمسی داره.
چالش هایی که وجود داره از مهارت های مختلفی هست و توسط هر زبانی میتونه حل بشه.
داوطلب ها بر اساس سرعت تو رتبه بندی خصوصی و جهانی رده بندی میشن.

من خودم شرکت نکرده بودم و نمیدونم چطوری هست ولی قراره امسال شرکت کنم.
(چیز خیلی جدی نیست، فقط برای تفریح و تمرینه)

https://adventofcode.com/

روند های مختلف Loss curve و معنیشون.

تو اولی ما underfitting داریم. یعنی مدل ما الگو ها رو درست یاد نگرفته.

تو دومی overfitting داریم. یعنی مدل ما الگو ها رو حفظ کرده و سر همین تو train data خیلی خوب عمل میکنه.

سومی روند درست و معمولی هست.
تو حالت عادی باید train یکم بهتر از test عمل کنه.
اگر test بهتر از train عمل میکنه یعنی به اندازه کافی نگذاشتید train بشه.

تو اینجا لینک یکسری اطلاعات بیشتر راجب Loss curve ها هست.

تو پست بعدی راجب راه هایی برای فیکس کردن Overfitting صحبت میکنم.

راه های درست کردن Overfitting:

1. دیتای بیشتری جمع کنیم
2. بهبود داده
3. استفاده از انتقال یادگیری
4. مدل رو ساده تر کنیم
5. استفاده از learning rate decay
6. توقف زودهنگام

توضیحات هر کدوم از این روش ها:

1. دیتای بیشتری جمع کنیم: وقتی به اندازه کافی دیتا نداشته باشیم مدل نمیتونه الگویی از این دیتا ها استخراج کنه تا بتونه باهاش test data رو درست حدس بزنه.

2. بهبود داده: با کمی دستکاری میتونیم یادگیری دیتا ها رو متنوع تر کنیم و مدل رو مجبور کنیم تا الگو های قابل تعمیم تری یاد بگیره.
اطلاعات بیشتر راجب augment کردن دیتا تو خود داکیومنت torchvision هست.

3. استفاده از انتقال یادگیری: روش مورد علاقه خودم که قبل تر راجبش توضیح دادم. از یک مدل با وزن های آماده استفاده میکنیم و تغییراتی روی لایه های پایانی میدیم تا بتونیم برای مثال خودمون استفاده کنیم (یا حتی fine tuning انجام میدیم اگر دیتا بیشتری داشته باشیم).

4. مدل رو ساده تر کنیم: مدل بیش از حد اندازه پیچیده ممکنه الگو های قابل تعمیم روی test data یاد نگیره و در عوضش train data رو حفظ کنه. سر همین مدل رو میتونید ساده کنید تا مجبور بشه که الگو های قابل تعمیم یاد بگیره.

5. استفاده از learning rate decay: استفاده از ضریب یادگیری (learning rate) ثابت کارو وقتی که به نقطه همگرایی نزدیک میشیم سخت میکنه. مثل سکه ای که پشت مبل افتاده. وقتی نزدیک تر میشی باید گام کمتری برداری. کاهش ضریب یادگیری هم همینکارو میکنه.
تو داکیومنت PyTorch بهش میگن Learning rate scheduling که اطلاعات بیشتر در این باره اینجا هست.

6. توقف زودهنگام: وقتی یه مدل رو زیاد train کنیم به جایی میرسیم که overfitting رخ بده. پس باید به موقع توقف کنیم و بیشتر از این train نکنیم. وقتی که شروع کرد به overfit کردن میریم و وزن های قبلی ایده آلی که برای مثال تو 10 epoch قبل بود رو انتخاب و ذخیره کنید.
این منبع خوبی برای بحث early stopping هست.

تکنیک های دیگه هم برای بهبود training وجود داره:

1. Learning rate warmup
2. Weight decay
3. Gradient clipping

اما از اونجایی که وارد نشدم فعلا توضیحی راجبشون ندادم.
وقتی که یاد گرفتم و ازشون استفاده کردم حتما راجبشون مینویسم.

راه‌های حل مشکل Underfitting:

1. اضافه کردن لایه‌های بیشتر یا افزایش پارامتر های هر لایه
2. دستکاری learning rate (پایین آوردن)
3. استفاده از انتقال یادگیری
4. بیشتر train کردن
5. کاهش regularization

توضیحات هر کدوم از این روش ها:

1. شاید مدلتون به دلیل کمبود پارامتر توانایی یادگیری الگو ها رو نداره. معمولاً وقتی که این اتفاق میفته باید تعداد لایه ها و پارامتر ها رو افزایش بدید. ولی خب حواستون باشه که زیادی هم افزایش ندید که به overfitting بخورید.

2. ضریب یادگیری بیش از حد بالا میتونه به دلیل تغییرات زیاد موجب عدم یادگیری مدل بشه. انگار مدل داره پرش های بزرگی انجام میده و به همگرایی نمیرسه. سر همین استفاده از learning rate معقول توصیه میشه.

3. انتقال یادگیری سر همین روش مورد علاقم هست. چون هم برای overfitting کاربرد داره و هم underfitting. یک تیر تو دو نشان.

4. بعضی وقتا باید صبر کرد و بیشتر train کرد. مخصوصاً اگر روندی که مدل داره میره این موضوع رو نشون میده (test loss کمتر از train loss).

5. وقتی از regularization بیش از حد استفاده میکنیم (سعی میکنیم که مدل الگو هایی رو یاد بگیره که قابل بسط روی test set باشه) ممکنه به underfitting بخوریم.

تمامی اینا عملا صد درصدی کار نمیکنن. هیچ silver bullet ای داخل هوش مصنوعی نیست.

بهترین راه اینه که امتحان کنید.

جدا از این موضوع این تمام تکنیک های موجود نیست. قطعا تکنیک های بیشتری هم وجود دارن.

اصن یکی از بحث‌های تحقیقاتی تو موضوع machine learning همین موضوعات هست. Overfitting و Underfitting.

یک خط خیلی باریکی هم بین این دو هست که ما ترجیحاً دنبال این میگردیم.

یعنی اگر خیلی تلاش کنیم که جلوی underfitting رو بگیریم overfit میکنیم و برعکس.
سر همین یکی از هنر های machine learning اینه که چطوری این حد وسط ایده‌آل رو پیدا کنیم.

در ضمن یه منبع خیلی خوبی هم پیدا کردم که راجب مفاهیم هوش مصنوعی اطلاعات خوبی میده و ریفرنس های خوبی هم برای مطالعه ارائه میکنه.

https://ml-cheatsheet.readthedocs.io/en/latest/index.html

راجب regularization یه بخش داره که اگر اطلاعات بیشتری در این بحث میخواید پیشنهاد میدم مطالعه کنید.

یکی از باحال ترین چیزایی که دیدم این چند وقت پیش GAN Lab و Diffusion Explainer بود.

دو تا وبسایت که به صورت گرافیکی
GAN (Generative Adverserial Network)
و
Stable Diffusion
رو توضیح میدن و به صورت گرافیکی هم نمایش میدن.

GAN Lab

Diffusion Explainer

یک دلیل خیلی خوب و منطقی برای یادگیری Docker.

#Meme

جدا از این میم. خوندن این مقاله رو هم پیشنهاد میکنم.

درسته، واسه استفاده های تکی شاید اونقدر هم مهم نباشه.
ولی وقتی که تو یه تیم هستید این ابزار بازی رو عوض میکنه.

پیشنهاد میدم کار باهاش رو یاد بگیرید و ازش مرتب استفاده کنید تا کاملا مسلط بشید.

https://towardsdatascience.com/how-docker-can-help-you-become-a-more-effective-data-scientist-7fc048ef91d5

Errata − اشتباهات:

داکر فقط واسه یک تیم نیست. حتی تک نفری هم خیلی مهمه.
چون کار دیپلوی رو آسون تر میکنه.

همونطور که میبینید گزینه دیپلوی از طریق داکر تو huggingface spaces هست.

فکر نکنید فقط اینجاست. خیلی جای بیشتری هم وجود داره که کار مارو برای دیپلوی ساده تر میکنه.

ولی خب قبل از اینکه عجله کنید و برید Docker یاد بگیرید پست بعدی رو بخونید که متوجه بشید آیا واقعا نیاز دارید یا نه.

اول از همه بهتون بگم که بنده متخصص Docker و DevOps کار نیستم. سر همین ممکنه نظرات من صرفاً صحیح نباشه بنابراین به چشم نظر شخصی بهش نگاه کنید.

من خیلی از ایده و فلسفه Docker خوشم میاد.

و ازش استفاده کردم. ولی متاسفانه استفاده واقعی و درستش رو هنوز به کار نبردم و سر همین ازتون میخوام که وقتی سمتش برید که واقعا دلایل معقولی دارید.

زمان هممون محدود هست و نمیتونیم هر تکنولوژی رو یاد بگیریم و تو workflow امون integrate کنیم.

اول اینکه من برای داکر چند استفاده میبینم.
دو تای اول معقولن. سومی، یکم عجیب....

1. دیپلوی: این مهم ترین استفاده هست. مخصوصا مخصوصا اگر از kubernetes استفاده میکنید. ولی خب اگر هم نمیکنید باز هم حتما میخواید که یه محیط کاملا reproducible و stable داشته باشید. دلیل بر این نیست که بخواید کدی بنویسید که تنها با dependency های داکر کار کنه. وقتی بحث نرم افزار های enterprise وسط باشه ما نمیتونیم 100% compatibility رو روی همه محیط ها تضمین کنیم، مگر اینکه این همه هزینه dev time بزاریم. ولی خب compatibility حتماً باید تا حد امکان بالا باشه.

2. اشتراک گذاری سرویس های مورد توسعه بین توسعه دهندگان: همه توسعه دهنده ها وقت ندارن که تمام سرویس ها رو بالا بیارن. تک تک سرویس ها کلی تنظیمات و دردسر ها دارن و کلی زمان میبره و داکیومنتیشن میخواد. ما با داکر راحت میتونیم ایمیج سرویس های مورد توسعه رو گیر بیاریم و برناممون رو همگام با اون توسعه بدیم.

3. محیط توسعه شخصی (یا تیمی): حالا چه پروژه به پروژه یا چه گلوبال. این استفاده یکی از استفاده های جالبی هست... ولی خب ما اینجاست که وارد تنظیمات Xorg و Wayland socket forwarding میشیم و کلی جزییات عمیق دیگه داکر.

این استفاده سومی حالا از کجا به ذهنم اومد؟
وقتی که vscode devcontainers و distrobox و همینطور Fedora Silverblue که شامل ابزار toolbox هست آشنا شدم.

مفهوم وجود یک محیط stable و کاملا reproducible که هر جایی بتونی راحت نصبش کنی و کارت رو انجام بدی خیلی چیز خوبی بود.

ولی خب اگر شما بخواید از صفر Dockerfile درست کنید و دستوراتش رو یاد بگیرید به نظرم ارزشش رو نداره. مخصوصا وقتی که واقعا چنین نیازی پیش نمیاد. من سیستم عاملم رو زیاد تغییر نمیدم و ۹۵ درصد مواقع روی سیستم خودم کار میکنم. جدا از اینکه اینقدر زمان باید بزارید که زیر و روی docker رو یاد بگیرید.

البته که محیط توسعه میتونه حتی بین توسعه دهنده ها هم به اشتراک گذاشته بشه. ولی خب onboard یک نفر تازه کار با این روش بد هست. چون اگر tech stack خودش رو بلد نباشه نصب و پیاده کنه قطعاً تو آینده دچار مشکل میشه.

ایده خوبی که میتونه کارو ساده‌تر کنه distrobox هست به اضافه یه اسکریپت شخصی که post init بیاد و نرم‌افزار های مورد نیازتون رو نصب کنه. ولی خب این دیگه داکر نیست. ابزار تحت داکر هست.

البته که ما استفاده های خیلی بیشتر و عجیب تر هم از داکر داریم که تو آینده مطرح میکنم. از جمله ران کردن مرورگر firefox یا یکسری برنامه‌های گرافیکی روی داکر (که موندم واقعاً به چه دردی میخوره)...

اما یه چیزی رو میدونم. و اونم اینه که دنبال دلایل منطقی برای یادگیری یک تکنولوژی باشید. یادگیری صرف یادگیری یا دلیل نامناسب دیگه فایده‌ای نداره.