چگونه برای قابلیتهای AI دیتاست، معیار، Rubric و آستانه انتشار بسازیم؟ راهنمای عملی طراحی Eval از تعریف موفقیت تا پایش تولید.
طراحی Eval برای محصولات هوش مصنوعی یعنی تبدیل تعریف مبهم «پاسخ خوب» به مجموعهای تکرارپذیر از سناریوها، معیارها و قواعد تصمیم. در نرمافزار قطعی معمولاً یک ورودی مشخص، خروجی مورد انتظار واحد دارد؛ اما مدل مولد ممکن است برای یک درخواست چند پاسخ متفاوت و در عین حال قابلقبول بسازد. بنابراین بررسی اینکه API خطای ۵۰۰ نمیدهد یا JSON معتبر است، کیفیت محصول را تضمین نمیکند.
Eval یک آزمون واحد نیست؛ یک سیستم اندازهگیری است. باید نشان دهد قابلیت AI در کار واقعی کاربر چقدر موفق است، کجا شکست میخورد، تغییر مدل یا پرامپت چه چیزی را بهتر یا بدتر کرده و آیا کیفیت برای انتشار کافی است. راهنمای رسمی OpenAI درباره Evals نیز ارزیابی را سنجش خروجی مدل در برابر معیارهای سبک و محتوای تعریفشده میداند و آن را برای مقایسه مدل یا ارتقا ضروری معرفی میکند.
این راهنما تا ۹ سپتامبر ۲۰۲۶ بازبینی شده است. اگر هنوز نوع راهحل را انتخاب نکردهاید، ابتدا مقایسه AI Agent، چتبات و Automation را بخوانید؛ چون شکل Eval باید با میزان اختیار سیستم هماهنگ باشد.
اشتباه رایج این است که تیم ابتدا چندصد سؤال جمع میکند و بعد دنبال متریک میگردد. مسیر بهتر از یک Decision Statement شروع میشود:
«میخواهیم تصمیم بگیریم آیا دستیار پشتیبانی میتواند پاسخگویی به سؤالهای سطح یک را برای ۲۰ درصد کاربران فعال کند، بدون اینکه پاسخ پرریسک یا هزینه هر مکالمه از حد توافقشده بیشتر شود.»
این جمله کاربر و سناریو، Outcome، دامنه انتشار و محدودیت را روشن میکند. سپس تعریف موفقیت را در چند بعد بنویسید:
این ابعاد گاهی با هم تعارض دارند. پاسخ طولانی شاید پوشش بیشتری بدهد اما زمان، هزینه و رضایت را بدتر کند. کار مدیر محصول حذف این تعارض نیست؛ تعیین وزن و حداقل قابلقبول هر بعد است.
ابتدا مشخص کنید دقیقاً چه چیزی را میسنجید. برای استخراج داده، واحد Eval میتواند یک سند و JSON خروجی باشد. برای چتبات، یک مکالمه چندمرحلهای و برای ایجنت، کل مسیر شامل فراخوانی ابزار، تغییر وضعیت و Outcome نهایی است.
در ایجنتها فقط متن آخر را نمره ندهید. ممکن است ایجنت بگوید «رزرو انجام شد» اما هیچ رکوردی ساخته نشده باشد؛ یا نتیجه درست را با دسترسی غیرمجاز به دست آورده باشد. مقاله فنی Anthropic درباره Eval ایجنتها میان Task، Trial، Grader، Transcript و Outcome تفاوت میگذارد و توصیه میکند مسیر و وضعیت نهایی را با هم بسنجیم.
برای هر واحد ارزیابی این قرارداد را ثبت کنید: ورودی، زمینه، ابزارهای مجاز، نتیجه مطلوب، رفتار ممنوع و شرایط توقف.
یک Eval خوب از فهرست قابلیتها ساخته نمیشود؛ از شیوههای شکست ساخته میشود. ۳۰ تا ۵۰ نمونه از لاگهای مجاز، تست دستی، تیکت پشتیبانی یا تحقیق کاربر را مرور کنید و خطاها را دستهبندی کنید. برای دستیار پشتیبانی ممکن است Taxonomy چنین باشد:
برای هر دسته تعریف ورود، ضدمثال و شدت پیامد بنویسید. تیمی که فقط «دقت کلی» را میبیند ممکن است به امتیاز ۹۲ درصد افتخار کند، در حالی که هشت درصد باقیمانده شامل افشای داده یا اقدام مالی اشتباه است. برای پیدا کردن شکستهای کیفی در داده واقعی، فرایند تحلیل مصاحبه کاربر با هوش مصنوعی الگویی مفید برای حفظ شواهد است.
دیتاست را به سه لایه تقسیم کنید:
۱. نمونههای رایج: پرتکرارترین کارهایی که کاربران واقعاً انجام میدهند. ۲. نمونههای مرزی: ورودی ناقص، غلط املایی، چندزبانه، درخواست مبهم، متن طولانی و تضاد دستورها. ۳. نمونههای پرریسک: داده حساس، اقدام برگشتناپذیر، Prompt Injection، جعل منبع یا درخواست خارج از سیاست.
هر ردیف حداقل باید شناسه پایدار، بخش کاربری، ورودی، زمینه مجاز، انتظار، رفتارهای ممنوع، شدت ریسک و منشأ نمونه داشته باشد. نمونهها را میان Development Set و Holdout Set جدا کنید؛ اگر تیم دائماً روی همه سؤالها پرامپت را تنظیم کند، امتیاز بالا فقط حفظکردن آزمون را نشان میدهد.
داده مصنوعی برای گسترش پوشش مفید است، اما نباید جای توزیع واقعی را بگیرد. از AI بخواهید بر پایه هر شکست معتبر، تغییرهای کنترلشده بسازد؛ سپس انسان شباهت و واقعگرایی آنها را بازبینی کند. اطلاعات شخصی را حذف و دسترسی به Transcriptها را محدود کنید.
سه خانواده Grader را ترکیب کنید:
برای قالب، Schema، وجود Citation، محدوده عدد، فراخوانی ابزار مجاز یا ثبت رکورد از کد استفاده کنید. این Grader سریع، ارزان و تکرارپذیر است. هرجا پاسخ را میتوان با قانون روشن سنجید، قضاوت مدل را وارد نکنید.
برای ارتباط، انسجام، رعایت لحن یا کیفیت خلاصه از LLM-as-a-Judge استفاده کنید. Rubric باید هر سطح را با رفتار قابلمشاهده تعریف کند. مثلاً امتیاز ۳ برای «همه ادعاهای اصلی به منبع پشتیبان وصلاند»، امتیاز ۲ برای «یک ادعای فرعی بیمنبع» و امتیاز ۱ برای «ادعای اصلی بیپشتوانه»؛ نه واژههای مبهمی مثل عالی و متوسط.
برای پیامد پرریسک، ترجیح ظریف، تجربه احساسی و کالیبرهکردن داور مدل از متخصص انسانی استفاده کنید. داور مدل هم خطا و سوگیری دارد. مستندات Google Cloud درباره ارزیابی Judge Model مقایسه امتیاز مدل با رتبه انسانی و استفاده از معیارهایی مانند Balanced Accuracy، F1 و Confusion Matrix را توضیح میدهد.
اگر دو ارزیاب انسانی روی تعریف «پاسخ خوب» توافق ندارند، خودکارسازی اختلاف را حل نمیکند. ابتدا Rubric را با نمونههای Anchor روشن کنید و میزان توافق را بسنجید.
پیش از هر بهبود، نسخه فعلی محصول را روی Suite اجرا و Baseline ثبت کنید. سپس سه نوع آستانه بگذارید:
میانگین بهتنهایی کافی نیست. نتیجه را براساس Segment، زبان، نوع دستگاه، شدت ریسک و نوع سناریو بشکنید. نرخ عبور را کنار فاصله اطمینان، تعداد نمونه و تعداد Trial نشان دهید؛ چون خروجی مدل تصادفی است و یک اجرای موفق نماینده پایداری نیست.
Latency و هزینه را هم وارد Scorecard کنید. بهترین مدل از نظر کیفیت ممکن است برای جریان پرترافیک یا پاسخ بلادرنگ انتخاب خوبی نباشد. دوره دادهمحوری برای مدیران محصول برای طراحی متریک، Segment و خواندن درست تغییرها کمککننده است.
وقتی مدل، پرامپت، Retrieval و Toolها همزمان عوض شوند، علت تغییر امتیاز نامشخص میماند. هر بار یک متغیر اصلی را تغییر دهید و Candidate را در برابر Baseline ثابت بسنجید. در خروجیهای باز، ارزیابی Pairwise معمولاً از امتیازدهی مطلق پایدارتر است: داور فقط میسنجد کدام پاسخ با Rubric سازگارتر است.
برای کاهش سوگیری ترتیب، جای Candidate و Baseline را تصادفی کنید و نام مدل را به داور نشان ندهید. موارد اختلاف میان Graderها را به صف بازبینی بفرستید؛ همین اختلافها معمولاً بهترین منبع برای اصلاح Rubric هستند.
Eval یک گزارش فصلی نیست. Suite کوچک Regression باید با هر تغییر مهم پرامپت، مدل، داده بازیابی یا ابزار اجرا شود. Suite کاملتر میتواند شبانه یا پیش از Release اجرا شود. نتیجه باید شامل نسخه مدل و پرامپت، تاریخ، Dataset، تنظیمات، امتیاز هر Segment، شکستهای تازه و تصمیم انتشار باشد.
پس از انتشار، پایش تولید جای Eval آفلاین را نمیگیرد؛ آن را تغذیه میکند. نمونههای جدید و رضایتدار را مرور، شکستهای تکرارشونده را به Taxonomy اضافه و پس از ناشناسسازی به Regression Set منتقل کنید. چرخه Analyze، Measure و Improve مرور کیفی خطا را به سنجش و بهبود هدفمند تبدیل میکند.
برای تشخیص آمادگی تیم برای مالکیت چنین چرخهای، خودارزیابی مدیریت محصول و چابکی نقطه شروع خوبی است.
فرض کنید دستیار باید وضعیت سفارش را توضیح دهد، سیاست مرجوعی را از پایگاه دانش پیدا کند و درخواست حساس را به اپراتور بسپارد. تیم ۱۲۰ Task میسازد: ۶۰ سناریوی رایج، ۳۵ مرزی و ۲۵ پرریسک.
Grader قطعی بررسی میکند شناسه سفارش متعلق به همان کاربر است، Citation معتبر وجود دارد و هیچ ابزار نوشتنی بدون Approval فراخوانی نشده. داور مدل با Rubric سهسطحی ارتباط و وضوح را میسنجد. متخصص پشتیبانی هر هفته ۲۰ نمونه اختلافی و تمام شکستهای پرریسک را بازبینی میکند.
آستانه انتشار چنین است: موفقیت وظیفه بالای ۸۸ درصد، پوشش منبع بالای ۹۵ درصد، P95 Latency زیر چهار ثانیه و صفر افشای اطلاعات در Suite پرریسک. نسخه جدید امتیاز کلی را از ۸۷ به ۹۱ میرساند، اما در درخواستهای فارسی محاورهای پنج درصد پسرفت دارد. تصمیم حرفهای «انتشار کامل» نیست؛ ابتدا بهبود همان Segment یا Rollout محدود همراه با Kill Switch است.
پروفایل ریسک هوش مصنوعی مولد NIST نیز بر ارزیابی و مدیریت ریسک متناسب با هدف، زمینه و تحمل ریسک سازمان در سراسر چرخه عمر تأکید میکند. یعنی یک Suite ثابت برای همیشه کافی نیست؛ محصول، کاربران و شیوههای سوءاستفاده تغییر میکنند.
طراحی Eval با خرید ابزار شروع نمیشود؛ با تعریف تصمیم و شکست غیرقابلقبول شروع میشود. واحد ارزیابی را انتخاب کنید، از داده واقعی Taxonomy بسازید، سناریوهای رایج و پرریسک را جدا پوشش دهید، Graderهای قطعی و انسانی و مدلمحور را ترکیب کنید و آستانه انتشار را پیش از دیدن نتیجه بنویسید.
Eval خوب به تیم نمیگوید محصول «باهوش» است؛ نشان میدهد برای کدام کاربر، در کدام شرایط و با چه ریسکی قابلاعتماد است. اگر میخواهید اولین Scorecard و Pilot را برای محصول خود طراحی کنید، منتورینگ و مشاوره مدیریت محصول میتواند این فرایند را به تصمیم انتشار واقعی وصل کند.
