LLM Engineers – Telegram
LLM Engineers
1.87K subscribers
103 photos
6 videos
3 files
140 links
A highly technical blog tailored for LLM engineers.

Contact me:
linkedin.com/in/mshojaei77
Download Telegram
نتایج بنچمارک‌های EQ-Bench و نویسندگی خلاقانه برای مدل‌های gpt-oss منتشر شده و خب، ناامیدکننده‌ست. این مدل‌ها در زمینه‌هایی که نیاز به هوش هیجانی و خلاقیت داره، عملکرد ضعیفی از خودشون نشون دادن.

این ضعف احتمالاً به خاطر معماری MoE و تعداد پایین پارامترهای فعال (active parameters) در هر لحظه‌ست. با اینکه مدل کلی مثلاً ۱۲۰ میلیارد پارامتر داره، اما برای پردازش هر توکن فقط بخش کوچکی از این پارامترها فعال می‌شن. این موضوع می‌تونه روی غنای زبانی و خلاقیت خروجی تأثیر منفی بذاره. البته عملکرد بالای این مدل‌ها در بنچمارک‌های دیگه نشون می‌ده که اولویت‌های OpenAI جای دیگه‌ای بوده؛ احتمالاً روی کدنویسی، استدلال منطقی و tool use

🛠 Join @LLMEngineers Community
بزودی خودم یسری بنچمارک روی عملکرد مدل روی دانش زبان فارسی و ایرانی اجرا میکنم و مدل های مختلف رو تست میزنم از جمله مدل های gpt-oss
ملکرد مدل‌های gpt-oss که OpenAI منتشر کرده روی بنچمارک ترکیبی Artificial Analysis Intelligence Index قابل قبوله، ولی بهترین نیست. این مدل‌ها بیشتر از اینکه یکه‌تاز باشن، یه بیس‌لاین قدرتمند برای جامعه اپن‌سورس محسوب میشن.

در نهایت، این مدل‌ها بیشتر برای تحقیق و توسعه و ساختن مدل‌های فاین‌تیون شده روی یک معماری قوی کاربرد دارن تا اینکه مستقیماً در پروداکشن، بهترین نتیجه رو بدن. رقابت در فضای اپن‌سورس خیلی جدیه.

🛠 Join @LLMEngineers Community
LLM Engineers
بزودی خودم یسری بنچمارک روی عملکرد مدل روی دانش زبان فارسی و ایرانی اجرا میکنم و مدل های مختلف رو تست میزنم از جمله مدل های gpt-oss
یه بنچمارک برای ارزیابی مدل‌های زبان بزرگ روی زبان فارسی ساختم به اسم ParsiEval. هدفم این بود که یه ابزار عملی و استاندارد بسازم تا بتونیم عملکرد واقعی مدل‌ها رو بدون هایپ و تبلیغات، روی زبان فارسی بسنجیم.

این پروژه شامل ۳۶۴ سوال چهارگزینه‌ای تو حوزه‌های مختلف مثل علم، تاریخ و دانش عمومیه. سعی کردم سوالات جوری باشه که فهم و استدلال مدل‌ها رو به زبان فارسی به چالش بکشه.

نتایجی که از ارزیابی مدل‌های مختلف گرفتم خیلی جالبه. همونطور که انتظار می‌رفت، gpt-4o با حدود ۷۹٪ دقت، بهترین عملکرد رو داشت. اما نکته مهم‌تر برای من، عملکرد خوب مدل‌های اپن‌سورس مثل kimi-k2 با دقت 77٪ بود.

به نظر من، یکی از کلیدی‌ترین یافته‌های این پروژه، افت عملکرد شدید بعضی مدل‌ها مثل سری Qwen موقع فعال کردن حالت thinking یا همون reasoning بود. برای مثال، مدل ۲۳۵ میلیارد پارامتری Qwen وقتی این قابلیت روشنه، دقتش از ۷۰٪ به زیر ۳۰٪ سقوط می‌کنه. این یعنی این قابلیت‌ها هنوز برای تسک‌های فارسی بهینه نشدن و گاهی نتیجه عکس میدن.

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

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

🧑‍💻 پروژه ParsiEval در گیت‌هاب

🛠 Join @LLMEngineers Community
اینم از نتایج دقت مدل‌ها روی بنچمارک ParsiEval که ساختم.

مدل gpt-4o با ۷۹٪ دقت در صدره بعدشم horizon-beta (احتمالا gpt-5-mini) ولی مدل‌های اوپن سورس kimi و llama-4 هم خیلی نزدیک دنبالش می‌کنن. مدل‌های جدید اپن‌سورس OpenAI یعنی gpt-oss هم عملکرد نسبتا خوبی داشتن و نسخه ۱۲۰ میلیارد پارامتریش به دقت ۷۰٪ رسیده.

🛠 Join @LLMEngineers Community
تو تستای خودم و به نظر شخصی خودم مدلای gpt-oss مزخرف هستن !!
همچنان kimi‌ و qwen رو ترجیح میدم
تیم Qwen دو مدل جدید ۴ میلیاردی از سری Qwen3 منتشر کرده که برای سیستم‌های شخصی یا حتی موبایل ها گزینه‌های خیلی خوبی به حساب میان.

این سری جدید شامل دو نسخه تخصصی می‌شه:

نسخه Instruct: بدون reasoning : برای تسک‌های عمومی، پشتیبانی چندزبانه و کار با متن‌های طولانی (long-context) بهینه‌سازی شده.

نسخه Thinking: با (reasoning) : برای استدلال در حوزه‌های منطق، ریاضی، علوم و کدنویسی طراحی شده.


🤗 مدل Instruct در Hugging Face

🤗 مدل Thinking در Hugging Face

🛠 Join @LLMEngineers Community
LLM Engineers
تیم Qwen دو مدل جدید ۴ میلیاردی از سری Qwen3 منتشر کرده که برای سیستم‌های شخصی یا حتی موبایل ها گزینه‌های خیلی خوبی به حساب میان. این سری جدید شامل دو نسخه تخصصی می‌شه: نسخه Instruct: بدون reasoning : برای تسک‌های عمومی، پشتیبانی چندزبانه و کار با متن‌های…
این مدل با ۴ میلیارد پارامتر به صورت نیتیو از طول محتوای ۲۵۶ هزار توکن پشتیبانی می‌کنه. این یعنی برای کار با اسناد خیلی طولانی روی سیستم‌های با منابع محدود، گزینه‌ی مناسبیه.

نکته جالب اینجاست که این مدل ۴ میلیاردی توی بعضی بنچمارک‌های استدلال و دانش، از نسخه 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
LLM Engineers
https://www.youtube.com/watch?v=0Uu_VJeVVfo
امروز 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
LLM Engineers
🎯 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…
این مقاله یکی از سنگ‌بناهای دیپ لرنینگه که الگوریتم 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
LLM Engineers
Photo
مقاله 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