تصور کنید یک عامل هوش مصنوعی بهجای رفع مشکل سرور، بهاشتباه کل زیرساخت شما را حذف کند؛ در دنیای DevOps، یک توهم ساده به معنای توقف کامل سرویس برای میلیونها کاربر است. برای جلوگیری از این فاجعه، باید از «تست حس» (Vibe Check) فاصله گرفت و به سراغ سیستمهای ارزیابی قطعی رفت.
طبق راهنمای جامع منتشرشده در ۲۰ ژوئیه ۲۰۲۶ توسط وبسایت devtocash.com، استقرار یک عامل (Agent) — شبیه به دستیاری که میتواند بهجای توصیف مشکل، مستقیماً ابزارها را برای حل آن به کار بگیرد — بدون یک چارچوب ارزیابی سختگیرانه، دقیقاً مانند اجرای یک دستورالعمل تستنشده در محیط عملیاتی است. این چالش نشان میدهد که چرا تستهای نرمافزاری سنتی برای ارزیابی عاملهای هوش مصنوعی شکست میخورند و چرا به رویکردهای نادترمینیستیک نیاز داریم. هدف این چارچوب، انتقال عاملها از حلقههای آزمایشی به ابزارهای آماده برای محیط تولید (Production) از طریق امتیازدهی قطعی به فراخوانی ابزارها است.
در فضای فعلی، بسیاری از توسعهدهندگان تنها چند نمونه از پاسخهای مدل را میخوانند و تصور میکنند سیستم پایدار است. اما برای مهندسان قابلیت اطمینان سایت (SRE)، توهم (Hallucination) — وقتی مدل با اطمینان چیزی میگوید که اصلاً وجود ندارد، شبیه دوستی است که خاطرهای را اشتباه تعریف میکند — صرفاً یک پاسخ غلط نیست، بلکه یک حادثه بحرانی است. همانطور که در تحلیلهای پیشین ما دربارهی امنیت مدلهای عاملمحور اشاره کردیم، تأثیر یک خطا در لایهی زیرساخت بسیار گستردهتر از یک چتبات پشتیبانی است.
به نقل از devtocash.com، عاملهای عملیاتی به سه عامل بسیار حساساند: عدم قطعیت در فراخوانی ابزارها، اثر مخرب گسترده تغییرات زیرساختی و پسرفتهای خاموش ناشی از بهروزرسانیهای ارائهدهندگان مدل. برای مقابله با این موارد، باید معیار «کیفیت پاسخ» را با «صحت اقدام» جایگزین کرد.
چهار بُعد ارزیابیهای عملیاتی
این چارچوب برای عبور از نمرهدهی متنی، چهار معیار مشخص را اولویت میبندد:
- موفقیت در تکلیف: آیا عامل به وضعیت نهایی درست رسید؟ (مثلاً شناسایی خطای OOMKill).
- صحت فراخوانی ابزار: آیا مدل از ابزار درست با آرگومانهای صحیح استفاده کرد یا صرفاً شانس آورد؟
- ایمنی و رد درخواست: این یک دروازه سخت است؛ عامل باید اقدامات ممنوعه را رد کند و بدون ساختن پاسخهای جعلی، به محدودیتها احترام بگذارد.
- هزینه و تأخیر: ردیابی توکن (Token) — تکههای کوچکی از متن که مدل تکهتکه میخورد — برای جلوگیری از حوادث بودجه در زمان عیبیابی.
ساخت با سناریوهای طلایی
هسته این سیستم بر «سناریوهای طلایی» استوار است که از گزارشهای واقعی پس از حوادث (Postmortems) استخراج میشوند. بهجای پرامپتهای کلی، توسعهدهندگان وضعیت خوشه (Cluster) را در لحظه وقوع یک حادثه تثبیت کرده و رفتار مورد انتظار را بهعنوان یک معیار ثابت کدنویسی میکنند.
برای مثال، در سناریوی خطا در کشیدن تصویر (imagepullbackoff-typo)، خروجیهای شبیهسازیشدهی kubectl به عامل داده میشود. ارزیاب سپس بررسی میکند که آیا عامل دستورات k_describe و k_get را اجرا کرده است و مطمئن میشود که در مرحله تشخیص (Read-only)، از ابزارهای تغییردهنده مانند k_apply_approved استفاده نکرده است. این دقت در ارزیابی برای جلوگیری از تکرار خطاهای رایج ضروری است، چرا که بسیاری از سختترین آزمونهای SWE-bench Verified نیز بهدلیل خطاهای فنی مشابه با شکست مواجه شدهاند.
اولویت اقدام بر متن
یک قاعده طلایی در این معماری این است که «سازنده» نباید «بررسیکننده» باشد. عامل نمیتواند خروجی خودش را نمره دهد. اکثر امتیازات باید بر اساس تأکیدات قطعی (Deterministic Assertions) روی ردیابی فراخوانی ابزارها باشد؛ کدهایی که مدل نمیتواند با چانهزنی یا «حرف زدن» از آنها عبور کند.
بررسیهای قطعی شامل تأیید استفاده از ابزارهای ضروری و اطمینان از عدم استفاده از ابزارهای ممنوعه است. اگر سناریویی نیاز به هیچ تغییری در سیستم ندارد، ارزیاب متن نهایی را برای یافتن دروغهایی مانند «من مشکل را حل کردم» جستوجو میکند، در حالی که در واقعیت هیچ تغییری اعمال نشده است.
برای بخشهای نامشخص تشخیص، میتوان از مدل زبانی بهمثابه داور (LLM-as-a-judge) استفاده کرد، به شرطی که این داور یک مدل مجزا با بستر متنی متفاوت باشد تا سوگیری نسبت به مدل اصلی ایجاد نشود.
پیادهسازی دروازه پسرفت در CI
به دلیل ماهیت احتمالی عاملها، یک بار اجرا کافی نیست. این راهنما توصیه میکند هر سناریو چندین بار (مثلاً ۵ بار) اجرا شود تا نرخ موفقیت محاسبه گردد. در حالی که برای کیفیت تکلیف میتوان حد آستانه (مثلاً بالای ۰.۹) گذاشت، اما در مورد خطاهای ایمنی، رویکرد «تسامح صفر» حاکم است؛ یعنی یک خطا کل مجموعه را رد میکند.
این مجموعه سپس به خط لوله CI (مانند GitHub Actions) متصل میشود. اگر تغییر در پرامپت، اصلاح ابزار یا بهروزرسانی نسخه مدل باعث پسرفت شود، بیلد شکست میرود. این یعنی بهروزرسانیهای ارائهدهندگان مدل، مانند تغییرات کد بررسی میشوند، نه مانند غافلگیریهایی در محیط تولید.
بستن حلقه با ارزیابیهای آنلاین
ارزیابیهای آفلاین حوادث شناختهشده را مدیریت میکنند، اما محیط تولید ناشناختهها را برملا میکند. این چارچوب پیشنهاد میکند هر اجرای واقعی عامل به عنوان یک جریان تلهمتری با استفاده از OpenTelemetry رصد شود تا فراخوانی ابزارها و تأخیرها ثبت گردند.
تیمها میتوانند شمارندههای حفاظها (Guardrails) را نظارت کنند تا ببینند عاملها هر چند وقت یکبار به ابزارهای مسدودشده برخورد میکنند. علاوه بر این، هرگاه یک مهندس انسانیِ On-call پیشنهادی را رد کند، آن پیشنهاد باید به یک سناریوی طلایی جدید تبدیل شود تا شکستهای دنیای واقعی به مجموعه تست بازگردند.
محدودیتهای ارزیابی
یک مجموعه ارزیابی ثابت نمیکند که عامل کاملاً ایمن است؛ بلکه فقط ثابت میکند که عامل میتواند مواردی را که توسعهدهندگان به فکر کدنویسیاش بودهاند، مدیریت کند. حالتهای شکست جدید و ورودیهای خصمانه همیشه خارج از این سناریوها وجود خواهند داشت.
به همین دلیل، این راهنما استدلال میکند که موفقیت در تستها تنها «مجوز اجرا در محیطی محدود و نظارتشده» است، نه مجوزی برای حذف دروازه تأیید انسانی از تغییرات زیرساختی. آخرین خط دفاعی همچنان حضور انسان در حلقه (Human-in-the-Loop) برای هر اقدامی است که وضعیت سیستم را تغییر میدهد.
گام بعدی شما
- گزارشهای پسازحادثه (Postmortem) سه ماه اخیر خود را مرور کنید و ۳ سناریوی طلایی برای تست عاملهای خود بسازید.
- یک مدل مجزا و سبکتر را بهعنوان داور (LLM-as-a-judge) برای ارزیابی خروجیهای عامل اصلی تعریف کنید.
- هرگونه رد درخواست توسط مهندس On-call را مستقیماً به یک Test Case در خط لوله CI تبدیل نمایید.
اما مدیریت هزینههای استنتاج در این مقیاس حتی پیچیدهتر است — به تحلیل ما دربارهی مدلهای کاهش هزینه مراجعه کنید.
گفتگو