اگر امروز یک سامانه چندعاملی برای اتوماسیون زیرساختهای ابری طراحی میکنید، احتمالاً با بحران «وسواس مدل» روبرو شدهاید؛ وضعیتی که در آن هوش مصنوعی بهدلیل ترس از خطاهای احتمالی، سادهترین برنامههای ایمن را هم رد میکند. در یک سیستم دو-مدلی (Dual-LLM) — جایی که یک مدل برنامه را مینویسد و مدل دوم آن را از نظر ایمنی و منطق بازبینی میکند — زیربنای قدرتمندی ایجاد میشود، اما این ساختار بهتنهایی نمیتواند مانع از آن شود که مدل دوم بهدلیل دقت بیش از حد، برنامههای ایمن را مسدود کند.
به گزارش وبسایت dev.to، موتور متنباز PlannerCritic در مواجهه با این چالش، دریافت که تکیه بر قضاوت مدل زبانی برای تعیین سطح خطر، یک استراتژی شکستخورده است. برای حل این مشکل، توسعهدهندگان دریافتند که تنها راهکار مؤثر، استفاده از یک «حفاظ کد قطعی» (Deterministic Code Guardrail) است تا لایهای از کدنویسی سخت جایگزین «احساس» مدل شود و از مسدود شدن بیدلیل فرآیندها جلوگیری گردد.
همانطور که در تحلیل قبلی ما دربارهی پایداری جریانهای توکن در StreamingLLM اشاره کردیم، چالش فعلی در سامانههای عاملمحور، دیگر حافظه نیست، بلکه «قضاوت» است. این مطلب دومین مقاله از سری بررسیهای موتور PlannerCritic است که پس از یک تست میدانی روی ۱۵۷ هدف در ۳۵ حوزه مختلف تهیه شده است. در این آزمایش، توسعهدهنده متوجه شد وقتی به یک مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — شخصیتی «خصمانه» (Adversarial) داده شود، یک شکست سیستمی رخ میدهد: مدل شروع میکند به علامتگذاری هر برنامهای به عنوان «مسدودکننده» (Blocker)، صرفاً چون میتواند یک مورد خاص و احتمالی (Edge Case) برای اعتراض پیدا کند. این رویکرد در تضاد با کاربردهای موفق این متد است؛ برای مثال، استفاده از حلقههای بررسی تخاصمی در برخی پروژهها توانسته است باگهای بحرانی را شناسایی کند، اما در اینجا وسواس مدل بر دقت غلبه کرده است.
ریشهٔ شکست: تضاد در درک «سختگیری»
طبق مستندات این پروژه، مشکل با یک پرامپت سیستمی (System Prompt) ششکلمهای شروع شد: «تو یک بازبین خصمانهٔ برنامهها هستی» (You are an adversarial plan reviewer). در حالی که این دستور در ابتدا کافی به نظر میرسید، اما باعث ایجاد یک «عدم تطابق در قرارداد» (Contract Mismatch) شد. هدف محصول از فعال کردن «حالت سختگیرانه» (Strict Mode) این بود که فقط تخلفات عینی در زمینه ایمنی، ترتیب اجرا یا نقص در برنامههای بازگشت (Rollback) مسدود شوند. اما مدل زبانی، کلمه «خصمانه» را به عنوان دستوری برای یافتن هرگونه اعتراض ممکن، بدون در نظر گرفتن شدت خطا، تفسیر کرد.
نتیجه این شد که در ۱۶ هدف حساس، نرخ ارجاع به انسان (Escalation Rate) ۱۰۰٪ شد. برنامهها از نظر ساختاری ناایمن نبودند؛ بلکه بازبین صرفاً استانداردی را اجرا میکرد که «هیچگونه ملاحظهای از سوی بازبین وجود نداشته باشد»، به جای اینکه بر «نبود نقصهای ساختاری» تمرکز کند.
نمونههای واقعی از مسدودسازیهای بیمورد
بر اساس گزارشهای منتشر شده در dev.to، مدل شروع به مسدود کردن برنامههایی کرد که از نظر ساختاری درست بودند اما «جامع» یا «کامل» نبودند. دو مثال مشخص این رفتار را نشان میدهد:
- اتصال VPC (VPC Peering): برنامهای برای اتصال دو حساب ابری (Cross-account VPC peering) مسدود شد، چون بازبین اشاره کرد که برنامهٔ بازگشت «میتوانست» سناریوهای جایگزینی DNS (DNS failback) را هم در نظر بگیرد. این یک پیشنهاد برای تکمیل برنامه بود، نه یک نقص ایمنی.
- مهاجرت شاخص (Index Migration): جابهجایی یک بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که میگوید این کلمه همسایهی چه کلمات دیگری است — بهدلیل یک یافته کلی درباره «ریسک» احتمالی تأخیر (Latency) در زمان انتقال، مسدود شد. این یک تحلیل ریسک بود، نه یک خطای ساختاری.
در هر دو مورد، موتور باید برنامه را با ذکر ریسک تأیید میکرد، اما بهجای آن، کل فرآیند را متوقف و به انسان ارجاع داد.
راهکار: جایگزینی قضاوت با قرارداد کد
توسعهدهندگان برای خروج از این بنبست، یک سامانه دو لایه طراحی کردند:
۱. طبقهبندی شدت خطا (Severity Taxonomy): شخصیت «خصمانه» از پرامپت سیستمی حذف شد و قوانین صریح شدت خطا جایگزین گشت. اکنون دستهبندی «مسدودکننده» فقط برای نقصهای عینی و محلی در برنامه رزرو شده است که اجرای آن را ناایمن میکند:
- مسدودکننده (Blocker): مخصوص موارد
unsafe_sequencing(توالی ناایمن)،weak_rollback(بازگشت ضعیف)،unverified_dependencies(وابستگیهای تأییدنشده) وfeasibility(امکانسنجی). - هشدار (Warning): مخصوص ریسکها یا مراحل فراموش شده.
- اطلاعات (Info): مخصوص مشاهدات جزئی.
اکنون پرامپت صراحتاً مدل را از ارجاع نگرانیهای مربوط به «جامعیت» یا «دقت» به سطح مسدودکننده منع میکند. این تغییر در واقع بازگشت به این اصل است که بسیاری از وظایف پیچیده هوش مصنوعی را میتوان به مسائل سادهتر طبقهبندی تبدیل کرد تا دقت و کارایی افزایش یابد.
۲. حفاظ کدنویسی (Code Guardrail): چون مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب — بهتنهایی شکست خورد و مدل همچنان در ۳۰٪ موارد نگرانیهای مربوط به جامعیت را مسدود میکرد، یک frozenset در کد برنامه تعریف شد تا به عنوان یک قرارداد قطعی عمل کند:
_BLOCKER_ELIGIBLE_FAMILIES = frozenset({ "unsafe_sequencing", "weak_rollback", "unverified_dependencies", "feasibility", })
در این ساختار، اگر مدل سطح شدت را Severity.BLOCKER برگرداند اما خانوادهی مورد (item.heuristic_family) در این مجموعه (frozenset) نباشد، کد بهطور خودکار سطح خطا را پیش از ورود به لیست یافتهها، به Severity.WARNING کاهش میدهد.
این تغییر باعث شد موتور از تکیه بر «احساس» متغیر مدل زبانی به یک قرارداد سخت منتقل شود. پس از این اصلاح، در ۹۲ اجرای بعدی، هیچ مورد مشورتی (Advisory) بهاشتباه مسدود نشد، در حالی که ۱۳۲ نقص ساختاری واقعی یا گیتهای قطعی همچنان بهدرستی شناسایی شدند.
این یافته با پژوهشهای اخیر (arXiv 2507.02778) همسو است که نشان میدهد حدود ۶۴.۵٪ از مدلها دچار «نقطه کور خوداصلاحی» (Self-correction blind spot) هستند و نمیتوانند بهدرستی صحت خروجی خود را ارزیابی کنند.
گام بعدی شما
برای توسعهدهندگانی که جریانهای کاری عاملمحور (Agentic Workflows) میسازند، این بدان معناست که نمیتوانید به مدل اعتماد کنید تا خودش دروازه کیفیت (Quality Gate) باشد. شما باید معیارهای «مسدودکننده» را در کد برنامه (Application Code) تعریف کنید، نه در پرامپت سیستمی. اگر از سامانههای چندعاملی استفاده میکنید، عاملهای «بازبین» (Critic Agents) خود را ممیزی کنید تا ببینید آیا بهخاطر وسواس در جامعیت، تولیدات شما را مسدود میکنند یا خیر. مخزن PlannerCritic در گیتهاب یک الگوی عملی برای پیادهسازی این جایگزینیهای قطعی ارائه میدهد.
اما این تنها بخشی از چالشهای استدلال است؛ برای درک اینکه مدلها چگونه در زنجیره تفکر دچار توهم میشوند، تحلیل ما دربارهی حفرههای ساختاری در زنجیره تفکر مدلهای OpenAI و Anthropic را بخوانید.
گفتگو