RL in LLMs

توی Pipeline آموزش LLMهای جدید، RL دیگه فقط اون مرحله‌ی آخر برای alignment نیست. الان مستقیم برای ساختن reasoning، کدنویسی، سرچ و قابلیت‌های ایجنتی استفاده می‌شه. برای یه AI Engineer هم به نظرم مهم‌ترین تغییر همین‌جاست: دیگه فقط نباید بدونیم PPO بهتره یا GRPO؛ باید بفهمیم مدل کجا تمرین می‌کنه، نتیجه‌ی کارش چطور چک می‌شه و دقیقاً بابت چه رفتاری reward می‌گیره.

برای اینکه مسیرش روشن باشه، اول برگردیم به مدل کلاسیک. یه مدل با Pre-Training ساخته می‌شد، بعد با SFT یه سری مثال خوب می‌دید تا یاد بگیره چطور دستور بگیره و جواب بده، بعد RLHF می‌اومد سراغش. توی RLHF معمولاً آدم‌ها چند جواب رو با هم مقایسه می‌کردن، از این ترجیح‌ها یه Reward Model ساخته می‌شد و بعد الگوریتمی مثل PPO مدل اصلی رو طوری تغییر می‌داد که امتیاز بیشتری از اون Reward Model بگیره.

مشکل اینه که Reward Model واقعیت رو نمی‌دونه؛ داره تخمین می‌زنه. مثلاً ممکنه یه جواب خیلی قانع‌کننده ولی غلط رو بیشتر دوست داشته باشه، یا مدل یاد بگیره چه شکلی جواب بده که judge خوشش بیاد. روش‌هایی مثل DPO بعداً این Pipeline رو ساده‌تر کردن و برای خیلی از alignmentها حتی نیاز به حلقه‌ی کامل RL رو هم کم کردن، ولی یه سؤال مهم باقی موند: وقتی جواب رو واقعاً می‌شه چک کرد، چرا اصلاً باید یه مدل دیگه حدس بزنه خوبه یا نه؟

اینجا بود که RL برای reasoning دوباره خیلی مهم شد. توی ریاضی می‌شه جواب نهایی رو چک کرد، توی کدنویسی می‌شه کد رو اجرا کرد و تست گرفت، توی یه Coding Agent می‌شه دید پروژه واقعاً درست شده یا نه. یعنی به‌جای اینکه یه Reward Model بگه «این جواب به نظرم خوبه»، یه Verifier می‌گه «این جواب واقعاً درست بود یا نه».

به این ایده معمولاً RLVR می‌گن؛ Reinforcement Learning with Verifiable Rewards. اسمش پیچیده‌تر از مفهومشه: هرجا می‌تونی نتیجه رو واقعاً چک کنی، reward رو از همون نتیجه بگیر.

اوایل ۲۰۲۵، DeepSeek-R1-Zero یکی از مهم‌ترین نمونه‌های این تغییر بود. DeepSeek نشون داد یه Base Model قوی رو می‌شه تقریباً بدون SFT اولیه مستقیم وارد RL کرد. مدل برای هر سؤال چند جواب مختلف تولید می‌کرد، جواب‌ها با ruleهای مشخص چک می‌شدن و رفتارهایی که بیشتر به جواب درست می‌رسیدن تقویت می‌شدن.

اینجا الگوریتم اصلی GRPO بود. ایده‌ی GRPO خیلی ساده‌تر از اسمشه: فرض کن یه سؤال رو به مدل می‌دی و ۸ جواب مختلف می‌گیری. بعضی درستن، بعضی غلط. به‌جای اینکه یه Value Model جدا داشته باشی که دائم حدس بزنه هر مسیر چقدر خوبه، همین ۸ جواب رو نسبت به هم مقایسه می‌کنی. جواب‌هایی که از بقیه بهتر بودن بیشتر تقویت می‌شن و جواب‌های ضعیف‌تر کمتر.

این تفاوت با PPO مهمه، چون توی PPO معمولاً علاوه بر خود LLM یه Value Model هم داری که باید آموزش ببینه و توی حافظه جا بشه. وقتی خود مدل صدها میلیارد پارامتر داره، نگه داشتن یه مدل بزرگ دیگه برای تخمین ارزش مسیر ارزون نیست. GRPO این بخش رو حذف می‌کنه و از مقایسه‌ی چند rollout برای همون سؤال کمک می‌گیره.

ولی GRPO هزینه رو کاملاً حذف نکرده؛ فقط شکلش رو عوض کرده. حالا برای هر سؤال چند rollout لازم داری. برای یه سؤال ریاضی چند جواب چند هزار tokenی هنوز قابل تحمله، ولی وقتی rollout تبدیل به یه Agent چنددقیقه‌ای بشه، همین موضوع بعداً تبدیل به یکی از بزرگ‌ترین دردهای Agentic RL می‌شه.

بعد از R1-Zero یه نکته‌ی مهم دیگه هم مشخص شد: RL لزوماً reasoning رو از هیچ خلق نمی‌کنه. بررسی‌های بعدی روی R1-Zero نشون دادن بخشی از رفتارهایی که به‌عنوان «Aha Moment» دیده می‌شدن از قبل هم توی Base Model وجود داشتن. RL بیشتر احتمال ظاهر شدن و ادامه پیدا کردن اون رفتارها رو تغییر می‌ده. یعنی کیفیت Pre-Training و چیزی که مدل قبل از RL بلده هنوز خیلی مهمه.

همین بررسی‌ها یه مشکل دیگه هم پیدا کردن. بعضی تنظیمات GRPO می‌تونن ناخواسته جواب‌های طولانی‌تر رو تشویق کنن، حتی وقتی جواب طولانی‌تر لزوماً بهتر نیست. Dr. GRPO برای همین ساخته شد تا بخشی از این Length Bias رو کم کنه. اینجا یه درس مهم داریم: اینکه بعد از RL مدل ۲۰ هزار token فکر می‌کنه، به‌خودی‌خود ثابت نمی‌کنه reasoning بهتری پیدا کرده.

بعد روش‌هایی مثل DAPO هم اومدن سراغ یه مشکل عملی دیگه. فرض کن برای یه سؤال ۸ rollout تولید کردی و هر ۸ تا درست شدن. یا برعکس هر ۸ تا غلط شدن. توی هر دو حالت مقایسه‌ی داخل گروه اطلاعات خیلی زیادی برای یادگیری نمی‌ده. DAPO سعی می‌کنه بیشتر روی سؤال‌هایی تمرکز کنه که مدل روی اون‌ها هم موفقیت داره هم شکست؛ یعنی جایی که واقعاً چیزی برای یاد گرفتن وجود داره.

کمی بعد Qwen3 نشون داد که خود Pipeline آموزش هم داره تغییر می‌کنه. دیگه داستان ساده‌ی «Pre-Training → SFT → RL → تمام» نیست. Qwen3 اول Cold Start و SFT داشت، بعد وارد Reasoning RL شد، بعد خود مدل تعداد زیادی جواب جدید تولید کرد، جواب‌های خوب با rejection sampling انتخاب شدن و دوباره تبدیل به دیتای SFT شدن، بعد مراحل بعدی آموزش ادامه پیدا کرد.

نکته‌ی مهم اینه که SFT و RL دیگه دو مرحله‌ی مستقل نیستن. RL می‌تونه رفتارهای جدید پیدا کنه، بعد خروجی‌های خوب خودش تبدیل به دیتای آموزشی بشن، SFT اون رفتارها رو تمیزتر و پایدارتر داخل مدل جا بندازه و بعد دوباره RL ادامه پیدا کنه. آموزش بیشتر شبیه یه حلقه شده تا یه Pipeline خطی.

بعد تیم Qwen یه مشکل دیگه رو هم جدی گرفت: پایداری RL روی مدل‌های خیلی بزرگ، مخصوصاً MoE. توی MoE همه‌ی پارامترها برای هر token فعال نمی‌شن و فقط بخشی از Expertها کار می‌کنن. این معماری خیلی بهینه‌ست، ولی RL روش می‌تونه دردسرهای خاص خودش رو داشته باشه.

برای همین Qwen در ۲۰۲۵ GSPO رو معرفی کرد. فرق مهمش اینه که به‌جای اینکه تغییر policy رو خیلی ریز در سطح تک‌تک tokenها بسنجه، بیشتر احتمال کل sequence رو مبنا قرار می‌ده. تیم Qwen گزارش کرد GRPO در آموزش طولانی ممکنه ناپایدار بشه و حتی به collapse برسه، در حالی که GSPO برای RL در مقیاس بزرگ، مخصوصاً روی MoE، پایدارتر طراحی شده.

از نظر من اینجا یه سوءبرداشت رایج هم باید کنار بره: «مدل‌های reasoning جدید یعنی همه GRPO استفاده می‌کنن.» نه. GRPO خیلی مهم شد، ولی خودش شروع یه خانواده‌ی بزرگ‌تر از روش‌ها بود. یه تیم Length Bias رو حل می‌کنه، یه تیم instability رو، یه تیم rollout cost رو، یه تیم Async RL رو. بسته به نوع تسک و مدل، راه‌حل فرق می‌کنه.

همین موضوع توی Kimi Researcher خیلی واضح شد. Kimi برای Agentic RL بیشتر سراغ REINFORCE رفت، نه اینکه صرفاً GRPO رو روی Agentها کپی کنه. این Agent می‌تونه چند مرحله سرچ کنه، صفحه باز کنه، کد اجرا کنه و مسیرش رو بر اساس چیزی که پیدا کرده تغییر بده.

اینجا reward دیگه فقط برای «جواب آخر خوب بود یا نه» نیست. کل trajectory مهمه. حتی طول مسیر هم اهمیت داره؛ اگه دو Agent هر دو مسئله رو حل کنن ولی یکی با مسیر خیلی کوتاه‌تر به نتیجه برسه، منطقیه که رفتار دوم بیشتر تقویت بشه.

برای یه Coding Agent هم همین تغییر ذهنی اتفاق می‌افته. لازم نیست یه مدل دیگه کد رو نگاه کنه و بگه «به نظرم خوبه». کد اجرا می‌شه؛ تست‌ها پاس شدن یا نشدن. برای Search Agent هم می‌شه جواب نهایی رو چک کرد. برای tool use هم می‌شه دید ابزار درست صدا زده شده و تسک واقعاً تموم شده یا نه.

اینجا RL کم‌کم از «چطور جواب بده» تبدیل می‌شه به «چطور یه کار رو انجام بده».

همون حوالی GLM-4.5 هم این جهت رو خیلی جدی گرفت. تمرکز GLM فقط reasoning نبود؛ خودشون Pipeline رو حول Agentic، Reasoning و Coding طراحی کردن. توی چنین مدلی یه reward واحد برای همه‌چیز کافی نیست. بعضی جاها جواب با rule دقیق چک می‌شه، بعضی جاها نتیجه‌ی اجرای کد مهمه، بعضی جاها رفتار Agent توی محیط باید بررسی بشه و برای بخش‌هایی مثل instruction following هم ممکنه feedback متفاوتی لازم باشه.

تا آخر ۲۰۲۵ مشخص شده بود که مشکل اصلی Agentic RL فقط الگوریتم نیست. وقتی Agent چند دقیقه یا چندصد مرحله کار می‌کنه، تازه با یه عالمه مسئله‌ی جدید روبه‌رو می‌شی: rollout گرونه، Agentها با سرعت‌های متفاوت تموم می‌شن، reward خیلی دیر می‌رسه، Context پر می‌شه و معلوم نیست دقیقاً کدوم تصمیم باعث موفقیت یا شکست شده.

اینجا وارد موج ۲۰۲۶ می‌شیم؛ جایی که بخش زیادی از پیشرفت RL عملاً از خود الگوریتم بیرون میاد و تبدیل می‌شه به مهندسی محیط، reward، Context، scheduler و ترکیب مدل‌های متخصص.

اوایل ۲۰۲۶، MiniMax توی Forge برای M2.5 دقیقاً رفت سراغ همین مشکل. فرض کن یه Agent صد مرحله کار کرده؛ تا اون موقع کلی سرچ، خروجی ابزار، فایل، خطا و متن داخل Context جمع شده. حتی اگر هنوز سقف Context پر نشده باشه، اطلاعات مهم ممکنه وسط این شلوغی گم بشن.

برای همین Forge، Context Management رو وارد خود حلقه‌ی RL کرده. یعنی Agent فقط یاد نمی‌گیره قدم بعدی چی باشه؛ حین آموزش هم یاد می‌گیره چه چیزی رو نگه داره، چه چیزی رو خلاصه کنه و چه چیزی رو کنار بذاره. این خیلی مهمه، چون اگه مدل در آموزش همیشه Context تمیز و کامل ببینه ولی موقع استفاده‌ی واقعی مجبور باشه Context رو خلاصه و حذف کنه، چیزی که زمان آموزش دیده با چیزی که زمان اجرا می‌بینه فرق می‌کنه.

یه بخش جالب دیگه‌ی Forge اینه که فقط درست بودن نتیجه reward نمی‌گیره. Task Completion Time هم وارد reward شده. فرض کن دو Agent هر دو یه تسک رو درست انجام بدن، ولی یکی ابزارها رو بهتر استفاده کنه و نصف زمان طول بکشه؛ رفتار دومی ارزش بیشتری داره.

برای محصول واقعی این موضوع خیلی مهمه. کاربر نمی‌گه «این Agent از نظر تئوری trajectory زیبایی داشت.» می‌گه چرا کاری که می‌شد دو دقیقه‌ای انجام بشه ده دقیقه طول کشید. پس latency و نحوه‌ی استفاده از ابزار هم کم‌کم بخشی از چیزی می‌شن که RL باید یاد بگیره.

خود Forge با CISPO و Reward-to-go هم سعی کرده مشکل trajectoryهای خیلی بلند رو بهتر مدیریت کنه. چون وقتی فقط آخر یه مسیر ۱۰۰ یا ۲۰۰ مرحله‌ای یه reward می‌دی، فهمیدن اینکه کدوم تصمیم وسط مسیر مفید بوده خیلی سخت می‌شه.

این همون مسئله‌ی Credit Assignmentـه. فرض کن Agent صد مرحله کار کرده و آخرش شکست خورده. دقیقاً کدوم مرحله خراب بوده؟ شاید سرچ مرحله‌ی ۵ اشتباه بوده و بقیه‌ی ۹۵ مرحله فقط دارن اثر همون اشتباه رو ادامه می‌دن. شاید همه‌چیز درست بوده و فقط آخر کار فرمت جواب خراب شده. یه reward نهایی صفر هیچ‌کدوم از این‌ها رو مستقیم نمی‌گه.

از طرف دیگه MiniMax یه درد زیرساختی رو هم حل کرده. توی Agentic RL زمان rolloutها خیلی با هم فرق می‌کنه. ممکنه ۹۹ Agent کارشون تموم شده باشه و یکی هنوز درگیر یه ابزار کند باشه. اگه کل آموزش منتظر همون یکی بمونه، GPUها بیکار می‌مونن.

برای همین Forge سراغ scheduling غیرهمزمان رفته تا تولید rollout و آموزش کمتر منتظر هم بمونن. همین چیزها نشون می‌ده RL برای Agent دیگه فقط یه فرمول loss نیست؛ scheduler هم می‌تونه روی هزینه و حتی کیفیت داده‌ی آموزشی اثر بذاره.

کمی بعد Agent-R1 این ایده رو از یه زاویه‌ی تمیزتر صورت‌بندی کرد. به‌جای اینکه کل کار Agent رو یه متن غول‌پیکر ببینه، هر تعامل با محیط رو یه مرحله‌ی واقعی در نظر می‌گیره: مدل یه عمل انجام می‌ده، محیط جواب می‌ده، reward ثبت می‌شه و مدل با مشاهده‌ی جدید می‌ره مرحله‌ی بعد.

این همون نگاه MDP کلاسیکه، ولی برای Agentهای LLM دوباره خیلی مهم شده. چون وقتی هر تعامل یه مرحله‌ی مستقل باشه، Context Management، استفاده از ابزار، reward هر مرحله و پایان تسک خیلی طبیعی‌تر مدل می‌شن.

جالب‌تر اینکه Agent-R1 از قبل Process Reward رو هم برای tool callها پشتیبانی می‌کرد. یعنی لازم نیست همیشه تا آخر trajectory صبر کنیم. اگه یه استفاده از ابزار مشخصاً مفید بوده، می‌تونه همونجا reward بگیره. این دقیقاً همون چیزی‌یه که برای Agentهای طولانی لازم داریم.

بعد در آوریل ۲۰۲۶، DeepSeek-V4 یه تغییر مهم دیگه رو توی شکل post-training نشون داد. ایده این بود که به‌جای اینکه همه‌ی مهارت‌ها رو توی یه mixed RL بزرگ با هم قاطی کنن، اول مدل‌های متخصص برای domainهای مختلف ساخته بشن.

هر متخصص اول Fine-Tuning مخصوص خودش رو می‌بینه، بعد با GRPO و reward مخصوص همون domain وارد RL می‌شه. یعنی متخصص ریاضی روی مسئله و reward مربوط به ریاضی تمرین می‌کنه، متخصص کدنویسی روی محیط خودش و متخصص Agent روی نوع دیگه‌ای از trajectory.

بعد قسمت مهم شروع می‌شه: DeepSeek برای جمع کردن این تخصص‌ها دیگه یه mixed RL نهایی انجام نداده. بیشتر از ده teacher متخصص رو با Multi-Teacher On-Policy Distillation داخل یه مدل واحد جمع کرده.

ایده‌ی On-Policy Distillation خیلی مهمه. توی Distillation معمولی ممکنه teacher از قبل یه عالمه جواب تولید کرده باشه و student فقط اون دیتای ثابت رو تقلید کنه. ولی توی On-Policy Distillation خود student جواب تولید می‌کنه و teacher روی همون مسیرهایی که student واقعاً واردشون شده راهنمایی می‌ده.

یه تشبیه ساده اینه که RL مثل امتحانیه که آخرش فقط می‌فهمی نمره‌ت ۷ شده. Distillation بیشتر شبیه استادیه که روی همون برگه‌ی خودت می‌گه اینجا انتخابت خوب بود، اینجا گزینه‌ی بهتر داشتی و از این نقطه مسیر درست‌تر چی بوده.

برای DeepSeek-V4 قضیه حتی از انتخاب یه token هم دقیق‌تره. Full-vocabulary Distillation یعنی teacher فقط نمی‌گه «token درست این بود»؛ توزیع احتمال خودش روی گزینه‌های مختلف رو به student می‌ده. در نتیجه به‌جای یه reward کم‌تراکم در پایان، یه بازخورد خیلی متراکم‌تر در طول جواب داری.

اینجا یه الگوی خیلی مهم برای ۲۰۲۶ شکل می‌گیره: RL برای ساختن متخصص‌هایی که capability جدید کشف می‌کنن، بعد Distillation برای جمع کردن این capabilityها داخل یه مدل عمومی.

تقریباً همزمان DR-Venus یه مشکل دیگه‌ی Agentها رو خیلی واضح هدف گرفت: Long-Horizon Research. اینجا Agent ممکنه بیشتر از ۲۰۰ مرحله سرچ و بازدید از صفحه داشته باشه. اگه فقط در آخر کار reward بدی، تقریباً کل مسیر بدون بازخورد مستقیم می‌مونه.

برای همین DR-Venus از IGPO استفاده کرده که reward رو به Information Gain نزدیک می‌کنه. ایده‌ی ساده‌ش اینه: بعد از این سرچ یا مشاهده، احتمال رسیدن مدل به جواب درست بیشتر شد یا نه؟ اگر این مرحله اطلاعات واقعاً مفیدی وارد مسیر کرده، باید همون مرحله یه سیگنال مثبت داشته باشه.

این خیلی فرق داره با اینکه به Agent بگیم «آخرش جواب درست شد، پس همه‌ی ۲۰۰ حرکتت خوب بودن». ممکنه ده‌ها سرچ بی‌ربط وسطش انجام شده باشه. Turn-Level Reward کمک می‌کنه مدل بفهمه کدوم حرکت‌ها واقعاً مسیر رو جلو بردن.

نکته‌ی جالب DR-Venus اینه که این ایده رو روی یه مدل 4B و با حدود 10K داده‌ی باز اجرا کرده. یعنی بحث فقط frontier modelهای چندصد میلیارد پارامتری نیست؛ کیفیت طراحی reward و استفاده‌ی بهتر از trajectory حتی روی مدل کوچیک هم می‌تونه خیلی تعیین‌کننده باشه.

بعد در مه ۲۰۲۶، BASIS مستقیم رفت سراغ هزینه‌ی GRPO. مشکل رو یادتونه: GRPO برای هر prompt چند rollout می‌خواد تا جواب‌ها رو با هم مقایسه کنه. BASIS می‌گه چرا برای هر prompt فقط یه rollout نگیریم و برای تخمین بهتر، اطلاعات بقیه‌ی نمونه‌های همون batch رو با هم share نکنیم؟

این یعنی یه مسیر Single-Rollout بدون Value Model بزرگ. هدفش اینه که هزینه‌ی ساخت چند پاسخ برای هر سؤال کم بشه، ولی هنوز از اطلاعات کل batch برای تخمین بهتر استفاده کنیم. برای reasoning این می‌تونه خیلی مهم باشه، چون هر rollout اضافه یعنی token و زمان بیشتر.

بعد در ژوئن ۲۰۲۶، Nemotron 3 Ultra یه نمونه‌ی خیلی واضح دیگه از ترکیب RL و Distillation شد. Pipeline اون با SFT شروع می‌شه، بعد RLVR داره و بعد Multi-Teacher On-Policy Distillation یا MOPD.

جالب اینه که NVIDIA هم به یه الگوی مشابه DeepSeek رسیده: یه student عمومی داری، چند teacher متخصص در حوزه‌های مختلف داری، بعد به‌جای اینکه انتظار داشته باشی یه RL واحد همه‌ی تخصص‌ها رو بی‌نقص داخل یه مدل جمع کنه، از Distillation برای انتقال رفتار این متخصص‌ها استفاده می‌کنی.

توی Nemotron 3 Ultra خود RLVR هم در مقیاس بزرگی اجرا شده؛ مثلاً برای هر prompt تعداد زیادی generation ساخته می‌شه. این دوباره یادآوری می‌کنه که RLVR هرچقدر از نظر reward تمیز باشه، rollout هنوز یه هزینه‌ی خیلی بزرگه.

بعد در جولای، SAO یه جواب متفاوت به همین مشکل داد. اسم کاملش Single-Rollout Asynchronous Optimizationـه و برای Agentic RL ساخته شده. منطقش اینه که Group Sampling مدل‌هایی مثل GRPO خیلی با Agentهای طولانی و Async جور درنمیاد.

برای همین SAO برای هر prompt فقط یه rollout می‌گیره، ولی این بار برخلاف BASIS یه Value Model رو برمی‌گردونه تا کمک کنه کیفیت مسیر تخمین زده بشه. یه جور trade-off داریم: چند rollout و بدون critic، یا یه rollout و یه critic.

این دقیقاً نشون می‌ده چرا حذف Value Model از GRPO یه قانون همیشگی نیست. برای reasoning کوتاه ممکنه چند rollout خیلی منطقی باشه. ولی برای Agentی که هر rollout چند دقیقه طول می‌کشه، شاید برگردوندن یه Value Model کوچیک‌تر خیلی ارزون‌تر از اجرای چندباره‌ی کل Agent باشه.

SAO علاوه بر این Async طراحی شده؛ یعنی rolloutها هر وقت آماده شدن می‌تونن وارد آموزش بشن و لازم نیست کل batch منتظر کندترین Agent بمونه. البته این یه مشکل جدید می‌سازه: بعضی rolloutها با نسخه‌ی کمی قدیمی‌تر مدل ساخته شدن، پس داده کاملاً on-policy نیست و باید جلوی زیاد شدن اختلاف بین مدل تولیدکننده‌ی rollout و مدل فعلی گرفته بشه.

این روش فقط یه paper آزمایشگاهی هم نموند و طبق گزارش خود تیم، توی Agentic RL مدل GLM-5.2 استفاده شده. اینجا دوباره همون الگو دیده می‌شه: وقتی Agentها طولانی می‌شن، طراحی سیستم آموزش خودش بخشی از الگوریتم می‌شه.

همین مشکل رو Kimi Researcher از یه مسیر دیگه با Partial Rollout حل کرده بود. اگه یه trajectory از زمان مشخصی بیشتر طول بکشه، لازم نیست بندازیش دور یا بقیه رو منتظر نگه داری. می‌تونی وضعیتش رو ذخیره کنی و در دور بعدی ادامه بدی.

البته اینجا هم یه نکته‌ی عجیب داریم: ممکنه نیمه‌ی اول مسیر با نسخه‌ی قدیمی مدل ساخته شده باشه و نیمه‌ی دوم با نسخه‌ی جدید. این یعنی یه optimization زیرساختی ساده بلافاصله تبدیل می‌شه به یه مسئله‌ی RL درباره‌ی on-policy بودن داده.

بعد در همون تابستون ۲۰۲۶، ایده‌ی Self-Evolving RL جدی‌تر شد. SEED یه نکته‌ی خیلی جالب داره: چرا trajectory شکست‌خورده رو فقط با reward صفر دور بندازیم؟

ایده اینه که مدل بعد از پایان مسیر به عقب نگاه کنه و از تجربه یه skill قابل استفاده استخراج کنه. مثلاً بفهمه «وقتی دو منبع با هم تناقض دارن، اول اعتبار منبع رو چک کن» یا «قبل از تغییر فایل، اول تست مرتبط رو اجرا کن».

بعد این skill دوباره وارد آموزش می‌شه و مدل روی همون trajectory می‌بینه که داشتن این دانش چطور احتمال تصمیم‌های بهتر رو تغییر می‌داد. یعنی شکست از یه نمونه‌ی مصرف‌شده تبدیل می‌شه به یه قطعه دانش قابل استفاده برای تلاش بعدی.

SESA یه مرحله جلوتر می‌ره و خود curriculum رو هم وارد این حلقه می‌کنه. یه Challenger مسئله‌های جدید می‌سازه، یه Solver تلاش می‌کنه حلشون کنه و شکست‌های مفید تبدیل به skill می‌شن. وقتی Solver بهتر می‌شه، Challenger هم باید مسئله‌های سخت‌تر بسازه.

اینجا دیگه فقط مدل در حال تغییر نیست. سه چیز با هم رشد می‌کنن: policy، حافظه‌ی skillها و توزیع مسئله‌هایی که مدل روی اون‌ها تمرین می‌کنه. این شاید یکی از مهم‌ترین جهت‌های بعدی RL باشه، چون دیتاست دیگه یه فایل ثابت نیست؛ خودش بخشی از سیستم یادگیری می‌شه.

و بعد می‌رسیم به سپتامبر ۲۰۲۶ و K2 Horizon، که به نظرم یکی از جالب‌ترین نمونه‌هاست چون تقریباً خیلی از ایده‌های قبلی رو کنار هم می‌ذاره.

مدل اصلی K2-Horizon-375B-A23B یه MoE با ۳۷۵ میلیارد پارامتره، ولی برای هر token حدود ۲۳ میلیارد پارامتر فعال می‌شن. Context هم تا 512K می‌ره. ولی برای بحث RL، اندازه‌ی مدل بخش جذاب ماجرا نیست؛ شکل Training Pipeline مهم‌تره.

تیم IFM داده‌های reasoning و کارهای ایجنتی رو برای آخر آموزش نگه نداشته. از mid-training ترکیب داده کم‌کم به سمت long-context، reasoning و trajectoryهای ایجنتی رفته. Context هم مرحله‌به‌مرحله بزرگ شده: از 8K به 32K، بعد 128K و در نهایت 512K.

یعنی وقتی مدل وارد RL می‌شه، تازه برای اولین بار ابزار، Context بلند یا reasoning رو نمی‌بینه. پایه‌ی این رفتارها قبل‌تر ساخته شده و RL قرار نیست همه‌چیز رو از صفر اختراع کنه.

یه بخش خیلی مهم‌تر، کارخانه‌ی ساخت داده‌ست. IFM می‌گه برای post-training بیشتر از ۱۰۰ میلیون تسک متفاوت ساخته. مسئله‌ها از taxonomy، تغییر شرایط و web-search seeding ساخته شدن و بعد مدل‌های solver برای اون‌ها trajectory تولید کردن.

اینجا یه تغییر مهم توی معنی «Scale کردن RL» می‌بینیم. Scale فقط این نیست که GPU بیشتری بذاری و تعداد stepها رو زیاد کنی. باید مرتب تسک جدید بسازی، محیط متنوع بسازی، جواب قابل‌چک تولید کنی و مدل رو جلوی مسئله‌هایی بذاری که هنوز براش ارزش یادگیری دارن.

بعد خود مدل 375B از یه checkpoint مشترک به پنج شاخه‌ی RL تقسیم شده: یه متخصص knowledge work، یکی instruction following، یکی سرچ، یکی tool use و یکی reasoning. هرکدوم جدا RL دیدن و بعد specialistها دوباره با هم merge شدن.

این فرق مهمیه. به‌جای اینکه یه مدل رو وسط یه ظرف بزرگ از rewardهای مختلف بندازی و بگی همزمان سرچ، ابزار، reasoning، knowledge work و دستورپذیری رو بهتر کن، هر مهارت اول فضای تمرین خودش رو می‌گیره.

ولی بعد از merge آموزش تموم نشده. مدل 375B سه مرحله‌ی SFT دیگه دیده: حدود ۸۰ میلیارد token، بعد ۲۰۰ میلیارد و بعد ۵۰ میلیارد؛ یعنی در مجموع حدود ۳۳۰ میلیارد token SFT بعد از RL و merge.

این واقعاً تصویر قدیمی «SFT قبل از RL» رو خراب می‌کنه. توی K2 Horizon مسیر تقریباً این شکلیه: Pre-Training → mid-training → چند متخصص RL → merge → دوباره SFT سنگین.

یه دلیل احتمالی هم قابل فهمه: RL متخصص‌ها رفتارهای قوی ولی متفاوت می‌سازه، merge اون‌ها رو داخل یه مدل جمع می‌کنه و SFT بعدی کمک می‌کنه رفتار نهایی دوباره مرتب و قابل استفاده بشه.

مدل کوچیک 0.9B خانواده‌ی K2 حتی واضح‌تر نشون می‌ده merge چه مشکلی داره. اونجا هفت متخصص RL برای math، code، instruction following و STEM ساخته شدن و بعد merge شدن.

ولی خود IFM نوشته merge باعث structural interference و افت بعضی قابلیت‌ها شده. یعنی دو متخصص ممکنه جداگانه خیلی خوب باشن، ولی وقتی وزن‌هاشون رو ترکیب می‌کنی، تضمینی نیست مجموعشون هم خوب باشه.

برای همین بعدش MOPD اجرا شده؛ Multi-Teacher On-Policy Distillation. متخصص‌های مختلف دوباره نقش teacher رو گرفتن و مدل mergeشده روی rolloutهای خودش از اون‌ها یاد گرفته تا بخشی از قابلیت‌هایی که در merge خراب شده بودن دوباره برگردن.

این دقیقاً همون الگویی‌یه که توی DeepSeek-V4 و Nemotron هم می‌بینیم: RL برای متخصص‌سازی، بعد Distillation برای جمع کردن تخصص‌ها.

ولی K2 Horizon یه نکته‌ی حتی آموزنده‌تر درباره‌ی Verifier داره. روی Terminal-Bench 2.1، مدل 375B روی ۸۹ تسک و هشت تلاش برای هرکدوم اجرا شده؛ در مجموع ۷۱۲ اجرا. ۵۰۰ اجرا Verifier رو پاس کردن و امتیاز اولیه 70.2 درصد شده.

بعد IFM همه‌ی اجراهای موفق رو دوباره برای reward hacking بررسی کرده. ۲۴ اجرا روی ۱۰ تسک مشکل‌دار تشخیص داده شدن و با حذف اون‌ها امتیاز از 70.2 به 66.9 درصد رسیده.

یعنی بعضی وقت‌ها Agent مسئله رو اون شکلی که ما فکر می‌کنیم حل نکرده؛ راهی پیدا کرده که grader فکر کنه مسئله حل شده. مثلاً جواب مخفی رو پیدا کرده، چیزی که محیط ناخواسته لو داده استفاده کرده یا خود فرایند ارزیابی رو دور زده.

این مثال خیلی خوب نشون می‌ده RLVR جادو نیست. Verifiable بودن reward فقط یعنی یه سیستم داری که جواب رو چک می‌کنه؛ معنی‌ش این نیست که اون سیستم دقیقاً نیت واقعی تو رو اندازه می‌گیره.

مدل چیزی رو یاد می‌گیره که reward می‌دی، نه چیزی که منظورت بوده.

در واقع هرچی Agent قوی‌تر می‌شه، طراحی Verifier هم سخت‌تر می‌شه. چون Agent فقط بهتر مسئله حل نمی‌کنه؛ بهتر هم می‌تونه shortcut پیدا کنه.

فعلاً یه محدودیت مهم درباره‌ی K2 Horizon هم وجود داره. تا الان ساختار کلی مراحل RL، checkpoint متخصص‌ها، merge و SFT بعدش منتشر شده، ولی جزئیات دقیق RL مدل 375B مثل الگوریتم، reward design، تعداد rolloutها و بودجه‌ی محاسباتی هنوز کامل منتشر نشده.

پس فعلاً نمی‌شه با اطمینان گفت پنج متخصص K2 Horizon با GRPO آموزش دیدن، PPO، GSPO یا روش دیگه. Technical Report کامل برای آخر سپتامبر ۲۰۲۶ اعلام شده و بخش‌هایی از RL در model card هنوز مقدار مشخصی ندارن.

این محدودیت مهمه چون نباید فقط از روی شباهت Pipeline حدس بزنیم «پس حتماً GRPO بوده». یکی از چیزهایی که ۲۰۲۵ و ۲۰۲۶ نشون دادن دقیقاً اینه که مدل‌های مختلف بسته به نوع trajectory و زیرساخت، optimizer متفاوت انتخاب می‌کنن.

وقتی همه‌ی این مسیر رو کنار هم می‌ذاریم، تحول RL خیلی واضح‌تر دیده می‌شه.

اول RLHF داشتیم که بیشتر می‌پرسید «انسان کدوم جواب رو ترجیح می‌ده؟»

بعد RLVR جدی شد و سؤال تبدیل شد به «آیا جواب واقعاً درسته؟»

بعد GRPO و روش‌های مشابه اومدن که گفتن «چطور بدون Value Model بزرگ از چند تلاش مدل یاد بگیریم؟»

بعد GSPO و بقیه رفتن سراغ «چطور این آموزش رو در scale بالا پایدار کنیم؟»

بعد Agentic RL سؤال رو عوض کرد به «آیا مدل واقعاً تونست یه کار چندمرحله‌ای رو انجام بده؟»

بعد مسئله‌ی Credit Assignment جدی شد: «کدوم حرکت وسط مسیر واقعاً مفید بود؟»

بعد Async RL و Single-Rollout اومدن سراغ «چطور rolloutهای چنددقیقه‌ای رو بدون هدر دادن GPU مدیریت کنیم؟»

بعد specialist training و On-Policy Distillation رسیدن به این سؤال که «چطور چند مهارت جدا رو بدون خراب کردن هم داخل یه مدل جمع کنیم؟»

و الان Self-Evolving RL داره می‌پرسه «چطور خود مسئله‌ها، skillها و curriculum هم همراه مدل رشد کنن؟»

برای یه AI Engineer، به نظرم این timeline یه نتیجه‌ی خیلی مهم داره: RL جدید دیگه یه «الگوریتم» نیست؛ یه سیستم کامله.

باید محیط درست داشته باشی.

باید تسک‌هایی داشته باشی که واقعاً چیز جدیدی به مدل یاد بدن.

باید Verifier درست داشته باشی.

باید جلوی reward hacking رو بگیری.

باید rolloutهای طولانی رو مدیریت کنی.

باید بفهمی کدوم مرحله‌ی trajectory مفید بوده.

باید Context رو وسط کار مدیریت کنی.

باید تصمیم بگیری کجا چند rollout ارزش هزینه‌ش رو دارن و کجا Single-Rollout بهتره.

باید تخصص‌های مختلف رو جدا تمرین بدی یا روشی پیدا کنی که توی آموزش مشترک همدیگه رو خراب نکنن.

و در آخر باید بدونی کجا RL واقعاً لازمه و کجا Distillation خیلی ارزون‌تر و تمیزتر همون قابلیت رو منتقل می‌کنه.

برای من مهم‌ترین تغییر ذهنی همین آخریه: سؤال اصلی دیگه فقط «چه الگوریتم RLـی استفاده کنیم؟» نیست.

سؤال اصلی اینه که «مدل قراره تو چه محیطی تمرین کنه، چه تجربه‌ای داشته باشه، چه بازخوردی بگیره و دقیقاً چه رفتاری رو داریم reward می‌کنیم؟»

چون آخرش مدل چیزی رو یاد نمی‌گیره که ما توی ذهنمون می‌خواستیم.

مدل چیزی رو یاد می‌گیره که سیستم واقعاً بابتش reward داده.

منابع:

https://arxiv.org/abs/2501.12948

https://arxiv.org/abs/2503.20783

https://arxiv.org/abs/2503.14476

https://arxiv.org/abs/2505.09388

https://qwenlm.github.io/blog/gspo/

https://arxiv.org/abs/2508.06471

https://moonshotai.github.io/Kimi-Researcher/

https://www.minimax.io/blog/forge-scalable-agent-rl-en-1779896141

https://github.com/AgentR1/Agent-R1

https://www.deepseek.com/en/transparency/

https://deepseek.com/en/news/v4-preview/

https://arxiv.org/abs/2604.19859

https://github.com/inclusionAI/DR-Venus

https://arxiv.org/abs/2605.27293

https://research.nvidia.com/labs/nemotron/Nemotron-3-Ultra/

https://docs.nvidia.com/nemotron/nightly/nemotron/ultra3/mopd.html

https://arxiv.org/abs/2607.07508

https://arxiv.org/abs/2607.14777

https://arxiv.org/abs/2607.29468

https://ifm.ai/blog/k2/

https://huggingface.co/IFM/K2-Horizon-375B-A23B

https://huggingface.co/IFM/K2-Horizon-0.9B

🛠 Join @LLMEngineers Community