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

توی این پست می‌خوام خیلی تکنیکال و بدون حاشیه، متدهای اصلی Fine-Tuning مبتنی بر RL رو کالبدشکافی کنم تا بدونی برای پروژه بعدیت کدوم رو انتخاب کنی.

دسته‌بندی کلی متدها
کلا داستان به دو بخش تقسیم میشه:
۱. متدهای On-Policy (مثل PPO و GRPO): که مدل همزمان با آموزش، دیتا تولید می‌کنه.
۲. متدهای Offline (مثل DPO، KTO و ORPO): که روی دیتای از قبل آماده شده (Preference Data) کار می‌کنن.

۱. معماری PPO (Proximal Policy Optimization)
پدرخوانده‌ی RLHF که ChatGPT باهاش بزرگ شد. مکانیزمش Actor-Critic هست. یعنی شما یه مدل داری که متن تولید می‌کنه (Actor) و یه مدل جدا داری که نمره میده (Critic/Reward Model).
مزیتش اینه که به شدت Stable هست و برای تولید متن‌های طولانی و مکالمه‌های پیچیده هنوز بهترین خروجی رو میده. اما ایراد بزرگش اینه که به شدت Compute-Heavy هست. شما باید همزمان چنتا مدل رو توی VRAM نگه داری که عملاً هزینه‌ها رو ۲ برابر می‌کنه.

۲. معماری DPO (Direct Preference Optimization)
الان محبوب‌ترین روش توی کامیونیتی Open Source هست (مدل‌های Zephyr و Llama 3 Instruct).
ایده اینه: Reward Model رو حذف کن! خود Policy مدل رو جوری آپدیت کن که احتمال تولید جواب‌های "Chosen" بیشتر از "Rejected" بشه.
خیلی سبک‌تر و پایدارتر از PPO هست اما یه باگ بزرگ داره: روی دیتاهای نویزی زود Overfit میشه و برای تسک‌های استدلالی سنگین (مثل ریاضی) به خوبی PPO عمل نمی‌کنه چون اکتشاف (Exploration) نداره.

۳. معماری GRPO (Group Relative Policy Optimization)
ستاره‌ی جدید بازی که DeepSeek باهاش سر و صدا کرد. این روش برای تسک‌های استدلالی (Reasoning) مثل ریاضی و کدنویسی شاهکاره.
تفاوتش با PPO اینه که Critic Model رو حذف کرده. به جاش میاد برای هر پرامپت، یه گروه (مثلا ۸ تا) خروجی می‌گیره و اینا رو نسبت به میانگین همون گروه می‌سنجه. این باعث میشه واریانس آموزش کم بشه و بدون نیاز به مدل Reward جداگانه، مدل بتونه مسیرهای استدلالی درست رو پیدا کنه.

۴. معماری ORPO (Odds Ratio Preference Optimization)
این روش میاد مرحله SFT و Alignment رو ترکیب می‌کنه. یعنی دیگه لازم نیست اول مدل رو SFT کنی بعد بری سراغ DPO.
توی تابع Loss، یه جریمه (Penalty) اضافه می‌کنه برای جواب‌های Rejected. برای مدل‌های کوچیک و متوسط (مثل Mistral 7B) عالیه و سرعت Train رو به شدت بالا می‌بره، اما هنوز روی اسکیل‌های خیلی بزرگ تست نشده.

۵. معماری KTO (Kahneman-Tversky Optimization)
این متد بر اساس تئوری اقتصاد رفتاری (Prospect Theory) ساخته شده. نکته کلیدیش اینه: نیاز به دیتای Pair شده (این بهتر از اونه) نداره.
فقط کافیه به مدل بگی این خروجی "خوبه" یا "بده" (باینری). این برای محیط‌های پروداکشن واقعی که دیتای مقایسه‌ای گرونه ولی دیتای لایک/دیسلایک زیاده، نجات‌بخش‌ترین روشه.

۶. معماری RLOO (REINFORCE Leave-One-Out)
یه جورایی برگشت به ریشه‌های REINFORCE هست ولی با یه تریک آماری برای کاهش واریانس.
برای تسک‌هایی که جواب قطعی دارن (مثل تولید کد که یا ران میشه یا نمیشه)، خیلی خوب عمل می‌کنه و توی بنچمارک‌ها تونسته PPO رو توی تسک‌های کدنویسی شکست بده.

به نظر من:
اگه منابع محدود داری و دنبال یه مدل جنرال چت‌بات هستی، شک نکن و برو سراغ DPO یا ORPO. پیچیدگی پیاده‌سازی PPO ارزشش رو نداره مگر اینکه داری روی یه مدل در حد GPT-4 کار می‌کنی.
اما اگه داری روی یه مدل تخصصی برای ریاضی، لاجیک یا کدنویسی کار می‌کنی، حتماً GRPO یا RLOO رو تست کن. ترند سال ۲۰۲۵ رفتن به سمت این متدها برای افزایش توانایی Reasoning مدل‌هاست.
و در نهایت، اگه دیتای Pair شده نداری و فقط لاگ‌های سیستم رو داری (Like/Dislike)، تنها گزینه‌ی معقولت KTO هست.

🛠 Join @LLMEngineers Community