این مدل با ۴ میلیارد پارامتر به صورت نیتیو از طول محتوای ۲۵۶ هزار توکن پشتیبانی می‌کنه. این یعنی برای کار با اسناد خیلی طولانی روی سیستم‌های با منابع محدود، گزینه‌ی مناسبیه.

نکته جالب اینجاست که این مدل ۴ میلیاردی توی بعضی بنچمارک‌های استدلال و دانش، از نسخه 30B-A3B هم بهتر عمل کرده. مثلا در بنچمارک استدلال منطقی ZebraLogic امتیاز ۸۰.۲ رو گرفته در حالی که نسخه ۳۰ میلیاردی امتیاز ۳۳.۲ داره. یا در بنچمارک ریاضی AIME25 امتیاز ۴۷.۴ رو در مقابل ۲۱.۶ کسب کرده. این جهش عملکردی توی تسک‌های پیچیده برای یه مدل با این سایز خیلی قابل توجهه.

همچنین در بنچمارک Arena-Hard v2 که همسویی مدل با ترجیحات انسانی رو می‌سنجه، امتیاز ۴۳.۴ رو گرفته که نسبت به امتیاز ۹.۵ نسخه قبلی، یک بهبود چشمگیر محسوب می‌شه و نشون می‌ده که مدل در پاسخ به سوالات باز و تولید متن باکیفیت، خیلی بهتر شده.

به نظر من، این نتایج نشون می‌ده که با post-training هدفمند و دیتاست‌های باکیفیت، می‌شه مدل‌های کوچک رو به سطح عملکردی مدل‌های خیلی بزرگ‌تر رسوند، مخصوصا در حوزه‌های تخصصی.

برای استفاده عملی، این مدل به راحتی با ابزارهایی مثل vLLM و sglang برای دیپلوی و با Ollama و llama.cpp برای اجرا روی سیستم‌های لوکال سازگاره. قابلیت tool-calling قوی هم داره که برای Agent ها به قابل استفاده‌ست.

🛠 Join @LLMEngineers Community

یه نفر تو توییتر چندتا نکته‌ی عملی بعد از ور رفتن و فاین‌تیون کردن مدل Dots.OCR روی دیتاست‌های مختلف گفته که قابل توجهه:
این مدل یه VLMـه که همزمان layout parsing و OCR/HTR انجام می‌ده.

۱. مدل خیلی سریع استایل‌های جدید annotation رو یاد می‌گیره. این یکی از اولین چیزاییه که توش خوب می‌شه. پس اگه می‌خواید فقط برای layout parsing ازش استفاده کنید، با تعداد نمونه‌ی کم هم می‌تونید بهش یاد بدید که خروجی رو طبق ساختار دلخواه شما تولید کنه.

۲. بهبود عملکردش روی زبان‌هایی که از قبل پشتیبانی می‌کنه خیلی راحت‌تر از حد انتظار بود. روی اسناد تایپی و دست‌نویس به صورت out-of-the-box کار می‌کنه و می‌تونه نویز زیاد رو هم مدیریت کنه.

۳. روی زبان‌های غیرمنتظره‌ای مثل یونانی باستان (تایپی) و لاتین (هم تایپی و هم بعضی دست‌نویس‌ها) هم بدون هیچ تغییری کار می‌کنه. البته با دست‌نویس‌های لاتین قرون وسطایی به چالش خورده.

۴. یاد دادن یه زبان کاملاً جدید و unsupported به مدل، کار خیلی سختیه. با ۲۳۰۰ صفحه دیتا از یه زبان اسلاوی کلیسایی قدیمی، مدل شروع به یادگیری بعضی کاراکترهای جدید کرده، ولی توی درک syntax زبان به مشکل خورده. دلیلش اینه که language model پایه‌ی اون، هیچ درکی از این زبان نداشته.

۵. در مورد catastrophic forgetting یا فراموشی مدل بعد از فاین‌تیون: گاهی این اتفاق خوبه. مثلاً برای layout parsing، شما می‌خواید که مدل روش قبلی خودش رو فراموش کنه و با فرمت جدید شما هماهنگ بشه. البته تکنیک‌هایی برای جلوگیری از فراموشی وجود داره، ولی کاملاً به مدل و کاربرد نهایی بستگی داره.

به نظر من، این مدل SOTA نیست، ولی با توجه به اندازه‌ی ۱.۷ میلیارد پارامترش، احتمالاً یکی از بهترین‌ها تو کلاس خودشه. اینکه دو تا کار پیچیده‌ی layout parsing و OCR/HTR رو همزمان انجام می‌ده، خیلی با ارزشه. چالش یادگیری یه زبان جدید هم طبیعیه و نشون می‌ده که کیفیت base model چقدر اهمیت داره.

یه فورک هم از ریپازیتوری Dots.OCR منتشر کرذه که اسکریپت‌های لازم برای full fine-tune کردن مدل رو اضافه کرده. این برای کسایی که می‌خوان مدل رو روی دیتای خودشون ترین کنن خوبه.

اسکریپت اصلی برای ترین، train_simple.py هست که هنوز جای کار داره، ولی روی یه GPU مدل H200 تست شده و کار می‌کنه. مدل‌های اولیه‌ی ترین‌شده هم روی هاگینگ فیس در دسترسه.


📃 ریپازیتوری فورک شدهDots.OCR

🛠 Join @LLMEngineers Community

امروز OpenAI یه ایونت برای معرفی GPT-5 برگزار کرد. خلاصه‌ی فنی و بی‌تعارفش رو اینجا می‌گم. تمرکز اصلی روی بهتر کردن مدل برای کار واقعی بود، نه فقط بنچمارک‌های آکادمیک.

کاربرد اصلی GPT-5، تبدیل شدن به یک ابزار تخصصی‌تر و قابل اعتمادتره. دیگه قرار نیست بین یه مدل سریع و یه مدل کند ولی هوشمند انتخاب کنیم. این مدل به صورت خودکار تشخیص می‌ده که یک پرامپت به "تفکر" عمیق‌تری نیاز داره یا نه و منابع محاسباتی رو بر همون اساس تخصیص می‌ده. به این قابلیت میگن dynamic reasoning یا تفکر پویا. هدف اینه که مدل برای تسک‌های ساده سریع باشه و برای مسائل پیچیده، خودش زمان بیشتری برای تحلیل بذاره.

از نظر فنی، چندتا آپدیت مهم برای دولوپرها وجود داره:

سه مدل جدید توی API عرضه شده: GPT-5 (مدل اصلی)، GPT-5 mini و GPT-5 nano که هر کدوم برای کاربردهای مختلف با trade-off بین هزینه و سرعت طراحی شدن.

قابلیت Custom Tools اضافه شده که به مدل اجازه می‌ده خروجی رو به صورت plaintext بده، نه فقط JSON. این برای وقتی که آرگومان‌های طولانی مثل یک اسکریپت کد داریم خیلی کاربردیه و دردسر escaping کاراکترها توی JSON رو حذف می‌کنه.

با Structured Outputs می‌تونیم خروجی مدل رو با استفاده از regular expression یا context-free grammar محدود کنیم تا همیشه فرمت دلخواه ما رو داشته باشه.

یک پارامتر جدید برای verbosity (پرحرفی) و reasoning effort (میزان تلاش برای استدلال) اضافه شده که کنترل بیشتری روی رفتار مدل به ما می‌ده.

کانتکست هم به 400K توکن افزایش پیدا کرده.

بخش بزرگی از ارائه روی قابلیت‌های کدنویسی متمرکز بود. دموهایی از ساخت اپلیکیشن‌های وب تعاملی، داشبوردهای مالی و حتی بازی‌های ساده 3D با یک پرامپت نشون داده شد. به نظر من، این دموها چشم‌گیر بودن ولی هنوز توی محیط ایزوله اجرا میشن. چالش اصلی وقتیه که این مدل بخواد روی یک codebase واقعی و پیچیده کار کنه، باگی رو پیدا کنه و بدون اینکه چیز دیگه‌ای رو خراب کنه، اون رو رفع کنه. دمو رفع باگ توی Cursor قدم مثبتی بود، ولی باید دید در عمل چقدر قابل اتکاست.

یه نکته‌ی مهم دیگه، بحث آموزش مدل با داده‌های سینتتیک بود. گفته شد که از نسل‌های قبلی مدل‌ها (o3) برای تولید "برنامه درسی" (curriculum) باکیفیت برای آموزش GPT-5 استفاده شده. این یعنی یک حلقه‌ی بهبود بازگشتی (recursive improvement loop) که در اون مدل‌ها به آموزش نسل بعدی خودشون کمک می‌کنن. این ایده جدید نیست ولی اجرای موفقش می‌تونه جهش بزرگی در کیفیت مدل‌ها ایجاد کنه.

در مورد ایمنی، سیستم جدیدی به اسم Safe Completion معرفی شد. به جای رد کردن کامل پرامپت‌های حساس (dual-use)، مدل سعی می‌کنه در چارچوب ایمنی، حداکثر کمک رو ارائه بده. مثلاً به جای اینکه دستور ساخت مواد منفجره رو بده، در مورد پروتکل‌های ایمنی و راهنمای سازنده صحبت می‌کنه. این رویکرد روی کاغذ خوبه، ولی ممکنه در عمل به جواب‌های محافظه‌کارانه و غیرکاربردی منجر بشه.

به نظر من، GPT-5 یک پیشرفت تدریجی ولی مهم نسبت به GPT-4o هست. تمرکز روی reliability و agentic behavior توی کدنویسی، دقیقاً همون چیزیه که جامعه دولوپرها نیاز داشت. اشباع شدن بنچمارک‌ها (مثل کسب امتیاز ۹۹٪ در یک تست) نشون می‌ده که دیگه این معیارها به تنهایی برای سنجش توانایی مدل کافی نیستن و باید روی کاربردهای واقعی تمرکز کرد. GPT-5 قدم درستی در این مسیره، ولی هایپ "متخصص سطح PhD" رو باید نادیده گرفت. این یک ابزار بهتره، نه یک ایجنت مستقل.

در ادامه پست های بیشتری راجب جزئیاتش قرار میدم

🛠 Join @LLMEngineers Community

یه چارت جدید از بنچمارک SWE-bench ساختم که وضعیت فعلی مدل‌های کدنویسی رو به خوبی نشون می‌ده. این بنچمارک توانایی مدل‌ها در حل کردن issue های واقعی از پروژه‌های گیت‌هاب رو می‌سنجه.

رقابت در صدر جدول خیلی نزدیکه. مدل Grok 4 Heavy با ۷۵٪ اوله، ولی GPT-5 با ۷۴.۹٪ و Opus 4.1 با ۷۴.۵٪ تقریباً هم‌سطح هستن. این اختلاف‌های ناچیز در عمل تفاوتی ایجاد نمی‌کنه و نشون می‌ده که بهترین مدل‌ها به یک سطح از توانایی رسیدن.

به نظر من، دیگه تفاوت‌های ۱-۲ درصدی در این بنچمارک‌ها معیار اصلی نیست. الان فاکتورهایی مثل کیفیت API، قیمت و قابلیت‌های agentic برای کار طولانی‌مدت روی یک پروژه، اهمیت بیشتری پیدا کرده. تمرکز از روی صرفاً «حل مسئله» به سمت «یکپارچه‌سازی در workflow توسعه» شیفت پیدا کرده.

🛠 Join @LLMEngineers Community

🎯 100 Days of Reading ML / LLM Papers Challenge

Day 5: Learning representations by back-propagating errors

🔗 https://gwern.net/doc/ai/nn/1986-rumelhart-2.pdf

Additional Resources:
⦁ 📄 Principles of training multi-layer neural network using backpropagation
⦁ 🎥 CS231n Winter 2016: Lecture 4: Backpropagation, Neural Networks 1
⦁ 📄 Yet Another Derivation of Backpropagation in Matrix Form
⦁ 🎥 Backpropagation, intuitively | Deep Learning Chapter 3

🛠 @LLMEngineers

این مقاله یکی از سنگ‌بناهای دیپ لرنینگه که الگوریتم back-propagation رو به شکل امروزی به دنیا معرفی کرد. با اینکه مال سال ۱۹۸۶ هست، ولی فهمیدنش برای هر مهندس هوش مصنوعی واجبه چون اساس کار اکثر شبکه‌های عصبی روی همین ایده بنا شده.

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

ایده اصلی back-propagation اینه:
۱. Forward Pass:
یک ورودی به شبکه داده می‌شه و خروجی محاسبه می‌شه.
۲. محاسبه خطا:
خروجی شبکه با خروجی مطلوب مقایسه و میزان خطا (مثلاً با Mean Squared Error) اندازه‌گیری می‌شه.
۳. Backward Pass:
اینجا بخش کلیدی ماجراست. خطا از لایه خروجی به سمت لایه‌های ورودی پس‌فرستاده می‌شه. با استفاده از قاعده زنجیره‌ای (chain rule) در مشتق‌گیری، سهم هر وزن (weight) در خطای نهایی محاسبه می‌شه (∂E/∂w). به عبارت ساده‌تر، مشخص می‌شه هر "پیچ" یا وزن، چقدر در اشتباه بودن جواب نهایی مقصر بوده.
۴. آپدیت وزن‌ها:
وزن‌ها در جهتی آپدیت می‌شن که خطا رو کاهش بده (خلاف جهت گرادیان).

نکته انقلابی این مقاله این بود که نشون داد لایه‌های مخفی، به صورت خودکار یاد می‌گیرن که ویژگی‌های مهم و معناداری از داده رو استخراج کنن. این همون representation learning هست. در مثال معروف family trees که تو مقاله اومده، واحدهای مخفی یاد گرفته بودن مفاهیمی مثل generation (اینکه فرد متعلق به کدام نسل است) یا branch of the family (کدام شاخه از خانواده) رو کدگذاری کنن، بدون اینکه کسی این مفاهیم رو بهشون یاد داده باشه.

چند تا نکته فنی مهم که تو همین مقاله بهش اشاره شده و هنوزم کاربرد داره:

Momentum:
برای بهبود سرعت همگرایی و فرار از local minima های ضعیف، یک ترم momentum به آپدیت وزن‌ها اضافه کردن. این ایده پایه‌ی بسیاری از بهینه‌سازهای مدرن مثل Adam هست.

Random Initialization:
برای شکستن تقارن و جلوگیری از اینکه همه نورون‌های یک لایه چیز یکسانی یاد بگیرن، وزن‌ها رو با مقادیر تصادفی کوچک مقداردهی اولیه کردن.

Generalization to RNNs:
در انتهای مقاله، نشون دادن که چطور می‌شه با باز کردن (unfold) یک شبکه بازگشتی در زمان، از همین الگوریتم برای آموزش اونها استفاده کرد. این ایده، اساس Backpropagation Through Time یا BPTT هست.

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

🛠 Join @LLMEngineers Community

مقاله ReAct یه الگوی ساده ولی خیلی قدرتمند رو برای مدل‌های زبانی بزرگ (LLM) معرفی می‌کنه که بهشون اجازه می‌ده همزمان هم استدلال (Reasoning) کنن و هم عمل (Acting). کاربرد اصلیش ساختن ایجنت‌های هوشمندیه که بتونن با ابزارهای خارجی (مثل API یا محیط‌های تعاملی) کار کنن و تسک‌های پیچیده رو حل کنن، بدون اینکه دچار توهم (hallucination) بشن.

ایده‌ی اصلی اینه که مدل‌ها CoT فقط در ذهن خودشون استدلال می‌کنن و به دنیای خارج دسترسی ندارن. این باعث می‌شه خیلی وقت‌ها اطلاعات غلط یا تاریخ مصرف گذشته رو به عنوان فکت ارائه بدن. از طرف دیگه، مدل‌های Act-only فقط می‌تونن یه سری اکشن رو پشت سر هم تولید کنن، ولی توانایی برنامه‌ریزی سطح بالا، ردیابی وضعیت، یا اصلاح برنامه در صورت بروز خطا رو ندارن.

معماری ReAct این دو تا رو با هم ترکیب می‌کنه و یک حلقه Thought -> Action -> Observation به وجود میاره:
۱. فکر (Thought): مدل اول یه استدلال درونی تولید می‌کنه. مثلاً "برای حل این مسئله، باید اول فلان اطلاعات رو از ویکی‌پدیا پیدا کنم." این thought به مدل کمک می‌کنه تسک رو به مراحل کوچیک‌تر بشکنه و استراتژی بچینه.
۲. عمل (Action): بر اساس اون فکر، مدل یه اکشن قابل اجرا تولید می‌کنه. مثلاً search['some entity'].
۳. مشاهده (Observation): این اکشن در یک محیط خارجی (مثلاً API ویکی‌پدیا) اجرا می‌شه و نتیجه‌ش به عنوان یه مشاهده به مدل برمی‌گرده.

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

نتایج مقاله روی چندتا بنچمارک:
روی تسک‌های دانش‌محور مثل HotpotQA (پرسش و پاسخ چند مرحله‌ای)، ReAct به شکل قابل توجهی از CoT قابل اعتمادتره. تحلیل خطاها نشون می‌ده که ۵۶٪ از شکست‌های CoT به خاطر توهم اطلاعاته، در حالی که ReAct با دسترسی به اطلاعات خارجی، این مشکل رو تا حد زیادی نداره.

روی تسک‌های تصمیم‌گیری تعاملی مثل ALFWorld (یه بازی متنی) و WebShop (شبیه‌ساز خرید آنلاین)، ReAct با اختلاف زیاد، مدل‌های مبتنی بر Imitation Learning و Reinforcement Learning رو شکست می‌ده. مثلا روی ALFWorld نرخ موفقیت رو تا ۳۴٪ و روی WebShop تا ۱۰٪ بالا می‌بره، اونم در حالی که فقط با یکی دو تا مثال (few-shot) پرامپت شده. این نشون می‌ده که توانایی استدلال پویا، یک مهارت بسیار عمومی‌تر و کارآمدتر از تقلید صرف از روی هزاران نمونه‌ی انسانیه.

به نظر من، ReAct فقط یه تکنیک پرامپتینگ نیست؛ یه الگوی معماری (architectural pattern) برای ساخت ایجنت‌های خودمختاره. تمام فریمورک‌های مدرن مثل LangChain یا LlamaIndex که بحث Tool-use رو پیاده‌سازی می‌کنن، در هسته‌ی خودشون از همین ایده الهام گرفتن. این مقاله، پشتوانه‌ی علمی و تجربی این معماریه.

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

در نهایت، ReAct به ما نشون می‌ده که ترکیب استدلال درونی با تعامل با دنیای بیرون، کلید ساختن سیستم‌های هوش مصنوعی قدرتمندتر، قابل اعتمادتر و البته قابل تفسیرتره. چون می‌تونیم قدم به قدم ببینیم مدل به چی فکر کرده و چرا یه تصمیم خاص رو گرفته.

📃 ReAct: Synergizing Reasoning and Acting in Language Models

🛠 Join @LLMEngineers Community

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

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

🛠 Join @LLMEngineers Community

مقاله‌ی Pre-Act یه بهبود مستقیم و منطقی روی معماری معروف ReAct ارائه می‌ده. کاربرد اصلیش اینه که به ایجنت‌های مبتنی بر LLM کمک می‌کنه تسک‌های پیچیده که به چند مرحله و ابزار نیاز دارن رو با برنامه‌ریزی قبلی و دقت بالاتری انجام بدن. این روش هم برای ایجنت‌های مکالمه‌محور (conversational) و هم غیرمکالمه‌محور کاربرد داره.

مشکل اصلی ReAct اینه که استدلالش (Thought) معمولاً کوته‌بینانه است و فقط برای اکشن بعدی تولید می‌شه. برای کارهای چند مرحله‌ای، این مدل تفکر کافی نیست و ایجنت ممکنه مسیر رو گم کنه. Pre-Act این مشکل رو با مجبور کردن مدل به تولید یک "نقشه راه چند مرحله‌ای" (multi-step plan) در همون ابتدای کار حل می‌کنه.

روند کار به این شکله:
۱. برنامه‌ریزی (Plan): به جای یه Thought ساده، مدل یه پلن کامل با تمام مراحل لازم برای رسیدن به جواب نهایی رو تولید می‌کنه. مثلاً:
* مرحله ۱: اول باید از ابزار get_user_info استفاده کنم چون به اطلاعات کاربر نیاز دارم.
* مرحله ۲: بعد با اطلاعات دریافتی، ابزار check_inventory رو فراخوانی می‌کنم.
* مرحله ۳: در نهایت بر اساس موجودی، به کاربر جواب می‌دم.
۲. اجرا و بازبینی (Act & Revise): مدل مرحله اول پلن رو اجرا می‌کنه، observation رو از ابزار می‌گیره و بعد پلن رو برای مراحل بعدی بازبینی می‌کنه. یعنی وضعیت مراحل قبلی (Previous Steps) و مراحل بعدی (Next Steps) رو همیشه در context خودش نگه می‌داره. این باعث می‌شه ایجنت همیشه بدونه کجای مسیره و قدم بعدیش چیه.

نکته‌ی کلیدی این مقاله که خیلی برای ما مهمه، بحث fine-tuning مدل‌های کوچیک‌تره. نویسنده‌ها نشون می‌دن که با این روش می‌شه مدل‌های اپن سورس مثل Llama-3.1-70B رو طوری fine-tune کرد که عملکردشون حتی از مدل‌های غول‌پیکر و بسته‌ای مثل GPT-4 هم بهتر بشه. این یعنی کاهش هزینه و تأخیر (latency) در کاربردهای واقعی.

نتایج تجربی خیلی قویه:
روی دیتاست Almita (که برای مدل out-of-domain حساب می‌شه)، مدل Llama-3.1-70B که با روش Pre-Act فاین‌تیون شده، در دقت اکشن (action accuracy) تا ۶۹.۵٪ و در نرخ تکمیل هدف (goal completion rate) تا ۲۸٪ از GPT-4 بهتر عمل کرده. این یه دستاورد خیلی مهمه و نشون می‌ده که با داده‌های باکیفیت و یه استراتژی هوشمندانه، می‌تونیم از مدل‌های اپن‌سورس نتایج فوق‌العاده‌ای بگیریم.

استراتژی fine-tuning اون‌ها هم جالبه و از curriculum learning استفاده می‌کنه:
۱. مرحله اول: مدل رو روی یه دیتاست بزرگ (مثل Glaive) با فرمت ساده‌ی ReAct فاین‌تیون می‌کنن تا اصول اولیه‌ی استفاده از ابزار رو یاد بگیره.
۲. مرحله دوم: با استفاده از LoRA، مدل رو روی یه دیتاست کوچیک‌تر ولی باکیفیت‌تر که با فرمت Pre-Act و توسط انسان لیبل‌گذاری شده، بیشتر فاین‌تیون می‌کنن تا توانایی برنامه‌ریزی چند مرحله‌ای رو یاد بگیره.

به نظر من، Pre-Act تکامل طبیعی ReAct هست. اگه ReAct به مدل‌ها یاد داد که چطور "عمل" کنن، Pre-Act بهشون یاد می‌ده که چطور "استراتژی" بچینن. این یه جهش از یه کارگر ساده به یه مدیر پروژه‌ست. بزرگترین چالش عملیاتی این روش، تهیه‌ی دیتاست باکیفیت برای fine-tuning هست که نیاز به تخصص و هزینه داره، ولی نتایج نشون می‌ده که این سرمایه‌گذاری کاملاً ارزشش رو داره.

📃 Pre-Act: Multi-Step Planning and Reasoning Improves Acting in LLM Agents

🛠 Join @LLMEngineers Community

مقاله‌ی TURA یه معماری خیلی مهم رو برای حل یکی از بزرگترین مشکلات سیستم‌های جستجوی مبتنی بر RAG معرفی می‌کنه. مشکل اینه که RAG استاندارد، فقط روی داده‌های استاتیک و از قبل ایندکس شده (مثل صفحات وب) کار می‌کنه و نمی‌تونه به کوئری‌های داینامیک، real-time یا تراکنشی جواب بده. مثلاً نمی‌تونه قیمت بلیط هواپیما برای فردا رو چک کنه یا موجودی یه کالا رو از دیتابیس دربیاره.

معماری TURA یا Tool-Augmented Unified Retrieval Agent این شکاف رو با ترکیب RAG و یک ایجنت هوشمند که از ابزارها (tools) استفاده می‌کنه، پر می‌کنه. این سیستم در یک محصول واقعی با ده‌ها میلیون کاربر پیاده‌سازی شده و نتایجش فوق‌العاده‌ست.

ساختار TURA سه مرحله‌ی اصلی داره:
۱. بازیابی هوشمند ابزار (Intent-Aware Retrieval): اول، یه LLM کوئری پیچیده‌ی کاربر رو به چندتا زیر-کوئری اتمی و مستقل می‌شکنه. بعد، به جای جستجو در وب، در یک کاتالوگ از ابزارها جستجو می‌کنه. برای اینکه ابزارها بهتر پیدا بشن، از یه تکنیک هوشمندانه به اسم index augmentation استفاده شده؛ یعنی برای هر ابزار، کلی کوئری مصنوعی تولید می‌کنن تا فضای معنایی اون ابزار غنی‌تر بشه و راحت‌تر پیدا بشه.

۲. برنامه‌ریزی تسک مبتنی بر DAG: این ماژول، زیر-تسک‌ها و ابزارهای پیدا شده رو می‌گیره و یک گراف جهت‌دار غیرمدور (DAG) ازشون می‌سازه. این کار برای بهینه‌سازی تأخیر (latency) حیاتیه. سیستم تشخیص می‌ده کدوم تسک‌ها به هم وابسته‌ان (مثلاً اول باید آدرس هتل رو بگیری بعد مسیر رو برنامه‌ریزی کنی) و کدوم‌ها مستقلن و می‌تونن به صورت موازی اجرا بشن (مثلاً چک کردن وضعیت آب‌وهوا و پیدا کردن جاذبه‌های توریستی). این موازی‌سازی، سرعت پاسخ رو برای کوئری‌های پیچیده به شدت بالا می‌بره.

۳. اجرای ایجنت تقطیر شده (Distilled Agent Executor): این بخش، شاهکار مهندسی این مقاله است. استفاده از یه مدل غول‌پیکر مثل Deepseek-V3 برای اجرای هر مرحله از تسک، در عمل به خاطر هزینه و latency غیرممکنه. برای حل این مشکل، از تقطیر ایجنت (agent distillation) استفاده شده.
* اول با مدل بزرگ (معلم)، کلی مسیر اجرای بهینه (expert trajectories) به همراه استدلال chain-of-thought تولید می‌کنن.
* این داده‌ها رو به صورت خودکار فیلتر می‌کنن تا فقط مسیرهای درست و بهینه باقی بمونن.
* بعد یه مدل خیلی کوچیک‌تر (دانش‌آموز) مثل Qwen3-4B رو روی این داده‌های باکیفیت fine-tune می‌کنن.
* تکنیک کلیدی اینجا Mixed-Rationale SFT هست: مدل دانش‌آموز با استدلال chain-of-thought آموزش می‌بینه، ولی در زمان اجرا (inference)، ازش خواسته می‌شه که فقط اکشن نهایی رو بدون تولید متن استدلال، خروجی بده. اینطوری، مدل استدلال رو به صورت ضمنی یاد گرفته ولی هزینه‌ی تولید توکن‌های اضافه رو در زمان اجرا نداره.

نتایجش فوق‌العاده است:
مدل تقطیر شده‌ی Qwen3-4B در دقت استفاده از ابزار (۸۸.۳٪) حتی از مدل معلم خودش (Deepseek-V3) و GPT-4o (با دقت ۸۱.۷٪) بهتر عمل کرده. همزمان، latency رو از ۶.۸ ثانیه به ۷۵۰ میلی‌ثانیه کاهش داده. در تست آنلاین A/B هم نرخ موفقیت (Session Success Rate) رو ۸.۹٪ افزایش داده که در مقیاس صنعتی یک عدد عظیمه.

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


📃 TURA: Tool-Augmented Unified Retrieval Agent for AI Search

🛠 Join @LLMEngineers Community

سربراس (Cerebras) یه رویکرد کاملاً متفاوت برای اجرای مدل‌های زبانی بزرگ داره که اساساً با معماری GPU-محور انویدیا فرق می‌کنه. کاربرد اصلیش، حذف کردن گلوگاه‌هاییه که موقع ترین و اینفرنس مدل‌های خیلی بزرگ روی کلاسترهای GPU به وجود میاد؛ یعنی مشکلاتی مثل پهنای باند حافظه، لتنسی و ارتباط بین چیپ‌ها.

معماری این شرکت بر اساس یک ایده کلیدی ساخته شده: به جای وصل کردن صدها GPU کوچیک به هم، یک چیپ غول‌پیکر به اندازه کل یک ویفر سیلیکونی ساخته بشه. این تکنولوژی که بهش Wafer-Scale Integration گفته می‌شه، تمام هسته‌های پردازشی و حافظه رو روی یک چیپ یکپارچه می‌کنه. اینجوری دیگه خبری از ارتباط کند بین چیپ‌ها و وابستگی به حافظه‌های خارج از چیپ مثل HBM نیست.

🛠 Join @LLMEngineers Community

تحلیل دقیق تر:

قضیه از این قراره که Cerebras با سیستم‌هاش داره رکوردهای سرعت Inference رو برای مدل‌های غول‌پیکر جابجا می‌کنه. چندتا عدد واقعی از بنچمارک‌های اخیر:

Llama 3.1 405B: حدود ۹۷۰ توکن بر ثانیه

Qwen3-Coder 480B: حدود ۲۰۰۰ توکن بر ثانیه

GPT-OSS 120B: حدود ۳۰۰۰ توکن بر ثانیه

این اعداد نشون می‌ده معماری Wafer-Scale دیگه یه پروژه تحقیقاتی جالب نیست، بلکه یه راه حل عملی برای رسیدن به سرعت‌های خیلی بالاست.

چرا Cerebras اینقدر سریعه؟ معماری Wafer-Scale

برخلاف رویکرد سنتی که توش چندین GPU رو با شبکه به هم وصل می‌کنیم، Cerebras یه تراشه غول‌پیکر به اندازه کل یک ویفر سیلیکونی ساخته. جدیدترین مدلش، WSE-3، حدود ۹۰۰ هزار هسته پردازشی بهینه شده برای هوش مصنوعی و ۴۴ گیگابایت حافظه SRAM فوق سریع رو روی یک چیپ یکپارچه کرده.

این معماری چندتا گلوگاه اصلی که تو کلاسترهای GPU وجود داره رو حذف می‌کنه:

۱. پهنای باند حافظه فضایی: بزرگترین مزیت Cerebras، حافظه On-Chip یا همون SRAM هست. WSE-2 پهنای باند حافظه داخلی حدود 20 PB/s (پتابایت بر ثانیه) داره. این عدد رو مقایسه کنید با پهنای باند حافظه HBM یه GPU مثل H100 که حدود 3 TB/s (ترابایت بر ثانیه) هست. یعنی بیش از ۷۰۰۰ برابر پهنای باند بیشتر. وقتی پارامترهای مدل و KV Cache داخل همین حافظه فوق سریع قرار می‌گیرن، دیگه نیازی به رفت‌وآمد به حافظه کندترِ خارج از چیپ نیست و عملیات‌های Memory-Bound مثل Attention به شدت سریع میشن.

۲. حذف گلوگاه شبکه: تو کلاسترهای GPU، مدل‌های بزرگ باید بین چندین چیپ Shard بشن. این یعنی بخش زیادی از زمان صرف ارتباط بین GPUها از طریق شبکه‌هایی مثل NVLink یا InfiniBand می‌شه. توی Cerebras، چون همه هسته‌ها روی یک ویفر هستن، با یه Fabric یا شبکه داخلی 2D Mesh با پهنای باند 220 Pb/s (پتابیت بر ثانیه) به هم وصلن. این یعنی ارتباط بین هسته‌ها هزاران برابر سریع‌تر از ارتباط بین GPUهاست و عملاً سربار ارتباطی حذف می‌شه.

۳. پشتیبانی سخت‌افزاری از Sparsity: هسته‌های پردازشی Cerebras که بهشون SLAC میگن، طوری طراحی شدن که عملیات ضرب در صفر رو به صورت سخت‌افزاری نادیده می‌گیرن. از اونجایی که وزن‌ها و Activationهای مدل‌های زبانی می‌تونن تا ۹۰٪ اسپارس باشن، این قابلیت بدون کاهش دقت، حجم محاسبات رو ۲ تا ۳ برابر کم می‌کنه.

۴. تکنیک Weight Streaming: برای مدل‌هایی که بزرگتر از حافظه SRAM هستن (مثلاً مدل‌های 400B)، پارامترها از حافظه خارجی (تا ۱.۲ پتابایت DRAM) به داخل چیپ استریم می‌شن. این کار با سخت‌افزار اختصاصی مدیریت می‌شه تا latency به حداقل برسه و نیاز به Sharding سنتی از بین بره.

چرا کلاسترهای GPU کندتر عمل می‌کنن؟

مشکل اصلی GPUها برای Inference مدل‌های بزرگ، معماری توزیع‌شده‌شونه. وقتی یه مدل مثل Llama 3 405B رو روی کلاستر H100 اجرا می‌کنید، مجبورید مدل رو بین ده‌ها GPU تقسیم کنید. هر توکن که تولید می‌شه، نیاز به ارتباط all-reduce بین همه GPUها برای محاسبات Attention داره. اینجاست که سرعت کلاستر توسط پهنای باند و latency شبکه محدود می‌شه، نه قدرت محاسباتی خود GPUها. حتی با سریع‌ترین شبکه‌ها، این ارتباطات سربار قابل توجهی ایجاد می‌کنن که Cerebras با معماری یکپارچه‌اش اون رو حذف کرده.

Wafer-scale Computing: Advancements, Challenges, and Future Perspectives

🛠 Join @LLMEngineers Community

ترکیب مدل‌های زبان بزرگ یا LLM Merging یه تکنیک خیلی کاربردیه. به جای اینکه یه مدل رو از صفر برای چند تا کار مختلف fine-tune کنی، میای چند تا مدل که هر کدوم تو یه چیزی خوبن رو با هم ترکیب می‌کنی. مثلاً توانایی کدنویسی یه مدل با خلاقیت نوشتاری یه مدل دیگه.

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

The Ultimate Guide to Merging LLMs

🛠 Join @LLMEngineers Community

گزارش فنی مدل GLM-4.5 از طرف Zhipu AI و دانشگاه Tsinghua منتشر شده که ارزش بررسی داره.

این مدل به طور خاص توی تسک‌های ایجنت (Agentic)، استدلال (Reasoning) و کدنویسی (Coding) خیلی قویه. این مدل با پارامترهای فعال کمتر، تونسته با مدل‌های بزرگ و اختصاصی مثل Claude و GPT رقابت کنه و در بعضی بنچمارک‌ها حتی ازشون بهتر عمل کنه. معماریش MoE هست با ۳۵۵ میلیارد پارامتر کلی و ۳۲ میلیارد پارامتر فعال در هر لحظه. یه نسخه سبک‌تر به اسم GLM-4.5-Air با ۱۰۶ میلیارد پارامتر هم داره.

نکته مهم و کلیدی این مدل، استراتژی ترینینگ چندمرحله‌ای و خیلی هوشمندانه‌شه.
اول، یه pre-training عمومی روی ۲۳ تریلیون توکن انجام شده.
دوم، وارد فاز mid-training شدن که اینجا قابلیت‌های خاص مدل رو تقویت کردن. توی این فاز، کانتکست رو تا ۱۲۸ هزار توکن افزایش دادن و روی دیتاست‌های تخصصی تمرکز کردن:

کد در سطح ریپازیتوری (Repo-level Code): برای اینکه مدل وابستگی بین فایل‌های مختلف یه پروژه نرم‌افزاری رو یاد بگیره.

دیتای استدلال سنتتیک (Synthetic Reasoning Data): برای تقویت توانایی حل مسائل پیچیده ریاضی و علوم.

دیتای ایجنت و کانتکست طولانی: شامل مسیرهای تعاملی (trajectories) سنتتیک برای ایجنت‌ها.

جذاب‌ترین بخش به نظر من، فاز post-training هست که بهش میگن Expert Model Iteration. اینجا اول چندتا مدل متخصص (expert) برای حوزه‌های مشخص مثل استدلال، ایجنت و چت عمومی ترین کردن. بعد با تکنیک self-distillation، قابلیت‌های این مدل‌های متخصص رو توی یه مدل واحد و یکپارچه ترکیب کردن. این رویکرد باعث شده مدل نهایی بتونه برای هر تسک، بهترین استراتژی رو انتخاب کنه.

این مدل یه حالت استدلال هیبریدی (hybrid reasoning) هم داره. یعنی برای تسک‌های پیچیده که نیاز به فکر کردن دارن، از حالت thinking استفاده می‌کنه و برای جواب‌های سریع، مستقیم پاسخ میده.

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

یادگیری تقویتی مبتنی بر سختی (Difficulty-based RL): برای Reinforcement Learning، از یه curriculum دو مرحله‌ای استفاده کردن. اول با مسائل متوسط شروع کردن و بعد که مدل قوی‌تر شد، مسائل خیلی سخت رو بهش دادن تا از پدیده reward hacking و درجا زدن جلوگیری کنن.

تمپلیت جدید برای Function Calling: یه تمپلیت جدید شبیه XML برای فراخوانی فانکشن‌ها طراحی کردن که نیاز به escape کردن کاراکترهای زیاد توی کد رو از بین می‌بره. این یه مشکل کوچیک ولی خیلی مهم برای مدل‌های ایجنته.

تست RL روی کانتکست طولانی: به این نتیجه رسیدن که ترین کردن RL به صورت تک‌مرحله‌ای روی حداکثر طول خروجی (مثلاً 64K)، بهتر از افزایش تدریجی طول خروجیه.

از نظر عملکرد، GLM-4.5 توی بنچمارک SWE-bench Verified از GPT-4.1 و Gemini-2.5-Pro بهتر عمل کرده و توی تسک‌های ایجنت، رقیب جدی Claude Sonnet 4 محسوب میشه.

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

📃 گزارش فنی GLM-4.5

🛠 Join @LLMEngineers Community

یه مدل جدید ۴ میلیاردی به اسم Jan-v1 معرفی شده که کار اصلیش سرچ وب و ریسرچ عمیقه. تیم سازنده‌ش اون رو به عنوان یه جایگزین open-source برای Perplexity Pro معرفی کرده که به صورت کاملاً local هم اجرا میشه.

این مدل روی نسخه‌ی جدید Qwen یعنی Qwen3-4B-Thinking ساخته شده که تا ۲۵۶ هزار توکن context length داره. به طور مشخص برای reasoning و استفاده از ابزارها (tool use) فاین‌تیون شده که این یعنی برای کارهای agentic و حل مسائل پیچیده بهینه شده.

توی ارزیابی SimpleQA، به دقت ۹۱.۱٪ رسیده که طبق بنچمارک‌های منتشر شده، عملکردش یه مقدار از Perplexity Pro بهتره. این نشون میده که مدل‌های با این سایز هم میتونن توی تسک‌های واقعی مثل پرسش و پاسخ مبتنی بر فکت، عملکرد خیلی خوبی داشته باشن.

برای استفاده، میشه اون رو توی Jan App، یا با فریمورک‌های llama.cpp و vLLM اجرا کرد. اگه از Jan App استفاده می‌کنید، برای فعال کردن قابلیت سرچ باید از تنظیمات، Experimental Features رو روشن کنید و بعدش یه سرور MCP مثل Serper رو فعال کنید تا به اینترنت دسترسی داشته باشه.

به نظر من، حرکت به سمت مدل‌های کوچیک‌تر و تخصصی که به صورت local هم اجرا میشن، خیلی مهمه. این مدل‌ها کنترل بیشتری به دولوپر میدن و وابستگی به API های پولی رو کم می‌کنن. اینکه یه مدل 4B داره با سرویسی مثل Perplexity رقابت می‌کنه، نشون میده که آینده فقط دست مدل‌های غول‌پیکر نیست و مدل‌های بهینه شده برای تسک‌های خاص، جایگاه خودشون رو دارن.

فایل‌های مدل رو می‌تونید از لینک‌های زیر بگیرید:

📃 مدل اصلی Jan-v1-4B

📃 نسخه GGUF برای llama.cpp

🛠 Join @LLMEngineers Community

🛠 Join @LLMEngineers Community

یه تست سریع و عملی روی چندتا LLM برای یه تسک ساده‌ی NLP تشخیص زبان انجام دادم.

شرایط تست مشخص بود: همه مدل‌ها به وب دسترسی داشتن، پس پیدا کردن بهترین و سریع‌ترین راه‌حل هم بخشی از آزمون بود. مهم‌تر اینکه، تست کاملاً Zero-Shot بود؛ یعنی کد تولید شده باید در اولین تلاش، بدون هیچ دخالت یا اصلاح دستی، اجرا می‌شد.

نتایج خیلی جالب بود. Claude Sonnet 4 با اختلاف بهترین عملکرد رو داشت. نه فقط کد رو Zero-Shot و بدون خطا تحویل داد، بلکه بهینه‌ترین الگوریتم رو با latency فقط 0.63 میلی‌ثانیه انتخاب کرد. نکته جالب‌تر این بود که توی کدش ۴ تا روش مختلف رو هم مقایسه کرده بود که این نشون‌دهنده فهم عمیق مسئله‌ است.

در مقابل، مدل‌هایی مثل Qwen Coder یا DeepSeek R1 که ادعای زیادی روی کد دارن، روی این تسک و با این شرایط fail شدن.

🛠 Join @LLMEngineers Community

گوگل از یه ورژن خیلی کوچیک Gemma 3 رونمایی کرده که ۲۷۰ میلیون پارامتریه.

کاربرد اصلی این مدل برای fine-tune کردن سریع و اجرای تسک‌های هوش مصنوعی روی دستگاه‌های کاربر (on-device) هست. نقطه قوت کلیدی این مدل، توانایی بالای اون در دنبال کردن دستورات یا instruction following هست که توی بنچمارک IFEval سنجیده شده.

توی نمودار مقایسه‌ای، نسخه 270M با اینکه سایز کوچیکی داره، مدل‌های بزرگتری مثل Qwen 2.5 0.5B و SmolLM2-360M رو با اختلاف کنار زده. این موضوع نشون‌دهنده بهینگی بالا در معماری و کیفیت دیتاست pre-train هست.

🛠 Join @LLMEngineers Community