دو مدل پرچمدار، یه مسئلهٔ NP-سخت
خلاصهٔ کاملتر
نویسنده یه مسئلهٔ واقعی تحقیق در عملیات رو به عنوان بنچمارک برداشته: طراحی شبکهٔ فیبر که خودش سال ۲۰۱۸ به عنوان دانشجو روش کار کرده و یه بار هم یه هفته وقت گذاشته تا با C++ حلش کنه — یعنی یه خط پایهٔ انسانی واقعی هم داره. مسئله باید نقاط توزیع و ترمینالها رو با حلقهها و شاخههای کوتاه به هم وصل کنه و هدف، کمینه کردن طول کل کابله.
برای اینکه اندازهٔ فضای جستوجو دستمون بیاد، فقط شهر پاریس با ۵۳۲ ترمینال و ۱۱ هاب توزیع، حتی تو یه خانوادهٔ عمداً محدودشده از جوابهای معتبر، به حدود ۱۰ به توان ۱۲۲۳ حالت میرسه. تنظیمات آزمایش هم مشخصه: بودجهٔ ۳۰ دقیقهای بهینهسازی، تایماوت ۱۹۰۰ ثانیهای برای ایجنت بیرونی، بالاترین سطح استدلال برای همهٔ مدلها و اجرا روی داکر با احراز هویت اشتراکی.
نتیجهٔ اول اینه که Fable 5 به قول نویسنده روی این بنچمارک یه هیولا بوده: بهترین جواب کلی رو تولید کرده و پایداریش هم چیزی بوده که تا حالا رو این مسئله ندیده. میانگین حالت سادهش ۱٬۸۷۵ امتیاز از رقیب بهتر بوده و مهمتر اینکه سه اجرای سادهش تو یه بازهٔ ۳۱۹ امتیازی موندن، در حالی که همون بازه برای مدل رقیب ۱٬۹۵۸ امتیاز بوده.
نتیجهٔ دوم جالبتره. حالت goal چهار تا از شش آزمایش جفتی رو برد، پس اگه فقط نرخ برد رو نگاه کنی فیچر مفیدی به نظر میرسه. ولی میانگینها حرف دیگهای میزنن: میانگین هر دو مدل با goal بدتر شد. الگو اینه که این حالت معمولاً یه سود کوچیک میده و گهگاه یه پسرفت بزرگ — یعنی میانه کمی بهتر میشه ولی دُم بد خیلی دورتر میره.
نویسنده توضیح میده چرا: تو یه تسک کدنویسی عادی، پیشرفت خواناست و یه دور اضافه میتونه یه تست رو سبز کنه. تو بهینهسازی اما وقتی ایجنت حلکنندهشو انتخاب کرد، وقت اضافه فقط همون تصمیم رو تقویت میکنه؛ چه خوب باشه چه بد. goal وقتی کمک کرد که یه پرتفوی سریع کامپایلشده رو ادامه داد، و وقتی ضرر زد که پای یه حلکنندهٔ کند یا یه جستوجوی فرسایشی موند.
بخش فنی مقاله نشون میده یه اسم مشترک، دو سیستم متفاوت رو پنهون کرده. تو Claude Code، دستور goal یه قلاب Stop در سطح جلسهست: بعد از هر نوبت مدل اصلی، یه مدل ارزیاب کوچیک (پیشفرض Haiku) شرط و گفتوگو رو میخونه و بله یا خیر برمیگردونه. این ارزیاب ابزار نداره و فایلها رو نمیبینه، پس فقط شواهد داخل ترنسکریپت رو قضاوت میکنه.
تو Codex اما هدف یه وضعیت ماندگار روی همون تردهست که تو SQLite ذخیره میشه؛ خود مدل کاری ابزارهای ساخت، خوندن و بهروزرسانی هدف رو در اختیار داره و اگه ترد بیکار بشه، یه نوبت ادامه به همراه ممیزی تکمیل تزریق میشه. جمعبندی نویسنده اینه که Claude تشخیص اتمام رو به یه مدل مستقل ولی نابینا سپرده و Codex به مدلی که فایلها رو میبینه ولی عملاً کار خودشو نمره میده.
خود نویسنده محدودیتها رو هم شفاف گفته: این فقط یه تسک NP-سخت منتشرنشدهست نه یه لیدربورد عمومی، فقط دو مدل سه جفت اجرای تمیز دارن، و کانتینرها برخلاف متادیتا هشت هسته در اختیار گذاشتن که به نفع پرتفوهای موازی تموم شده. حرف تیتر مقاله هم همینه: یه فیچر پایداری میتونه بیشتر آزمایشهای تکی رو ببره و همزمان میانگین عملکرد رو بدتر کنه.
نکات کلیدی:
- بنچمارک روی یه مسئلهٔ طراحی شبکهٔ فیبر با فضای جستوجوی نجومی اجرا شده
- Fable 5 بهترین جواب و کمنوسانترین اجراها رو داشت
- حالت goal چهار از شش آزمایش رو برد ولی میانگین هر دو مدل رو بدتر کرد
- دلیلش اینه که وقت اضافه، تصمیم اولیه رو تقویت میکنه؛ خوب یا بد
- پیادهسازی goal تو Claude Code و Codex بنیادی فرق داره: ارزیاب جدا در برابر وضعیت ماندگار
- محدودیتها: یه تسک، تعداد کم اجراها و منابع CPU بیشتر از چیزی که اعلام شده بود




