تصور کنید یک برنامه‌نویس میان‌رده خطای یک حلقه را در ۵ دقیقه پیدا کند، اما یک عامل هوش مصنوعی برای همان کار ۴۵ دقیقه زمان و ده‌ها فراخوانی ابزار هزینه کند. برای روهیت، بنیان‌گذار Krova Cloud، یک خطای ساده «یک واحد بیشتر یا کمتر» (off-by-one error) در یک تابع صفحه‌بندی (Pagination) به درسی گران‌بها در اقتصاد هوش مصنوعی تبدیل شد.
این شکست نشان می‌دهد که نحوه پرداخت توسعه‌دهندگان برای هوش مصنوعی در حال تغییر است. در حالی که بسیاری به اشتراک‌های ماهانه عادت کرده‌اند که در آن زمانِ عامل رایگان به نظر می‌رسد، مدل‌های پرداخت به‌ازای توکن (Token) — مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — هر خواندن فایل و هر اجرای تست را به یک ردیف هزینه مستقیم در صورت‌حساب تبدیل می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی اینکه چگونه Google Cloud از Gemini برای کاهش زمان بررسی اسناد استفاده کرد اشاره کردیم، این مورد ثابت می‌کند که بهره‌وری در زمان همیشه به معنای بهره‌وری در هزینه نیست. این چالش با رتبه‌بندی عامل‌های کدنویس بر اساس هزینهٔ هر اصلاح همسو است که نشان می‌دهد نرخ موفقیت به تنهایی معیار مناسبی برای ارزیابی کارایی نیست.
زمینهٔ این شکست
تیم Krova Cloud بر اساس یک فرض کاری پیش می‌رفت که طبق آن، هزینه زمانِ عامل در حاشیه تقریباً صفر است. این طرز فکر برای ابزارهای اشتراکی با قیمت ثابت ماهانه جواب می‌داد و منطقی به نظر می‌رسید. اما این دیدگاه زمانی شکست خورد که آن‌ها با عامل‌های خودکاری مواجه شدند که در برابر یک صورت‌حساب واقعی API فعالیت می‌کردند.
در این محیطِ اندازه‌گیری‌شده (Metered Environment)، هر فراخوانی ابزار، هر خواندن فایل و هر اجرای مجدد مجموعه تست‌ها هزینه دارد. فرآیند عامل برای حل یک مسئله ساده، یک اثر هزینه‌ای ترکیبی و تصاعدی ایجاد کرد که در نهایت باعث شد بخش مالی شرکت در اسلک (Slack) سؤال بپرسد و متوجه این هزینه‌های غیرمنتظره شود. این اتفاق یادآور آسیب‌پذیری‌های بحرانی در پرداخت‌های عامل‌های هوش مصنوعی است که ریسک تخطی از بودجه را در سیستم‌های خودکار برجسته می‌کند.
جزئیات محرک‌های هزینه
به نقل از گزارش dev.to، هزینه این عامل از پیچیدگی باگ نبود، بلکه از یک فرآیند اجرای معیوب ناشی شد. سه مکانیزم خاص به‌صورت لایه‌لایه روی هم قرار گرفتند تا قیمت را بالا ببرند:
- بازخوانی بیش از حد زمینه: عامل بارها و بارها متن‌های بسیار بیشتری از حد نیاز را می‌خواند. هر فراخوانی ابزار، حجم زیادی از زمینه اطراف را دوباره ارسال می‌کرد. چون عامل به‌جای استدلال بر اساس یک مدل ذهنی، در حال اکتشاف بود، بسیار بیشتر از یک انسان ابزارها را فراخوانی کرد.
- فقدان قضاوت در تست: عامل بعد از هر تلاش برای اصلاح، کل مجموعه تست‌ها را اجرا می‌کرد. در حالی که یک انسان فقط سه تست مربوط به صفحه‌بندی را اجرا می‌کند، عامل از «پیش‌فرض امن» استفاده کرد و همه چیز را اجرا کرد، چون فاقد قضاوت لازم برای تشخیص این بود که کدام تست‌ها واقعاً مرتبط هستند.
- حلقه تکرار بی‌نهایت: عامل در یک چرخه «فرضیه-اصلاح-تست» گیر کرده بود. یک انسان بعد از دومین شکست، مکث می‌کرد تا تابع را واقعاً بخواند و تحلیل کند، اما عامل بدون اینکه بداند هزینه تکرار پنجم دقیقاً با تکرار اول برابر است، به تکرار ساده ادامه داد.
برای جلوگیری از سوختن بودجه در آینده، Krova Cloud سه حفاظ (Guardrails) فنی خاص را پیاده کرد:
- سقف بودجه سخت: سیستم اکنون محدودیت‌های دقیقی را قبل از شروع هر تسک اعمال می‌کند. به‌طور مشخص، از متغیرهای
MAX_TOOL_CALLS_PER_TASK = 15وMAX_COST_USD_PER_TASK = 2.00استفاده می‌کند. اگر ردیاب بودجه (budget_tracker) به این محدودیت‌ها برسد، سیستم دستورescalate_to_human(task, reason="cost budget exceeded")را صادر می‌کند تا موضوع به انسان ارجاع شود. - تأیید محدود: به‌جای اجرای کل مجموعه تست‌ها، عامل اکنون فقط تست‌هایی را اجرا می‌کند که از روی فایل‌های خاصی که واقعاً لمس کرده است، استنباط شده‌اند. این کار هزینه محاسباتی حلقه تأیید را به‌شدت کاهش می‌دهد.
- سندباکس‌های یک‌بارمصرف: اجرا به محیط‌های کوتاه‌مدت منتقل شد که هزینه آن‌ها به‌صورت دقیقه‌ای محاسبه می‌شود و دقیقاً برای اندازه آن تسک تنظیم شده‌اند. این محیط‌ها در لحظه‌ای که تسک به پایان برسد یا به سقف بودجه خود برسد، نابود می‌شوند.
این تغییر در زیرساخت یعنی هزینه‌ها اکنون با فعالیت واقعی مقیاس می‌شوند، نه به‌عنوان یک هزینه ثابت (Flat Overhead). برای شما این یعنی رویکرد «بگذار مدل امتحان کند» اکنون یک ریسک مالی است. عاملی بدون سقف بودجه، تا ابد تکرار می‌کند چون قضاوت انسانی برای درک این نکته را ندارد که چه زمانی هزینه یک تسک از ارزش آن بیشتر می‌شود.
در دنیای حرفه‌ای، این موضوع تعریف «اپراتور ارشد» هوش مصنوعی را تغییر می‌دهد. هدف دیگر فقط مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — نیست، بلکه مهندسی محدودیت‌هایی است که مانع از خرج کردن ۱۰ دلار برای حل یک مسئله ۱ دلاری شود. واکنش درست به عاملی که بودجه‌اش تمام شده، بالا بردن سقف نیست، بلکه پذیرفتن این واقعیت است که تسک نیاز به شهود انسانی دارد؛ درست مثل وقتی که با یک برنامه‌نویس انسانی مواجه می‌شوید که سه ساعت روی یک باگ گیر کرده است. این عدم تعادل در هزینه و ارزش، در بلندمدت می‌تواند منجر به وضعیتی شود که هزینهٔ نگهداری کدهای تولیدشده توسط هوش مصنوعی در ماه‌های بعد از توسعه به‌شدت جهش کند.
توسعه‌دهندگان باید اکنون گران‌ترین تسک‌های عامل خود را بازرسی کنند تا این «حلقه‌های بی‌نهایت» را قبل از تبدیل شدن به هزینه‌های تکراری شناسایی کنند. می‌توانید همین امروز با پیاده کردن یک پوشش ردیاب هزینه (Cost-tracker wrapper) ساده دور حلقه فراخوانی ابزارهای عامل خود شروع کنید. برای داستان‌های بیشتر درباره عیب‌یابی عمیق، روهیت به‌طور منظم در debugly.dev می‌نویسد.
گام بعدی شما
- برای تمام عامل‌های خود سقف هزینه (Hard Budget Cap) به‌ازای هر تسک تعریف کنید.
- منطق اجرای تست‌ها را از «اجرای کامل» به «اجرای هدفمند» بر اساس فایل‌های تغییریافته تغییر دهید.
- یک سیستم هشدار (Alert) برای شناسایی تکرارهای بیش از حد در یک بازه زمانی کوتاه طراحی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو