رتبه‌بندی عامل‌های کدنویس بر اساس هزینهٔ هر اصلاح؛ فراتر از نرخ موفقیت

تصور کنید یک عامل کدنویس ۶۲.۵٪ از تسک‌ها را حل می‌کند اما برای هر مورد، ده‌ها بار در حلقه‌های تکراری می‌افتد؛ در مقابل، عاملی دیگر ۵۷.۵٪ موفقیت دارد اما هر بار در اولین تلاش جواب را می‌گیرد. در دنیای واقعی، دومی برای جیب و زمان شما ارزشمندتر است، اما در اسلایدهای تبلیغاتی شرکت‌ها، اولی به عنوان برنده معرفی می‌شود. این شکاف کارایی معمولاً در گزارش‌های شرکتی که فقط «نرخ موفقیت» (Pass Rate) را اعلام می‌کنند، پنهان می‌ماند. نرخ موفقیت فقط می‌گوید آیا یک مجموعه تست در نهایت سبز شد یا خیر، اما به این نمی‌پردازد که برای رسیدن به آن سبز شدنِ تست‌ها، چه مقدار منابع سوزانده شده است.

یک سناریوی دقیق را در نظر بگیرید: عامل A نرخ موفقیت ۶۲.۵ درصد و عامل B نرخ ۵۷.۵ درصد را ثبت می‌کند. در اسلایدها، عامل A برنده است. اما وقتی به صورت‌حساب‌ها، ساعات مصرف GPU یا تأخیرهای صف (Queue delays) نگاه می‌کنید، داستان تغییر می‌کند. عامل A احتمالاً تست‌رانر را در یک حلقه تکرار کرده و یک فایل را سه بار بازنویسی کرده است و حتی در نهایت باز هم به یک ادغام (Merge) انسانی نیاز داشته است. در مقابل، عامل B تسک‌های بیشتری را شکست خورده است، اما هر جا که موفق شده، این کار را در یک مرحله (Single shot) انجام داده است. اگر شما فقط نرخ موفقیت را منتشر کنید، در واقع یک «بروشور تبلیغاتی» چاپ کرده‌اید، نه یک گزارش فنی.

ارزیابی عامل‌های هوش مصنوعی (AI Agents) — شبیه به استخدام کارمندی است که فقط نتیجه نهایی را می‌بینید اما نمی‌دانید برای یک گزارش ساده، کل شب را بیدار مانده یا در ۱۰ دقیقه آن را نوشته است — پیش از این بر پایه درصد صحت بود. اما با تبدیل شدن چت‌های ساده به کدنویسی خودکار، هزینه هر «موفقیت» به‌شدت متغیر شده است. یک عامل ممکن است یک فایل واحد را سه بار بازنویسی کند یا ده‌ها فراخوانی ابزار (Tool calls) غیرضروری را فعال کند تا در نهایت تست را پاس کند، در حالی که عاملی دیگر همان نتیجه را با کمترین مصرف توکن به دست می‌آورد. ادعاهای رایجی وجود دارد که می‌گوید عامل‌های کدنویس در حال حاضر از اکثر برنامه‌نویسان پیشی گرفته‌اند. این ادعاها باید «غیرقابل اعتماد» تلقی شوند تا زمانی که پروتکل ارزیابی، واحد هزینه و میزان عدم قطعیت (Uncertainty) را به طور شفاف نشان دهد.

به نقل از راهنمای فنی منتشر شده در dev.to در ۱۱ سپتامبر ۲۰۲۶، تکیه بر نرخ موفقیت به عنوان تنها معیار، در واقع «رتبه‌بندی بر اساس حس و حال» (Ranking Vibes) است. برای رسیدن به یک دفتر کل واقعی و مستند، توسعه‌دهندگان باید واحد هزینه و عدم قطعیت نتیجه را ردیابی کنند. این امر مستلزم آن است که اگر مسائل مالی اهمیت دارند، جداول قیمت (Price tables) تثبیت شوند و حتی زمانی که صورت‌حساب صفر است، تعداد توکن‌ها و زمان واقعی (Wall-clock time) ثبت گردند. توکن‌ها و ثانیه‌ها حتی در نقاط دسترسی رایگان (Free endpoints) نیز منابع کمیاب محسوب می‌شوند. در همین راستا، برخی ابزارها توانسته‌اند با بهینه‌سازی مصرف توکن، هزینه‌های عملیاتی را تا ۴۰٪ کاهش دهند که نشان‌دهنده تأثیر مستقیم مدیریت توکن بر صرفه اقتصادی است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی هزینه‌های استنتاج اشاره کردیم، شفافیت در مصرف منابع، مرز بین ابزارهای کاربردی و اسباب‌بازی‌های گران‌قیمت است.

پروتکل دفتر کل (The Ledger Protocol)

برای جلوگیری از انحراف در ارزیابی، این پروتکل یک فرمت ثبت سخت‌گیرانه با فایل‌های JSONL را الزامی می‌کند. به جای شروع با داشبوردهای گرافیکی، باید برای هر تلاش در هر تسک، یک ردیف داده ثبت شود. هر تک تلاش برای هر تسک باید به عنوان یک ردیف ثبت گردد. اگر هر یک از فیلدها مفقود باشد، رتبه‌بندی نامعتبر تلقی می‌شود. هر ردیف باید شامل موارد زیر باشد:

• run_id و agent_id برای ردیابی دقیق هر اجرا و هر عامل.
• task_id و seed (بذر) برای تضمین بازتولیدپذیری (Reproducibility) نتایج.
• resolved: یک مقدار بولی (True/False) که توسط یک بررسی‌کننده (Checker) ثابت تعیین شود، نه بر اساس گزارش خودِ مدل از موفقیتش. این تفکیک بین گزارش مدل و واقعیت، یادآور شکاف تشخیص صحت در عامل‌های مرورگر است که در آن مدل‌ها اغلب تصور می‌کنند تسک را با موفقیت به پایان رسانده‌اند در حالی که در واقعیت چنین نیست.
• prompt_tokens و completion_tokens برای اندازه‌گیری دقیق کل محاسبات مصرف شده.
• tool_calls برای ردیابی میزان فعالیت و تعداد دفعات استفاده از ابزارها توسط عامل.
• wall_ms: زمان واقعی سپری شده به میلی‌ثانیه، که در خارج از استریم فروشنده اندازه‌گیری شده باشد.
• price_table_id: ارجاع به نرخ‌های هزینه خاصی که در زمان اجرای آن تست اعمال شده است.
• notes: فیلدی برای ثبت موارد خاص مانند ادغام‌های انسانی، تست‌های نادیده گرفته شده یا کرش‌های سیستم ارزیابی (Harness crashes).

عبور از نرخ موفقیت

پس از تکمیل دفتر کل، سه معیار حیاتی برای هر عامل استخراج می‌شود. نرخ موفقیت (Resolved rate) همچنان مفید است، اما به تنهایی کافی نیست. هزینه پولی باید به عنوان یک ستون مشتق‌شده از طریق ضرب تعداد توکن‌ها در جدول قیمت تثبیت‌شده محاسبه شود. بسیار حیاتی است که نرخ‌های قیمتی ماه مارس با اجراهای ماه سپتامبر ترکیب نشوند. معیارهای اصلی برای تعیین برنده در حالت‌های برابر (Tie-breaking) عبارت‌اند از:

• نرخ موفقیت: تعداد تسک‌های سبز تقسیم بر کل تسک‌ها.
• توکن به‌ازای هر موفقیت (TPR): کل توکن‌های مصرفی تقسیم بر تعداد تسک‌های موفق. اگر تعداد موفقیت‌ها صفر باشد، عامل TPR ندارد چون کل مجموعه را شکست خورده است. این معیار «دست‌وپا زدن» (Thrashing) مدل را جریمه می‌کند؛ یعنی وقتی عاملی هزاران توکن مصرف می‌کند تا در نهایت یک تسک را حل کند.
• ثانیه به‌ازای هر موفقیت (SPR): کل زمان واقعی (Wall-clock) تقسیم بر تسک‌های موفق.
• پول به‌ازای هر موفقیت: معیاری اختیاری که تنها پس از تثبیت price_table_id به نتایج اضافه می‌شود.

حل مشکل نویز آماری

نمونه‌های کوچک اغلب منجر به شکاف‌های گمراه‌کننده می‌شوند. برای مثال، تفاوت سه درصدی در ۴۰ تسک، یا شکاف ۱۵ درصدی در ۴ تسک، اغلب صرفاً نویز آماری است. برای حل این مشکل، پروتکل از روش بازه بوت‌استرپ (Bootstrap Interval) استفاده می‌کند. با نمونه‌برداری مجدد از داده‌ها (به عنوان مثال، ۲۰۰۰ دور با یک بذر مشخص)، توسعه‌دهندگان می‌توانند یک بازه اطمینان ۹۵٪ برای نرخ موفقیت ایجاد کنند.

اگر بازه‌های اطمینان دو عامل با هم هم‌پوشانی (Overlap) داشته باشند، برنده نرخ موفقیت مشخص نیست. در این موارد، برنده توسط TPR تعیین می‌شود. اگر شکاف TPR در محدوده ۱۰٪ باشد، نتیجه «مساوی» اعلام می‌شود. این باند ۱۰ درصدی یک انتخاب سیاستی است که باید در پروتکل قفل شود و نباید بعد از دیدن نمودارها تغییر کند. برای اطمینان از عدم انحراف، قوانین تعیین برنده باید در یک اجرای آزمایشی روی لپ‌تاپ (مانند یک مجموعه pytest) قفل شوند تا تایید گردد که هم‌پوشانی بازه‌ها به درستی منجر به نتیجه «بدون برنده نرخ» می‌شود.

محاسبه اتلاف‌ها

یکی از بحث‌برانگیزترین نقاط در ارزیابی عامل‌ها، نحوه برخورد با تلاش‌های شکست‌خورده است. متد پیشنهادی، تمام توکن‌ها — از جمله توکن‌های مربوط به تسک‌های شکست‌خورده — را در صورت کسر برای محاسبه TPR قرار می‌دهد. این کار تضمین می‌کند که یک عامل نویزدار و ناکارآمد، صرفاً به این دلیل که تسک‌های موفقش کوتاه بوده‌اند، «ارزان» به نظر نرسد. اگر شما فقط توکن‌های تسک‌های موفق را تقسیم کنید، در واقع در حال رتبه‌بندی «شانس» هستید. گنجاندن اتلاف‌ها تنها راه برای محاسبه هزینه واقعی عملیات عامل است. برای جلوگیری از چنین اتلاف‌هایی و تضمین کیفیت خروجی، می‌توان از سیستم‌های اعتبارسنجی چندلایه استفاده کرد تا از تخریب کد در محیط تولید جلوگیری شود.

حفاظ‌های اجرایی

برای جلوگیری از «نمایش سهمیه» (Quota theater) و آلودگی داده‌های تأخیر (Latency contamination)، راهنما توصیه می‌کند که این سیستم‌های ارزیابی روی یک کلید API مجزا از محیط تولید اجرا شوند. ترافیک ارزیابی که سهمیه پولی خود را با کاربران واقعی به اشتراک می‌گذارد، هم صورت‌حساب و هم ستون تأخیر را آلوده می‌کند. استفاده از یک سرور رایگان، مانند سرویس‌های MonkeyCode، اجازه می‌دهد توکن‌های ارزیابی بدون اثرگذاری بر ترافیک مشتریان یا ستون‌های تأخیر تولید، مصرف شوند. یک سرور رایگان برای مقیاس ۴۰ تسک و یک پروسه دارای دیسک برای ذخیره JSONL کافی است.

با این حال، پروتکل نسبت به چند تله رایج هشدار می‌دهد:

• اندازه نمونه: برای رتبه‌بندی فروشندگان از بسته‌های ۴ تسکی استفاده نکنید. اگر N < 30 باشد، نتایج باید به عنوان «یادداشت‌های اکتشافی» برچسب بخورند، نه رتبه‌بندی فروشنده.
• مقایسه انسانی: روش بوت‌استرپ روی تسک‌ها جایگزینی برای مطالعه انسانی روی داده‌های کنار گذاشته شده (Held-out) نیست. شما نمی‌توانید بدون یک پروتکل انسانی ادعا کنید که مدلی «بهتر از اکثر برنامه‌نویسان» است.
• برابری محیط: مقایسه یک بررسی‌کننده محلی ۷ ثانیه‌ای با یک عامل ابری که در صف انتظار است و سپس ادعای پیروزی در تأخیر، نادرست است. زمان واقعی در سرورهای رایگان نوسان دارد؛ بنابراین SPR را به عنوان یک فیلتر کلی در نظر بگیرید، نه یک بنچ‌مارک دقیق (Microbenchmark).
• ثبات: اگر نمی‌توانید بررسی‌کننده را تثبیت کنید، اگر طرح ابزارها (Tool schemas) بین عامل‌ها تغییر می‌کند، یا اگر یک عامل دسترسی شبکه دارد و دیگری ندارد، این متد را رها کنید.

جدول تصمیم‌گیری برای گزارش‌دهی

برای حفظ اعتبار، پروتکل این جدول سخت‌گیرانه را برای آنچه مجاز است چاپ شود، پیشنهاد می‌کند:

• هم‌پوشانی بازه‌ها + شکاف TPR > ۱۰٪: چاپ «مساوی در نرخ؛ عامل B برای هر اصلاح ارزان‌تر است». هرگز ننویسید «B بدتر است».
• هم‌پوشانی بازه‌ها + شکاف TPR ≤ ۱۰٪: چاپ «مساوی». هیچ عنوانی (تاج برنده) چاپ نکنید.
• جدا بودن بازه‌ها + نرخ بالاتر با TPR بالاتر: چاپ «برنده نرخ، با هشدار هزینه». هرگز ننویسید «به طور مطلق بهتر است».
• جدا بودن بازه‌ها + نرخ بالاتر با TPR پایین‌تر: چاپ «برنده نرخ و هزینه».
• عدم تثبیت جدول قیمت: فقط چاپ توکن و ثانیه. هرگز رتبه‌بندی دلاری چاپ نکنید.
• عدم تثبیت بررسی‌کننده: هیچ داده‌ای چاپ نکنید.

این تغییر در اندازه‌گیری، فرض بنیادی بنچ‌مارک‌های عامل‌محور را عوض می‌کند: هدف از «آیا می‌تواند کار را انجام دهد؟» به «انجام قابل‌اعتماد این کار چقدر هزینه دارد؟» تغییر می‌یابد. برای توسعه‌دهنده، این تفاوت بین ابزاری است که زمان می‌بخشد و ابزاری که یک صورت‌حساب مخفی و عظیم GPU ایجاد می‌کند. برای معتبر بودن، هر پست یا گزارش باید دفتر کل (Ledger)، اسکریپت و قانون هم‌پوشانی را ضمیمه کند. اگر خواننده نتواند رتبه‌بندی را از روی فایل JSONL بازتولید کند، شما یک عدد ندارید — شما فقط یک اسلاید دارید.

گام بعدی شما

• اگر در حال ارزیابی مدل‌های مختلف برای کدنویسی هستید، از این به بعد به جای Pass Rate، معیار TPR (توکن به‌ازای هر موفقیت) را محاسبه کنید.
• برای هر تست، یک فایل JSONL شامل زمان واقعی (Wall-clock) و تعداد توکن‌ها ایجاد کنید تا اثر نویز آماری را حذف کنید.
• از سرورهای ایزوله برای ارزیابی استفاده کنید تا تأخیرهای شبکه روی نتایج بنچ‌مارک شما اثر نگذارد.

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