Agent Evaluation در Gemini Enterprise GA شد؛ چطور Agent را قبل و بعد از Production بسنجیم؟

Google در 31 ژوئیه 2026 قابلیت Agent and Model Evaluations را در Gemini Enterprise Agent Platform به GA رساند. نقطه مهم این Release فقط داشتن چند Metric تازه نیست؛ یک چرخه کامل از Experiment پیش از انتشار تا ارزیابی Traceهای واقعی Production، Drift Alert، User Simulator و Environment Simulator در یک موتور واحد کنار هم قرار گرفته است. این مقاله نشان می دهد این ابزارها را چگونه به یک Quality Gate واقعی تبدیل کنید.

دقیقاً چه چیزی GA شده است؟

Google یک Evaluation Service یکپارچه را برای Agent و Model در Agent Platform به General Availability رسانده است. هدف اصلی این است که تیم در Development و Production دو روش اندازه گیری متفاوت نداشته باشد. همان خانواده Metric و Experiment که روی Dataset آزمایشی استفاده می کنید می تواند روی Traceهای واقعی نیز اعمال شود؛ بنابراین تغییر امتیاز بیشتر احتمال دارد از رفتار Agent آمده باشد، نه از عوض شدن روش سنجش.

این تفاوت عملی مهمی با «چند Prompt تست دستی» دارد. یک سیستم Evaluation باید Dataset، Metric Definition، Version، Run، Trace و نتیجه را قابل بازتولید نگه دارد. Release جدید دقیقاً روی این چرخه تمرکز دارد و برای تیمی که Agent را محصول واقعی می داند، Evals را از یک Notebook جانبی به بخشی از Platform تبدیل می کند.

بیش از 20 Metric؛ کدام را برای چه چیزی انتخاب کنیم؟

مجموعه آماده Google حوزه هایی مثل Quality، Safety، Grounding، Agent Tool Use و Trajectory را پوشش می دهد. برای وظایف مرجع دار نیز Metricهای محاسباتی مانند ROUGE برای خلاصه سازی، BLEU، MetricX و COMET برای ترجمه و Exact Match برای سؤال پاسخ استخراجی ذکر شده اند. مزیت Metric محاسباتی این است که deterministic است؛ اما فقط وقتی Ground Truth معنی دار دارید.

برای Agentهای ابزارمحور، فقط شباهت متن کافی نیست. ممکن است پاسخ نهایی خوب به نظر برسد اما Agent Tool اشتباه را صدا زده، Argument نامعتبر فرستاده یا مسیر پرهزینه ای طی کرده باشد. به همین دلیل Tool Use Quality و Trajectory باید کنار Task Success دیده شوند. Quality یک عدد واحد نیست؛ مجموعه ای از ابعاد است که باید با ریسک محصول شما وزن دهی شود.

Adaptive Rubric چه فرقی با LLM-as-a-Judge ساده دارد؟

Google Adaptive Rubric را به عنوان workflow پیشرفته ای معرفی می کند که از تعریف Eval Case، دستور توسعه دهنده و Tool Declaration معیارهای pass/fail مخصوص همان Case می سازد و سپس Trace را بر اساس آن ها امتیاز می دهد. ایده این است که یک Prompt Judge ثابت برای همه ورودی ها معیارهای نامربوط یا شکننده تحمیل نکند.

با این حال Rubric تولیدشده نیز باید قابل Review باشد. برای Taskهای حساس، نمونه هایی با برچسب انسانی داشته باشید و نرخ توافق Judge با Reviewer را بسنجید. اگر Rubric با تغییر کوچک Prompt نوسان زیادی دارد، هنوز برای Release Gate قابل اتکا نیست. Adaptive بودن جای Calibration را نمی گیرد؛ فقط امکان تعریف معیار context-aware را بهتر می کند.

Experiment را چگونه طراحی کنیم که قابل مقایسه بماند؟

واحد اصلی کار در سرویس، Experiment است: Dataset از Eval Caseها، مجموعه Metricها و Scoreهایی که روی Run ایجاد می شوند. برای مقایسه دو Prompt یا دو Model، همه چیز جز متغیر موردنظر را ثابت نگه دارید. اگر هم Dataset، هم Tool Version و هم Model را هم زمان تغییر دهید، نتیجه بهتر یا بدتر علت روشنی نخواهد داشت.

Experiment را version کنید و Regression Set پایدار داشته باشید. علاوه بر مثال های عادی، Failure Caseهای واقعی Production را بعد از Incident به Dataset اضافه کنید. این کار یک Flywheel می سازد: خطای واقعی به Test دائمی تبدیل می شود و تغییر بعدی باید ثابت کند همان شکست قبلی برنمی گردد.

User Simulator و Environment Simulator چه مشکلی را حل می کنند؟

User Simulator برای Agentهای چندمرحله ای ارزش دارد، چون نوشتن دستی ده ها Conversation branch سخت و پرهزینه است. Simulator می تواند تعامل های چندturn را تولید کند تا Agent مجبور شود سؤال روشن کننده بپرسد، Context قبلی را حفظ کند یا به هدفی که در چند پیام شکل می گیرد برسد. خروجی Simulator باید بخشی از Dataset باشد، نه حقیقت قطعی درباره رفتار همه کاربران.

Environment Simulator از زاویه دیگری مهم است: Tool یا سیستم خارجی را با پاسخ Mock، Error اجباری یا Latency اضافه شبیه سازی می کند. به این ترتیب می توانید بدون خراب کردن Production ببینید Agent وقتی Payment API کند است، Search خالی برمی گرداند یا Tool exception می دهد چگونه Recovery می کند. اینجا Evals به Reliability Engineering نزدیک می شود.

Online Evaluation و Drift در Production

سرویس می تواند Traceهایی را که از Production جمع می کنید به طور پیوسته ارزیابی کند و score-over-time و Drift Alert بسازد. این قابلیت برای Agent مهم تر از API قطعی است، چون رفتار مدل و ترکیب ورودی ها می تواند تغییر کند حتی وقتی کد شما ثابت مانده است. Quality Monitoring باید کنار Latency و Error Rate به یک SLI محصول AI تبدیل شود.

نمونه برداری را هوشمند انتخاب کنید. ارزیابی همه Sessionها با Judge مدل محور می تواند هزینه زیادی بسازد و ممکن است داده حساس بیشتری را وارد مسیر Eval کند. Stratified Sampling بر اساس نوع Task، مشتری، Risk Tier یا Failure Signal معمولاً اطلاعات بهتری از Sampling کاملاً تصادفی می دهد.

چطور Eval را وارد CI/CD کنیم؟

برای هر Pull Request لازم نیست کل Dataset سنگین را اجرا کنید. یک Fast Gate کوچک از Caseهای بحرانی بسازید و Full Evaluation را nightly یا قبل از Release اجرا کنید. Gate باید Threshold و Regression Budget روشن داشته باشد؛ مثلاً افت در Safety یا Task Success بحرانی Blocker باشد اما تغییر کوچک در Style فقط Warning بدهد.

Google اشاره می کند ADK می تواند Evalها را محلی و حتی داخل pytest اجرا کند. همین الگو برای معماری کلی مهم است: Test باید به توسعه دهنده Feedback سریع بدهد و Pipeline مرکزی نیز Run قابل Audit تولید کند. Evals اگر فقط در Dashboard تیم AI دیده شوند، دیر وارد چرخه اصلاح می شوند.

هزینه Evaluation را چگونه کنترل کنیم؟

طبق اعلام رسمی، Metricهای code-based و computation-based هزینه اضافه مدل ندارند، اما LLM-as-a-judge و Metricهای مدل محور هزینه Model Call خود را دارند و اجرای server-side برای Artifactها Cloud Storage مصرف می کند. بنابراین Quality Budget باید کنار Token Budget دیده شود.

برای کاهش هزینه، ابتدا Metric deterministic را هرجا ممکن است استفاده کنید، Judge گران تر را روی Caseهای ambiguous یا High-risk اجرا کنید و Dataset را به Tierهای smoke، regression و full تقسیم کنید. هدف کم کردن Evaluation نیست؛ هدف خرج کردن محاسبه در جایی است که اطلاعات تصمیم بیشتری می دهد.

Trace، PII و امنیت Evaluation

Trace Agent می تواند Prompt، پاسخ، Tool Argument و داده برگشتی سیستم های داخلی را شامل شود. قبل از فعال کردن Online Evaluation، Data Classification و Retention Policy را تعیین کنید. منبع رسمی می گوید Dataset و Trace در Project شما باقی می مانند، اما این موضوع مسئولیت دسترسی، لاگ گذاری و کمینه سازی داده را از تیم حذف نمی کند.

برای محیط حساس، Token یا Secret را قبل از Trace redaction کنید و دسترسی به Experiment Artifactها را محدود نگه دارید. همچنین Tool outputهایی که اطلاعات کاربر دارند نباید صرفاً برای Debug نامحدود ذخیره شوند. Quality Observability باید با Privacy Engineering طراحی شود.

یک برنامه 7 مرحله ای برای شروع Agent Eval

اول هدف محصول را به Success Criteria قابل اندازه گیری تبدیل کنید. دوم 30 تا 100 Case نماینده جمع کنید؛ تعداد جادویی نیست و پوشش مهم تر از حجم است. سوم Metric deterministic و Judge-based را جدا انتخاب کنید. چهارم Baseline Agent فعلی را اجرا کنید. پنجم یک تغییر مشخص مانند Prompt یا Model را مقایسه کنید. ششم Failureها را cluster و تحلیل کنید. هفتم بخشی از همین Metricها را روی Production monitor کنید.

هر Failure باید به یک دسته قابل اقدام برسد: فهم اشتباه هدف، Tool Selection، Argument، Grounding، Safety، Latency یا Recovery. Dashboardی که فقط Average Score نشان می دهد برای مهندسی کافی نیست. تیم باید بتواند از افت Score به Trace و از Trace به یک اصلاح مشخص برسد.

Anti-patternهایی که Eval را بی اثر می کنند

اولین Anti-pattern، Optimize کردن Agent برای همان Dataset کوچکی است که همیشه اجرا می شود؛ نتیجه شبیه overfitting در Test Suite است. دوم، تغییر Rubric پس از دیدن نتیجه برای بهترشدن Score است. سوم، استفاده از یک Judge واحد بدون Human Calibration و چهارم، مقایسه Runهایی است که Model Version یا Tool backend متفاوت دارند.

Anti-pattern دیگر این است که Offline Eval عالی را معادل Production Quality بدانیم. Distribution کاربر، داده واقعی، timeout، permission و failure سیستم های خارجی فقط در محیط واقعی آشکار می شوند. به همین دلیل چرخه کامل باید Offline Experiment و Online Monitor را به هم وصل کند.

چه زمانی این سرویس برای تیم شما ارزشمند است؟

اگر Agent شما چند Tool دارد، Model یا Prompt را مرتب عوض می کند، SLA کیفی دارد یا در محیط Enterprise نیازمند Audit است، یک Evaluation Platform یکپارچه ارزش زیادی ایجاد می کند. اگر فقط Prototype کوچکی با چند کاربر داخلی دارید، ممکن است یک Dataset ساده و Test harness سبک در مرحله اول کافی باشد.

معیار انتخاب باید reproducibility، integration با Trace، هزینه، قابلیت تعریف Metric و تجربه Debug باشد؛ نه تعداد Widgetهای Dashboard. بهترین Eval Platform پلتفرمی است که Failure را سریع به علت و اقدام مهندسی وصل کند.

Human Calibration را چگونه انجام دهیم؟

قبل از اینکه Judge مدل محور روی هزاران Session تصمیم بگیرد، یک مجموعه کوچک اما متنوع را توسط Reviewer انسانی برچسب بزنید. بهتر است حداقل دو Reviewer برای بخشی از Caseها داشته باشید تا بفهمید خود انسان ها چقدر با هم توافق دارند. اگر تعریف «موفقیت» برای انسان ها مبهم است، انتظار ثبات بالا از LLM Judge منطقی نیست. اختلاف ها را به بهبود Rubric یا روشن ترکردن Product Requirement تبدیل کنید.

پس از ساخت Baseline، نمونه های False Positive و False Negative Judge را نگه دارید و در هر تغییر Metric دوباره اجرا کنید. Calibration یک فعالیت یک باره نیست؛ Model Judge، Prompt Judge و نوع Traffic عوض می شوند. برای Gateهای مهم، نسخه Judge و Rubric را کنار نتیجه Experiment ذخیره کنید تا Score ماه قبل و امروز واقعاً قابل مقایسه باشد.

Runbook وقتی Quality Score افت می کند

Alert باید مستقیم به اقدام وصل شود. ابتدا بررسی کنید افت عمومی است یا فقط یک Task/Segment را درگیر کرده؛ سپس تغییرات هم زمان Model، Prompt، Tool backend و Data source را فهرست کنید. Traceهای نمونه را باز کنید و Failure Cluster را تعیین کنید. اگر Tool backend دچار timeout شده، Prompt rollback احتمالاً مسئله را حل نمی کند؛ اگر Grounding افت کرده، زیرساخت Retrieval اولویت دارد.

برای Rollback نیز نسخه قابل بازگشت Agent Configuration داشته باشید: Model، Prompt، Tool schema و Feature Flag. Quality Incident بدون Configuration Versioning می تواند طولانی شود چون تیم نمی داند دقیقاً چه چیزی در Session بد با Session خوب متفاوت بوده است. Eval زمانی عملیاتی می شود که به همین Runbook، on-call و release process متصل باشد.

نمونه یا الگوی عملی

def release_gate(baseline, candidate):
  critical = ["task_success", "safety", "tool_use_quality"]
  for metric in critical:
    if candidate[metric] < baseline[metric]:
      raise RuntimeError(f"Regression detected: {metric}")

# در پروژه واقعی، threshold و confidence هر metric را مستقل تعریف کنید.

این مثال API واقعی Google نیست؛ یک الگوی کوچک برای تفکر Release Gate است. نقطه اصلی این است که Metricهای بحرانی را صریح و مستقل از Average Score تعریف کنید تا بهبود یک بعد، Regression خطرناک در بعد دیگر را پنهان نکند.

پرسش های متداول

Agent and Model Evaluations چه زمانی GA شد؟

Google در 31 ژوئیه 2026 GA شدن این قابلیت را اعلام کرد.

آیا فقط مدل Gemini را می توان ارزیابی کرد؟

سرویس در Agent Platform برای Agent و Model evaluation طراحی شده است؛ دامنه دقیق Providerها و Regionها را باید از مستندات جاری سرویس بررسی کنید.

Adaptive Rubric همان LLM-as-a-Judge است؟

یک workflow Judge مدل محور است اما معیارهای case-specific را از تعریف Case، instruction و tool declarations می سازد؛ همچنان نیازمند Calibration انسانی است.

Online Evaluation چه چیزی را مانیتور می کند؟

Traceهای Production را امتیازدهی می کند و می تواند score-over-time و Drift Alert بسازد.

کدام Metricها هزینه مدل ندارند؟

طبق منبع رسمی، code-based و computation-based metrics هزینه مدل اضافه ندارند؛ Metricهای مدل محور هزینه Model Call دارند.

آیا Eval خوب جای Human Review را می گیرد؟

خیر. مخصوصاً برای دامنه حساس، Human Calibration و بررسی نمونه Failureها بخش ضروری سیستم Evaluation است.

منابع رسمی

• اعلام رسمی GA شدن Agent and Model Evaluations — Metricها، Experiment، Simulator، Online Monitor، Pricing و روش های دسترسی
• مستندات رسمی ارزیابی مدل و Agent در Google Cloud — مرجع تکمیلی مفاهیم Evaluation و Metricها