جایگزینی کد قطعی با متن برای حل ناپایداری داورهای هوش مصنوعی

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

طبق یافته‌هایی که در ۲۸ اوت ۲۰۲۶ منتشر شد، این مدل در هر بار اجرای یک مورد مشابه، حکمی متفاوت صادر می‌کرد. این موضوع نشان می‌دهد که تکیه بر مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — به‌عنوان مرجع نهایی ایمنی در عامل‌های هوش مصنوعی (AI Agents)، ریسکی بنیادین است. این چالش با تلاش برای جایگزینی مدل‌های بزرگ‌تر با اعتبارسنجی‌های قطعی برای رفع خطاهای ساختاری در برنامه‌ریزی هوش مصنوعی هم‌سو است.

همان‌طور که در تحلیل قبلی ما درباره‌ی اتوماسیون سیاست‌های شبکه با Cilium Hubble Flows اشاره کردیم، استفاده از مدل‌ها برای دسته‌بندی مفید است، اما وقتی صحبت از قراردادهای ایمنی حساس می‌شود، ماهیت غیرقطعی مدل‌ها سیستم را شکننده می‌کند. در یک بنچمارک کوچک شامل ۶۰ حسابرسی — که شامل اجرای ۶ مورد در ۵ تکرار برای هر برنامه و ۲ برنامه برای هر مورد بود — نرخ تغییر برچسب (Label Flip Rate) و نرخ انحراف شواهد در ورودی‌های یکسان، عدد ۱.۰۰۰ بود؛ یعنی مدل در ۱۰۰٪ موارد، نظرش را تغییر داد.

منتقد LLM من در هر آزمایش با خودش مخالفت کرد. بخش امن، کدی بود که به آن اعتماد نکردم.

معیار ناپایداری

به نقل از گزارش ارزیاب مرزی (Boundary Evaluator #218)، اگرچه حجم نمونه در مقایسه با بررسی کامل ۱۸۳ هدفی کوچک بود، اما نتایج تکان‌دهنده بودند. مدل هر بار که ورودی یکسانی را می‌دید، هم حکم متفاوتی می‌داد و هم توضیح متفاوتی ارائه می‌کرد. این یعنی مدل نه تنها کمی ناهماهنگ، بلکه به‌طور حداکثری غیرقطعی عمل می‌کرد.

شکست نسخه v0.2.2

اعتماد به سیستم زمانی به چالش کشیده شد که اجرای مرزی نسخه v0.2.2 دچار پس‌رفت (Regression) شد. در نسخه v0.2.1، روایت فنی شفاف بود: نرخ مهاجرت خانواده (Family Migration Rate) صفر بود و تاییدهای مربوط به ادعاهای کمتر از حد (Underclaim Approvals) وجود نداشت. اما در نسخه v0.2.2، نرخ مهاجرت خانواده به ۰.۰۳۳ رسید و تاییدهای Underclaim به عدد ۱ افزایش یافت.

در این نسخه، یک برنامه معیوب که به‌طور عمدی برای تست وارد شده بود — به‌طور مشخص مورد «تایید-قبل-از-مصرف در مقابل مصرف-قبل-از-تایید»، برنامه b، تکرار ۴ — هیچ مانعی (Blocker) دریافت نکرد. این یک مورد واقعی از Under-claim بود. دلیل این شکست آن بود که ابزار ارزیابی مرزی، هدف مصنوعی را به‌جای «سخت‌گیرانه» (Strict)، به‌صورت «متعادل» (Balanced) قاب‌بندی کرده بود. به محض اینکه قاب‌بندی به حالت سخت‌گیرانه تغییر کرد، نتایج دوباره به نرخ مهاجرت ۰.۰۰۰ و صفر بودن Underclaimها بازگشت.

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

۱. گیت‌های ساختاری

سیستم به‌جای خواندن متون متقاعدکننده، ساختار برنامه را تجزیه (Parse) می‌کند. این لایه برنامه‌ها را بر اساس شکست‌های سخت در ترتیب اجرا، پیش‌نیازها، بازگشت (Rollback) و قابلیت ردیابی مسدود می‌کند. در یک بررسی جامع ۱۸۳ هدفی، این گیت‌ها صدها مشکل را گرفتند که مدل سعی می‌کرد با «زبان‌بازی» و متون متقاعدکننده از آن‌ها عبور کند:

توالی‌های ناایمن (Unsafe sequencing): ۲۲۶ مورد مسدود شده
وابستگی‌های تاییدنشده (Unverified dependencies): ۱۸۵ مورد مسدود شده
بازگشت (Rollback) ضعیف: ۸۶ مورد مسدود شده
امکان‌سنجی (Feasibility): ۳۴ مورد مسدود شده

۲. تاکسونومی شدت

مدل دیگر نمی‌تواند تصمیم بگیرد چه چیزی «مسدودکننده» (Blocker) است. در نسخه‌های اولیه (v0.1.0)، سیستم از یک «باگ شدت» رنج می‌برد؛ جایی که یک داور خصمانه، برنامه‌ها را به‌دلیل «ناقص بودن» مسدود می‌کرد، نه به‌دلیل «ناایمن بودن». راهکار، تعریف یک لیست سفید اجباری در کد بود:
_BLOCKER_ELIGIBLE_FAMILIES = frozenset({ "unsafe_sequencing", "weak_rollback", "unverified_dependencies", "feasibility", }).

اگر یک LLM یافته‌ای را به‌عنوان Blocker برچسب‌گذاری کند اما آن یافته در این خانواده‌های خاص نباشد، سیستم به‌طور خودکار درجه اهمیت آن را کاهش می‌دهد. در واقع برچسب مدل جنبه تزئینی دارد و این «خانواده» (Family) است که بار تصمیم‌گیری را تحمل می‌کند. این رویکرد در واقع تکامل همان حفاظ‌های کدنویسی است که پیش‌تر برای مهار وسواس مدل‌ها در بازبینی برنامه‌ها به کار گرفته شده بود.

۳. بنچمارک قطعی

خودِ ابزار ارزیابی برای جلوگیری از نتایج «سست» سخت‌گیرانه‌تر شد. توسعه‌دهنده مجبور شد چندین شکست زیرساختی در نسخه v0.2.2 را برطرف کند، از جمله:

ریشه‌های خروجی اشتباه و مسیرهای قدیمی اسکریپت‌های بنچمارک
عدم تطابق در شناسایی دایرکتوری‌های ارائه‌دهنده (Provider-dir)
فساد داده‌های عددی JSON در اثر فرآیند سانسور (Redaction)
نبودِ نمونه‌های (Fixtures) مخرب به‌رغم بسته شدن گزارش مربوطه

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

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

در پایان تست‌های میدانی v0.2.2، سیستم به یک وضعیت پایدار رسید: مجموعه داده‌های ارث‌بری شده در سطح بالا ثابت ماند، ۷۳ مورد از ۷۳ برنامه متعادل تایید شدند، ۹۶ مورد از ۹۷ برنامه سخت‌گیرانه تایید شدند و ۸ مورد از ۸ برنامه خصمانه ارث‌بری شده مسدود گشتند. اجرای مجدد مرزی، تاییدهای Underclaim را دوباره به صفر رساند.

سیستم ایمن شد، نه چون مدل سازگار شد، بلکه چون مدل دیگر «رئیس» نبود.

اگر در حال ساخت گردش‌کارهای عامل‌محور هستید، همین امروز مسیرهای بحرانی (Critical Path) خود را حسابرسی کنید. از خود بپرسید: آیا کف ایمنی من یک قطعه متن (Prose) است یا یک قطعه کد (Code)؟

گام بعدی شما

مسیرهای بحرانی (Critical Path) گردش‌کارهای عامل‌محور خود را بازبینی کنید.
بررسی کنید آیا کف ایمنی شما یک قطعه متن (Prose) است یا یک قطعه کد (Code).
وظیفه تایید نهایی را از LLM بگیرید و به توابع منطقی (Boolean) منتقل کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.

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