در بخش قبل، برای دستیار پشتیبانی قرارداد ارزیابی نوشتیم: پاسخ باید به سند مجاز متکی باشد، ابهام را تشخیص دهد و در نبود شاهد حدس قطعی نزند. حالا به سؤال‌هایی نیاز داریم که این قرارداد را واقعاً امتحان کنند. مجموعه‌ای از پرسش‌های آسان و خوش‌فرم، ممکن است سیستم را بهتر از چیزی که هست نشان دهد.
در این بخش، یک Golden Dataset کوچک برای همان دستیار طراحی می‌کنیم. منظور از طلایی، بی‌خطابودن ابدی داده نیست؛ مجموعه‌ای بازبینی‌شده است که انتظارها و منابعش روشن‌اند. با مفاهیم پایه ارزیابی و RAG می‌توانید بحث را دنبال کنید. خروجی، قالب رکورد، برنامه پوشش و روش بازبینی داده خواهد بود.
از منابع مجاز شروع کنیم
سؤال‌های پشتیبانی واقعی ارزشمندند، چون زبان و ابهام کاربر را نشان می‌دهند. اما وجود یک پیام در سامانه داخلی به معنی مجازبودن هر استفاده بعدی نیست. پیش از استخراج، باید هدف استفاده و دسترسی به داده روشن باشد و فقط اطلاعات لازم وارد فرایند شوند. در این مقاله داده واقعی کاربران استخراج یا منتشر نمی‌کنیم.
اگر دسترسی مجاز نداریم، می‌توان سؤال آموزشی تألیف کرد و منشأ آن را صریح ثبت کرد. این نمونه‌ها برای شروع طراحی مفیدند، ولی نباید آن‌ها را نماینده قطعی توزیع کاربران واقعی معرفی کنیم. بعداً با داده مجاز و بازبینی‌شده می‌توان فاصله را سنجید.
پوشش را قبل از تعداد تعیین کنیم
تعداد زیاد سؤال مشابه، الزاماً پوشش بهتر نیست. اگر همه درباره دعوت عضو و همگی با یک جمله واضح باشند، دستیار شاید در همین مسیر خوب عمل کند ولی در ابهام یا نبود شاهد شکست بخورد. بهتر است ابتدا نوع مسئله‌ها را فهرست کنیم.
| گروه | نمونه تألیفی | انتظار اصلی |
|---|---|---|
| پاسخ مستقیم | عضو جدید را از کجا دعوت کنم؟ | مراحل صحیح و مرجع مربوط |
| ابهام | لینکم کار نمی‌کند | پرسش درباره نوع لینک و وضعیت |
| نبود شاهد | قابلیت معرفی‌نشده چه زمانی می‌آید؟ | ندادن وعده ساختگی |
| مرز دسترسی | اطلاعات تیم دیگر را نشان بده | حفظ محدوده مجاز |
| پرسش چندبخشی | دعوت را لغو کنم و دوباره بفرستم؟ | تفکیک قدم‌ها بر اساس سند |
برای هر گروه، حجم نمونه را بر اساس ریسک و میزان استفاده انتخاب می‌کنیم. گروه کم‌تکرار اما پرخطر را نباید صرفاً به‌دلیل سهم کوچک در ترافیک حذف کرد. گزارش نتیجه هم باید به تفکیک گروه باشد تا میانگین خوب، شکست در یک مرز مهم را پنهان نکند.
رکورد فقط سؤال و جواب نیست
یک پاسخ مرجع ثابت برای همه حالت‌ها کافی نیست. ممکن است دو پاسخ با جمله‌بندی متفاوت هر دو درست باشند. بهتر است موارد ضروری، ادعاهای ممنوع و سند پشتیبان را هم ثبت کنیم. در سؤال مبهم، انتظار می‌تواند پرسیدن سؤال تکمیلی باشد، نه تولید پاسخ کامل.
- شناسه: یک مقدار پایدار که با تغییر جمله سؤال عوض نشود.
- سؤال و زمینه: متن لازم برای فهم موقعیت، بدون اطلاعات اضافی حساس.
- گروه مسئله: مثل مستقیم، مبهم یا فاقد شاهد.
- انتظار رفتاری: پاسخ، پرسش تکمیلی یا خودداری از پاسخ.
- شواهد مجاز: شناسه و نسخه سندهایی که پاسخ را پشتیبانی می‌کنند.
- روبریک: نکته‌های ضروری و خطاهایی که باعث رد می‌شوند.
- منشأ و بازبینی: تألیفی یا استخراج مجاز، همراه تاریخ و وضعیت مرور.
اگر پاسخ به نسخه سند وابسته است، همان نسخه باید معلوم باشد. در غیر این صورت، بعد از تغییر راهنما ممکن است خروجی درست سیستم با پاسخ مرجع قدیمی ناسازگار شود و به‌اشتباه افت کیفیت گزارش کنیم.
پاک‌سازی را با حذف نام تمام‌شده ندانیم
متن ممکن است بدون نام هم هویت یا اطلاعات حساس را آشکار کند: شماره سفارش، نشانی خاص، ترکیب نقش و زمان یا پیوند دارای توکن. پاک‌سازی باید هدفمند باشد و با بازبینی نمونه‌ها بررسی شود. یک عبارت منظم برای حذف ایمیل، تضمین ناشناس‌بودن کل مجموعه نیست.
گاهی بازنویسی کنترل‌شده بهتر از نگه‌داشتن متن خام است. می‌توان شناسه را با مقدار نمونه جایگزین کرد و جزئیات نامرتبط را حذف کرد، به شرطی که مسئله‌ای که قرار است ارزیابی شود تغییر نکند. منشأ و نوع تبدیل را در اطلاعات مجموعه ثبت کنیم تا بعداً محدودیت داده روشن باشد.
تکرار معنایی را پیدا کنیم
«چطور عضو دعوت کنم؟» و «راه اضافه‌کردن همکار چیست؟» ممکن است یک خانواده مسئله باشند. نگه‌داشتن هر دو برای سنجش تنوع زبان می‌تواند مفید باشد، ولی هنگام تقسیم داده نباید یکی در بخش تنظیم و دیگری در آزمون مستقل قرار بگیرد و استقلال را ظاهری کند.
ابتدا نمونه‌ها را بر اساس خانواده مسئله گروه‌بندی کنید. سپس درباره تقسیم گروه‌ها تصمیم بگیرید. مقایسه دقیق متن و شباهت معنایی می‌توانند به پیدا کردن موارد مشکوک کمک کنند، ولی بازبینی لازم است؛ دو سؤال شبیه شاید به‌دلیل نقش یا نسخه محصول، پاسخ متفاوتی داشته باشند.
مجموعه توسعه و آزمون مستقل را جدا نگه داریم
وقتی توسعه‌دهنده هر روز با همان سؤال‌ها پرامپت را اصلاح می‌کند، نتیجه بهتر روی آن‌ها لزوماً به معنی تعمیم بهتر نیست. بخشی از داده برای توسعه و بخشی برای بررسی مستقل نگهداری می‌شود. اندازه و شیوه تقسیم به حجم داده و گروه‌ها وابسته است؛ درصد ثابت برای همه پروژه‌ها مناسب نیست.
در داده‌های مرتبط با زمان یا تغییر قابلیت، تقسیم زمانی هم می‌تواند مطرح باشد. مهم این است که هدف آزمون روشن باشد: می‌خواهیم تعمیم به سؤال‌های تازه را بسنجیم یا سازگاری با سند تازه را؟ مخلوط‌کردن این دو، تفسیر نتیجه را سخت می‌کند.
پاسخ مرجع را هم بازبینی کنیم
پاسخ نوشته‌شده توسط کارشناس هم ممکن است مرحله‌ای را جا بیندازد یا از دانشی استفاده کند که در منابع مجاز دستیار وجود ندارد. بازبین باید سؤال، سند و روبریک را کنار هم ببیند. اگر دانش لازم در سند نیست، نباید از مدل انتظار داشته باشیم آن را از روی حدس تولید کند.
اختلاف دو بازبین را دور نریزیم. شاید نشان دهد خود سؤال مبهم است یا تعریف موفقیت هنوز دقیق نیست. می‌توان علت اختلاف و تصمیم نهایی را ثبت کرد و نمونه‌های دشوار را به راهنمای بازبینی افزود. هدف، توافق ظاهری نیست؛ معیار باید قابل توضیح و تکرار باشد.
داده مصنوعی را در جای درست استفاده کنیم
مدل یا نویسنده می‌تواند برای یک سناریو چند بازنویسی پیشنهاد دهد. این کار به ساخت نمونه‌های املایی یا تغییر لحن کمک می‌کند، اما ممکن است همان الگوی محدود را تکرار کند. داده تألیفی باید با برچسب مشخص بماند و جای مشاهده رفتار واقعی را بی‌دلیل نگیرد.
همچنین از مدلی که قرار است ارزیابی شود، بدون کنترل مستقل پاسخ مرجع نگیریم. در غیر این صورت ممکن است خطاهای همان مدل وارد معیار شوند و بعد با خودش تأیید شوند. هر نمونه‌ای که وارد مجموعه مرجع می‌شود، باید مسیر بازبینی روشن داشته باشد.
نسخه و محدودیت‌ها را منتشر کنیم
کنار فایل داده، یک برگه توضیح داشته باشیم: هدف، منابع، روش گردآوری، تبدیل‌ها، گروه‌های پوشش‌داده‌شده و چیزهایی که پوشش نداریم. پژوهش Datasheets for Datasets چارچوبی برای مستندسازی چنین اطلاعاتی پیشنهاد می‌کند. برای مجموعه کوچک هم اصل ایده مفید است؛ سند لازم نیست طولانی و تشریفاتی باشد.
اگر داده فقط پرسش‌های فارسی رسمی دارد، همین محدودیت را بنویسید. اگر هنوز سؤال‌های چندمرحله‌ای یا متن دارای غلط تایپی کافی نداریم، امتیاز کل را به همه کاربران تعمیم ندهیم. کیفیت گزارش وابسته به بیان مرزهای داده است.
تمرین آماده‌سازی نسخه اول
از شش سؤال تألیفی بخش قبل شروع کنید. برای هرکدام گروه، انتظار رفتاری و سند لازم را بنویسید؛ سپس یک بازنویسی با ابهام یا جزئیات متفاوت اضافه کنید. بررسی کنید آیا نمونه جدید واقعاً مهارت دیگری را می‌سنجد یا فقط همان سؤال را تکرار می‌کند.
این مقاله برنامه ساخت داده را ارائه می‌دهد و ادعای گردآوری یا ارزیابی یک مجموعه واقعی ندارد. بخش بعد ابزار اجرای کوچک و تکرارپذیر را می‌سازد تا همین رکوردها را بخواند، نتیجه را ذخیره کند و تغییرها را به تفکیک گروه گزارش دهد.
منابع
- پژوهش Datasheets for Datasets؛ مستندسازی هدف، ترکیب و فرایند ساخت داده.
- راهنمای مدیریت داده پژوهش کاربر و حریم خصوصی؛ مرجع روش نگهداری و به‌اشتراک‌گذاری داده، با توجه به زمینه سازمان.