Liger (Linkedin GPU Efficient Runtime) Kernel

لینکدین یک لایبرری بنام Liger Kernel معرفی کرده که به طرز قابل توجهی باعث افزایش سرعت و کاهش مصرف RAM در آموزش LLM میشه. آمار و ارقام نشون میده که شما با این لایبرری می‌تونید 20% افزایش سرعت و 60% کاهش مصرف RAM رو تجربه کنید! 🤯

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

import transformers
from liger_kernel.transformers import apply_liger_kernel_to_llama

model = transformers.AutoModelForCausalLM.from_pretrained("<some llama model>")

# Adding this line automatically monkey-patches the model with the optimized Liger kernels
apply_liger_kernel_to_llama()

همونطور که گفتم، این لایبرری رو لینکدین ارائه کرده و هم مورد توجه جامعه هوش مصنوعی قرار گرفته و هم دست مایه طنز کاربرهای توییتر شده! تصویر بالا رو ببینید. 😁

لینک گیتهاب

تحلیل BSOD پتچ امنیتی CrowdStrike

مشکل اصلی که در نرم‌افزار CrowdStrike رخ داد، به دلیل دسترسی نادرست به حافظه از طریق یک اشاره‌گر تهی (NULL pointer) در زبان برنامه‌نویسی C++ بود. حافظه در کامپیوتر به صورت یک آرایه بزرگ از اعداد سازماندهی شده است. اگر برنامه‌ای تلاش کند به یک آدرس حافظه نامعتبر دسترسی پیدا کند، سیستم‌عامل بلافاصله برنامه را متوقف می‌کند و این موضوع منجر به خرابی سیستم می‌شود.

در این حالت خاص، برنامه سعی کرد به آدرس حافظه 0x9c (که معادل 156 در مبنای 10 است) دسترسی پیدا کند. این آدرس حافظه نامعتبر است و دسترسی به آن باعث می‌شود که سیستم‌عامل برنامه را متوقف کند. این مسئله به دلیل عدم بررسی اشاره‌گر تهی توسط برنامه‌نویس اتفاق افتاد.

برای مثال:

struct Obj {
    int a;
    int b;
};

Obj* obj = NULL;

print(obj->a);

در این مثال، اشاره‌گر obj تهی (NULL) است. هنگامی که برنامه سعی می‌کند به عضو a از شیء obj دسترسی پیدا کند، به دلیل تهی بودن اشاره‌گر، به یک آدرس نامعتبر دسترسی پیدا می‌کند و باعث خرابی برنامه می‌شود.

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

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

➖➖➖➖➖➖➖➖

🔶 متاسفانه زیر ساخت شبکه TON تلگرام بسیار ضعیف اجرا شد و آنها انتظار نداشتند چنین حجم سنگینی از تراکنش های روی شبکه TON انجام شود. گزارشی رسیده که حجم تراکنش از روزانه 2.5 ملیون تراکنش به 9.5 ملیون تراکنش رسیده است و بسیاری از تراکنش ها انجام نمی شود و برخی از صرافی ها مثل بایننس مجبور شدند که برداشت از شبکه TON ببندد. بهرحال این اتفاق به ایردارپ داگز بر می گردد که نتوانست به ۴۰ میلیون کاربر خود توکن های داگز از طریق شبکه TON به حساب آنها انتقال دهد.

باید دید شبکه TON چه برنامه ای برای ارتقای زیرساخت خود در کوتاه مدت دارد.


@TheRaymondDev

#regreSSHion #OpenSSH #CVE-2024-6387
اخیرا برنامه OpenSSH که استفاده گسترده ای در پروتکل SSH دارد، دارای یک آسیب پذیری شرایط رقابتی یا Race Condition شده است.

این آسیب پذیری از نسخه 8.5p1 => 9.8p1 که در برابر signal handler آسیب پذیری Race Condition رخ خواهد داد، که به زبان ساده میشود اینکه در یک بازه زمانی مشخص، چندین Thread موازی تلاش میکنند در یک منطقه حافظه برخی فرایند خواندن و برخی فرایند نوشتن را انجام دهند.

اینجا تقدم و تأخر لحظه استفاده و لحظه چک بهم خواهد خورد و آسیب پذیری این امکان رو خواهد داد که شما از 200 درخواست یا Request ارسالی چند مورد رو به اشتباه مجوز تایید بگیرید.

خب حالا نحوه رخداد آسیب پذیری چطور بوده؟ این آسیب پذیری بر روی سیستم عامل های لینوکسی که از کتابخونه glibc بهره میگیرند، قابل بهره برداری است.

چرا که تابع syslog خود تابع async-signal-unsafe را فراخوانی میکند که این تابع از malloc و free برای تخصیص حافظه استفاده میکند که در منطقه سیستم است لذا سطح دسترسی نیز root خواهد بود، همچنین در تابع main_sigchld_handler شرط آسیب قرار دارد.

فصل اول
2- بلاکچین چگونه کار می‌کند؟

بلاکچین را مجموعه‌ای از بلاک‌ها تصور کنید که به صورت زنجیره‌وار به یکدیگر متصل‌اند.

1- ساختار هر بلاک
هر بلاک در زنجیره شامل 3 بخش اصلی است:

1.1- داده (Data): این بخش شامل اطلاعاتی است که بلاک ذخیره می‌کند. برای نمونه، در بلاکچین بیتکوین داده‌ها شامل جزئیات هر تراکنش است مانند فرستنده، گیرنده و مقدار بیتکوین انتقال داده شده.

1.2- هش بلاک (Block Hash): هر بلاک دارای یک کد منحصر به فرد به نام هش است که با استفاده از الگوریتم‌های رمزنگاری تولید می‌شود. هش یک بلاک مانند اثر انگشت آن بلاک است و کوچکترین تغییری در جزئیات داده‌های بلاک، هش آن را به کلی تغییر می‌دهد.
الگوریتم‌های هشینگ توابع ریاضی یک‌طرفه‌ای هستند که ورودی آن هر چیزی می‌تواند باشد اما خروجی آن یک مقدار منحصر به فرد با اندازه ثابت است. یک‌طرفه بودن این توابع به این معناست که با داشتن خروجی نمی‌توان به داده ورودی آن دست پیدا کرد.

1.3- هش بلاک قبلی (Previous Block Hash): هر بلاک حاوی هش بلاک قبلی است که به آن متصل است. این ویژگی باعث ایجاد زنجیره‌ای از بلاک‌ها می‌شود و امنیت و تغییرناپذیری بلاکچین را تضمین می‌کند.

2- فرایند افزودن بلاک به زنجیره
برای افزودن بلاک جدید به زنجیره، مراحل زیر انجام می‌شود:


2.1- تایید تراکنش‌ها (Transaction Verification): ابتدا تراکنش‌های جدید توسط نودهای شبکه تایید می‌شوند. این تایید شامل بررسی صحت امضاهای دیجیتال و اطمینان از عدم تکراری بودن تراکنش‌ها است.

2.2- حل مسئله ریاضی (Proof of Work): برای اضافه کردن بلاک جدید به زنجیره، نودها باید یک مسئله ریاضی پیچیده را حل کنند که به آن اثبات کار می‌گویند. این فرآیند نیازمند قدرت محاسباتی زیادی است و زمان و انرژی زیادی مصرف می‌کند.

2.3- اضافه شدن به زنجیره (Block Addition): پس از حل مسئله و تایید صحت بلاک جدید توسط سایر نودهای شبکه، بلاک به زنجیره اضافه می‌شود.

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

تکمیلی:
بعضی از سایت‌های تولید محتوا مانند ویکی‌پدیا و everpedia بر بستر بلاکچین هستند.که اصولا برای اضافه کردن بلاک جدید نیاز به حل معادلات پیچیده نیست،مثلا در سایت everpedia براساس یک سری الگورتیم های دیگه بلاکچین باشه که هیچ یک از این کار ها رو کاربر انجام نمیده.

بیشتر بخوانید:
الگوریتم های هشینگ Hashing algorithms
هش بلاک Block Hash
نود Node

#blockchain
@code_crafters

دوره آنلاین "معاملات الگوریتمی براساس یادگیری ماشین"
Machine Learning-based Algorithmic Trading

زمان:
از 15 شهریور تا 20 مهر
پنجشنبه‌ها: 16:30 تا 19
جمعه‌ها: 17:30 تا 20
طول دوره:
30 ساعت
امکان برگزاری جلسات تکمیلی و رفع اشکال بدون هزینه اضافی وجود دارد. این امکان به دلیل گستردگی مباحث و ذات بین رشته‌ای دوره ایجاد شده است.
✅ مشاهده سرفصل‌ها و ثبت‌نام: Link

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

🔴 ظرفیت بلیط‌هایِ زودهنگام به پایان رسید
🔵 تعدادی بلیط معمولی باقی مانده است

Event storming

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

به شیوه سابق مهندسین نرم افزار از UML استفاده میکردن (زبان مدلسازی یکنواخت) اما دو ایراد اساسی داشتیم اول اینکه در این رویکرد متخصصین کسب و کار حذف میشدند یعنی کسانی که در شناخت حوزه بشدت کارآمد هستند و دوم اینکه عدم در نظر گرفتن گلوگاه‌ها، وابستگی‌ها و داینامیک بودن پروژه می باشد این مسئله درست هستش که میتوان دیاگرام‌های بیشتر و بیشتری طراحی و این برای مهندسین نرم افزار خوب و بهتر بود اما همچنان مورد اول پا برجا بود

در دنیای DDD ما نیاز به رویکردی جدید و مدرنتر داشتیم که بتوان موارد زیر رو رفع کرد:
۱- فضای مسئله و راه حل‌ها
۲- شناخت و یافتن BC یا همان مرزهای محدود
۳ـ جلسات منفعل با BR یا همان متخصصان کسب و کار
۴- فرار از مدلسازی‌های نامناسب
۵- تهیه کردن لیست نیازمندی ها
۶- دست یافتن سریع به یک زبان مشترک


همیشه دیدگاه اشتباهی راجب DDD وجود دارد اینکه این رویکرد فقط برای سیستم‌هایی جوابگو هستش که در ابتدای راه و ساختن قراردارد اما این یک اشتباه هست اتفاقا این رویکرد برای سیستم‌های قهوه‌ای (امیدوارم منظور نویسنده از قهوه‌ای را گرفته باشید) بهتر پاسخ میدهد

در سال ۲۰۱۳ یک روش خلاقانه با عنوان event storming معرفی شد که پایان هرآنچه که در بالاتر مطرح کردیم رو ختم کرد

این رویکرد یک طوفان فکری را بپا میکرد که به سرعت موجب فرآیندسازی کسب و کار میشد و مشکل UML را نیز با خود نداشت


با توجه به اینکه مطالب مربوط به event storming زیاد و گوناگون است لذا این بخش از کتاب رو بهتر هستش خودتون با سرچ کردن و خوندن مقالات متنوع یاد بگیرید

#DDD
#domain_driven_design

@code_crafters

تحلیل دیتاست‌های جدولی (Tabular) هم در ریسرچ و هم در کاربردهای واقعی خیلی مورد توجه هست. مقایسه‌هایی که تا الان انجام شده، نشون میده عملکرد مدل‌های دیپ اغلب پایین‌تر یا هم‌سطح مدل‌های بوستینگ گرادیان (GBMs) هست.

می‌خوام درباره مقاله‌ای صحبت کنم که مقایسه عمیقی روی مدل‌های آنسامبل مبتنی بر درخت تصمیم (TE)، دیپ (DL) و مدل‌های کلاسیک ML انجام داده. عنوان مقاله:
A Comprehensive Benchmark of Machine and Deep Learning Across Diverse Tabular Datasets link

حدود 111 دیتاست جدولی و 20 مدل مختلف برای مقایسه انتخاب شده. مقایسه‌های متنوعی انجام شده؛ مقایسه عملکرد مدل‌های DL و TE رو در تصویر بالا آوردم. نتایج جالبی بدست اومده:
* مدل CatBoost در 19 مورد از 111 دیتاست بهترین بوده.
* رتبه Random Forest قابل توجه هست.
* مدل XGBoost که خیلی‌ها انتخاب اولشون هست، در رتبه 10 دیده میشه!
* رتبه اول تا چهارم رو مدل‌های ML اشغال کردن.
* اولین مدل دیپ لرنینگی در رتبه 5 دیده میشه.
* شبکه MLP در رتبه 9 دیده میشه.
* شبکه TabNet آخره!

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

از جان مهندسین نرم افزار چه میخواهند؟؟


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

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

من در ذهن خودم بدین شکل می‌اندیشم: مهندسی نرم افزار کلاسیک و مهندسی نرم افزار مدرن مبتنی بر اجایل

اما در پاسخ به این سوال که از جان مهندسین نرم افزار چه میخواهند، پاسخ بدین شکل خواهد بود، علاوه بر ساختن صحیح یک نرم افزار ،انتظار می‌رود که یک نرم افزار مناسب ساخته شود

در این سری از پست‌ها میخواهیم راجب BDD (Behavior-Driven Development) توسعه مبتنی بر رفتار صحبت کنیم که از بالاترین سطح تا پایینترین سطح کدزنی را تحت تاثیر خواهد گذاشت و منجر به ایجاد یک نرم افزار مناسب میشود و علاوه بر آن به شما کمک خواهد کرد تا به یکی از بزرگترین چالش‌های موجود که زمان تحویل بموقع نرم افزار است فائق آیید


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


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

#BDD
#behavior_driven_development

@code_crafters

شاپرک برگزار می‌کند: رویداد امنیت سایبری CASH24

رویداد فتح پرچم  CASH24 با هدف ارتقاء دانش و مهارت‌های امنیت سایبری به ویژه در صنعت پرداخت برای نخستین بار از سوی شرکت شاپرک برگزار می‌شود.
به گزارش روابط عمومی شرکت شاپرک، این رویداد در دو بخش مسابقه CTF و همایش علمی طی سه روز در هفته آخر شهریور ماه و با حضور مدیران ارشد بانک مرکزی، گروه ملی انفورماتیک و متخصصان امنیت سایبری برگزار خواهد شد.
نخستین دوره از رقابت‌های تست نفوذ سایبری شاپرک تحت عنوان رقابت‌های فتح پرچم (Capture the Flag (CTF با هدف شناسایی و مقابله با آسیب‌پذیری‌های محصولات نرم‌افزاری و سامانه‌های امنیتی در روزهای 24 و 25 شهریورماه به صورت آنلاین برگزار می‌شود.
مسابقهCASH24 (CTF Arena For Security & Hacking)  شاپرک شامل بخش‌های مختلفی از جمله امنیت برنامه‌های وب و برنامک‌های موبایل، رمزنگاری و مهندسی معکوس و تحلیل جرم‌شناسی دیجیتال است.
جوایز تیم‌های برنده که شامل جایزه‌های ارزنده‌ای است، همزمان با رویداد امنیت سایبری شاپرک به برندگان اهدا خواهد شد.
رویداد علمی ـ تخصصی امنیت سایبری شاپرک با همکاری آکادینو و حمایت چهار شرکت پرداخت الکترونیک امیدپی، به پرداخت، پارسیان و سپ در روز 27 شهریورماه در قالب کارگاه‌ها و سخنرانی‌های علمی برگزار خواهد شد.
تیم‌های علاقه‌مند برای شرکت در مسابقه می‌توانند از طریق لینک زیر ثبت نام کنند:
https://cash.ctfd.io

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

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

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

{"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 دارند.


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