درون autoresearch؛ عامل‌هایی برای بهینه‌سازی کد یادگیری ماشین

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

۱۱٪؛ این عدد، میزان بهبود سرعتی است که آندری کارپاتی با اجرای ۷۰۰ آزمایش به دست آورد تا زمان آموزش نسخه‌ای با کیفیت GPT-2 را از ۲.۰۲ ساعت به ۱.۸۰ ساعت برساند. طبق اعلام کارپاتی، این نتیجه حاصل تلاش یک مهندس انسان نبود، بلکه محصول یک حلقهٔ خودکار هوش مصنوعی بود که خستگی‌ناپذیر در حال آزمون و خطا روی کدهای خودش بود.

همان‌طور که در تحلیل قبلی ما درباره‌ی خودکارسازی حلقه‌های کدنویسی اشاره کردیم، صنعت در حال گذاری سریع از پرامپت‌های تک‌مرحله‌ای به «مهندسی حلقه» است. در یک پرامپت معمولی، انسان باید هر مرحله را تأیید و فعال کند، اما در یک حلقه، عامل (Agent) — مثل یک دستیار هوشمند که هدف نهایی را می‌داند و تا رسیدن به آن دست برنمی‌دارد — به‌صورت مستقل پیش می‌رود تا به یک معیار موفقیت قابل اندازه‌گیری برسد. این تحول در واقع بخشی از تغییر استراتژیک به سمت بازبینی رفتار به‌جای کدنویسی است که در آن تمرکز بر خروجی نهایی و رفتاری است نه صرفاً خطوط کد. این راهنما بر اساس مستندات تأیید شده شامل مخزن autoresearch آندری کارپاتی، مقاله Bilevel Autoresearch و نوشتارهای فنی @0xCodila تدوین شده است.

کالبدشکافی حلقهٔ کارپاتی

در ۷ مارس ۲۰۲۶، کارپاتی مخزن autoresearch را با مجوز MIT منتشر کرد. این سیستم به‌شدت سبک است و آگاهانه به گونه‌ای طراحی شده که تنها شامل ۶۳۰ خط کد در سه فایل اصلی باشد. طبق گزارش‌های گیت‌هاب، این پروژه به‌سرعت ویروسی شد و با دریافت نزدیک به ۹۰ هزار ستاره توجه جهانیان را جلب کرد. معماری این سیستم بر سه ستون اصلی استوار است:

• تأییدکننده (Verifier): یک دروازه سخت‌گیرانه (مانند ابزار prepare.py) که تلاش‌های مدل را با معیاری به نام val_bpb (بیت بر بایت اعتبارسنجی) می‌سنجد. بدون وجود این بخش، عامل صرفاً با خودش موافقت می‌کند و در یک چرخه تکراری گیر می‌کند.
• وضعیت پایدار (Persistent State): یک فایل جانبی کوچک که ثبت می‌کند چه چیزهایی امتحان شده، کجا شکست خورده و چه مسیرهایی هنوز بررسی نشده‌اند. این قابلیت به عامل اجازه می‌دهد پیشرفت خود را ادامه دهد، به جای اینکه هر بار از صفر شروع کند.
• شرط توقف (Stop Condition): یک محدودیت سخت روی تعداد دفعات تلاش (N attempt) یا یک امتیاز هدف مشخص برای جلوگیری از هزینه‌های سرسام‌آور محاسباتی در صورت عدم رسیدن به نتیجه.

برای جلوگیری از «تقلب» هوش مصنوعی، عامل فقط اجازه دارد فایل train.py را ویرایش کند؛ جایی که مدل GPT، بهینه‌ساز (Optimizer) — شامل Muon و AdamW — و حلقهٔ آموزش قرار دارند. عامل به‌طور مطلق مجاز نیست به ابزارهای ارزیابی در prepare.py دست بزند. این جداسازی تضمین می‌کند که عامل مدل را واقعاً بهبود ببخشد، نه اینکه تست‌ها را ساده‌تر کند تا امتیاز به ظاهر بالا برود. برای مدیریت ریسک‌های احتمالی در این süreç، ابزارهایی مانند ai-loopguard برای توقف چرخه‌های مرگبار توسعه یافته‌اند تا از گیر افتادن عامل در حلقه‌های بی‌‌پایان جلوگیری کنند. در این میان، انسان تنها دستورالعمل‌ها و جهت‌گیری‌های کلی را در فایلی به نام program.md می‌نویسد و عامل موظف است به این دستورات احترام بگذارد.

عملکرد در دنیای واقعی

کارپاتی این حلقه را روی کد بهینه‌شدهٔ nanochat GPT-2 خود اجرا کرد. در هر چرخه، سیستم یک آزمایش را اجرا می‌کند: عامل کد را می‌خواند، تغییری پیشنهاد می‌دهد، مدل را برای ۵ دقیقه آموزش می‌دهد و سپس تصمیم می‌گیرد تغییر را نگه دارد یا آن را به حالت قبل (Roll back) برگرداند. با این بودجه زمانی، سیستم حدود ۱۲ آزمایش در ساعت انجام می‌دهد که اجازه می‌دهد حدود ۱۰۰ اجرا در طول یک شب رخ دهد.

بر اساس بررسی‌های فنی، این عامل طی دو روز ۷۰۰ آزمایش انجام داد و در نهایت ۲۰ بهبود واقعی و معتبر را ثبت کرد. یکی از موفقیت‌های کلیدی و خاص، شناسایی یک پیاده‌سازی ناقص در QK-Norm بود که یک ضرب‌کننده اسکالر (Scalar multiplier) در آن گم شده بود؛ این نقص باعث می‌شد مکانیزم توجه (Attention) بیش از حد در میان سرهای توجه (Heads) پراکنده شود و دقت مدل کاهش یابد.

دیگران نیز نتایج مشابهی می‌گیرند. توبی لوتکه، مدیرعامل Shopify، این سیستم را شبانه روی یک مدل داخلی اجرا کرد و گزارش داد که تنها پس از ۳۷ آزمایش، بهبود ۱۹ درصدی حاصل شده است. این رویکرد یادگیری مستمر یادآور تلاش‌های کیپرونو نگتیچ در کاهش نرخ خطای هوش مصنوعی است که با استفاده از حلقه‌های بازخورد داده‌ها، دقت مدل‌ها را به‌شدت افزایش داد. نکته کلیدی در اینجا، تضاد شدید در استقامت است: انسان‌ها معمولاً بعد از ۱۰ تا ۱۲ آزمایش خسته می‌شوند و دقت خود را از دست می‌دهند، اما حلقه با Rigor یا دقت کامل، صدها بار این کار را تکرار می‌کند. همان‌طور که کارپاتی اشاره کرد: اگر یک معیار سنجش عینی (Objective metric) داشته باشید، خودِ شما (انسان) تنها گلوگاه سرعت هستید.

مقایسه: پرامپت در برابر حلقه

برای درک تکامل این سیستم‌ها، می‌توان آن‌ها را به‌صورت رودررو مقایسه کرد:

• پرامپت تک‌مرحله‌ای (One-shot Prompt): شما هر قدم را تعریف می‌کنید و دستی تکرار می‌کنید. شما هم موتور محرک هستید و هم تأییدکننده. وضعیت (State) تنها در تاریخچه چت ذخیره می‌شود.
• حلقهٔ کارپاتی: هدف را یک‌بار تعریف می‌کنید. عامل داخلی تکرار می‌کند. تأییدکننده فایل prepare.py است و وضعیت در یک لاگ آزمایش‌ها پیگیری می‌شود. انسان تنها نویسنده program.md است.
• حلقهٔ دوسطحی (Bilevel Loop): هدف یک‌بار تعریف می‌شود اما هم عامل داخلی و هم عامل خارجی تکرار می‌کنند. این مدل از همان معیار استفاده می‌کند اما در دو سطح مختلف عمل می‌کند و از لاگ‌ها و تزریق کد برای مدیریت وضعیت استفاده می‌کند. نتیجه، افت بسیار شدیدتر و بهتری در val_bpb است.

مقیاس‌پذیری با Bilevel Autoresearch

پژوهشگران در مقاله‌ای با عنوان Bilevel Autoresearch: Meta-Autoresearching Itself، این مفهوم را به «حلقه روی حلقه» ارتقا دادند تا مشکل تکرار پیش‌فرض‌های شکست‌خورده در حلقهٔ داخلی حل شود.

در این معماری، یک حلقه داخلی تغییرات را پیشنهاد، آموزش و ارزیابی می‌کند. اما یک حلقه خارجی، این حلقه داخلی را زیر نظر می‌گیرد، کدهای آن و ردپاهای (Traces) اجرایی‌اش را می‌خواند تا تشخیص دهد جست‌وجو در کجا متوقف شده یا دچار رکود شده است. سپس حلقه خارجی مکانیزم‌های پایتونی جدیدی می‌نویسد، آن‌ها را در زمان اجرا (Runtime) تزریق می‌کند و حلقه داخلی را مجدداً اجرا می‌کند تا مدل را مجبور به اکتشاف در مسیرهای ناشناخته و غیرمتعارف کند.

با استفاده از یک کارت گرافیکی RTX 5090 32GB و بودجه زمانی ۳۰۰ ثانیه‌ای، این معماری دوسطحی به کاهش val_bpb دست یافت که ۵ برابر بیشتر از حلقه تک‌لایه بود (۰.۰۴۵- در برابر ۰.۰۰۹-). نکته حیاتی این است که هر دو مدل از یک LLM یکسان استفاده کردند؛ این یعنی پیشرفت ناشی از معماری حلقه بود، نه هوشمندتر شدن خودِ مدل.

این طراحی دقیقاً در سه سطح عمل می‌کند:

• سطح ۱: اجرای حلقه پایه برای تغییرات کد.
• سطح ۱.۵: تنظیم ابرپارامترهای جست‌وجو هر ۵ تکرار یک‌بار.
• سطح ۲: تولید مکانیزم‌های جدید از طریق یک جلسه چهار مرحله‌ای.

مهندسی حلقه در تیم‌های مدرن

تیم‌های هوش مصنوعی اکنون این جریان‌های کاری را با استفاده از پنج بلوک بازپذیر و قابل استفاده مجدد می‌سازند:

• اتوماسیون (Automation): فعال کردن حلقه بر اساس یک زمان‌بندی، یک رویداد خاص یا یک Trigger.
• مهارت‌ها (Skills): تزریق دانش ذخیره شده در فایل‌های markdown که در هر اجرای حلقه خوانده می‌شوند.
• عامل‌های فرعی (Sub-agents): جداسازی نویسنده از بازبین (Reviewer) برای جلوگیری از این اتفاق که مدل با سخاوتمندی بیش از حد، به کارهای خودش نمره بالا بدهد.
• رابط‌ها (Connectors): اجازه دادن به حلقه برای فعالیت در ابزارهای واقعی، مانند Slack یا سیستم‌های پیگیری خطا (Issue tracker).
• تأییدکننده (Verifier): دروازه نهایی که هرگونه کار بی‌کیفیت یا شکست‌خورده را رد می‌کند.

پلتفرم‌هایی مانند Claude Code و Codex اکنون هر پنج جزء را در قالب ابزارهای خود ارائه می‌دهند. برای کاربر عملی، نقش انسان از «موتور» به «نویسنده» تغییر می‌کند. شما دیگر کد نمی‌نویسید؛ بلکه دستورات متنی در program.md و معیارهای موفقیت را تعیین می‌کنید.

کاربردهای متنوع

این معماری فراتر از پیش‌آموزش (Pretraining) مدل‌هاست. هر جا که یک «دروازه خودکار» برای رد یا پذیرش کار وجود داشته باشد، مهندسی حلقه قابل اجراست:

• کار با مدل: جست‌وجوی ابرپارامترها تا رسیدن به کمترین مقدار val_bpb.
• مهندسی نرم‌افزار: بازنویسی و Refactoring کد تا زمانی که تمام تست‌ها، Type-checkها و Build نهایی پاس شوند.
• تولید محتوا: بازنویسی متوالی متن تا زمانی که امتیاز هر بخش طبق یک rubric (سنجه‌) مشخص، از حد معین بالاتر برود.
• مهندسی داده: تنظیم خط لوله‌های داده (Pipeline) تا زمانی که تمام بررسی‌های Schema تأیید شوند.

تست عملی: شبیه‌سازی حلقه در یک پرامپت

شما می‌توانید این مکانیزم را بدون ابزار خاص، با یک پروتکل خود-اصلاحی شبیه‌سازی کنید. متن زیر را در یک مدل قوی قرار دهید:

"You will work in a loop until the task meets the bar.
TASK: [describe exactly what you want produced]
SUCCESS CRITERIA (be strict): - [criterion 1], [criterion 2], [criterion 3]
LOOP PROTOCOL, repeat every turn:

1. PLAN - state the single next step.
2. DO - produce or improve the work.
3. VERIFY - score the result 1-10 on each criterion. Be honest.
4. DECIDE - if every criterion is 8+, print FINAL and stop. Otherwise print ITERATING and fix the weakest point first.
   RULES: Never call it done until every criterion is 8 or higher. Each pass must fix the weakest score. Do not ask questions."

در لایه زیرین، منطق این جریان مانند یک کد پایتونی ساده است: یک تأییدکننده امتیاز را حساب می‌کند و تصمیم می‌گیرد کاندید جدید را نگه دارد یا رد کند (بر اساس اینکه آیا امتیاز جدید بهتر از بهترین امتیاز قبلی است یا خیر)، و این روند تنها زمانی پایان می‌یابد که بودجه MAX_STEPS تمام شود یا هدف TARGET محقق گردد.

گام بعدی شما

• اگر از مدل‌های کدنویس استفاده می‌کنید، به‌جای درخواست تک‌مرحله‌ای، معیارهای موفقیت (Success Criteria) را به‌صورت لیست عددی و سخت‌گیرانه تعریف کنید.
• مخزن autoresearch را در گیت‌هاب بررسی کنید تا متوجه شوید چگونه می‌توان با محدود کردن دسترسی عامل به فایل‌های ارزیابی، از تقلب مدل جلوگیری کرد.
• پروتکل شبیه‌سازی حلقه را در چت‌های پیچیده خود امتحان کنید تا نرخ خطای خروجی‌ها را کاهش دهید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.