بودجه‌های اختیار: سطح کنترل گمشده میان یک عامل و ابزارهایش

لایهٔ دستورالعمل یک سطح کنترل نیست

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

در مقابل، اختیار در زیر لایهٔ مدل اجرا می‌شود. اختیار در اعتبارنامه، در دامنهٔ توکن، در محدودیت نرخ نقطهٔ پایانی، و در گواهی لازم برای تمدید دسترسی زندگی می‌کند. این‌ها دستورالعمل‌هایی نیستند که مدل بتواند بازتفسیرشان کند. این‌ها محدودیت‌هایی‌اند که زمان اجرا اعمال می‌کند. اگر یک عامل اعتبارنامه‌ای در دست داشته باشد که می‌تواند یک پایگاه داده را حذف کند، پرامپتی که می‌گوید «پایگاه داده را حذف نکن» یک امید است، نه یک مرز. واحد عملی کنترل، مجاز بودن یا نبودن نیست. بلکه مقدار، تکرار، و گواهی تحت آن است.

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

چرا پرامپت‌ها نمی‌توانند اختیار حمل کنند

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

الگویی رایج را در نظر بگیرید: به یک عامل دستور داده می‌شود تیکت‌های پشتیبانی را خلاصه کند و ابزاری به آن داده می‌شود که می‌تواند وضعیت تیکت را نیز به‌روزرسانی کند. پرامپت می‌گوید «فقط خواندن». API ابزار یک پارامتر نوشتن می‌پذیرد. مدل، در پی هدف حل تیکت، ممکن است آن پارامتر را تنظیم کند. پرامپت اختیار نوشتن اعطا نکرده بود، اما اعتبارنامه این کار را کرد. این شکست، شکست پرامپت نیست؛ شکست طراحی اختیار است.

همین امر دربارهٔ نرخ و حجم نیز صادق است. پرامپت ممکن است بگوید «از ابزار جست‌وجو کم استفاده کن». نقطهٔ پایانی هیچ سهمیه‌ای ندارد. عامل می‌تواند هزاران بار آن را فراخوانی کند. پرامپت نمی‌تواند کم‌مصرفی را اجرا کند. فقط یک سهمیه می‌تواند.

به همین دلیل ایمنی عامل بهتر است به‌صورت یک سهمیهٔ اختیار قابل‌مصرف مدل‌سازی شود. هر قابلیت یک اعطا با دامنه، سهمیه، انقضا و شرط تمدید است. مدل می‌تواند اعطا را خرج کند. نمی‌تواند از آن فراتر رود. نقطهٔ اجرا ابزار است، یا دروازه، یا صادرکنندهٔ اعتبارنامه، نه پرامپت.

طراحی یک بودجهٔ اختیار

یک بودجهٔ اختیار هر قابلیت را به‌صورت یک اعطای کران‌دار بیان می‌کند. یک اعطا چهار بخش دارد:

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

بودجه باید برای برنامه‌ریز قابل مشاهده باشد. اگر عامل ببیند که سه نوشتن باقی دارد و دو ساعت تا انقضا، می‌تواند دربارهٔ تخلیه استدلال کند. می‌تواند اولویت‌بندی کند، به تعویق بیندازد، یا درخواست تمدید کند. اگر بودجه نامرئی باشد، عامل محدودیت‌ها را به‌صورت خطا کشف می‌کند، که به تلاش‌های مجدد، دور زدن‌ها و رفتار غیرقابل‌پیش‌بینی می‌انجامد. مشاهده‌پذیری یک توقف سخت را به یک محدودیت برنامه‌ریزی تبدیل می‌کند.

اختیار را بر حسب نوع جدا کنید. اختیار خواندن کم‌ریسک است و می‌تواند به‌طور خودکار درون یک نشست تمدید شود. اختیار نوشتن پرریسک‌تر است و باید دامنهٔ باریک‌تر و انقضای کوتاه‌تری داشته باشد. اختیار برگشت‌ناپذیر، مانند ارسال یک ارتباط خارجی، حذف داده، یا انتقال وجه، باید برای هر برداشت گواهی صریح یا سهمیه‌ای بسیار کوچک با حضور انسان در حلقه را الزامی کند. مسیرهای تمدید باید بر همین اساس متفاوت باشند: اعطاهای خواندن را می‌توان توسط هماهنگ‌کننده تازه کرد؛ اعطاهای نوشتن را با یک بررسی سیاست؛ اعطاهای برگشت‌ناپذیر را با یک انسان یا یک حد نصاب.

یک سازوکار مشخص: یک دروازهٔ اختیار میان عامل و ابزارها قرار می‌گیرد. عامل یک توکن اعطا ارائه می‌دهد. دروازه توکن را اعتبارسنجی می‌کند، دامنه را در برابر اقدام درخواستی بررسی می‌کند، سهمیه را کاهش می‌دهد و برداشت را ثبت می‌کند. اگر سهمیه تمام شده باشد یا از دامنه فراتر رفته باشد، دروازه یک رد ساختاریافته برمی‌گرداند که هماهنگ‌کننده می‌تواند تفسیرش کند. توکن توسط یک سرویس اعتبارنامه صادر می‌شود که دامنه، سهمیه، انقضا و الزامات گواهی را رمزگذاری می‌کند. مدل هرگز اعتبارنامه‌های زیرین را نمی‌بیند؛ فقط اعطا و بودجهٔ باقی‌ماندهٔ آن را می‌بیند.

این ایدهٔ جدیدی نیست. همان روشی است که IAM ابری، محدودسازی نرخ API و امنیت مبتنی بر قابلیت از قبل کار می‌کنند. سهم آن این است که اختیار عامل را به‌عنوان یک منبع درجه‌یک و قابل‌مصرف در نظر بگیرد که برنامه‌ریز می‌تواند دربارهٔ آن استدلال کند و زمان اجرا می‌تواند آن را اجرا کند.

پیامدهای عملیاتی

وقتی اختیار یک بودجه است، واکنش به حادثه تغییر می‌کند. به‌جای بازنویسی یک پرامپت سیستمی و امید به تمکین مدل، اپراتورها یک اعطا را لغو می‌کنند. لغو فوری و قابل‌اجراست. عامل قابلیت را از دست می‌دهد، نه فقط دستورالعمل را. حادثه در لایهٔ اعتبارنامه مهار می‌شود، همان‌جایی که آسیب رخ می‌داد.

خروجی حسابرسی به یک دفتر برداشت‌ها در برابر بودجه‌ها تبدیل می‌شود. هر سطر اعطا، دامنه، اقدام، سهمیهٔ باقی‌مانده و گواهی را ثبت می‌کند. این دفتر برای بازبینان غیر-ML خواناست: امنیت، انطباق و عملیات می‌توانند آن را بدون درک درونیات مدل بخوانند. می‌توانند ببینند عامل چه کرد، تحت چه اختیاری، و آیا درون مرزها ماند. همچنین می‌توانند ببینند چه زمانی یک اعطا تمدید شد و بر چه شواهدی.

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

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

معاوضهٔ دوم انعطاف‌پذیری است. یک اعطای با دامنهٔ تنگ ممکن است اقدامی مشروع را که عامل برای تکمیل یک وظیفه لازم دارد مسدود کند. عامل باید تمدید درخواست کند، که ممکن است تأیید انسانی لازم داشته باشد. این حلقه را کند می‌کند. جایگزین، یک اعطای گسترده است که آن اقدام و هر چیز دیگری را مجاز می‌کند. انتخاب طراحی این است که مرز میان خودمختاری و نظارت کجا قرار گیرد. بودجه‌های اختیار این انتخاب را صریح و قابل‌اجرا می‌کنند، به‌جای آنکه آن را به تفسیر مدل از یک پرامپت واگذار کنند.

نتیجه‌گیری

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