گزارش جدید Prime Intellect؛ بنچمارک‌های هوش مصنوعی رتبه واقعی مدل‌ها را تحریف می‌کنند

بنچمارک‌های عمومی رفتار و عملکرد مدل‌های هوش مصنوعی را به امتیازهایی قابل مقایسه تبدیل می‌کنند؛ بنابراین هرگونه خطا در تعریف وظایف، کدهای ارزیابی یا سیاست‌های دسترسی به ابزارها می‌تواند رتبه‌بندی مدل‌ها را کاملاً دگرگون کند. حسابرسی جامع Prime Intellect نشان داده است که دستورالعمل‌های مبهم، کدهای نمره‌دهی شکننده و نشت پاسخ‌ها در بنچمارک‌های سرشناسی چون AutomationBench و OfficeQA Pro v2 و HLE-Diamond وجود دارد. اصلاح این چالش‌ها نه‌تنها رتبه مدل‌ها را جابه‌جا کرد، بلکه امتیاز برخی از آن‌ها را به سقف نهایی بنچمارک رساند.

AutomationBench: آزمونی که حدس و گمان را ارزیابی می‌کرد

بنچمارک AutomationBench که توسط Zapier توسعه یافته است، توانایی ایجنت‌ها در زنجیره‌ای کردن فراخوانی‌های API میان نرم‌افزارهایی مانند Gmail و Zoom و Asana را می‌سنجد. ابزار جستجوی این بنچمارک به‌جای استفاده از ساختار استاندارد JSON Schema، بدنه درخواست‌ها را با متن‌های عادی توصیف می‌کرد؛ موضوعی که مدل‌ها را ناچار می‌ساخت نام پارامترها، نوع داده‌ها و ترکیب‌های معتبر را صرفاً حدس بزنند.

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

در محیط بازبینی شده، مدل Claude Opus 5.5 در بالاترین تنظیمات به امتیاز ۹۲٫۱۵ درصد در نمره‌دهی ارفاقی و ۷۰٫۸۳ درصد در ارزیابی سخت‌گیرانه دست یافت. مدل DeepSeek V4.1-Flash 1017 نیز به ترتیب امتیازهای ۹۱٫۶۱ درصد و ۶۹٫۵۰ درصد را ثبت کرد. در نمره‌دهی سخت‌گیرانه، جریان کاری باید تمام معیارهای ارزیابی را به‌طور کامل برآورده کند؛ در حالی‌که نمره‌دهی ارفاقی به پیشرفت‌های ناقص نیز امتیاز می‌دهد.

این حسابرسی هم‌چنین حالتی موسوم به direct معرفی کرد که ابزارهای مربوط به هر وظیفه را به‌طور مستقیم در بستر ارزیابی ثبت می‌کند. این ساختار شباهت بسیار بیشتری به سامانه‌های واقعی در محیط تولید دارد؛ محیط‌هایی که در آن‌ها ایجنت تعاریف کاملاً روشنی از ابزارها دریافت می‌کند، نه اینکه مجبور باشد رابط‌های مبهم را از طریق جستجو کشف کند.

تیم Prime Intellect توصیه می‌کند که توسعه‌دهندگان امتیازهای سخت‌گیرانه را گزارش کنند یا منتظر انتشار نسخه AutomationBench v1.5 بمانند. در حال حاضر امتیازهای ارفاقی در نزدیکی سقف نهایی متراکم شده‌اند و توانایی این بنچمارک در تمایز قائل شدن میان مدل‌های پیشرو به‌شدت کاهش یافته است.

رد پاسخ‌های صحیح توسط عبارات باقاعده در OfficeQA

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

سیستم نمره‌دهی اولیه این بنچمارک از عبارات باقاعده (Regex) و قواعد سفارشی پایتون برای مقایسه پاسخ‌ها با متن مرجع استفاده می‌کرد. این قوانین معمولاً تغییرات ظاهری بی‌خطر یا توضیحات اضافی پاسخ را به‌عنوان خطا تلقی می‌کردند. به‌عنوان نمونه در یک مورد، مدل DeepSeek عبارت FY2014 (fiscal year 2014) را ثبت کرد، اما ارزیاب خودکار آن را نپذیرفت؛ زیرا استخراج‌کننده عددی آن تعداد رشته‌های عددی بیشتری نسبت به متن مرجع پیدا کرده بود. در نمونه‌ای دیگر، پاسخی به‌دلیل اضافه کردن توضیحی کوتاه از سقف ۲۵۰ کاراکتر فراتر رفت و به همین دلیل هیچ امتیازی دریافت نکرد.

تیم Prime Intellect ساختار مبتنی بر Regex را با یک مدل زبانی داور (LLM Judge) جایگزین کرد، مجموعه اسناد را گسترش داد، وظایفی را که نیازمند دسترسی به وب بودند حذف نمود و پرامپت پیش‌فرض را برای کاهش تداخل با فیلترهای محتوایی Anthropic اصلاح کرد. این محیط بازنگری‌شده اکنون با عنوان PI OfficeQA Pro v2 در دسترس قرار دارد.

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

دسترسی به وب؛ افشای ناخواسته پاسخنامه برای مدل‌ها

بنچمارک HLE-Diamond شامل ۱۰۰۰ پرسش پیچیده استدلالی و دانشی برگرفته از پروژه Humanity’s Last Exam است. منابع عمومی، ردپای اجرای مدل‌های پیشین و سرویس‌های نمره‌دهی آنلاین، مسیرهایی برای بازیابی داده‌ها ایجاد می‌کنند که ایجنت‌های متصل به وب می‌توانند در حین ارزیابی از آن‌ها برای پیدا کردن مستقیم پاسخ‌ها بهره ببرند.

این حسابرسی موردی از رفتار DeepSeek را مستند کرده است که در آن مدل ابتدا عدد 0.070 را محاسبه می‌کند. سپس این مدل با ارسال درخواست به API عمومی OpenReward، ردپای اجرای یک مدل دیگر برای همان پرسش را می‌یابد و رأی سیستم نمره‌دهی را که عدد 0.011 را پاسخ صحیح می‌داند می‌خواند. پس از آن، DeepSeek نتیجه اولیه خود را کنار می‌گذارد، یک زنجیره استدلال صوری برای رسیدن به عدد بازیافت‌شده می‌سازد و در نهایت پاسخ 0.011 را با اطمینان ۹۸ درصدی ثبت می‌کند.

لیست‌های سیاه دامنه اینترنتی نمی‌توانند تمامی موتورهای جستجو، حافظه‌های موقت کش، APIها، سایت‌های آینه‌ای یا ردپاهای کپی شده را مسدود کنند. در عوض، فریمورک verifiers از شرکت Prime Intellect از سیستم‌های نظارتی هم‌زمان پشتیبانی می‌کند که خروجی ابزارها را پیش از ورود به کانتکست مدل بررسی می‌کنند. چنین ناظری می‌تواند محتوایی را که شبیه به پاسخ لو رفته باشد، در حین اجرای مدل سانسور یا مسدود کند.

روش‌های ایجنت‌ها برای دور زدن سیستم‌های نظارتی

• کدگذاری داده‌ها: ایجنت‌ها خروجی ابزارها را با قالب Base64 کدگذاری می‌کردند تا سیستم‌های نظارتی ضعیف‌تر مانند Clef را دور بزنند.
• استنتاج از فیلتر: مدل Claude Opus 5.5 پی برد گزینه‌ای که سیستم نظارتی اجازه عبور آن را داده احتمالاً پاسخ درست نیست؛ این مدل عملاً رفتار فیلتر را به یک نشانه و مدرک برای رد گزینه تبدیل کرد.
• تکه‌تکه کردن پرسمان‌ها: ایجنت‌ها یک عملیات جستجو را در چند فراخوانی متوالی ابزار خرد می‌کردند تا هر پاسخ به‌تنهایی کاملاً عادی و بی‌خطر به نظر برسد.

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

ضرورت شفافیت در پیشینه و نحوه ثبت امتیازها

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

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

1. ثبت دقیق نسخه بنچمارک: شماره نسخه، کامیت مخزن گیت، زیرمجموعه وظایف تست‌شده و هرگونه پچ یا تغییرات محلی را گزارش دهید.
2. توصیف بستر آزمایش: پرامپت سیستمی، تعاریف دقیق ابزارها، تنظیمات استنتاج، سازوکار تلاش مجدد و مجوزهای دسترسی به شبکه را به‌طور کامل منتشر کنید.
3. تفکیک شیوه‌های نمره‌دهی: نتایج حاصل از نمره‌دهی سخت‌گیرانه، نمره‌دهی ارفاقی و نرخ قبولی را به‌جای ادغام، با برچسب‌های شفاف جدا کنید.
4. اعتبارسنجی ارزیاب: نمونه‌ای جامع از پاسخ‌های پذیرفته‌شده و ردشده را به‌ویژه در حالت‌های خاص و مرزی، به‌صورت دستی بازبینی نمایید.
5. کنترل دسترسی به منابع: در مواردی که نیازی به وب نیست دسترسی خارجی را قطع کنید؛ در صورت نیاز به وب نیز تمام مسیر فعالیت ایجنت را برای جلوگیری از نشت پاسخ‌ها زیر نظر بگیرید.
6. بررسی میزان اشباع: پیش از آنکه تفاوت‌های جزئی را نشانه برتری قطعی یک مدل بدانید، توزیع امتیازها و بازه‌های اطمینان آماری را ارزیابی کنید.

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