Learning With M

یادش بخیر… یه زمانی غرق بحث‌های تکنیکال بودیم. می‌نشستیم بحث می‌کردیم که چرا GC نمیاد LOH رو Compact کنه! سر پارتیشن‌بندی‌های کافکا و انواع‌واقسام Partition Assignment حرف می‌زدیم. سر روش‌های مختلف پیاده‌سازی Idempotency با هم بحث می‌کردیم، گاهی حتی دعوامون می‌شد! الان اما همه‌چی شده AI. گاهی فکر می‌کنم همون‌طور که ما آخرین نسلی بودیم که توی کوچه‌خیابون بازی می‌کردیم، شاید آخرین نسلی هم باشیم که از ساعت‌ها بحث و کلنجار رفتن سر جزئیات تکنیکال، از خودِ تکنولوژی و از یاد گرفتن چیزهای جدید لذت می‌بردیم. انگار یه چیزی از لذت مهندسی نرم‌افزار، وسط این همه هیاهوی AI مرد...

بچه ها این کتاب Data-intensive (فعلا رایگانه و اشتراک نمیخواد) رو یه گوشی بدین، ببینین خوبه کتاب های فنی این شکلی رو خلاصه صوتی بسازیم ؟ مخصوصا شما حسن جان https://shabgoftar.ir/programs/book-summaries/designing-data-intensive-applications/

🔗 معرفی LayerFS برای وقتی ایجنت‌ها زیاد می‌شن! فرض کنین یه پروژه نرم‌افزاری بزرگ دارین و به‌جای اینکه یه ایجنت رو مأمور Refactoring کنین، تصمیم می‌گیرین ۲۰ تا ایجنت رو هم‌زمان به کار بگیرین؛ ۵ تا برای refactoring، پنج‌تا هم برای پیدا کردن و رفع Bug، پنج‌تا برای نوشتن تست و پنج‌تای دیگه هم برای امتحان کردن روش‌های مختلف بهینه‌سازی performance. خب؟ روی کاغذ خوبه؛ ولی یه مشکل اساسی داریم: هر Agent برای کارش به سورس‌کد پروژه، dependencyها و یه محیط اجرایی مستقل نیاز داره. راه‌حل‌های دوران پیشاهوشواره (ماقبل AI) مثل git تا حد خوبی این نیاز رو برطرف می‌کنن، ولی وقتی تعداد Agentها به ده‌ها یا صدها برسه، مدیریت این محیط‌ها، نگهداری فایل‌های تکراری، آماده‌سازی dependencyها و هماهنگی تغییرات، خودش تبدیل به یه چالش جدی می‌شه. مثلاً وقتی یه پروژه‌ با سورس‌کد ۱۰۰ گیگابایتی دارین؛ چرا باید برای هر Agent یک کپی جداگانه از همه‌چیز داشته باشین؟ از طرفی هم نمی‌شه همه از یه نسخه مشترک استفاده کنن و فقط تغییرات خودشون رو مستقل نگه دارن؟ دلیل پیدایش پروژه متن‌باز LayerFS همین مسئله بود! ایده اصلیش Ephemeral Workspaces, Durable Shared History است؛ یعنی محیط‌های کاری موقت، با تاریخچه تغییرات ماندگار و مشترک. به زبون ساده، هر ایجنت یه workspace مستقل داره، بدون اینکه لازم باشه همه فایل‌ها و dependencyهای پروژه براش کپی بشن. همه از یه پایه مشترک استفاده می‌کنن و فقط تغییرات اختصاصی خودشون رو نگه می‌دارن. قابلیت جذاب‌ترش اینکه تغییرات می‌تونن به‌صورت checkpoint ثبت بشن. فرض کنین یه ایجنت برای refactoring چهار مرحله جلو رفته، ولی توی مرحله چهارم به بن‌بست رسیده. می‌شه از مرحله دوم یه branch جدید ساخت و به چند ایجنت دیگه سپرد تا مسیرهای متفاوتی رو امتحان کنن. حتی می‌شه ۵۰ تا ایجنت رو روی ۵۰ راه‌حل متفاوت برای یه مسئله به کار گرفت، بعد خروجی‌ها رو تست و مقایسه کرد و بهترین گزینه رو انتخاب کرد. البته انتخاب بهترین راه‌حل کار خود LayerFS نیست؛ این زیرساخت فقط اجرای چنین الگویی رو ساده‌تر می‌کنه. از نظر فنی هم پروژه با ترکیبی از تکنیک‌های شناخته‌شده و حتی قدیمی مثل Copy-on-Write، Content-Addressed Storage و SQLite پیاده‌سازی شده و ادعاهای جالبی درباره کاهش مصرف استورج و زمان آماده‌سازی Workspaceها داره. البته هنوز محدودیت‌هایی هم داره، مثل محدودیت اشتراک Store بین ماشین‌های مستقل، یا مدیریت Conflictهای منطقی و بعضی ملاحظات مربوط به Durability. بنابراین فعلاً نباید بهش به‌عنوان «امروزه، عصر، عسر LayerFS است و هر کس بلد نباشه یا استفاده نکنه، ابله است» نگاه کنیم. 💡 اما به نظرم نکته مهم‌تر از خود LayerFS؛ مسئله‌ایه که داره حل می‌کنه. ما داریم به سمتی می‌ریم که توسعه نرم‌افزار لزوماً به معنی همکاری یه برنامه‌نویس با یه ایجنت نیست. ممکنه به معنی اجرای ده‌ها یا صدها ایجنت باشه که هم‌زمان فرضیه‌های مختلف رو امتحان می‌کنن، شکست می‌خورن، به عقب برمی‌گردن و مسیرهای جدیدی رو پیش می‌گیرن. برای چنین آینده‌ای، فقط مدل‌های هوشمندتر کافی نیستن. به زیرساخت‌هایی نیاز داریم که این شکل از توسعه رو از نظر هزینه، سرعت، مدیریت state و قابلیت ردیابی عملی کنن. و LayerFS قرار نیست ایجنت‌ها رو باهوش‌تر کنه؛ می‌خواد کاری کنه که بتونیم تعداد خیلی بیشتری از اون‌ها رو به شکل مؤثر، کنار هم به کار بگیریم و هزینه منابع رو در سطح استورج و زمان، کنترل کنیم. و شاید این بخشِ کمتر دیده‌شده‌ یا کمتر پرداخته‌شده‌ای از تحول AI-Native Software Engineering باشه: تحول توی زیرساخت توسعه، نه صرفاً ابزار تولید کد یا حتی محصول. 🔗 وب‌سایتش 🔗 سورس‌کدش

امشب با احمد سجادیان عزیز از آلمان درباره شرایط کاری و انعطاف و ... بین کارمند و بیزنس ها گپ میزنیم ساعت شروع برنامه : 22:30 مسیر ورود به برنامه : Shabgoftar.ir همزمان با صحبت های مجری و میهمان شما هم می تونید از طریق بخش گفتگو سایت نظراتتون رو در لحظه با ما در میون بگذارید. پیشاپیش از همراهی تون سپاس گزاریم #گزارش_کار #شبگفتار

ایده های مسعود بیگی، یکی از یکی نو آورانه ترن.

ما هیچ، ما نگاه. #SoftwareArchitecture #فان

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

به نظرم این پروژه واقعاً ارزش بررسی داره: https://github.com/morluto/rea چیزی که در مورد REA برام جالبه، رویکردش به ترکیب مهندسی معکوس با ایجنت‌های هوش مصنوعیه. ایده اینه که به‌جای محدود موندن به تحلیل کد منبع، امکان بررسی رفتار و ساختار اپلیکیشن‌ها، حتی در سطح باینری، فراهم بشه تا ایجنت بتونه با تکیه بر شواهد به درک عمیق‌تری از نحوه عملکرد سیستم برسه و در مسیر بازپیاده‌سازی قابلیت‌های اون کمک کنه. به نظرم این دقیقاً یکی از حوزه‌هاییه که ترکیب AI و مهندسی نرم‌افزار می‌تونه تأثیر جدی بذاره؛ جایی که ایجنت صرفاً کد تولید نمی‌کنه، بلکه باید تحلیل کنه، فرضیه بسازه، شواهد رو بررسی کنه و بر اساس اون‌ها به راه‌حل برسه. فکر می‌کنم ارزش اصلی چنین پروژه‌هایی در حرکت از تولید صرف کد به سمت درک و تحلیل سیستم‌های پیچیده‌ست. قطعاً بررسی معماری و قابلیت‌های REA می‌تونه دید جالبی نسبت به آینده‌ی AI-assisted reverse engineering بده. قبلا میگفتیم همه محصولات یه کپی چینی دارن الان در حوزه نرم افزار هم داره ابن اتفاق میفته (نمونش مثلا PhotoCraft یکی اومده کلا فتوشاپ رو از اول نوشته و اپن سورس کرده!)

سلام. ما یک پوزیشن Software Engineer در دیجی کالا ادز داریم که می خوایم با یک Staff Engineer پرش کنیم. کاری که قراره بکنید روی سیستم های پر تراکنش(حدود 50 میلیون درخواست در روز) کار کنید که برای سازمان بسیار مهم و با ارزشه. تمرکز این فرد روی بازطراحی و بهبود این سرویس ها و توسعه اونهاست. پس، اگر روی golang متخصص هستید و بیشتر از ۸ سال سابقه کار دارید، خوشحال میشم بهم پیام بدید و یا از طریق این لینک اپلای کنید‌. #استخدام #جذب

مارگارت همیلتون یکی از پیشگامان مهندسی نرم افزار چند روز پیش در سن 90 سالگی درگذشت. خانم همیلتون دانشمند علوم کامپیوتر در دانشگاه MIT بود که در دهه 1960 میلادی مسئولیت هدایت تیم توسعه نرم افزار پرواز ماموریت اپولوی ناسا رو دست گرفت و در نهایت منجر به اولین فرود انسان روی ماه در تاریخ شد. ایشون از افرادی بود که به رواج اصطلاح مهندسی نرم‌افزار کمک کرد و تأکید داشت که ساخت نرم‌ افزار صرفا نوشتن کد نیست، بلکه نرم افزار به طراحی سیستم، ازمایش، مدیریت خطا و تضمین قابلیت اطمینان نیاز داره. 🔎 mit 📍 @TechTube

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

سلام به همگی با Rookery آشنا بشید: از Issue تا Pull Request! چند وقتیه دارم روی Rookery کار می‌کنم. یه GitHub Appه که یه Issue رو برمی‌داره و تا یه Draft PR آماده جلو می‌بره. قبل از اینکه حتی یه خط کد نوشته بشه، شما پلن رو تأیید می‌کنید. الان هم بالا اومده و می‌تونید امتحانش کنید https://rookery.run 🚀 شروع کار 1️⃣ GitHub App Rookery رو روی ریپوهاتون نصب کنید. 2️⃣ با اکانت GitHub وارد پرتال بشید. 3️⃣ کلید API خودتون (Anthropic، DeepSeek یا GLM) رو توی صفحه‌ی Keys اضافه کنید. کلیدها رمزنگاری‌شده ذخیره می‌شن و دیگه هیچ‌جا نمایش داده نمی‌شن 🔒 🔄 از Issue تا PR 🏷️ لیبل rookery:trigger رو به Issue بزنید. 📝 Rookery یه پلن و لیست تسک می‌نویسه. اگه جایی ابهام داشته باشه، همون‌جا زیر Issue ازتون می‌پرسه. ✅ کامنت approve بذارید. فقط کسایی که دسترسی write دارن می‌تونن تأیید کنن، و پرتال هم دکمه‌ی approve نداره. ⚙️ تسک‌ها رو یکی‌یکی انجام می‌ده. برای هر تسک یه سشن تازه باز می‌کنه و بعد از هر کدوم commit می‌کنه. 🔍 آخر کار یه ایجنت ریویوئر نتیجه رو چک می‌کنه، و شما یه Draft PR تحویل می‌گیرید که پلن، تصمیم‌ها و ریویو همه توشه. 👀 ریویوی PR هر وقت خواستید روی هر PR که خواستید @rookery-agent رو منشن کنید، یا لیبل ریویو رو بزنید، یه جدول خلاصه با یافته‌ها و نتیجه‌ی نهایی تحویل می‌گیرید. 🛠️ پشت صحنه هارنس ما Claude Codeه. هر مرحله، CLI ِ claude رو توی یه git worktree جدا اجرا می‌کنه. با قوانین سفت‌وسخت deny، ایجنت نه می‌تونه push کنه و نه به GitHub دسترسی داره. همه‌ی commitها، pushها و PRها رو خود Rookery انجام می‌ده. 🎁 جایزه: به ۳ نفر که Rookery رو امتحان کنن و نظرشون رو همین‌جا کامنت کنن، اعتبار رایگان می‌دم تا بدون اضافه کردن کلید API خودشون ازش استفاده کنن 😉 لطفا به اشتراک بذارید و کمک کنید بهترش کنم.

قسمت اول از طراحی سیستم ورک فلو انجین - چیزی شبیه به n8n توی این جلسه سعی میکنیم، یه ورک فلو انجین طراحی کنیم. بیشتر تمرکز بر دیزاین کردن یه ورک فلو انجین به صورت داینامیک هست. 🚨 به علت اینکه ثبت نام محدود هست و کسیکه رجیستر میکنه و حضور پیدا نمیکنه در جلسات، تصمیم بر این شد که مبلغی رو برای ورودی و ثبت نام در نظر بگیریم. چنانچه شما مطمئن هستید که در جلسات شرکت میکنید ثبت نام انجام بدید. ساعت و روز : چهارشنبه 15 مهر ماه، ساعت 8.30 دقیقه صبح به وقت تهران مدت زمان جلسه : 2 ساعت نیازمندی : چنانچه میخواهید در مباحث شرکت کنید، حتما لب تاب و دسترسی به هوش مصنوعی داشته باشید. جلسات رکورد میشود : خیر لینک ثبت نام: https://luma.com/yx4w1imq راهنمایی ثبت نام: 1- در ابتدا روی لینک کلیک نمایید، اطلاعات واریز در توضیحات هست. 2- واریز رو انجام بدید، و بعد نیازی به ارسال فیش و یا چیزی نیست، در زمان ثبت نام گزینه ی " واریز کرده ام " رو انتخاب کنید. 3- چنانچه در گروه وی آی پی هستید، میتونید پرداخت نکنید و گزینه ی وی آی پی رو انتخاب کنید. 4- منتظر تایید باشید تا لینک جلسه برای شما ارسال شود.

آندری کارپتی (Andrej Karpathy) یه توییت جالب زده در مورد اینکه با قوی‌تر شدن LLMها، کار اصلی ما دیگه تولید محتوا نیست، بلکه فهمیدن و نظارت روی خروجی‌هاشون می‌شه. یعنی مدل‌ها دارن بیشتر و بیشتر کار سنگین رو خودشون انجام می‌دن و ما باید بریم سمت لایه‌های بالاتر و بفهمیم واقعاً چی دارن می‌گن. چند تا ترفند باحال و عملی پیشنهاد داده که من هم کم‌کم دارم امتحانشون می‌کنم: نوشتن با ASD-STE100: بگید مدل مطلب رو با زبان کنترل‌شده ASD-STE100 بنویسه. این استاندارد اصلش برای مستندات نگهداری هواپیما و تجهیزات هوافضا طراحی شده و قوانین خیلی سختگیرانه‌ای داره (جمله‌های کوتاه، فعل‌های مشخص، دیکشنری محدود، بدون ابهام و استعاره‌های پیچیده). نتیجه‌ش اینه که متن خیلی تمیز، مستقیم و خوانا می‌شه. اگر خیلی خشک شد، می‌تونید بگید «۸۰ درصد نزدیک به ASD-STE100» تا یه کم نرم‌ترش کنه. برای توضیح‌های فنی و پیچیده عالیه، چون مغزتون کمتر خسته می‌شه. نمودار و دیاگرام به جای متن: به جاش مستقیم ازش بخواید دیاگرام، flowchart یا mermaid یا تصویر مفهومی بسازه. مغز ما اطلاعات بصری رو خیلی سریع‌تر پردازش می‌کنه و پارس کردنش راحت‌تره. مخصوصاً وقتی موضوع پیچیده باشه، یه دیاگرام خوب می‌تونه کل ایده رو در چند ثانیه منتقل کنه، در حالی که متن ممکنه چند پاراگراف طول بکشه. خروجی به صورت HTML: بگید خروجی رو به صورت HTML کامل بده. مدل‌های جدید واقعاً تو فرانت‌اند قوی شدن و می‌تونن صفحه‌های وب قشنگ، اینتراکتیو، با انیمیشن و استایل مدرن بسازن. به جای یه متن خشک، یه تجربه‌ی تعاملی می‌گیرید که می‌تونید روش کلیک کنید، اسکرول کنید یا حتی چیزایی رو تست کنید. برای فهمیدن مفاهیم پیچیده خیلی کمک‌کننده‌ست. ویدیوهای explainer سفارشی (بهترینش اینه!): کارپتی می‌گه بیشتر از همه به این فرمت امیدواره. از مدل بخواید یه ویدیوی کامل و اختصاصی به سبک 3Blue1Brown بسازه (همون انیمیشن‌های ریاضی و مفهومی تمیز و قشنگ). می‌تونید بگید از API کی ElevenLabs برای narration استفاده کنه یا جایگزین‌های رایگان/لوکال پیدا کنه. اینطوری برای هر موضوعی که بخواید، یه ویدیوی آموزشی شخصی‌سازی‌شده می‌سازید که قبلاً ساختنش زمان و هزینه‌ی دیوانه‌کننده‌ای داشت.خلاصه‌ش اینه که هوش مصنوعی داره انقدر زیاد و ارزون می‌شه که می‌تونیم ازش artifactهای بزرگ و دورریختنی بسازیم (وب‌اپ، ویدیو، دیاگرام‌های پیچیده و غیره) که قبلاً اصلاً به‌صرفه نبود. کار ما داره می‌ره به لایه‌های بالاتر abstraction و oversight، و جالب اینجاست که خود LLMها می‌تونن تو همین بخش هم کمک‌مون کنن. به نظرم خیلی نکته‌ی درستیه، مخصوصاً برای ما که هر روز با اینا کار می‌کنیم. حتماً امتحان کنید و نتیجه‌ش رو بگید 🔥 پ.ن: آندری کارپتی یکی از استادای واقعی و پیشگام‌های حوزه LLM و deep learning حساب می‌شه. قبلاً مدیر AI تسلا بوده، از بنیان‌گذاران اولیه OpenAI، و یکی از بهترین‌ها در توضیح شفاف و عمیق مفاهیم هوش مصنوعیه. وقتی حرف می‌زنه، معمولاً ارزش گوش دادن داره. لینک توییت: https://x.com/karpathy/status/2105819303471976479

به عنوان یک معلم، یادگیری برای من امیده، به عنوان یک پدر، یادگیری برای من مسیر نجات فرزندم از جهله، و به عنوان یک انسان، یادگیری برای من حق طبیعیه که نباید به خاطر جبر جغرافیایی از کسی گرفته بشه. در نهایت به عنوان یک دیجی کالایی،امروز دیجی کالا مهر برای من مسیر رسیدن به: امید یک معلم، مسیر نجات یک فرزند و احقاق حق اولیه یه انسانه. ازتون میخوام در صورتی که امکانش رو دارید در پویش "هر جا که تویی" شرکت کنید و برای آینده کودکان کشورمون سهمی داشته باشید : https://mehr.digikala.com/madrese-besaz/ @learning_with_m

این هم خیلی جالب درآورده بود Iranshahr.netlify.app

همینه! به نظرم AI میتونه همه چی بزنه و اینکه 'چی' بزنه نیاز به وقت و زمان داره. این نکته خیلی مهمه، الان متاسفانه یه جوی شده که آقا با AI بزن بره اینکه کاری نداره. برای من AI تونسته بین 50 تا 60 درصد سرعت توسعه بیشتر کرده و زمان تحویل رو کمتر. نکته: تولید کد شاید 99 درصد سریع تر شده ولی اینکه قبلش فک کنی پلن کنی و بعدش چک کنی تست کنی بفهمی هنوز زمان میگیره. برای شما چند درصد تونسته کمک کنه؟

مارتین فاولر یه مطلب نوشته به اسم «I don't like LLMs». فاولر قبول داره که این ابزارها کار می‌کنن. حتی از Jessica Kerr نقل می‌کنه که استفاده نکردن ازشون غیرمسئولانه‌ست. مشکلش با کارایی‌شون نیست، با رفتارشونه. می‌گه ادای آدم رو درمیارن، و تازه ادای آدمی رو که اگه واقعی بود باهاش رفیق نمی‌شد. وقتی یه چیزی رو نمی‌دونن با همون اطمینانی که جواب درست می‌دن سرهمش می‌کنن، و اشتباهشون رو که بگی یه عذرخواهی سرسری می‌کنن و می‌رن سراغ جواب بعدی. لینک مطلبش رو گذاشتم، تمایل داشتید بخونید: https://martinfowler.com/articles/2026-dont-like-llms.html @gocasts

استارتاپ TypeSafe AI بعد از دو سال فعالیت در سکوت کامل خبری، رسماً از مدل متفاوتی به نام Jev رونمایی کرده که رویکرد کاملاً جدیدی رو وارد حوزه اتوماسیون و سیستم‌های نرم‌افزاری می‌کنه. این شرکت که توسط دیوگو آلمیدا، یکی از سازندگان ChatGPT تاسیس شده، مدلی رو ارائه داده که بر خلاف روندهای مرسوم، یک چت‌بات متنی نیست و در دسته جدیدی به نام «مدل‌های سیستم یک» قرار می‌گیره. عبارت «سیستم یک» از نظریه دانیل کانمن در کتاب معروف «تفکر، سریع و کُند» الهام گرفته شده. در علوم شناختی، ذهن دو ساختار پردازش داره: سیستم ۱ پردازش سریع، شهودی، خودکار و بدون مکثه که انرژی کمی مصرف می‌کنه. در نقطه مقابل، سیستم ۲ تفکر آرام، استدلالی، گام‌به‌گام و تحلیلیه؛ دقیقاً شبیه کاری که مدل‌های استدلالی جدید (مثل ChatGPT یا Claude) با ساختن زنجیره تفکر طولانی انجام میدن. سازندگان Jev با حذف استدلال متنی کُند، دقیقاً از مفهوم سیستم ۱ استفاده کردن تا مدلی سریع برای تصمیم‌گیری‌های آنی داشته باشن. تفاوت بنیادین Jev با مدل‌های زبانی بزرگ متداول اینه که فرآیند تولید توکن‌به‌توکن و کلمه‌به‌کلمه متن رو کاملاً کنار گذاشته تا بتونه تصمیم‌های قطعی، ساختاریافته و دارای ساختار داده معتبر رو برای نرم‌افزارها پردازش کنه. این مدل وضعیت برنامه رو به عنوان پرامپت دریافت می‌کنه و خروجی‌هاش رو در قالب سه نوع تصمیم‌گیری پایه تحویل سیستم میده: اول، تصمیم‌های دو‌وجهی یا بله و خیر که با ضریب اطمینان کالیبره‌شده مشخص می‌شن؛ برای مثال مدل بررسی می‌کنه که آیا پیام ورودی کاربر یک پرامپت مخربه یا نه و در کسری از ثانیه فقط مقدار درست یا غلط رو برای جلوگیری از حمله برمی‌گردونه. دوم، تصمیم‌های چندگزینه‌ای که مدل دقیقاً یکی از شناسه‌های از پیش تعیین‌شده رو انتخاب می‌کنه؛ مثلاً در یک سیستم تیکتینگ، درخواست رو بدون هیچ خطایی دقیقاً به یکی از گزینه‌های امور مالی، پشتیبانی فنی یا بخش ارسال کالا هدایت می‌کنه، بدون اینکه خطایی در ساختار پیش بیاد. سوم، امتیازدهی آماریه که مدل بر اساس یک مقیاس عددی مشخص، میزان اضطرار یک وظیفه یا باگ رو تخمین می‌زنه و همراه با میزان احتمال تحویل سامانه میده. در بخش آموزش، سازندگان Jev به جای تکیه بر روش‌های سنتی RLHF، از رویکرد یادگیری تقویتی برای تصمیم‌های کالیبره‌شده موسوم به RLCD استفاده کردن تا نرخ توهم و خطاهای ساختاری به صفر برسه. به همین دلیل سیستم‌های مبتنی بر این مدل با خطای نامعتبر بودن پاسخ‌ها یا کرش کردن کدهای بک‌اند مواجه نمی‌شن. از نظر کاربرد در صنایع، این معماری تحول زیادی ایجاد می‌کنه. در حوزه ایجنت‌های هوش مصنوعی، Jev به عنوان مغز روتینگ عمل می‌کنه و تصمیم می‌گیره کدوم ابزار در گام بعدی باید اجرا بشه. در حوزه فین‌تک و خدمات مالی، به لطف تأخیر بسیار پایین در حد چند ده تا چند صد میلی‌ثانیه، توانایی غربال آنی تراکنش‌های مشکوک به تقلب رو داره. در پلتفرم‌های پرمخاطب فروشگاهی و ابری، میتونه میلیون‌ها تیکت و پیام رو به شکل کم‌هزینه دسته‌بندی کنه و در امنیت سایبری هم به عنوان لایه اول تحلیل لاگ‌های فایروال و روتر، هشدارهای جعلی رو از خطرات واقعی جدا می‌کنه. ساختار هزینه‌ها و منابع Jev هم به دلیل عدم تولید متن، نسبت به کل بازار هوش مصنوعی کاملاً نامتقارن و متفاوته. هزینه توکن‌های ورودی این مدل معادل ۰.۰۴۲ دلار به ازای هر یک میلیون توکن در نظر گرفته شده که بین ۱۰ تا ۵۰ برابر اقتصادی‌تر از مدل‌های متداول تجاریه. از طرف دیگه، با توجه به اینکه خروجی به صورت داده‌های تصمیم گیری تحویل داده می‌شه، هزینه توکن‌های خروجی کاملاً رایگان تعیین شده. این مدل با کانتکست ویندوی ۳۲ هزار توکنی، در تسک‌های دسته‌بندی و اتوماسیون بین ۴۰ تا ۲۰۰ برابر سریع‌تر و تا ۴۰۰ برابر کم‌هزینه‌تر از مدل‌های پرچمدار سنتی عمل می‌کنه. این مدل از حالا در پلتفرم های مختلف از جمله اوپن روتر قابل استفاده هست. به دلیل اینکه نحوه کار با این مدل نسبت به LLMهای متداول متفاوت هست، بهتره این مطلب رو در رابطه با طراحی سیستم برای چنین مدل جدیدی مطالعه کنید. 🔎 Typesafe.ai 📍 @TechTube

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