تصور کنید یک عامل خودمختار در ساعت ۲ بامداد تصمیمی اشتباه بگیرد و تمام اعتمادی که طی هفته‌ها به یک سیستم تولیدی ساخته‌اید را در یک لحظه نابود کند. برای جلوگیری از این فاجعه، توسعه‌دهندگان باید دست از نگاه به خودمختاری به عنوان یک تنظیمات کلی بردارند و آن را به عنوان ویژگیِ هر اقدامِ خاص تعریف کنند.
به نقل از چارچوبی کاربردی که در ۱۹ اوت ۲۰۲۶ در dev.to منتشر شد، بسیاری از تیم‌ها دسترسی‌های عامل را با عجله تنظیم می‌کنند و سپس متوجه می‌شوند که این تنظیمات یا بیش از حد سخت‌گیرانه است یا در مواجهه با موارد خاص، به‌شدت خطرناک است. تفاوت بین عاملی که یک جلسه را خلاصه می‌کند با عاملی که برای مشتری وجهی را بازمی‌گرداند، از نظر ریسک زمین و آسمان است؛ اما بسیاری از سیستم‌ها با هر دو یکسان برخورد می‌کنند و آن‌ها را با سطح نظارت یکسانی مدیریت می‌کنند.
زمینه و بستر کنترل عامل‌ها
در پوشش پیشین ما از امنیت مدل‌های بازمتن، دیدیم که کنترل دسترسی‌ها نقطه‌ی ضعف اصلی در استقرار مدل‌هاست. در مورد عامل‌های هوش مصنوعی، سه تصمیم مجزا در پسِ پرسش درباره دسترسی بدون نظارت نهفته است. اول، میزان خودمختاری عامل است. دوم، این است که چه چیزی یک اقدام خاص را پیش از اجرا متوقف می‌کند. سوم، تعیین این است که چه کسی موارد خارج از توان عامل را مدیریت می‌کند. تفکیک این سه مورد از یکدیگر، مانع از اشتباه رایجِ «تنظیمات یک‌باره» می‌شود که یا کارهای ایمن را بیش از حد نظارت می‌کند یا ریسک‌های واقعی را رها می‌کند. این تغییر رویکرد در واقع بخشی از تحول گسترده‌تری است که در آن ماهیت توسعه نرم‌افزار از کدنویسی صرف به تفویض اختیار به عامل‌های هوش مصنوعی تغییر می‌یابد.
پنج سطح خودمختاری
خودمختاری یک کلید دوحالتی نیست، بلکه طیفی است. این چارچوب ۵ سطح کاربردی را تعریف می‌کند:
۱. فقط اطلاعات: عامل داده‌ها را تحلیل می‌کند؛ انسان تمام تصمیمات را می‌گیرد.
۲. توصیه‌ای: عامل اقداماتی را پیشنهاد می‌دهد؛ انسان هر مورد را تایید می‌کند.
۳. خودمختاری محدود: عامل در چارچوب محدودیت‌های سخت‌گیرانه عمل کرده و استثناها را ارجاع می‌دهد.
۴. مبتنی بر استثنا: عامل در اکثر موارد خودمختار است و فقط موارد پرت را گزارش می‌کند.
۵. خودمختاری کامل: عامل بدون نظارت روتین فعالیت می‌کند.
نکته حیاتی این است که این سطح، ویژگیِ خودِ عامل نیست، بلکه ویژگیِ هر «نوع اقدام» است. یک عامل (Agent) — شبیه به کارآموزی که در کارهای اداری مستقل است اما برای امضای قرارداد نیاز به مدیر دارد — می‌تواند در خواندن و خلاصه‌سازی در سطح ۴ باشد، اما در هر اقدامی که روی رکورد مشتری می‌نویسد، در سطح ۲ بماند. این تعادل به گونه‌ای طراحی شده است که با کسب اعتماد سیستم، به مرور زمان تنظیم و گسترش یابد.
گیت‌های اطمینان و اجرای زمان-اجرا
برای اجرای این سطوح در زمان اجرا، سیستم از گیت‌های اطمینان (Confidence Gating) استفاده می‌کند. این مکانیزم، اقدام را پیش از اجرا متوقف می‌کند. عامل بر اساس سیگنال‌های عینی به اقدام برنامه‌ریزی شده خود امتیاز می‌دهد:
- میزان شباهت موقعیت فعلی به مواردی که قبلاً دیده است.
- میزان کامل بودن اطلاعات موجود.
- اینکه آیا برنامه با قوانین تعریف‌شده مطابقت دارد یا خیر.
- نتایج اقدامات مشابه در گذشته چگونه بوده است.
اگر امتیاز به زیر یک حد آستانه برسد — که برای اقدامات غیرقابل‌بازگشت مانند نوشتن در رکورد مشتری باید بسیار بالاتر باشد — عامل متوقف می‌شود. خواندن یک رکورد و بازگرداندن وجه مشتری هرگز نباید از یک استاندارد یکسان عبور کنند. این ساختار باعث می‌شود اقدامات ارزان و قابل‌بازگشت به‌راحتی جریان یابند و اقدامات هزینه‌بر، به قطعیت نزدیک به ۱۰۰٪ نیاز داشته باشند؛ درست مانند روشی که شما وظایف را به یک نیروی تازه‌وارد می‌سپارید. در همین راستا، برخی سیستم‌های پیشرفته‌تر مانند سامانه LEASH از مفهوم بودجه خطا برای مسدود کردن فیزیکی دسترسی عامل‌های سرکش استفاده می‌کنند تا ریسک‌های عملیاتی را به حداقل برسانند.
تعریف مسیرهای ارجاع
توقف اقدام تنها نیمی از راه است. بدون یک مسیر ارجاع تعریف‌شده، عاملی که به محدودیت می‌رسد سه گزینه بد دارد: حدس بزند و ریسک خطا کند، در سکوت شکست بخورد، یا خطایی بدهد که هیچ‌کس نمی‌بیند. یک مسیر ارجاع واقعی با تعریف موارد زیر، گزینه چهارم را می‌سازد:
- شرایط دقیق فعال‌سازی ارجاع (Trigger Conditions).
- شخص یا صفِ دریافت‌کننده مورد.
- بستری از اطلاعات (Context) که همراه با ارجاع منتقل می‌شود.
- زمان پاسخ‌دهی مورد انتظار.
تیم‌ها اغلب اهمیت «بستر اطلاعات» را دست‌کم می‌گیرند. اگر ارجاع فقط یک تیکت باشد که می‌گوید «عامل شکست خورد»، انسان باید همه چیز را از صفر شروع کند و هزینه ارجاع از هزینه خودِ کار بیشتر می‌شود. یک ارجاع درست باید شامل برنامه تولیدشده توسط عامل، امتیاز اطمینان، قانون یا آستانه‌ای که باعث توقف شده و داده‌های خام مربوطه باشد.
این رویکرد، تمرکز را از تنظیمات «روز لانچ» به یک سیستم ارتقای پویا تغییر می‌دهد. عاملی که یک ماه در سطح «فقط توصیه» بدون خطا عمل کند، برای آن تسک خاص ارتقا می‌یابد. برعکس، هر نتیجه بد منجر به تنزل سطح خودمختاری می‌شود.
برای توسعه‌دهندگان، این یعنی هزینه خطا باید معماری را دیکته کند. با تنظیم آستانه‌ها بر اساس هزینه بازگرداندن یک اقدام به حالت اول، سیستم کنترلی ایمن‌تر می‌سازید. نرخ اقدامات متوقف‌شده در لاگ‌های خود را زیر نظر بگیرید؛ جهش در این نرخ معمولاً نشان‌دهنده تغییر در محیط خارجی است، نه کاهش هوش ذاتی مدل.
گام بعدی شما
- لیست تمام اقداماتی که عامل شما انجام می‌دهد را بنویسید و برای هر کدام یک سطح از ۵ سطح خودمختاری تعیین کنید.
- برای اقدامات «غیرقابل‌بازگشت»، آستانه اطمینان (Confidence Threshold) را حداقل ۲۰٪ بالاتر از اقدامات «خواندنی» قرار دهید.
- فرمت ارجاع به انسان را بازبینی کنید تا شامل «دلیل توقف» و «برنامه پیشنهادی عامل» باشد تا زمان بررسی توسط انسان کاهش یابد.
اما مدیریت این ارجاع‌ها در مقیاس هزاران کاربر، نیازمند زیرساخت‌های متفاوتی است — به تحلیل ما درباره پروتکل‌های ارتباطی عامل‌های هوش مصنوعی مراجعه کنید.
گفتگو