بسیاری از ایجنت‌های هوش مصنوعی در ارائه‌ها و دموهای اولیه عملکردی چشمگیر دارند، اما هنگام ورود به محیط عملیاتی (Production) با رفتارهای پیش‌بینی‌نشده، بن‌بست در ابزارها و خروجی‌های نامعتبر متوقف می‌شوند. اتکای صرف به بنچمارکهای عمومی مانند SWE-bench یا GAIA تنها نشان میدهد که مدل پایه تا چه حد توانمند است، اما تضمین نمی‌کند ایجنت در مسیر اهداف اختصاصی محصول شما به‌درستی تصمیم بگیرد.
توسعه‌ی مبتنی بر ارزیابی (Eval-Driven Development) این چالش را با تبدیل سنجش کیفیت از مرحله‌ی پایانی پروژه به حلقه‌ی هدایت‌کننده‌ی معماری حل میکند. در این روش، هر قابلیت، محدودیت یا شکست گذشته به یک مورد ارزیابی در مخزن کد بدل شده و با استقرار در خطوط یکپارچه‌سازی مداوم (CI)، جلوی هرگونه پس‌رفت (Regression) پیش از ادغام کد گرفته میشود.
اگر دسترسی به API سرویس‌های ابری خارجی مانند مدل‌های ارزیاب یا ابزارهای تله‌متری با محدودیت‌های شبکه همراه باشد، می‌توانید ارزیابیهای پایه‌ای را به شکل محلی و با مدل‌های سبک‌تر اجرا کرده و پایپ‌لاین‌های CI خود را بدون وابستگی دائم به زیرساخت‌های ابری پایدار نگه دارید.
توصیه‌ی Anthropic: «با پرامپت‌های ساده شروع کنید، آن‌ها را با ارزیابی جامع بهینه‌سازی کنید، و فقط در صورت نیاز سیستم‌های ایجنتی چندمرحله‌ای را بیفزایید.» ارزیابی مرحله‌ی آخر کار نیست؛ حلقه‌ی بیرونی است که تک‌تک انتخاب‌های دیگر در فاز 14 را هدایت میکند.
اهداف یادگیری
- نام بردن سه لایهی ارزیابی — بنچمارکهای ایستا، ارزیابیهای سفارشی آفلاین، ارزیابیهای پروداکشن آنلاین — و کاربرد هر کدام.
- توضیح حلقه‌ی فشرده‌ی ارزیاب-بهینهساز (evaluator-optimizer).
- شرح بهترین روش‌های سال 2026: استقرار ارزیابی‌ها در کنار کد، اجرا در CI، و اعمال گیت روی PRها.
- پیوند دادن هر یک از درس‌های فاز 14 به مورد ارزیابی که ایجاد میکند.
صورت مسئله
ایجنتها در دموها قبول می‌شوند، ولی در محیط پروداکشن طوری شکست می‌خورند که دموها قادر به پیش‌بینی‌اش نیستند. بنچ‌مارک‌ها به این پرسش پاسخ می‌دهند که «آیا این مدل به‌طور کلی توانمند است؟» نه اینکه «آیا این ایجنت تکه‌های (patches) کُد درستی برای محصول من تحویل میدهد؟» راهکار این است: ارزیابی در سه لایه که به‌صورت مداوم اجرا شود و هر گاردریل (ریل ایمنی) و قاعده‌ی آموخته‌شده به یک مورد ارزیابی متصل باشد.
مفاهیم کلیدی
سه لایهی ارزیابی
-
بنچمارکهای ایستا — SWE-bench Verified برای کد (درس 19)، WebArena/OSWorld برای مرور وب و دسکتاپ (درس 20)، GAIA برای توانمندی‌های عمومی (درس 19)، BFCL V4 برای فراخوانی ابزار (Tool Use) (درس 06). کاربرد: مقایسهی میان‌مدلی و اعمال گیت بر اساس پس‌رفت (regression). نسبت آلودگی (contamination) کاملاً واقعی است: پروژه‌ی +SWE-bench نشان داد که 32.67% نشت راه‌حل وجود دارد. همیشه امتیازها را روی SWE-bench Verified یا مجموعه‌ای بازبینی‌شده از نظر نشت داده، مثل +SWE-bench، گزارش کنید.
-
ارزیابیهای سفارشی آفلاین — متناسب با ساختار محصول شما:
- مدل زبانی در نقش داور (LLM-as-judge) (با Langfuse ،Phoenix ،Opik — درس 24).
- مبتنی بر اجرا (اجرای تکه، بررسی آزمون‌ها).
- مبتنی بر مسیر حرکت (مقایسهی توالی اقدام‌ها با مسیر مرجع؛ پروژه‌ی OSWorld-Human نشان میدهد ایجنت‌های برتر 1.4 تا 2.7 برابر مسیر مرجع گام برمی‌دارند).
-
ارزیابیهای آنلاین — محیط پروداکشن:
- بازپخش نشستها (Langfuse).
- هشدارهای فعال‌شده توسط گاردریل (درس‌های 16 و 21).
- ردیابی هزینه و تاخیر در هر گام (اسپن‌های OTel در درس 23).
ارزیاب-بهینهساز (Anthropic)
حلقه‌ی فشرده:
- پیشنهاددهنده خروجی را تولید میکند.
- ارزیاب داوری میکند.
- بازبینی و اصلاح ادامه می‌یابد تا ارزیاب خروجی را تایید کند.
این رویکرد تعمیم‌یافته‌ی Self-Refine (درس 05) است. برای افزایش قابلیت اطمینان، می‌توانید هر جریان ایجنتی مهمی را درون یک ارزیاب-بهینهساز بپیچید.
بهترین روش‌ها در سال 2026
- ارزیابی‌ها در کنار کد قرار می‌گیرند.
- در هر PR درون CI اجرا می‌شوند.
- ادغام (merge) بر اساس امتیازهای ارزیابی مشروط میشود (مثلاً «عدم وجود پس‌رفت بیشتر از 5% نسبت به شاخه‌ی main»).
- هر گاردریل به یک مورد ارزیابی متصل است.
- هر قاعده‌ی آموخته‌شده (Reflexion یا یادگیری قواعد در جریان‌های کاری پیشرفته) به یک حالت شکست نگاشت میشود.
اتصال درس‌های فاز 14 به یکدیگر
بیشتر درس‌های فاز 14 یک مورد ارزیابی مشخص تولید می‌کنند. جدول زیر درس‌هایی را نشان میدهد که روشن‌ترین موارد را دارند:
| درس | مورد ارزیابی حاصل از آن |
|---|---|
| 01 حلقه‌ی ایجنت | اتمام بودجه، محافظت در برابر حلقه‌ی بی‌نهایت |
| 02 ReWOO | برنامه‌ریزی مجدد و درستِ برنامه‌ریز هنگام شکست ابزار |
| 03 Reflexion | اعمال بازتاب‌های آموخته‌شده در تلاش مجدد |
| 05 Self-Refine/CRITIC | قبولی خروجی اصلاح‌شده توسط داور |
| 06 فراخوانی ابزار | کارکرد صحیح تبدیل نوع آرگومان‌ها؛ رد ابزارهای ناشناخته |
| 07-10 حافظه | تطابق ارجاع‌های بازیابی با منابع؛ باطل‌سازی فکت‌های منسوخ |
| 12 الگوهای گردش کار | تولید خروجی درست توسط هر الگو |
| 13 LangGraph | بازتولید دقیق وضعیت هنگام ادامه‌ی کار (Resume) |
| 14 اکتورهای AutoGen | به‌دام‌انداختن گرداننده‌های متوقف‌شده توسط DLQ |
| 16 SDK ایجنت‌های OpenAI | فعال‌شدن گاردریل روی ورودی‌های درست |
| 17 SDK ایجنت Claude | بازگشت نتایج زیرایجنت‌ها به هماهنگ‌کننده (Orchestrator) |
| 19-20 بنچ‌مارک‌ها | امتیاز SWE-bench Verified، نرخ موفقیت WebArena، کارایی OSWorld |
| 21 استفاده از کامپیوتر | مهار DOMهای تزریق‌شده توسط ایمنی گام‌به‌گام |
| 23 OTel | انتشار ویژگی‌های الزامی توسط اسپن‌ها |
| 26 حالت‌های شکست | برچسب‌گذاری خطاهای شناخته‌شده توسط آشکارسازها |
| 27 تزریق پرامپت | رد بازیابی‌های مسموم توسط PVE |
| 28 ارکستراسیون | مسیریابی سرپرست به متخصص مناسب |
| 29 ساختارهای محیط اجرا | مدیریت N% خطا توسط DLQ |
اگر مجموعه‌ی ارزیابی شما برای هر ردیف یک مورد داشته باشد، هسته‌ی فاز 14 را پوشش داده‌اید.
دلایل شکست توسعه‌ی مبتنی بر ارزیابی
- نبود خط مبنا (Baseline). ارزیابی‌ها بدون آخرین وضعیت تاییدشده غیرقابل‌فهم هستند. خطوط مبنا را ذخیره کنید.
- داوری مدل زبانی بدون ارجاع‌دهی مکانی (Grounding). داورها هم دچار توهم می‌شوند. از الگوی CRITIC (درس 05) استفاده کنید تا داور به ابزارهای بیرونی متکی باشد.
- بیش‌برازش روی ارزیابی‌ها. بهینه‌سازی افراطی برای ارزیابی‌ها، کارایی در دنیای واقعی پروداکشن را کم میکند. موارد ارزیابی را به‌صورت دوره‌ای تغییر دهید.
- ارزیابیهای ناپایدار (Flaky). آزمون‌های غیرقطعی هشدارهای کاذب می‌سازند. مقدار seed را ثابت نگه دارید و از وضعیت‌ها اسنپ‌شات بگیرید.
پیاده‌سازی از صفر
فایل code/main.py یک بستر آزمایشی (harness) ارزیابی با کتابخانه‌ی استاندارد است:
- رجیستری موارد آزمون با دسته‌بندی مشخص (بنچ‌مارک، سفارشی، آنلاین).
- یک ایجنت آزمایشی مبتنی بر اسکریپت تحت آزمون.
- حلقه‌ی ارزیاب-بهینهساز: پیشنهاد، داوری، اصلاح تا زمان قبولی یا رسیدن به سقف دورها.
- گیت CI: محاسبه‌ی مجموع نرخ قبولی (Pass Rate) و سنجش پس‌رفت نسبت به خط مبنا.
اجرای برنامه:
python3 code/main.pyخروجی: قبولی یا ردی در هر مورد، هشدار پس‌رفت، و حکم نهایی گیت CI.
استفاده از ابزارهای واقعی
- موارد ارزیابی را در همان مخزن کد ایجنت بنویسید.
- آن‌ها را در هر PR از طریق CI اجرا کنید.
- در صورت پس‌رفت، فرایند ساخت را متوقف کنید.
- روند تغییرات نرخ قبولی را در طول زمان زیر نظر بگیرید.
- هر شکست در پروداکشن را به یک مورد ارزیابی تازه متصل کنید.
خروجی این درس
فایل outputs/skill-eval-suite.md یک مجموعه‌ی ارزیابی سه‌لایه‌ای برای یک محصول ایجنتی به‌همراه گیت‌های CI و ردیابی پس‌رفت می‌سازد.
تمرین‌ها
- یکی از شکست‌های سیستم خود در پروداکشن را بردارید و یک مورد ارزیابی برای بازتولید آن بنویسید. آیا ایجنت شما الان در آن قبول میشود؟
- یک شیوه‌نامه‌ی نمره‌دهی (Rubric) برای داوری مدل زبانی در دامنه‌ی کاری خود با سه بعد (صحت فکت‌ها، لحن، دامنه) بسازید. عملکرد 50 نشست را ارزیابی کنید.
- مجموعه‌ی ارزیابی را به CI متصل کنید؛ طوری که با پس‌رفت 5% یا بیشتر، ساخت ناموفق شود.
- معیار کارایی مسیر حرکت را اضافه کنید: ایجنت در مقایسه با مسیر مرجع چند گام برداشته است؟
- هر یک از درس‌های فاز 14 را به یک مورد ارزیابی در مجموعه‌ی خود نگاشت کنید. موردی جا مانده؟ این همان شکافی است که باید پر شود.
اصطلاحات کلیدی
| اصطلاح | بر زبان‌ها | در عمل |
|---|---|---|
| بنچ‌مارک ایستا | «ارزیابی آماده» | SWE-bench ،GAIA ،AgentBench ،WebArena ،OSWorld |
| ارزیابی سفارشی آفلاین | «ارزیابی دامنه» | داوری مدل زبانی / مبتنی بر اجرا / ارزیابی مسیر متناسب با محصول شما |
| ارزیابی آنلاین | «ارزیابی پروداکشن» | بازپخش نشستها، هشدارهای گاردریل، ردیابی هزینه و تاخیر |
| ارزیاب-بهینهساز | «پیشنهاد-داوری-اصلاح» | تکرار فرایند تا تایید نهایی داور |
| گیت CI | «مانع ادغام» | متوقف کردن ساخت در صورت پس‌رفت در ارزیابی |
| خط مبنا | «آخرین وضعیت تاییدشده» | امتیاز مرجع برای تشخیص پس‌رفت |
| کارایی مسیر حرکت | «تعداد گام‌ها نسبت به مسیر مرجع» | تعداد گام‌های ایجنت تقسیم بر حداقل گام‌های کارشناس انسانی |
برای مطالعه‌ی بیشتر
- راهنمای Anthropic در ساخت ایجنت‌های اثربخش — «با سادگی شروع کنید، با ارزیابی بهینه کنید»
- معرفی SWE-bench Verified توسط OpenAI — بنچ‌مارک بازبینی‌شده
- جدول رده‌بندی فراخوانی تابع برکلی (BFCL) — بنچ‌مارک فراخوانی ابزار
- مستندات Langfuse — کاربرد عملی ارزیابی‌ها و بازپخش نشستها