موضوع
۵۵ مقاله با این موضوع (به انگلیسی Benchmarks & evals). جستجو و فیلتر در همین موضوع
مقاله‌ی OfficeTown: Generative Organizations for Evolving Agent Intelligence (16 Oct 2026، مایکروسافت ریسرچ آسیا؛ Hongchen Wei، Daohong Ying و همکاران) مسئله: بیشتر بنچمارک‌های ایجنت هر کار را جدا و از صفر می‌دهند. در یک شرکت واقعی کار این‌طور پیش نمی‌رود: درخ
خلاصه‌ی فارسی هنوز نوشته نشده است.
بنچمارکی برای «آخرین مایل» تحویل هوش مصنوعی: کار واقعی با مشتری، نه تسک خوش‌تعریف
بنچمارک‌های ایجنت معمولاً تسک‌های خوش‌تعریف دارند: یک ایشو، یک مشخصات یا یک تیکت. اما تحویل یک سیستم به مشتری واقعی فرق دارد. مهندسی که در محل مشتری کار می‌کند باید نیازهای مبهم را روشن کند، روی سیستم زنده کار کند و محدودیت‌هایی را پیدا کند که کسی به زبان نیاو
سنجیدن حافظه‌ی ایجنت با پرسش و پاسخ کافی نیست؛ باید خود حافظه را بازرسی کرد
بنچمارک‌های حافظه‌ی ایجنت معمولاً می‌پرسند آیا جواب ایجنت به سؤال درست است، و از روی آن درباره‌ی کیفیت حافظه قضاوت می‌کنند. اما این روش سه چیز را با هم قاطی می‌کند: درستی حافظه، کیفیت بازیابی و کیفیت تولید جواب. گاهی جواب درست است در حالی که حافظه خراب است (مد
مدل کوچکی که فقط کارش نوشتن در حافظه‌ی بلندمدت است و در چند سیستم حافظه کار می‌کند
سیستم‌های حافظه‌ی بیرونی برنامه‌های مدل زبانی را از محدودیت پنجره‌ی کانتکست فراتر می‌برند، اما کیفیتشان به مدلی بستگی دارد که در حافظه می‌نویسد: چه چیزی نگه داشته شود، با چه دقتی و شواهد تازه چطور وضعیت قبلی را به‌روز کند. معمولاً یک مدل زبانی عمومی بزرگ با پر
ساختن محیط‌های تمرین برای ایجنت‌های تحلیل داده از صفر: اول دنیای پشت فایل‌ها، بعد خود فایل‌ها
ایجنت‌های داده با کدنویسی فایل‌های ناهمگون را پردازش می‌کنند و از آن‌ها نتیجه‌ی تحلیلی می‌گیرند. آموزش این ایجنت‌ها در مقیاس بزرگ سخت است: ساختن محیط گران است، داده‌ی واقعی محدودیت حریم خصوصی و مالکیت دارد، و بررسی درستی یافته‌های باز وقتی حقیقت پشت داده معلوم
ارزیابی ایجنت‌های دارای وضعیت با یک پرونده‌ی ارزیابی که شواهدش قابل بازرسی است
تمام شدن یک تسک به‌تنهایی نشان نمی‌دهد ایجنتی که وضعیت را تغییر می‌دهد (مثلاً سفارش ثبت می‌کند یا پول برمی‌گرداند) همه‌ی تعهداتش را انجام داده است. یک حکم ثبت‌شده هم تضمین نمی‌کند شواهد پشتش هنوز معتبر باشد؛ مثلاً ممکن است داده‌ای که ارزیابی بر آن تکیه کرده بع
بنچمارکی که نشان می‌دهد بخش بزرگی از شکست ایجنت‌های ابزاری از بودجه‌ی هارنس است، نه از مدل
نمره‌ی موفقیت یک ایجنت ابزاری هم به مدل بستگی دارد و هم به بودجه‌های هارنسی که اجرایش می‌کند، مثل سقف توکن خروجی یا تعداد مجاز فراخوانی. معمولاً این دو از هم جدا نمی‌شوند و شکست به گردن مدل می‌افتد. بنچمارک ToolBottleneckBench تسک‌های سازمانی ساختگی را ثابت نگ
مقاله‌ی Skip the Compressor: Coding Agents Fix More Issues When They Pick Whole Files (15 Oct 2026، دانشگاه ایلینوی اربانا-شمپین؛ Xiaocong Yang، Rishit Chatterjee و همکاران) مسئله: یک ریپوی واقعی خیلی بزرگ‌تر از پنجره‌ی کانتکست ایجنت است، پس باید تصمیم گرفت کد
چهار ایجنت کلاد یک مدل پایه‌ی خام را خودشان پس‌آموزش دادند و به سطح نسخه‌ی رسمی رساندند
«خودبهبودی بازگشتی»، یعنی ساخته شدن سیستم‌های قوی‌تر هوش مصنوعی به دست خود هوش مصنوعی، را هنوز نمی‌شود مستقیم اندازه گرفت. نویسنده‌ها نسخه‌ی ضعیف‌تر و قابل سنجشی را بررسی می‌کنند: آیا ایجنت‌های پیشرو می‌توانند یک مدل پایه‌ی کوچک و خام را فقط با داده‌ی عمومی پس
یک تکنیک مهندسی کانتکست برای یک ایجنت نجات‌بخش است و برای ایجنت دیگر مضر
جواب دادن به سؤال روی داده‌های ناهمگون یعنی ترکیب شواهد از فایل‌ها، پایگاه داده، اسناد و وب. ایجنت‌های داده این کار را خودکار می‌کنند و موفقیتشان به کانتکست بستگی دارد. سه تکنیک مهندسی کانتکست رایج‌اند: «لایه‌ی معنایی» که داده را توصیف می‌کند، «ارکستراسیون» که
پلتفرم بازی برای ارزیابی و آموزش ایجنت‌های رابط گرافیکی در موبایل، کامپیوتر و وب
یادگیری تقویتی برخط با پاداش قابل بررسی، در ریاضی، کدنویسی و کار با ابزار پیشرفت سریعی آورده، اما گسترش آن به ایجنت‌های رابط گرافیکی سخت است: محیط‌های تعاملی گران‌اند و تسک‌های آموزشی واقع‌گرا کم‌اند. کارهای قبلی اپ و تسک تازه ساخته‌اند ولی نه کد آموزش را منتش
تکامل اسکیل‌های ایجنت بدون دور ریختن نسخه‌های نیمه‌کاره‌ای که فعلاً نمره‌ی کمتری دارند
اسکیل‌ها دانش روالی را به ساخته‌هایی قابل استفاده‌ی دوباره تبدیل می‌کنند و «تکامل اسکیل» آن‌ها را با بازخورد اجرا بهتر می‌کند. اما بهبود گاهی به چند ویرایش وابسته به هم نیاز دارد؛ مثلاً اول باید قدم نصب را درست کرد و بعد قدم پیکربندی، و نسخه‌ی میانی ممکن است م
دنیا منتظر نمی‌ماند: سنجیدن ایجنت‌ها وقتی بازی در حین فکر کردنشان ادامه دارد
ایجنت‌های مدل زبانی کارهای تعاملی پیچیده را حل می‌کنند، اما استدلال و فراخوانی ابزار زمان می‌برد. در محیطی که مدام تغییر می‌کند، یک عمل درست ممکن است خیلی دیر برسد؛ مثلاً در یک بازی، تا مدل تصمیم بگیرد به کدام سمت برود، مانع رسیده است. بیشتر بنچمارک‌ها محیط را
خلاصه‌ی فارسی هنوز نوشته نشده است.
هارنس قوی فاصله‌ی مدل‌ها را کم می‌کند: تبدیل قانون‌های ایالتی آمریکا به XML دقیق
بازتولید محتوای حقوقی باید دقیقاً با منبع یکی باشد: سلسله‌مراتب بخش‌ها، متن عینی، ارجاع‌ها و بازه‌ی اصلاحیه‌ها. یک ارجاع جاافتاده یا اصلاحیه‌ی غلط‌برچسب‌خورده مستقیم به محصولاتی می‌رسد که وکیل‌ها به آن‌ها تکیه می‌کنند. نویسنده‌ها یک خط لوله‌ی صنعتی را که قانون
بنچمارکی برای سنجیدن این‌که ایجنت‌ها قاعده‌های تخصصی را در سناریوهای پراکنده در چند فایل درست پیدا و اعمال می‌کنند
مدل‌های زبانی بیشتر و بیشتر سراغ کارهای واقعی در حوزه‌های تخصصی می‌روند، اما پیدا کردن و درست اعمال کردن قاعده‌های آن حوزه وقتی اطلاعات سناریو در چند فایل پخش شده سخت است. مثلاً برای این‌که بفهمی یک کارمند مرخصی تشویقی می‌گیرد یا نه، باید آیین‌نامه، سابقه‌ی کا
یادگیری از ادامه‌ی واقعی یک «اوراکل» از همان وضعیتی که ایجنت به آن رسیده
یادگیری تقویتی برای کارهای طولانی محدود به آینده‌هایی است که سیاست فعلی می‌بیند. اگر اجراها هیچ‌وقت به رفتار مفید نرسند، هیچ روش تقسیم اعتباری نمی‌تواند برای وضعیت‌ها و عمل‌هایی که اصلاً دیده نشده‌اند نظارت بدهد. روش‌های تقطیر روی سیاست راهنمایی معلم را روی وض
داورهای فراخوانی ابزار به مرجع متنی تکیه می‌کنند و مقدار درستی را که منبعش دیده نمی‌شود رد می‌کنند
داورهای فراخوانی ابزار مقدار آرگومان‌هایی را که ایجنت پیشنهاد داده ارزیابی می‌کنند. نویسنده‌ها دیدند وقتی در ورودی داور هیچ متنی نیست که بگوید مقدار باید چه باشد، داور مقدار درست را کمتر می‌پذیرد. این در سه حالت پیش می‌آید: مقدار پیش‌فرض طرح‌واره‌ی تابع است که
ایجنت‌ها با تسک‌های مبهم یا ناقص چه می‌کنند؟ بنچمارکی روی ترکیب‌های مختلف مدل و هارنس
تعریف مبهم یا ناقص تسک هم اجرا را برای ایجنت سخت می‌کند و هم پرسیدن سؤال روشن‌کننده را. اما واکنش ایجنت‌ها به این شکاف‌های اطلاعاتی در مدل‌ها و هارنس‌های مختلف به‌خوبی شناخته نشده است؛ مثلاً اگر کاربر نگوید خروجی باید با چه قالبی ذخیره شود، ایجنت می‌پرسد، حدس
آیا ایجنت‌ها وقتی از آن‌ها خواسته شود فراموش می‌کنند؟ بنچمارکی برای حذف حافظه که تقریباً هیچ سیستمی از آن رد نمی‌شود
حافظه‌ی بلندمدت جزء اصلی ایجنت‌های مدل زبانی شده است. وقتی ایجنت در استفاده‌ی طولانی اطلاعات شخصی جمع می‌کند، کاربران بیشتر از آن می‌خواهند واقعیت‌های حساس یا کهنه را حذف کند؛ مثلاً «آدرس قبلی‌ام را فراموش کن». سیستم حافظه باید دقیقاً همان را حذف کند و بقیه را
مقاله‌ی DuoDiscover: Scaling Autonomous Discovery Beyond the Evaluation Bottleneck (12 Oct 2026، گوگل با دانشگاه‌های برکلی و استنفورد؛ از جمله یون استوئیکا و توماس فیستر) مسئله: وقتی به ایجنت کدنویس می‌گویی کدی را سریع‌تر کند، مثلاً یک کرنل جی‌پی‌یو یا موتور س
سخت‌تر کردن بازگشتی محیط‌های بنچمارک بدون تغییر هدف تسک، برای ارزیابی و آموزش ایجنت
بنچمارک‌های ایجنتی زود اشباع می‌شوند و ساختن بنچمارک تازه گران است. نویسنده‌ها راه دیگری بررسی می‌کنند: سخت‌تر کردن محیط یک بنچمارک موجود، در حالی که هدف اصلی تسک ثابت می‌ماند. مثلاً همان تسک «گزارش ماهانه را بساز»، ولی این بار داده‌ها در دو منبع جدا هستند و ی
مقاوم کردن خودکار بررسی‌کننده‌های محیط‌های ایجنتی در برابر تقلب، با حلقه‌ی هکر و ترمیم‌کار
محیط‌های ایجنتی با بررسی‌کننده‌های برنامه‌ای، نتیجه‌های پیچیده را به پاداش تبدیل می‌کنند. اما می‌شود به این بررسی‌کننده‌ها حمله کرد تا به ایجنتی که تسک را انجام نداده و تقلب کرده نمره‌ی کامل بدهند؛ مثلاً ایجنت به جای درست کردن کد، فایل تست را عوض کند. این هم ا
اجازه‌ی تکرار با بازیابی موفق فرق دارد: ایجنت‌ها گاهی فراخوانی ابزار را بی‌پشتوانه تکرار می‌کنند
وقتی فراخوانی یک ابزار به مهلت زمانی می‌خورد، ایجنت باید تصمیم بگیرد آن را دوباره بفرستد یا نه. اگر قرارداد ابزار اجازه‌ی تکرار امن را ندهد، تکرار می‌تواند کار را دو بار انجام دهد؛ مثلاً یک پرداخت دو بار ثبت شود. نویسنده‌ها این خطا را «اجازه‌ی تکرار نادرست» می
حلقه‌ی خودبهبودی برای ایجنت‌های هارنس، بدون مدل معلم بیرونی
ایجنت‌های مدل زبانی امروز در هارنس‌های عمومی کار می‌کنند و مستقیم با فایل‌ها و شل سروکار دارند. خط لوله‌های پس‌آموزش این ایجنت‌ها کم‌اند و بیشترشان یک‌باره و وابسته به معلم‌اند: یک مدل قوی‌تر بیرونی تسک و مسیر می‌سازد، مدل هدف یک بار آموزش می‌بیند و نتیجه‌ی ار
آیا کارخانه‌ی نرم‌افزار می‌تواند بدون ناظر انسانی کار کند؟ سنجش ایجنت‌های بازبینی کد در یافتن باگ
با پیشرفت ایجنت‌های کدنویسی، برنامه‌نویس‌ها بیشتر وقتشان را صرف بازبینی کد می‌کنند تا نوشتن آن. چون سرعت بازبینی انسان از تولید کد عقب افتاده، وسوسه‌ی ساختن ایجنت‌های بازبینی خودکار و «کارخانه‌ی چراغ‌خاموش» بدون نظارت انسانی وجود دارد. سؤال این است که این ایده
آیا ایجنت‌های کدنویسی می‌توانند ایجنتی را که واقعاً می‌خواهید بسازند؟ فاصله‌ی بین نمایش و تحویل
ایجنت‌های کدنویسی بیشتر مأمور ساختن ایجنت‌هایی برای گردش کار کاربرانشان می‌شوند. این واگذاری فرض می‌کند ایجنت تحویلی واقعاً نیازی را که برایش ساخته شده برآورده می‌کند، نه این‌که فقط ظاهرش این‌طور باشد. هیچ بنچمارکی این فرض را نمی‌آزمود. بنچمارک AgentSWE سه مرح
تکامل با فراتأمل: بهینه‌ساز تکاملی که کل تاریخچه‌ی جست‌وجو را می‌خواند و سیستم زنده را کاوش می‌کند
بهینه‌سازی تکاملی با هدایت مدل زبانی پرامپت‌ها، برنامه‌ها و حتی کل سیستم‌های هوش مصنوعی را بهتر کرده است. بیشتر روش‌ها یک نامزد را از مرز جست‌وجو انتخاب می‌کنند و فقط بر اساس شکست‌هایش آن را در یک گذر مدل جهش می‌دهند. این تمرکز روی مرز در سیستم‌های تولیدی متوق
میدان دوئل مهندسی نرم‌افزار: بنچمارکی خودمقیاس که در آن ایجنت‌های کدنویسی برای هم باگ می‌کارند و رفع می‌کنند
بنچمارک‌های ثابت کدنویسی در لحظه‌ی انتشار منجمد می‌شوند؛ با گذر زمان تسک‌هایشان به داده‌ی آموزشی نشت می‌کند و ایجنت‌های قوی‌تر اشباعشان می‌کنند. نویسنده‌ها استدلال می‌کنند بنچمارک باید خودمقیاس باشد: تسک‌ها و داورها در زمان ارزیابی ساخته شوند تا چیزی از قبل بر
منشور تست: ارزیابی تست‌های تولیدشده فراتر از یک پیاده‌سازی مرجع واحد
ایجنت‌های کدنویسی در تولید تست پیشرفت کرده‌اند، اما رویه‌ی رایج ارزیابی تست‌ها در برابر یک راه‌حل مرجع واحد، پیاده‌سازی‌های معتبر جایگزین را نادیده می‌گیرد و کیفیت تست را بیش از واقع نشان می‌دهد. مثلاً تستی که فقط با ترتیب خروجی مرجع کار می‌کند، یک پیاده‌سازی
نگاهی دقیق‌تر به بهینه‌سازی جعبه‌سیاه ایجنتی: بنچمارکی میان‌دامنه‌ای برای ایجنت‌های بهینه‌ساز
بهینه‌سازی جعبه‌سیاه در بسیاری از مسئله‌های علمی و مهندسی پیش می‌آید که هر ارزیابی هدف گران و محدود است، مثل تنظیم پایگاه داده یا طراحی تراشه. ایجنت‌های مدل زبانی با ترکیب معنای تسک، محاسبه، ابزارهای بهینه‌سازی و تصمیم‌گیری مبتنی بر بازخورد راه تازه‌ای پیشنهاد
ایوآلوک: ایجنت خودتکامل تخصیص منابع که ارزیابی‌های گران را در تکامل برنامه هدفمند خرج می‌کند
تکامل برنامه با مدل زبانی برای هدایت جست‌وجوی تکراری به بازخورد ارزیابی متکی است، اما ارزیابی اغلب از نظر محاسباتی گران است، پس باید منابع محدود به نامزدهایی برسد که جست‌وجو را بیشتر پیش می‌برند. روش‌های موجود در کل جست‌وجو یک راهبرد ثابت تخصیص دارند و ممکن اس
تریس: تشخیص شکنندگی تأییدکننده در ارزیابی ایجنت‌ها، تا معلوم شود تغییر امتیاز از ایجنت است یا از سنجش
امتیاز تأییدکننده‌ها هم معیار بنچمارک است و هم پاداش آموزشی ایجنت‌ها، و تغییر امتیاز معمولاً تغییر توانایی خوانده می‌شود. اما ممکن است فقط تغییر در خود ارزیابی باشد؛ مثلاً اگر فقط نام ابزارها عوض شود و امتیاز افت کند، ممکن است قاعده‌ی امتیازدهی به نام‌ها حساس
پژوهش عمیق باز افزایشی با هارنس ساختاریافته: به‌روزرسانی گزارش به جای نوشتن از صفر
سیستم‌های پژوهش عمیق باز عمدتاً گزارش را از صفر تولید می‌کنند، که برای گزارش‌هایی که باید با رسیدن اطلاعات تازه پیوسته نگهداری شوند ناکارآمد است. مثلاً گزارشی درباره‌ی بازار خودروهای برقی هر ماه باید به‌روز شود، اما بازنویسی کامل هر بار هزینه دارد و بخش‌های م
سفر مهندسی نرم‌افزار: ارزیابی واقع‌گرایانه‌تر دستیارهای کدنویسی با تعامل طولانی و چندنوبتی
دستیارهای کدنویسی مثل Claude Code و Codex کاربرد اصلی ایجنت‌ها شده‌اند، اما بنچمارک‌ها از نظر طول تسک و طول تعامل از استفاده‌ی واقعی دورند. در واقعیت دستیار باید زنجیره‌ی طولانی کار توسعه را در مخزنی که پیوسته تغییر می‌کند انجام دهد و بارها نیازها را روشن و پی
فهم کد گلوگاه ایجنت‌های کدنویسی است، نه فقط ویرایش آن
بنچمارک‌های مخزن‌محور مثل SWE-bench اغلب فرض می‌کنند تعداد خطوط ویرایش‌شده سختی تسک را پیش‌بینی می‌کند، اما کنترل ضعیف این داده‌ها روی نوع کد و تسک باعث می‌شود نتوان فهمید کدام توانایی واقعاً خطاهای ایجنت را تعیین می‌کند. مثلاً یک اصلاح یک‌خطی ممکن است نیاز به
مسئله: معمولاً ایجنت را با نتیجه‌ی نهایی می‌سنجیم: کار را تمام کرد یا نه، چقدر سود کرد. اما در محیطی که مدام عوض می‌شود، نتیجه هم به رفتار ایجنت بستگی دارد و هم به شانس و شرایط بیرون. پس از روی نتیجه نمی‌شود فهمید ایجنت در کدام توانایی خوب است: ابزار را درست ص
بنچمارک‌های ایجنت کدنویسی باید با جریان تسک کاربرانشان منطبق باشند
ارزیابی ایجنت‌های کدنویسی می‌کوشد تا حد ممکن واقع‌گرا باشد، اما بنچمارک‌های برگرفته از گزارش‌های مشکل فقط یک نوع درخواست را می‌سنجند. در واقعیت کاربران در یک جلسه سؤال می‌پرسند، برنامه‌ریزی می‌کنند، بازبینی و بازسازی می‌خواهند و مدام بین این نوع‌ها جابه‌جا می
هر فراخوانی مدل پیشرو نمی‌خواهد: ارزیابی مدل‌های کوچک به تفکیک نقطه‌ی فراخوانی در یک سیستم ایجنتی خانه‌ی هوشمند
یک سیستم ایجنتی چند نوع فراخوانی مدل زبانی با ساختار متفاوت دارد: مسیریابی نیت، دسته‌بندی اقدام، اتصال زبان به فهرست دستگاه‌ها، برنامه‌ریزی خط لوله‌های چندایجنتی و نوشتن کد پایتون. سختی این نقطه‌ها تا یک مرتبه‌ی بزرگی فرق دارد، اما در عمل یک مدل که برای سخت‌تر
ترانسکت: حفظ قابلیت مشاهده در ارزیابی‌های بلندمدت ایجنت‌ها با تحلیل قابل بازتولید رونوشت‌ها
ارزیابی‌های هوش مصنوعی پیشرو بیش از پیش از تسک‌های باز، ایجنتی و بلندمدت استفاده می‌کنند که رونوشتشان می‌تواند صدها صفحه خروجی و اقدام از شبکه‌های چندایجنتی پیچیده باشد. پس دامنه‌ی آنچه ارزیاب‌ها می‌توانند به‌طور قابل اعتماد درباره‌ی رفتار ایجنت استنتاج کنند ت
بنچمارک یادبگیر و بازی کن: ایجنت‌ها در محیط‌های ناآشنا چقدر خوب از تجربه یاد می‌گیرند؟
یادگیری از تجربه برای سازگاری ایجنت‌ها با محیط‌های ناآشنا و پویا ضروری است. بنچمارک‌های موجود عمدتاً تسک‌هایی را می‌سنجند که قاعده‌هایشان در دستور آمده یا برای مدل پیش‌آموزش‌دیده آشناست، پس نمی‌شود یادگیری از تعامل را از استدلال با دانش موجود جدا کرد؛ مثلاً ای
بنچمارک واگذاری: سنجش این‌که ایجنت کِی باید پیش از اقدام از کاربر بپرسد
ایجنت‌هایی که ایمیل می‌فرستند، فایل ویرایش می‌کنند و خرید انجام می‌دهند باید تصمیم بگیرند کِی خودشان عمل کنند و کِی اول از کاربر بپرسند. این تصمیم معمولاً با نشان دادن یک اقدام پیشنهادی به مدل و سنجش توافق با برچسب انسانی ارزیابی می‌شود. سؤال این است که آیا ای
مش‌هارنس: هارنس‌های خودبهبود با تکامل ترکیبی ماژول‌ها به هدایت الگوریتم راهزن
هارنس ایجنت کدی است که کانتکست را سازمان می‌دهد، وضعیت را نگه می‌دارد و فراخوانی ابزارها را هماهنگ می‌کند. سؤال این است که چطور می‌شود هارنس را با بودجه‌ی ارزیابی محدود و وزن‌های ثابت مدل بهتر کرد، وقتی فضای ترکیب‌های ممکن بسیار بزرگ است. روش MESH-Harness هر ه
دایادمم: بنچمارک حافظه‌ی بلندمدت درباره‌ی این‌که ایجنت چطور با هر کاربر کار کند
ایجنت‌های بلندمدت باید نه فقط آنچه درباره‌ی کاربر درست است، بلکه این را هم به خاطر بسپارند که یک ایجنت خاص با گذشت تاریخچه‌ی مشترک چطور باید با آن کاربر کار کند؛ مثلاً این‌که کاربر توضیح‌های طولانی را رد کرده یا ترجیح می‌دهد پیش از تغییر فایل‌ها از او اجازه گر
پیدا کردن جفت مناسب: تعامل مدل و هارنس در تسک‌های ایجنتی
انتخاب یک سیستم ایجنتی یعنی انتخاب هم مدل زبانی و هم هارنسی که مدل از طریق آن عمل می‌کند. سؤال این است که آیا یک مدل، هارنس یا جفت قوی وقتی شرایط عوض می‌شود قوی می‌ماند یا نه. نویسنده‌ها ۶۶ پیکربندی را ارزیابی کردند: چهار هارنس قابل پیکربندی، یعنی OpenHands، D
قابلیت اطمینان ارزیابی ایجنت‌ها: تسک بیشتر همیشه جدول رتبه‌بندی را درست نمی‌کند
ارزیابی ایجنت‌ها برای مقایسه‌ی مدل‌ها و تصمیم‌های استقرار به کار می‌رود، اما رتبه‌ها می‌توانند نه فقط مدل بلکه اثر شرایط ارزیابی مثل داربست یا تسک‌ها را هم منعکس کنند. پس قابلیت اطمینان به ادعا بستگی دارد: ارزیابی‌ای که سیستم‌های مستقر را قابل اعتماد رتبه‌بندی
ایجنت چه چیزی را باید به خاطر بسپارد؟ جدا کردن نگهداری از بازیابی در ارزیابی حافظه‌ی محدود
یک ایجنت پایدار باید هم تصمیم بگیرد با رسیدن اطلاعات چه چیزی را نگه دارد و هم وقتی پرسشی آمد چه چیزی را بیرون بکشد. اما ارزیابی‌های حافظه با مقایسه‌ی روش‌هایی که هم در نگهداری و هم در انتخاب فرق دارند، این دو تصمیم را با هم قاطی می‌کنند؛ پس معلوم نیست بهبود گز
کوآ-اسپیدران: بنچمارک استاندارد سرعت ایجنت‌های استفاده از کامپیوتر
ایجنت‌های استفاده از کامپیوتر که با رابط گرافیکی کار می‌کنند، در بسیاری از بنچمارک‌ها از کارایی انسان گذشته‌اند، اما سرعت و هزینه مانع اصلی استقرار گسترده‌شان است. سنجش قابل اعتماد سرعت هم سخت است، چون بنچمارک‌ها روی زیرساخت‌های پیچیده با پیکربندی‌های متفاوت م
اپرا: چارچوب منتقد کلامی برای ایجنت‌های کدنویسی بلندمدت که اصلاح‌ها را تا حل مشکل دنبال می‌کند
ایجنت‌های کدنویسی بلندمدت به اصلاح به‌موقع نیاز دارند، اما بازخورد وقتی کار جاری را اشتباه ارزیابی کند یا به مشکل اصلی نپردازد، بی‌اثر یا حتی مضر است. منتقدهای موجود روی ارزیابی مسیر و تولید بازخورد تمرکز دارند اما به ندرت دنبال می‌کنند پس از رساندن بازخورد چه
اسکلیت: بستری برای آموزش و ارزیابی ایجنت‌های یادگیری پیوسته در افق‌های چندجلسه‌ای
ایجنت‌های یادگیری پیوسته سیستم‌هایی از مدل، هارنس و حافظه‌اند که در افق‌های طولانی چندجلسه‌ای کار می‌کنند. ارزیابی و آموزششان نیاز دارد تسک‌ها با رویدادهای سمت ایجنت مثل توقف و شروع جلسه، کارهای زمان‌بندی‌شده و یکپارچه‌سازی حافظه درهم اجرا شوند. اما بنچمارک‌ها
دلفین‌بنچ: ترسیم مرز پارتوی حافظه‌ی ایجنت با سنجش دقت، هزینه و تأخیر
ایجنت‌ها امروز کنش‌های واقعی انجام می‌دهند که به حافظه‌ی بلندمدت و یادآوری کانتکست وابسته است. اما بیشتر بنچمارک‌های حافظه در قالب پرسش و پاسخ گفت‌وگویی ساخته شده‌اند، جایی که خود پرسش نشان می‌دهد باید چیزی بازیابی شود و اغلب کدام چیز. همچنین بنچمارک‌ها به ندر
وایب‌مم‌بنچ: ارزیابی سیستم‌های حافظه‌ی ایجنت‌های کدنویسی روی تسک‌های واقعی مخزن
ایجنت‌های کدنویسی روی تسک‌های واقعی مخزن کار می‌کنند و سیستم‌های حافظه‌ی پایدار قول استفاده‌ی مجدد از تجربه بین تسک‌ها را می‌دهند. اما ارزیابی‌های موجود نشان نمی‌دهند این سیستم‌ها کار اجرایی روی مخزن را بهتر می‌کنند یا نه: بنچمارک‌های مخزن تغییر کد را می‌سنجند
نسخه‌ی تأییدشده‌ی SWE-Bench Pro: بنچمارک قابل اعتماد برای ایجنت‌های مهندسی نرم‌افزار
بنچمارک SWE-Bench Pro استاندارد ارزیابی ایجنت‌های مهندسی نرم‌افزار روی تسک‌های دشوار سطح مخزن شده است، اما ارزیابی‌اش دو منبع عدم اطمینان دارد: تقلب در پاداش از طریق نشت راه‌حل طلایی یا اطلاعات پنهان ارزیابی، مثلاً خواندن پاسخ از تاریخچه‌ی گیت؛ و مشکلات کیفیت
هو اند وِن پرو: آیا مدل‌های زبانی واقعاً می‌توانند شکست ایجنت‌ها را به علتش نسبت دهند؟
نسبت‌دهی خودکار شکست از مدل‌های زبانی استفاده می‌کند تا مشخص کند سیستم‌های ایجنتی کجا و چرا شکست می‌خورند. با تواناتر شدن ایجنت‌ها، شکست‌هایشان ظریف‌تر و نسبت‌دهی خودکار مهم‌تر می‌شود، اما برای سنجش این توانایی به برچسب‌های طلایی دقیق در مقیاس بزرگ نیاز است. ب