دیتاست ارزیابی LLM

مجموعه‌دادهٔ ارزیابی (eval dataset) برای قابلیت‌های LLM همان نقشی را دارد که مجموعه تست برای کد: بدون آن «بهتر شد» فقط یک احساس است. اما ساختن آن خطاهای مخصوص خودش دارد: نمونه‌ها شبیه کاربر واقعی نیستند، داده محرمانه به دیتاست درز می‌کند، برچسب‌ها سلیقه‌ای‌اند و کسی نمی‌داند کدام نسخه را اجرا کرده است. این مقاله روش ساخت یک دیتاست کوچک ولی قابل‌اعتماد را گام‌به‌گام شرح می‌دهد.

مرجع: راهنمای «Evaluation best practices» در OpenAI و «Define success criteria and build evaluations» در Anthropic، هر دو خوانده‌شده در ۱۹ اکتبر ۲۰۲۶. صفحهٔ OpenAI اعلام می‌کند پلتفرم Evals آن شرکت از ۳۱ اکتبر ۲۰۲۶ فقط‌خواندنی و از ۳۰ نوامبر ۲۰۲۶ خاموش می‌شود؛ بنابراین ما به ابزار خاصی وابسته نمی‌شویم و فقط اصول را می‌گیریم. اندازهٔ دیتاست، قالب فایل و فرایند نسخه‌بندی که می‌آید توصیهٔ نویسنده است. مقررات داده شخصی ایران را بررسی نکرده‌ایم. برای تعریف نیاز پیش از ساخت user story را ببینید.

گام ۱: هدف و معیار

OpenAI مراحل را این‌طور می‌چیند: هدف، دیتاست، متریک، اجرا و مقایسه، و ارزیابی پیوسته. Anthropic هم می‌گوید معیار موفقیت باید مشخص، قابل‌اندازه‌گیری، دست‌یافتنی و مرتبط باشد؛ «مدل باید خوب دسته‌بندی کند» بد است و «حداقل امتیاز مشخص روی مجموعهٔ نگه‌داشته‌شده» خوب است. بیشتر کاربردها چندبعدی‌اند: دقت وظیفه، سازگاری، حفظ حریم خصوصی، تأخیر و هزینه. پیش از جمع‌آوری نمونه، برای هر بعد بنویسید «شکست یعنی چه». مثلاً برای دستیار پشتیبانی: «پاسخ نباید مبلغ یا مهلتی بگوید که در سند نیست».

گام ۲: از کجا نمونه بیاوریم؟

OpenAI منابع ممکن را می‌شمارد: داده تولید (بازخورد کاربران)، داده تاریخی و لاگ‌ها، داده ساخته‌شدهٔ متخصص، داده مصنوعی و داده خریداری‌شده. همین‌جا یک ضدالگو مطرح است: دیتاستی که الگوی ترافیک واقعی را بازتولید نمی‌کند. پیشنهاد (نویسنده):

• هستهٔ دیتاست را از پرسش‌های واقعی (لاگ پشتیبانی، جست‌وجوی سایت) بسازید، نه از پرسش‌هایی که تیم می‌نویسد.
• برای شروع، چند ده نمونه متنوع کافی است؛ Anthropic می‌گوید حجم بیشتر با سیگنال کمی ضعیف‌تر بر موارد کم و دستی مزیت دارد، پس تدریجی گسترش دهید.
• داده مصنوعی (ساخته‌شده با مدل) را فقط برای پوشش موارد نادر به‌کار ببرید و جدا برچسب بزنید؛ OpenAI هم می‌گوید مدل می‌تواند در جمع‌آوری موارد و حالت‌های مرزی کمک کند، اما برچسب را متخصص انسانی باید تأیید کند.

گام ۳: نمایندگی و موارد مرزی

هر دو منبع بر موارد مرزی تأکید دارند. OpenAI می‌گوید دادهٔ آزمون باید موارد معمول، مرزی و خصمانه داشته باشد؛ Anthropic نمونه‌هایی می‌دهد: ورودی نامرتبط یا ناموجود، ورودی بسیار بلند، ورودی مضر و موارد مبهمی که حتی انسان‌ها دربارهٔ آن توافق ندارند. جدول پوشش (قالب پیشنهادی):

نسبت گروه‌ها را با نسبت واقعی ترافیک مقایسه کنید (OpenAI «biased design» را ضدالگو می‌نامد) و گروه‌های ریسک‌دار را عمداً بیشتر نمایندگی دهید تا خطاها دیده شوند، اما در گزارش بین «وزن ترافیک» و «پوشش ریسک» تفاوت بگذارید (توصیهٔ نویسنده).

گام ۴: مجاز بودن و محرمانگی

لاگ واقعی کاربران ممکن است نام، شماره تماس، سفارش و شکایت شخصی داشته باشد. پیش از ورود به دیتاست (توصیهٔ نویسنده، نه نقل از منابع):

1. بررسی کنید جمع‌آوری و استفادهٔ ثانویه از آن داده مجاز است یا نه؛ ما قوانین ایران را بررسی نکرده‌ایم و باید از مشاور حقوقی بپرسید.
2. شناسه‌های مستقیم را حذف یا جایگزین کنید (نام، تلفن، ایمیل، شماره سفارش) و بعد از ناشناس‌سازی دوباره مرور انسانی کنید.
3. اگر دیتاست را برای ارزیابی روی API ارائه‌دهنده می‌فرستید، سیاست نگه‌داری و آموزش آن ارائه‌دهنده را بخوانید.
4. دسترسی به دیتاست را مثل داده تولید محدود کنید و مدت نگه‌داری تعیین کنید.
5. اسرار (کلید API، رمز) هرگز در نمونه‌ها نماند؛ نمونه‌های ساختگی بسازید.

گام ۵: برچسب‌گذاری

OpenAI توصیه می‌کند از برچسب‌زن‌های متخصص انسانی استفاده شود و امتیاز خودکار با قضاوت انسان هم‌راستا شود. Anthropic برای مواردی که پاسخ مشخص دارند خودکارسازی (تطبیق دقیق، کد، LLM) را پیشنهاد می‌کند. عملی (نویسنده):

• برای هر نمونه «پاسخ مرجع» یا «ویژگی‌های لازم و ممنوع» بنویسید (مثلاً باید مهلت ۷ روز را بگوید و نباید هزینهٔ ارسال را حدس بزند).
• دو برچسب‌زن مستقل روی بخشی از نمونه‌ها بگذارید و اختلاف را بررسی کنید؛ Anthropic نمونه‌های مبهم را مطرح می‌کند که «حتی انسان‌ها توافق ندارند»، این موارد را علامت‌گذاری کنید.
• راهنمای برچسب‌گذاری یک‌صفحه‌ای بنویسید تا معیارها ثابت بماند.

گام ۶: نسخه‌بندی و استفاده

دیتاست را مثل کد نسخه‌بندی کنید (توصیهٔ نویسنده): هر نمونه یک شناسه، گروه، منبع (واقعی/مصنوعی)، تاریخ افزودن، نسخهٔ راهنمای برچسب و وضعیت (فعال/بازنشسته) دارد. هر اجرای ارزیابی باید نسخهٔ دیتاست، نسخهٔ prompt و مدل و تاریخ را ثبت کند. OpenAI «ارزیابی پیوسته» را توصیه می‌کند: اجرای eval در هر تغییر و رشد دیتاست با موارد تازه. مواردی که در تولید شکست می‌خورند را (پس از ناشناس‌سازی) به دیتاست اضافه کنید. یک زیرمجموعهٔ «نگه‌داشته‌شده» (held-out) نگه دارید که برای تنظیم prompt استفاده نشود تا overfit نشوید؛ Anthropic هم از مجموعهٔ نگه‌داشته‌شده در مثال معیارها یاد می‌کند.

{"id":"eval-0042","group":"edge","source":"production-anonymized",
 "input":"کالا را باز کردم و ۱۰ روز گذشته",
 "must_include":["۷ روز"],"must_not_include":["هزینهٔ ارسال برگشتی"],
 "label_guide":"v3","added":"2026-10","status":"active"}

نمونهٔ بالا ساختگی است.

اولین اجرا و گزارش

پس از ساخت نسخهٔ ۱ دیتاست، یک اجرای پایه بگیرید و نتیجه را به‌جای یک عدد کلی، به تفکیک گروه گزارش کنید. فرض کنید ۶۰ نمونه دارید: ۳۰ معمول، ۱۰ مرزی، ۸ بی‌ربط، ۴ طولانی، ۴ خصمانه و ۴ مبهم (اعداد فرضی). گزارش نمونه باید بگوید در هر گروه چند مورد گذشت و کدام موارد شکست خورد، نه فقط «۸۲٪ دقت». گروه کوچک مثل خصمانه با چهار مورد آماری معنی‌دار نیست و فقط به‌عنوان آزمون «دود» (smoke test) خوانده می‌شود: اگر یکی از آن‌ها شکست بخورد، بررسی دستی لازم است حتی اگر درصد کلی بالا باشد. دو نکتهٔ عملی: اجرا را چند بار تکرار کنید تا بدانید تغییرپذیری خروجی چقدر است (OpenAI تغییرپذیری را دلیل نیاز به eval می‌داند)، و تغییرهای کوچک prompt را با همان دیتاست و همان نسخهٔ مدل مقایسه کنید تا اثر هر تغییر جدا دیده شود. هر زمان مدل یا ارائه‌دهنده عوض شد، همین اجرا را تکرار کنید و نتیجه را کنار اجرای قبلی بگذارید؛ این همان «ارزیابی پیوسته»ای است که OpenAI توصیه می‌کند.

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

• ساختن دیتاست فقط از نمونه‌های «تمیز» نوشته‌شدهٔ تیم.
• ورود داده شخصی یا اسرار به دیتاست.
• نداشتن مورد بی‌ربط، مرزی و خصمانه.
• برچسب سلیقه‌ای بدون راهنما.
• استفاده از همهٔ نمونه‌ها برای تنظیم و سنجش.
• تغییر دیتاست بی‌ثبت نسخه و ناتوانی در مقایسهٔ اجراها.
• وابستگی به یک ابزار ارزیابی که ممکن است از دسترس برود (مثال Evals در OpenAI).

چک‌لیست

1. معیار موفقیت چندبعدی و قابل‌اندازه‌گیری نوشته شده است.
2. هستهٔ دیتاست از پرسش‌های واقعی آمده است.
3. گروه‌های معمول، مرزی، بی‌ربط، طولانی، خصمانه و مبهم پوشش دارند.
4. مجاز بودن و ناشناس‌سازی بررسی و مستند شده است.
5. برچسب‌ها با راهنما و دست‌کم نمونه‌ای از دو برچسب‌زن کنترل می‌شود.
6. دیتاست نسخه دارد و بخشی نگه‌داشته‌شده است.
7. هر اجرا با نسخهٔ دیتاست، prompt و مدل ثبت می‌شود.
8. شکست‌های تولید به دیتاست برمی‌گردند.

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

منابع و مراجع

• Evaluation best practices — OpenAI API Docs، 2026-10-19.
• Define success criteria and build evaluations — Anthropic (Claude Platform Docs)، 2026-10-19.