معیار Tank Duel

14 اجرا از یک بازی three.js با یک مشخصات واحد، با 7 روش ساخت مختلف و هر روش دو بار، تا معلوم شود graph-loop باید چطور بسازد. هر اجرا مراحل حلقه را طی کرد: ساخت، مجموعه‌ی آزمون، بازبینی مستقل و تا دو اصلاح. سپس 14 بررسی پنهان، که هیچ سازنده‌ای ندیده بود، بازی را از راه کنترل‌های خودش سنجید.

نوشتهٔ بابک بندپی

هر روش، میانگین دو اجرای آن

هزینه‌ی هر اجرا

ساخت اول اصلاح‌ها

بازی‌ها

هر بازی همان‌طور باز می‌شود که ساخته شده است. با کلیدهای W، A، S، D یا جهت‌نما حرکت کنید و با کلید Space شلیک کنید.

آنچه اجراها نشان دادند

هر اجرا از هر 14 بررسی پنهان گذشت، ولی بازبین هیچ‌کدام را نپذیرفت. در هر دور مورد تازه‌ای از حالت‌های مرزی هندسه پیدا می‌کرد، مثل گلوله‌ای که تانک را سطحی لمس می‌کند، یا تانکی که وقتی به دیوار چسبیده شلیک می‌کند. پس بررسی‌ها روش‌ها را از هم جدا نکردند؛ هزینه و زمان این کار را کردند.
Opus به‌تنهایی (E) ارزان‌ترین بود: میانگین 1.71 دلار برای هر اجرا، با ساخت‌های اول 7 و 12 دقیقه. Sonnet به‌تنهایی (A، همان روش امروز graph-loop) برای ساخت 19 و 24 دقیقه وقت گذاشت و هر اجرایش 2.08 دلار هزینه داشت.
واگذاری کار به کارگرهای Sonnet هزینه را بالاتر برد. Opus که Sonnet را هدایت می‌کرد (B، C، F) برای هر اجرا 2.30 تا 2.89 دلار خرج کرد، در برابر 1.71 دلار برای Opus به‌تنهایی، با همان نتیجه.
وقتی به Opus گفته شد کار را تقسیم کند و هر تعداد کارگر Haiku که لازم می‌داند راه بیندازد (G)، 3 و 4 کارگر راه انداخت، بیشتر برای نوشتن آزمون‌ها، و منطق بازی را خودش نوشت. سهم Haiku از هزینه 3 تا 5 سنت بود؛ هزینه‌ی این دو اجرا 1.91 و 2.28 دلار شد، نزدیک به Sonnet به‌تنهایی و بیشتر از Opus به‌تنهایی. در B، C و F، Opus هیچ‌وقت Haiku را انتخاب نکرد، و Sonnet با یک کارگر Haiku (D) هیچ کاری را واگذار نکرد.
در G دو چیز هم‌زمان عوض شد، مدل کارگر و متن دستور، پس از نتیجه‌اش نمی‌شود فهمید کدام‌یک اثر داشته. این دو اجرا بعد از بقیه و روی ماشینی خلوت‌تر انجام شدند، پس 18 و 22 دقیقه‌شان با بقیه قابل مقایسه نیست.
اجراها 386 تا 621 خط کد بازی و 234 تا 439 خط آزمون نوشتند. دو اجرای G، که آزمون‌هایشان را Haiku نوشت، از بیشترین آزمون‌ها را دارند: 439 و 399 خط.
ادامه دادن همان نشست برای اصلاح به صرفه بود: دو اصلاح به این شکل 0.13 تا 0.66 دلار هزینه داشت، و با یک نشست تازه که از بریف کوتاه شروع می‌شد (F)، 1.06 تا 1.28 دلار.
بعد از ساخت، بازبینی کندترین مرحله بود: 5 تا 9 دقیقه برای هر اجرا در سه دور.
نشستی که ادامه داده می‌شود مجموع در حال اجرای خود را گزارش می‌دهد، پس جمع زدن عددهای هر فراخوانی، فراخوانی‌های قبلی را دوباره می‌شمارد. عددهای این صفحه فقط چیزی را حساب می‌کنند که هر فراخوانی اضافه کرده، همان‌طور که بودجه‌ی خود graph-loop حساب می‌کند.

چگونه سنجیده شد

روش‌ها: A، Sonnet 5.5 به‌تنهایی می‌سازد (همان روش امروز graph-loop). B، Opus 5.5 کارگرهای Sonnet و Haiku را هدایت می‌کند و Sonnet اصلاح می‌کند. C، همان، با این فرق که Opus اصلاح می‌کند. D، Sonnet با یک کارگر Haiku می‌سازد. E، Opus به‌تنهایی می‌سازد. F، مثل C، با این فرق که هر اصلاح با یک نشست تازه‌ی Opus و یک بریف کوتاه شروع می‌شود، نه با ادامه‌ی نشست قبلی. G، Opus کار را تقسیم می‌کند و هر تعداد کارگر Haiku که لازم بداند راه می‌اندازد، چند تا هم‌زمان وقتی مرحله‌ها به هم وابسته نیستند، و خودش در همان نشست اصلاح می‌کند.
ساخت‌ها با میزان تلاش «زیاد»، اصلاح‌ها با «متوسط» و کارگرها با «خیلی زیاد» اجرا شدند. بازبین در همه‌ی اجراها یکی بود: gpt-6.1-sol با تلاش «متوسط».
بودجه‌ی Claude برای هر اجرا 10 دلار بود و حداکثر دو اصلاح. اجرایی که بازبین بعد از آخرین اصلاح هم رد کرده بود، باز هم به‌عنوان یک درخواست ادغام در graph-loop ساخته می‌شد، با یافته‌های بازبین پیوست.
دوازده اجرای اول (A تا F) هم‌زمان روی یک ماشین بودند و دو اجرای G بعداً، پس زمان‌های مجموعه‌ی آزمون بار آن را هم دارند.
ساختن یک بازی تازه با ویرایش‌های کوچکی که graph-loop معمولاً انجام می‌دهد فرق دارد. پس این نتیجه یکی از ورودی‌های تنظیم پیش‌فرض graph-loop است، نه پاسخ کامل.