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

معماریش یه هیولای ۹۵۲ میلیارد پارامتریه که حدود ۴۱ میلیاردش تو هر توکن اکتیوه. یعنی عملا ۱۶ تا کارت H200. حتی نسخه کوانتایز شده NVFP4 هم ۶۰۰ گیگ مموری می‌خواد. پس عملا اجرای لوکالش واسه ماها قفله و باید از همون سرویس Tinker خودشون یا پرووایدرهای دیگه استفاده بشه.

بچه‌های تیم سازنده‌ش که اکثرا از OpenAI اومدن بیرون، تصمیم جالبی واسه اسکیل کردن گرفتن. برگشتن سمت muP یا همون Maximal Update Parametrization. چند وقت پیش یه پیپر می‌خوندم که نشون می‌داد واسه مدل‌های بالای یک تریلیون پارامتر، این روش چطور پایداری ترینینگ رو تضمین می‌کنه. ۴۵ تریلیون توکن دیتای آموزشی به خورد مدل داده شده که تو فضای اوپن‌‌ها یه عدد عجیبه.

چیز عجیبی که تو معماری attention دیده میشه، ترکیبش با کانولوشنه. به علاوه اینکه اومدن weight decay رو با learning rate گره زدن. قطعا یه دلیل بهینه‌سازی پشتش بوده ولی به شدت وابسته به ستاپ کاستوم خودشونه. از اون طرف، تو بحث پردازش تصویر، از یه انکودر پچ سلسله‌مراتبی استفاده شده و صدا هم به صورت توکن‌های گسسته درمیاد. این یکپارچگی روی درک کدهای پیچیده و تسک‌های reasoning تاثیر مثبت گذاشته.

🛠 Join @LLMEngineers Community

چیزی که تو معماریش واسم جالب بود بحث Continuous Reasoning Effort هست. جای اینکه مثل بقیه مدل‌ها فقط چند تا مود ثابت واسه ریزونینگ داشته باشه، یه پارامتر بین صفر و یک می‌گیره. من رو ۰.۷ تنظیمش کردم واسه تسک‌های روتین، و فقط وقتی می‌خوام یه کد پیچیده رو دیباگ کنه می‌ذارمش رو ۰.۹۹. اینطوری هم توکن کمتری مصرف می‌شه هم سرعت ریسپانس خیلی بالاتره، چون مدل مجبور نیست رو سوال‌های ساده پردازش الکی انجام بده.

واسه فاین‌تیون کردنش هم داکیومنت‌های پلتفرم Tinker یه سری دیتای خوب داده که به درد پروژه‌های دیگه هم می‌خوره. نوشتن اگه می‌خواید رو این مدل‌های اسپارس MoE لورا بزنید، فقط تارگت کردن لایه‌های اتنشن جواب نمیده. باید وزن‌های LoRA رو روی تمام ماتریکس‌ها، از جمله MLP و خود لایه‌های MoE اعمال کنید. رنک دیفالت رو ۳۲ پیشنهاد دادن و گفتن لرنینگ ریت رو حدود ۱۰ برابر زمانی بذارید که دارید فول‌فاین‌تیون می‌کنید. این ستاپ واسه SFT و حتی RL روی دیتای کاستوم بهترین نتیجه رو داده.

واقعیتش مدلی که من منتظرشم این نسخه ۹۷۵ میلیاردی نیست. تو پیش‌نمایش‌هاشون حرف از Inkling-Small زدن که کلا ۲۷۶ میلیارد پارامتر داره و فقط ۱۲ میلیاردش تو هر توکن اکتیوه. بنچمارک‌هاش تو پردازش صدا و ریکوئست‌های ایجنتیک تقریبا هم‌سطح برادر بزرگترشه ولی هنوز وزن‌هاش رو پابلیک نکردن...

گزارش کامل وضعیت ساپورت نرم‌افزاری و بررسی بنچمارک‌های نسخه کوچیکتر:
https://thinkingmachines.com/inkling-technical-ecosystem

🛠 Join @LLMEngineers Community

مدل Kimi K3 معرفی شد. و توی سایت در دسترسه
kimi.com

کمپانی Moonshot AI تیزر رسمی این مدل رو منتشر کرده و به نظر می‌رسه قراره یکی از جدی‌ترین مدل‌های متن‌باز امسال باشه.
گویا میگن 3T پارامتر داره 1M کانتکس و قدرتش در حد Opus و حتی بالاتره.
هنوز بنچمارک‌ها و جزئیات کامل منتشر نشده، ولی احتمالاً به‌زودی رقابت جذاب‌تری بین مدل‌های متن‌باز و بسته خواهیم دید.

منتظر نتایجش هستم 👀

اگه میتونستم هر career ای دلم میخواد انتخاب کنم، حوزه مورد علاقم post-train و benchmarks design می بود، هم در سطح research هم پروداکشن
لعنتی خیلی جذابه

Boom 💣

مفهوم Agent Harness یا Harness Engineering یکی از اون اصطلاحاتیه که این روزها زیاد شنیده می‌شه، اما چون هم خیلی کلیه و هم خیلی تخصصی، خیلیا هنوز دقیقاً نمی‌دونن چیه. در ساده‌ترین تعریف، خیلیا فکر می‌کنن Harness فقط همون محیط (Environment) اجرای ایجنت هست، اما داستان خیلی عمیق‌تر از این حرف‌هاست.

برای درک بهتر، باید مسیر تکامل تعامل با مدل‌ها رو ببینیم:

۱. سال ۲۰۲۳ و Prompt Engineering:
اوایل که ChatGPT اومد، با Context Window محدود (۴۰۹۶ توکن) درگیر بودیم. تمام تلاشمون این بود که با نوشتن پرامپت‌های بهتر، خروجی دقیق‌تری بگیریم. اما برای کارهای پیچیده اصلاً کافی نبود.

۲. سال ۲۰۲۴ و Context Engineering:
اینجا ابزارهایی مثل RAG، Tool Calling و پروتکل‌هایی مثل MCP وارد شدن. هدف این بود که کانتکست مدل رو بهتر مدیریت کنیم تا ایجنت بتونه به دیتابیس یا فایل‌های خاص دسترسی داشته باشه. اما یک مشکل بزرگ وجود داشت: وقتی تسک‌ها طولانی می‌شد (مثلاً ۱۰-۱۲ ساعت کار مداوم)، کانتکست پر می‌شد و ایجنت مجبور بود اطلاعات رو خلاصه‌سازی (Summarize) کنه. این کار باعث می‌شد جزئیات فنی گم بشه، ایجنت گیج بشه و تسک‌ها رو نصفه رها کنه.

۳. ظهور Harness Engineering:
اینجاست که مفهوم Harness وارد عمل می‌شه. Harness در واقع یک لایه‌ی Orchestration بالای سر کانتکست هست. به جای اینکه ایجنت رو توی کانتکست خودش غرق کنیم، اون رو وارد یک Loop (حلقه) منظم می‌کنیم.

ساختار کار در Harness معمولاً به این شکله:
* ابتدا یک فایل نیازمندی‌های دقیق (PRD) تولید می‌شه.
* این فایل به تسک‌های ریز در قالب JSON شکسته می‌شه.
* ایجنت در هر تکرار (Iteration) از حلقه، فقط روی یک تسک مشخص تمرکز می‌کنه.
* در شروع هر مرحله، ایجنت یک کانتکست کاملاً تازه و تمیز (Fresh Context) دریافت می‌کنه، اما با قوانین (Rules) سخت‌گیرانه‌ای که از قبل براش تعریف شده.

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

نمونه‌های عملی این رویکرد رو می‌شه توی دموی اخیر Anthropic دید. حتی Cursor با معرفی Cloud Agents و قابلیت تعریف Automation برای آپدیت خودکار کدبیس، عملاً داره به سمت Harness Engineering حرکت می‌کنه. در این حالت، شما حتی لازم نیست IDE باز باشه؛ ایجنت توی کلاود طبق تسک‌های تعریف شده کار می‌کنه، کد می‌زنه، تست می‌کنه و در نهایت Pull Request رو براتون می‌فرسته.

در واقع قدرت واقعی ایجنت‌های آینده نه فقط توی مدل قوی‌تر، بلکه توی Harness یا همون زیرساخت مدیریتی هست که ایجنت رو هدایت می‌کنه تا تسک‌های طولانی رو بدون افت کیفیت به پایان برسونه.

🛠 Join @LLMEngineers Community

نشستم ۲۲ تا ابزار کدزنی AI رو با هم مقایسه کردم... بحث سر Harness یا همون بستر اجرای مدله. یعنی اون سیستم مدیریت کانتکست و ابزارهایی که دور مدل کشیده شده.

خلاصه چندتا دسته‌بندی اصلی:
— اگه دنبال سرعت و تجربه تمیز توی ادیتوری: Cursor هنوز بی‌رقیبه.
— اگه گیک ترمینالی: Claude Code جادو می‌کنه.
— اگه کنترل کامل و دنیای متن‌باز رو می‌خوای: Cline و opencode رو حتماً تست کن.
— اگه می‌خوای تسک رو بسپری به ایجنت و بری سراغ کارای دیگه: Devin و Codex و Jules گزینه‌های اصلی‌ان.

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

لینک مقاله:
https://medium.com/@mshojaei77/i-compared-22-ai-coding-harnesses-most-developers-are-comparing-the-wrong-thing-4efb26650fcd

🛠 Join @LLMEngineers Community

بینا ۰.۱ ✨ 👀

پروژه Bina OCR رو کلاً یک هفته‌ست که استارت زدیم و امروز اولین بنچمارک واقعی رو ازش گرفتیم... نتیجه حتی برای خودمون هم غیرمنتظره بود. مدل Bina 0.1 توی تست‌های OCR فارسی جلوتر از مدل‌های بزرگی مثل Gemini 3.5 Flash قرار گرفت. البته این تازه اول مسیره و هنوز کلی باگ و کار زمین‌مونده داریم.

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

این پروژه با همکاری رضا سیار جلو رفته که قبلاً هم سیستم شنوا (ASR فارسی) رو توسعه داده بود. از اون دست به کیبوردهایی که کمتر حرف می‌زنن و بیشتر کد می‌زنن. (اسپویلر: پروژه بعدی هم قراره tts فارسی باشه)

واقعیت فنی اینه که ساختن یه مدل خوب، بیشتر از اینکه درگیر بازی با معماری و مدل‌های عجیب‌وغریب باشه، لنگِ داده‌ست. برای اینکه نسخه‌های بعدی Bina OCR بتونن کارهای سخت‌تر رو انجام بدن به چندتا چیز نیاز مبرم داریم: داده‌های متنوع‌تر، اسناد واقعی‌تر، دستخط‌های نامرتب و البته قدرت پردازش (compute) برای آموزش و تست.

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

نسخه اولیه مدل :
https://huggingface.co/Reza2kn/Bina-0.1
کامیونیتی تلگرام پروژه :
https://t.me/bina_ocr


🛠 Join @LLMEngineers Community

براساس این بنچمارک ما که دارای ۶,۶۶۹ خط متن تایپی و ۶,۶۶۹ صفحه متن دست نویس هست: بینا ۰.۱ در حال حاضر بهترین مدل تشخیص متن فارسی تایپی و دست نویسه! 🔥🔥

پروژه OpenBench v1 برای ارزیابی و بنچمارک دقیق ایجنت‌های کدنویسی منتشر شد... ابزاری متن‌باز که روی مقایسه و سنجش harnessها تمرکز داره.

اکثر تیم‌ها تمام تمرکز رو روی انتخاب مدل گذاشتن - اما یک ایجنت کدنویسی حاصل ترکیب مدل و harness است؛ یعنی همون ابزارهای جانبی، پرامپت‌ها، دسترسی‌ها و سیستم مدیریت اجرای اطراف مدل. وقتی مدل یکسان باشه (مثلاً gpt-5.6)، تغییر دادن harness از cursor به codex، claude یا devin می‌تونه درصد موفقیت و هزینه‌ها رو کلاً تغییر بده.

معیارهای سنجش توی این فریم‌ورک روی سه محور اصلی میچرخه: درصد درستی (correctness)، میزان مصرف token (ورودی، خروجی و cache) و تاخیر زمانی (latency)... ارزیابی‌ها هم داخل کانتینرهای ایزوله Docker اجرا میشن و صحت کد با اسکریپت‌های checker مستقل ارزیابی میشه، نه ادعای خود ایجنت.

https://github.com/minghinmatthewlam/openbench

🛠 Join @LLMEngineers Community

Explain what happens when your input exceeds the context window?

Find out what you can’t do…

امروز داشتم پیپر SkillOpt رو می‌خوندم که مایکروسافت منتشر کرده. یه ایده کاربردی برای وقت‌هایی که به وزن‌های مدل دسترسی نداریم یا تغییر دادنشون گرونه.

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

ایده اصلی این پیپر اینه که فایل متنی SKILL.md رو مثل یه متغیر قابل آموزش توی شبکه‌های عصبی در نظر بگیریم. مدل اصلی کاملا ثابت می‌مونه و یه مدل دیگه به عنوان بهینه‌ساز، فقط روی همون متن کار می‌کنه.

سازوکارش دقیقا از مفاهیم یادگیری عمیق الگو برداشته، ولی روی فضای متن:
- اول مدل روی یه دسته از تسک ها کار میکنه تا خروجی‌های درست و غلط جمع بشن.
- مدل بهینه‌ساز، الگوهای تکراریِ شکست و موفقیت رو تحلیل می‌کنه.
- به جای اینکه کل متن رو از نو بنویسه، فقط بخش‌های خاصی رو اضافه یا جایگزین می‌کنه. این سقف تعداد تغییرات مجاز، اینجا دقیقا کارکرد نرخ یادگیری رو داره تا متن یهو به هم نریزه.
- تغییرات روی یه دیتاسِت جداگانه تست می‌شن. فقط اگه امتیاز واقعا بهتر بشه، تغییر روی فایل نهایی اعمال می‌شه.
- اگه تغییری امتیاز رو کم کنه، میره تو یه حافظه موقت تا مدل دوباره همون اشتباه رو برای ویرایش‌های بعدی تکرار نکنه.

نتایج تست‌ها روی شش تا بنچمارک مختلف (از پرسش‌وپاسخ تا کار با فایل‌های اکسل) و هفت تا مدل (از نسخه‌های جی‌پی‌تی ۵.۵ تا qwen) نشون میده که این روش به شدت خوب کار می‌کنه.
- روی جی‌پی‌تی ۵.۵، میانگین دقت رو حدود ۲۳.۵ درصد نسبت به حالت بدون دستورالعمل بالا برده.
- خروجی نهایی بعد از همه این کارها، فقط یه فایل متنی کوچیک بین ۳۰۰ تا ۲۰۰۰ توکنه.
- دستورالعملی که برای یه مدل قوی بهینه شده، به طرز عجیبی روی مدل‌های کوچیک‌تر هم جواب می‌ده و قابل انتقاله.

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

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

🛠 Join @LLMEngineers Community

مدل جدید کیمی K3 کلاً قضیه مدل‌های متن‌باز رو وارد یه مرحله جدید کرده... یه مدل غول‌پیکر با ۲.۸ تریلیون پارامتر کل که موقع جواب دادن به هر کلمه، ۱۰۴ میلیارد پارامترش فعال می‌شن و تا ۱ میلیون توکن متن یا تصویر رو هم‌زمان پردازش می‌کنه.

سازنده‌هاش تونستن بازدهی آموزش مدل رو نسبت به نسل قبل ۲.۵ برابر بهتر کنن. خلاصه تغییرات مهمش ایناست:

- ترکیب هوشمندانه توجه (Hybrid Attention):
برای اینکه موقع خواندن متن‌های خیلی طولانی حافظه کارت گرافیک پر نشه، ۳ لایه از یک مکانیزم سبک و سریع خطی با نام Kimi Delta Attention استفاده کردن و بعد ۱ لایه توجه کامل با نام Gated MLA گذاشتن. این ترکیب باعث می‌شه مدل متن‌های طولانی رو بدون کند شدن بفهمه.

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

- تقسیم کار بین ۸۹۶ کارشناس کوچک (MoE):
به جای یک شبکه یک‌دست، مدل از ۸۹۶ کارشناس تخصصی کوچک تشکیل شده که برای هر کلمه فقط ۱۶ تاشون انتخاب می‌شن. با یک روش ریاضی جدید به اسم Quantile Balancing کاری کردن که بار پردازشی کاملاً مساوی تقسیم بشه و هیچ کارشناسی بی‌کار نمونه.

- پردازش تصویر بومی بدون مدل کمکی (MoonViT-V2):
بخش فهم تصویر مدل از همون روز اول همراه با متن آموزش دیده؛ برعکس مدل‌های دیگه که یک مدل تصویربردار آماده رو به متن وصل می‌کردن. این کار پایداری مدل رو موقع یادگیری خیلی بالاتر برده.

چرا این مدل مهمه؟
- توی تست‌های کدنویسی و هوش خودکار (مثل چرخیدن توی وب و انجام کارهای چندمرحله‌ای) پا‌به‌پای قوی‌ترین مدل‌های تجاری مثل Claude Fable 5 و GPT-5.6 Sol می‌اد.
- نمره ۹۳.۵٪ توی آزمون دانش و استدلال GPQA Diamond گرفته.
- هزینه‌ی اجرایی هر درخواستش حدود یک‌سوم مدل‌های تجاری مشابه هست.

نقطه ضعفش کجاست؟
توی استدلال‌های خیلی پیچیده در سطح تحقیقات علمی (مثل بنچمارک CritPt با نمره ۲۳.۴٪) هنوز عقب‌تر از مدل‌های تجاری قوی می‌افته که نشون می‌ده مدل‌های متن‌باز توی استدلال عمیق هنوز جای کار دارن.
https://github.com/MoonshotAI/Kimi-K3/blob/main/k3_tech_report.pdf

🛠 Join @LLMEngineers Community