Forwarded from Md Daily (Mahan)
داشتم یه پست از Nimrod Kramer میخوندم، میگفت:
کافیه دیگه. مهندسی پرامپت، مهندسی نیست. (Prompt engineering is not engineering)
چسبوندن کلمهی «مهندسی» به «نوشتن پرامپت»، مثل اینه که به مهندسی اجتماعی بگیم یک شاخه از مهندسی نرمافزار. مسخره است، ولی به طرز عجیبی برای معتبر نشون دادنِ کار، جواب میده.
بیاین روراست باشیم... نوشتن یه پرامپت خوب برای هوش مصنوعی میتونه هوشمندانه، نکتهسنجانه و حتی هنرمندانه باشه. اما این مهندسی نیست. نه طراحی سیستمی در کاره، نه ریاضیاتی، نه تکرارپذیری و نه منطقِ قابل آزمایش. فقط آزمون و خطاست و (گاهی وقتا) حس و حال.
این کار بیشتر به وِرد خوندن شبیهه تا توسعه نرمافزار.
«مهندسی» خطاب کردنش، یکی از بزرگترین دروغهای تبلیغاتیه از وقتی که پای هوش مصنوعی به زندگی ما باز شد. این عنوان، یه کار ساده مثل تبلیغنویسی رو به یه شغل با حقوقهای نجومی تبدیل کرد. باعث شد آدما فکر کنن دارن سیستم میسازن، در حالی که فقط داشتن با مدلهای زبان بزرگ (LLMها) وَر میرفتن.
بله، پرامپت نوشتن میتونه کار مهمی باشه. اما اگه به این کار ادامه بدیم و بهش بگیم مهندسی، داریم هم به خودمون دروغ میگیم و هم به نسل بعدی توسعهدهندهها که سعی دارن بفهمن تسلط فنی واقعی یعنی چی.
بیاید به کلمات احترام بذاریم. هر چیزی که بوی تکنولوژی میده، لازم نیست لباس مهندسی تنش کنه.
---
💡 مثل همیشه کنجکاو بمونید :)
🆔 @MdDaily
کافیه دیگه. مهندسی پرامپت، مهندسی نیست. (Prompt engineering is not engineering)
چسبوندن کلمهی «مهندسی» به «نوشتن پرامپت»، مثل اینه که به مهندسی اجتماعی بگیم یک شاخه از مهندسی نرمافزار. مسخره است، ولی به طرز عجیبی برای معتبر نشون دادنِ کار، جواب میده.
بیاین روراست باشیم... نوشتن یه پرامپت خوب برای هوش مصنوعی میتونه هوشمندانه، نکتهسنجانه و حتی هنرمندانه باشه. اما این مهندسی نیست. نه طراحی سیستمی در کاره، نه ریاضیاتی، نه تکرارپذیری و نه منطقِ قابل آزمایش. فقط آزمون و خطاست و (گاهی وقتا) حس و حال.
این کار بیشتر به وِرد خوندن شبیهه تا توسعه نرمافزار.
«مهندسی» خطاب کردنش، یکی از بزرگترین دروغهای تبلیغاتیه از وقتی که پای هوش مصنوعی به زندگی ما باز شد. این عنوان، یه کار ساده مثل تبلیغنویسی رو به یه شغل با حقوقهای نجومی تبدیل کرد. باعث شد آدما فکر کنن دارن سیستم میسازن، در حالی که فقط داشتن با مدلهای زبان بزرگ (LLMها) وَر میرفتن.
بله، پرامپت نوشتن میتونه کار مهمی باشه. اما اگه به این کار ادامه بدیم و بهش بگیم مهندسی، داریم هم به خودمون دروغ میگیم و هم به نسل بعدی توسعهدهندهها که سعی دارن بفهمن تسلط فنی واقعی یعنی چی.
بیاید به کلمات احترام بذاریم. هر چیزی که بوی تکنولوژی میده، لازم نیست لباس مهندسی تنش کنه.
---
🆔 @MdDaily
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Hamed
🚀 ترجمهی فارسی کتاب C# 12 in a Nutshell رو شروع کردم و روی GitHub منتشرش کردم:
🔗https://github.com/hheydarian/csharp-12-in-a-nutshell-persian
این کتاب یکی از کامل ترین منابع برای یادگیری و تسلط بر زبان #CSharp هست.
اگه علاقه مندید یه مرجع فارسی خوب و دقیق برای #CSharp بسازیم، خوشحال میشم همراه بشید.
میتونید فورک بگیرید، مشارکت کنید و به بهتر شدنش کمک کنید 💡
#CSharp #GitHub
#OpenSource #Net
🔗https://github.com/hheydarian/csharp-12-in-a-nutshell-persian
این کتاب یکی از کامل ترین منابع برای یادگیری و تسلط بر زبان #CSharp هست.
اگه علاقه مندید یه مرجع فارسی خوب و دقیق برای #CSharp بسازیم، خوشحال میشم همراه بشید.
میتونید فورک بگیرید، مشارکت کنید و به بهتر شدنش کمک کنید 💡
#CSharp #GitHub
#OpenSource #Net
Forwarded from DevTwitter | توییت برنامه نویسی
پردازش ۱.۲ میلیون پیام در ثانیه با Kafka و Go — معماری سبک اما حرفهای
وقتی نرخ ورود داده به میلیونها پیام در ثانیه میرسد، عامل تعیینکننده در یک معماری بهینه و سریع و موثر، نه ارتقای پرهزینهی سختافزار است و نه تکیه بر زیرساختهای سنگین ابری، بلکه یک طراحی دقیق، ساده و هوشمندانه است که میتواند تفاوت واقعی را رقم بزند.
اخیراً با مقالهای مواجه شدم که دقیقاً همین رویکرد را نشان میداد: تیمی که با استفاده از مفاهیم سبکوزن مانند goroutine در Go و چند تصمیم مهندسیشده، توانسته بودند تنها با یک سختافزار معمولی، بیش از ۱ میلیون پیام در ثانیه را بهصورت پایدار پردازش کنند.
در این پست، به مرور نکات کلیدی این معماری ساده اما تأثیرگذار میپردازیم — روایتی کاربردی از دنیای مهندسی داده و سیستمهای توزیعشده.
مقاله اصلی:
Kafka at 1M Messages/Second with Go – Our Exact Pipeline Setup
چالشها:
- هجوم سنگین دادهها از دستگاههای IoT و کاربران
- نیاز به پردازش بلادرنگ و ارسال همزمان به چند سرویس
- تضمین پایداری، مانیتورینگ دقیق و ریکاوری خودکار در خطا
مکانیزمهایی که این معماری را ممکن کردند:
- کامیت دستی offsetها:
تأیید دریافت فقط زمانی انجام میشود که پیام کاملاً و با موفقیت پردازش شده باشد — جلوگیری از گمشدن یا پردازش تکراری دادهها.
- مکانیزم Worker Pool کنترلشده با goroutine:
بهجای ایجاد goroutine برای هر پیام، یک استخر ثابت از goroutineها (به ازای هر پارتیشن کافکا) با طول کانال مشخص و محدود، تعریف شده است که پیامها را موازی اما کنترلشده پردازش میکنند.
- یک Worker Pool به ازای هر پارتیشن Kafka:
مثلاً با ۱۰ پارتیشن و ۵ goroutine برای هر پارتیشن، در مجموع ۵۰ goroutine داریم — بدون همپوشانی، بدون رقابت اضافه.
- الگوی Dispatcher برای جداسازی دریافت از پردازش:
- بخش اول: فقط دریافت پیام و ارسال به کانال داخلی (یک کانسیومر به ازای هر پارتیشن)
- بخش دوم: پردازش پیام از صف به کمک Worker Pool
- مکانیزم Batching در ارسال خروجی:
پیامهای پردازششده بهصورت گروهی ارسال میشوند، مثلاً به دیتابیس یا تاپیکهای دیگر Kafka. این کار فشار ارتباطی را کاهش داده و throughput را بالا برده است.
- اعمال Backpressure هوشمند:
با محدود کردن ظرفیت صفها، اگر سیستم تحت فشار شدید قرار گیرد، مصرف از Kafka موقتاً کند یا متوقف میشود تا منابع آزاد شوند. این مکانیزم، از overload جلوگیری کرده و سیستم را در حالت پایدار نگه میدارد.
- مانیتورینگ دقیق با Prometheus و Grafana:
شاخصهایی مثل تأخیر پردازش، consumer lag و مصرف CPU بهصورت لحظهای مانیتور میشوند — برای تنظیم سریع و واکنش فوری.
نتایج:
- نرخ پردازش: ۱.۲M msg/sec
- تأخیر کل مسیر: <۳ms
- مصرف CPU: ۹۰٪ (پایدار و قابل پیشبینی)
نکات مهم برای مهندسان داده و سیستمهای توزیعشده:
- طراحی درست مهمتر از افزایش منابع
- انجام commit دقیق، batching و backpressure = ستونهای یک سیستم مقاوم
- تفکیک دریافت/پردازش + تقسیم کار بین پارتیشنها = مقیاسپذیری مؤثر
- مانیتورینگ لحظهای = پاسخ سریع به فشارها و خطاها
@DevTwitter | <Mojtaba Banaie/>
وقتی نرخ ورود داده به میلیونها پیام در ثانیه میرسد، عامل تعیینکننده در یک معماری بهینه و سریع و موثر، نه ارتقای پرهزینهی سختافزار است و نه تکیه بر زیرساختهای سنگین ابری، بلکه یک طراحی دقیق، ساده و هوشمندانه است که میتواند تفاوت واقعی را رقم بزند.
اخیراً با مقالهای مواجه شدم که دقیقاً همین رویکرد را نشان میداد: تیمی که با استفاده از مفاهیم سبکوزن مانند goroutine در Go و چند تصمیم مهندسیشده، توانسته بودند تنها با یک سختافزار معمولی، بیش از ۱ میلیون پیام در ثانیه را بهصورت پایدار پردازش کنند.
در این پست، به مرور نکات کلیدی این معماری ساده اما تأثیرگذار میپردازیم — روایتی کاربردی از دنیای مهندسی داده و سیستمهای توزیعشده.
مقاله اصلی:
Kafka at 1M Messages/Second with Go – Our Exact Pipeline Setup
چالشها:
- هجوم سنگین دادهها از دستگاههای IoT و کاربران
- نیاز به پردازش بلادرنگ و ارسال همزمان به چند سرویس
- تضمین پایداری، مانیتورینگ دقیق و ریکاوری خودکار در خطا
مکانیزمهایی که این معماری را ممکن کردند:
- کامیت دستی offsetها:
تأیید دریافت فقط زمانی انجام میشود که پیام کاملاً و با موفقیت پردازش شده باشد — جلوگیری از گمشدن یا پردازش تکراری دادهها.
- مکانیزم Worker Pool کنترلشده با goroutine:
بهجای ایجاد goroutine برای هر پیام، یک استخر ثابت از goroutineها (به ازای هر پارتیشن کافکا) با طول کانال مشخص و محدود، تعریف شده است که پیامها را موازی اما کنترلشده پردازش میکنند.
- یک Worker Pool به ازای هر پارتیشن Kafka:
مثلاً با ۱۰ پارتیشن و ۵ goroutine برای هر پارتیشن، در مجموع ۵۰ goroutine داریم — بدون همپوشانی، بدون رقابت اضافه.
- الگوی Dispatcher برای جداسازی دریافت از پردازش:
- بخش اول: فقط دریافت پیام و ارسال به کانال داخلی (یک کانسیومر به ازای هر پارتیشن)
- بخش دوم: پردازش پیام از صف به کمک Worker Pool
- مکانیزم Batching در ارسال خروجی:
پیامهای پردازششده بهصورت گروهی ارسال میشوند، مثلاً به دیتابیس یا تاپیکهای دیگر Kafka. این کار فشار ارتباطی را کاهش داده و throughput را بالا برده است.
- اعمال Backpressure هوشمند:
با محدود کردن ظرفیت صفها، اگر سیستم تحت فشار شدید قرار گیرد، مصرف از Kafka موقتاً کند یا متوقف میشود تا منابع آزاد شوند. این مکانیزم، از overload جلوگیری کرده و سیستم را در حالت پایدار نگه میدارد.
- مانیتورینگ دقیق با Prometheus و Grafana:
شاخصهایی مثل تأخیر پردازش، consumer lag و مصرف CPU بهصورت لحظهای مانیتور میشوند — برای تنظیم سریع و واکنش فوری.
نتایج:
- نرخ پردازش: ۱.۲M msg/sec
- تأخیر کل مسیر: <۳ms
- مصرف CPU: ۹۰٪ (پایدار و قابل پیشبینی)
نکات مهم برای مهندسان داده و سیستمهای توزیعشده:
- طراحی درست مهمتر از افزایش منابع
- انجام commit دقیق، batching و backpressure = ستونهای یک سیستم مقاوم
- تفکیک دریافت/پردازش + تقسیم کار بین پارتیشنها = مقیاسپذیری مؤثر
- مانیتورینگ لحظهای = پاسخ سریع به فشارها و خطاها
@DevTwitter | <Mojtaba Banaie/>
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)
🔶 می دونی بدترین صدا در زندگی چیه؟
۱- صدای موتور سیکلت
۲- صدای اسباب بازی بچه شیبه موتور سیکلت 😂
@TheRaymondDev
۱- صدای موتور سیکلت
۲- صدای اسباب بازی بچه شیبه موتور سیکلت 😂
@TheRaymondDev
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)
🔶 به نظر میرسد شرکت راکستار در حال کار بر روی افزودن سیستم تأیید سن است و دسترسی به بازی آنلاین GTA 6 برای افراد زیر ۱۸ سال دشوارتر خواهد شد.
#خبر
@TheRaymondDev
#خبر
@TheRaymondDev
👎1
Forwarded from Gopher Academy
پردازش ۱.۲ میلیون پیام در ثانیه با Kafka و Go — معماری سبک اما حرفهای
وقتی نرخ ورود داده به میلیونها پیام در ثانیه میرسد، عامل تعیینکننده در یک معماری بهینه و سریع و موثر، نه ارتقای پرهزینهی سختافزار است و نه تکیه بر زیرساختهای سنگین ابری، بلکه یک طراحی دقیق، ساده و هوشمندانه است که میتواند تفاوت واقعی را رقم بزند.
اخیراً با مقالهای مواجه شدم که دقیقاً همین رویکرد را نشان میداد: تیمی که با استفاده از مفاهیم سبکوزن مانند goroutine در Go و چند تصمیم مهندسیشده، توانسته بودند تنها با یک سختافزار معمولی، بیش از ۱ میلیون پیام در ثانیه را بهصورت پایدار پردازش کنند.
در این پست، به مرور نکات کلیدی این معماری ساده اما تأثیرگذار میپردازیم — روایتی کاربردی از دنیای مهندسی داده و سیستمهای توزیعشده.
مقاله اصلی:
Kafka at 1M Messages/Second with Go – Our Exact Pipeline Setup
چالشها:
- هجوم سنگین دادهها از دستگاههای IoT و کاربران
- نیاز به پردازش بلادرنگ و ارسال همزمان به چند سرویس
- تضمین پایداری، مانیتورینگ دقیق و ریکاوری خودکار در خطا
مکانیزمهایی که این معماری را ممکن کردند:
- کامیت دستی offsetها:
تأیید دریافت فقط زمانی انجام میشود که پیام کاملاً و با موفقیت پردازش شده باشد — جلوگیری از گمشدن یا پردازش تکراری دادهها.
- مکانیزم Worker Pool کنترلشده با goroutine:
بهجای ایجاد goroutine برای هر پیام، یک استخر ثابت از goroutineها (به ازای هر پارتیشن کافکا) با طول کانال مشخص و محدود، تعریف شده است که پیامها را موازی اما کنترلشده پردازش میکنند.
- یک Worker Pool به ازای هر پارتیشن Kafka:
مثلاً با ۱۰ پارتیشن و ۵ goroutine برای هر پارتیشن، در مجموع ۵۰ goroutine داریم — بدون همپوشانی، بدون رقابت اضافه.
- الگوی Dispatcher برای جداسازی دریافت از پردازش:
- بخش اول: فقط دریافت پیام و ارسال به کانال داخلی (یک کانسیومر به ازای هر پارتیشن)
- بخش دوم: پردازش پیام از صف به کمک Worker Pool
- مکانیزم Batching در ارسال خروجی:
پیامهای پردازششده بهصورت گروهی ارسال میشوند، مثلاً به دیتابیس یا تاپیکهای دیگر Kafka. این کار فشار ارتباطی را کاهش داده و throughput را بالا برده است.
- اعمال Backpressure هوشمند:
با محدود کردن ظرفیت صفها، اگر سیستم تحت فشار شدید قرار گیرد، مصرف از Kafka موقتاً کند یا متوقف میشود تا منابع آزاد شوند. این مکانیزم، از overload جلوگیری کرده و سیستم را در حالت پایدار نگه میدارد.
- مانیتورینگ دقیق با Prometheus و Grafana:
شاخصهایی مثل تأخیر پردازش، consumer lag و مصرف CPU بهصورت لحظهای مانیتور میشوند — برای تنظیم سریع و واکنش فوری.
نتایج:
- نرخ پردازش: ۱.۲M msg/sec
- تأخیر کل مسیر: <۳ms
- مصرف CPU: ۹۰٪ (پایدار و قابل پیشبینی)
نکات مهم برای مهندسان داده و سیستمهای توزیعشده:
- طراحی درست مهمتر از افزایش منابع
- انجام commit دقیق، batching و backpressure = ستونهای یک سیستم مقاوم
- تفکیک دریافت/پردازش + تقسیم کار بین پارتیشنها = مقیاسپذیری مؤثر
- مانیتورینگ لحظهای = پاسخ سریع به فشارها و خطاها
| <Mojtaba Banaie/>
وقتی نرخ ورود داده به میلیونها پیام در ثانیه میرسد، عامل تعیینکننده در یک معماری بهینه و سریع و موثر، نه ارتقای پرهزینهی سختافزار است و نه تکیه بر زیرساختهای سنگین ابری، بلکه یک طراحی دقیق، ساده و هوشمندانه است که میتواند تفاوت واقعی را رقم بزند.
اخیراً با مقالهای مواجه شدم که دقیقاً همین رویکرد را نشان میداد: تیمی که با استفاده از مفاهیم سبکوزن مانند goroutine در Go و چند تصمیم مهندسیشده، توانسته بودند تنها با یک سختافزار معمولی، بیش از ۱ میلیون پیام در ثانیه را بهصورت پایدار پردازش کنند.
در این پست، به مرور نکات کلیدی این معماری ساده اما تأثیرگذار میپردازیم — روایتی کاربردی از دنیای مهندسی داده و سیستمهای توزیعشده.
مقاله اصلی:
Kafka at 1M Messages/Second with Go – Our Exact Pipeline Setup
چالشها:
- هجوم سنگین دادهها از دستگاههای IoT و کاربران
- نیاز به پردازش بلادرنگ و ارسال همزمان به چند سرویس
- تضمین پایداری، مانیتورینگ دقیق و ریکاوری خودکار در خطا
مکانیزمهایی که این معماری را ممکن کردند:
- کامیت دستی offsetها:
تأیید دریافت فقط زمانی انجام میشود که پیام کاملاً و با موفقیت پردازش شده باشد — جلوگیری از گمشدن یا پردازش تکراری دادهها.
- مکانیزم Worker Pool کنترلشده با goroutine:
بهجای ایجاد goroutine برای هر پیام، یک استخر ثابت از goroutineها (به ازای هر پارتیشن کافکا) با طول کانال مشخص و محدود، تعریف شده است که پیامها را موازی اما کنترلشده پردازش میکنند.
- یک Worker Pool به ازای هر پارتیشن Kafka:
مثلاً با ۱۰ پارتیشن و ۵ goroutine برای هر پارتیشن، در مجموع ۵۰ goroutine داریم — بدون همپوشانی، بدون رقابت اضافه.
- الگوی Dispatcher برای جداسازی دریافت از پردازش:
- بخش اول: فقط دریافت پیام و ارسال به کانال داخلی (یک کانسیومر به ازای هر پارتیشن)
- بخش دوم: پردازش پیام از صف به کمک Worker Pool
- مکانیزم Batching در ارسال خروجی:
پیامهای پردازششده بهصورت گروهی ارسال میشوند، مثلاً به دیتابیس یا تاپیکهای دیگر Kafka. این کار فشار ارتباطی را کاهش داده و throughput را بالا برده است.
- اعمال Backpressure هوشمند:
با محدود کردن ظرفیت صفها، اگر سیستم تحت فشار شدید قرار گیرد، مصرف از Kafka موقتاً کند یا متوقف میشود تا منابع آزاد شوند. این مکانیزم، از overload جلوگیری کرده و سیستم را در حالت پایدار نگه میدارد.
- مانیتورینگ دقیق با Prometheus و Grafana:
شاخصهایی مثل تأخیر پردازش، consumer lag و مصرف CPU بهصورت لحظهای مانیتور میشوند — برای تنظیم سریع و واکنش فوری.
نتایج:
- نرخ پردازش: ۱.۲M msg/sec
- تأخیر کل مسیر: <۳ms
- مصرف CPU: ۹۰٪ (پایدار و قابل پیشبینی)
نکات مهم برای مهندسان داده و سیستمهای توزیعشده:
- طراحی درست مهمتر از افزایش منابع
- انجام commit دقیق، batching و backpressure = ستونهای یک سیستم مقاوم
- تفکیک دریافت/پردازش + تقسیم کار بین پارتیشنها = مقیاسپذیری مؤثر
- مانیتورینگ لحظهای = پاسخ سریع به فشارها و خطاها
| <Mojtaba Banaie/>
Forwarded from Ninja Learn | نینجا لرن (Mohammad)
This media is not supported in your browser
VIEW IN TELEGRAM
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)
This media is not supported in your browser
VIEW IN TELEGRAM
Forwarded from DevTwitter | توییت برنامه نویسی
یک بلاگ فوق العاده راجع به اینکه دیپلوی کردن AI Agent ها توی محیط پروداکشن خیلی فرق داره با درست کردن یک دمو!
ساخت یه حلقهی ساده برای ایجنتهای مبتنی بر مدلهای زبانی (LLM agents) خیلی آسونه. شاید با کمتر از ۲۰ خط کد! ولی این سادگی در واقع مشکلات پشت پردهٔ اجرای واقعی در محیط تولید (production) رو میپوشونه.
من خلاصه مقاله را میذارم ولی باید کامل خود مقاله بخونید.
- فاصلهی پنهان بین دمو و اجرا در عمل
۱. دمو مساوی نیست با محصول واقعی: شاید توی دمو همهچی خوب پیش بره، ولی توی محیط واقعی اتفاقاتی مثل:
-از کنترل خارج شدن ایجنتها
- نشت اطلاعات توی context
- گیر کردن توی حلقههای بیپایان
- یا خراب شدن زنجیره ابزارها خیلی رایجه.
- همچنین، تصمیمگیریهای معماری مثل مدیریت context، احراز هویت ابزارها یا ذخیرهسازی state، اگر از اول درست انتخاب نشن، بعداً تغییر دادنشون کلی دردسر داره.
۲. دنیای کنفرانسها با واقعیت فرق داره: شرکتهای بزرگ ممکنه از زیرساختهای خاص خودشون برای اجرای چندایجنت بهصورت موازی استفاده میکنن. ولی اکثر تیمها کار رو سادهتر میگیرن:
- با Docker و GitHub Actions
- یا اجرای ایجنتها روی AWS Lambda فقط برای صرفهجویی ماهانه ۱۰ دلار!
۳. کی اوضاع بهم میریزه؟
وقتی لازم باشه ایجنتهاتون حافظه داشته باشن، بتونن بعد از قطع شدن ادامه بدن، یا با context طولانی کار کنن، همه چی پیچیدهتر میشه. بعضی تیمها تجربهشون رو اینطوری به اشتراک گذاشتن:
- ذخیرهی state توی دیتابیس (مثلاً PostgreSQL) برای بررسی و بازیابی
- استفاده از پردازش غیرهمزمان مثل job queue و webhook
- حذف فریمورکهای سنگین مثل LangChain و استفاده از FastAPI و کلاینت ساده OpenAI
- چیها واقعاً مهمن؟
- زیرساخت موجود: همون جایی deploy کنید که تیمتون بلده (K8s، AWS Lambda، Docker و …)
- سرعت توسعه: گاهی اینکه زود به نتیجه برسید مهمتر از طراحیهای پیچیدهست
- هزینهها: حتی صرفهجوییهای کوچیک هم مهمه، مخصوصاً برای استارتاپها
- نیازهای سازمانی برای ایجنتها
- تناقض پلتفرم: شما دنبال قدرت یه پلتفرم کامل هستید (احراز هویت، حافظه، ارزیابی)، ولی در عین حال نمیخواید به یه vendor خاص وابسته بشید. استانداردهایی مثل MCP دارن کمک میکنن تا ابزارها باهم سازگار بشن.
- قابلیت اطمینان و مشاهدهپذیری: ایجنتهاتون باید بعد از crash شدن بتونن ادامه بدن. باید ردگیری کامل، حافظه پایدار، و توانایی بررسی لاگ داشته باشید. Redis برای سرعت، PostgreSQL برای ماندگاری.
- مقیاسپذیری و انعطاف: وقتی کار جدی میشه، باید ایجنتها بتونن از صفر تا هزاران اجرا در لحظه مقیاس پیدا کنن. اگه ایجنتهاتون کدنویسی انجام میدن، احتمالاً نیاز به sandbox برای امنیت و ایزوله کردن دارن.
- یکپارچهسازی و استانداردها: MCP داره نشون میده که همه دنبال یه راهحل استاندارد برای اجرای ایجنتها روی پلتفرمهای مختلف هستن.
- نتیجه اخلاقی:
- ساده شروع کنید، نیازهای واقعیتون رو تخمین بزنید
- اول با deploy ساده مثل Docker یا Lambda برید جلو
- زود تست کنید، چون مشکلات واقعی فقط توی دنیای واقعی مشخص میشن
- کمکم پیچیدگی اضافه کنید. هر چیزی رو وقتی لازمه پیادهسازی کنید.
حتما کامل بخونید اگه ایجنت تو پرداکشن دیپلوی میکنید!
https://zenml.io/blog/the-agent-deployment-gap-why-your-llm-loop-isnt-production-ready-and-what-to-do-about-it
@DevTwitter | <Mehdi Allahyari/>
ساخت یه حلقهی ساده برای ایجنتهای مبتنی بر مدلهای زبانی (LLM agents) خیلی آسونه. شاید با کمتر از ۲۰ خط کد! ولی این سادگی در واقع مشکلات پشت پردهٔ اجرای واقعی در محیط تولید (production) رو میپوشونه.
من خلاصه مقاله را میذارم ولی باید کامل خود مقاله بخونید.
- فاصلهی پنهان بین دمو و اجرا در عمل
۱. دمو مساوی نیست با محصول واقعی: شاید توی دمو همهچی خوب پیش بره، ولی توی محیط واقعی اتفاقاتی مثل:
-از کنترل خارج شدن ایجنتها
- نشت اطلاعات توی context
- گیر کردن توی حلقههای بیپایان
- یا خراب شدن زنجیره ابزارها خیلی رایجه.
- همچنین، تصمیمگیریهای معماری مثل مدیریت context، احراز هویت ابزارها یا ذخیرهسازی state، اگر از اول درست انتخاب نشن، بعداً تغییر دادنشون کلی دردسر داره.
۲. دنیای کنفرانسها با واقعیت فرق داره: شرکتهای بزرگ ممکنه از زیرساختهای خاص خودشون برای اجرای چندایجنت بهصورت موازی استفاده میکنن. ولی اکثر تیمها کار رو سادهتر میگیرن:
- با Docker و GitHub Actions
- یا اجرای ایجنتها روی AWS Lambda فقط برای صرفهجویی ماهانه ۱۰ دلار!
۳. کی اوضاع بهم میریزه؟
وقتی لازم باشه ایجنتهاتون حافظه داشته باشن، بتونن بعد از قطع شدن ادامه بدن، یا با context طولانی کار کنن، همه چی پیچیدهتر میشه. بعضی تیمها تجربهشون رو اینطوری به اشتراک گذاشتن:
- ذخیرهی state توی دیتابیس (مثلاً PostgreSQL) برای بررسی و بازیابی
- استفاده از پردازش غیرهمزمان مثل job queue و webhook
- حذف فریمورکهای سنگین مثل LangChain و استفاده از FastAPI و کلاینت ساده OpenAI
- چیها واقعاً مهمن؟
- زیرساخت موجود: همون جایی deploy کنید که تیمتون بلده (K8s، AWS Lambda، Docker و …)
- سرعت توسعه: گاهی اینکه زود به نتیجه برسید مهمتر از طراحیهای پیچیدهست
- هزینهها: حتی صرفهجوییهای کوچیک هم مهمه، مخصوصاً برای استارتاپها
- نیازهای سازمانی برای ایجنتها
- تناقض پلتفرم: شما دنبال قدرت یه پلتفرم کامل هستید (احراز هویت، حافظه، ارزیابی)، ولی در عین حال نمیخواید به یه vendor خاص وابسته بشید. استانداردهایی مثل MCP دارن کمک میکنن تا ابزارها باهم سازگار بشن.
- قابلیت اطمینان و مشاهدهپذیری: ایجنتهاتون باید بعد از crash شدن بتونن ادامه بدن. باید ردگیری کامل، حافظه پایدار، و توانایی بررسی لاگ داشته باشید. Redis برای سرعت، PostgreSQL برای ماندگاری.
- مقیاسپذیری و انعطاف: وقتی کار جدی میشه، باید ایجنتها بتونن از صفر تا هزاران اجرا در لحظه مقیاس پیدا کنن. اگه ایجنتهاتون کدنویسی انجام میدن، احتمالاً نیاز به sandbox برای امنیت و ایزوله کردن دارن.
- یکپارچهسازی و استانداردها: MCP داره نشون میده که همه دنبال یه راهحل استاندارد برای اجرای ایجنتها روی پلتفرمهای مختلف هستن.
- نتیجه اخلاقی:
- ساده شروع کنید، نیازهای واقعیتون رو تخمین بزنید
- اول با deploy ساده مثل Docker یا Lambda برید جلو
- زود تست کنید، چون مشکلات واقعی فقط توی دنیای واقعی مشخص میشن
- کمکم پیچیدگی اضافه کنید. هر چیزی رو وقتی لازمه پیادهسازی کنید.
حتما کامل بخونید اگه ایجنت تو پرداکشن دیپلوی میکنید!
https://zenml.io/blog/the-agent-deployment-gap-why-your-llm-loop-isnt-production-ready-and-what-to-do-about-it
@DevTwitter | <Mehdi Allahyari/>
Forwarded from Unlocking Software Verification
Monotonic Partial Order Reduction: An Optimal Symbolic Partial Order Reduction Technique
#paper #Aarti #CAV #2009
https://link.springer.com/content/pdf/10.1007/978-3-642-02658-4_31.pdf
#paper #Aarti #CAV #2009
https://link.springer.com/content/pdf/10.1007/978-3-642-02658-4_31.pdf
Forwarded from a pessimistic researcher (Kc)
امیرحسین نامی توی ارائه پرسید که آیا میشه non-determinism موجود در scheduling رو به SAT reduce کرد و حل کرد، من فراموش کردم که به این کار اشاره کنم. optimal نیست (برخلاف ادعای مقاله) و completeness نداره. ولی خودمم دارم میخونمش و ایدههایی دارم که بیارمش روی ConDpor.
Forwarded from نوشتههای ترمینالی
لیفت یه برنامه تاکسی اینترنتیه و تو این مقاله توضیح میده که چطوری راننده ها و مسافرها رو بر اساس شرایط مختلف (مثلا مجاورت) به هم وصل میکنه. برای توضیحش از گراف و به شکل خاص از bipartite graph استفاده میکنه و به نظرم متن جالبی بود.
https://eng.lyft.com/solving-dispatch-in-a-ridesharing-problem-space-821d9606c3ff
https://eng.lyft.com/solving-dispatch-in-a-ridesharing-problem-space-821d9606c3ff
Medium
Solving Dispatch in a Ridesharing Problem Space
Imagine having to assemble a dynamic jigsaw puzzle with millions of new pieces every second. How would you approach such a problem…
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)
Forwarded from 🎄 یک برنامه نویس تنبل (Lazy 🌱)
🔶 بالاخره OBS برای ضبط دوره آموزشی تنظیم کردم.
هر ۱ دقیقه ۵ مگ خروجی میده...
یعنی ۳۰ دقیقه ضبط بشه حدود ۱۵۰ مگ خروجی میده...
@TheRaymondDev
هر ۱ دقیقه ۵ مگ خروجی میده...
یعنی ۳۰ دقیقه ضبط بشه حدود ۱۵۰ مگ خروجی میده...
@TheRaymondDev
👍1
Forwarded from DevTwitter | توییت برنامه نویسی
خیلی از ماها دنبال LLM ای هستیم تا بتونه جواب های معتبری بده و جواب هاش رو از خودش درنیاورده باشه. برای حل این مسائل چه سرویس هایی مناسبه. یکی از راهکار ها استفاده از سرویس deep search در LLM های موجوده. یکی دیگه از راهکار ها استفاده ازسرویس های سرچ و اتصال آنها به LLM هست
Tavily
امکانات خوبی داره میتونید deep search به صورت advanced بگذارید تاجواب های بهتری بدهد حتی میتوان دامنه و تاریخ رو نیز مشخص کرد. کرالش برای سایت هایی که داینامیک بودن، نتونست دیتا مورد نظرم رو بخونه.
https://app.tavily.com/playground
Linkup
تقریبا شبیه tavily هست ولی منابع ای که در تست های من می آورد با tavily متفاوت بود. منابع معتبر و خوبی بود.
https://linkup.so
سرویس گوگل بود که در منابعی که جدول و عکس داشت نسبت به tavily به درستی خوب عمل نکرد.
https://ai.google.dev/gemini-api/docs/google-search
این مقایسه مدل ها در زمینهhallucination یا توهم مدل ها همون طور که میبینید مدل های گوگل عملکرد بهتری نسبت به openai داشتن:
https://github.com/vectara/hallucination-leaderboard?tab=readme-ov-file…
@DevTwitter | <Mari/>
Tavily
امکانات خوبی داره میتونید deep search به صورت advanced بگذارید تاجواب های بهتری بدهد حتی میتوان دامنه و تاریخ رو نیز مشخص کرد. کرالش برای سایت هایی که داینامیک بودن، نتونست دیتا مورد نظرم رو بخونه.
https://app.tavily.com/playground
Linkup
تقریبا شبیه tavily هست ولی منابع ای که در تست های من می آورد با tavily متفاوت بود. منابع معتبر و خوبی بود.
https://linkup.so
سرویس گوگل بود که در منابعی که جدول و عکس داشت نسبت به tavily به درستی خوب عمل نکرد.
https://ai.google.dev/gemini-api/docs/google-search
این مقایسه مدل ها در زمینهhallucination یا توهم مدل ها همون طور که میبینید مدل های گوگل عملکرد بهتری نسبت به openai داشتن:
https://github.com/vectara/hallucination-leaderboard?tab=readme-ov-file…
@DevTwitter | <Mari/>
Forwarded from Armon technical logs (armon Taheri)
این ویدیو جز آموزنده ترین تاثیر صورت بندی در حل مسئله ای بود که در زندگیم دیدم
https://youtu.be/1-zm2EvFr-g
https://youtu.be/1-zm2EvFr-g
YouTube
ناگفتههای بحران آب - قسمت «اول» | گفتگوی محمد فاضلی و حجت میانآبادی
محمد فاضلی: بحران آب پیچیدهترین مسئلهایست که نظام حکمرانی ما با آن مواجه است. آب بهشدت ظرفیت ایدئولوژیک شدن دارد به این معنا که یکسری گزارههای نیازموده بهسادگی در اذهان جا میگیرد، مانند «افسانه هندوانه»، که تمام بحران مدیریت آب به مسئله کشت هندوانه…
Forwarded from linuxtnt(linux tips and tricks) (hosein seilany https://seilany.ir/)
🔥 مهمترین اخبار هفته
🔹میز KDE Plasma 6.4.3: بروزرسانی جزئی با رفع باگهای جمعآوری شده طی دو هفته و بهبود ترجمهها، مخصوص محیط دسکتاپ KDE
🔹برنامه Blender 4.5 LTS: نسخهی پایدار جدید با بهبود پشتیبانی از Vulkan در اپلیکیشن گرافیک سهبعدی متنباز .
🔹برنامهVirtualBox 7.1.12: بهبود هماهنگی با هسته لینوکس ۶.۱۶ در میزبان و ماشینهای مجازی لینوکسی .
🔹برنامهRescuezilla 2.6.1: سیستم بازیابی بر پایه Ubuntu 25.04، با ویژگیهای موثر و رابط کاربری ساده .
🔹برنامهGStreamer 1.26.4: اضافه شدن پشتیبانی از timestamp نوع TAI در mp4mux و تغییرات جزئی دیگر .
🔹برنامهWireshark 4.4.8: بهروزرسانی پروتکلها و رفع باگهای ابزار تحلیل شبکه .
🔹برنامهLibreOffice 25.2.5: عرضه بستهای با ۶۳ رفع اشکال برای مجموعه آفیس محبوب متنباز .
🔹برنامهCalibre 8.7: اضافه کردن قابلیت ساخت فایلهای شمارهگذاری صفحات برای کیندلهای مبتنی بر MTP .
🔹میز KDE Plasma 6.4.3: بروزرسانی جزئی با رفع باگهای جمعآوری شده طی دو هفته و بهبود ترجمهها، مخصوص محیط دسکتاپ KDE
🔹برنامه Blender 4.5 LTS: نسخهی پایدار جدید با بهبود پشتیبانی از Vulkan در اپلیکیشن گرافیک سهبعدی متنباز .
🔹برنامهVirtualBox 7.1.12: بهبود هماهنگی با هسته لینوکس ۶.۱۶ در میزبان و ماشینهای مجازی لینوکسی .
🔹برنامهRescuezilla 2.6.1: سیستم بازیابی بر پایه Ubuntu 25.04، با ویژگیهای موثر و رابط کاربری ساده .
🔹برنامهGStreamer 1.26.4: اضافه شدن پشتیبانی از timestamp نوع TAI در mp4mux و تغییرات جزئی دیگر .
🔹برنامهWireshark 4.4.8: بهروزرسانی پروتکلها و رفع باگهای ابزار تحلیل شبکه .
🔹برنامهLibreOffice 25.2.5: عرضه بستهای با ۶۳ رفع اشکال برای مجموعه آفیس محبوب متنباز .
🔹برنامهCalibre 8.7: اضافه کردن قابلیت ساخت فایلهای شمارهگذاری صفحات برای کیندلهای مبتنی بر MTP .
Forever Lost (Reprise)
God Is an Astronaut
تو وبلاگش یه کتاب معرفی کرد. بعد از چند روز از کامنتهایی که گرفت مأیوس شد، چون اکثرا درباره این بودند که «میشه خلاصهش رو بنویسی برامون؟». و همین رو سوژه مقاله بعدیش کرد و گفت «اینکه انقدر معتاد خلاصهسازی هستید که حتی رمان رو هم میخواهید در یکی دو پاراگراف قورت بدید، نشوندهنده یک روند در دوران ماست که اسمش رو فشردهپسندی میذارم و تا حد زیادی تحت تأثیر شبکههای اجتماعی و اینترنته! و این چیز خوبی نیست چون برای اینکه دانایی خودت رو افزایش بدی باید به گلاویز شدن با پیچیدگیها تن بدی، و پیچیدگی خیلی وقتها قابل فشردهسازی نیست، و اگه هم کسی فشردهش کرد برات باعث میشه دچار این توهم بشی که میدانی در حالی که نمیدانی».
Anarconomy
@hagigcafe
Anarconomy
@hagigcafe