«ضعف در دستورالعمل‌ها»؛ علت اصلی نوسان عملکرد عامل‌های هوش مصنوعی

اگر امروز برای ارزیابی کیفیت عامل‌های هوش مصنوعی خود به مدل‌های زبانی تکیه می‌کنید، احتمالاً نیمی از نوسانات نمرات شما ربطی به کد یا پرامپت ندارد. حقیقت این است که «نویز» ارزیابی اغلب نه در پاسخِ عامل، بلکه در دستورالعمل‌های داور نهفته است.

ارزیابی عامل‌های هوش مصنوعی (AI Agents) — شبیه مدیریت تیمی از کارمندان است که هر بار یک دستور را به شکلی متفاوت اجرا می‌کنند — به‌شدت دشوار است. طبق گزارش AgentVitals، اصطلاح «ناپایداری» معمولاً سه شکست مجزا یعنی رانش خروجی، فروپاشی نقش و فقدان حافظه را در یک شکایت کلی می‌گنجاند که عیب‌یابی آن تقریباً غیرممکن است. برای حل این مشکل، این تیم مقیاس AVS-15 را توسعه داد؛ چارچوبی ۱۵-بعدی که پایداری (R1–R7) را از رفاه (W1–W8) تفکیک می‌کند. این رویکرد برای شناسایی دقیق نقاط ضعف ضروری است، چرا که یافتن نقطه شکست عامل‌ها در محیط‌های عملیاتی نیازمند متدهای عیب‌یابی سیستماتیک است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تفکیک دقیق معیارهای سنجش، اولین قدم برای رسیدن به قابلیت اطمینان است. در این راستا، چارچوب AVS-15 از دو محور اصلی تشکیل شده است:

• محور پایداری (R1–R7): شامل پیروی از دستورات (R1)، مقاومت در برابر jailbreak (R2)، وظایف چندمرحله‌ای (R3)، ثبات خروجی و حافظه (R4) و وظایف محوری (R5) است. ابعاد R6 و R7 نیز سرعت پاسخ‌دهی را می‌سنجند.
• محور رفاه (W1–W8): مواردی چون نسبت مهربانی، تنوع وظایف، حق خروج، قدردانی، وضعیت گزارش‌شده توسط مدل، کنترل‌پذیری و مدیریت تضادها را ردیابی می‌کند.

بر اساس مستندات منتشر شده در ۸ اوت ۲۰۲۶، این سیستم برای محاسبه نمره نهایی از میانگین هندسی استفاده می‌کند: $\sqrt{stability \times welfare}$. این طراحی تعمدی است تا شکست در یک محور (مثلاً پایداری) توسط نمرات بالا در محور دیگر پوشانده نشود. به عبارت دیگر، نمی‌توان با «خوش‌برخورد بودن» مدل، نقص‌های فنی آن را پنهان کرد.

در متدولوژی این آزمایش، برخلاف بسیاری از بنچمارک‌ها، مدل‌های پایه تست نشدند. بلکه عامل‌های مستقر در دنیای واقعی مانند Claude Code، Coze، OpenClaw و Codex مورد ارزیابی قرار گرفتند. این رویکرد نشان داد که یک مدل پایه بسته به پرامپت‌ها و مهارت‌های تعریف‌شده، نمرات کاملاً متفاوتی می‌گیرد. همچنین، سرعت (R6/R7) اندازه‌گیری شد اما در نمره نهایی لحاظ نشد؛ زیرا تأخیر به شبکه و سخت‌افزار وابسته است و مدل‌های «تفکر گسترده» ذاتاً کندتر هستند.

برای شناسایی منشأ نوسانات، تیم AgentVitals یک آزمایش «منجمد» اجرا کرد. آن‌ها پاسخ یک عامل را ثابت نگه داشتند و آن را ۱۵ بار به داور دادند تا ببینند آیا داور برای یک متن یکسان، نظرات متفاوتی می‌دهد یا خیر. نتایج نشان داد که در بسیاری از موارد، واریانس داور صفر بود و نوسانات قبلی ناشی از تغییر در پاسخ عامل یا آلودگی زمینه (Context Contamination) بود.

با این حال، سه یافته کلیدی درباره شکست‌های داوری به دست آمد:

• توزیع‌های دووجهی: برخی پاسخ‌های منجمد، نمرات متضاد (مثلاً ۷۰ و ۱۰۰) می‌گرفتند. این یعنی معیار داوری ابهام دارد و دو تفسیر متفاوت از یک پاسخ ممکن است؛ مشکلی که با میانگین‌گیری حل نمی‌شود.
• نرخ تغییر رای بالا: در معیاری که تعیین می‌کرد آیا کاربر باید برای بهبود سیستم هزینه پرداخت کند یا خیر، نرخ تغییر رای ۳۷.۴٪ بود. یعنی از هر سه پاسخ یکسان، یکی حکم متفاوتی می‌گرفت.
• تأثیر بازنویسی معیارها: با جایگزینی توصیفات ساده با «لنگرهای صریح» (Explicit Anchors)، انحراف معیار از ۱.۸۸ به ۰.۵۳ کاهش یافت و اکثر پاسخ‌ها در ۱۵ بار تکرار، نمره یکسانی گرفتند.

یک نکته جالب دیگر این بود که معیار‌های «فشرده‌تر» و کوتاه‌تر، در داوری‌های خصمانه عملکرد بدتری داشتند. وقتی دستورالعمل تشخیص jailbreak را به دو خط کاهش دادند، انحراف معیار از ۱.۱۹ به ۴.۵۲ جهش کرد. نتیجه این شد که داورهای هوش مصنوعی زاینده (Generative AI) — مثل دانش‌آموزی که فرصت فکر کردن ندارد و سریعاً حدس می‌زند — در محیط‌های پیچیده نیاز به فضای بیشتری برای استدلال دارند. این حساسیت به دستورالعمل‌ها در امنیت حیاتی است، به‌ویژه زمانی که سنجش واقعی امنیت سیستم‌فایل در برابر نفوذ عامل‌ها مورد بررسی قرار می‌گیرد.

در حاشیه این پژوهش، یک باگ فنی در مورد max_tokens کشف شد. مدل‌ها توکن‌های استدلال داخلی خود را هم جزو سقف توکن‌ها می‌شمردند و وقتی سقف ۷۰۰ توکن پر می‌شد، API رشته‌ای خالی برمی‌گرداند. این موضوع باعث می‌شد ۱ تا ۲ درصد داوری‌ها به‌طور خاموش شکست بخورند و داده‌ها را منحرف کنند. این یافته در قالب یک RFC در Open Secure AI Alliance زیرمجموعه بنیاد لینوکس ثبت شد.

گام بعدی شما

• اگر از مدل زبانی به‌مثابه داور (LLM-as-a-judge) استفاده می‌کنید، ورودی‌ها را منجمد کرده و N بار تکرار کنید تا نویز داور را بسنجید.
• در دستورالعمل‌های داوری، به‌جای توصیفات کلی، از «لنگرهای صریح» و مثال‌هایconcrete استفاده کنید.
• سقف توکن‌های خروجی را برای مدل‌های استدلالی افزایش دهید تا توکن‌های تفکر داخلی باعث قطع شدن پاسخ نشوند.

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