دادهٔ خوب برای ارزیابی AI از کجا می‌آید؟

یک ردیف خوب eval چه اجزایی دارد؟

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

این فیلدها dataset را کمی اداری‌تر می‌کنند، اما بعدها کمک می‌کنند بفهمیم score چرا تغییر کرده است. یک عدد ۸۰ درصدی بدون دانستن ترکیب نمونه‌ها ممکن است از یک عدد ۷۰ درصدی روی دادهٔ متنوع‌تر کم‌ارزش‌تر باشد.

• شناسه و منبع: این نمونه از کدام سناریو، log، تیکت، مصاحبه یا طراحی تست آمده است؟
• ورودی و context مجاز: مدل دقیقاً چه چیزی را می‌بیند؟ چه داده‌ای عمداً حذف شده است؟
• انتظار یا reference: پاسخ درست، action مجاز، برچسب یا ویژگی قابل‌قبول چیست؟
• معیار: با string check، schema، rubric، similarity یا قضاوت متخصص چه چیزی سنجیده می‌شود؟
• ریسک و دامنه: پرتکرار، پرریسک، مرزی، خارج از دامنه یا adversarial؟
• برچسب و توضیح: چه کسی و چه زمانی آن را بررسی کرده و اختلاف نظر چه بوده است؟
• نسخه و provenance: مربوط به کدام workflow، prompt، model و policy است؟

منابع واقعی: از تعامل تا failure case

تعامل‌های واقعیِ مجاز: لاگ گفت‌وگو، تیکت پشتیبانی، درخواست جست‌وجو یا خروجی workflow می‌تواند بهترین تصویر از زبان و نیاز واقعی کاربر باشد؛ البته فقط با مبنای قانونی و فرایند مجاز برای جمع‌آوری، حذف PII، کنترل دسترسی و نگهداری. دادهٔ واقعی را خام وارد dataset نکنید؛ آن را کمینه، ناشناس، طبقه‌بندی و با محدودیت استفاده ثبت کنید.

نمونهٔ واقعی الزاماً answer آماده ندارد. گاهی ارزش آن در نشان‌دادن ابهام، context ناقص یا مسیر منتهی به escalation است. برای چنین ردیفی می‌توان به‌جای یک پاسخ مرجع، «رفتار قابل‌قبول» تعریف کرد: سؤال روشن‌کننده، نپاسخ‌دادن، انتقال به انسان یا عدم اجرای action.

خطاها، اعتراض‌ها و اصلاح‌های انسانی: هرجایی که کاربر گفت «این جواب اشتباه است»، کارشناس متن را بازنویسی کرد یا سیستم مجبور به retry و fallback شد، یک منبع ارزشمند برای eval داریم. این نمونه‌ها را فقط به‌عنوان شکست ذخیره نکنید؛ علت شکست را هم دسته‌بندی کنید: نبود context، منبع قدیمی، instruction مبهم، خطای tool، مجوز، لحن، hallucination یا انتظار غیرواقعی.

خطاهای پرتکرار برای regression مفیدند، اما خطاهای نادر و پرپیامد را هم جدا نگه دارید. اگر یک ردیف باعث افشای داده یا action اشتباه شده، نباید در میان نمونه‌های عادی گم شود.

نظر متخصص و توافق بر سر reference: در پاسخ‌های باز، همیشه یک «جواب واحد» وجود ندارد. متخصص حوزه باید مشخص کند چه چیزی حداقل قابل‌قبول است، کدام omission خطرناک است و کدام تفاوت در لحن قابل‌پذیرش است. اگر دو متخصص اختلاف دارند، اختلاف را پنهان نکنید؛ آن را به rubric یا برچسب ambiguity تبدیل کنید.

مستندات رسمی OpenAI annotation متخصص را راهی برای واردکردن دانش حوزه معرفی می‌کند. این کار فقط برای نمره‌دادن نیست؛ به تیم کمک می‌کند بفهمد معیار موفقیت دقیقاً چیست و grader چه چیزی را باید تشخیص دهد.

دادهٔ synthetic کجا کمک می‌کند؟

دادهٔ مصنوعی برای ساخت variation سریع، پوشش‌دادن ترکیب‌های نادر و تولید نمونهٔ اولیه مفید است. مثلاً می‌توان از یک سناریوی واقعیِ ناشناس‌شده، شکل‌های مختلف لحن، زبان، typo، ترتیب اطلاعات و context ناقص ساخت. اما synthetic data معمولاً از الگوهای فرضی تولیدکننده می‌آید؛ ممکن است همهٔ کاربران را منظم‌تر، مسئله‌ها را واضح‌تر و خطاها را قابل‌پیش‌بینی‌تر نشان دهد.

سه قاعدهٔ عملی داشته باشید:

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

• synthetic را با برچسب منبع جدا نگه دارید و با دادهٔ واقعی قاطی نکنید.
• بخشی از دادهٔ واقعیِ مجاز را به‌عنوان anchor برای بررسی realism و score نگه دارید.
• نمونه‌های مصنوعی را با متخصص یا reviewer حوزه بازبینی کنید، به‌خصوص در سناریوهای پرریسک.

پوشش مهم‌تر از تعداد خام است

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

هدف پوشش همهٔ ترکیب‌های ممکن نیست. هدف این است که بدانید کدام قسمت‌ها دیده شده، کدام blind spot است و کدام ناحیه به‌دلیل هزینه یا ریسک باید زودتر بررسی شود. یک جدول کوچک با ستون «پوشش، اهمیت و آخرین review» از تعداد بزرگ اما بی‌ساختار بهتر است.

• سناریوی پرتکرار و مسیرهای کم‌تکرار
• زبان، لحن، طول و کیفیت context
• کاربر تازه‌وارد در برابر کاربر حرفه‌ای
• خروجی کم‌خطر، پرریسک و خارج از دامنه
• دادهٔ کامل، ناقص، متناقض و قدیمی
• موفقیت مستقیم، نیاز به سؤال، fallback و escalation
• نسخهٔ مدل، prompt، ابزار و policy

train، eval و production را قاطی نکنیم

اگر همان نمونه‌ای را که برای طراحی prompt یا تنظیم workflow دیده‌اید، برای گزارش نهایی هم استفاده کنید، score می‌تواند بیش‌ازحد خوش‌بینانه شود. dataset توسعه، dataset ارزیابی ثابت و نمونه‌های پس از launch را از نظر نقش جدا کنید.

این جداسازی به معنی پنهان‌کردن خطا نیست. تیم باید از failure case یاد بگیرد، اما معیار مقایسه نباید هر بار با حذف نمونهٔ سخت آسان‌تر شود. اگر dataset ثابت تغییر کرد، دلیل، owner و اثر آن روی trend score را ثبت کنید.

• توسعه: برای کشف و اصلاح سریع، با دسترسی گسترده‌تر به failure case.
• ارزیابی ثابت: برای مقایسهٔ نسخه‌ها؛ تغییرهای بی‌دلیل آن باید ثبت شود.
• پس از launch: برای کشف رفتار جدید و افزودن edge case پس از review.

از score به تصمیم برسیم

Eval وقتی ارزش دارد که به یک تصمیم وصل شود. پیش از اجرای آن مشخص کنید score چه کاری را فعال می‌کند:

به یک میانگین کلی اکتفا نکنید. score را به تفکیک سناریو، شدت ریسک، source، model و version ببینید. اگر میانگین بهتر شده اما خطای پرریسک بدتر شده، release موفق نیست. اگر score ثابت است ولی پوشش dataset بهتر شده، شاید سنجش واقعی‌تر شده باشد نه این‌که محصول بدتر شده باشد.

• ادامهٔ rollout یا توقف آن
• انتخاب model یا prompt
• تغییر سطح human review
• افزودن validator یا fallback
• اصلاح source data یا policy
• آموزش تیم و بازنویسی تجربهٔ کاربر

اثر AI بر کیفیت نرم‌افزار و مدیریت پروژه

AI جمع‌آوری نمونه، حذف دادهٔ حساس، تولید variation، دسته‌بندی failure و حتی draft کردن reference را سریع‌تر می‌کند. این نقش بیشتر augmentation است. اما همان سرعت می‌تواند dataset پرحجم و کم‌اعتبار تولید کند؛ بنابراین مالکیت معیار، مجوز داده، severity و تصمیم release انسانی می‌ماند.

در Agile، دادهٔ eval باید کنار feature به backlog بیاید:

این کار معنی Definition of Done را هم عوض می‌کند. «مدل پاسخ می‌دهد» کافی نیست؛ باید بدانیم روی کدام داده، با چه معیار و چه محدودیتی پاسخ می‌دهد و در failure چه اتفاقی می‌افتد.

• در discovery: معیار موفقیت و سناریوهای شکست را پیش از ساخت مشخص کنید.
• در planning: زمان جمع‌آوری، annotation و اختلاف‌زدایی را estimate کنید.
• در delivery: خروجی feature با dataset ثابت و edge caseهای تازه سنجیده شود.
• در review: فقط demo را نشان ندهید؛ پوشش، failure و score تفکیک‌شده را مرور کنید.
• در retrospective: خطاهای تازه را به dataset، policy، prompt یا طراحی workflow برگردانید.

چک‌لیست ساخت اولین dataset

• outcome و معیار موفقیت را در یک جمله بنویسید.
• schema ردیف، منبع، مجوز، ریسک و نسخه را تعریف کنید.
• چند سناریوی پرتکرار واقعی و مجاز جمع کنید.
• failure case، اعتراض کاربر و اصلاح انسانی را اضافه کنید.
• نمونه‌های مرزی، خارج از دامنه و adversarial طراحی کنید.
• reference یا rubric را با متخصص حوزه بازبینی کنید.
• دادهٔ synthetic را جدا برچسب بزنید و با anchor واقعی مقایسه کنید.
• dataset توسعه، ثابت و پس از launch را از هم جدا کنید.
• score را به تفکیک ریسک و سناریو گزارش کنید.
• معیار توقف، owner و مسیر افزودن blind spot را ثبت کنید.

اثر AI بر این فرایند

AI می‌تواند سرعت جمع‌آوری، پاک‌سازی، variation و triage دادهٔ ارزیابی را بالا ببرد؛ نقش مناسب آن augmentation است، نه داور بی‌قیدوشرط کیفیت. trade-off اصلی میان پوشش سریع و اعتبار، privacy، سوگیری و توافق مصنوعی است. معیار بازبینی باید provenance، سهم دادهٔ واقعی و synthetic، کیفیت annotation، پوشش failure case و score تفکیک‌شده را نشان دهد. قضاوت متخصص، تصمیم release و پاسخ‌گویی در خطا همچنان مالک انسانی دارد.

جمع‌بندی: dataset را مثل محصول نگهداری کنید

واقعیت عمومی: مستندات رسمی OpenAI eval را با test input و معیار سنجش تعریف می‌کنند، برای datasets گسترش edge case و blind spot را توصیه می‌کنند و annotation متخصص را باارزش می‌دانند. همان مستندات در ۲۰۲۶ دربارهٔ deprecate شدن Evals platform و تاریخ‌های انتقال هشدار داده‌اند؛ بنابراین اصول dataset و evaluation را مستقل از ابزار نگه دارید.

تحلیل من: دادهٔ eval فقط ورودی مدل نیست؛ حافظهٔ تصمیم‌های تیم دربارهٔ کاربر، ریسک و کیفیت است. اگر منبع، مجوز، reference، severity و نسخه را ثبت نکنیم، score قابل‌اعتماد و قابل‌توضیح نخواهد بود. دادهٔ مصنوعی هم باید برای پوشش باشد، نه جانشین واقعیت.

پیشنهاد حکیم: با یک workflow محدود شروع کنید، ده‌ها نمونهٔ متنوع و مستند بسازید، failure case را از همان ابتدا وارد کنید و هر تغییر prompt یا model را با dataset ثابت مقایسه کنید. بعد از launch، خطای واقعی را با فرایند مجاز به مجموعه برگردانید. AI می‌تواند ساخت eval را سریع‌تر کند؛ اعتبار آن را فقط evidence، قضاوت انسانی و تداوم می‌سازد.

منابع اولیه برای بررسی

• راهنمای رسمی OpenAI دربارهٔ eval، test input، grader و فرایند تکرارشوندهٔ ارزیابی: https://developers.openai.com/api/docs/guides/evals.md — بررسی‌شده در 2026-09-14.
• راهنمای رسمی OpenAI دربارهٔ datasets، annotation متخصص، edge case و گسترش مجموعهٔ ارزیابی: https://developers.openai.com/api/docs/guides/evaluation-getting-started.md — بررسی‌شده در 2026-09-14.
• مستندات رسمی OpenAI دربارهٔ graderها و تفاوت string check، similarity، model grader و code execution: https://developers.openai.com/api/docs/guides/graders.md — بررسی‌شده در 2026-09-14.