ریسک‌ها و حالت‌های شکست عوامل هوش مصنوعی: چرا عوامل "خوب نسبتاً" هنوز هم خراب می‌شوند

ریسک‌ها و حالت‌های شکست عوامل هوش مصنوعی عمدتاً ناشی از خطاهای خاموش تجمعی در استفاده از ابزارهای چند مرحله‌ای است، نه یک سقوط مدل دراماتیک. یک جریان کار که در هر مرحله 90٪ "درست" به نظر می‌رسد، می‌تواند در نهایت غیرقابل استفاده باشد مگر اینکه با مجوزهای صریح، نقاط چک و نظارت ساخته شود.

نکات کلیدی

• قابلیت اطمینان عامل چند مرحله‌ای در مراحل مختلف ضرب می‌شود، بنابراین دقت 85٪ در هر عمل می‌تواند به حدود 20٪ موفقیت در یک جریان کار 10 مرحله‌ای کاهش یابد، در حالی که دقت 95٪ در هر عمل به حدود 60٪ می‌رسد.
• بیشترین شکست‌های آسیب‌زننده عوامل، شکست‌های "نرم" هستند: خروجی‌های قابل قبول، تماس‌های نادرست با ابزار و اهداف منحرف که خطاها یا هشدارها را تحریک نمی‌کنند.
• سیستم‌های چند عاملی حالت‌های شکست خاص خود را اضافه می‌کنند، از جمله تعصب هم‌راستایی و وضعیت مشترک کهنه، که می‌تواند یک توهم را به توافق نادرست تبدیل کند.
• تزریق درخواست یک تهدید در لایه اجرایی برای عوامل است زیرا می‌تواند تماس‌های ابزار و اهداف را هدایت کند، نه فقط خروجی متن.

چگونه شکست‌های عوامل هوش مصنوعی متفاوت است

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

این تغییر کلیدی در مدل ذهنی برای هر کسی است که در حال ساخت آنچه که عوامل هوش مصنوعی در کریپتو هستند: شکست معمولاً یک خروجی به ظاهر تمیز است که از نظر عملی نادرست است.ریاضیات تجمعی بخشی است که بیشتر تیم‌ها از آن صرف نظر می‌کنند. مثال ترانتور صریح است: اگر یک عامل در هر عمل 85٪ دقیق باشد، یک جریان کار 10 مرحله‌ای تنها حدود 20٪ موفقیت دارد. حتی دقت 95٪ در هر مرحله تنها حدود 60٪ موفقیت در 10 مرحله به دست می‌آورد. این همان شکل کاهش نرخ پرشدن در یک کتاب معاملاتی است زمانی که یک استراتژی به چندین پرشدن وابسته نیاز دارد. هر مرحله می‌تواند به طور محلی منطقی باشد و هنوز هم یک اجرای جهانی خراب تولید کند.سیستم‌های عامل همچنین به طور غیرقطعی شکست می‌خورند. دو اجرای با ورودی‌های یکسان می‌توانند انحراف پیدا کنند زیرا نمونه‌های مدل، خروجی‌های ابزار تغییر می‌کنند یا زمینه بازیابی شده تغییر می‌کند. ریدیس الگوی رایج را به عنوان تجمع خطا در خطوط لوله توالی‌دار که در آن خطاهای نرم بدون خرابی یا هشدارها گسترش می‌یابند، چارچوب‌بندی می‌کند. آن ویژگی "بدون ردیابی پشته" دلیل این است که تیم‌ها شکست‌های عامل را به عنوان "ما به یک مدل بهتر نیاز داریم" تشخیص می‌دهند در حالی که مشکل واقعی عدم دروازه‌ها و عدم قابلیت مشاهده است.

کریپتو لبه تیزتری اضافه می‌کند. زمانی که یک عامل هوش مصنوعی یک کیف پول عامل دارد، تماس با ابزار یک درخواست API بی‌ضرر نیست. این می‌تواند یک تراکنش، یک تأیید، یک پل یا یک امضا باشد. هزینه یک اشتباه خاموش پاسخ بد نیست. این یک عمل زنجیره‌ای است که تسویه می‌شود.حالت‌های شکست اصلی عامل که باید انتظار داشتسوء استفاده از ابزار حالت شکست پایه است زیرا در مرز بین زبان و اجرا قرار دارد.

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

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

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

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

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

کاهش کیفیت خاموش یکی است که تیم‌ها را در طول هفته‌ها می‌سوزاند. ترانتور عواملی مانند انحراف ذخیره‌سازی اسناد، پسرفت درخواست، تغییرات رفتار مدل خاموش و تغییر توزیع ورودی را فهرست می‌کند. عامل همچنان به "تکمیل" وظایف ادامه می‌دهد، اما مفید بودن زیر آستانه‌ای که خروجی ایمن برای عمل باشد، کاهش می‌یابد.

هماهنگی چند عاملی و ریسک‌های آبشاری

تنظیمات چند عاملی اغلب به عنوان ایمنی از طریق افزونگی فروخته می‌شوند. منابع به سمت دیگر اشاره می‌کنند مگر اینکه تأیید به طور صریح طراحی شده باشد. ریدیس به تعصب هم‌راستایی اشاره می‌کند: عوامل پایین‌دست تمایل دارند با یک ادعای مطمئن از بالا هم‌راستا شوند و یک توهم را به توافق نادرست تقویت کنند. این یک ویژگی نظری نیست. این یک حالت شکست هماهنگی است که شبیه توافق به نظر می‌رسد و خروجی‌های نادرست را سریع‌تر ارسال می‌کند.

مطالعه arXiv این را با MASFT، یک طبقه‌بندی از 14 حالت شکست چند عاملی که به سه دسته تقسیم شده‌اند، رسمی می‌کند: شکست‌های طراحی مشخصات و سیستم، عدم هم‌راستایی بین عوامل و شکست‌های تأیید و خاتمه وظیفه. این مطالعه پنج چارچوب MAS را در بیش از 150 وظیفه با ردیابی‌های انسانی تجزیه و تحلیل می‌کند و توافق بین ردیاب‌ها را با کاپا 0.88 کوهن گزارش می‌دهد.

همچنین گزارش می‌دهد که دقت ChatDev می‌تواند در ارزیابی آن‌ها به 25٪ کاهش یابد و مداخلات بهترین تلاش مانند مشخصات نقش بهبود یافته و ارکستراسیون ChatDev را 14٪ بهبود بخشید اما هنوز برای استقرار در دنیای واقعی کافی نبود.

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

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

درس چند عاملی ساده است: بیشتر عوامل به طور پیش‌فرض ایمنی بیشتری ایجاد نمی‌کنند. آن‌ها سطوح بیشتری برای فرضیات تأیید نشده ایجاد می‌کنند تا پایدار شوند.

تهدیدات امنیتی در جریان‌های کاری عامل

تزریق درخواست حالت شکست امنیتی است که برای عوامل مهم‌ترین است زیرا محدود به متن نیست. ترانتور تزریق درخواست را به عنوان شماره یک آسیب‌پذیری OWASP LLM Top 10 برای سال 2025 توصیف می‌کند و تأکید می‌کند که در زمینه‌های عاملی خطرناک‌تر است زیرا می‌تواند اهداف و تماس‌های ابزار را در سراسر یک جریان کار ربوده کند. این تفاوت بین "چت‌بات چیزی عجیب می‌گوید" و "عامل آنچه را که سعی دارد انجام دهد تغییر می‌دهد" است.

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

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

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

ترانتور همچنین ادعا می‌کند که 88٪ از سازمان‌هایی که عوامل هوش مصنوعی را مستقر کرده‌اند، در سال 2025 حداقل یک حادثه امنیتی گزارش کرده‌اند. این رقم به عنوان یک ادعای ثانویه در منبع ارائه شده است، اما با جهت حرکت مطابقت دارد: هنگامی که عوامل می‌توانند عمل کنند، سطح حادثه سریع‌تر از کنترل‌های بیشتر تیم‌ها رشد می‌کند.

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

کنترل‌هایی که کار می‌کنند شبیه محدودیت‌های ریسک هستند، نه "بهتر درخواست کردن". پایان‌نامه در سراسر منابع این است که شکست‌های عامل در مراحل و بازیگران مختلف تجمع می‌یابند، بنابراین سیستم به محدودیت‌های صریح، تأیید و قابلیت مشاهده در هر مرز نیاز دارد.یک پشته کنترل به سبک دفتری می‌تواند به عنوان یک توالی ساخت مرتب بیان شود:1. ابزارها را به حداقل مجوز محدود کنید. مثال‌های سوء استفاده از ابزار ترانتور اساساً شکست‌های مجوزی هستند.

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

برای ابزارهای کریپتو، این به معنای تأیید زنجیره، توکن، اعشار، گیرنده و تغییرات مجوز قبل از اینکه یک تماس مجاز به انجام شود، است. 3. نقاط چک تأیید را وارد کنید. ریدیس توصیه می‌کند که در هر مرز تأیید شود و طبقه‌بندی MASFT در arXiv شکست‌های تأیید و خاتمه وظیفه را به عنوان یک دسته اصلی علامت‌گذاری می‌کند. نقش تأییدکننده باید به طور ساختاری متفاوت از برنامه‌ریز باشد، یا به یک فرهنگ تک‌بعدی تبدیل می‌شود. 4. رشد زمینه را کنترل کنید.

ترانتور توصیه می‌کند که در فواصل منظم خلاصه‌سازی سلسله‌مراتبی انجام شود تا از انحراف زمینه جلوگیری شود. ریدیس هشدار می‌دهد که افزودن زمینه بیشتر می‌تواند مشکلات هماهنگی را بدتر کند به دلیل پوسیدگی زمینه و رفتار گم‌شده در میانه. 5. حلقه‌ها و هزینه‌ها را در لایه ارکستراسیون محدود کنید. ترانتور خواستار محدودیت‌های تکرار سخت و نظارت بر هزینه‌های زمان واقعی با سقف‌های هزینه است. این نیاز به کلید خاموش در فرم مهندسی است. 6.

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

کنترل‌های سازمانی به اندازه کنترل‌های فنی مهم هستند. ترانتور ادعا می‌کند که انحراف دامنه و مشکلات کیفیت داده‌ها 61٪ از شکست‌های عوامل هوش مصنوعی را تشکیل می‌دهند. این دلیل غیرجذاب است که بسیاری از آزمایش‌ها هرگز به سیستم‌های تولید تبدیل نمی‌شوند.

نکات عملی برای استقرار ایمن‌تر

آمادگی تولید با اندازه‌گیری زنجیره شروع می‌شود، نه تحسین مدل. اگر جریان کار به 10 مرحله وابسته نیاز دارد، تنها عدد قابل اعتماد در مورد قابلیت اطمینان، نرخ موفقیت تجمعی است، نه "دقت" در هر مرحله. مثال 85٪ به ~20٪ ترانتور سریع‌ترین راه برای آزمایش دود است که آیا یک سیستم یک دمو است یا یک ابزار عملیاتی.

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

چند عاملی می‌تواند برای کارهای قابل موازی‌سازی توجیه شود، اما تنها زمانی که نقش‌های تأییدکننده و معیارهای خاتمه صریح باشند.

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

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

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

من دیده‌ام که تیم‌ها نرخ «پاسخ صحیح 90 درصد» را مانند یک SLA تولیدی در نظر می‌گیرند و سپس وقتی که عامل در لحظه‌ای که باید ده کار را به‌طور متوالی انجام دهد، خراب می‌شود، شگفت‌زده می‌شوند. ریاضیات ترانتور سیلی مناسبی به صورت است: 85 درصد در هر مرحله به ~20 درصد در انتها در 10 مرحله تبدیل می‌شود و دقیقاً همین‌طور است که یک استراتژی با شانس‌های پرکردن مناسب هنوز هم در زمانی که به زنجیره‌ای از پرکردن‌ها نیاز دارد، از بین می‌رود.

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

منابع

ترانتور

ریدیس

arXiv

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

[@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop

• [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop
• [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop
• [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop