یک مدل هوش مصنوعی ممکن است در چند نمونه آزمایشی پاسخ‌های عالی تولید کند، اما هنگام استفاده واقعی با پرسش‌های مبهم، داده ناقص، زبان محاوره‌ای یا ورودی‌های غیرمنتظره روبه‌رو شود. چند خروجی خوب برای اثبات قابل اعتماد بودن یک سامانه کافی نیست. اگر قرار است مدل در تولید متن، استخراج اطلاعات، طبقه‌بندی، پاسخ‌گویی یا کمک به تصمیم‌گیری استفاده شود، باید کیفیت آن را با آزمون‌های تکرارپذیر بسنجیم. ارزیابی خروجی مدل هوش مصنوعی یعنی تعریف انتظار، ساخت مجموعه‌ای از ورودی‌های نماینده، سنجش پاسخ با معیارهای روشن، تحلیل خطا و تکرار آزمون پس از هر تغییر. این کار قرار نیست همه پاسخ‌ها را به یک عدد ساده تقلیل دهد؛ هدف، شناخت نقاط قوت و محدودیت و تعیین شرایط امن استفاده است.
ابتدا کاربرد را محدود و دقیق تعریف کنید
عبارت «مدل خوب باشد» معیار قابل سنجشی نیست. باید مشخص کنید مدل برای چه کاری استفاده می‌شود و خروجی مناسب چه ویژگی‌هایی دارد. خلاصه‌سازی یک سند، استخراج شماره فاکتور، پاسخ به پرسش از پایگاه دانش و پیشنهاد عنوان، معیارهای متفاوتی دارند. برای هر کاربرد، ورودی، خروجی مورد انتظار، کاربر نهایی و پیامد خطا را بنویسید. اگر مدل فقط ایده اولیه پیشنهاد می‌دهد، خطای جزئی ممکن است قابل قبول باشد؛ اگر داده حقوقی یا مالی استخراج می‌کند، خطای کوچک هم می‌تواند پرهزینه باشد. کاربرد را به وظیفه‌ای مشخص تبدیل کنید تا بتوانید آزمون متناسب طراحی کنید. ارزیابی بدون تعریف دامنه، معمولاً به امتیازهای ظاهراً دقیق اما بی‌معنا ختم می‌شود.
مجموعه آزمون را از نمونه‌های واقعی بسازید
مجموعه آزمون یا test set باید نماینده تنوع ورودی‌هایی باشد که در عمل دریافت می‌کنید. از نمونه‌های واقعی و مجاز استفاده کنید و اطلاعات شخصی یا محرمانه را پیش از ورود به محیط آزمایش حذف یا ناشناس کنید. ورودی‌های ساده، دشوار، کوتاه، طولانی، دارای غلط املایی، چندمعنایی و ناقص را در نظر بگیرید. اگر مدل با فارسی و انگلیسی سروکار دارد، ترکیب زبان‌ها و اصطلاحات تخصصی را نیز بیازمایید. نمونه‌های پرتکرار را بیش از حد زیاد نکنید؛ در غیر این صورت مجموعه آزمون تصویری خوش‌بینانه از عملکرد می‌دهد. برای هر ورودی، پاسخ مرجع، معیار پذیرش یا دست‌کم ویژگی‌های لازم خروجی را ثبت کنید و نسخه مجموعه را نگه دارید.
نمونه‌های مرجع را با دقت تعریف کنید
برای بعضی وظایف پاسخ دقیق و یگانه وجود دارد؛ مثلاً استخراج تاریخ از یک سند مشخص. برای وظایف دیگر مانند خلاصه‌سازی یا پاسخ تشریحی، چند پاسخ متفاوت می‌توانند درست باشند. در حالت دوم، به جای یک متن مرجع خشک، rubric یا جدول معیار تهیه کنید. مثلاً پاسخ باید نکته اصلی را پوشش دهد، اطلاعاتی خارج از منبع اضافه نکند، ابهام مهم را پنهان نکند و در حد تعیین‌شده کوتاه باشد. برای موارد اختلافی، دو ارزیاب مستقل می‌توانند نمونه‌ها را بررسی کنند و اختلاف را ثبت کنند. اگر معیار پذیرش روشن نباشد، امتیازدهی انسانی نیز سلیقه‌ای می‌شود. تعریف مرجع باید پیش از مشاهده خروجی مدل انجام شود تا معیارها برای توجیه پاسخ تولیدشده تغییر نکنند.
معیارهای ارزیابی را متناسب با وظیفه انتخاب کنید
برای استخراج ساختاریافته، دقت هر فیلد، نرخ مقدار اشتباه و نرخ مقدار جاافتاده مهم است. برای طبقه‌بندی، precision و recall در کنار ماتریس خطا تصویر بهتری از عملکرد می‌دهند. برای خلاصه‌سازی، پوشش نکات کلیدی، صحت گزاره‌ها و حذف جزئیات نامرتبط اهمیت دارد. برای پاسخ‌گویی مبتنی بر منبع، باید بررسی کنید آیا پاسخ با منبع سازگار است، آیا ادعاها پشتیبانی می‌شوند و آیا مدل در نبود شواهد از پاسخ قطعی خودداری می‌کند. معیارهای خودکار می‌توانند مقایسه را سریع کنند، اما همیشه با کیفیت انسانی همبستگی کامل ندارند. یک عدد کلی را به عنوان حقیقت نهایی نپذیرید؛ نتایج را بر اساس نوع خطا و اهمیت آن تفکیک کنید.
خطاهای خطرناک را از خطاهای ظاهری جدا کنید
غلط تایپی، قالب نامناسب و پاسخ کمی طولانی با جعل عدد، افشای اطلاعات یا توصیه خطرناک هم‌وزن نیستند. برای هر نوع خطا شدت تعریف کنید: بحرانی، مهم و جزئی. خطای بحرانی می‌تواند انتشار را متوقف کند؛ خطای مهم نیازمند اصلاح یا تأیید انسانی است؛ خطای جزئی ممکن است در نسخه بعدی بهبود یابد. نرخ خطای بحرانی را جداگانه گزارش کنید و اجازه ندهید میانگین خوب آن را پنهان کند. برای نمونه، اگر مدل در ۹۸ درصد موارد درست است اما در دو درصد باقی‌مانده اطلاعات حساس را افشا می‌کند، میانگین ۹۸ درصد توصیف مناسبی از ریسک نیست. معیارها باید به پیامد واقعی خطا وصل باشند.
ارزیابی انسانی را ساختارمند کنید
بازبین انسانی نباید فقط بگوید «این پاسخ خوب است». فرم ارزیابی را به معیارهای مشخص تقسیم کنید: صحت، کامل بودن، ارتباط با پرسش، وضوح، پیروی از قالب، رعایت محدودیت و استناد به منبع. برای هر معیار مقیاس تعریف کنید و چند نمونه مرزی را به عنوان راهنمای امتیازدهی نگه دارید. اگر چند ارزیاب دارید، بخشی از نمونه‌ها را مشترک بررسی کنید تا میزان توافق آن‌ها مشخص شود. اختلاف زیاد میان ارزیابان نشانه ابهام در rubric یا نیاز به آموزش است. در کاربردهای حساس، بازبینی متخصص حوزه لازم است و نباید تمام مسئولیت به یک ارزیاب عمومی سپرده شود. زمان و هزینه ارزیابی انسانی را نیز در برنامه نگهداری مدل لحاظ کنید.
مدل داور یا LLM-as-a-Judge را با احتیاط به کار ببرید
می‌توان از یک مدل دیگر برای امتیازدهی به خروجی استفاده کرد، اما مدل داور نیز خطا و سوگیری دارد. ممکن است پاسخ طولانی‌تر را بهتر بداند، به لحن مطمئن امتیاز بیشتری بدهد یا تفاوت ظریف واقعیت و حدس را تشخیص ندهد. برای کاهش ریسک، معیارها و قالب امتیازدهی را ثابت کنید، ترتیب پاسخ‌های مقایسه‌ای را جابه‌جا کنید و بخشی از نتایج را با ارزیابی انسانی بسنجید. از مدل داور برای غربال اولیه و یافتن نمونه‌های مشکوک استفاده کنید، نه به عنوان تنها مرجع تصمیم. اگر داور و ارزیاب انسانی اختلاف دارند، نمونه را بررسی و دلیل اختلاف را ثبت کنید. اعتبار داور نیز باید با داده مستقل سنجیده شود.
پایداری و تکرارپذیری را اندازه بگیرید
مدل‌های مولد ممکن است برای یک ورودی در اجراهای مختلف پاسخ‌های متفاوت بدهند. برای کاربردهایی که ثبات اهمیت دارد، یک نمونه را چند بار اجرا کنید و دامنه تغییر را بسنجید. تغییر در prompt، مدل، دما، ابزارهای متصل یا نسخه داده می‌تواند رفتار را عوض کند. تمام تنظیمات آزمون را ثبت کنید: نام و نسخه مدل، زمان اجرا، prompt، پارامترها، داده ورودی و نسخه معیارها. اگر فقط نتیجه نهایی ذخیره شود، بازتولید خطا دشوار خواهد بود. در وظایفی که خروجی ساختاریافته لازم است، اعتبار JSON یا schema را جدا از معنای محتوا بررسی کنید. پاسخ از نظر معنایی درست اما از نظر ساختار غیرقابل پردازش، در یک سامانه خودکار خروجی موفقی نیست.
آزمون‌های مرزی و سوءاستفاده را اضافه کنید
سامانه باید در برابر ورودی‌های خارج از محدوده، درخواست‌های متناقض و تلاش برای دور زدن محدودیت‌ها آزمایش شود. اگر مدل به اسناد متصل است، دستورهای مخرب داخل سند یا متن نقل‌شده را به عنوان داده غیرقابل اعتماد در نظر بگیرید. اگر مدل ابزار فراخوانی می‌کند، بررسی کنید آیا می‌تواند بدون مجوز عملیاتی انجام دهد یا داده‌ای را به مقصد نامناسب بفرستد. آزمون‌های مرزی شامل متن بسیار طولانی، ورودی خالی، زبان غیرمنتظره، کاراکترهای خاص، اطلاعات جعلی و پرسش‌هایی است که پاسخ آن‌ها در منبع وجود ندارد. برای هر آزمون، رفتار مطلوب را از پیش تعریف کنید؛ گاهی پاسخ درست، امتناع روشن یا درخواست توضیح بیشتر است.
آزمون رگرسیون پس از هر تغییر
وقتی prompt یا مدل را تغییر می‌دهید، ممکن است یک خطای قدیمی برطرف شود اما قابلیت دیگری آسیب ببیند. مجموعه آزمون ثابت را پس از هر تغییر مهم اجرا کنید و نتایج را با نسخه قبلی مقایسه کنید. آزمون رگرسیون باید شامل نمونه‌هایی باشد که قبلاً مشکل‌ساز بوده‌اند، نه فقط نمونه‌های تازه. تغییر مدل ارائه‌دهنده، نسخه embedding، ابزار بازیابی یا قالب خروجی نیز می‌تواند رفتار را تغییر دهد. برای تغییرات بزرگ، ابتدا روی محیط آزمایشی و گروه محدودی از کاربران اجرا کنید. اگر معیار بحرانی افت کرد، بازگشت به نسخه قبلی باید ممکن باشد. نگهداری نسخه‌های prompt و گزارش ارزیابی، بخشی از مهندسی سامانه است و نباید به یادداشت‌های پراکنده وابسته بماند.
معیار توقف و اجازه انتشار تعریف کنید
پیش از شروع آزمون مشخص کنید چه نتیجه‌ای برای استفاده قابل قبول است. مثلاً نرخ استخراج درست برای فیلدهای ضروری باید از حدی مشخص بالاتر باشد و هیچ خطای بحرانی در مجموعه آزمون پذیرفته نشود. این حدها باید با ریسک کاربرد تعیین شوند؛ برای پیشنهاد ایده با استخراج اطلاعات حساس یکسان نیستند. اگر خروجی نیازمند تأیید انسان است، این مرحله را در طراحی فرایند لحاظ کنید و آن را پس از انتشار حذف نکنید. در گزارش ارزیابی، میانگین امتیاز، توزیع خطا، نمونه‌های شکست، محدودیت‌ها و تصمیم نهایی را ثبت کنید. «مدل خوب است» نتیجه قابل اقدام نیست؛ «در این دامنه با این محدودیت‌ها و این سطح نظارت قابل استفاده است» تصمیم دقیق‌تری است.
پایش عملکرد در استفاده واقعی
مجموعه آزمون پیش از انتشار کافی نیست. با تغییر داده و رفتار کاربران، توزیع ورودی‌ها نیز تغییر می‌کند. نرخ پاسخ نامعتبر، درخواست‌های بدون پاسخ، ارجاع‌های ناموجود، اصلاح‌های انسانی و بازخورد کاربران را پایش کنید. نمونه‌های تازه را با رعایت حریم خصوصی به مجموعه آزمون اضافه کنید و مراقب باشید داده‌های آزمون به شکل ناخواسته وارد prompt یا داده آموزش نشوند. اگر مدل در موضوعی خاص خطا می‌کند، دامنه استفاده را محدود یا مرحله تأیید را تقویت کنید. پایش نباید به جمع‌آوری بی‌رویه محتوای خصوصی تبدیل شود؛ داده لازم را با حداقل‌سازی و کنترل دسترسی ثبت کنید.
یک الگوی عملی برای شروع
یک وظیفه مشخص انتخاب کنید و ۵۰ تا ۱۰۰ نمونه متنوع گردآوری کنید؛ تعداد دقیق به ریسک و تنوع کار بستگی دارد. برای هر نمونه، پاسخ مرجع یا معیار پذیرش را ثبت کنید. خروجی مدل را بدون تغییر در فایل ارزیابی ذخیره کنید. سپس معیارهای وظیفه، خطاهای بحرانی و امتیاز انسانی را محاسبه کنید. پنج نمونه شکست مهم را تحلیل کنید و مشخص کنید مشکل از prompt، داده، مدل یا طراحی فرایند است. پس از اصلاح، همان مجموعه را دوباره اجرا کنید و نتیجه را مقایسه کنید. این چرخه ساده، بسیار ارزشمندتر از تعویض مداوم مدل بر اساس چند تجربه پراکنده است. برای چارچوب گسترده‌تر مدیریت ریسک و ارزیابی می‌توانید منابع مرکز منابع هوش مصنوعی NIST و چارچوب مدیریت ریسک هوش مصنوعی NIST را مطالعه کنید.
جمع‌بندی
ارزیابی خروجی هوش مصنوعی باید از کاربرد و پیامد خطا آغاز شود. مجموعه آزمون نماینده بسازید، معیارها را پیش از مشاهده پاسخ تعریف کنید، خطاهای بحرانی را جداگانه بسنجید و ارزیابی انسانی و خودکار را مکمل یکدیگر قرار دهید. نسخه مدل و prompt را ثبت کنید و پس از هر تغییر آزمون رگرسیون اجرا کنید. نتیجه ارزیابی باید محدوده استفاده، نیاز به نظارت و محدودیت‌های شناخته‌شده را روشن کند. هیچ امتیاز واحدی جای قضاوت مهندسی و شناخت ریسک را نمی‌گیرد.
پرسش‌های متداول
برای ارزیابی مدل چند نمونه لازم است؟
عدد ثابتی وجود ندارد. تنوع وظیفه، پیامد خطا و میزان تغییر ورودی تعیین‌کننده‌اند. یک مجموعه کوچک و متنوع برای نمونه اولیه مناسب است، اما کاربرد حساس به داده و بازبینی گسترده‌تر نیاز دارد.
آیا امتیاز مدل داور کافی است؟
خیر. مدل داور می‌تواند غربال اولیه را سریع کند، اما باید با نمونه‌برداری انسانی اعتبارسنجی شود و معیارهای آن شفاف باشد.
هر چند وقت یک بار باید آزمون را تکرار کرد؟
پس از تغییر مدل، prompt، داده، ابزار متصل یا تنظیمات اصلی و نیز به صورت دوره‌ای در استفاده واقعی. تغییر توزیع ورودی‌ها نیز می‌تواند نیاز به بازنگری مجموعه آزمون ایجاد کند.
منابع برای مطالعه بیشتر
- NIST AI Resource Center؛ منابع آزمون، ارزیابی، راستی‌آزمایی و اعتبارسنجی سامانه‌های هوش مصنوعی.
- NIST AI Risk Management Framework؛ چارچوب مدیریت ریسک هوش مصنوعی.
