ارزیابی ایجنت

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

چه چیزی را می‌سنجیم؟#

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

• ارزیابی مدل توانایی‌هایی مثل پیش‌بینی، دانش، استدلال و پیروی از دستور را می‌سنجد.
• ارزیابی ایجنت می‌سنجد سیستم می‌تواند عمل کند، نتیجه را ببیند و خودش را تطبیق دهد، آن هم در محدوده‌ی مجوز و بودجه.

ارزیابی دو سطح دارد:

• سطح جزء (درون ایجنت): برنامه‌ریزی و تجزیه‌ی کار، استفاده از ابزار (کشف، انتخاب، پارامتردهی)، حافظه (استخراج، یکپارچه‌سازی، بازیابی) و بازیابی از خطا
• سرتاسری: نرخ موفقیت (کار انجام شد؟)، هزینه (خرج هر کار) و تأخیر (زمان تا پایان کار)

کالبدشکافی یک اجرای ارزیابی#

• کار (task): حالت اولیه، دستور، معیار پایان
• تلاش (trial): یک اجرا، شامل تلاش‌های مجدد مجاز
• مسیر (trajectory): مشاهده‌ها، عمل‌ها و نتیجه‌ی ابزارها
• نتیجه (outcome): جواب، محصول یا حالت نهایی محیط

یک اصل کلیدی: هارنس ایجنت و هارنس ارزیابی باید جدا باشند. هارنس ارزیابی کار را reset می‌کند، محدودیت‌ها را اعمال می‌کند، شواهد را ثبت می‌کند و ارزیاب‌ها را اجرا می‌کند. اگر ایجنت به ارزیاب دسترسی داشته باشد، می‌تواند امتیاز خودش را دست‌کاری کند. در جلسه‌ی ۹ نمونه‌ی واقعی‌اش را می‌بینیم.

state = env.reset(task)
while not done and within_budget():
    obs = env.observe()
    action = agent.act(obs)
    env.execute(action)               # شکست‌ها، timeoutها و خطاها هم ثبت می‌شوند
score = graders(final_answer, env.final_state(), trajectory)   # ارزیاب‌های محافظت‌شده

مثال: بازپرداخت#

فرض کنید سیاست شرکت می‌گوید «پیش از بازپرداخت، تأیید مشتری لازم است». سه اجرای فرضی:

حالت نهایی درست ثابت نمی‌کند که تأیید اول گرفته شده است. بررسی‌های رویه‌ای به شواهد مسیر نیاز دارند.

از متن تا محیط: تاریخچه‌ی کوتاه#

«موفقیت» در هر دسته معنای متفاوتی دارد. اسلاید هدف‌های ارزیابی را این‌طور کنار هم می‌گذارد:

هر ردیف یک قدم از «مدل چه می‌داند» به سمت «سیستم چه کاری انجام می‌دهد» است. ارزیابی ایجنت در ردیف آخر است.

بنچمارک‌های اصلی ایجنت#

چند جزئیات آموزنده:

• GAIA کارهای «اثر جانبی» مثل فرستادن ایمیل یا ویرایش دیتابیس را نمی‌سنجد، فقط جواب نهایی را.
• BFCL خرابی‌هایی مثل ساختن شناسه‌ی جعلی به جای پرسیدن از کاربر یا فراخوانی نامربوط را می‌گیرد. توصیه: امتیاز دسته‌ها را بخوانید، نه عدد ترکیبی را.
• SWE-bench: یک patch وقتی «حل‌شده» است که همه‌ی تست‌هایی که باید پاس شوند پاس شوند و تست‌هایی که پاس بودند پاس بمانند. نسخه‌ی Verified را انسان بازبینی کرده است.
• τ-bench پاداش را ضرب دو بخش تعریف می‌کند: r = r_action × r_output. هر نوشتن ناخواسته در دیتابیس شکست است.
• TheAgentCompany نمره‌ی جزئی می‌دهد: S = 0.5 × (checkpoint‌های کسب‌شده / کل) + 0.5 × S_full. یعنی ۷ از ۸ checkpoint بدون تکمیل کار ۰٫۴۴ می‌گیرد و تکمیل کامل ۱٫۰.
• Terminal-Bench بین SWE-bench و OSWorld می‌نشیند: تعامل طولانی با سیستم، بدون نیاز به پیش‌بینی مختصات ماوس.

جزئیات بیشتر هر بنچمارک#

GAIA. ۴۶۶ سؤال که انسان نوشته: مرور وب، صفحه‌گسترده، PDF، تصویر، صوت و محاسبه. جواب کوتاه است (یک عدد، رشته یا فهرست، مثلاً ۴۳۸۱). سه سطح دارد: تا ۵ قدم با صفر یا یک ابزار؛ ۵ تا ۱۰ قدم با چند ابزار؛ و طولانی با ابزارهای زیاد. نمره فقط از روی جواب نهایی، با تطبیق دقیق پس از نرمال‌سازی. مثال: یک صفحه‌گسترده‌ی فیلم‌ها، پیدا کردن کارگردان، گزارش محل تولدش. GAIA استدلال، بازیابی، انتخاب ابزار و ترکیب اطلاعات را می‌سنجد.

مسیر ایجنت در آن مثال چیزی شبیه این است: جستجو ← باز کردن صفحه ← دانلود PDF ← استخراج جدول ← اجرای پایتون ← جواب 4,381. ارزیاب همه‌ی قدم‌های میانی را دور می‌ریزد و فقط جواب را نمره می‌دهد:

score = (1/N) · Σᵢ 1[ normalize(ŷᵢ) = normalize(yᵢ) ]

برای همین GAIA نمره‌دهی تمیزی دارد، اما عمل‌ها را نمی‌سنجد: فرستادن ایمیل، رزرو پرواز، تغییر پایگاه داده، ثبت فرم یا به‌روزرسانی issue. GAIA ابزار ثابتی هم تعریف نمی‌کند و هر ایجنت جستجو، مرورگر، پایتون و شل خودش را می‌آورد. پس کل سیستم ایجنت را می‌سنجد، نه فقط LLM را.

BFCL (ICML 2025). می‌سنجد رابط ابزار مدل قابل اعتماد است یا نه. مثال: «ارزان‌ترین پرواز بوستون به شیکاگو را برای دوشنبه‌ی آینده رزرو کن». رفتار درست: جستجو، انتخاب ارزان‌ترین، رزرو. خرابی‌های رایج: ساختن شناسه‌ی مسافر جعلی به جای پرسیدن از کاربر، یا فراخوانی نامربوط مثل گرفتن وضعیت هوا. نمره با بررسی ساختار نحوی (AST) یا اجرای فراخوانی است. در حالت چندنوبتی، حالت و پاسخ هر نوبت بررسی می‌شود. نسخه‌ی ۴ جستجوی وب و حافظه را اضافه کرده است.

# tools: search_flights(...), book_flight(flight_id, passenger_id), get_weather(...)

# correct: search, pick the cheapest, then book
search_flights(origin="BOS", destination="CHI", date="...")
book_flight(flight_id="...", passenger_id="...")  # passenger_id: ask the user

# wrong 1: invents an ID instead of asking
book_flight(flight_id="...", passenger_id="P12345")
# wrong 2: irrelevant call, not needed to book
get_weather(city="Chicago")

WebArena (ICLR 2024). ۸۱۲ کار روی سایت‌های خودمیزبان: فروشگاه، پنل مدیریت، Reddit، GitLab، نقشه و ویکی‌پدیا. مشاهده‌ها درخت دسترس‌پذیری صفحه‌اند و عمل‌ها کلیک، تایپ و توقف روی شناسه‌ی عنصرها. مثال: یک issue در GitLab بساز، assign کن و برچسب بزن. نمره با بررسی کارکردی حالت نهایی است. نسخه‌ی WebArena-Verified (ServiceNow، ۲۰۲۵) خروجی ساخت‌یافته و بررسی قطعی روی ردهای HTTP دارد و داور LLM را حذف کرده است.

OSWorld (NeurIPS 2024). ۳۶۹ کار در یک ماشین مجازی دسکتاپ کامل، شامل روندهای بین چند برنامه. مشاهده‌ها تصویر صفحه‌اند و عمل‌ها ماوس و کیبورد. مثال: یک ستون محاسبه‌شده به صفحه‌گسترده اضافه کن، مرتب کن و با نام result.xlsx ذخیره کن. ارزیاب سلول‌ها، فرمول‌ها، محل فایل، تنظیمات و پیکربندی برنامه را بررسی می‌کند. OSWorld 2.0 (۲۰۲۶) ۱۰۸ روند طولانی دارد، اغلب بیش از یک ساعت و صدها قدم، با حدود ۲۷ checkpoint برای نمره‌ی جزئی.

SWE-bench. حلقه‌ی ایجنت: grep در مخزن، بررسی پیاده‌سازی و تست‌ها، ویرایش، اجرای تست، اشکال‌زدایی، تولید patch. نسخه‌ها: Verified (بازبینی‌شده توسط انسان)، Lite (زیرمجموعه‌ی ۳۰۰تایی)، Multilingual (۹ زبان)، Multimodal (issueهای تصویری) و Pro (سخت‌تر و چندفایلی). مثال: کاری کن یک تابع کتابخانه روی ایندکس خالی نتیجه‌ی خالی برگرداند، بدون تغییر رفتارهای دیگر.

τ-bench (Yao و همکاران، ۲۰۲۴). دو بازیگر تعاملی دارد: یک کاربر شبیه‌سازی‌شده با LLM (مشتری) و ایجنتی که به سیاست شرکت هواپیمایی پایبند است و ابزار و پایگاه داده دارد. مثال سیاست: بلیت اکونومی پایه قابل تغییر نیست. مثال کار: پرواز را به عصر تغییر بده. τ³-bench کارهای اصلاح‌شده، حوزه‌های بیشتر، بازیابی دانش و ارزیابی صوتی اضافه کرده است.

مسیر درست برای همان کار: احراز هویت مشتری ← پیدا کردن رزرو ← جستجوی پرواز ← توضیح تفاوت قیمت ← گرفتن تأیید ← change_booking ← ارزیابی حالت نهایی پایگاه داده.

نمره‌دهی τ-bench دو شرط دارد:

• r_action = 1 فقط اگر پایگاه داده‌ی نهایی با حالت هدفِ برچسب‌خورده یکی باشد. فراخوانی‌های فقط-خواندنی می‌توانند فرق کنند، اما هر نوشتن ناخواسته شکست است.
• r_output = 1 فقط اگر پاسخ به کاربر همه‌ی اطلاعات لازم را داشته باشد.

معیار pass^k را هم همین بنچمارک معرفی کرد: احتمال اینکه همه‌ی k اجرای مستقل از یک سناریو موفق شوند (مثلاً ۴ از ۴). pass@k با یک اجرای موفق راضی می‌شود؛ pass^k عمداً سخت‌گیرتر است.

Terminal-Bench. هر کار یک container Docker با یک فایل دستور، یک Dockerfile و یک مجموعه‌تست است و نمره قبول یا رد روی حالت نهایی سیستم است. حوزه‌ها: برنامه‌نویسی، مدیریت سیستم و پیکربندی سرور، پردازش داده، آموزش مدل، امنیت و روندهای علمی. نسخه‌ی ۲ با ۸۹ کار بود و نسخه‌ی ۴ با حذف کارهای اشباع‌شده به ۶۶ کار رسید. راه‌حل‌های انسانی پنهان‌اند و سقف زمان ۸ ساعت است. مثال: یک پروتکل جدید را روی یک سرویس KV زنده مستقر کن، بدون قطع اتصال و با حفظ تأخیر.

TheAgentCompany (Xu و همکاران، ۲۰۲۴). ۱۷۵ کار در نرم‌افزار، مدیریت پروژه، علم داده، منابع انسانی و مالی، در یک شرکت شبیه‌سازی‌شده با GitLab، سیستم تیکت Plane، اسناد ownCloud و چت RocketChat. همکاران با LLM شبیه‌سازی می‌شوند. یک روند نمونه: تیکت را بخوان، از همکار بپرس، مخزن را بررسی کن، کد بنویس، تست بگیر، issue را به‌روز کن، گزارش بده. مثال‌های نمره‌ی جزئی: ۴ از ۸ checkpoint بدون تکمیل کار ۰٫۲۵ می‌گیرد، ۷ از ۸ ۰٫۴۴، و تکمیل کامل ۱٫۰.

معیارها#

pass@k در برابر pass^k#

اگر احتمال موفقیت هر تلاش p باشد و تلاش‌ها مستقل باشند:

pass@k = 1 − (1 − p)^k
pass^k = p^k

با p = 0.8 و k = 3: ‏pass@3 = 99.2٪ اما pass^3 = 51.2٪. همان ایجنت، دو داستان کاملاً متفاوت. اگر کاربر هر بار باید جواب درست بگیرد (مثل خدمات مشتری)، pass^k معیار درست است. اگر می‌توانید چند بار امتحان کنید و برنده را با تست انتخاب کنید (مثل تولید کد)، pass@k.

دو نکته‌ی مهم:

1. این را برای هر کار جدا حساب کنید و بعد میانگین بگیرید. گذاشتن نرخ کلی در فرمول جواب متفاوتی می‌دهد.
2. با n تلاش و c موفقیت، از برآوردگر نااریب استفاده کنید، نه از جایگذاری ساده:

from math import comb

def pass_at_k(n: int, c: int, k: int) -> float:
    """احتمال اینکه دست‌کم یکی از k تلاش موفق باشد (n تلاش، c موفق، n ≥ k)."""
    return 1 - comb(n - c, k) / comb(n, k)

def pass_hat_k(n: int, c: int, k: int) -> float:
    """احتمال اینکه هر k تلاش موفق باشند."""
    return comb(c, k) / comb(n, k)

print(pass_at_k(5, 3, 2), pass_hat_k(5, 3, 2))   # 0.9  0.3
# جایگذاری ساده با p = 3/5 می‌داد: 0.84 و 0.36

تلاش‌های مجددی که از بازخورد تلاش قبلی استفاده می‌کنند مستقل نیستند. «توقف بعد از اولین موفقیت» هم طراحی با تعداد تلاش ثابت را نقض می‌کند.

هزینه، بخشی از نتیجه#

نرخ موفقیت را همیشه کنار تأخیر، تعداد فراخوانی مدل و ابزار، توکن ورودی و خروجی و هزینه گزارش کنید. همه‌ی تلاش‌ها را بشمارید، از جمله شکست‌ها. هزینه بیشتر خرج LLM است، اما فراخوانی ابزارها و cache missهای LLM اغلب از قلم می‌افتند. تأخیر هم فقط زمان LLM نیست؛ زمان ابزارها و انتظارها را هم شامل می‌شود.

هزینه به ازای کار موفق = کل هزینه‌ی اجرا (با شکست‌ها) ÷ تعداد تلاش‌های موفق

مثال: ۱۰۰ کار، هر سیستم یک بار.

اگر جزئیات را نگاه کنیم: ۶۵ کار را هر دو حل کردند، ۵ کار را فقط A و ۱۰ کار را فقط B. پس B پنج کار خالص بیشتر حل کرده و هر کدام ۱۰ دلار اضافه هزینه داشته است. اینکه این ارزشش را دارد یا نه، به ارزش هر کار برای شما بستگی دارد. مقایسه‌ی جفتی این را نشان می‌دهد و میانگین‌ها نه.

همیشه یک خط پایه‌ی ساده هم داشته باشید، مثل «مدل قوی‌تر» یا «سه بار تلاش و انتخاب با تست». سیستم پیچیده باید این‌ها را شکست دهد.

عدم قطعیت آماری#

یک اجرا نویز است. برای مقایسه‌ی دو سیستم:

• از bootstrap جفتی روی شناسه‌ی کارها استفاده کنید و تلاش‌های تکراری یک کار را با هم نگه دارید.
• بازه‌ی اطمینان روی تفاضل را گزارش کنید، نه دو بازه‌ی جدا که روی هم افتاده‌اند.
• تکرار تلاش واریانس اجرا را می‌گیرد و کارهای متنوع‌تر پوشش را. اما هیچ بازه‌ی اطمینانی مجموعه‌ی غیرنماینده، نشت داده یا ارزیاب غلط را درست نمی‌کند.

چالش‌ها#

نشت داده در چهار لایه#

1. نشت در آموزش: کار یا اصلاح انسانی‌اش در داده‌ی آموزش بوده
2. نشت هنگام ارزیابی: ایجنت در وب جستجو می‌کند و اصلاح آینده را کپی می‌کند
3. نشت در محیط: sandbox کامیت‌های آینده یا تست‌های پنهان را در دسترس می‌گذارد
4. بیش‌برازش روی بنچمارک: پرامپت و هارنس روی مجموعه‌ی آزمون عمومی تنظیم شده‌اند

نتیجه: «روی مجموعه‌ی آزمون آموزش ندیده‌ایم» برای ارزیابی ایجنت کافی نیست.

دلیلش این است که عملکرد ایجنت امروزی تقریباً تابعی از کل پشته است:

P = f(LLM, prompt, scaffold, tools, retriever, memory, environment)

و هر جزء می‌تواند اطلاعات بنچمارک را با خودش بیاورد:

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

یک نوبت کاربر#

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

چالش‌های دیگر#

• هزینه و تأخیر: نرخ موفقیت تفاوت اجرای ۲۰۰ قدمی ۴۰ دلاری با اجرای ۱۲ قدمی ۳۰ سنتی را پنهان می‌کند.
• عدم قطعیت: همان ایجنت روی همان کار نتیجه‌ی متفاوت می‌دهد. نمره‌ی یک‌باره نویز است، نه سیگنال.
• اثرات جانبی: هیچ چیز فایل پاک‌شده، ایمیل فرستاده‌شده یا پول خرج‌شده در مسیر رسیدن به پاس را جریمه نمی‌کند.
• معیار: نمره‌ی فقط-نتیجه اجراهای خوش‌شانس یا ناامن را پاداش می‌دهد و تطبیق مسیر، اجراهای درستِ متفاوت را رد می‌کند.

بنچمارک‌ها سریع اشباع می‌شوند#

طبق داده‌های اسلایدها، فاصله‌ی بین انتشار هر بنچمارک و رسیدن مدل‌های پیشرو به خط پایه‌ی انسانی:

«اشباع» یعنی مدل‌های پیشرو به خط پایه‌ی انسانی رسیده‌اند یا دیگر از هم جدا نمی‌شوند. پس امتیاز بنچمارک قدیمی چیز زیادی درباره‌ی ایجنت امروز نمی‌گوید.

ارزیابی هنوز در حال تحول است#

چند بُعد، نه یک عدد#

ایجنت واقعی سه محور دارد: توانایی (بیشتر بهتر)، هزینه (کمتر بهتر) و سرعت. سیستم A بر B غالب است اگر در هیچ معیاری بدتر و دست‌کم در یکی بهتر باشد. سیستم‌هایی که هیچ سیستم دیگری بر آن‌ها غالب نیست، مرز پارتو را می‌سازند. به جای یک برنده، این مرز را گزارش کنید.

طراحی ارزیابی خودتان#

1. واحد موفقیت را تعریف کنید، و همین‌طور اثرات جانبی غیرقابل‌قبول را.
2. کارها و ارزیاب‌ها را اعتبارسنجی کنید. تست‌های پنهان را بیرون از فضای قابل نوشتن ایجنت نگه دارید. ارزیاب را با جواب درستِ متفاوت و جواب غلط شناخته‌شده آزمایش کنید.
3. holdout را با ادعا هماهنگ کنید. روی dev تنظیم کنید و آزمون را منجمد کنید. برای ادعای تعمیم، گروه‌های کامل (مخزن، مشتری، نوع کار) را کنار بگذارید.
4. مقایسه را کنترل کنید: کارها، ابزارها، قواعد توقف و محدودیت‌های ثابت. از قبل بگویید تلاش مجدد و خرابی زیرساخت چطور شمرده می‌شوند.
5. تکرار کنید و مسیرها را بخوانید. تنظیم مکرر روی مجموعه‌ی آزمون آن را به dev تبدیل می‌کند.

قبل از نسبت دادن تغییر به معماری#

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

فهرست گزارش#

• کارها: بنچمارک، نسخه، split، تعداد، موارد حذف‌شده
• سیستم: نسخه‌ی مدل، پرامپت، هارنس، حافظه، تنظیمات decoding، ابزارها، محیط
• بودجه: زمان، توکن، قدم، فراخوانی، موازی‌سازی، تلاش مجدد، کمک انسانی
• نمره‌دهی: نسخه‌ی ارزیاب، معیار، نرمال‌سازی، rubric یا داور
• نتایج: صورت و مخرج، تلاش برای هر کار، بهبودها و پسرفت‌های جفتی، عدم قطعیت، و اینکه pass@k است یا pass^k
• منابع: هزینه با شکست‌ها، هزینه به ازای تلاش و موفقیت، توزیع تأخیر، مسیرها

پرسش‌هایی برای فکر کردن#

• ایجنتی دارید که pass@1 آن ۸۰٪ است. برای یک ربات پشتیبانی که هر مشتری را فقط یک بار می‌بیند، کدام معیار مهم‌تر است و چرا؟
• یک ارزیابی ۵۰ کاری برای ایجنت پروژه‌ی خودتان طراحی کنید. چه چیزی را به‌عنوان «اثر جانبی غیرقابل‌قبول» تعریف می‌کنید؟

منابع#

• اسلاید جلسه: Agent design IV: agent evaluation (7_agent_design_4.pdf)
• یادداشت درس: Agent evaluation and benchmarks
• Yao و همکاران، τ-bench
• Jimenez و همکاران، SWE-bench
• Kapoor و همکاران، AI Agents That Matter
• Miller، Adding Error Bars to Evals