بنیادهای ارزیابی عاملهای هوش مصنوعی در حال فروپاشی است. باید بدانید مدلهایی که بهعنوان داور برای نمرهدهی به عاملها به کار میروند، بهطور سیستماتیک غیرقابلاعتماد هستند و اغلب در مواجهه با ورودیهای کاملاً یکسان، رأی خود را تغییر میدهند.
طبق پژوهشی که در ۱۲ سپتامبر ۲۰۲۶ منتشر شد، اکثر محکهای فعلی برای تعیین موفقیت یک وظیفه، به یک مدل «داور» تکیه میکنند. این فرآیند بر این فرض استوار است که اگر خروجی یک عامل را به یک نقطه انتهایی (Endpoint) ثابت بدهید، همیشه نتیجه یکسانی میگیرید؛ اما تحلیل فنی Liu et al. (arxiv:2609.04198v1) ثابت میکند این فرض غلط است.
سازوکار شکست
در اکوسیستم فعلی، چارچوبهایی مانند LangChain، CrewAI و Agentic Security Lab همگی از این الگو پیروی میکنند: یک عامل اجرا میشود، اقداماتش را ثبت میکند و یک مدل جعبهسیاه، حکم «موفقیت» یا «شکست» را صادر میکند.
به نقل از این پژوهش، ارائهدهندگان API مانند OpenAI و Anthropic مدلهای خود را بهصورت خاموش و بدون نسخهبندی بهروز میکنند. این یعنی نقاط انتهایی که «ایستا» به نظر میرسند، در واقع دچار رانش (Drift) میشوند. در نتیجه، رفتار داور میتواند یکشبه و بدون هیچگونه اطلاعی به توسعهدهنده تغییر کند.
زمینه و اثر بر محکهای فعلی
این ناپایداری تقریباً تمام مقایسههای منتشرشده در لیدربوردها را متزلزل میکند. الگوی پیشفرض در سراسر صنعت این است که یک عامل را اجرا کنند، اقدامات را ثبت نمایند و برای ادعای پیشرفت، از یک نقطه انتهایی جعبهسیاه بخواهند که حکمی صادر کند. این تضاد میان نتایج آزمایشگاهی و عملکرد واقعی، دلیل اصلی شکست بسیاری از عاملها در محیطهای عملیاتی است که پیشتر به آن پرداخته بودیم.
همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، تکیه بر زیرساختهای بسته همواره ریسک تغییرات پیشبینینشده را به همراه دارد. این مسئله طیف گستردهای از ارزیابیها، از جمله محکهای استفاده از ابزار (Tool-use) در LangChain، وظایف همکاری در CrewAI و ارزیابیهای باز و بدون ساختار (Open-ended) در Agentic Security Lab را تحت تأثیر قرار داده است. سامانههایی مثل AgentEval و OpenAgents نیز از این قاعده مستثنی نیستند.
کمیسازی ناپایداری
این مطالعه نرخ توافق داخلی (Self-agreement) را برای خروجیهای قطعی عاملها با دمای (Temperature) صفر اندازهگیری کرد. نتایج نشاندهنده شکستی جدی در قابلیت بازتولید است، بهطوری که نرخ توافق در برخی موارد تا ۸۹٪ سقوط کرده است:
- OpenAI GPT-4o (در محک LangChain Tool-Use): میانگین توافق ۸۸٪ (بازه ۸۰٪ تا ۱۰۰٪).
- OpenAI GPT-4o (در Agentic Security Lab): میانگین توافق ۹۱٪ (حداقل ۸۶٪).
- Anthropic Claude-3 (در CrewAI Collaboration): میانگین توافق ۹۰٪ (بازه ۸۴٪ تا ۹۸٪).
به زبان ساده، از هر ۱۰ حکم، احتمالاً یک مورد متناقض است. این مشاهدات طی یک بازه ۲۴ ساعته و با استفاده از ۳۰ نمونه برای هر چارچوب به دست آمده است. این یعنی اگر دو عامل با اختلاف اندکی (مثلاً ۸۲٪ در برابر ۸۴٪) رتبهبندی شوند، این رتبه عملاً نتیجهی یک پرتاب سکه است، نه برتری فنی.
شکست راهکارهای موقت
پژوهشگران دریافتند که ترفندهای رایج صنعت، مشکل ریشهای را حل نمیکنند. مهندسی پرامپت (Prompt Engineering)، پرامپتنویسی با چند نمونه (Multi-shot) و نرمالسازیهای تقریبی (Fuzzy Normalization) شاید تصادفی بودن را پنهان کنند، اما رانش نقطه انتهایی را از بین نمیبرند. برای حل این مشکل، برخی رویکردها جایگزینی کد قطعی با متن را برای حذف ناپایداری داوران پیشنهاد دادهاند.
نگاشتهای «بله/خیر» (Yes/No mapping) نیز یکی دیگر از تاکتیکهای رایج است که بدون رفع تصادفی بودن، تنها مسئله را ماسک میکند. حتی نمونهگیری مکرر نمیتواند سیستمی را که در حالت پایه غیرقطعی است، جبران کند. هیچ مقدار بذر (Seed) هوشمند یا رایگیری چند-داوری (Multi-rater voting) نمیتواند شکست در سطح زیرساخت را ترمیم کند.
برای جامعه فنی، این یافته فرض بنیادی بنچمارکینگ را تغییر میدهد. هر لیدربوردی که بدون نسخهبندی سختگیرانه به نقاط انتهایی جعبهسیاه تکیه کند، در واقع «روی شن» ساختمان میسازد. فقدان خروجیهای خام داوران و عدم قابلیت بازتولید عینی به این معناست که ادعاهای برتری اغلب بدون پشتوانه هستند.
بازتولید رانش
نویسندگان برای اثبات این ادعا، یک اسکریپت پایتون (judge_replay.py) و مجموعهای از دادهها را در گیتهاب (github.com/your-org/agent-llm-judge-reliability) منتشر کردهاند. این اسکریپت به توسعهدهندگان اجازه میدهد خروجیهای ذخیرهشده عاملها را مجدداً از طریق APIهای OpenAI و Anthropic اجرا کنند تا نرخ توافق داخلی را محاسبه نمایند.
توسعهدهندگان میتوانند این ابزار را با ۱۰ نمونه یا بیشتر از وظایف هر چارچوب به کار ببرند تا احکام هر اجرا را ثبت کرده و ناپایداری را شخصاً مشاهده کنند. برای کسانی که به دنبال پایداری در محیط عملیاتی هستند، تبدیل خطاهای واقعی به رگرسیونهای تست یکی از موثرترین روشهای مقابله با این نوسانات است.
توصیه میشود توسعهدهندگان اولویت خود را به داورهای با وزنهای باز (Open Weights) یا چارچوبهای ارزیابی محلی تغییر دهند که در آنها وزنهای مدل منجمد (Frozen) هستند. تا زمانی که ارائهدهندگان API نسخهبندی تغییرناپذیر (Immutable Versioning) ارائه ندهند، نمیتوان به بهبودهای تکرقمی در لیدربوردهای عاملها اعتماد کرد.
گام بعدی شما
- اگر از مدلهای API برای ارزیابی استفاده میکنید، خروجیهای داور را در بازههای زمانی مختلف ذخیره و نرخ توافق داخلی را بسنجید.
- برای ارزیابیهای حساس، به جای مدلهای بسته، از مدلهای محلی با وزنهای باز (مانند Llama 3 یا Mistral) استفاده کنید تا از ثبات نتایج مطمئن شوید.
- در گزارشهای فنی خود، به جای ذکر یک عدد مطلق، بازه عدمقطعیت (Confidence Interval) را برای نتایج ارزیابی ذکر کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو