تصور کنید یک عامل هوش مصنوعی برای حل یک مشکل فنی، ۹۹٪ مسیر را درست طی کند اما در آخرین لحظه با یک غلط املایی در دستور Bash، کل محیط سیستم را نابود کند. در دنیای فعلی، تنها راه نجات این است که کل فرآیند را از ابتدا تکرار کنید، اما حالا راهی ارزان‌تر پیدا شده است.
طبق گزارشی که در ۱ اکتبر ۲۰۲۶ منتشر شد، پژوهشگران NVIDIA و KAIST با معرفی روش Mid-Harness، استاندارد فعلی صنعت یعنی «مقیاس‌بندی مسیر» (Trajectory Scaling) را به چالش کشیدند. یافته‌های آن‌ها نشان می‌دهد که فیلتر کردن یک دستور واحد در مرز بین مدل و محیط اجرا، ۵.۸ برابر ارزان‌تر از اجرای مجدد کل جلسه است.
بسیاری از عامل‌های ترمینال نه به دلیل ضعف در استدلال سطح بالا، بلکه به دلیل یک خطای دقیق در اجرا شکست می‌خورند. یک عامل ممکن است ساختار پروژه را به‌درستی بفهمد و بداند که به یک پارسر yaml نیاز دارد، اما در گام دوم، به‌جای دستور pip install pyyaml از دستور pip install yaml استفاده کند.
این اشتباه کوچک باعث ایجاد یک آبشار از اقدامات کنترل خسارت می‌شود. شل Bash دستور را اجرا می‌کند، pip اعلام می‌کند که هیچ توزیع منطبق یافت نشد و عامل وارد یک حلقه شکست می‌شود. مدل ممکن است سعی کند از apt-get استفاده کند، راهکارهای ناقصی را در فایل‌های موقت بنویسد یا محیط مجازی (Virtualenv) موجود را تخریب کند. تا گام بیستم، محیط به قدری آلوده می‌شود که هیچ مقدار استدلالی نمی‌تواند مسیر را نجات دهد.
وقتی یک فایل قفل (Lockfile) فاسد شود، یک دیمون پس‌زمینه (Background Daemon) کشته شود یا یک طرح دیتابیس (Database Schema) به‌صورت نیمه‌کاره مهاجرت کند، وضعیت سیستم اغلب غیرقابل بازگشت می‌شود. برای حل این مشکل، توسعه‌دهندگان معمولاً از مقیاس‌بندی مسیر استفاده می‌کنند؛ به این معنا که با عامل مانند یک جعبه سیاه برخورد کرده و جلسات «بهترین در بین N» (Best-of-N) را اجرا می‌کنند. اگر یک عامل در گام دوم کرش کند، سیستم کانتینر را دور ریخته و ۶ جلسه موازی دیگر را از صفر آغاز می‌کند. این روش ضربتی، یک تخصیص هزینه‌بر و نادرست از منابع محاسباتی است. این چالش‌های مدیریتی در محیط‌های ایزوله، رویکردهای جدیدی در استفاده از میکرو-ماشین‌های مجازی برای مدیریت وضعیت عامل‌ها را به دلیل نیاز به بازیابی سریع‌تر، به شدت ضروری کرده است.
سازوکار Mid-Harness
روش Mid-Harness که جزئیات آن در مقاله arXiv:2609.39982 آمده است، محاسبات زمان تست را از بازپخش کل مسیر به مرز بین مدل و محیط اجرا منتقل می‌کند. در این سیستم، به‌جای اجرای اولین خروجی حریصانه (Greedy Output)، سیستم N کاندیدای اقدام را استخراج کرده و از یک «تأییدکننده» (Verifier) برای انتخاب برنده استفاده می‌کند. سایر کاندیداها پیش از آنکه هرگز با شل تماس پیدا کنند، دور ریخته می‌شوند.
پژوهشگران با استفاده از مدل ۹ میلیارد پارامتری (TMAX-9B) روی محک TerminalBench-Lite دریافتند که تولیدکننده (Generator) اغلب دستور درست را تولید می‌کند، حتی زمانی که انتخاب اولش غلط است. نرخ موفقیت پایه (Pass@1) تحت اجرای استاندارد ۵۰.۰۰٪ بود.
با نمونه‌گیری از ۸ کاندید و استفاده از GPT-5.6 Sol به‌عنوان تأییدکننده برای انتخاب بهترین گزینه، نرخ Pass@1 به ۶۸.۰۳٪ جهش کرد. این افزایش ۱۸ امتیازی بدون هیچ‌گونه تنظیم دقیق (Fine-tuning) در مدل تولیدکننده ۹ میلیاردی یا تغییر در محیط ترمینال رخ داد. این موضوع ثابت می‌کند که مدل‌های کوچک فاقد توانایی تولید عملیات‌های معتبر نیستند؛ بلکه فاقد دقت لازم برای رتبه‌بندی دستور درست به‌عنوان انتخاب اول خود هستند. این بهبود در دقت، گامی در جهت کاهش شکاف قابلیت‌سنجی و افزایش قابلیت اطمینان عامل‌های هوش مصنوعی است که پیش‌تر توسط Hugging Face مورد بررسی قرار گرفته بود.
استراتژی‌های تأیید
نویسندگان سه روش متمایز را برای انتخاب دستور برنده از بین N کاندید ارزیابی کردند:
- تأیید لیستی (Listwise Verification): در این روش، تمام ۸ کاندید در یک پرامپت واحد قرار گرفتند و از مدل خواسته شد بهترین حرف (گزینه) را انتخاب کند. این روش تأثیر بسیار کمی داشت و به Pass@1 معادل ۵۱.۰۲٪ رسید (تنها ۱.۰۲ امتیاز افزایش)، زیرا مدل‌های زبانی در مقایسه هم‌زمان چندین دستور فنی Bash در یک لیست واحد دچار مشکل می‌شوند.
- تأیید نقطه‌ای (Pointwise Verification): در این حالت، هر دستور به‌طور مستقل در مقیاس صفر تا ده طی ۸ فراخوانی استنتاج مجزا امتیازدهی شد. این روش به Pass@1 معادل ۵۲.۳۸٪ رسید که بهبود متوسطی را نشان داد اما فاقد یک سیگنال مقایسه‌ای مستقیم بین جایگزین‌های نزدیک بود.
- تأیید جفتی (Pairwise Verification): این روش از یک طرح تورنمنت «دوئل حلقوی» (Ring-duel) استفاده می‌کند. از آنجایی که یک دور کامل (Round-robin) برای ۸ کاندید به ۲۸ دوئل نیاز دارد، نویسندگان طرحی را به کار بردند که در آن ۸ کاندید، ۴ محور (Pivot) ایجاد می‌کنند و سپس این محورها در ۱۶ دوئل با سایر کاندیداها روبرو می‌شوند. این کار سربار را به ۲۲ فراخوانی کاهش داد. این روش با مدل پایه به ۵۴.۷۶٪ و پس از تقطیر (Distillation) قضاوت‌های ترجیحی از GPT-5.6 Sol به مدل ۹ میلیاردی، به ۵۷.۱۴٪ رسید.
نقد زنجیره تفکر (CoT)
در یک مطالعه ابلیشن (Ablation Study) غافلگیرکننده، پژوهشگران این فرض را که تأییدکننده‌ها به یک منطق مفصل زنجیره تفکر (CoT) نیاز دارند، به چالش کشیدند. آن‌ها دو نسخه از تأییدکننده ۹ میلیاردی تقطیر شده خود را آزمایش کردند:
۱. تأییدکننده استدلالی (Reasoning Verifier): یک منطق ۴۲ توکنی می‌نوشت و توضیح می‌داد چرا اقدام B نسبت به اقدام A ترجیح داده می‌شود و سپس انتخاب خود را اعلام می‌کرد. این مدل امتیاز ۵۷.۱۴٪ Pass@1 را کسب کرد.
۲. تأییدکننده تک-توکنی (Single-Token Verifier): مستقیماً یک توکن واحد را برای پیش‌بینی احتمال لاجیت A در برابر B صادر می‌کرد، بدون هیچ متن استدلالی. این مدل امتیاز ۵۹.۱۸٪ Pass@1 را کسب کرد.
استدلال‌های مفصل اغلب باعث می‌شود مدل‌های کوچک دچار توهم در مورد وضعیت‌های فرضی محیط شوند. مدل دلایلی ابداع می‌کند که چرا یک دستور ممکن است شکست بخورد و خودش را از دستورات تک‌خطی و تمیز دور می‌کند و بدین ترتیب نویز را وارد حلقه تصمیم‌گیری می‌کند. طبقه‌بندی مستقیم، این انحراف روایتی را دور می‌زند و هزینه‌های توکن‌های سرتاسری (End-to-end) را ۲۴.۱٪ کاهش می‌دهد.
اقتصاد محاسبات
بر اساس مقاله، انتقال محاسبات به مرز اقدام، ساختار هزینه را به‌طور چشمگیری تغییر می‌دهد. Mid-Harness با N=8 و تأیید جفتی تقطیر شده، عملکرد مشابه مقیاس‌بندی مسیر Best-of-7 (با Pass@1 معادل ۵۹.۱۸٪) را داشت، اما تفاوت هزینه بسیار شدید است:
- Mid-Harness: هزینه تخمینی توکن ۰.۱۶ دلار برای هر اجرا.
- مقیاس‌بندی مسیر Best-of-7: هزینه ۰.۹۱ دلار برای هر اجرا.
این نشان‌دهنده کاهش ۵.۸ برابری در هزینه‌های استنتاج برای نرخ موفقیت یکسان است. همچنین مقیاس‌بندی اقدام (Action Scaling) با مقیاس‌بندی مسیر قابل ترکیب است. ترکیب Mid-Harness با ۳ مسیر (Best-of-3 trajectories) به Pass@1 معادل ۶۵.۳۱٪ با هزینه ۰.۶۱ دلار برای هر اجرا دست یافت. در مقابل، اجرای Best-of-7 روی یک عامل بدون تأیید، تنها به ۵۹.۱۸٪ رسید در حالی که ۰.۹۱ دلار هزینه داشت. کاربران قابلیت اطمینان بالاتری دریافت می‌کنند در حالی که ۳۳٪ کمتر هزینه محاسباتی می‌پردازند.
نقاط شکست باقی‌مانده
تأیید اقدامات هنوز یک مسئله کاملاً حل شده نیست. نویسندگان ۱۸۱۰ مورد را تحلیل کردند که در آن‌ها تأییدکننده تقطیر شده با مدل معلم (Teacher Model) اختلاف نظر داشت و باعث شکست در تکلیف شد. دو حالت شکست، ۶۷.۴٪ از تمام خطاها را تشکیل می‌دادند:
- معناشناسی کاندیدا (۳۹.۰٪): تأییدکننده در مورد اینکه یک رشته دستور در واقعیت چه کاری انجام می‌دهد، اشتباه قضاوت کرد. برای مثال، دستور
token[4] = 'a' + s1را به‌عنوان یک باگ علامت‌گذاری کرد و ادعا کرد که بایدs1 + 'a'باشد، در حالی که هر دو در آن محیط به یک کاراکتر یکسان منجر می‌شدند. - امکان اجرای عملی (۲۸.۴٪): تأییدکننده به دستوراتی پاداش داد که از نظر منطقی کامل به نظر می‌رسیدند اما ناامن بودند. در یک تکلیف پاک‌سازی پردازش، تأییدکننده از اسکریپتی برای کشتن پردازش‌های پورت ۹۰۹۰ تمجید کرد، اما متوجه نشد که این حلقه، خودِ پردازش اجرای پایتونِ عامل را پیش از اتمام کار می‌کشد.
این موضوع نشان می‌دهد تا زمانی که تأییدکننده‌ها بتوانند درخت‌های پردازش و وضعیت‌های کانتینر را مدل کنند، بررسی‌های امکان اجرا شکننده باقی خواهند ماند.
برای متخصصان فنی، این یافته‌ها تمرکز بهینه‌سازی عامل را تغییر می‌دهد. به‌جای سرمایه‌گذاری در زیرساخت‌های کانتینری موازی، اولویت باید دقت در مرز انتخاب اقدام باشد. فیلتر کردن آرگومان‌های خراب پیش از آنکه با شل تماس پیدا کنند، بیش از هر روش بازیابی پس از شکست، در تعداد اجراها صرفه‌جویی می‌کند.
توسعه‌دهندگان اکنون باید ارزیابی کنند که آیا شکست‌های عامل آن‌ها مبتنی بر استدلال است یا مبتنی بر دقت. اگر دستور درست در بین N نمونه برتر مدل وجود دارد، یک تأییدکننده سبک، کارآمدترین مسیر برای رسیدن به قابلیت اطمینان است.
گام بعدی شما
- اگر از عامل‌های کدنویس استفاده می‌کنید، بررسی کنید آیا شکست‌ها ناشی از ضعف استدلال است یا عدم دقت در دستورات نهایی.
- به‌جای افزایش تعداد کانتینرهای موازی، روی پیاده‌سازی یک لایه تأییدکننده سبک (Lightweight Verifier) در مرز اجرا سرمایه‌گذاری کنید.
- برای مدل‌های کوچک، از تأییدکننده‌های تک-توکنی به‌جای مدل‌های استدلالی استفاده کنید تا نرخ توهم کاهش یابد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو