«بودجه‌بندی ابزارها»؛ راهکاری برای توقف حلقه‌های تکرار گران‌قیمت در LLM

تصور کنید یک برنامه‌نویس ابزاری ساخته که باید ایمیل‌های تاییدیه را بخواند، اما یک غلط املایی ساده در آدرس ایمیل کاربر، کل سیستم را به یک چرخه تکرار بی‌‌پایان و هزینه‌بر تبدیل می‌کند. این دقیقاً همان نقطه‌ای است که بسیاری از عامل‌های هوش مصنوعی که در محیط دمو عالی عمل می‌کنند، در دنیای واقعی و هنگام مواجهه با یک غلط املایی در ایمیل کاربر یا تأخیر در پاسخ API، شکست می‌خورند.

به نقل از راهنمای فنی منتشر شده در dev.to در ۱۵ اکتبر ۲۰۲۶، کلید حل این مشکل در تبدیل بودجه‌های ابزار به «قراردادهای مرئی» است. این رویکرد اجازه نمی‌دهد عامل‌ها هنگام مواجهه با خطا، منابع سیستم را به طور نامحدود ببلعند و از مصرف بی‌رویه منابع در حلقه‌های شکست جلوگیری می‌کند.

بسیاری از توسعه‌دهندگان تصور می‌کنند چالش اصلی، انتخاب ابزار درست توسط مدل است؛ اما ریسک واقعی در محیط عملیاتی، هزینه هر فراخوانی است. همان‌طور که پیش‌تر بررسی کردیم که چگونه VIDRAFT با استفاده از NPUهای استنتاج-محور برای مدیریت محدودیت‌های محاسباتی، پیش‌آموزش LLM را بهینه کرد، لایه عامل‌محور (Agentic Layer) به نوع متفاوتی از انضباط نیاز دارد: اجرای سخت‌گیرانه بودجه در زمان اجرا (Runtime Budget Enforcement).

مشکل: ابزارهایی بدون بودجه

یک عامل هوش مصنوعی را تصور کنید که در حال ایجاد یک حساب کاربری آزمایشی است و منتظر دریافت ایمیل تاییدیه می‌ماند. گردش کار (Workflow) مسیر مشخصی را دنبال می‌کند: مدل $\rightarrow$ ایجاد هویت $\rightarrow$ انتظار برای اینباکس $\rightarrow$ خواندن کد $\rightarrow$ تایید نتیجه. اگر اینباکس کند باشد، مدلی که هیچ محدودیتی ندارد ممکن است هر ۲۰۰ میلی‌ثانیه یک بار سرویس را چک کند (Polling). این رفتار ساده، یک وظیفه ارزان را به زنجیره‌ای از فراخوانی‌های تکراری، گران و زائد تبدیل می‌کند.

خطاهای خاص کاربر می‌توانند این حلقه‌ها را تحریک کنند. برای مثال، ورودی‌هایی مانند "fake e mail com" یا دامنه‌های اشتباه مانند "temp gamil com" نباید باعث تبدیل یک جریان کاری به توالی گران‌قیمتی از فراخوانی‌ها شوند. در نبود محدودیت‌های محلی، سه نشانه (Symptom) بحرانی ظاهر می‌شود: اول، افزایش شدید تأخیر کلی (Total Latency) علی‌رغم اینکه هر فراخوانی به تنهایی زمان معقولی می‌برد؛ دوم، شکست‌های پنهان در قراردادها که منجر به تکرار اثرات جانبی (Side Effects) می‌شود؛ و سوم، ناتوانی در ردیابی اینکه هزینه‌ها ناشی از مدل است، ارائه‌دهنده خارجی است یا مکانیزم نظارت (Polling). در همین راستا، بهینه‌سازی تأخیر در پاسخ‌دهی مدل‌ها اهمیت ویژه‌ای دارد، مشابه آنچه در کاهش تأخیر پرس‌وجوهای Postgres توسط مدل Qwen 4B مشاهده شد.

بودجه به مثابه یک قرارداد

برای حل این مشکل، نویسنده ساختار «قرارداد بودجه» را پیشنهاد می‌کند. در این مدل، یک بودجه کلی برای کل تسک (مثلاً ضرب‌الاجل ۶۰۰۰۰ میلی‌ثانیه، حداکثر ۸ فراخوانی ابزار و سقف هزینه ۰.۰۴ دلار) تعریف می‌شود که با محدودیت‌های محلی هر ابزار جفت می‌گردد. ارزش این کار در اعداد دقیق نیست، بلکه در اعلام این محدودیت‌ها پیش از اجراست تا آداپتور (Adapter) — لایه‌ای که مثل یک مترجم بین مدل و ابزار عمل می‌کند — بتواند درخواست‌ها را در صورت اتمام بودجه رد کند.

ساختار نمونه این قرارداد به شرح زیر است:

• بودجه کلی (Global Budget): deadline_ms: 60000 ، max_tool_calls: 8 ، max_estimated_cost: 0.04.
• ایجاد حساب (create_test_account): timeout_ms: 5000 ، max_attempts: 1.
• خواندن اینباکس (read_inbox): timeout_ms: 8000 ، max_attempts: 3.
• تایید کد (confirm_code): timeout_ms: 5000 ، max_attempts: 1.

در این ساختار، تایم‌اوت‌های محلی باید به ضرب‌الاجل کلی احترام بگذارند. اگر سه ابزار هر کدام ۶۰ ثانیه زمان مصرف کنند در حالی که کل تسک محدودیت یک دقیقه‌ای دارد، سیستم شکست می‌خورد. پاسخ آداپتور باید صریح باشد: ok (موفق)، timeout (اتمام زمان)، budget_exhausted (اتمام بودجه) یا unknown (نامشخص). وضعیت unknown برای عملیاتی که اثرات جانبی دارند حیاتی است، زیرا اتمام زمان (Timeout) ثابت نمی‌کند که سرور دستور را اجرا نکرده است.

چارچوب پیاده‌سازی

مدیریت موثر بودجه بر چهار نقطه بازرسی (Checkpoint) خاص متکی است:

• اجرای محدودیت (Limit Enforcement): سیستم باید به محض اینکه deadline_remaining_ms به صفر رسید، فراخوانی‌ها را فوراً رد کند.
• اندازه‌گیری دقیق (Precise Measurement): هر تلاش باید زمان شروع، زمان پایان و بودجه باقی‌مانده را ثبت (Log) کند.
• طبقه‌بندی خطا (Error Classification): سیستم باید بین خطاهای قابل تکرار (Retryable)، شکست‌های قطعی (مانند دامنه‌های نامعتبر) و وضعیت‌های «نامشخص» تمایز قائل شود.
• تست استرس (Stress Testing): توسعه‌دهندگان باید تأخیرهای بالا، پاسخ‌های دیرهنگام، ورودی‌های نامعتبر و تکرارها را شبیه‌سازی کنند تا مطمئن شوند بودجه به درستی اعمال می‌شود.

برای حفظ شفافیت و قابلیت مشاهده (Visibility)، این راهنما پیشنهاد می‌کند به‌جای ذخیره یک کپی کامل از پرامپت، یک «رسید» (Receipt) برای هر تلاش ذخیره شود. این رسید شامل موارد زیر است: شناسه اجرا (run_id مانند "agent_91a")، شناسه فراخوانی ابزار (tool_call_id مانند "call_04")، نام ابزار، شماره تلاش، مقدار deadline_remaining_ms و هش ورودی (input_hash). این داده‌ها به اپراتورها اجازه می‌دهد به سوالات عملیاتی پاسخ دهند: آیا زمان قبل از ارسال پرس‌وجو تمام شد؟ چند تلاش برای نظارت (Polling) استفاده شد؟ کدام ابزار بودجه را تخلیه کرد؟

قوانین عملیاتی برای زمان و تکرارها

برای بهینه‌سازی زمان اجرا، نویسنده سه قانون اولیه را پیشنهاد می‌کند:
۱. رزرو زمان برای خروجی: اگر ابزارها تمام زمان ضرب‌الاجل را مصرف کنند، عامل نمی‌تواند نتیجه را برای کاربر توضیح دهد.
۲. عدم تکرار برای خطاهای اعتبارسنجی: یک کد بدساخت یا دامنه نامعتبر با تکرار تلاش بهبود نمی‌یابد.
۳. نظارت پیش‌رونده (Progressive Polling): بهتر است پرس‌وجوها در فواصل ۱، ۲ و ۴ ثانیه انجام شوند تا اینکه هر ۲۰۰ میلی‌ثانیه به اینباکس ضربه زده شود.

برای اقداماتی که منابع ایجاد می‌کنند (مانند ساخت حساب)، نویسنده بر استفاده از کلیدهای Idempotency یا بررسی وضعیت (State) پیش از اجرا تأکید می‌کند. اگر هیچ‌کدام ممکن نباشد، بازگرداندن وضعیت unknown صادقانه‌تر از ادعای شکست است. یک ماتریس معماری ساده کمک می‌کند: «مشاوره با اینباکس» اجازه تکرارهای محدود با شواهد پیام/تایم‌اوت را می‌دهد؛ «ایجاد حساب» فقط تکرارهای Idempotent با یک ID خارجی را می‌پذیرد؛ و «تایید کد» عموماً هیچ تکراری را نمی‌پذیرد و بر وضعیت نهایی تمرکز دارد.

این تغییر، قدرت و مرجعیت را از پرامپت به زمان اجرا (Runtime) منتقل می‌کند. در حالی که یک مدل ممکن است پیشنهاد دهد «کمی بیشتر منتظر بمانیم»، آداپتور ابزار به‌عنوان مرجع نهایی عمل کرده و اگر منابع تمام شده باشد، درخواست را رد می‌کند. این تضمین می‌کند که عامل همیشه زمان کافی برای توضیح نتیجه نهایی به کاربر را دارد، نه اینکه در میانه جمله دچار تایم‌اوت شود.

این رویکرد، فرض بنیادی درباره قابلیت اطمینان عامل‌ها را تغییر می‌دهد. یک عامل قابل اعتماد، عاملی نیست که به هر قیمتی بر رسیدن به نتیجه اصرار ورزد، بلکه عاملی است که دقیقاً بداند چه زمانی باید متوقف شود. با تبدیل زمان و هزینه به یک قرارداد، توسعه‌دهندگان می‌توانند مدل‌های زیرساختی را بدون از دست دادن کنترل روی هزینه‌های عملیاتی تعویض کنند. برای مثال، استفاده از مدل‌های بهینه‌شده‌ای که هزینه‌های میانگین را به شدت کاهش داده‌اند، مانند Claude Haiku 5.5، در کنار این قراردادها می‌تواند بهره‌وری سیستم را دوچندان کند.

گام بعدی شما

• در کدهای خود، لایه آداپتور را از لایه تصمیم‌گیری مدل جدا کنید تا بتوانید محدودیت‌های سخت‌گیرانه اعمال کنید.
• برای هر ابزار، یک max_attempts تعریف کنید تا از حلقه‌های تکرار در صورت بروز خطای ۴۰۴ یا ۴۰۰ جلوگیری شود.
• سیستم لاگینگ خود را به‌گونه‌ای تغییر دهید که «بودجه باقی‌مانده» را در هر مرحله ثبت کند.

اما مدیریت این هزینه‌ها تنها بخشی از ماجراست؛ برای درک اینکه چگونه مدل‌های کوچک‌تر می‌توانند هزینه استنتاج را به شدت کاهش دهند، تحلیل ما درباره مدل‌های SLM را بخوانید.