Forwarded from a pessimistic researcher (Kc)
توی هفته گذشته این گروه جلسهی اول خودش رو برگزار کرد. تجربهی خیلی خوبی بود. بعد از مدتها دوباره فرصتی پیش اومد تا در کنار دوستان عزیز و علاقهمند باشم و ازشون یاد بگیرم. خواستم بهتون بگم که قرار شد آخر هفته، مجدد جلسهی اول رو تکرار کنیم تا دوستانی که به هر دلیلی نتونسته بودند خودشون رو برسونن، یک فرصت دیگهای باشه تا بتونن به جمع ما بپیوندند. در ادامه جا داره به چند نکته اشاره کنم.
راستش خیلی مهمه که موقع شرکت در جلسات مقالات رو تا یک حدی بررسی کرده باشید. حقیقتا زمان جلسه محدوده و اگر قرار باشه گردانندهی جلسه مقالات رو درس بده وقت بسیار کم میاریم.
نکتهی دیگه این هستش که تصمیم گرفتیم یک git repo درست کنیم جهت قرار دادن منابع و مطالبی که توی reading group بهشون بر میخوریم. از بین دوستان، یاسمین داوطلب شد که مدیریت ریپو رو دست بگیره. توی این repo علاوه بر مقالات اصلی، مقالات و کتب جانی هم قرار میدیم. یک روحیهی خیلی قشنگی که بچهها دارن، این هستش که بسیار مشتاقن تا کارهای عملی و پیادهسازی هم انجام بدیم. از این رو برای هر مبحثی که میخونیم، هر کسی توی این ریپو پروژههای عملی مربوط به اون حوزهی خاص که state of the art هستند رو قرار میده. علاوه بر اون تصمیم گرفتیم که پروژههای کوچکی هم تعریف کنیم که خودمون هم دست بکار بشیم.
برای مثال مطالب هفتهی اول دوره مربوط بود به Hoare Logic و زبان GCL بود. اگر به ریپو مراجعه کنید، علاوه بر مقالات و کتب جانبی، لیستی از پروژه ها مثل Dafny, Boogie, Why3 و KeY رو مشاهده میکنید که همگی زبانهای برنامهنویسی و verification هستند که Hoare Logic رو ساپورت میکنن و همهشون Deductive Verifier دارند برای اثبات درستی برنامهها.
علاوهبر اینا ۳ تا پروژه هم تعریف شده که به زودی یکی از اینها رو استارت میزنیم و ببینیم تا کجا میتونیم پیش ببریمش.
نکته آخر هم اینکه تصمیم گرفتیم موقعی که این مقالات رو میخونیم، هر چیزی که ازش فهمیدیم رو در قالب یک نوت به شکل خلاصه بنویسیم و توی ریپو push کنیم. به همین منظور توصیه کردیم که دوستان نوتهاشون رو با latex بنویسن و سورسش رو push کنن. بنده هم سعی میکنم نوتهای دوستان رو بخونم و ادیت کنم و در نهایت یک نوت ادغام شده از هر مطلب داشته باشیم.
خلاصه که آقا همش Fun و عشق و صفاست.
راستش خیلی مهمه که موقع شرکت در جلسات مقالات رو تا یک حدی بررسی کرده باشید. حقیقتا زمان جلسه محدوده و اگر قرار باشه گردانندهی جلسه مقالات رو درس بده وقت بسیار کم میاریم.
نکتهی دیگه این هستش که تصمیم گرفتیم یک git repo درست کنیم جهت قرار دادن منابع و مطالبی که توی reading group بهشون بر میخوریم. از بین دوستان، یاسمین داوطلب شد که مدیریت ریپو رو دست بگیره. توی این repo علاوه بر مقالات اصلی، مقالات و کتب جانی هم قرار میدیم. یک روحیهی خیلی قشنگی که بچهها دارن، این هستش که بسیار مشتاقن تا کارهای عملی و پیادهسازی هم انجام بدیم. از این رو برای هر مبحثی که میخونیم، هر کسی توی این ریپو پروژههای عملی مربوط به اون حوزهی خاص که state of the art هستند رو قرار میده. علاوه بر اون تصمیم گرفتیم که پروژههای کوچکی هم تعریف کنیم که خودمون هم دست بکار بشیم.
برای مثال مطالب هفتهی اول دوره مربوط بود به Hoare Logic و زبان GCL بود. اگر به ریپو مراجعه کنید، علاوه بر مقالات و کتب جانبی، لیستی از پروژه ها مثل Dafny, Boogie, Why3 و KeY رو مشاهده میکنید که همگی زبانهای برنامهنویسی و verification هستند که Hoare Logic رو ساپورت میکنن و همهشون Deductive Verifier دارند برای اثبات درستی برنامهها.
علاوهبر اینا ۳ تا پروژه هم تعریف شده که به زودی یکی از اینها رو استارت میزنیم و ببینیم تا کجا میتونیم پیش ببریمش.
نکته آخر هم اینکه تصمیم گرفتیم موقعی که این مقالات رو میخونیم، هر چیزی که ازش فهمیدیم رو در قالب یک نوت به شکل خلاصه بنویسیم و توی ریپو push کنیم. به همین منظور توصیه کردیم که دوستان نوتهاشون رو با latex بنویسن و سورسش رو push کنن. بنده هم سعی میکنم نوتهای دوستان رو بخونم و ادیت کنم و در نهایت یک نوت ادغام شده از هر مطلب داشته باشیم.
خلاصه که آقا همش Fun و عشق و صفاست.
GitHub
GitHub - yasaminashoori/CS_ReadingClub: A club for reading cool papers
A club for reading cool papers . Contribute to yasaminashoori/CS_ReadingClub development by creating an account on GitHub.
Forwarded from Python Hints
توی معماری سیستم یک اصطلاحی داریم به اسم؛
که خب یک
معماری سیستم مثلاً قرار بوده micro-service باشه؛ در نگاه اول هم هست و حتی از تمام ابزارهای لازم هم داره استفاده میشه اما به اشتباه.
کل سیستم رو امروز کنار هم چیدم و روی یک سرور بالا آوردم (بجای چندتا سرور) و تبدیلش کردم به
البته من مطمئن بودم که اینطوری میشه به سه دلیل :
۱- به وضوح
۲- تعداد درخواستهای بین سرویسها زیاد بود
۳- خیلی از زمان پروفایلنگ، برای درخواست بین سرویسها هدر میرفت روی نتورک. (که خب حتی
این موضوع دلیلی شد؛ بیام چندتا تعریف اشتباه که دائم میشنوم رو انتقال بدم:
۱- توی ماکروسرویس هر سرویس باید دیتابیس جدا داشته باشه.
این تعریف درسته، اما تفسیر غلط ازش زیاده؛ مثلاً ۹۹٪ فکر میکنند این یعنی برای هر سرویس باید یک سرور
مثلاً سرویس
۲- هر تابع، متد یا ... باید
بله درسته، این یکی از موارد مهم هست اما تفسیر اشتباه ازش زیاده، مثلاً:
فرض کنید سرویس payment بالا، بعد از اینکه پرداخت انجام شد باید به بخش انبارداری تیکت بزنیم که پرداخت موفق بوده موجودی رو کم کن، به بخش حسابداری بزنیم که فاکتور صادر شده پرداخت شد و مثلاً به بخش ارسال کالا هم بگیم چیو بستهبندی و ارسال کنه به چه آدرسی ...
اینو دیدم که میگم، به طرف میگم، خب عالی توابع اینکارها رو بذار یکجا داخل یک تابع و درخواست بده اگر مشکلی توی پرداخت پیش اومد همه باهم باید
یک ساعت داشتم براش توضیح میدم؛ که این تابع SRP رو رعایت میکنه چون تو فقط داری میگی من پول رو پرداخت کردم موفق بود یا نه.
۳- ماکروسرویس بهتره ...
نه چون یک چیزی سختتر هست پیادهسازیش لزوماً بهتر نیست، بسیار بسیار پروژه دیدم که گفتم خب همهی چیزایی که اینا لازم دارن اگر
چندتا برداشت اشتباه دیگه هم بود که متأسفانه یادم نیست دیگه، ولی تبدیل سیستم به یک
حتی برای مرحله بعدی هم پیشنهاد کردم اول سراغ
و بالا آوردن چندتا
نهایتاً؛ البته من میدونم خیلی از این برداشتهای اشتباه از کجا میاد.
منابع ترجمه شده به فارسی.
ترجمه اشتباه لغوی یک کلمه، باعث میشه معنی یک جمله بطور کامل عوض بشه.
distributed monolithicکه خب یک
anti-pattern هست برای معماری micro-service اول هفته با یک شرکتی برای مشاوره صحبت کردیم (کارشون رو قبول نکردم ولی یک قرارداد کوچک بستم برای اینکه بگم مشکل فعلی سیستم کجاس) معماری سیستم مثلاً قرار بوده micro-service باشه؛ در نگاه اول هم هست و حتی از تمام ابزارهای لازم هم داره استفاده میشه اما به اشتباه.
کل سیستم رو امروز کنار هم چیدم و روی یک سرور بالا آوردم (بجای چندتا سرور) و تبدیلش کردم به
multi app monolithic اولش خیلی ناراحت و نگران بودند که پرفورمنس خراب میشه و ازین حرفا ولی بعد توی تستها دیدند که حداقل ۲ برابر سرعت پاسخ و تعداد درخواستهایی که هندل میشه بیشتره.البته من مطمئن بودم که اینطوری میشه به سه دلیل :
۱- به وضوح
anti pattern رو میدیدم۲- تعداد درخواستهای بین سرویسها زیاد بود
۳- خیلی از زمان پروفایلنگ، برای درخواست بین سرویسها هدر میرفت روی نتورک. (که خب حتی
async هم نبود که حداقل cpu هدر نره) این موضوع دلیلی شد؛ بیام چندتا تعریف اشتباه که دائم میشنوم رو انتقال بدم:
۱- توی ماکروسرویس هر سرویس باید دیتابیس جدا داشته باشه.
این تعریف درسته، اما تفسیر غلط ازش زیاده؛ مثلاً ۹۹٪ فکر میکنند این یعنی برای هر سرویس باید یک سرور
Postgres جدا داشته باشند، نه لزوماً مفهوم این تعریف اینه که: مثلاً سرویس
auth شما نره دیتای سرویس payment رو بخونه حتی اگر جفتشون روی یک دیتابیس هستند (فقط دوتا تیبل جداشده) و برای گرفتن دیتای مورد نیازش به سرویس payment درخواست بده۲- هر تابع، متد یا ... باید
single responsibility داشته باشه.بله درسته، این یکی از موارد مهم هست اما تفسیر اشتباه ازش زیاده، مثلاً:
فرض کنید سرویس payment بالا، بعد از اینکه پرداخت انجام شد باید به بخش انبارداری تیکت بزنیم که پرداخت موفق بوده موجودی رو کم کن، به بخش حسابداری بزنیم که فاکتور صادر شده پرداخت شد و مثلاً به بخش ارسال کالا هم بگیم چیو بستهبندی و ارسال کنه به چه آدرسی ...
اینو دیدم که میگم، به طرف میگم، خب عالی توابع اینکارها رو بذار یکجا داخل یک تابع و درخواست بده اگر مشکلی توی پرداخت پیش اومد همه باهم باید
rollback بخوره (توجه به بحث قبل شما حق نداری، تیبل سرویسهای دیگه رو دستکاری کنی)؛ برگشته میگه پس Single Responsiblity چی میشه ؟یک ساعت داشتم براش توضیح میدم؛ که این تابع SRP رو رعایت میکنه چون تو فقط داری میگی من پول رو پرداخت کردم موفق بود یا نه.
۳- ماکروسرویس بهتره ...
نه چون یک چیزی سختتر هست پیادهسازیش لزوماً بهتر نیست، بسیار بسیار پروژه دیدم که گفتم خب همهی چیزایی که اینا لازم دارن اگر
monolithic بود، هم سریعتر بود هم سرعت توسعهاش بیشتر بود هم نیاز به این همه دولوپر نداشت.چندتا برداشت اشتباه دیگه هم بود که متأسفانه یادم نیست دیگه، ولی تبدیل سیستم به یک
monolithic واقعی توی این پروژه نتایج خیلی بهتری داشت.حتی برای مرحله بعدی هم پیشنهاد کردم اول سراغ
Load balanceو بالا آوردن چندتا
instance از همین monolithic برند، بعد برای تبدیل به micro-sercive از یکی که معماری رو واقعاً بلد هست کمک بگیرند نه کسی که پوشه پوشه کردن فایلای پایتونش رو فقط یاد گرفته.نهایتاً؛ البته من میدونم خیلی از این برداشتهای اشتباه از کجا میاد.
منابع ترجمه شده به فارسی.
ترجمه اشتباه لغوی یک کلمه، باعث میشه معنی یک جمله بطور کامل عوض بشه.
Forwarded from نوشتههای ترمینالی
https://www.youtube.com/watch?v=DbhYpx70zTY
ویدیو جالبی بود در مورد سطح های متفاوت کاربرد LLM برای برنامه نویس های جونیور تا سنیور
آیا هوش مصنوعی جایگزین ما میشود؟ فعلا فقط جونیور ها
ویدیو جالبی بود در مورد سطح های متفاوت کاربرد LLM برای برنامه نویس های جونیور تا سنیور
آیا هوش مصنوعی جایگزین ما میشود؟ فعلا فقط جونیور ها
YouTube
The More Senior You Get, The Worse LLMs Become?
To try everything Brilliant has to offer—free—for a full 30 days, visit https://brilliant.org/TravisMedia/ . You’ll also get 20% off an annual premium subscription.
Today we're going to look at an article that made me rethink how I view the impact of LLMs…
Today we're going to look at an article that made me rethink how I view the impact of LLMs…
Forwarded from DevTwitter | توییت برنامه نویسی
اخیراً برای ساخت پنل کاربری در یکی از پروژههام از Filament استفاده کردم و تجربه متفاوتی بود.
برخلاف AdminLTE که نیاز به شخصیسازی سنگین دارن، Filament روی لاراول با چند خط کد یه پنل کامل بهم داد؛
مثلا با دستور make:filament-resource نهتنها CRUD مدل ساخته میشه، بلکه فرمها، جدولها، فیلترها و حتی bulk action ها رو بهصورت پیشفرض برات میسازه.
چیزی که برای من جذاب بود، هماهنگی مستقیم Filament با Policies لاراول و همینطور پشتیبانی از Spatie Permission برای role/permission بود؛ یعنی میتونید بهجای workaround، امنیت و سطح دسترسی رو طبق best practice خود لاراول پیاده کنید.
برای دولوپرهای جوونیور و میدلول، کار با Filament بهترین فرصت برای لمس معماری تمیز، درک بهتر authorization و ساخت سریع feature های واقعی توی پروژههای production هست.
@DevTwitter | <ehsan azizi/>
برخلاف AdminLTE که نیاز به شخصیسازی سنگین دارن، Filament روی لاراول با چند خط کد یه پنل کامل بهم داد؛
مثلا با دستور make:filament-resource نهتنها CRUD مدل ساخته میشه، بلکه فرمها، جدولها، فیلترها و حتی bulk action ها رو بهصورت پیشفرض برات میسازه.
چیزی که برای من جذاب بود، هماهنگی مستقیم Filament با Policies لاراول و همینطور پشتیبانی از Spatie Permission برای role/permission بود؛ یعنی میتونید بهجای workaround، امنیت و سطح دسترسی رو طبق best practice خود لاراول پیاده کنید.
برای دولوپرهای جوونیور و میدلول، کار با Filament بهترین فرصت برای لمس معماری تمیز، درک بهتر authorization و ساخت سریع feature های واقعی توی پروژههای production هست.
@DevTwitter | <ehsan azizi/>
Forwarded from Gopher Academy
زک یادگاری، مدیرعامل ۱۸ سالهای که ماهانه ۱٫۵ میلیون دلار درآمد دارد - زومیت
https://www.zoomit.ir/business/447742-cal-ai-app-featured/
https://www.zoomit.ir/business/447742-cal-ai-app-featured/
زومیت
زک یادگاری، مدیرعامل ۱۸ سالهای که ماهانه ۱٫۵ میلیون دلار درآمد دارد - زومیت
زک یادگاری از ۷ سالگی کدنویسی را شروع کرد و حالا با هوش مصنوعی، اپلیکیشنی توسعه داده که ماهانه حدود ۱٫۴ میلیون دلار درآمد ناخالص برایش به همراه دارد.
Forwarded from محتوای آزاد سهراب (Sohrab)
Forwarded from IRCF | اینترنت آزاد برای همه
پسکوچه اخیرا Baba VPN و Giti VPN رو بهعنوان دو #فیلترشکن ناامن یا مشکوک معرفی کرده. این برنامهها از طریق گوگلپلی عرضه شدن و آمار نصب بالایی دارن، که نقصها و حفرههای امنیتی اونها کاربران زیادی رو در معرض خطر قرار داده.
برنامههای دیگری رو هم در بررسیهای قبلی بهعنوان ناامن یا مشکوک معرفی کرده بودن، که توصیه میشه احتیاط کنید:
KLID SABZ VPN / Verde VPN / Azad VPN / Canary VPN / Agile VPN / Golnar VPN / Dali VPN / Sai VPN / Bonbast VPN / HaloVPN / Rooz VPN / Tiger VPN / Ultraunique VPN / Alvand VPN / V2ray VPN / Bean VPN / 77 VPN / Ram VPN / Hula VPN / JumpJump VPN ...
🔍 ircf.space
@ircfspace
برنامههای دیگری رو هم در بررسیهای قبلی بهعنوان ناامن یا مشکوک معرفی کرده بودن، که توصیه میشه احتیاط کنید:
KLID SABZ VPN / Verde VPN / Azad VPN / Canary VPN / Agile VPN / Golnar VPN / Dali VPN / Sai VPN / Bonbast VPN / HaloVPN / Rooz VPN / Tiger VPN / Ultraunique VPN / Alvand VPN / V2ray VPN / Bean VPN / 77 VPN / Ram VPN / Hula VPN / JumpJump VPN ...
🔍 ircf.space
@ircfspace
Forwarded from IRCF | اینترنت آزاد برای همه
#گزارش
کلودفلر در هفتههای اخیر تغییراتی اعمال کرده که بخش بزرگی از کاربران را تحت تأثیر قرار داده. این تغییرات ابتدا با محدودسازی Workers آغاز شد، اما خیلی زود دامنه آن به پروکسیهای ساده پشت CDN مانند WebSocket و gRPC هم رسید. نتیجه این سیاستها برای مهساسرور جهش بیسابقه در حجم ترافیک، فشار سنگین بر کانفیگهای غیرورکری و افزایش گزارشهای Abuse برای دامنهها بود.
این محدودیتها احتمالاً چند عامل مختلف دارند. یکی فشار مالی و تلاش برای سوق دادن کاربران به سرویسهای پولی پیش از انتشار گزارشهای مالی است. همچنین ترافیک سنگین کاربران ایرانی، بهویژه از مسیر دیتاسنتر آلمان و در حوالی رویدادهای حساس سیاسی، ممکن است شرکت را مجبور به اعمال محدودیتهای تازه کرده باشد. افزایش سوءاستفادهها و بازنگری در سیاست تفکیک منابع رایگان از پولی نیز نقش دارند، ضمن اینکه کلودفلر بهعنوان یک شرکت آمریکایی ملزم به رعایت تحریمها و مقررات قانونی است. تغییر شیوه شمارش درخواستها هم میتواند دلیلی فنی برای محدودیتها باشد.
پیامدهای این سیاستها فقط فنی نیستند؛ کاربران ایرانی فشار مضاعف را تجربه میکنند، دسترسی پایدار به اینترنت آزاد محدودتر میشود و وابستگی به کانفیگهای شکننده افزایش یافته و خطر قطعی گسترده بیشتر میشود.
متن کامل گزارش:
👉 mahsanet.com/fa/blog/11/new-cloudflare-limitations
🔍 ircf.space
@ircfspace
کلودفلر در هفتههای اخیر تغییراتی اعمال کرده که بخش بزرگی از کاربران را تحت تأثیر قرار داده. این تغییرات ابتدا با محدودسازی Workers آغاز شد، اما خیلی زود دامنه آن به پروکسیهای ساده پشت CDN مانند WebSocket و gRPC هم رسید. نتیجه این سیاستها برای مهساسرور جهش بیسابقه در حجم ترافیک، فشار سنگین بر کانفیگهای غیرورکری و افزایش گزارشهای Abuse برای دامنهها بود.
این محدودیتها احتمالاً چند عامل مختلف دارند. یکی فشار مالی و تلاش برای سوق دادن کاربران به سرویسهای پولی پیش از انتشار گزارشهای مالی است. همچنین ترافیک سنگین کاربران ایرانی، بهویژه از مسیر دیتاسنتر آلمان و در حوالی رویدادهای حساس سیاسی، ممکن است شرکت را مجبور به اعمال محدودیتهای تازه کرده باشد. افزایش سوءاستفادهها و بازنگری در سیاست تفکیک منابع رایگان از پولی نیز نقش دارند، ضمن اینکه کلودفلر بهعنوان یک شرکت آمریکایی ملزم به رعایت تحریمها و مقررات قانونی است. تغییر شیوه شمارش درخواستها هم میتواند دلیلی فنی برای محدودیتها باشد.
پیامدهای این سیاستها فقط فنی نیستند؛ کاربران ایرانی فشار مضاعف را تجربه میکنند، دسترسی پایدار به اینترنت آزاد محدودتر میشود و وابستگی به کانفیگهای شکننده افزایش یافته و خطر قطعی گسترده بیشتر میشود.
متن کامل گزارش:
👉 mahsanet.com/fa/blog/11/new-cloudflare-limitations
🔍 ircf.space
@ircfspace
Forwarded from Reza Jafari
نگاهی بر مقاله تازه انویدیا، چرا آینده Agentic AI دست مدلهای کوچیکه؟
ین روزها بحث زیادی هست که آیندهی Agentic AI نه با مدلهای خیلی بزرگ (LLM) بلکه با مدلهای کوچکتر یا همون SLMها رقم میخوره. مقالهی تازهای هم از شرکت NVIDIA منتشر شده که دقیقاً همین موضوع رو توضیح میده و سه دلیل اصلی براش میاره: قدرت کافی، صرفهجویی اقتصادی و انطباق عملیاتی.
اول از نظر قدرت. خیلیها تصور میکنن برای ساخت یک ایجنت همیشه باید از یک مدل خیلی عظیم استفاده کنیم، اما واقعیت اینه که بیشتر کارهایی که یک ایجنت انجام میده چندان پیچیده نیست. عمدهی وظایف به انتخاب ابزار مناسب برمیگرده؛ یعنی تصمیم بگیره از بین چند ابزار، کدوم یکی باید بهکار گرفته بشه. این در عمل شبیه یک مسئلهی دستهبندی (classification) هست، نه نوشتن مقالهی طولانی یا حل یک معادلهی سخت. ایجنتها بیشتر به تواناییهایی مثل دنبالکردن دستورالعملها، تولید کدهای کوتاه، استدلال ساده و درک متن نیاز دارن. بنابراین بهکارگیری یک مدل غولآسا برای چنین کاری مثل اینه که برای دوختن یک لباس سوزن بخوای از شمشیر استفاده کنی.
از نظر اقتصادی، تفاوتها چشمگیره. اجرای یک مدل ۷ میلیارد پارامتری بین ۱۰ تا ۳۰ برابر ارزونتر از اجرای یک مدل ۷۰ میلیاردی تموم میشه. این تفاوت فقط در هزینهی سختافزار و سرویسهای ابری نیست، بلکه مصرف انرژی کمتر، نیاز به زیرساخت سبکتر و حتی امکان اجرا روی دستگاههای لوکال مثل رایانهی شخصی یا لپتاپ رو هم شامل میشه. علاوه بر این، چون SLMها کوچکتر هستن، آموزش و فاینتیون کردنشون داده و زمان کمتری لازم داره. همین موضوع باعث میشه چرخهی آزمایش و بهبود خیلی سریعتر پیش بره و توسعهدهندهها راحتتر ایدههاشون رو امتحان کنن. به بیان ساده، این مدلها ماژولار و قابل تعویض هستن و هزینهی تکرار و آزمایش رو پایین میآرن.
از نظر انطباق عملیاتی هم SLMها برتریهای مهمی دارن. ایجنتها معمولاً فقط از بخش کوچکی از قابلیتهای LLM استفاده میکنن. مثلاً تولید یک خروجی JSON تمیز یا برقراری ارتباط درست با یک API. در این موارد، مدلهای کوچکتر هم دقیقتر و هم مطمئنتر عمل میکنن. یکی از مشکلات مدلهای بزرگ، خطاهای موسوم به «توهم» یا همون hallucination هست. اما SLMها چون برای وظایف محدودتر آموزش میبینن، خروجیشون سازگارتر و قابل اعتمادتره. نتیجه اینه که فرمت خروجی ثابت میمونه، ابزار و کد راحتتر یکپارچه میشن و ارتباط با APIها بدون خطا انجام میشه. NVIDIA حتی پیشنهاد داده که بهترین روش استفادهی ترکیبیه: یعنی LLM برای مرحلهی برنامهریزی و SLM برای مرحلهی اجرا. اینطوری هم قدرت استدلال مدل بزرگ رو داری و هم سرعت و دقت مدل کوچک رو.
یکی از نوآوریهای جالبی که در این مقاله مطرح شده، چرخهی تبدیل LLM به SLM هست. ایده اینه که اول کار رو با یک مدل بزرگ عمومی شروع میکنی و همهی دادههای مربوط به تعامل کاربران رو ثبت میکنی. بعد این دادهها رو دستهبندی (خوشهبندی) میکنی و میبینی وظایف به چند گروه تقسیم میشن. حالا به جای استفادهی همیشگی از همون LLM، برای هر دسته یک SLM تخصصی طراحی میکنی و جایگزینش میکنی. این کار باعث میشه سیستم هم ارزانتر بشه، هم سریعتر، هم خروجی دقیقتر تولید کنه. از طرف دیگه، هر تعامل کاربر دادهی تازهای تولید میکنه که میتونه برای آموزش دوبارهی همین مدلهای کوچک به کار بره. در نتیجه، یک چرخهی بهبود مستمر شکل میگیره که سیستم رو روزبهروز بهتر میکنه.
با وجود این همه مزایا، هنوز خیلی از شرکتها سراغ مدلهای بزرگ میرن. دلیل اصلی هم سرمایهگذاریهای سنگین روی زیرساختهای LLM و همینطور نوع معیارهایی هست که برای ارزیابی SLM استفاده میشه. معمولاً این ارزیابیها روی تواناییهای خیلی پیچیده مثل استدلال چندمرحلهای متمرکز هستن، در حالی که معیار واقعی در Agentic AI باید چیزهایی مثل دقت در انتخاب ابزار یا پایداری تعامل با API باشه.
در نهایت میشه گفت که SLMها هم قدرت کافی دارن، هم اقتصادی هستن و هم عملیاتی. ایجنتها بیشتر از همه به دقت، تمرکز و سازگاری نیاز دارن، نه به یک مدل همهفنحریف. بنابراین آیندهی Agentic AI نه با مدلهای غولآسا و پرهزینه، بلکه با مدلهای کوچک، تخصصی و ماژولار ساخته خواهد شد.
🔤 🔤 🔤 🔤 🔤 🔤 🔤
🥇 اهورا اولین اپراتور هوش مصنوعی راهبردی ایران در حوزه ارائه خدمات و سرویسهای زیرساخت هوش مصنوعی
🛍 کد تخفیف ۱۰ درصدی محصولات اهورا برای اعضای کانال
🌐 لینک وبسایت اهورا
@reza_jafari_ai
ین روزها بحث زیادی هست که آیندهی Agentic AI نه با مدلهای خیلی بزرگ (LLM) بلکه با مدلهای کوچکتر یا همون SLMها رقم میخوره. مقالهی تازهای هم از شرکت NVIDIA منتشر شده که دقیقاً همین موضوع رو توضیح میده و سه دلیل اصلی براش میاره: قدرت کافی، صرفهجویی اقتصادی و انطباق عملیاتی.
اول از نظر قدرت. خیلیها تصور میکنن برای ساخت یک ایجنت همیشه باید از یک مدل خیلی عظیم استفاده کنیم، اما واقعیت اینه که بیشتر کارهایی که یک ایجنت انجام میده چندان پیچیده نیست. عمدهی وظایف به انتخاب ابزار مناسب برمیگرده؛ یعنی تصمیم بگیره از بین چند ابزار، کدوم یکی باید بهکار گرفته بشه. این در عمل شبیه یک مسئلهی دستهبندی (classification) هست، نه نوشتن مقالهی طولانی یا حل یک معادلهی سخت. ایجنتها بیشتر به تواناییهایی مثل دنبالکردن دستورالعملها، تولید کدهای کوتاه، استدلال ساده و درک متن نیاز دارن. بنابراین بهکارگیری یک مدل غولآسا برای چنین کاری مثل اینه که برای دوختن یک لباس سوزن بخوای از شمشیر استفاده کنی.
از نظر اقتصادی، تفاوتها چشمگیره. اجرای یک مدل ۷ میلیارد پارامتری بین ۱۰ تا ۳۰ برابر ارزونتر از اجرای یک مدل ۷۰ میلیاردی تموم میشه. این تفاوت فقط در هزینهی سختافزار و سرویسهای ابری نیست، بلکه مصرف انرژی کمتر، نیاز به زیرساخت سبکتر و حتی امکان اجرا روی دستگاههای لوکال مثل رایانهی شخصی یا لپتاپ رو هم شامل میشه. علاوه بر این، چون SLMها کوچکتر هستن، آموزش و فاینتیون کردنشون داده و زمان کمتری لازم داره. همین موضوع باعث میشه چرخهی آزمایش و بهبود خیلی سریعتر پیش بره و توسعهدهندهها راحتتر ایدههاشون رو امتحان کنن. به بیان ساده، این مدلها ماژولار و قابل تعویض هستن و هزینهی تکرار و آزمایش رو پایین میآرن.
از نظر انطباق عملیاتی هم SLMها برتریهای مهمی دارن. ایجنتها معمولاً فقط از بخش کوچکی از قابلیتهای LLM استفاده میکنن. مثلاً تولید یک خروجی JSON تمیز یا برقراری ارتباط درست با یک API. در این موارد، مدلهای کوچکتر هم دقیقتر و هم مطمئنتر عمل میکنن. یکی از مشکلات مدلهای بزرگ، خطاهای موسوم به «توهم» یا همون hallucination هست. اما SLMها چون برای وظایف محدودتر آموزش میبینن، خروجیشون سازگارتر و قابل اعتمادتره. نتیجه اینه که فرمت خروجی ثابت میمونه، ابزار و کد راحتتر یکپارچه میشن و ارتباط با APIها بدون خطا انجام میشه. NVIDIA حتی پیشنهاد داده که بهترین روش استفادهی ترکیبیه: یعنی LLM برای مرحلهی برنامهریزی و SLM برای مرحلهی اجرا. اینطوری هم قدرت استدلال مدل بزرگ رو داری و هم سرعت و دقت مدل کوچک رو.
یکی از نوآوریهای جالبی که در این مقاله مطرح شده، چرخهی تبدیل LLM به SLM هست. ایده اینه که اول کار رو با یک مدل بزرگ عمومی شروع میکنی و همهی دادههای مربوط به تعامل کاربران رو ثبت میکنی. بعد این دادهها رو دستهبندی (خوشهبندی) میکنی و میبینی وظایف به چند گروه تقسیم میشن. حالا به جای استفادهی همیشگی از همون LLM، برای هر دسته یک SLM تخصصی طراحی میکنی و جایگزینش میکنی. این کار باعث میشه سیستم هم ارزانتر بشه، هم سریعتر، هم خروجی دقیقتر تولید کنه. از طرف دیگه، هر تعامل کاربر دادهی تازهای تولید میکنه که میتونه برای آموزش دوبارهی همین مدلهای کوچک به کار بره. در نتیجه، یک چرخهی بهبود مستمر شکل میگیره که سیستم رو روزبهروز بهتر میکنه.
با وجود این همه مزایا، هنوز خیلی از شرکتها سراغ مدلهای بزرگ میرن. دلیل اصلی هم سرمایهگذاریهای سنگین روی زیرساختهای LLM و همینطور نوع معیارهایی هست که برای ارزیابی SLM استفاده میشه. معمولاً این ارزیابیها روی تواناییهای خیلی پیچیده مثل استدلال چندمرحلهای متمرکز هستن، در حالی که معیار واقعی در Agentic AI باید چیزهایی مثل دقت در انتخاب ابزار یا پایداری تعامل با API باشه.
در نهایت میشه گفت که SLMها هم قدرت کافی دارن، هم اقتصادی هستن و هم عملیاتی. ایجنتها بیشتر از همه به دقت، تمرکز و سازگاری نیاز دارن، نه به یک مدل همهفنحریف. بنابراین آیندهی Agentic AI نه با مدلهای غولآسا و پرهزینه، بلکه با مدلهای کوچک، تخصصی و ماژولار ساخته خواهد شد.
AHURA5@reza_jafari_ai
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from a pessimistic researcher (Kc)
فرازی از بیوگرافی آقای Apt ( متن کپی شده از روی وبسایتشون )
Krzysztof Apt studied mathematics in Wroclaw, Poland and got his PhD in mathematical logic in 1974, in Warsaw, Poland. "But the communism was not a very inspiring political system so already in the Fall of 1974 I voted with my feet and left the country for good", he explains. "It was not easy in those times of bipolar world to settle down abroad, but somehow I succeeded without giving up my interest in science. I learned computer science and more recently, game theory, so to say, 'on the street', which was possible because of my background in mathematics."
Krzysztof Apt studied mathematics in Wroclaw, Poland and got his PhD in mathematical logic in 1974, in Warsaw, Poland. "But the communism was not a very inspiring political system so already in the Fall of 1974 I voted with my feet and left the country for good", he explains. "It was not easy in those times of bipolar world to settle down abroad, but somehow I succeeded without giving up my interest in science. I learned computer science and more recently, game theory, so to say, 'on the street', which was possible because of my background in mathematics."
Forwarded from DevTwitter | توییت برنامه نویسی
هر روز که میگذره MCP داره بیشتر و بیشتر پر اهمیت میشه تو دنیای LLM ها.
و الان هم Openai داره داخل Chatgpt قابلیت اتصال به MCP شخصی رو تست میکنه و در اختیار DEV ها قرار میده.
اگر هنوز از MCP اطلاعی ندارید این راهنمای ۵ دقیقه ای ماکس ایده خوبی به شما میده
https://maux.site/learn/mcp
@DevTwitter | <Mani/>
و الان هم Openai داره داخل Chatgpt قابلیت اتصال به MCP شخصی رو تست میکنه و در اختیار DEV ها قرار میده.
اگر هنوز از MCP اطلاعی ندارید این راهنمای ۵ دقیقه ای ماکس ایده خوبی به شما میده
https://maux.site/learn/mcp
@DevTwitter | <Mani/>
Forwarded from a pessimistic researcher (Kc)
کاش میفهمیدم که از این زندگی چی میخوام و دنبال چیام
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)