Evals چیست؟ راهنمای کامل ارزیابی و مقایسۀ مدل‌های هوش مصنوعی

انتخاب مدل هوش مصنوعی فقط با نگاه کردن به سَنجه‌های عمومی، قیمت توکن یا شهرت شرکت سازنده امکان‌پذیر نیست. مدلی که در یک آزمون عمومی رتبۀ بالایی دارد، ممکن است در پردازش متن فارسی، استخراج اطلاعات از اسناد شما، اجرای Tool Calling یا پاسخ‌گویی به مشتریان عملکرد مناسبی نداشته باشد.

حتی اگر یک مدل در آزمایش اولیه خوب به نظر برسد، پس از تغییر Prompt، اضافه شدن RAG، انتشار نسخۀ جدید مدل یا افزایش طول ورودی ممکن است رفتار آن تغییر کند.

در یک محصول واقعی باید بتوانیم به پرسش‌های زیر پاسخ دهیم:

• کدام مدل برای وظیفۀ ما دقیق‌تر است؟
• آیا مدل اقتصادی‌تر کیفیت قابل‌قبولی دارد؟
• تغییر Prompt باعث بهبود پاسخ شده یا افت کیفیت؟
• مدل جدید واقعاً از مدل قبلی بهتر است؟
• چند درصد خروجی‌های JSON معتبرند؟
• RAG تا چه اندازه اسناد مرتبط را بازیابی می‌کند؟
• آیا پاسخ مدل واقعاً براساس منابع بازیابی‌شده است؟
• Agent چند درصد ابزار درست را انتخاب می‌کند؟
• هزینۀ هر نتیجۀ موفق چقدر است؟
• آیا مدل در ورودی‌های فارسی نیز عملکرد پایداری دارد؟
• آیا پاسخ‌ها در محیط عملیاتی با آزمایش‌های اولیه یکسان‌اند؟

Evals برای پاسخ دادن به همین پرسش‌ها استفاده می‌شود.

Eval مخفف Evaluation است و به فرایندی ساختاریافته برای اندازه‌گیری عملکرد یک مدل، پرامپت، سیستم RAG، Agent یا قابلیت هوش مصنوعی گفته می‌شود.

یک Eval حرفه‌ای فقط چند پرامپت آزمایشی نیست. این فرایند شامل دیتاست، معیار موفقیت، اجرای تکرارپذیر، ثبت نتایج، مقایسۀ نسخه‌ها و تحلیل خطا است.

پاسخ کوتاه: Evals چیست؟

Evals مجموعه‌ای از آزمون‌های تکرارپذیر برای سنجش کیفیت و عملکرد سیستم‌های هوش مصنوعی است.

در یک Eval معمولاً اجزای زیر وجود دارند:

• مجموعۀ داده آزمایشی
• ورودی‌های واقعی یا شبیه‌سازی‌شده
• خروجی موردانتظار یا معیار ارزیابی
• مدل یا سیستم تحت آزمایش
• روش امتیازدهی
• گزارش کیفیت، هزینه و سرعت
• مقایسۀ نسخه‌ها

برای مثال، اگر یک مدل وظیفۀ دسته‌بندی تیکت‌ها را انجام دهد، Eval می‌تواند بررسی کند مدل چند درصد تیکت‌ها را در دستۀ صحیح قرار می‌دهد:

{
  "input": "مبلغ از کیف پول من کم شده اما پاسخ مدل دریافت نشده است.",
  "expected_category": "billing",
  "expected_priority": "high"
}

پس از اجرای مدل:

{
  "category": "billing",
  "priority": "high"
}

این پاسخ با خروجی موردانتظار مقایسه و امتیاز ثبت می‌شود.

چرا ارزیابی چشمی کافی نیست؟

در مرحلۀ ابتدایی معمولاً چند پرامپت به مدل داده می‌شود و پاسخ‌ها به‌صورت دستی بررسی می‌شوند. این روش برای شناخت اولیه مفید است، اما برای تصمیم عملیاتی کافی نیست.

مشکلات ارزیابی چشمی:

• تعداد نمونه‌ها محدود است.
• موارد دشوار نادیده گرفته می‌شوند.
• قضاوت افراد متفاوت است.
• نتایج ثبت و نسخه‌بندی نمی‌شوند.
• مقایسۀ چند مدل دشوار می‌شود.
• هزینه و تاخیراندازه‌گیری نمی‌شوند.
• تغییرات کوچک پرامپت قابل‌ردیابی نیستند.
• خطاهای نادر اما مهم دیده نمی‌شوند.

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

Evals چه چیزهایی را ارزیابی می‌کند؟

Evals فقط برای خود مدل زبانی نیست. می‌توان تمام زنجیرۀ یک محصول هوش مصنوعی را ارزیابی کرد:

• مدل
• Prompt
• System Prompt
• Structured Output
• Tool Calling
• RAG
• Retrieval
• Reranking
• Agent
• Guardrail
• Fallback
• Model Router
• خلاصه‌سازی تاریخچه
• پاسخ نهایی
• هزینه
• Latency
• پایداری

بنابراین واحد ارزیابی می‌تواند یک مدل منفرد یا کل سیستم باشد.

تفاوت Model Eval و System Eval

Model Eval

خود مدل را با یک Prompt و تنظیمات مشخص ارزیابی می‌کند:

Input
→ Model
→ Output

System Eval

تمام اجزای محصول را ارزیابی می‌کند:

Input
→ Retrieval
→ Reranking
→ Prompt Construction
→ Model
→ Tool Calling
→ Output Validation
→ Final Response

ممکن است مدل قدرتمند باشد، اما Retrieval سند اشتباه را پیدا کند. در این شرایط کیفیت پایین پاسخ الزاماً تقصیر مدل نیست.

هدف Eval باید پیش از انتخاب مدل مشخص شود

پیش از اجرای آزمون باید تعریف کنید «پاسخ خوب» چیست.

برای مثال، در دسته‌بندی تیکت:

خروجی صحیح
+ JSON معتبر
+ زمان پاسخ کمتر از ۲ ثانیه
+ هزینه کمتر از سقف تعیین‌شده

در یک دستیار RAG:

پاسخ مرتبط
+ استناد صحیح
+ نداشتن ادعای خارج از منبع
+ رعایت مجوز دسترسی

در Agent:

انتخاب ابزار صحیح
+ آرگومان معتبر
+ عدم اجرای عملیات غیرمجاز
+ تکمیل وظیفه در کمتر از ۵ مرحله

بدون تعریف موفقیت، امتیاز مدل معنای عملی نخواهد داشت.

اجزای اصلی یک Eval

Dataset

مجموعه‌ای از نمونه‌های ورودی، خروجی موردانتظار و متادیتا است.

Target

مدل، پرامپت، عامل یا سیستم مورد ارزیابی.

Evaluator

منطقی که خروجی را بررسی و امتیازدهی می‌کند.

Metrics

اعدادی که عملکرد سیستم را نمایش می‌دهند.

Report

گزارش نتایج، خطاها، هزینه‌ها و مقایسۀ نسخه‌ها.

ساخت دیتاسِت ارزیابی

کیفیت Eval به کیفیت دیتاسِت وابسته است. اگر دیتاست نمایندۀ ترافیک واقعی محصول نباشد، نتیجۀ ارزیابی قابل‌اعتماد نخواهد بود.

یک دیتاسِت خوب باید شامل این دسته‌ها باشد:

• موارد عادی
• موارد پرتکرار
• موارد دشوار
• ورودی‌های مبهم
• موارد مرزی
• داده‌های ناقص
• متن فارسی
• متن ترکیبی فارسی و انگلیسی
• ورودی طولانی
• ورودی بسیار کوتاه
• خطاهای واقعی کاربران
• تلاش‌های Prompt Injection
• محتوای غیرمجاز
• موارد حساس کسب‌وکار

منابع ساخت دیتاسِت

داده‌های واقعی محیط عملیاتی

بهترین منبع برای شناخت رفتار واقعی کاربران است، اما باید پیش از استفاده:

• اطلاعات شخصی حذف شوند.
• داده‌های حساس ناشناس شوند.
• مجوز استفاده بررسی شود.
• دسترسی دیتاسِت محدود شود.
• سیاست نگهداری مشخص باشد.

تیکت‌ها و خطاهای گذشته

مواردی که سیستم قبلاً در آن‌ها شکست خورده، نمونه‌های ارزشمندی برای Regression Test هستند.

هر خطای مهم محیط عملیاتی بهتر است به یک Test Case تبدیل شود.

داده‌های کارشناسان دامنه

کارشناسان می‌توانند نمونه‌های درست و موارد مرزی را مشخص کنند.

داده‌های مصنوعی

مدل دیگری می‌تواند نمونه‌های متنوع تولید کند، اما داده مصنوعی نباید تنها منبع Dataset باشد؛ زیرا ممکن است سوگیری مدل تولیدکننده را تکرار کند.

نمونه‌های رقبا یا سنجه عمومی

برای مقایسۀ اولیه مفیدند، اما باید با Dataset اختصاصی محصول ترکیب شوند.

ساختار پیشنهادی هر Test Case

{
  "id": "ticket-001",
  "input": {
    "text": "مبلغ شارژ از حساب بانکی کم شد ولی کیف پول افزایش پیدا نکرد."
  },
  "expected": {
    "category": "billing",
    "priority": "high",
    "requires_human": true
  },
  "metadata": {
    "language": "fa",
    "difficulty": "medium",
    "source": "production_anonymized",
    "tags": ["payment", "wallet"]
  }
}

وجود متادیتا امکان تحلیل دقیق‌تر نتایج را فراهم می‌کند.

برای مثال، ممکن است دقت کلی ۹۰ درصد باشد، اما دقت در نمونه‌های فارسی طولانی فقط ۶۵ درصد باشد.

تقسیم دیتاسِت

Development Set

برای طراحی پرامپت و اصلاح سیستم استفاده می‌شود.

Validation Set

برای انتخاب مدل و تنظیم پارامترها کاربرد دارد.

Test Set

برای ارزیابی نهایی است و نباید دائماً برای تنظیم پرامپت استفاده شود.

Production Set

نمونه‌های ناشناس‌شده از ترافیک واقعی برای بررسی مستمر.

اگر همۀ تصمیم‌ها براساس Test Set گرفته شوند، سیستم روی همان مجموعه Overfit می‌شود و عملکرد واقعی آن ممکن است پایین‌تر باشد.

Golden Dataset چیست؟

Golden Dataset مجموعه‌ای از نمونه‌های باکیفیت و تأییدشده توسط متخصصان است که خروجی صحیح آن‌ها مشخص است.

ویژگی‌های مناسب:

• بازبینی انسانی
• پوشش سناریوهای اصلی
• تنوع کافی
• نسخه‌بندی
• متادیتا
• نگهداری امن
• امکان ردیابی تغییرات

Golden Dataset باید با تغییر محصول و کشف خطاهای جدید به‌روزرسانی شود.

انواع روش‌های ارزیابی

ارزیابی قطعی

خروجی با قاعده‌ای دقیق بررسی می‌شود:

• Exact Match
• JSON Validation
• Regex
• Schema Validation
• Unit Test
• اجرای کد
• بررسی مقدار عددی
• بررسی وجود Citation

این روش تکرارپذیر و ارزان است.

ارزیابی آماری

برای وظایف طبقه‌بندی و بازیابی:

• Accuracy
• Precision
• Recall
• F1 Score
• Mean Reciprocal Rank
• NDCG
• Hit Rate

ارزیابی انسانی

کارشناس یا کاربر پاسخ را ارزیابی می‌کند.

ارزیابی با مدل داور

یک مدل زبانی دیگر خروجی را براساس Rubric امتیازدهی می‌کند.

ارزیابی رفتاری

رفتار واقعی کاربر بررسی می‌شود:

• پذیرش پاسخ
• تولید مجدد
• ویرایش پاسخ
• رضایت
• نرخ تبدیل
• حل شدن تیکت
• ارجاع به نیروی انسانی

Exact Match

در Exact Match پاسخ باید دقیقاً با خروجی موردانتظار برابر باشد.

Expected: billing
Actual: billing
Result: pass

برای دسته‌بندی، کد وضعیت و پاسخ کوتاه مناسب است.

برای پاسخ‌های آزاد مناسب نیست؛ زیرا دو پاسخ متفاوت می‌توانند از نظر معنایی هر دو درست باشند.

Accuracy

Accuracy =
تعداد پاسخ‌های صحیح
÷ تعداد کل پاسخ‌ها

اگر ۹۲۰ مورد از هزار نمونه صحیح باشند:

920 ÷ 1000 = 0.92

دقت برابر ۹۲ درصد است.

Accuracy در Dataset نامتوازن می‌تواند گمراه‌کننده باشد.

Precision و Recall

فرض کنید مدل باید تیکت‌های فوری را شناسایی کند.

Precision

از میان مواردی که مدل فوری اعلام کرده، چند مورد واقعاً فوری بوده‌اند؟

Precision =
True Positive
÷ (True Positive + False Positive)

Recall

از میان تمام تیکت‌های واقعاً فوری، چند مورد شناسایی شده‌اند؟

Recall =
True Positive
÷ (True Positive + False Negative)

اگر از دست دادن یک مورد فوری خطرناک باشد، Recall اهمیت بیشتری دارد.

F1 Score

میانگین هماهنگ Precision و Recall است:

F1 =
2 × Precision × Recall
÷ (Precision + Recall)

برای مسائل نامتوازن معمولاً از Accuracy مناسب‌تر است.

JSON Validity

در کاربردهای برنامه‌نویسی باید درصد خروجی‌هایی را اندازه‌گیری کرد که JSON معتبر هستند:

JSON Validity Rate =
Valid JSON Responses
÷ Total Responses

این معیار با Schema Compliance متفاوت است. ممکن است JSON معتبر باشد، اما فیلد ضروری را نداشته باشد.

Schema Compliance

خروجی با JSON Schema، Zod یا Pydantic اعتبارسنجی می‌شود.

نمونه Schema با Zod:

import { z } from "zod";

const TicketSchema = z.object({
  category: z.enum([
    "billing",
    "technical",
    "account",
    "other",
  ]),
  priority: z.enum([
    "low",
    "medium",
    "high",
  ]),
  requiresHuman: z.boolean(),
});

Evaluator:

function evaluateSchema(output: unknown) {
  const result = TicketSchema.safeParse(output);

  return {
    passed: result.success,
    error: result.success
      ? null
      : result.error.issues,
  };
}

ارزیابی معنایی

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

روش‌ها:

• Embedding Similarity
• BERTScore
• مدل داور
• بررسی انسانی
• Rubric اختصاصی

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

ارزیابی با Rubric

Rubric معیارهای پاسخ خوب را مشخص می‌کند.

مثال:

صحت: ۰ تا ۴
کامل بودن: ۰ تا ۴
ارتباط با پرسش: ۰ تا ۴
شفافیت: ۰ تا ۴
رعایت محدودیت: صفر یا یک

امتیاز کلی:

Total =
Accuracy × 0.4
+ Completeness × 0.25
+ Relevance × 0.2
+ Clarity × 0.15

وزن‌ها باید براساس نیاز محصول انتخاب شوند.

LLM-as-a-Judge چیست؟

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

ورودی داور می‌تواند شامل موارد زیر باشد:

• پرسش
• پاسخ تولیدشده
• پاسخ مرجع
• اسناد منبع
• Rubric
• قالب امتیاز

نمونۀ Prompt داور:

پاسخ را براساس صحت، ارتباط و کامل بودن ارزیابی کن.

امتیاز هر معیار باید عددی بین ۰ تا ۴ باشد.

اگر پاسخ ادعایی خارج از منابع دارد، groundedness را صفر قرار بده.

خروجی فقط JSON معتبر باشد.

مزایای LLM-as-a-Judge

• مقیاس‌پذیرتر از ارزیابی دستی
• مناسب پاسخ‌های آزاد
• امکان استفاده از Rubric
• سرعت بیشتر
• قابلیت مقایسۀ چند پاسخ

محدودیت‌های LLM-as-a-Judge

• داور ممکن است اشتباه کند.
• ممکن است پاسخ‌های طولانی را ترجیح دهد.
• ممکن است به نام مدل حساس باشد.
• ترتیب پاسخ‌ها می‌تواند اثر بگذارد.
• سبک نگارش می‌تواند امتیاز را منحرف کند.
• هزینۀ اضافی ایجاد می‌کند.
• تغییر مدل داور می‌تواند نتایج را تغییر دهد.

کاهش سوگیری مدل داور

• نام مدل تولیدکننده را مخفی کنید.
• ترتیب پاسخ‌ها را تصادفی کنید.
• Rubric دقیق بنویسید.
• مثال‌های امتیازدهی ارائه کنید.
• خروجی داور را Structured کنید.
• بخشی از نتایج را انسانی بازبینی کنید.
• توافق چند داور را اندازه‌گیری کنید.
• برای موارد حساس از چند روش ارزیابی استفاده کنید.

Pairwise Evaluation

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

پاسخ A
پاسخ B

خروجی:

{
  "winner": "A",
  "reason": "پاسخ A دقیق‌تر و مستندتر است."
}

برای کاهش سوگیری ترتیب، همان مقایسه را با جابه‌جایی A و B تکرار کنید.

ارزیابی انسانی

در وظایف حساس، ارزیابی انسانی همچنان ضروری است.

چه زمانی؟

• پزشکی
• حقوقی
• مالی
• محتوای برند
• تصمیم‌های پرریسک
• داده‌های پیچیدۀ دامنه
• ارزیابی لحن
• موارد اختلاف میان داورها

طراحی فرم ارزیابی

هر معیار باید تعریف روشن داشته باشد:

توافق میان ارزیابان

اگر دو ارزیاب انسانی پاسخ یکسانی را متفاوت امتیاز دهند، مشکل ممکن است از Rubric باشد.

معیارهای توافق:

• Percent Agreement
• Cohen’s Kappa
• Krippendorff’s Alpha

توافق پایین نشان می‌دهد تعریف پاسخ خوب به‌اندازۀ کافی شفاف نیست.

ارزیابی هزینۀ مدل

کیفیت تنها معیار انتخاب مدل نیست.

متریک‌های مالی:

• هزینه هر درخواست
• هزینه هر خروجی معتبر
• هزینه هر پاسخ پذیرفته‌شده
• هزینه هر Tool Call موفق
• هزینه هر مکالمه
• هزینه هر کاربر فعال

فرمول مهم:

Cost per Successful Result =
Total Cost
÷ Successful Results

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

ارزیابی Latency

متریک‌های مناسب:

• Time to First Token
• Total Response Time
• P50
• P90
• P95
• P99
• Timeout Rate

میانگین تاخیر کافی نیست. ممکن است متوسط مناسب باشد، اما یک درصد کاربران چندین ثانیه منتظر بمانند.

ارزیابی پایداری

• Error Rate
• Timeout Rate
• Rate Limit Rate
• Empty Response Rate
• Fallback Rate
• Retry Rate
• Invalid Output Rate

مدلی که کیفیت بالایی دارد اما مرتباً با خطا روبه‌رو می‌شود، ممکن است برای مسیر اصلی Production مناسب نباشد.

Quality-Cost-Latency Trade-off

انتخاب مدل معمولاً یک مسئلۀ چندمعیاره است:

Score =
Quality × Wq
- Cost × Wc
- Latency × Wl
- Error Rate × We

وزن‌ها به کاربرد بستگی دارند.

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

نمونۀ مقایسۀ مدل‌ها

هیچ مدل واحدی در تمام ستون‌ها بهترین نیست.

Eval برای طبقه‌بندی

مناسب‌ترین معیارها:

• Accuracy
• Precision
• Recall
• F1
• Confusion Matrix
• Cost per Classification
• Latency

Confusion Matrix نشان می‌دهد مدل کدام دسته‌ها را با یکدیگر اشتباه می‌گیرد.

Eval برای استخراج اطلاعات

معیارها:

• Field-Level Accuracy
• Exact Match
• Schema Compliance
• Missing Field Rate
• Hallucinated Field Rate
• Numeric Accuracy
• Date Parsing Accuracy

برای هر فیلد جداگانه امتیاز ثبت کنید:

invoice_number: 98%
date: 91%
total_amount: 96%
customer_name: 87%

امتیاز کلی می‌تواند مشکل یک فیلد مهم را پنهان کند.

Eval برای خلاصه‌سازی

معیارها:

• پوشش نکات اصلی
• صحت
• فشردگی
• نبود اطلاعات ساختگی
• رعایت طول
• لحن
• ROUGE یا معیارهای مشابه
• ارزیابی انسانی یا مدل داور

خلاصۀ طولانی‌تر الزاماً بهتر نیست.

Eval برای تولید کد

کد باید اجرا و آزمایش شود.

معیارها:

• Pass Rate تست‌ها
• Compilation Success
• Runtime Error
• Security Checks
• Performance
• رعایت API Contract
• تعداد تلاش تا موفقیت
• هزینه حل مسئله

اجرای واقعی Test Suite از قضاوت زبانی دقیق‌تر است.

Eval برای Structured Output

• JSON Validity
• Schema Compliance
• Field Accuracy
• Enum Accuracy
• Missing Fields
• Extra Fields
• Retry Rate
• Repair Rate

اگر سیستم برای اصلاح JSON نامعتبر Retry انجام می‌دهد، هزینه و تعداد Retry نیز باید ثبت شوند.

Eval برای Tool Calling

سه بخش را جدا ارزیابی کنید:

انتخاب ابزار

آیا مدل ابزار صحیح را انتخاب کرده است؟

Tool Selection Accuracy

آرگومان ابزار

آیا آرگومان‌ها معتبر و صحیح هستند؟

Argument Validity
Argument Accuracy

نتیجۀ نهایی

آیا مدل پس از دریافت نتیجۀ ابزار، پاسخ صحیح تولید کرده است؟

متریک‌های دیگر:

• ابزار غیرضروری
• فراخوانی تکراری
• Tool Loop
• عملیات غیرمجاز
• تعداد مراحل
• هزینه کل

Eval برای Agent

ارزیابی عامل پیچیده‌تر است؛ زیرا مسیر رسیدن به نتیجه اهمیت دارد.

معیارها:

• Task Completion Rate
• Tool Success Rate
• Step Count
• Model Call Count
• Total Cost
• Total Duration
• Loop Rate
• Unauthorized Action Rate
• Human Escalation Rate

دو عمامل ممکن است هر دو به نتیجۀ صحیح برسند، اما یکی ۳ مرحله و دیگری ۲۰ مرحله طی کند.

ارزیابی مسیر یا Trace

Trace شامل تمام مراحل اجرای Agent است:

User Request
→ Model Decision
→ Tool Call
→ Tool Result
→ Model Decision
→ Final Answer

Eval باید علاوه بر پاسخ نهایی، مسیر را نیز بررسی کند:

• ابزار درست انتخاب شد؟
• ابزار غیرضروری اجرا شد؟
• داده حساس به مدل ارسال شد؟
• Retry لازم بود؟
• محدودیت هزینه رعایت شد؟
• عملیات خطرناک تأیید انسانی داشت؟

Eval برای RAG

کیفیت RAG از دو بخش اصلی تشکیل می‌شود:

Retrieval Quality
+ Generation Quality

این دو باید جداگانه ارزیابی شوند.

ارزیابی Retrieval

Hit Rate

آیا سند مرتبط در میان نتایج بازیابی‌شده وجود دارد؟

Hit Rate@K

Recall@K

چه درصدی از اسناد مرتبط در K نتیجۀ اول بازیابی شده‌اند؟

Precision@K

چه درصدی از K نتیجۀ اول واقعاً مرتبط‌اند؟

Mean Reciprocal Rank

اولین نتیجۀ مرتبط در چه رتبه‌ای قرار دارد؟

NDCG

کیفیت رتبه‌بندی چند سند با درجات مختلف ارتباط را می‌سنجد.

ارزیابی Generation در RAG

Answer Relevance

پاسخ تا چه اندازه به سؤال مرتبط است؟

Groundedness

آیا ادعاهای پاسخ توسط Context پشتیبانی می‌شوند؟

Faithfulness

آیا مدل بدون تحریف به منابع پایبند مانده است؟

Citation Correctness

آیا استنادها واقعاً از ادعا پشتیبانی می‌کنند؟

Completeness

آیا تمام بخش‌های مهم سؤال پاسخ داده شده‌اند؟

تشخیص محل خطای RAG

اگر پاسخ اشتباه است، ابتدا مشخص کنید مشکل در کدام مرحله رخ داده است:

سند مرتبط بازیابی نشده
→ Retrieval Problem

سند درست بازیابی شده اما پایین رتبه بوده
→ Ranking Problem

سند درست در Context بوده اما مدل اشتباه پاسخ داده
→ Generation Problem

پاسخ درست است اما Citation اشتباه است
→ Citation Problem

بدون این تفکیک، ممکن است مدل را عوض کنید درحالی‌که مشکل اصلی Chunking یا Retrieval است.

Eval برای Model Router

در معماری چندمدلی باید خود روتر نیز ارزیابی شود.

معیارها:

• Routing Accuracy
• Capability Match
• Budget Compliance
• Latency Compliance
• Fallback Rate
• Cost Savings
• Quality Loss
• Unsupported Model Selection Rate

نمونۀ Test Case:

{
  "task": "analyze_image",
  "requirements": {
    "vision": true,
    "structured_output": true
  },
  "expected_group": "vision-structured"
}

Router نباید درخواست تصویر را به مدل Text-only ارسال کند.

Eval برای جایگزینی مدل

سناریوهای خرابی را شبیه‌سازی کنید:

• پاسخ 429
• Timeout
• پاسخ 503
• قطع اتصال
• Provider ناسالم
• Model Not Found
• خروجی نامعتبر

بررسی کنید:

• Fallback فقط برای خطای مناسب انجام شد؟
• مدل جایگزین قابلیت لازم را داشت؟
• Request ID حفظ شد؟
• هزینه هر Attempt ثبت شد؟
• عملیات تکراری انجام نشد؟
• پاسخ نهایی قابل‌استفاده بود؟

Eval آفلاین و آنلاین

Offline Eval

روی دیتاسِت ثابت و خارج از ترافیک واقعی اجرا می‌شود.

مناسب برای:

• مقایسۀ مدل
• تغییر پرامپت
• Regression Test
• ارزیابی مدل جدید
• بررسی امنیت

Online Eval

در محیط Production و روی ترافیک واقعی انجام می‌شود.

مناسب برای:

• رفتار واقعی کاربران
• Latency واقعی
• نرخ پذیرش
• هزینه واقعی
• Drift
• خطاهای پیش‌بینی‌نشده

بهترین راهکار ترکیب هر دو است.

Shadow Evaluation

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

درخواست کاربر
├── مدل Production → پاسخ به کاربر
└── مدل Candidate → فقط ارزیابی

مزایا:

• داده واقعی
• بدون ریسک برای کاربر
• مقایسۀ مستقیم
• کشف مشکلات محیط عملیاتی

معایب:

• هزینه تقریباً بیشتر
• نیاز به رعایت حریم خصوصی
• پیچیدگی ثبت و تطبیق
• افزایش بار زیرساخت

A/B Testing

در A/B Test، بخشی از کاربران پاسخ مدل جدید را دریافت می‌کنند.

گروه‌بندی باید پایدار باشد:

Group A → مدل فعلی
Group B → مدل جدید

متریک‌ها:

• رضایت
• نرخ تبدیل
• نرخ تولید مجدد
• مدت مکالمه
• ارجاع به پشتیبانی
• هزینه
• تاخیر

A/B Test زمانی مناسب است که Offline Eval نشان داده مدل جدید حداقل معیارهای ایمنی و کیفیت را دارد.

Regression Testing

هر تغییر در این اجزا می‌تواند کیفیت را تغییر دهد:

• مدل
• Prompt
• Tool Schema
• Retrieval
• Chunking
• Reranker
• پارامترها
• Gateway
• Provider
• System Prompt

Regression Test تضمین می‌کند قابلیت‌های قبلی پس از تغییر همچنان درست کار می‌کنند.

هر خطای محیط عملیاتی باید به Test Case تبدیل شود

فرایند پیشنهادی:

خطای واقعی
→ تحلیل علت
→ ناشناس‌سازی داده
→ افزودن به Dataset
→ اصلاح سیستم
→ اجرای Regression Eval

این فرایند باعث می‌شود خطاهای قبلی دوباره تکرار نشوند.

Drift چیست؟

Drift یعنی تغییر تدریجی رفتار سیستم یا داده‌های ورودی.

انواع Drift:

Data Drift

نوع درخواست کاربران تغییر می‌کند.

Model Drift

نسخۀ مدل یا رفتار ارائه‌دهنده تغییر می‌کند.

Prompt Drift

پرامپت‌ها بدون کنترل تغییر می‌کنند.

Retrieval Drift

اسناد یا Index به‌روزرسانی می‌شوند.

Business Drift

تعریف پاسخ درست یا سیاست محصول تغییر می‌کند.

Evalهای دوره‌ای برای شناسایی Drift ضروری‌اند.

Versioning

برای بازتولید نتیجه باید این موارد ثبت شوند:

model_id
provider
model_version
prompt_version
dataset_version
evaluator_version
tool_schema_version
retrieval_version
parameters
timestamp

ثبت عبارت «از مدل X استفاده شد» کافی نیست؛ زیرا مدل ممکن است نسخۀ شناور داشته باشد.

نمونه Dataset در JSONL

{"id":"1","input":"رمز عبورم را فراموش کرده‌ام","expected":{"category":"account"},"metadata":{"language":"fa","difficulty":"easy"}}
{"id":"2","input":"از کیف پول مبلغ کم شد ولی پاسخ نگرفتم","expected":{"category":"billing"},"metadata":{"language":"fa","difficulty":"medium"}}
{"id":"3","input":"API با خطای 429 پاسخ می‌دهد","expected":{"category":"technical"},"metadata":{"language":"fa","difficulty":"easy"}}

هر خط یک Test Case مستقل است.

پیاده‌سازی Eval ساده با Node.js و API درواره

ابتدا SDK را نصب کنید:

npm install openai zod

Client درواره:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.DARVAREH_API_KEY,
  baseURL: "https://api.darvareh.ir/v1",
});

Base URL درواره:

https://api.darvareh.ir/v1

تعریف Schema:

import { z } from "zod";

const OutputSchema = z.object({
  category: z.enum([
    "billing",
    "technical",
    "account",
    "other",
  ]),
});

Dataset:

const dataset = [
  {
    id: "1",
    input: "کیف پولم شارژ نشده است.",
    expected: {
      category: "billing",
    },
  },
  {
    id: "2",
    input: "کلید API من کار نمی‌کند.",
    expected: {
      category: "technical",
    },
  },
  {
    id: "3",
    input: "چگونه ایمیلم را تغییر دهم؟",
    expected: {
      category: "account",
    },
  },
];

اجرای مدل:

async function runModel(model, input) {
  const startedAt = Date.now();

  const response =
    await client.chat.completions.create({
      model,
      messages: [
        {
          role: "system",
          content: `
پیام را در یکی از دسته‌های زیر قرار بده:
billing, technical, account, other

فقط JSON برگردان:
{"category":"..."}
          `.trim(),
        },
        {
          role: "user",
          content: input,
        },
      ],
      temperature: 0,
    });

  return {
    content:
      response.choices[0]?.message?.content ?? "",
    latencyMs: Date.now() - startedAt,
    usage: response.usage,
  };
}

ارزیابی:

function evaluateOutput(content, expected) {
  try {
    const parsed = JSON.parse(content);
    const validated = OutputSchema.parse(parsed);

    return {
      validJson: true,
      validSchema: true,
      correct:
        validated.category === expected.category,
      actual: validated,
    };
  } catch (error) {
    return {
      validJson: false,
      validSchema: false,
      correct: false,
      actual: null,
      error: error.message,
    };
  }
}

اجرای Dataset:

async function runEval(model) {
  const results = [];

  for (const item of dataset) {
    try {
      const modelResult = await runModel(
        model,
        item.input,
      );

      const evaluation = evaluateOutput(
        modelResult.content,
        item.expected,
      );

      results.push({
        id: item.id,
        ...evaluation,
        latencyMs: modelResult.latencyMs,
        inputTokens:
          modelResult.usage?.prompt_tokens ?? 0,
        outputTokens:
          modelResult.usage?.completion_tokens ?? 0,
      });
    } catch (error) {
      results.push({
        id: item.id,
        correct: false,
        requestFailed: true,
        error: error.message,
      });
    }
  }

  const total = results.length;
  const correct = results.filter(
    (result) => result.correct,
  ).length;

  const validSchema = results.filter(
    (result) => result.validSchema,
  ).length;

  const averageLatency =
    results.reduce(
      (sum, result) =>
        sum + (result.latencyMs ?? 0),
      0,
    ) / total;

  return {
    model,
    total,
    accuracy: correct / total,
    schemaValidity: validSchema / total,
    averageLatency,
    results,
  };
}

const report = await runEval("MODEL_ID");
console.dir(report, { depth: null });

مقدار MODEL_ID باید با شناسه واقعی مدل در کاتالوگ درواره جایگزین شود.

اجرای چند مدل

const candidates = [
  "MODEL_A_ID",
  "MODEL_B_ID",
  "MODEL_C_ID",
];

const reports = [];

for (const model of candidates) {
  reports.push(await runEval(model));
}

console.table(
  reports.map((report) => ({
    model: report.model,
    accuracy:
      `${(report.accuracy * 100).toFixed(1)}%`,
    schemaValidity:
      `${(report.schemaValidity * 100).toFixed(1)}%`,
    averageLatencyMs:
      Math.round(report.averageLatency),
  })),
);

اجرای موازی با محدودیت

اجرای تمام موارد به‌صورت هم‌زمان ممکن است باعث خطای 429 شود. بهتر است Concurrency محدود شود.

نمونۀ مفهومی:

async function runWithConcurrency(
  items,
  concurrency,
  handler,
) {
  const results = new Array(items.length);
  let index = 0;

  async function worker() {
    while (true) {
      const current = index++;

      if (current >= items.length) {
        return;
      }

      results[current] = await handler(
        items[current],
      );
    }
  }

  await Promise.all(
    Array.from(
      { length: concurrency },
      () => worker(),
    ),
  );

  return results;
}

Retry در Eval

Retry زیاد می‌تواند نتیجۀ آزمون را مخدوش کند. بهتر است دو متریک جدا ثبت شوند:

• نتیجۀ تلاش اول
• نتیجۀ نهایی پس از Retry

اگر یک مدل در ۲۰ درصد درخواست‌ها به Retry نیاز داشته باشد، پایداری آن پایین‌تر است؛ حتی اگر پاسخ نهایی صحیح باشد.

تکرار آزمون‌های غیرقطعی

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

برای سنجش ثبات:

هر Test Case را چند بار اجرا کنید.

معیارها:

• Pass Rate
• Variance
• Consistency
• Worst-case Result

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

کنترل Temperature

برای وظایف قطعی مانند طبقه‌بندی، مقدار پایین‌تر معمولاً نوسان را کاهش می‌دهد. بااین‌حال رفتار پارامترها بین مدل‌ها یکسان نیست و برخی مدل‌ها آن‌ها را محدود می‌کنند.

در گزارش Eval باید تمام پارامترها ثبت شوند.

محاسبۀ هزینه در Eval

اطلاعات Usage:

function calculateCost({
  inputTokens,
  outputTokens,
  inputPricePerMillion,
  outputPricePerMillion,
}) {
  return (
    (inputTokens / 1_000_000) *
      inputPricePerMillion +
    (outputTokens / 1_000_000) *
      outputPricePerMillion
  );
}

برای مقایسۀ مدل‌ها:

هزینه کل Eval
هزینه هر Test Case
هزینه هر پاسخ صحیح
هزینه هر خروجی معتبر

هزینه هر پاسخ صحیح

const costPerCorrect =
  totalCorrect > 0
    ? totalCost / totalCorrect
    : Infinity;

این معیار از قیمت خام توکن کاربردی‌تر است.

تعریف Threshold انتشار

پیش از اجرای Eval، حداقل معیارها را مشخص کنید:

{
  "minimum_accuracy": 0.92,
  "minimum_schema_validity": 0.99,
  "maximum_p95_latency_ms": 3000,
  "maximum_cost_per_request_usd": 0.02,
  "maximum_error_rate": 0.01
}

مدل فقط زمانی منتشر شود که تمام معیارهای الزامی را پاس کند.

Eval در CI/CD

هر تغییر Prompt یا مدل می‌تواند Eval را اجرا کند:

Pull Request
→ Unit Tests
→ AI Evals
→ Compare Baseline
→ Pass or Block
→ Deploy

نباید برای هر Commit کل Dataset بزرگ اجرا شود. می‌توان چند سطح داشت:

Smoke Eval

تعداد کمی مورد حیاتی؛ سریع و کم‌هزینه.

Regression Eval

مجموعۀ متوسط برای Pull Request.

Full Eval

Dataset کامل به‌صورت زمان‌بندی‌شده یا پیش از انتشار مهم.

جلوگیری از انتشار مدل ضعیف‌تر

گزارش Candidate با Baseline مقایسه می‌شود:

Accuracy نباید بیش از ۱٪ کاهش یابد.
Schema Validity نباید کاهش یابد.
P95 Latency نباید بیش از ۲۰٪ افزایش یابد.
هزینه نباید از سقف عبور کند.

ممکن است افت کوچک میانگین قابل‌قبول باشد، اما افت در سناریوی امنیتی نباید پذیرفته شود.

وزن‌دهی Test Caseها

تمام نمونه‌ها اهمیت یکسان ندارند.

مثال:

پرسش عمومی: وزن ۱
خطای مالی: وزن ۳
درخواست امنیتی: وزن ۵
عملیات حذف داده: وزن ۱۰

فرمول:

Weighted Score =
Σ(Test Score × Weight)
÷ Σ(Weight)

موارد پرریسک باید Threshold مستقل نیز داشته باشند.

تحلیل خطا

پس از Eval فقط به امتیاز نهایی نگاه نکنید. خطاها را دسته‌بندی کنید:

• Prompt Failure
• Retrieval Failure
• Tool Selection Failure
• Parsing Failure
• Hallucination
• Context Overflow
• Language Failure
• Safety Failure
• Provider Error
• Timeout
• Schema Failure

سپس تعداد و شدت هر دسته را بررسی کنید.

Error Taxonomy

نمونه:

{
  "error_type": "schema_failure",
  "severity": "medium",
  "stage": "generation",
  "recoverable": true,
  "requires_retry": true
}

Taxonomy به تیم کمک می‌کند بداند اصلاح باید در Prompt، مدل، Validator یا Retrieval انجام شود.

داشبورد Eval

یک داشبورد مناسب می‌تواند این اطلاعات را نمایش دهد:

• مدل و نسخه
• Prompt Version
• Dataset Version
• امتیاز کلی
• امتیاز هر دسته
• هزینه
• P95 Latency
• Error Rate
• Schema Validity
• مقایسه با Baseline
• موارد شکست‌خورده
• روند تغییر کیفیت

اشتباهات رایج در Evals

استفاده از چند مثال ساده

Dataset باید نمایندۀ ترافیک واقعی باشد.

تنظیم Prompt روی Test Set

این کار باعث Overfitting می‌شود.

استفاده از یک معیار

کیفیت، هزینه، سرعت و پایداری باید هم‌زمان سنجیده شوند.

اعتماد کامل به مدل داور

نتایج داور باید با قواعد قطعی و نمونه انسانی کالیبره شوند.

نادیده گرفتن زبان فارسی

داده واقعی فارسی و متن ترکیبی باید در Dataset وجود داشته باشد.

ارزیابی فقط پاسخ نهایی Agent

مسیر Tool Call نیز باید بررسی شود.

مخلوط کردن Retrieval و Generation

این دو بخش در RAG باید جدا ارزیابی شوند.

نداشتن Versioning

بدون نسخه مدل، Prompt و Dataset، نتایج قابل‌بازتولید نیستند.

ثبت نکردن هزینه Retry

هزینه نهایی ممکن است بیشتر از یک فراخوانی باشد.

انتخاب مدل براساس میانگین

P95، P99 و سناریوهای پرریسک را بررسی کنید.

نداشتن Threshold

امتیاز بدون معیار انتشار به تصمیم عملی تبدیل نمی‌شود.

چک‌لیست طراحی Eval حرفه‌ای

• هدف سیستم مشخص شده است.
• تعریف پاسخ موفق نوشته شده است.
• Golden Dataset وجود دارد.
• داده‌های حساس ناشناس شده‌اند.
• نمونه‌های فارسی کافی هستند.
• موارد دشوار و مرزی پوشش داده شده‌اند.
• Development و Test Set جدا هستند.
• معیار قطعی در اولویت قرار دارد.
• Rubric برای پاسخ آزاد تعریف شده است.
• مدل داور کالیبره شده است.
• نمونه‌ای از نتایج انسانی بررسی می‌شود.
• کیفیت، هزینه و Latency ثبت می‌شوند.
• Retry و Fallback جدا ثبت می‌شوند.
• Model ID و Provider واقعی ذخیره می‌شوند.
• Prompt و Dataset نسخه‌بندی شده‌اند.
• Threshold انتشار تعریف شده است.
• Eval در CI/CD اجرا می‌شود.
• خطاهای محیط عملیاتی به دیتاسِت اضافه می‌شوند.
• Online Monitoring فعال است.
• Drift به‌صورت دوره‌ای بررسی می‌شود.

نقش درواره در ارزیابی مدل‌ها

درواره دسترسی به مدل‌های مختلف هوش مصنوعی را از طریق یک API یکپارچه فراهم می‌کند. این موضوع ساخت Eval چندمدلی را ساده‌تر می‌کند؛ زیرا می‌توان با یک ساختار درخواست و یک API Key، مدل‌های مختلف را روی Dataset یکسان آزمایش کرد.

Base URL درواره:

https://api.darvareh.ir/v1

فرایند پیشنهادی:

1. دیتاسِت واقعی خود را آماده کنید.
2. معیار موفقیت را تعریف کنید.
3. چند Model ID را از کاتالوگ درواره انتخاب کنید.
4. درخواست یکسان را برای مدل‌ها اجرا کنید.
5. مصرف، هزینه و تاخیر را ثبت کنید.
6. خروجی‌ها را با Evaluator بررسی کنید.
7. هزینه هر نتیجۀ موفق را محاسبه کنید.
8. مدل مناسب هر وظیفه را انتخاب کنید.
9. مدل منتخب را ابتدا به‌صورت Canary منتشر کنید.
10. کیفیت محیط عملیاتی را پیوسته مانیتور کنید.

اولین درخواست ارزیابی با cURL

curl "https://api.darvareh.ir/v1/chat/completions" \
  -H "Authorization: Bearer $DARVAREH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MODEL_ID",
    "messages": [
      {
        "role": "system",
        "content": "پیام را در یکی از دسته‌های billing، technical، account یا other قرار بده و فقط JSON برگردان."
      },
      {
        "role": "user",
        "content": "موجودی کیف پول من بعد از پرداخت افزایش پیدا نکرده است."
      }
    ]
  }'

همین Test Case را می‌توان با چند Model ID اجرا و نتایج را مقایسه کرد.

چه زمانی Eval را اجرا کنیم؟

• پیش از انتخاب مدل
• پیش از تغییر مدل
• پس از تغییر Prompt
• پس از تغییر RAG
• پس از تغییر Tool Schema
• پیش از انتشار
• پس از مشاهده خطای Production
• پس از انتشار نسخۀ جدید مدل
• به‌صورت روزانه یا هفتگی
• هنگام تغییر Provider
• پیش از فعال کردن Fallback
• هنگام تغییر قیمت مدل

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

Evals چیست؟

Evals مجموعه‌ای از آزمون‌های ساختاریافته و تکرارپذیر برای سنجش کیفیت، هزینه، سرعت و پایداری مدل یا سیستم هوش مصنوعی است.

Eval با سنجه چه تفاوتی دارد؟

Benchmark عمومی عملکرد مدل را روی یک Dataset استاندارد نشان می‌دهد. Eval اختصاصی، مدل را روی وظایف و داده‌های واقعی محصول شما ارزیابی می‌کند.

دیتاست طلایی چیست؟

مجموعه‌ای از نمونه‌های باکیفیت و بازبینی‌شده است که پاسخ صحیح یا معیار ارزیابی مشخص دارند.

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

عدد ثابتی وجود ندارد. بهتر است ابتدا با ۵۰ تا ۱۰۰ نمونۀ باکیفیت شروع کنید و با خطاهای Production آن را توسعه دهید. برای تصمیم‌های مهم، پوشش سناریوها از تعداد خام مهم‌تر است.

آیا می‌توان با ۱۰ نمونه مدل انتخاب کرد؟

برای آزمایش اولیه بله، اما برای تصمیم Production کافی نیست؛ مگر وظیفه بسیار محدود و قطعی باشد.

LLM-as-a-Judge چیست؟

استفاده از یک مدل زبانی برای امتیازدهی پاسخ مدل دیگر براساس Rubric مشخص است.

آیا می‌توان کاملاً به مدل داور اعتماد کرد؟

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

بهترین معیار ارزیابی چیست؟

به نوع وظیفه بستگی دارد. برای طبقه‌بندی F1، برای JSON اعتبار Schema، برای RAG معیارهای Retrieval و Groundedness و برای Agent نرخ تکمیل وظیفه و موفقیت Tool Call مهم‌اند.

چگونه توهم را اندازه‌گیری کنیم؟

ادعاهای پاسخ را با منابع معتبر یا Context مقایسه کنید و نسبت ادعاهای بدون پشتوانه را محاسبه کنید. در RAG می‌توان Groundedness و Citation Correctness را سنجید.

آیا مدل گران‌تر همیشه کیفیت بیشتری دارد؟

خیر. کیفیت به وظیفه، زبان، Prompt و داده بستگی دارد. مدل اقتصادی ممکن است در یک وظیفۀ محدود عملکرد بهتری داشته باشد.

هزینه هر نتیجۀ موفق چیست؟

کل هزینه مدل‌ها تقسیم بر تعداد خروجی‌های صحیح و قابل‌استفاده است. این معیار از قیمت خام توکن کاربردی‌تر است.

آیا RAG و مدل باید با هم ارزیابی شوند؟

بله، اما Retrieval و Generation باید ابتدا جدا و سپس به‌صورت End-to-End بررسی شوند.

چگونه عامل را ارزیابی کنیم؟

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

آیا Eval باید در CI/CD اجرا شود؟

بله. مجموعه‌ای کوچک برای Pull Request و Eval کامل‌تر پیش از انتشار یا به‌صورت زمان‌بندی‌شده مناسب است.

آیا اجرای Eval هزینه دارد؟

بله. هر فراخوانی مدل، داور و ابزار می‌تواند هزینه داشته باشد. Dataset بزرگ باید با Concurrency و بودجۀ مشخص اجرا شود.

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

یک Dataset و Prompt ثابت تعریف کنید، Model ID را در هر اجرا تغییر دهید و کیفیت، Usage، هزینه و Latency مدل‌ها را با یک Evaluator یکسان مقایسه کنید.

Base URL درواره چیست؟

https://api.darvareh.ir/v1

جمع‌بندی

Evals حلقۀ اتصال میان «آزمایش یک مدل» و «ساخت محصول قابل‌اعتماد» است.

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

یک فرایند ارزیابی حرفه‌ای شامل مراحل زیر است:

تعریف موفقیت
→ ساخت Dataset
→ انتخاب معیار
→ اجرای مدل‌ها
→ امتیازدهی
→ تحلیل خطا
→ مقایسۀ کیفیت، هزینه و سرعت
→ انتشار تدریجی
→ مانیتورینگ Production

برای وظایف قطعی از Evaluatorهای قطعی مانند Schema Validation، Unit Test و Exact Match استفاده کنید. برای پاسخ‌های آزاد، Rubric، ارزیابی انسانی و LLM-as-a-Judge را به‌صورت ترکیبی به کار ببرید.

RAG، ایجنت، Tool Calling، روترو فال‌بک را فقط براساس پاسخ نهایی ارزیابی نکنید؛ مسیر پردازش و عملکرد هر جزء باید جداگانه اندازه‌گیری شود.

درواره با فراهم کردن دسترسی به مدل‌های مختلف از طریق یک API سازگار با OpenAI، اجرای آزمون‌های چندمدلی را ساده‌تر می‌کند. کافی است مدل‌های موردنظر را انتخاب و آن‌ها را روی Dataset واقعی خود مقایسه کنید:

https://api.darvareh.ir/v1

بهترین مدل، مدلی نیست که بالاترین رتبۀ عمومی را دارد؛ بهترین مدل، مدلی است که روی داده‌های واقعی محصول شما با هزینه و سرعت قابل‌قبول، بیشترین نتیجۀ موفق را تولید می‌کند.

مقالات مرتبط پیشنهادی

• معماری چندمدلی هوش مصنوعی چیست؟
• بهترین API هوش مصنوعی برای سایت و اپلیکیشن
• AI Gateway چیست و چه تفاوتی با API Gateway دارد؟
• Auto Router چیست و چگونه مدل مناسب را انتخاب می‌کند؟
• Structured Output چیست؟
• Function Calling و Tool Calling چیست؟
• RAG چیست و چگونه کیفیت آن را ارزیابی کنیم؟
• Prompt Engineering چیست؟
• API سازگار با OpenAI چیست؟
• درواره چیست؟ معرفی پلتفرم API هوش مصنوعی برای ایران