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

گلوگاه واقعی در کشف خودکار الگوریتم‌های یادگیری ماشین چیست؟ مشکل ناتوانی در تولید کدهای بدون خطای سینتکسی نیست، بلکه شکست سیستماتیک در حفظ و مدیریت «حالت» (state) در سناریوهای طولانی‌مدت است. در هر مسئله‌ی بهینه‌سازی پیچیده، یک عامل (agent) باید تصویری کلی از فضای جستجو بسازد. با این حال، بیشتر عامل‌های مهندسی یادگیری ماشین (MLE) مانند برنامه‌نویسانی مبتلا به فراموشی عمل می‌کنند؛ آن‌ها شاخه‌های کدنویسی کاملاً جداگانه‌ای می‌سازند که هیچ ارتباطی با هم ندارند، مسیر خطایابیشان فاقد حافظه است و دائم برنامه‌ریزی استراتژیک را با دیباگ کردن سینتکس مخلوط می‌کنند.

در فریم‌ورک جدیدی به نام MLEvolve که جزئیات آن در مقاله‌ی ژوئن ۲۰۲۶ آمده است، شاهد یک تلاش عمیقاً سیستماتیک برای حل این سه چالش ساختاری هستیم: ایزوله‌شدن اطلاعات بین شاخه‌ها، جستجوی بدون حافظه و فقدان کنترل سلسله‌مراتبی.

بیایید ابتدا سازوکار اصلی این فریم‌ورک را تعریف کنیم. فریم‌ورک MLEvolve یک سیستم چندعاملی و خودتکامل‌دهنده بر پایه‌ی مدل‌های زبانی بزرگ است که مشخصاً برای کشف خودکار الگوریتم‌های یادگیری ماشین طراحی شده است. توسعه‌دهندگان این سیستم به‌جای اینکه جستجوی فضای الگوریتمی را یک درخت ساده فرض کنند، از روشی به نام Progressive Monte Carlo Graph Search (یا Progressive MCGS) استفاده کرده‌اند که ایده‌ی جستجوی درختی مونت‌کارلو را به گراف بسط می‌دهد.

برای فهم کارکرد Progressive MCGS باید ببینیم جستجوهای درختی معمولی در تولید چگونه شکست می‌خورند. وقتی یک عامل، شاخه‌های موازی برای تست ابرپارامترها یا معماری‌های مختلف ایجاد می‌کند، این شاخه‌ها کاملاً از هم ایزوله‌اند. اگر شاخه‌ی الف به یک ترفند ارزشمند — مثلاً یک نرخ یادگیری پویا — دست یابد، شاخه‌ی ب هرگز از آن باخبر نمی‌شود. Progressive MCGS این مشکل را با تبدیل درخت به گراف و تعریف یال‌های مرجع (reference edges) بین شاخه‌ها حل می‌کند تا جریان اطلاعات به صورت افقی برقرار شود. علاوه بر این، از یک زمان‌بندی پویا مبتنی بر آنتروپی استفاده می‌کند که در ابتدا اجازه‌ی اکتشاف گسترده (exploration) می‌دهد و رفته‌رفته تمرکز سیستم را روی استخراج نتایج بهینه‌تر (exploitation) در مسیرهای موفق‌تر می‌گذارد.

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

بخش ساختاری دوم، حافظه‌ی گذشته‌نگر یا Retrospective Memory است. یک عامل معمولی معمولاً روی یک پنجره‌ی متنی ساده یا یک جستجوی وکتوری اولیه کار می‌کند. این نگاه بدون حافظه منجر به تکرار خطاهای قبلی می‌شود. طبق مستندات منتشرشده در نسخه‌ی PDF مقاله، این فریم‌ورک حافظه را به دو بخش تقسیم می‌کند: یک پایگاه دانش اولیه (cold-start) برای اطلاعات پایه‌ای دامنه، و یک حافظه‌ی پویای جهانی (dynamic global memory) برای ثبت تجربیات خاص هر تسک.

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

سومین مؤلفه‌ی طراحی، جداسازی برنامه‌ریزی استراتژیک از تولید کد است. یکی از شایع‌ترین سناریوهایی که یک عامل را متوقف می‌کند، «مارپیچ مرگ سینتکس» است؛ جایی که عامل ایده‌ی کلان فوق‌العاده‌ای دارد، اما یک ویرگول جاافتاده یا خطای ابعاد (shape mismatch) در پایتورچ باعث می‌شود استراتژی اصلی را کلاً رها کند. MLEvolve با جدا کردن عامل برنامه‌ریز (planner) از عامل کدنویس (coder) و استفاده از حالت‌های کدنویسی آداپتیو (adaptive coding modes) این مشکل را حل می‌کند.

بر اساس ارزیابی‌های انجام‌شده روی محک سخت‌گیرانه‌ی MLE-Bench که در پایگاه نتایج پروژه بازتاب یافته است، MLEvolve توانسته به نرخ مدال متوسط ۶۵.۳ درصد دست یابد. نکته‌ی کاربردی و کلیدی این است که سیستم مذکور این نتیجه را در یک بازه‌ی زمانی ۱۲ ساعته (نصف زمان استاندارد ۲۴ ساعته در این محک) به‌دست آورده است. همچنین در بهینه‌سازی الگوریتم‌های ریاضیاتی، از فریم‌ورک‌های تخصصی کشف الگوریتم مانند AlphaEvolve پیشی گرفته است.

وقتی این را پیاده می‌کنی، با چه چالشی روبه‌رو می‌شوی؟ موازنه‌ی اصلی (trade-off) در اینجا هزینه‌ی پردازش و زمان تاخیر ناشی از ارکستریشن چندعاملی است. عملیات متراکم گرافی در Progressive MCGS و جستارهای مداوم در حافظه‌ی گذشته‌نگر، بار پردازشی بالایی برای مدیریت دیتای متادیتا ایجاد می‌کنند. این رویکرد یادآور درسی است که در پیاده‌سازی سیستم‌های واقعی و عملیاتی مانند BLZN.AI Enterprise گرفتم؛ جایی که برای تست استراتژی‌های معاملاتی باید یک موتور بک‌تست قوی می‌ساختیم. اگر برنامه‌ریزی سطح‌بالا را با اجرای خام کدها جفت می‌کردیم، کوچک‌ترین باگی در محیط اجرا کل مسیر جستجو را نابود می‌کرد. جداسازی برنامه‌ریزی از بستر اجرا یک کار لوکس نیست، بلکه یک ضرورت زیرساختی برای تداوم کار بدون وقفه‌ی سیستم است.

در نهایت، فریم‌ورک MLEvolve نشان می‌دهد که مسیر رسیدن به سیستم‌های خودتکامل‌دهنده، صرفاً ساخت مدل‌های زبانی «باهوش‌تر» نیست. بلکه تعریف مرزهای ساختاری درست است.

منابع

• MLEvolve: A Self-Evolving Framework for Automated Machine Learning Algorithm Discovery — arXiv · cs.AI · 2026-06-04