مقاله‌ی arXiv:2610.17184 · در صف خبرنامه
DuoDiscover: Scaling Autonomous Discovery Beyond the Evaluation Bottleneck
- تاریخ
- (۲۰ مهر ۱۴۰۵) 2026-10-12
- نویسنده‌ها
- Shubham Agarwal, Akshat Gupta, Mike Heddes, Dilara Soylu, Ion Stoica, Tomas Pfister
- برچسب لابراتوار
- موضوع‌ها
خلاصه‌ی فارسی
مقاله‌ی DuoDiscover: Scaling Autonomous Discovery Beyond the Evaluation Bottleneck (12 Oct 2026، گوگل با دانشگاه‌های برکلی و استنفورد؛ از جمله یون استوئیکا و توماس فیستر)
مسئله: وقتی به ایجنت کدنویس می‌گویی کدی را سریع‌تر کند، مثلاً یک کرنل جی‌پی‌یو یا موتور سرو مدل vLLM، هر بار سنجیدن واقعی نتیجه چند دقیقه تا چند ساعت طول می‌کشد. پس در کل اجرا فقط چند ده بار می‌شود نتیجه را درست اندازه گرفت و ایجنت بیشتر وقتش را منتظر می‌ماند.
روش:
- هر ایجنت در یک گروه چهارتایی خودش یک بخش از کد را برای بهینه‌سازی انتخاب می‌کند و هم‌زمان یک «خط‌کش» ارزان برایش می‌نویسد: اسکریپتی که در چند ثانیه نمره می‌دهد، مثلاً فقط چند ورودی نماینده را اجرا می‌کند یا چند تکرار را زمان می‌گیرد. برای نمونه، در یک لایه‌ی ترکیب متخصص‌ها سنجش کامل حدود ۱۶ دقیقه طول می‌کشید و خط‌کش ایجنت ۱۸ ثانیه.
- ایجنت ویرایش‌ها را پشت سر هم روی همین خط‌کش امتحان می‌کند و هر کدام نمره را بهتر کند نگه می‌دارد. خط‌کش لازم نیست عدد دقیق بدهد؛ فقط باید درست بگوید از دو نسخه کدام بهتر است.
- هر بهبود در نهایت با سنجش واقعی تأیید می‌شود. یک «آزمون وفاداری» هم مدام چک می‌کند ترتیبی که خط‌کش می‌دهد هنوز با سنجش واقعی جور است. اگر ایجنت راهی پیدا کرده باشد که فقط خط‌کش را راضی کند و کد واقعاً بهتر نشود، آن خط‌کش کنار گذاشته می‌شود.
- کار از بالا تقسیم نمی‌شود. یک ارکستراتور سبک فقط سنجش‌های گران را مدیریت می‌کند: ایجنت گیرکرده را متوقف می‌کند، به بقیه در یک پیام کوتاه می‌گوید گروه تا حالا چه پیدا کرده، و ایجنت تازه را از بهترین نتیجه‌ی تأییدشده شروع می‌کند یا بهبودهای چند ایجنت را در یک نسخه جمع می‌کند.
یافته‌ها:
- روی vLLM، کلاد کد به‌تنهایی (با همان مدل Opus 5) سرعت را فقط حدود ۷ درصد بهتر کرد، ولی با این روش تقریباً دو برابر شد. روی SQLite هم حدود ۴۰ درصد سریع‌تر شد.
- روی بنچمارک SWE-fficiency، که در آن باید ریپوهای واقعی را سریع‌تر کرد، میانگین افزایش سرعتش دو برابرِ چیزی بود که متخصص‌های انسانی به دست آورده بودند. در جدول کرنل‌های انویدیا (SOL-Exec) هم روی ۱۲۱ کرنل از ۲۳۵ کرنل رتبه‌ی اول را گرفت.
- روش به یک ابزار خاص بسته نیست: روی آنتی‌گرویتی با Gemini 3.8 Flash هم نتیجه را بالا برد.
- در طراحی ریزمعماری پردازنده، که هر سنجش واقعی تا ۲۸ ساعت طول می‌کشد، از بهترین طراحی انسانی و از ArchAgent v2 (ساخته‌شده روی AlphaEvolve) جلو زد و در ۱۶٫۷ روز، در برابر بیش از ۴۰ روز، به بهبودی ۱٫۶۵ برابرِ بهبود ArchAgent v2 رسید.
محدودیت‌ها: خود نویسنده‌ها می‌گویند اگر برای بخشی نشود خط‌کش قابل‌اعتماد ساخت، روش به همان جست‌وجوی معمولی با سنجش گران برمی‌گردد. ساختن خط‌کش‌ها و آزمون‌های اولیه هم وقت راه‌اندازی می‌خواهد، پس برای بودجه‌های خیلی کوتاه به‌صرفه نیست. نتایج اصلی هم از یک اجرا هستند و پراکندگی نتایج فقط روی بخشی از کارها گزارش شده.