تصور کنید یک عامل هوش مصنوعی برای حل یک باگ ساده، ده بار تلاش می‌کند و هر بار توکن‌های گران‌قیمت را می‌سوزاند تا در نهایت به جواب برسد؛ در دنیای واقعی، این یک پیروزی نیست، بلکه یک فاجعه‌ی مالی است. شکاف عمیقی میان هوش خام یک مدل و عملکرد واقعی آن در محیط تولید وجود دارد و نقطه شکست معمولاً نبودِ نظم عملیاتی و مالی است.
برای حل این مشکل، Supabase در ۲ آگوست ۲۰۲۶ ابزار supabase/evals را به‌صورت متن‌باز عرضه کرد. این محک (Benchmark) — ابزاری برای اندازه‌گیری دقیق توانایی مدل‌ها — عامل‌هایی نظیر Claude Code، Codex و OpenCode را در مواجهه با وظایفی واقعی، با استفاده از ابزارهای خط فرمان (CLI) و محیط‌های کانتینری‌شده می‌سنجد. این ابزار در واقع تکامل یافته‌ی رویکرد Supabase برای سنجش عامل‌های هوش مصنوعی در محیط‌های واقعی است که هدفش خروج از فضای تئوریک و ورود به چالش‌های عملیاتی است.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی هزینه‌های استنتاج اشاره کردیم، بسیاری از توسعه‌دهندگان موفقیت یک عامل (Agent) — سیستمی که می‌تواند به‌طور مستقل تصمیم بگیرد و ابزارها را اجرا کند — را به‌صورت صفر و یک می‌بینند. اما این نگاه، «مالیات پنهان» توکن‌های تلف‌شده و حلقه‌های تکرار بی‌پایان را نادیده می‌گیرد. طبق گزارش dev.to، این چارچوب ارزیابی سه محدودیت سخت‌گیرانه را برای شبیه‌سازی واقعیت‌های محیط تولید پیاده کرده است:
- سقف سخت‌گیرانه‌ی تلاش مجدد: سیستم تنها یک بار اجازه تلاش مجدد می‌دهد. این کار مانع از آن می‌شود که عامل‌ها با سوزاندن توکن‌های زیاد، ناکارآمدی خود را بپوشانند.
- بهینگی فراخوانی ابزار: داده‌ها نشان می‌دهد Claude Code به‌طور میانگین ۲ بار مستندات را خوانده است، در حالی که Codex ۸ بار این کار را کرده است. هر دو به جواب رسیدند، اما Codex حجم بسیار بیشتری از پنجره‌ی زمینه را اشغال کرد.
- بهینه‌سازی توصیفات: Supabase مشاهده کرد که تنها با بازنویسی توصیف یک مهارت داخلی، نرخ فعال‌سازی آن از ۱۰٪ به ۶۰٪ رسید، بدون آنکه کدی تغییر کند.
این تغییر رویکرد نشان می‌دهد که برای یک توسعه‌دهنده، «بهترین» مدل دیگر آن نیست که بالاترین امتیاز را در جدول‌های رتبه‌بندی دارد. برنده واقعی مدلی است که کار را با کمترین تعداد فراخوانی ابزار و پایین‌ترین هزینه استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه به خودِ آشپزی به جای دوره‌ی آموزش — به پایان برساند. این محک در واقع یک تمرین آکادمیک را به یک مسئله‌ی حسابداری هزینه تبدیل کرده است.
اگر در حال ساخت گردش‌کارهای عامل‌محور هستید، بودجه‌ی تلاش مجدد را به‌عنوان یک محدودیت درجه‌یک در نظر بگیرید، نه یک جزئیات پیاده‌سازی. کسانی که این محدودیت‌ها را نادیده بگیرند، احتمالاً نتیجه را تنها پس از دریافت یک صورت‌حساب فاجعه‌بار از سرویس‌های ابری کشف خواهند کرد.
گام بعدی شما
- دستور
supabase evalرا روی مخازن (Repositories) خود اجرا کنید تا نقاط ضعف مدل‌هایتان را شناسایی کنید. - توصیفات ابزارهای داخلی مدل خود را بازنویسی کرده و اثر آن را بر نرخ فعال‌سازی بسنجید.
- برای هر تسک، یک سقف توکن یا تعداد دفعات تلاش مجدد (Retry Cap) تعریف کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو