داشبوردهای سبز رنگ ارزیابی، لزوماً ثابت نمی‌کنند که عامل شما باکیفیت است؛ آن‌ها فقط می‌گویند عامل شما تست‌های فعلی را پاس کرده است. این تمایز ظریف اما حیاتی، محوریت یک تحلیل فنی عمیق بود که در ۲۱ ژوئن ۲۰۲۶ در وب‌سایت dev.to منتشر شد. این گزارش هشدار داد که اکثر تیم‌های توسعه عامل‌های هوش مصنوعی با پدیده‌ای به نام «پوسیدگی ارزیابی» مواجه می‌شوند؛ وضعیتی که در آن مجموعه‌های تست به‌جای اندازه‌گیری کیفیت واقعی، خود به هدفی برای بهینه‌سازی تبدیل می‌شوند.
این پدیده یک کاربرد کلاسیک از «قانون گودهارت» (Goodhart's Law) است: «وقتی یک معیار تبدیل به هدف شود، دیگر معیار خوبی نیست». در دنیای عامل‌های هوش مصنوعی (AI Agents) — موجوداتی که مثل کارمندانی دیجیتال هستند و می‌توانند ابزارها را برای رسیدن به هدف مدیریت کنند — این اتفاق معمولاً ظرف سه ماه پس از استقرار اولین گیت‌های انتشار (Release Gates) رخ می‌دهد. این یک ریسک احتمالی یا فرضی نیست، بلکه مسیر پیش‌فرض و اجتناب‌ناپذیر اکثر تیم‌هاست. توسعه‌دهندگان شروع می‌کنند به تغییر پرامپت‌ها و نمونه‌های یادگیری با نمونهٔ اندک (Few-shot Learning) به‌طور خاص برای اینکه مدلِ داور را راضی کنند. در واقع، آن‌ها به‌طور ناخودآگاه مجموعه ارزیابی خود را به یک مجموعه آموزشی تبدیل می‌کنند. اکثر تیم‌ها تنها زمانی متوجه این تغییر مخرب می‌شوند که یک نسخه با وضعیت «پاس کامل» در محیط عملیاتی (Production) منتشر می‌شود و در سکوت، همه چیز را بدتر می‌کند.
با تکیه بر پوشش‌های قبلی ما درباره‌ی «شکاف هارنس» (Harness Gap) و دلایلی که باعث می‌شود دموهای محیط عملیاتی شکست بخورند، باید گفت این زوال به این دلیل رخ می‌دهد که ارزیابی‌ها معمولاً باگ‌های دیروز را هدف قرار می‌دهند. این چالش با نقص‌های لایه‌ی نظارت بر عامل‌های سازمانی همسو است که استقرار ایمن این فناوری را دشوار می‌کند. وقتی یک تست شکست می‌خورد، توسعه‌دهندگان اغلب به‌جای اصلاح استدلال زیربنایی، سخت‌گیری‌های (Assertions) تست را کاهش می‌دهند تا نتیجه «سبز» شود. با گذشت زمان، عامل در پاس کردن موارد تست مهارت می‌یابد، اما در انجام کار واقعی پیشرفتی نمی‌کند. در اینجا، «نقشه» جایگزین «قلمرو» می‌شود.
مکانیسم زوال ارزیابی
طبق تحلیل dev.to، این زوال «کسل‌کننده» است و دقیقاً به همین دلیل خطرناک است، چون از یک توالی پیش‌بینی‌پذیر پیروی می‌کند:
- ابتدا، تست‌ها بر اساس باگ‌های شناخته‌شده نوشته می‌شوند و حالت‌های شکست احتمالی در آینده کاملاً نادیده گرفته می‌شوند.
- هرگاه یک پس‌رفت (Regression) رخ می‌دهد، ادعاهای تست (Assertions) طوری تغییر می‌کنند که سخت‌گیری کمتری داشته باشند. در این مرحله، تیم به‌جای پرسیدن این سوال که «آیا ما دچار پس‌رفت شده‌ایم؟»، می‌پرسد «آیا تست بیش از حد سخت‌گیرانه است؟».
- روباریک‌های داور (Judge Rubrics) از طریق مهندسی پرامپت و عبارت‌بندی‌های خاص دور زده می‌شوند. نمونه‌های Few-shot به‌سمت عبارت‌های دقیقی سوق پیدا می‌کنند که مدل داور به آن‌ها پاداش (امتیاز بالا) می‌دهد.
- مجموعه داده‌های ذخیره شده (Held-out set) به‌دلیل دیباگ کردن مستقیم روی آن‌ها، به‌طور آرام فاسد می‌شوند. هر موردی که برای دیباگ باز شود، موردی است که عامل اکنون روی آن بیش‌برازش (Overfitting) شده است.
نقطه پایان این مسیر، عاملی است با نرخ موفقیت ۹۸٪ که از نظر کاربر نهایی به‌طور محسوسی بدتر شده است؛ زیرا امتیاز او دیگر کیفیت کار را نمی‌سنجد، بلکه میزان رضایت از تست را اندازه‌گیری می‌کند. این توهمِ موفقیت، یادآور فریب معیارهای DORA در فرآیندهای تولید کد است، جایی که سرعت بالا لزوماً به معنای کیفیت نیست.
حل مشکل «فقدان روایت»
یک بیت ساده‌ی پاس/شکست (Pass/Fail)، اندازه‌گیری‌ای است که شما فقط می‌توانید به آن اعتماد کنید یا نکنید. شفاف‌ترین سیگنال برای رسیدن به نقطه بحرانی قانون گودهارت زمانی است که یک نسخه از گیت ارزیابی عبور می‌کند، اما هیچ‌کس در تیم نمی‌تواند توضیح دهد چرا یک مورد مرزی (Borderline case) خاص پاس شده است. در این حالت، امتیاز به عددی تبدیل می‌شود که هیچ روایتی (Narrative) پشت آن نیست.
برای مبارزه با این وضعیت، نویسنده رویکردی یکپارچه را پیشنهاد می‌کند که دو ابزار خاص را با هم ترکیب می‌کند: agent-eval و AgentLens. این دو نباید به صورت داشبوردهای جداگانه، بلکه باید به عنوان یک واحد عمل کنند.
- agent-eval: این ابزار خروجی را امتیازدهی کرده و گیت‌ها را کنترل می‌کند. این ابزار بررسی‌های قطعی (Deterministic)، روباریک‌های مدل-به-مثابه-داور و سیگنال‌های مربوط به انحراف (Drift) و توهم (Hallucination) را اجرا می‌کند تا در نهایت یک حکم صادر کند.
- AgentLens: این ابزار ردپای (Trace) نحوه رسیدن عامل به نتیجه را ثبت می‌کند. هر فراخوانی مدل، هر گام ابزاری، ورودی‌های نهایی (پس از جایگذاری در قالب یا Templating) و خروجی‌های خام پیش از پردازش نهایی را ضبط می‌کند.
هیچ‌کدام از این دو به تنهایی کافی نیستند. یک امتیاز ارزیابی لخت، هدفی است که منتظر است تا دور زده شود؛ و یک ردپای لخت، داده‌های جنایی (Forensic) بدون حکم است. با پیوند دادن امتیاز به ردپا، هر تصمیم در گیت انتشار، یک «رسیدِ» مدلِ «به من نشان بده چرا» دارد. اگر موردی از قرمز به سبز تغییر کند، توسعه‌دهنده می‌تواند ردپای AgentLens را بازرسی کند تا ببیند آیا عامل واقعاً درست استدلال کرده یا صرفاً در انتخاب یک عبارت شانس آورده است.
اصلاح معماری
در سطح کد، الگوی غلط (Anti-pattern) ایجاد گیتی است که صرفاً یک مقدار بولی برمی‌گرداند و بدین ترتیب «طعمه گودهارت» ایجاد می‌کند، بدون اینکه شواهدی پشت آن باشد:
async function gate(testCase: TestCase): Promise<boolean> { const output = await runAgent(testCase.input); return judge(output, testCase.expected) >= 0.8; }
راهکار اصلاحی این است که اطمینان حاصل شود امتیاز و ردپا با هم جابجا می‌شوند و از یک رابط (Interface) به نام GatedResult استفاده می‌کنند. این رابط باید شامل متغیر بولی passed، امتیاز عددی score، یک traceId (به عنوان رسید) و یک پرچم heldOut باشد تا ردیابی شود که آیا این مورد هرگز برای دیباگ استفاده شده است یا خیر.
در پیاده‌سازی بهبودیافته، متد trace.start عملیات رزولوشن را ثبت می‌کند و تابع evaluate مواردی چون «طرح‌واره» (Schema)، «مبنی‌سازی» (Grounding) و «انحراف» (Drift) را با استفاده از یک روباریک خاص (مثلاً rubric-v3) بررسی می‌کند. سپس حکم نهایی به نشست (Session) متصل می‌شود. این ساختار تضمین می‌کند که هیچ «پاسی» بدون توضیح نباشد و بیش‌برازش به‌طور مستقیم از طریق تفاوت امتیاز بین مجموعه‌های ذخیره شده و دیباگ شده اندازه‌گیری شود.
اجرای گارد‌های ضد-گودهارت
ابزارها به تنهایی نمی‌توانند جلوی قانون گودهارت را بگیرند؛ این فرآیند عملیاتی پیرامون ابزارهاست که باید خط قرمزها را حفظ کند. این راهنما سه قانون عملیاتی را پیشنهاد می‌کند:
۱. قرنطینه کردن مجموعه ذخیره (Held-Out Set): مجموعه‌ای از موارد را نگه دارید که هرگز برای دیباگ استفاده نشوند. اگر توسعه‌دهنده‌ای برای رفع یک شکست، ردپای یک تست را باز کند، آن مورد برایاً «سوخته» است و دیگر نمی‌تواند برای اندازه‌گیری کیفیت استفاده شود. این مورد باید از یک «مورد ارزیابی» به یک «تست رگرسیون» تبدیل شود. یک مجموعه چرخشی داشته باشید که فقط امتیازدهی کنید و هرگز مدل را به‌سمت آن تنظیم (Tune) نکنید.
۲. حسابرسی ویرایش‌های ارزیابی: هرگونه کاهش سخت‌گیری در یک ادعای تست را مانند یک تغییر در کد تولید (Production) را ببینید. شل کردن یک Assertion برای رسیدن به رنگ سبز، یک «شعاع تخریب» (Blast Radius) دارد. این کار باید مستلزم یک Diff، یک بازبین (Reviewer) و توجیهی باشد که به یک ردپا متصل است (مثلاً: «این مورد اشتباه بود چون ردپا نشان می‌دهد X رخ داد»)، به‌جای اینکه صرفاً ادعا شود تست «ناپایدار» (Flaky) بوده است.
۳. استخراج ردپاهای تولید: از اختراع موارد مصنوعی بر اساس تخیل خود اجتناب کنید، زیرا این‌ها فقط شکست‌هایی را منعکس می‌کنند که شما همین حالا می‌توانید تصور کنید. در عوض، ردپاهای واقعی و غافلگیرکننده را به‌طور مستمر از AgentLens استخراج کرده و به مجموعه ذخیره اضافه کنید. این کار تضمین می‌کند که مجموعه تست شما یک هدف متحرک را اندازه می‌گیرد، نه یک هدف منجمد شده.
نتیجه‌گیری ناگوار
در نهایت، یک داشبورد سبز رنگ ارزیابی، دلیلی بر خوب بودن عامل شما نیست. بلکه دلیلی است بر اینکه عامل شما، ارزیابی‌های شما را پاس کرده است. این دو تنها زمانی یک معنا دارند که شما فعالانه از شکاف بین آن‌ها دفاع کنید.
معتبرترین تیم‌ها آن‌هایی نیستند که نرخ موفقیت ۹۸٪ دارند، بلکه کسانی هستند که می‌توانند هر تیک سبز را بیرون بکشند و منطق زیربنایی آن را توضیح دهند. حکمی که توسط agent-eval ارائه می‌شود تنها زمانی معنادار است که توسط رسیدِ AgentLens پشتیبانی شود. اگر در حال حاضر در حال مقیاس‌دهی به یک جریان کاری عامل‌محور هستید، ارزیابی کنید که آیا داشبورد «سبز» فعلی شما بازتاب‌دهنده ارزش واقعی برای کاربر است یا صرفاً نشان‌دهنده توانایی تیم شما در دور زدن مدل داور است.
گام بعدی شما
- بررسی کنید آیا در ارزیابی‌های فعلی خود، مجموعه‌ای از داده‌ها دارید که هرگز برای اصلاح مدل (Tuning) از آن‌ها استفاده نشده باشد؟
- ابزارهای Trace-based مانند AgentLens یا جایگزین‌های آن را برای متصل کردن امتیازات به مسیر اجرای مدل پیاده کنید.
- هرگونه تغییر در معیار موفقیت تست‌ها را به چرخه Code Review وارد کنید.
داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو