نمایش چند پاسخ درست برای معرفی یک ایده مفید است، اما برای تصمیم درباره انتشار کافی نیست. ممکن است نمونه‌ها از قبل شناخته شده باشند، موضوع‌های دشوار حذف شده باشند یا پاسخ روان، خطای پنهانی داشته باشد. ارزیابی سامانه هوش مصنوعی باید روشن کند در چه شرایطی می‌توان به خروجی اعتماد کرد و در چه شرایطی باید آن را اصلاح یا به انسان ارجاع داد.
از تصمیم کاربر به معیار برسید
ابتدا مشخص کنید پاسخ قرار است چه کاری را ممکن کند. در راهنمای خدمات، یافتن مسیر درست اهمیت دارد؛ در استخراج اطلاعات، یک فیلد جاافتاده می‌تواند مشکل اصلی باشد. معیار کلی «کیفیت پاسخ» برای طراحی آزمون کافی نیست. آن را به موارد قابل بررسی بشکنید: درستی اطلاعات، وجود شواهد، رعایت دسترسی، زمان پاسخ و رفتار هنگام نامعلوم بودن جواب. وزن این موارد باید به نیاز همان محصول وابسته باشد.
راهنمای بهترین روش‌های ارزیابی OpenAI بر آزمون متناسب با کار واقعی و ترکیب معیارها با قضاوت انسانی تأکید می‌کند. این یک اصل روش‌شناختی است و نیاز به استفاده از سرویس خاصی ندارد. برای تیم کوچک، یک مجموعه سؤال در فایل قابل نسخه‌بندی هم می‌تواند آغاز مناسبی باشد؛ مهم این است که پاسخ مطلوب و دلیل آن روشن ثبت شوند.
مجموعه آزمون باید نماینده کاربرد باشد
سؤال‌های پرتکرار، دشوار، مبهم و خارج از حوزه را جداگانه انتخاب کنید. تنها متن‌های رسمی و کامل نگذارید؛ کاربران با جمله شکسته، واژه محاوره‌ای و اشتباه تایپی هم مراجعه می‌کنند. در پروژه فارسی، اعداد فارسی و لاتین، شکل‌های مختلف ی و ک و نام‌های مشابه باید در طراحی داده دیده شوند. در غیر این صورت، مجموعه آزمون ممکن است تصویری مرتب اما غیرواقعی از استفاده روزمره بسازد.
در آموزش تقسیم مجموعه داده در Google، استقلال داده آزمون از داده آموزش و خطر نمونه‌های تکراری توضیح داده شده است. در ارزیابی یک برنامه مولد نیز باید مراقب تکرار و آشنایی قبلی با نمونه‌ها بود. پیشنهاد ما نگه داشتن مجموعه‌ای جداست که برای اصلاح دستورها به صورت روزمره استفاده نشود، تا مقایسه نسخه‌ها معنای بیشتری داشته باشد.
خطا را دسته‌بندی کنید
یک پاسخ اشتباه می‌تواند علت‌های متفاوتی داشته باشد. شاید سند مناسب پیدا نشده، شاید سند درست بوده اما عدد اشتباه نقل شده، یا شاید برنامه نتیجه ابزار را نادرست نمایش داده است. اگر همه موارد فقط «ناموفق» ثبت شوند، تیم نمی‌داند چه بخشی را اصلاح کند. دسته‌هایی محدود و قابل فهم بسازید و برای هر خطا، ورودی، خروجی، نسخه سامانه و توضیح کوتاه نگه دارید.
خطاهای پرهزینه را در گروه جدا ببینید. اشتباه در جمله‌بندی با افشای یک سند محرمانه وزن یکسان ندارد. میانگین خوب ممکن است ضعف در یک گروه مهم را پنهان کند. در گزارش، نتیجه گروه‌های اصلی و موارد بحرانی را نشان دهید. وقتی داده محدود است، عدم قطعیت را هم بیان کنید؛ درصدی که از تعداد اندک مثال به دست آمده نباید به عنوان کیفیت قطعی کل محصول معرفی شود.
داوری خودکار را با انسان تطبیق دهید
برای بررسی قالب و وجود فیلدها می‌توان از قواعد قطعی استفاده کرد. برای مفید بودن پاسخ، داوری انسانی معمولاً اطلاعات بیشتری می‌دهد. اگر یک مدل دیگر نقش داور دارد، چند نمونه را مستقل با کارشناس بررسی کنید و اختلاف‌ها را بخوانید. پاسخ طولانی یا لحن قاطع نباید خودبه‌خود امتیاز بیشتری بگیرد. معیارهای داوری را به رفتار مورد انتظار وصل کنید و نمونه‌های مرزی برای آن بنویسید.
مقایسه نسخه‌ها را قابل تکرار کنید
هنگام تغییر مدل، دستور یا پایگاه دانش، همان مجموعه را با تنظیمات ثبت‌شده اجرا کنید. تنها نتیجه نهایی را مقایسه نکنید؛ زمان پاسخ، مصرف و نوع خطا نیز ممکن است تغییر کنند. یک نسخه می‌تواند در پاسخ‌های عادی بهتر شود و در موارد حساس ضعیف‌تر. تصمیم انتشار باید بر اساس این تصویر کامل باشد و برای بازگشت به نسخه قبلی مسیر روشن داشته باشد.
ارزیابی با انتشار تمام نمی‌شود. با رعایت حریم خصوصی، موارد شکست واقعی را به مجموعه بررسی اضافه کنید و دوره‌ای درباره تعریف موفقیت بازنگری کنید. ممکن است کاربران از محصول کاری بخواهند که در فرض اولیه دیده نشده است. یک برنامه ارزیابی سالم به تیم کمک می‌کند میان مشکل داده، مشکل طراحی و محدودیت فناوری فرق بگذارد و منابع را در جایی صرف کند که برای کاربر ارزش واقعی دارد.
منابع و مطالعهٔ بیشتر
بررسی منابع: ۲۱ مهر ۱۴۰۵. تحلیل‌ها و پیشنهادهای اجرایی، جمع‌بندی نویسنده‌اند.
