ما یک سقف اعتبار ۱۰۰ دلاری برای ناوگان ۱۰ عامل هوش مصنوعی خود تعیین کردیم و همان روز محدودکننده (throttle) فعال شد و تمام وظایف جدید را تا زمانی که سقف را افزایش ندادیم، متوقف کرد. این حادثه نشان میدهد که وقتی بودجه نقض شد، حلقه کنترل بلافاصله وارد عمل شد.
چرا سقف اعتبار برای ناوگانهای هوش مصنوعی اهمیت دارد
اجرای ده عامل خودمختار روی یک سرور واحد، جریان مداومی از فراخوانیهای API ایجاد میکند که هر کدام بر اساس تعداد توکنهای مصرفی محاسبه میشوند. لاگهای سنتی آنچه را که عاملها انجام دادهاند (پرسوجوها، پاسخها، برچسبهای زمانی) ثبت میکنند، اما چیزی درباره هزینه آن اقدامات نمیگویند. وقتی یک ناوگان مقیاس میگیرد، آن صورتحساب نامرئی میتواند منفجر شود و بودجه را پیش از آنکه کسی متوجه شود، تخلیه کند.
تبدیل لاگها به یک دفتر کل
اولین قدم ما این بود که از برخورد با لاگها به عنوان متن ساده دست برداریم و با آنها مانند یک دفتر کل مالی رفتار کنیم. هر چرخه عامل — task → taking → done — اکنون سه ورودی دفتر روزنامه تولید میکند:
- Money (پول) – یک ارزش دلاری برآوردی که از تعداد توکنهای درخواست به دست میآید.
- Promises (تعهدات) – وظایف باز که نشاندهنده یک بدهی معوق هستند، یعنی کارهایی که پس از تکمیل، هزینه آنها محاسبه خواهد شد.
- Labour (نیروی کار) – واحدهای کار واقعی که عامل انجام داده است.
به جای جستجو کردن در یک فایل لاگ برای عبارت “error”، اکنون میتوانیم یک پرسوجوی مالی واقعی اجرا کنیم: “تمام تعهداتی را نشان بده که مجموع پول آنها از ۱۰۰ دلار فراتر میرود.” دفتر کل، هزینههای پنهان را قابل مشاهده و قابل جستجو میکند.
سیستم کنترل حلقه بسته
مکانیسم سقف اعتبار از یک حلقه چهار مرحلهای پیروی میکند که به طور مداوم اجرا میشود:
- Measure (اندازهگیری) – هر نوبت عامل، خطی را به لاگ هزینهها اضافه میکند که میزان استفاده از توکن و مبلغ دلاری مشتق شده را ثبت میکند.
- Price (قیمتگذاری) – سیستم تعداد توکنها را با استفاده از نرخ فعلی به دلار تبدیل میکند.
- Alert (هشدار) – یک مانیتور، بودجه در حال گردش را زیر نظر میگیرد. وضعیت آن از none (بدون هشدار) به warn (نزدیک شدن به سقف) و سپس به cap (رسیدن به سقف) تغییر میکند.
- Throttle (محدودسازی) – دروازه (gate) وضعیت فعلی را میخواند و زمانی که وضعیت به cap برسد، از ارسال هرگونه وظیفه جدید جلوگیری میکند.
پنجره بودجه یک دوره پنج ساعته متحرک است، به این معنی که سیستم همیشه به پنج ساعت اخیر هزینهها نگاه میکند، نه یک بازه زمانی ثابت تقویمی. این کار باعث میشود حلقه نسبت به فورانهای فعالیت پاسخگو باشد و از قفل شدن دائمی ناوگان توسط یک جهش ناگهانی جلوگیری میکند.
داشبوردی که صرفاً هزینهها را نمایش میدهد، یک داستان تعریف میکند؛ اما محدودکنندهای که آن عدد را میخواند و ارسال وظایف را متوقف میکند، کنترل واقعی است.
تابآوری در طراحی
یک سیستم کنترل هزینه که خود به یک نقطه شکست واحد (single point of failure) تبدیل شود، نتیجه معکوس خواهد داشت. ما سه لایه حفاظتی ساختیم:
- Fails open (باز ماندن در صورت خطا) – اگر ابزار بودجه کرش کند، عاملها به کار خود ادامه میدهند. ممکن است هزینهها بدون کنترل باقی بمانند، اما ناوگان عملیاتی میماند.
- Manual bypass (دور زدن دستی) – اپراتورها میتوانند از طریق یک کانال اولویتدار، محدودکننده را نادیده بگیرند و اجازه دهند کارهای حیاتی حتی در صورت رسیدن به سقف، پیش بروند.
- Auto-resume (بازیابی خودکار) – با حرکت رو به جلوی پنجره متحرک، هزینههای قدیمی از محاسبات خارج میشوند. به محض اینکه مجموع هزینهها به زیر سقف برسد، دروازه بدون دخالت انسان به طور خودکار باز میشود.
آزمایش: سقف ۱۰۰ دلاری در مقابل ۱56 دلار هزینه موجود
ما سیستم را با سقف ۱۰۰ دلار راهاندازی کردیم، در حالی که فعالیتهای اخیر ناوگان قبلاً ۱56 دلار هزینه ایجاد کرده بود. محدودکننده بلافاصله فعال شد و تمام وظایف جدید را متوقف کرد. وقتی سقف را به ۲۰۰ دلار افزایش دادیم، دروازه باز شد و کار بدون مراحل دستی بیشتر، از سر گرفته شد.
این آزمایش دو چیز را تأیید کرد:
- حلقه کنترل در لحظه (real time) واکنش نشان میدهد؛ هیچ تأخیری بین تشخیص نقض بودجه و اجرای محدودیت وجود ندارد.
- اپراتورها میتوانند سقفها را در حین کار تنظیم کنند و از توقف غیرضروری کارهای با اولویت پایین جلوگیری کنند.
نتیجهگیری: برخورد با لاگهای عامل به عنوان یک دفتر کل مالی و پیادهسازی یک محدودکننده بودجه متحرک در خط لوله ارسال وظایف، یک محافظ فوری و قابل اجرا در برابر بیشازحد خرج کردن به شما میدهد. این یک کنترل ارزان و تابآور است که همین امروز کار میکند؛ سیاستهای پیچیدهتر را میتوان بعداً اضافه کرد، اما حلقه اصلی باید اولین خط دفاعی برای هر ناوگان عامل هوش مصنوعی باشد.
