ارزیابی مسیر در برابر بنچمارک‌های سنتی؛ تضمین پایداری عامل‌های هوش مصنوعی

تیم‌هایی که در بنچمارک‌ها به امتیاز ۹۰٪ رسیده‌اند، اغلب بلافاصله پس از استقرار در محیط عملیاتی شکست می‌خورند. این هشدار شرکت آنتروپیک (Anthropic) در ژانویه ۲۰۲۶ در مقاله‌ای با عنوان «دمستیکی کردن ارزیابی‌ها برای عامل‌های هوش مصنوعی» (Demystifying evals for AI agents)، پرده از توهم «همه-سبز» برمی‌دارد؛ وضعیتی که در آن یک عامل (Agent) — شبیه به کارمندی که با اشتباهات زیاد در پرونده‌ها، در نهایت جواب درست را به رئیس می‌دهد — پاسخی کاملاً صحیح ارائه می‌کند اما در مسیر رسیدن به آن، خطاهای فاجعه‌باری مرتکب شده است. این پدیده دقیقاً همان دلیلی است که باعث می‌شود ارزیابی‌های تک‌مرحله‌ای منجر به فریب توسعه‌دهندگان شود و نرخ موفقیت کاذبی را گزارش کنند.

به گزارش مورف‌ال‌ال‌ام (Morphllm)، این نگرانی را تأیید کرده و اشاره می‌کند که امتیاز پاسخ نهایی می‌تواند سبز و موفق به نظر برسد، در حالی که مسیر اجرای مدل دچار حلقه شده و برای سه نوبت از سیاست‌های تعیین‌شده (Off-policy) فاصله گرفته است. اکثر توسعه‌دهندگان در حال حاضر با عامل‌ها مانند جعبه‌های سیاه برخورد می‌کنند: ورودی می‌دهند و خروجی را تأیید می‌کنند. این رویکرد نسبت به «مسیر» (Trajectory) — یعنی توالی فراخوانی ابزارها، انتخاب پارامترها و گره‌های تصمیم‌گیری که عامل برای رسیدن به پاسخ طی می‌کند — کاملاً کور است. در محیط تولید، ارزش یک عامل در فرآیند است، نه فقط در نتیجه.

تصور کنید کاربری بخواهد «تاریخچه پیش‌فاکتورهای این مشتری» را بررسی کند. طبق مستندات ثبت‌شده در مسیر (Trajectory)، عامل ابتدا عبارت «لجستیک شانگهای» را جست‌وجو کرده و سه گزینه می‌یابد. سپس تابع get_quote_history را برای مخاطب ۰۰۷ فراخوانی می‌کند (که نتیجه آن خالی است)، و سپس همان تابع را برای مخاطب ۰۰۳ فراخوانی می‌کند (که ۱۲ پیش‌فاکتور برمی‌گرداند). در نهایت، عامل تابع send_email را برای مخاطب ۰۰۷ فراخوانی می‌کند اما پیش‌فاکتورهای مربوط به مخاطب ۰۰۳ را پیوست می‌کند. چون پیام نهایی عامل این است که «تاریخچه پیش‌فاکتورها برای مشتری ارسال شد»، تست‌های سنتی سطح خروجی این مورد را «موفق» علامت می‌زنند؛ در حالی که در واقعیت، عامل یک نقض شدید حریم خصوصی داده‌ها را مرتکب شده و اطلاعات یک شخص را برای شخص دیگری ارسال کرده است.

کالبدشکافی شکست‌های مسیر

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

این چالش‌ها در واقع همان مسیرهای شکست کلیدی هستند که مانع از استقرار تجاری و تبدیل مدل‌های آزمایشگاهی به محصولات عملیاتی می‌شوند.

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

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

پیاده‌سازی ارزیاب مسیر (TrajectoryEvaluator)

برای حل این مشکل، مهندسان به سمت معماری ارزیاب مسیر (TrajectoryEvaluator) حرکت می‌کنند. این سیستم هر گام — شامل اقدام (Action)، پارامترها و نتیجه — را در یک ردپای حسابرسی (Audit Trail) ثبت می‌کند. به‌جای یک پاسخ صفر و یکی (قبول/رد) بر اساس جواب نهایی، سیستم بر اساس الگوهای ناهنجاری به کل مسیر امتیاز می‌دهد.

برای مثال، یک ارزیاب قدرتمند سه لایه قانون اصلی را برای امتیازدهی به مسیر اعمال می‌کند. امتیاز اولیه ۱۰۰ است و برای هر تخلف ۲۰ امتیاز کسر می‌شود:

• تشخیص حلقه: اگر یک ابزار بیش از ۳ بار متوالی فراخوانی شود (MAX_REPEAT = 3)، این مورد به عنوان تخلف برای احتمال وقوع حلقه ثبت می‌شود.
• تأیید لیست سفید: هرگونه فراخوانی ابزاری که در مجموعه whitelist حضور ندارد، به عنوان «فرار از سطح دسترسی» علامت‌گذاری می‌شود.
• سنجش پارامترها: سیستم بررسی می‌کند که آیا پارامترهای ضروری وجود دارند یا خیر. برای مثال، اگر توابع send_email یا send_quote بدون پارامتر to فراخوانی شوند، به عنوان خطای پارامتری ثبت می‌گردند.

چرخه بازخورد دفتر خطاهای سیستم

ارزیابی یک اتفاق یک‌باره نیست، بلکه یک چرخه داده‌ای مداوم (Flywheel) است. در سیستم عملیاتی وو جی، این فرآیند از یک چرخه سخت‌گیرانه پیروی می‌کند:

۱. اجرای عملیاتی: هر گام عامل در یک ردپای حسابرسی شامل (اقدام/پارامترها/نتیجه/زمان) ثبت می‌شود.
۲. ثبت خطا: هرگاه مشکلی شناسایی شود، در یک «دفتر خطاهای» (Error-ledger) ثبت می‌گردد (که در سیستم او در حال حاضر ۳۱ مورد ثبت شده است).
۳. استخراج درس: خطا به شکل یک قانون یا مهارت در فایلی به نام writing_lessons رسوب می‌کند (که شامل ۵۰ خط منطق است).
۴. سد بازگشتی: یک گیت انتشار (publish_gate) از این درس‌ها استفاده می‌کند تا از وقوع همان خطا در تکرار بعدی جلوگیری کند.

این ساختار یک «سد بازگشتی» (Regression Gate) ایجاد می‌کند: به محض اینکه خطایی ثبت و قانونی برای آن نوشته شود، publish_gate مانع از تکرار آن خطای خاص در نسخه‌های آینده می‌شود. این امر توسعه‌دهنده را از یک مشاهده‌گر خوش‌بین به یک حسابرس سخت‌گیر تبدیل می‌کند که هر حرکت عامل را امتیازدهی می‌کند.

گام بعدی شما برای پیاده‌سازی

برای پیاده‌سازی این رویکرد در سیستم خود، این سه گام را دنبال کنید:

• گام اول: افزودن ثبت مسیر (Trajectory Logging). فارغ از اینکه از LangGraph، CrewAI یا یک ساختار سفارشی استفاده می‌کنید، اطمینان حاصل کنید که هر فراخوانی ابزار، اقدام، پارامترها و نتیجه را ثبت می‌کند.
• گام دوم: تعریف قوانین ناهنجاری. با سه قانون پایه (حلقه، فرار از دسترسی و خطای پارامتر) شروع کنید و سپس آن را به ناهنجاری‌های تأخیر (Latency)، مانند Timeoutهای تک‌گامه، گسترش دهید.
• گام سوم: اتصال به گیت و چرخه بازخورد. آستانه‌ای تعیین کنید که در آن امتیاز پایین، خروجی را برای تأیید انسانی متوقف کند. پس از تأیید، خطا را به دفتر خطاها (Ledger) منتقل کنید تا قانون جدیدی استخراج شود.

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