تصور کنید برنامهنویسی دارید که کدنویسی فوقالعادهای بلد است، اما نمیداند چه زمانی باید متوقف شود یا چگونه خطاهای تکراری را مدیریت کند. این دقیقاً همان نقطهای است که پیشرفتهترین عاملهای هوش مصنوعی امروز در آن شکست میخورند. آنها نه به دلیل ناتوانی در نوشتن کد، بلکه به دلیل ناتوانی در مدیریت فرآیند نوشتن آن، با یک سقف عملکردی مواجه شدهاند.
طبق گزارشی که تیم DreamX از شرکت Alibaba و دانشگاه UNSW در تاریخ ۲۶ آگوست ۲۰۲۴ در arXiv (با شماره ۲۶۰۸.۲۸۲۸۱) منتشر کردند، نرخ موفقیت سختگیرانه برای وظایف طولانیمدت در عاملهای کدنویس تنها ۲۴.۶۹٪ است. این یافته نشان میدهد که سقف عملکرد فعلی، به دلیل ناتوانی در مدیریت فرآیند کدنویسی است، نه لزوماً ضعف در نوشتن خودِ کد.
مشکل حلقه بیرونی
بیشتر چارچوبهای عاملمحور (Agentic) مدرن، مانند Claude Code و Devin، بر اساس یک «حلقه بیرونی» عمل میکنند که وظایف را تجزیه کرده و مدل کارگر را هدایت میکند. این حلقه وظایفی چون ثبت تغییرات (Diffs)، بررسی لاگهای تست، مطالعه یادداشتهای پیشرفت و تصمیمگیری برای ادامه، تغییر مسیر یا توقف کامل فرآیند را بر عهده دارد. این ساختارها در واقع تکامل یافتهی مدلهای سادهتری هستند که در آن رانتایمهای بادوام جایگزین حلقههای ساده در عاملهای هوش مصنوعی شدند تا پایداری عملیاتی افزایش یابد.
با این حال، محکهای استانداردی مانند SWE-bench، این اجراها را به صورت یک «تلاش مبهم» میبینند. این رویکرد باعث میشود مشخص نشود که شکست نهایی به دلیل یک خطای سینتکسی ساده در کد بوده یا به این دلیل که مدل ناظر (Supervisor)، فرآیند را خیلی زود متوقف کرده است. اگر یک عامل شکست بخورد، لاگ خطای نهایی فاش نمیکند که آیا کارگر سینتکس نامعتبر نوشته است یا اینکه ناظر حلقه، یک تاییدیه توهمی (Hallucinated) از تست را پذیرفته یا یک پسرفت (Regression) را نادیده گرفته است.
برای جداسازی این سطح از خطا، LoopArena سامانه را به دو نقش مجزا تقسیم میکند:
- کارگر (Worker): عاملی ثابت که فایلها را ویرایش میکند، دستورات شل (Shell) را اجرا کرده و مجموعهتستها را میراند. این نقش، تغییرات کد (Diffs) را تولید کرده و خروجیهای اجرا و لاگهای خطا را صادر میکند.
- کنترلکننده (Controller): مدلی که تحت آزمایش است؛ این مدل خلاصههای ساختاریافته از اجرا را میخواند و تصمیم میگیرد که آیا باید قراردادهای جدید صادر کند، بررسیهای تأییدی خاصی را اجرا نماید، عملیات را بازگرداند (Rollback) یا نتیجه را ارسال (Submit) کند.
سطوح ارزیابی
این محک، کنترلکنندهها را در سه سطح هزینه اجرا ارزیابی میکند:
- نوع اول (Type I): پرسشهای استاتیک برای بررسی اینکه آیا کنترلکننده گام بعدی درست را در ردپاهای تاریخی (Historical Traces) انتخاب میکند یا خیر. این ارزیابی بدون نیاز به محیط زنده اجرا میشود.
- نوع دوم (Type II): کنترل تعاملی روی بخشهای هدفمند (Slices) از یک وظیفه توسعه برای اندازهگیری توانایی بازیابی چندمرحلهای در مواجهه با زیر-مسئلههای خاص.
- نوع سوم (Type III): اجرای کامل وظایف طولانیمدت از وضعیت اولیه مخزن کد تا اتمام کامل کار.
بر اساس مستندات LoopArena، کنترلکنندههای کارآمد میتوانند هزینههای کل استنتاج (Inference) را بهطور متوسط ۶۴.۴٪ کاهش دهند. این امر از طریق «هرس فعال» (Active Pruning) محقق میشود که چرخههای تکراری تست را حذف کرده، از ویرایشهای دوری (Circular Edits) جلوگیری میکند و مسیرهای محکوم به شکست را پیش از آنکه بودجه توکنها تمام شود، متوقف میکند.
علاوه بر این، پژوهشگران همبستگی رتبهای اسپیرمن (Spearman rank correlation) شدیدی به مقدار ۰.۹۷۴۷ بین ارزیابیهای تکهای نوع دوم و اجراهای کامل نوع سوم یافتند. این یعنی توسعهدهندگان میتوانند پرامپتهای ناظر را روی بخشهای کوتاه آزمایش کنند، بهجای آنکه برای هر اجرای کامل مخزن، صدها دلار هزینه کنند.
بهبود سیاست کنترلی
این تغییر در ارزیابی، این فرض بنیادین را که «ارتقای مدل پایه یا گسترش پنجره زمینه (Context Window) تنها راه دستیابی به قابلیت اطمینان است» به چالش میکشد. دادهها نشان میدهند که سیاست کنترل زمان اجرا (Runtime Control Policy)، اغلب پیش از آنکه محدودیتهای زمینه به مشکل تبدیل شوند، نقطه شکست اصلی است. این موضوع با تحلیلهای پیشین ما همسو است که بررسی میکرد چرا لایه هماهنگکننده باعث شکست سامانههای چندعاملی در محیط عملیاتی میشود.
برخی از شکستهای رایج در محیط تولید عبارتاند از:
- نوسان حلقه (Loop Thrashing): کارگر بین دو ویرایش متضاد جابهجا میشود و ناظر کورکورانه گزارش میدهد که پیشرفت حاصل شده است.
- یادداشتهای پیشرفت منقضی: کارگر ادعا میکند باگی را در یک docstring رفع کرده و ناظر بدون اجرای مجموعهتستها، فرآیند را میبندد.
برای رفع این شکافها، پژوهشگران اجرای سختگیرانه قراردادها را توصیه میکنند:
- اجبار به گیتهای تأیید: هر زیر-وظیفه باید با یک تست قابل اجرا و صریح تأیید شود؛ هرگز نباید اجازه داد ناظر، تضمینهای متنی و زبان طبیعی کارگر را بپذیرد.
- ردیابی بودجه تغییرات: اگر عاملی یک بخش پنج خطی از کد را سه بار تغییر داد اما وضعیت تست تغییر نکرد، ناظر باید به جای صدور یک تلاش مجدد آزاد، دستور بازگشت (Rollback) اجباری صادر کند.
- جداسازی مشاهده از تصمیمگیری: برای جلوگیری از توهم و حفظ استقرار تصمیمات، به جای ارسال کل خروجی خام ترمینال (Scrollback)، یک خلاصه پاکسازیشده و ساختاریافته به ناظر داده شود.
توسعهدهندگان اکنون میتوانند به مخزن کد و ابزارهای ارزیابی در گیتهاب در مسیر AMAP-ML/LoopArena دسترسی داشته باشند تا سیاستهای کنترلی خود را آزمایش کنند.
گام بعدی شما
- اگر از عاملهای کدنویسی استفاده میکنید، لایه ناظر خود را با گیتهای تأیید سختگیرانه (Verification Gates) بازبینی کنید.
- برای کاهش هزینهها، استراتژی هرس فعال را در مدیریت توکنهای استنتاج پیادهسازی کنید.
- از ارزیابیهای تکهای (Slices) برای بهینهسازی پرامپتهای کنترلی استفاده کنید تا هزینههای تست کاهش یابد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو