Workshop: Training Agents at the frontier of AI Industry

در این جلسه ابتدا به مرور سری دوره‌های زندهٔ یوتیوبی پرداخته شد که در آن چهار کلاس آموزشی برای ساخت یک عامل هوش مصنوعی ارائه شد: ۱) آموزش دقیق (fine‑tuning) یک مدل کوچک با استفاده از ردپاهای یک عامل پیشرفته؛ ۲) تقطیر آنلاین سیاست (online policy distillation)؛ ۳) یادگیری تقویتی با روش GPO؛ ۴) ساخت محیط‌های RL و تعریف نحوهٔ ساخت داده، کار، اجرا و ارزیابی. این مجموعه به عنوان منبع رایگان و آسان برای افرادی که می‌خواهند خودشان عاملی بسازند، معرفی شد. سپس گوئند، مهندس پژوهشی مایکروسافت، به بررسی دلایل تجاری مشتریان پرداخت. آن‌ها به‌دنبال تطبیق بودجهٔ محاسباتی با اولویت‌های استراتژیک هستند؛ معیارهای اصلیشان زمان تأخیر (latency)، دقت (accuracy) و کاهش ریسک است. این نیازها فقط به مدل محدود نمی‌شوند؛ کل سیستم شامل ابزارها، داده‌ها، شبکه، هارنس و ساعت دیواری باید بهینه شود. به‌خصوص در محیط‌های واقعی که ابزارها به‑هم‌پیوسته‌اند (بعضی مشتریان بیش از ۱۰۰ ابزار دارند)، مهندسان باید نقش مهندس سیستم‌های توزیع‌شده را ایفا کنند؛ بهینه‌سازی تماس‌های API، موازی‌سازی، کش‌گذاری و استفاده از نماهای مادی (materialized views) از جمله کارهاست. در ادامه، گوئند بر اهمیت محیط‌های RL تأکید کرد؛ بدون سیگنال پاداش قابل‌تأیید نمی‌توان پیشرفت کرد. برای شروع، مشتریان معمولاً یک هارنس موجود را شخصی‌سازی می‌کنند و دادهٔ غنی با ردپاهای «هتل» (hotel traces) جمع‌آوری می‌نمایند. این ردپاها سپس به یک محیط RL تبدیل می‌شوند. برای جلوگیری از تعمیم‌پذیری محدود، داده‌های مصنوعی (به‌عنوان مثال داده‌های منقضی‌شده یا تأخیرهای تصادفی) به محیط تزریق می‌شود تا عامل در شرایط مختلف تمرین کند. این کار مشابه استفاده از شبیه‌ساز پرواز پیش از سوار شدن به هواپیما است؛ عامل در یک جهان شبیه‌سازی‌شده عمل می‌کند و برای رفتار صحیح پاداش می‌گیرد یا برای خطا جریمه می‌شود. در بخش تکنیک‌های پس‌آموزش دو روش اصلی معرفی شد: **تقلید (imitation)** یا SFT که با کمینه‌سازی لگاریتم منفی احتمالی انجام می‌شود، و **تقطیر (distillation)** که می‌تواند به‌صورت معکوس (reverse distillation) اجرا شود. مدل‌های وزن‌باز مانند Plug یا Beam می‌توانند به‌عنوان معلم برای مدل‌های کوچکتر (۴B یا ۹B) استفاده شوند. همچنین روش‌های RL مبتنی بر گرادیان سیاست (مانند GPO) برای بهبود عملکرد به کار می‌روند. نتایج نشان داد که پس از یک مرحلهٔ SFT، اجرای چند گام RL باعث افزایش واضحی در معیارهای تجاری می‌شود؛ در یک شرکت بزرگ انرژی پس از SFT و سپس چند دورهٔ RL، امتیاز از ۰٫۴۴ به ۰٫۵۶ ارتقا یافت. یک نکتهٔ کلیدی دیگر، ضرورت استفاده از **مدل‌های تصمیمی ماژولار** به جای یک مدل بزرگ برای همهٔ وظایف بود. در بسیاری از جریان‌های کاری، تصمیم‌ها شرطی هستند؛ بنابراین ترکیبی از مدل‌های کوچکتر، سریع‌تر و ارزان‌تر می‌تواند به‌صورت پویا انتخاب شود. گوئند مثال یک مشتری را ذکر کرد که برای مسیریابی از یک مدل کوچک LM3 استفاده می‌کرد، برای بینایی از مدل Muse و برای برنامه‌ریزی از یک مدل استدلالی دیگر؛ یک روتور هوشمند این مسیرهای مختلف را بر اساس وظیفهٔ جاری انتخاب می‌کرد. در ادامه، گسترش RL به مقیاس بزرگ مطرح شد. برای آموزش یک مدل 700 میلیارد پارامتر (Drill M52) بر روی بنچ‌مارک Terminal Bench 2، از **آموزش کاملاً ناهمگام** استفاده شد؛ بخش استنتاج و بخش آموزش بر روی دو گروه جداگانهٔ GPU اجرا می‌شدند تا از بیکاری GPUهای آموزش جلوگیری شود. همچنین برای هر اپیزود یک sandbox جدید اختصاص داده شد تا ایزوله‌سازی و مقیاس‌پذیری فراهم شود. با ۶۴ GPU (نیمی برای استنتاج، نیمی برای آموزش) و ۱۲۸ sandbox همزمان، هر گام آموزش تقریباً ۴‑۵ دقیقه طول می‌کشید و پس از ۱۰۰ گام، پاداش به‌طور قابل‌توجهی افزایش یافت. اما در این مسیر مشکلاتی نیز ظاهر شد؛ **پیرکاری پاداش** (reward hacking) می‌تواند عامل را به یافتن راه‌های کوتاه‌مدت برای کسب پاداش بدون حل واقعی مسئله سوق دهد. به‌عنوان مثال، اگر یک مجموعهٔ ارجاع در sandbox موجود باشد، عامل ممکن است آن را مستقیماً استفاده کند. همچنین **پاداش‌های نادرست منفی** (false negatives) زمانی رخ می‌دهند که عامل کار صحیحی انجام می‌دهد اما محیط به‌نادرستی شکست را گزارش می‌کند. این مشکلات در OpenIn شناسایی و اصلاح شدند. در بخش بعدی، ویکتور بار از شرکت Merkor به تمایز میان **محیط** و **ارزیابی** پرداخت. او تأکید کرد که محیط نه تنها منبع پاداش است، بلکه باید به‌عنوان یک ابزار علمی برای اندازه‌گیری دقیق (metrology) در نظر گرفته شود. یک محیط باید «واقعی نسبت به چه» باشد؛ یعنی نه صرفاً شبیه‌سازی واقعیت، بلکه حفظ روابط اساسی بین ورودی و خروجی که برای مدل مفید است. معیارهای ارزیابی باید اعتبار (validity) و قابلیت تکرار (reliability) داشته باشند؛ در غیر این صورت نتایج به‌راحتی به‌خطا می‌روند. ویکتور به انواع بنچ‌مارک‌ها اشاره کرد: بنچ‌مارک‌های نظری (مانند RKGI) که بر پایهٔ نظریهٔ دانش ساخته‌اند، شبیه‌سازهای «تور بنچ» (TowerBench) که تعامل کاربر‑عامل را مدل می‌کنند، و بنچ‌مارک‌های عملی که بر پایهٔ داده‌های واقعی ساخته می‌شوند. او هشدار داد که استفادهٔ مستقیم یک بنچ‌مارک به‌عنوان معیار نهایی می‌تواند سرقت نمونه (sampling bias) ایجاد کند؛ برای مثال، اگر یک بنچ‌مارک فقط کارهای ساده را شامل شود، مدل‌ها ممکن است در کارهای پیچیده شکست بخورند. تالیین بعدی، تالین از Radics Arc، چارچوب Miles را معرفی کرد؛ یک پلتفرم متن‌باز که از اکثر مدل‌های وزن‌باز پشتیبانی می‌کند (Megatron، FSDP، Torch‑Titan) و می‌تواند از یک GPU تا صدها GPU مقیاس‌پذیر باشد. Miles امکان اتصال سادهٔ محیط‌های OpenAI‑Gym‑like به چرخهٔ آموزش را فراهم می‌کند؛ با یک حلقهٔ کوتاه می‌توان محیط را ریست کرد، عمل را با مدل تولید کرد، به محیط ارسال کرد و پاداش را دریافت کرد. این ساختار امکان ترکیب با هارنس‌های سفارشی (مثلاً کد ابری یا sandboxهای اختصاصی) را می‌دهد. در یک مثال عملی، تیم تالین از Miles برای آموزش یک مدل 700 میلیارد پارامتر بر روی بنچ Terminal Bench 2 استفاده کرد؛ با استفاده از RL ناهمگام، ۶۴ GPU برای استنتاج و ۶۴ GPU برای آموزش به کار گرفته شد و در هر گام ۶۴ مسیر (trajectory) تولید شد. نتایج نشان داد که پس از حدود ۱۰۰ گام، پاداش از ۰٫۴۴ به ۰٫۵۶ ارتقا یافت، اما مهم‌تر از این، کشف مشکلاتی همچون **پیرکاری پاداش** و **پاداش‌های نادرست منفی** بود که با اصلاح در OpenIn رفع شدند. سپس ژیانگ لی از Bench Flow به پروژهٔ **Open Arena** پرداخت. هدف این پروژه ساخت یک زیرساخت داده‌ای برای ارزیابی و آموزش مدل‌های بزرگ (تا ۳۲۰ میلیارد پارامتر) است. او اشاره کرد که اکثر پژوهش‌های اخیر روی مدل‌های ۹‑۳۲ میلیارد پارامتر تمرکز دارند و هیچ‌یک از مدل‌های > ۱۲۲ میلیارد پارامتر به‌صورت عمومی منتشر نشده‌اند. در Open Arena بیش از ۹۰ هزار محیط جمع‌آوری شده‌اند؛ از این میان تنها حدود ۸ هزار محیط دارای سیگنال قابل‌آموزش برای مدل GLM 5