توی برنامه نویسی زیادی خسیس نباشید

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

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

{"name":"linuxor","type":"channel"}

میایم یه صرفه جویی کثیف میکنیم

["linuxor",2]

ما اینجا توی حافظه صرفه جویی کردیم ولی هر جایی بخوایم از این دیتا استفاده کنیم باید بدونیم ایندکس صفرم name هست و ایندکس یکم type و عدد 2 هم برای type یعنی channel این یعنی نیاز به مستندات بیشتر.

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

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

و این تصور که اگه تعداد پردازنده هارو به سمت بی نهایت ببریم سرعت هم بینهایت افزایش پیدا میکنه اشتباهه و در نهایت به یه جایی میرسه که دیگه با افزایش تعداد پردازنده سرعت بیشتر نمیشه.

وقتی که دو نفر، در دو منطقه‌ی جغرافیایی، همزمان اقدام به نصب یک کتابخونه، بعنوان مثال با دستور

pip install 'NAME-OF-LIBRARY'

می‌کنند، لزومن ورژن هر دو شخص برابر نخواهد بود. حتی اگر ورژن پیپ و پایتون در هر دو سیستم برابر باشه.

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

یعنی، برای شخص اول، آخرین ورژن دانلود و نصب بشه، در حالی که نفر دوم، از مخزنی اقدام به دانلود کنه که هنوز فرایند آپلود آخرین نسخه تکمیل نشده است و ورژنی که نصب میشه، قدیمی باشد.

و همین اختلاف‌های ریز، گاهن مشکلات بزرگی رو تولید می‌کنه. حالا برو بگرد دنبال دلیل 😎.

راه‌ حلش هم ساده است؛ یا دقیقن ورژن مد نظر رو ذکر کنیم. یا هر دو شخص از یک آدرس مخزن استفاده کنند.

بچه‌ها سلام 👋

امروز می‌خوام یه‌ سری تجربیات و نکات رو باهاتون به اشتراک بذارم. 😊

تو این مسیر بک‌اند دولوپری، چیزایی هست که شاید اولش به نظر مهم نیاد ولی واقعاً اهمیت داره. بیاید با هم مرور کنیم:

1⃣ دیتابیس‌ها رو جدی بگیرید 
از همون اول کار دیتابیس رو دست‌کم نگیرید. خیلی وقتا دولوپرها دیتابیس رو فقط یه محل ذخیره داده می‌بینن ولی واقعیت اینه که نحوه طراحی و مدیریت دیتابیس تاثیر زیادی روی عملکرد کلی سیستم داره. ساختار درست دیتابیس، ایندکس‌ها، نرمال‌سازی و حتی دِنورمال‌سازی وقتی لازمه، همه اینا چیزایی هست که باید بلد باشی.

2⃣ فریم‌ورک مهمه، ولی تسلط به مفاهیم مهم‌تره 
ببینید، همه ما از یه جایی شروع کردیم و احتمالا با یه فریم‌ورک خاص، مثل Django یا Laravel، کار رو شروع کردیم. ولی اگه به مفاهیم پایه‌ای مثل HTTP، RESTful APIs، و اصول SOLID مسلط باشی، راحت‌تر می‌تونی با فریم‌ورک‌های مختلف کار کنی. یادگیری یه فریم‌ورک جدید نباید برات چالشی باشه اگه مفاهیم اساسی رو بلدی.

3⃣ کد خوانا بنویس، نه فقط برای کامپایلر، برای بقیه هم! 
این نکته شاید تکراری باشه ولی هنوزم خیلیا رعایت نمی‌کنن. کد رو جوری بنویس که خودت یا هر کس دیگه‌ای که قراره بعداً باهاش کار کنه، راحت بفهمه. کامنت‌های بیجا هم ننویس ولی اگه جایی پیچیده‌ست، کامنت بذار. یادت باشه: «کد برای کامپیوتر نوشته نمیشه، برای آدم‌ها نوشته میشه.»

4⃣ تست نویسی از نون شب واجب‌تره 
این یکی از اون چیزاییه که خود منم اولش ازش فراری بودم، ولی وقتی میری تو پروژه‌های بزرگ، می‌فهمی که بدون تست درست و حسابی، خیلی راحت ممکنه همه چی به هم بریزه. یونیت تست‌ها، اینتگریشن تست‌ها، و حتی تست‌های خودکار (Automated Tests) رو حتماً تو برنامه‌هات بزار.

5⃣ همیشه در حال یادگیری باش 
دنیای برنامه‌نویسی خیلی سریع تغییر می‌کنه. امروز یه تکنولوژی خیلی خفنه، فردا یه چیز جدید میاد و همه ازش حرف می‌زنن. خودت رو محدود به یه زبان یا تکنولوژی نکن. دائماً در حال یادگیری باش، حتی اگه شده یه ساعتی در هفته رو به یادگیری اختصاص بده.

6⃣ همکار خوب بودن رو یاد بگیر 
آخرش همونطور که همه می‌دونیم، بک‌اند دولوپری فقط کد زدن نیست. باید با بقیه اعضای تیم هماهنگ باشی، با فرانت‌اندی‌ها، دیزاینرها، و حتی مشتریا ارتباط خوبی داشته باشی. همکار خوب بودن و داشتن مهارت‌های نرم (soft skills) هم بخشی از این شغل هست.

خب بچه‌ها، این‌ها تجربیات و نکاتی بود که دوست داشتم باهاتون به اشتراک بذارم.

امیدوارم براتون مفید بوده باشه. 🌹

اگه سوالی دارید یا می‌خواید در مورد موضوع خاصی بیشتر بدونید، کامنت بذارید یا دایرکت بدید.

به امید موفقیت‌های بیشتر برای همتون! ✌🏻

@ninja_learn_ir

دیروز تو کارخونه ی نوآوری آزادی داشتم با یکی از همکارانم صحبت میکردیم که چرا open ai تو قسمتی از پروژه هاش از زبان Go استفاده کرده به جای #پایتون. ایشون گفتند به خاطر اینکه زبان پایتون یک زبان مفسری هست و زبان های مفسری سرعت اجراشون کند هست.
تو این موضوع خیلی حرف دارم که چرا با وجود کند بودن پایتون همچنان این زبان به عنوان اولین و مهمترین زبان در حوزه ی AI داره استفاده میشه و دولوپرهای AI چه استراتژی هایی رو به کار میگیرند تا این ضعف پایتون رو پوشش بدن.

به زودی راجب این موضوع یک مقاله ی خوب و کامل مینویسم ولی یکی از کارهایی که میکنند اینه که مدل ml رو توسط ماژول های pickle و یا joblib سیو میکنند، با این کار از مدل یه فایل باینری صفر و یکی ساخته میشه و همونطور که میدونید فرمت های باینری بسیار سریع execute میشن. بقیه ی کارهارو تو مقاله ی جدیدم میگم.
منتظر باشید😎.

مدل یا سامانه؟!

در پیاده‌سازی اپلیکیشن‌های مبتنی بر هوش مصنوعی دو رویکرد کلی وجود دارد:
۱. ساخت یک مدلِ End-to-End که صفر تا صد کار را از روی داده‌ی آموزشی، یادگرفته و در قالب یک مدلِ یک‌پارچه به انجام کار (Task) می‌پردازد.
۲. ساخت یک سامانه‌ی Compound AI که از اجزای مختلف از جمله مدل‌ها و ماژول‌ها و ابزارهای نرم‌افزاری مختلف تشکیل شده و در قالب یک سامانه‌ی ترکیبی،‌ به انجام کار می‌پردازد. این سامانه در حین انجام کار ممکن‌ست چندین بار، یک مدل مشخص را به‌شکل‌های مختلف فراخوانی کند.

روش اول ساده‌تر و تاحدی سریع‌ترست. پژوهشی موسوم به Scaling Laws هم نشان می‌دهد که با افزایش پیچیدگی محاسباتی مدل می‌توان به نتایج بهتری رسید. ازطرفی بهینه‌سازی کلیِ این روش ساده‌ست چون برخلافِ یک سامانه‌ی AI متشکل از اجرایی مثل موتور جستجو، همه‌ی اجزای یک مدل End-to-End مشتق‌پذیر و قابل‌بهینه‌سازی‌اند.

بااین‌حال، روندها نشان‌دهنده‌ی این‌اند که علاقه‌مندی بیشتر به‌سمت طراحی سامانه‌ها (System Design) و بهره‌گیری از ابزارها و روش‌های موجود در مهندسی‌ست. در زیر، شش دلیل برای این علاقه‌مندی آمده‌ست.

- وقتی از مدل‌ها استفاده می‌کنیم، هزینه‌ی تمام‌شده و دقت، مشخص و ثابت‌ست اما اپلیکیشن‌ها و بخش‌های مختلف آن‌ها، بسته به کاربرد، نیاز به دقت و هزینه‌ی متفاوت دارند. مثلا وقتی قرارست یک متن حقوقی دقیق نوشته شود، هزینه‌ی GPT-4o اصلا برای کاربر دغدغه نیست اما زمانی که اپلیکیشنی مثل GitHub Copilot قصد کمک به تکمیل کد برنامه‌نویس در هر خط را دارد، احتمالا استفاده از یک مدل ساده‌تر و ارزان‌تر مطلوب‌ترست.

- در بعضی از تسک‌ها (مثلا حل مسابقات برنامه‌نویسی)، افزایش جدی هزینه‌ی آموزش مدل (مثلا افزایش سه‌برابری)، باعث بهبود عملکرد مدل می‌شود ولی نه زیاد (مثلا دقت ۳۰ درصد می‌شه ۳۵ درصد) اما فقط با مهندسی‌ِ یک سامانه‌ی Compound AI ممکن‌ست بهبود بسیاری حاصل شود (مثلا ۸۰ درصد) - منبع

- مدل‌های ML (با وجود قابلیت Generalization) محدود به داده‌های آموزشی‌اند ولی اپلیکیشن‌های AI نیاز به پویایی دارند. استفاده از یک سامانه به‌جای یک مدل، امکان استفاده‌ی لحظه‌ای از جستجو و بازیابی به‌منظور دریافت اطلاعت جدید و دقیق را به اپلیکیشن اضافه می‌کند. با دسترسی مستقیم به مراجع خارجی در کنار دانش داخلیِ مدل، اپلیکیشن قابلیت شفافیت (Transparency) و تفسیرپذیری (Interpretability) بیشتری پیدا می‌کند که این قدم مهمی در راستای Trustworthy AI است.

- خیلی از داده‌ها را به‌علت رعایت مسايل مربوط به privacy و copyright و safety نمی‌توان موقع آموزش به مدل نشان داد. استفاده از سامانه‌های Compound AI به ما اجازه‌ی کنترل داده‌ها باتوجه به سطح دسترسی افراد (ACL) را می‌دهد. به‌این شکل اپلیکیشن در هنگام استفاده‌ی کودک به داده‌های مشخص‌تر و امن‌تری دسترسی دارد، فایل‌های شخصی افراد فقط براستفاده‌ی خودشان قابل بازیابی‌اند، برای دسترسی به بعضی از داده‌ها می‌توان حقوق مولف را درنظر گرفت و …

- مدل‌ها پتانسیل بالایی در تولید توهم (Hullucination) دارند. استفاده از ابزارهایی مثل Guardrails و Outlines و LMQL و SGLang در سامانه‌های AI، به ما اجازه‌ی ارزیابی، پایش و پالایش خروجی مدل را می‌دهند. این موضوع می‌تواند در کنترل سوگیری‌های اجتماعی (Social Bias) ازجمل سوگیری‌های سیاسی، نژادی، مذهبی و … کمک‌کننده باشد. پژوهش جدیدی نشان می‌دهد که بیش‌تر مدل‌های زبانی موجود (به‌‌علت سوگیری در داده‌های جمع‌آور‌ی‌شده از رسانه‌ها) ازنظر سیاسی چپ-‌گرا‌اند.

- با این‌که همه‌ی اجزای یک سامانه‌ی AI مشتق‌پذیر نیستند اما ابزارهایی مانند DSPy معرفی شده‌اند که به‌روش‌هایی سعی در بهینه‌کردن کل پایپ‌لاین سامانه به‌صورت End-to-End دارند.


مرجع: بخش‌های از نوشتار بالا از این بلاگ‌پست برداشت شده‌ست.

معرفی توسعه رفتار محور

توسعه رفتار محور مجموعه‌ای از شیوه‌های مهندسی نرم افزار است که در ساخت و ارائه سریعتر، با ارزش تر و با کیفیت تر نرم افزار طراحی شده است، از شیوه‌های چابک و ناب مانند TDD و DDD بهره میبرد و از همه مهمتر با یک زبان مشترک ساده بین توسعه دهندگان ،ذینفعان و تحلیلگران کسب و کار جهت ارتباط باهمدیگر ارائه میدهد

در ابتدای مسیر BDD یک رویکرد ساده‌تر برای یادگیری TDD بود (پس اگه جایی خوندین که BDD همان TDD است تعجب نکنید این رویکرد اولیه آن بود)

در واقع TDD یک رویکرد مبتنی بر تست‌های واحد unit test برای تعیین و طراحی و ازمایش کدهای برنامه است

متخصصان TDD در ابتدا یک تست شکست خورده مینویسند که توصیفگر ویژگی جدید است و سپس کدهای زیادی مینویسند تا تست با موفقیت اجرا شود و سپس با بازنگری کد خود آن را بهبود داده تا جایی که مطمئن شوند که نگهداری کد ساده است، این رویکرد تا میزان قابل توجهی خطاهای سیستم را کاهش میدهد

با وجود مزایای TDD بسیاری از تیم‌ها با مشکل مواجه هستند اینکه از کجا شروع کنند و چه تست‌هایی باید در ابتدا نوشته شود و از کجا شروع کنند، TDD ممکن یک مشکل اساسی دارد اینکه ممکن است توسعه دهندگان را چنان درگیر جزئیات کند که ممکن است از اهداف اصلی کسب و کار دور شده و آن را فراموش کنند بعدها تیم ممکن است متوجه شود که نگهداری تعداد زیادی تست واحد کار بسیار مشکل سازی باشد

بسیاری از تست‌های سنتی یا حتی نوشته شده با رویکرد TDD با بخش خاصی از کدها ارتباط دارند و فراموش میکنند که باید با قسمت تجاری هماهنگ شوند

بیایید یک مثال بزنین:
در یک سیستم بانکی میخواهند فرایند انتقال پول از یک حساب به حساب دیگر انجام شود و دو تابع برای ان نوشته میشود تابع گرفتن اکانت و تابع انتقال پول، تست‌های ان نیز نوشته و پاس میشود اما یک مشکل وجود دارد این تست‌ها بیانگر دقیق فرآیند مدنظر نیست و با تغییر کد تست‌ها شکسته میشوند و باید نام تست‌های خود را نیز تغییر دهید، تست‌های واحد یک مشکل دیگر دارند آن هم اینکه با نگاه اولیه به آن نمی‌توانند توصیف‌گر دقیق فرآیند باشند و این موجب میشود که درک نوشتن تست‌های دیگر را نیز سختتر کند

جناب نورث (مخترع رویکرد BDD) مشاهده کرد با افزودن کلمه should به ابتدای نام تست‌های واحد میتوان تست‌های واحد با معنی داری نوشت که بیانگر این هستند که آن تست باید چکاری کند و بدین شکل شما متوجه میشوید که کلاس باید چکاری انجام دهد بجای اینکه چه روش یا عملکردی در حال آزمایش است اینگونه راحتتر میتوانید تلاش‌های خود را بر روی نیازهای اساسی کسب و کار متمرکز کنید و تست‌های بیشتر و بهتری نوشته شود که کیفیت کار را بالا ببرد، تست‌هایی که بدین شکل نوشته میشود بیشتر شبیه مشخصات است تا تست‌های واحد و بر روی رفتار برنامه تمرکز میکنند و از تست‌ها برای تایید و بیان ان رفتار استفاده میکنند و نگهداری آنها بدلیل واضح بودن هدف آنها بسیار آسانتر است (جناب نورث بعد از مشاهده تاثیر آن دیگر به آن TDD نگفت و امروزه شیوه‌های کاملا متمایزی از همدیگر هستند)

هدف مخترعان BDD ایجاد یک زبان فراگیر ساده که قابل درک برای تحلیلگران کسب و کار باشد که بتوانند از آن برای تعریف نیازمندی‌های خود استفاده کنند به مثال زیر دقت کنید

Given a customer has a current account 

When the customer transfers funds from this account to an overseas account 

Then the funds should be deposited in the overseas account 

And the transaction fee should be deducted from the current account

یک صاحب کسب و کار می تواند به راحتی سناریویی را که به این شکل نوشته شده درک کند. اهداف روشن و عینی را برای هر داستان از نظر اینکه چه چیزی باید توسعه یابد و چه چیزی باید آزمایش شود ارائه می دهد و امروز به شکل نمادین با عنوان Gherking تبدیل شد

متخصصان BDD دوست دارند با شناسایی اهداف تجاری و جستجوی ویژگی‌هایی که به تخقق این اهداف کمک میکند شروع کنند که با همکاری کاربر از نمونه‌های عینی برای نشان دادن این ویژگی ها استفاده میکنند، این نمونه‌ها در قالب اجرایی خودکار می‌شوند که هم نرم افزار را تایید می‌کند و هم اسناد فنی و عملکردی بروز رسانی خودکار را ارائه میدهد، اصول BDD در سطح کدنویسی به توسعه دهندگان کمک میکند تا کد با کیفیت بالاتر، بهتر تست شده، مستندتر شده و استفاده و نگهداری آن آسانتر باشد تصویر اول در کامنت‌ها


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



#BDD
#behavior_driven_design

@code_crafters

تا حالا به امنیت هر نوع داده ساختار و متغیر ها فکر کردی؟

برای زبان #پایتون امنیت داده‌ها رو میشه از جنبه های مختلف بررسی کرد، از جمله امنیت تغییرناپذیری (immutability)

رشته‌ها (Strings): رشته‌ها در پایتون تغییرناپذیر هستن. پس از ایجاد یک رشته، نمیشه محتواشو   تغییر داد. این ویژگی باعث می‌شود که رشته‌ها در برابر تغییرات ناخواسته محافظت بشن.

s = "Hello"
s[0] = 'h'  # این خط خطا می‌ده چون رشته‌ها تغییرناپذیر هستن

تاپل‌ها (Tuples): تاپل‌ها هم تغییرناپذیرن. بنابراین، پس از ایجاد یک تاپل، نمیشه المان‌هاشو تغییر داد.

t = (1, 2, 3)
t[0] = 10  # این خط خطا میده چون تاپل‌ها تغییرناپذیر هستن

لیست‌ها (Lists): لیست‌ها  تغییرپذیرن. بنابراین، میشه المان‌های اونارو تغییر داد، افزود یا حذف کرد. این ویژگی ممکنه  باعث مشکلات امنیتی بشه اگه لیست‌ها بدون کنترل مناسب تغییر کنند.

lst = [1, 2, 3]
lst[0] = 10  # این خط درسته چون لیست‌ها تغییرپذیر هستن

مجموعه‌ها (Sets) و دیکشنری (Dictionaries): این دو ساختمان داده نیز تغییرپذیر هستند. بنابراین، میشه المان‌ها رو بهشون افزود یا حذف کرد.

my_set = {1, 2, 3}
my_set.add(4)  # افزودن یک المان به مجموعه

my_dict = {'a': 1, 'b': 2}
my_dict['c'] = 3  # افزودن یک جفت کلید-مقدار به دیکشنری

یه نفر اومده روی لپ تاپ فریمورک چند تا بازی رو بین ویندوز 11 و لینوکس فدورا 40 مقایسه کرده.

مقایسه روی میزان FPS بوده و نتایج مقایسه به اینصورت شده :



بازی Shadow of the Tomb Raider روی لینوکس نیتیو نسبت به ویندوز 7% فریم ریت بیشتری داشته.

بازی Total War: Warhammer III روی لینوکس نیتیو نسبت به ویندوز 2% فریم ریت کمتری داشته.

بازی Forza Horizon 5 روی لینوکس از طریق پروتون نسبت به ویندوز 7% فریم ریت کمتری داشته.

بازی Cyberpunk 2077 روی لینوکس از طریق پروتون نسبت به ویندوز 7% فریم ریت بیشتری داشته.

پروتون درواقع یه لایه سازگار کننده بازی ویندوز برای لینوکسه اینکه روی لینوکس Cyberpunk فریم ریت بهتری داشته عجیبه؛ البته مقایسه به عوامل محیطی زیادی وابسته‌س و نمیشه با این اعداد مقایسه دقیقی انجام داد، اما به صورت کلی میشه این مقایسه رو قبول کرد.

برای دیدن مقاله اینجا کلیک کنید.

اگه اینارو نمیدونی ادعایی تو برنامه نویسی نداشته باش!

شاید پارامترهای 'arg' و 'kwarg'  توی تعریف توابع یا داکیومنت های کتابخونه های مختلف  #پایتون دیده باشین.
اما این دوتا پارامتر دقیقا چیکار میکنن؟
زمان تعریف توابع میشه یک یا چند آرگیومنت رو به عنوان ورودی به اون تابع تعریف کرد اما اگر ندونیم که ورودی ها دقیقا چند تا هستند یا در آینده بخواییم چیزهای دیگه رو هم به عنوان ورودی به تابع بدیم به مشکل برمیخوریم و اینجاست که این دو تا پارامتر وارد عمل میشن.

پارامتر *arg: اگر تابعی از این پارامتر استفاده کنه به ترتیب وردی هایی که بهش داده شده رو میگیره و داخل پارامترهاش میریزه اما هر ورودی بیش تر از تعداد ورودی های ثابت رو به *arg اختصاص میده

def testfunc(one,*argv):
    for arg in argv:
        print(arg)

testfunc('Hello', 'this', 'is', 'SiliconBrain')

توی مثال بالا تابع مقدار ورودی 'one' رو با "hello" پر میکنه و باقی ورودی ها رو داخل *arg میریزه.
پارامتر *arg از مجوعه پارامترهای position based هست یعنی ترتیب ورودی هایی که بهش داده میشه اهمیت داره و به تبع اون میشه به همون ترتیب داخل تابع بهشون دسترسی داشت.

پارامتر **kwarg: این پارامتر هم مثل پارامتر قبلی برای ورودی دادن اضافی به توابع استفاده میشه با این تفاوت که ساختار اون به صورت دیکشنری هست و ورودی هایی که از این طریق به تابع داده میشن رو باید به صورت مقادیر {key:value} تعریف کرد.

def testfunc(arg1, **kwargs):
    for key, value in kwargs.items():
        print(f"{key} == {value}")

testfunc("Hi", first='this', mid='is', last='SiliconBrain')

در مثال بالا مقدار arg1 با "Hi" پر میشه و بقیه ورودی ها با **kwarg اختصاص پیدا میکنند در نتیجه داخل تابع به جای دسترسی به ورودی ها با استفاده از slicing که در *arg استفاده میشه.

نکته مهم: نام گذاری برای این دو پارامتر آزاد هست و هر اسمی که بعد از  * یا ** بیاد همون کاربرد موارد گفته شده بالا رو داره.
#python

یکی از مشکلات کلیدی و پایه تمامی دانشجویان حوزه امنیت سیستم‌های کامپیوتری و برنامه‌نویسی، ریاضی و زیرشاخه‌های آن است. بعد از حدود 1 سال تلاش به هر صورت دوره پایه آیو با عنوان Nexus of Thought تکمیل شد. این دوره شامل مباحث ریاضی مهندسی، ریاضی گسسته، منطق، تئوری اطلاعات، طراحی و سنتز سیستم‌‎های دینامیک و استاتیک، تحلیل ساختار کامپیوترها و پردازنده، استخراج دی اف دی، پردازش سیگنال و اصول کدینگ اطلاعات در شبکه است.

شایان ذکر است، این دوره رایگان خواهد بود و هر دانشجو که وارد دوره‌های آیو می‌شود، در فاز Preparation این دوره را دریافت خواهد کرد تا وقتی وارد کورس می‌شود، تمامی اصول پایه علوم کامپیوتری را فهمیده باشد. امیدوارم این دوره، موجب بهتر شدن تعمق دانشجویان در حوزه مهندسی دیجیتال شود. با تشکر از تمامی اعضای آیو که در انجام و آماده‌سازی این دوره کمک کردند.

جایگزین Llama3.1 فقط می‌تونه یک نسخه بهتر براساس همین معماری باشه :

arcee-ai/Llama-3.1-SuperNova-Lite

مدل ۸ میلیارد پارامتری هست، مدل ۷۰ میلیاردی فقط از طریق api در دسترس هست.
طبق ادعا از 405b, gpt4o, ... بهتر عمل می‌کنه؛ البته برای تسک‌های مربوط به
instruction-following

شخصاً هم همین رو احساس کردم توی تست‌ها.

یک نفر در Stackoverflow سوال کرده بود "چطور میشه گپ بین دقت داده train و test رو در مدل‌های Machine Learning حل کرد"؟ سوال برای یک مسئله سری زمانی بود. اول با خودم گفتم آقا خسته نباشی ملت صبح و شب در تلاش برای همین کار هستن تا هوش مصنوعی بهتر یاد بگیره. اما خوب تصمیم گرفتم به سوالش جواب بدم و حتی vote منفی سوالش رو که بقیه داده بودن خنثی کردم. روند توسعه مدل Machine Learning خیلی اوقات خوب انجام نمیشه و موارد پایه‌ای دیتاساینس و ماشین لرن رعایت نمیشه. مواردی مثل مانیتور کردن bias variance، شروع با مدل ساده و ارتقا با توجه به بایاس واریانس، experiment tracking و MLOps , بعضی روش‌های Advanced رو در 8 مورد نوشتم.
پ.ن: تمامی LLM ها و چت جی پی تی از منابعی مثل Stackoverflow کار و ریزه کاری کدزنی رو یاد گرفتن و باهوش شدن. پس مشارکت در Stackoverflow فراموش نشه.
آپدیت: یک مشارکت کننده رده بالا اومد گفت آقا چرا همچین سوالی رو جواب دادی و این سوال افزایش پرفورمنس در model dev هست نه سوال برنامه نویسی و اینجا off topic محسوب میشه. منم گفتم آره طرف باید این سوال رو در کامیونیتی مثل Cross Validated میپرسید (از زیرمجموعه های stackexchange هست اگر ندیدین حتما سر بزنید). اما طرف خوشش نیومد در کل و یک رای منفی هم داد و رفت! اما قصد نوشتن اون مطلب بود که اینجا میارم کاملش رو

In theory, the gap between train and test sets' error can not be less than what is called Bayes error, which is sometimes equivalent to human-level intelligence/error in fields where human natural perception is high (such as NLP and Vision). However, in Time Series, it is difficult to predict how far we can minimize this gap. The following steps are what I suggest and they are all basically about using model's bias & variance in each experiment and then use some techniques to improve the model:

0. Use an experiment tracking tool: Start by organizing all your experiments using MLOps tools such as WandB and MLflow that let you log metadata (such as cross-validation results) and save models as artifacts. I prefer Weights&Biases which lets you do multiple experiments using Sweep and Grid Search or Bayesian Optimization to maximize a defined metric on your cross-validation for HPO. Note: Do not waste your time by overly tuning the models' parameters when doing HPO. It is wise to work on data centric approaches instead

1. Start with simple models: Avoid starting with irrelevant or overly complicated models. Begin with simple models and monitor their bias and variance. If you observe underfitting, you might want to use models that can capture non-linear relationships and work well with tabular time series data, such as Random Forest and XGBoost. Avoid jumping directly to complicated RNN models like LSTM, which were initially developed for NLP applications and have not performed well in time series competitions.

2. Address overfitting: Once you solve the underfitting problem, you may reach a model that can learn non-linear relationships in the training data. At this point, your model might exhibit high variance and overfitting on the training data. There are several ways to mitigate overfitting:

Add more training data or use data augmentation techniques. For example, a 2017 Kaggle winning solution for tabular data augmentation and representation learning used DAE. Regularization techniques: Apply L1 and L2 regularization (known as reg_lambda and reg_alpha in XGBoost) to penalize large weights and coefficients. Early stopping, Dropout, and Reduce Learning Rate on Plateau are other techniques commonly used for neural networks.

3. Use ensemble methods: Combine multiple models using techniques like soft voting.

4. Blending & stacking: Implement blending and stacking techniques to leverage the strengths of different models.

5. Advanced time series representations: Explore advanced methods such as signature kernels and wavelets to create better features and representations of your data.

6. Advanced tabular ML models: Look into new models like GRANDE, which combines the advantages of tree-based models and neural networks. Note that if you want to use models such as RF, XGB or GRANDE for time series problems you should do some shape transform first.

7. Improved time-series CV: You can use more advanced time-series Cross-Validation techniques like Embargo & Purge which usually used in quantitative finance.