چطور کیفیت نتایج مدل‌های زبانی بزرگ (LLM) را ارزیابی کنیم؟

مدل‌های زبانی بزرگ یا LLM می‌توانند متن تولید کنند، به پرسش‌ها پاسخ دهند، اسناد را خلاصه کنند و در برنامه‌نویسی و تحلیل اطلاعات کمک کنند. با این حال، پاسخ روان و ظاهراً منطقی یک مدل لزوماً پاسخ صحیحی نیست. ممکن است مدل بخشی از سؤال را نادیده بگیرد، اطلاعات نادرست بسازد، منبعی نامعتبر معرفی کند یا در پاسخ به پرسش‌های مشابه نتایج متفاوتی ارائه دهد.

به همین دلیل، ارزیابی کیفیت خروجی مدل‌های زبانی یکی از مراحل مهم استفاده حرفه‌ای از هوش مصنوعی است. این ارزیابی به کاربران و سازمان‌ها کمک می‌کند بفهمند آیا یک مدل برای وظیفه موردنظر مناسب است، چه نوع خطاهایی دارد و تا چه اندازه می‌توان به نتیجه آن اعتماد کرد.

در این مقاله، معیارهای اصلی ارزیابی LLM، روش طراحی آزمون، نمونه‌های عملی، ابزارهای سنجش و راهکارهای کاهش خطا را بررسی می‌کنیم.

ارزیابی کیفیت LLM چیست؟

ارزیابی کیفیت LLM فرایندی است که در آن خروجی یک مدل بر اساس معیارهای مشخص بررسی می‌شود تا میزان مناسب‌بودن آن برای یک کاربرد تعیین شود.

این ارزیابی ممکن است برای مقایسه دو مدل، بررسی نسخه جدید یک سامانه، آزمایش یک پرامپت، سنجش عملکرد چت‌بات سازمانی یا کنترل کیفیت محتوای تولیدشده انجام شود.

برای مثال، اگر از مدل برای پاسخ‌گویی به پرسش‌های مشتریان استفاده می‌کنید، صرفاً روان‌بودن پاسخ کافی نیست. پاسخ باید با سیاست‌های شرکت سازگار باشد، اطلاعات نادرست ندهد، به سؤال مشتری مرتبط باشد و در صورت نداشتن اطلاعات کافی، از حدس‌زدن خودداری کند.

در نتیجه، کیفیت LLM یک ویژگی تک‌بعدی نیست. مدل ممکن است در خلاصه‌سازی عملکرد خوبی داشته باشد، اما در استخراج اعداد، پاسخ‌گویی درباره اطلاعات جدید یا رعایت دستورهای پیچیده ضعیف‌تر عمل کند.

چرا باید نتایج مدل‌های زبانی را ارزیابی کنیم؟

ارزیابی منظم چند مزیت مهم دارد.

جلوگیری از انتشار اطلاعات نادرست

مدل‌های زبانی ممکن است اطلاعاتی تولید کنند که از نظر زبانی قانع‌کننده است، اما با واقعیت مطابقت ندارد. این مسئله در محتوای تخصصی، گزارش‌های مدیریتی و پاسخ‌گویی به مشتریان اهمیت بیشتری پیدا می‌کند.

انتخاب مدل مناسب

بزرگ‌تر یا گران‌تر بودن یک مدل الزاماً به معنی مناسب‌تر بودن آن برای همه کاربردها نیست. آزمون‌های واقعی نشان می‌دهند کدام مدل برای وظیفه موردنظر عملکرد بهتری دارد.

کاهش هزینه و زمان بازبینی

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

شناسایی مشکلات پیش از انتشار

آزمون قبل از راه‌اندازی به شناسایی خطاهایی کمک می‌کند که ممکن است در محیط واقعی به کاربران آسیب بزنند یا هزینه ایجاد کنند.

بررسی عملکرد در طول زمان

پس از تغییر مدل، پرامپت، منابع اطلاعاتی یا نرم‌افزار، عملکرد سامانه ممکن است تغییر کند. آزمون‌های تکرارشونده کمک می‌کنند افت کیفیت زودتر شناسایی شود.

۱. دقت پاسخ را بررسی کنید

دقت یکی از مهم‌ترین معیارهای ارزیابی است. در این مرحله بررسی می‌کنیم آیا ادعاهای مطرح‌شده در پاسخ با اطلاعات معتبر یا پاسخ مرجع سازگار هستند یا خیر.

برای سنجش دقت، ابتدا باید بدانید پاسخ صحیح چیست یا از چه منبعی می‌توان صحت آن را بررسی کرد.

برای نمونه، اگر از مدل درباره ویژگی‌های یک پردازنده سؤال می‌کنید، مشخصات رسمی سازنده می‌تواند مرجع مناسبی باشد. اگر مدل باید بر اساس یک سند داخلی پاسخ دهد، همان سند باید مبنای بررسی قرار گیرد.

چگونه دقت را بسنجیم؟

  • ادعاهای مهم پاسخ را جدا کنید.
  • برای هر ادعا، منبع معتبر یا پاسخ مرجع تعیین کنید.
  • اطلاعات نادرست، ناقص یا قدیمی را علامت بزنید.
  • میزان اهمیت هر خطا را مشخص کنید.
  • نتیجه را روی چندین نمونه بررسی کنید، نه فقط یک پاسخ.

همه خطاها شدت یکسانی ندارند. اشتباه نگارشی با ارائه مشخصات فنی نادرست یا راهنمایی ناامن تفاوت دارد. بنابراین، بهتر است خطاها بر اساس پیامد احتمالی نیز دسته‌بندی شوند.

۲. ارتباط پاسخ با سؤال را بسنجید

پاسخ ممکن است از نظر اطلاعاتی درست باشد، اما سؤال اصلی را پاسخ ندهد. ارتباط (Relevance) نشان می‌دهد خروجی تا چه اندازه با هدف و درخواست کاربر هماهنگ است.

فرض کنید کاربر می‌پرسد: «سه تفاوت اصلی بین حافظه SSD و HDD را توضیح بده.» اگر مدل تاریخچه طولانی ذخیره‌سازی داده را شرح دهد، اما تفاوت‌های موردنظر را مشخص نکند، پاسخ از نظر ارتباط ضعیف است؛ حتی اگر بخش زیادی از اطلاعات آن صحیح باشد.

برای بررسی ارتباط، این پرسش‌ها را مطرح کنید:

  • آیا مدل مستقیماً به سؤال پاسخ داده است؟
  • آیا تمام بخش‌های درخواست را پوشش داده است؟
  • آیا پاسخ شامل اطلاعات غیرضروری و تکراری است؟
  • آیا سطح توضیح با دانش مخاطب تناسب دارد؟
  • آیا قالب درخواستی، مانند جدول یا فهرست، رعایت شده است؟

در کاربردهای حرفه‌ای، ارتباط را بهتر است جدا از صحت بررسی کنید. پاسخ می‌تواند مرتبط اما نادرست، یا صحیح اما نامرتبط باشد.

۳. کامل‌بودن پاسخ را ارزیابی کنید

کامل‌بودن (Completeness) نشان می‌دهد آیا مدل تمام اطلاعات ضروری برای انجام وظیفه را ارائه کرده است یا خیر.

برای مثال، اگر از مدل بخواهید مزایا، محدودیت‌ها و ریسک‌های یک فناوری را توضیح دهد، ارائه صرفاً مزایا به معنی پاسخ کامل نیست.

برای سنجش کامل‌بودن، پیش از اجرای آزمون فهرستی از اجزای ضروری پاسخ تهیه کنید. سپس بررسی کنید کدام موارد در خروجی وجود دارند و کدام موارد جا افتاده‌اند.

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

۴. توهم هوش مصنوعی را شناسایی کنید

توهم هوش مصنوعی (Hallucination) به حالتی گفته می‌شود که مدل اطلاعات نادرست یا بدون پشتوانه کافی تولید می‌کند؛ برای مثال، نام یک مقاله، عدد، نقل‌قول، ویژگی محصول یا منبع را به شکلی مطرح می‌کند که واقعیت ندارد.

این خطا می‌تواند حتی زمانی رخ دهد که پاسخ از نظر نگارش بسیار حرفه‌ای باشد.

روش‌های شناسایی توهم

بررسی منابع: اگر مدل منبعی معرفی کرده است، وجود آن و ارتباطش با ادعا را بررسی کنید.

مقایسه با اسناد مرجع: در کاربردهای مبتنی بر اسناد، پاسخ را با متن اصلی تطبیق دهید.

پرسش‌های دارای پاسخ مشخص: چند سؤال با پاسخ مرجع و قابل‌بررسی طراحی کنید.

آزمون موارد ناشناخته: پرسش‌هایی مطرح کنید که اطلاعات کافی برای پاسخ‌گویی به آن‌ها وجود ندارد و بررسی کنید آیا مدل محدودیت خود را اعلام می‌کند یا اطلاعات می‌سازد.

بررسی جزئیات حساس: اعداد، تاریخ‌ها، نام‌ها، نسخه‌ها و مشخصات فنی را جداگانه کنترل کنید.

یک نکته مهم این است که درخواست از مدل برای اعلام میزان اطمینان، به‌تنهایی صحت پاسخ را تضمین نمی‌کند. مدل ممکن است نسبت به پاسخ اشتباه خود نیز مطمئن به نظر برسد.

۵. پایبندی به دستورها و قالب خروجی را بررسی کنید

بسیاری از وظایف حرفه‌ای نیازمند رعایت محدودیت‌های مشخص هستند. برای مثال، خروجی باید در قالب JSON معتبر باشد، حداکثر پنج مورد داشته باشد یا تنها بر اساس اطلاعات یک سند تهیه شود.

پایبندی به دستورها (Instruction Following) نشان می‌دهد مدل تا چه اندازه خواسته‌های صریح کاربر را رعایت کرده است.

برای ارزیابی این معیار، دستورهای مهم را به چک‌لیستی تبدیل کنید:

  • آیا قالب خروجی صحیح است؟
  • آیا تعداد موارد تعیین‌شده رعایت شده است؟
  • آیا مدل از اطلاعات خارج از محدوده تعیین‌شده استفاده کرده است؟
  • آیا بخش‌های ضروری حذف شده‌اند؟
  • آیا محدودیت‌های طول یا زبان رعایت شده‌اند؟

اگر خروجی برای نرم‌افزار دیگری استفاده می‌شود، اعتبارسنجی ماشینی قالب نیز اهمیت دارد. برای مثال، یک خروجی JSON باید با تجزیه‌گر معتبر بررسی شود؛ ظاهر مرتب متن کافی نیست.

۶. ثبات پاسخ‌ها را اندازه‌گیری کنید

مدل‌های زبانی ممکن است در درخواست‌های مشابه پاسخ‌هایی با تفاوت‌های قابل‌توجه تولید کنند. میزان این تفاوت به مدل، تنظیمات تولید، پرامپت و نوع وظیفه بستگی دارد.

ثبات (Consistency) به‌ویژه در سامانه‌های پشتیبانی مشتری، طبقه‌بندی متن، استخراج داده و تولید گزارش اهمیت دارد.

برای آزمون ثبات، یک مجموعه از درخواست‌های یکسان یا معادل تهیه کنید و خروجی‌ها را با یک معیار ثابت مقایسه کنید.

برای نمونه، اگر مدل باید پیام‌های مشتریان را در پنج دسته طبقه‌بندی کند، می‌توانید بررسی کنید آیا پیام‌های مشابه در اجراهای مختلف برچسب یکسانی می‌گیرند یا خیر.

ثبات همیشه به معنی صحت نیست. مدل ممکن است یک پاسخ اشتباه را بارها تکرار کند. به همین دلیل، ثبات و دقت باید به‌صورت جداگانه اندازه‌گیری شوند.

۷. کیفیت منابع و استنادها را بررسی کنید

برخی سامانه‌ها پاسخ را همراه با ارجاع به اسناد یا صفحات وب ارائه می‌کنند. در این موارد، فقط وجود لینک کافی نیست؛ باید مشخص شود منبع واقعاً از ادعای مطرح‌شده پشتیبانی می‌کند یا خیر.

چهار مورد مهم عبارت‌اند از:

  1. وجود منبع: آیا صفحه یا سند واقعاً در دسترس است؟
  2. اعتبار منبع: آیا ناشر برای این موضوع قابل‌اعتماد است؟
  3. ارتباط: آیا منبع درباره همان ادعای مطرح‌شده صحبت می‌کند؟
  4. پشتیبانی از ادعا: آیا محتوای منبع، پاسخ را تأیید می‌کند یا فقط به موضوعی مشابه مربوط است؟

در سامانه‌هایی که پاسخ را بر اساس اسناد داخلی تولید می‌کنند، باید بررسی شود که مدل از سند درست استفاده کرده و مفهوم آن را تحریف نکرده باشد.

وجود استناد معتبر احتمال بررسی مستقل را آسان‌تر می‌کند، اما به‌تنهایی صحت تمام پاسخ را ثابت نمی‌کند.

۸. عملکرد مدل را با مجموعه آزمون بسنجید

برای ارزیابی قابل‌اعتماد، بهتر است مجموعه‌ای از نمونه‌های آزمون (Test Set) طراحی کنید. این مجموعه شامل ورودی‌های نماینده کاربرد واقعی و در صورت امکان، پاسخ‌های مرجع یا معیارهای روشن ارزیابی است.

برای مثال، اگر مدل قرار است به پرسش‌های فنی کاربران پاسخ دهد، آزمون باید شامل سؤال‌های ساده، سؤال‌های تخصصی، موارد مبهم، پرسش‌های خارج از محدوده و نمونه‌هایی باشد که پاسخ آن‌ها در منابع موجود نیست.

یک مجموعه آزمون مناسب چه ویژگی‌هایی دارد؟

  • نماینده درخواست‌های واقعی کاربران است.
  • نمونه‌های ساده و دشوار را در بر می‌گیرد.
  • خطاهای مهم و موارد مرزی را آزمایش می‌کند.
  • معیار ارزیابی آن پیش از آزمون مشخص شده است.
  • برای مقایسه نسخه‌های مختلف، قابل‌استفاده مجدد است.
  • شامل اطلاعات حساس غیرضروری نیست.

برای جلوگیری از نتیجه‌گیری بر اساس چند نمونه محدود، بهتر است آزمون را روی تعداد کافی از ورودی‌های متنوع اجرا کنید. اندازه مجموعه باید با پیچیدگی وظیفه، ریسک کاربرد و منابع در دسترس متناسب باشد.

۹. از معیارهای مناسب برای نوع وظیفه استفاده کنید

هیچ معیار واحدی برای سنجش همه وظایف LLM مناسب نیست. معیار باید با هدف کاربرد انتخاب شود.

نوع وظیفه معیارهای پیشنهادی
پاسخ‌گویی به سؤال دقت، ارتباط، کامل‌بودن و پشتیبانی از منابع
خلاصه‌سازی پوشش نکات اصلی، وفاداری به متن و خوانایی
ترجمه حفظ معنا، روانی و صحت اصطلاحات
طبقه‌بندی متن Precision، Recall و F1 در صورت وجود برچسب مرجع
استخراج داده صحت فیلدها، میزان داده‌های جاافتاده و قالب خروجی
تولید کد موفقیت آزمون‌ها، صحت عملکرد و بررسی امنیت
تولید محتوای عمومی ارتباط، انسجام، صحت ادعاها و رعایت دستورها
سامانه بازیابی‌محور کیفیت بازیابی اسناد و میزان پشتیبانی پاسخ از منابع

Precision، Recall و F1 چیست؟

در وظایف طبقه‌بندی، این معیارها برای بررسی کیفیت پیش‌بینی مدل کاربرد دارند.

  • Precision: از مواردی که مدل مثبت تشخیص داده، چه سهمی واقعاً مثبت بوده‌اند؟
  • Recall: از تمام موارد مثبت واقعی، چه سهمی توسط مدل شناسایی شده‌اند؟
  • F1: میانگین هماهنگ Precision و Recall است و تعادلی میان این دو معیار ایجاد می‌کند.

برای مثال، در سامانه شناسایی پیام‌های هرزنامه، Precision پایین ممکن است باعث شود پیام‌های سالم به‌اشتباه هرزنامه تشخیص داده شوند؛ در حالی که Recall پایین می‌تواند به عبور تعداد زیادی از پیام‌های ناخواسته منجر شود.

انتخاب معیار مناسب به هزینه هر نوع خطا بستگی دارد.

آیا معیارهای خودکار برای ارزیابی متن کافی هستند؟

معیارهای خودکار می‌توانند سرعت ارزیابی را افزایش دهند، اما برای تمام وظایف کافی نیستند. در تولید متن آزاد، ممکن است دو پاسخ متفاوت هر دو صحیح و مفید باشند؛ در نتیجه، مقایسه صرف واژه‌ها با یک پاسخ مرجع می‌تواند گمراه‌کننده باشد.

در این موارد، ترکیب آزمون‌های خودکار، بررسی انسانی و معیارهای متناسب با کاربرد معمولاً نتیجه بهتری می‌دهد.

۱۰. ارزیابی انسانی و ارزیابی خودکار را ترکیب کنید

ارزیابی انسانی به داور اجازه می‌دهد کیفیت معنا، لحن، ارتباط و ظرافت‌های پاسخ را بررسی کند. ارزیابی خودکار نیز برای سنجش سریع و تکرارشونده معیارهای مشخص مفید است.

هر روش محدودیت‌هایی دارد.

ارزیاب انسانی ممکن است تحت تأثیر لحن قانع‌کننده، ترتیب نمایش پاسخ‌ها یا انتظار قبلی خود قرار بگیرد. ابزار خودکار نیز ممکن است ظرافت‌های معنایی را نادیده بگیرد یا با پاسخ‌های سطحی اما خوش‌ساخت امتیاز بالایی بدهد.

برای کاهش این مشکلات:

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

مدل دیگری از هوش مصنوعی نیز می‌تواند به‌عنوان ارزیاب کمکی استفاده شود؛ این روش گاهی «LLM-as-a-Judge» نامیده می‌شود. با این حال، ارزیاب ماشینی هم ممکن است سوگیری یا خطا داشته باشد و بهتر است برای کاربردهای مهم با نمونه‌های انسانی اعتبارسنجی شود.

۱۱. امنیت و مقاومت در برابر ورودی‌های مخرب را آزمایش کنید

کیفیت یک مدل فقط به درست‌بودن پاسخ‌های عادی محدود نمی‌شود. سامانه باید در برابر درخواست‌های مخرب، تلاش برای افشای اطلاعات و ورودی‌های غیرمنتظره نیز رفتار مناسبی داشته باشد.

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

آزمون امنیتی می‌تواند شامل موارد زیر باشد:

  • بررسی تلاش برای دورزدن دستورهای سیستم
  • آزمایش دسترسی به اطلاعات خارج از سطح مجاز
  • بررسی نحوه پردازش محتوای نامطمئن در اسناد
  • آزمون ورودی‌های غیرعادی یا بسیار طولانی
  • کنترل خروجی‌هایی که قرار است در ابزارهای دیگر اجرا شوند
  • بررسی ثبت و مدیریت خطاها

امنیت را نباید فقط به توانایی مدل در ردکردن یک درخواست مخرب وابسته کرد. کنترل دسترسی، جداسازی داده‌ها، اعتبارسنجی ورودی و محدودکردن مجوز ابزارها باید در سطح سامانه نیز پیاده‌سازی شوند.

۱۲. یک روش عملی برای ارزیابی LLM

اگر قصد دارید یک مدل یا چت‌بات را برای کار واقعی ارزیابی کنید، می‌توانید از فرایند زیر استفاده کنید.

مرحله اول: تعریف هدف

ابتدا مشخص کنید مدل قرار است چه کاری انجام دهد. «مدل خوب» تعریف دقیقی نیست؛ اما «مدلی که بتواند بر اساس راهنمای محصول به پرسش‌های متداول پاسخ دهد و اطلاعات خارج از سند نسازد» هدف قابل‌آزمایش‌تری است.

مرحله دوم: انتخاب معیارها

سه تا پنج معیار مهم انتخاب کنید؛ برای مثال، دقت، ارتباط، کامل‌بودن، رعایت قالب و امنیت. در کاربردهای حساس، معیارهای ایمنی باید اولویت بیشتری داشته باشند.

مرحله سوم: آماده‌سازی ورودی‌ها

مجموعه‌ای از درخواست‌های واقعی و نماینده تهیه کنید. نمونه‌های ساده، دشوار، مبهم و خارج از محدوده را نیز در نظر بگیرید.

مرحله چهارم: تعیین مرجع

برای سؤال‌های دارای پاسخ مشخص، پاسخ مرجع یا منبع معتبر تعیین کنید. برای وظایف خلاقانه، به‌جای پاسخ واحد، معیارهای کیفی مانند ارتباط، انسجام و رعایت محدودیت‌ها را مشخص کنید.

مرحله پنجم: اجرای آزمون

همه مدل‌ها یا نسخه‌ها را با ورودی‌های یکسان و تنظیمات ثبت‌شده آزمایش کنید. نسخه مدل، پرامپت، تنظیمات مهم و زمان آزمون را یادداشت کنید تا مقایسه منصفانه باشد.

مرحله ششم: ثبت و تحلیل خطاها

خطاها را دسته‌بندی کنید؛ مثلاً اطلاعات نادرست، حذف نکته مهم، عدم رعایت دستور، قالب نامعتبر یا نقض محدودیت امنیتی.

مرحله هفتم: اصلاح و آزمون مجدد

بر اساس خطاها، پرامپت، منابع بازیابی یا تنظیمات سامانه را اصلاح کنید. سپس همان مجموعه آزمون را دوباره اجرا کنید تا مشخص شود اصلاحات واقعاً کیفیت را بهتر کرده‌اند یا فقط نوع خطا را تغییر داده‌اند.

۱۳. نمونه جدول ارزیابی کیفیت

جدول زیر یک نمونه ساده برای امتیازدهی انسانی است. می‌توانید معیارها را متناسب با پروژه خود تغییر دهید.

معیار امتیاز ۱ امتیاز ۳ امتیاز ۵
دقت خطاهای مهم عمدتاً صحیح با برخی خطاها صحیح و مستند
ارتباط پاسخ نامرتبط پاسخ نسبتاً مرتبط پاسخ مستقیم و متناسب
کامل‌بودن بخش‌های اصلی جا افتاده‌اند بیشتر موارد پوشش داده شده‌اند تمام موارد ضروری پوشش داده شده‌اند
رعایت دستور محدودیت‌ها رعایت نشده‌اند بخشی از دستورها رعایت شده‌اند همه دستورهای مهم رعایت شده‌اند
خوانایی مبهم یا آشفته قابل‌فهم با ایرادهایی روشن و ساختارمند

در این نمونه، امتیاز ۲ و ۴ نیز می‌تواند برای حالت‌های بینابینی استفاده شود. امتیازها باید همراه با توضیح و نمونه خطا ثبت شوند تا مشخص باشد دلیل ارزیابی چیست.

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

۱۴. چگونه نتایج ارزیابی را بهبود دهیم؟

پس از مشخص‌شدن نوع خطا، راهکار مناسب را انتخاب کنید. تغییر مدل همیشه اولین یا بهترین گزینه نیست.

اگر پاسخ مبهم است: هدف، مخاطب و قالب خروجی را در پرامپت روشن‌تر کنید.

اگر پاسخ ناقص است: فهرست اجزای ضروری را مشخص کنید و از مدل بخواهید هر بخش را جداگانه پوشش دهد.

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

اگر پاسخ به اطلاعات داخلی وابسته است: سامانه بازیابی اسناد را بررسی کنید و مطمئن شوید اطلاعات مرتبط به مدل ارائه می‌شوند.

اگر خروجی ناپایدار است: تنظیمات و پرامپت را ثابت نگه دارید، آزمون را روی نمونه‌های بیشتری اجرا کنید و میزان تغییر نتیجه را بسنجید.

اگر هزینه زیاد است: بررسی کنید آیا مدل کوچک‌تر یا فرایند ساده‌تری می‌تواند همان کیفیت را با هزینه کمتر ارائه دهد.

اگر خطر امنیتی وجود دارد: کنترل دسترسی، محدودیت ابزارها و سازوکارهای امنیتی سامانه را اصلاح کنید. پرامپت به‌تنهایی راهکار کافی برای حفاظت از اطلاعات نیست.

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

۱۵. ابزارهای ارزیابی مدل‌های زبانی بزرگ

برای ارزیابی LLM می‌توان از روش‌های دستی، اسکریپت‌های اختصاصی یا چارچوب‌های نرم‌افزاری استفاده کرد. انتخاب ابزار به پیچیدگی پروژه و مهارت تیم بستگی دارد.

چند گزینه شناخته‌شده عبارت‌اند از:

  • lm-evaluation-harness: چارچوبی برای اجرای مجموعه‌ای از ارزیابی‌های مدل‌های زبانی.
  • Hugging Face Evaluate: کتابخانه‌ای برای محاسبه معیارهای ارزیابی یادگیری ماشین و مدل‌ها.
  • DeepEval: چارچوبی برای ارزیابی و آزمون برنامه‌های مبتنی بر مدل‌های زبانی.
  • Ragas: ابزارهایی برای ارزیابی سامانه‌های تولید تقویت‌شده با بازیابی اطلاعات و برنامه‌های مبتنی بر LLM.

این ابزارها جایگزین طراحی آزمون مناسب نیستند. پیش از انتخاب، نوع مدل، سازگاری چارچوب، روش ارزیابی، هزینه اجرا و نیاز به بازبینی انسانی را بررسی کنید. معیارهای آماده نیز ممکن است با شرایط واقعی پروژه شما تطابق کامل نداشته باشند.

پرسش‌های متداول درباره ارزیابی کیفیت LLM

مهم‌ترین معیار ارزیابی مدل زبانی بزرگ چیست؟

معیار اصلی به نوع کاربرد بستگی دارد. برای پاسخ‌گویی تخصصی، دقت و پشتیبانی از منابع اهمیت زیادی دارد؛ برای طبقه‌بندی، Precision و Recall می‌توانند مناسب باشند؛ و برای تولید محتوا، ارتباط، کامل‌بودن و رعایت دستورها نیز اهمیت دارند.

آیا می‌توان کیفیت LLM را فقط با یک امتیاز سنجید؟

معمولاً خیر. یک امتیاز کلی ممکن است تفاوت میان انواع خطا را پنهان کند. بهتر است چند معیار متناسب با وظیفه را جداگانه گزارش کنید و خطاهای حساس را مستقل از میانگین امتیازها بررسی کنید.

آیا پاسخ روان نشانه پاسخ صحیح است؟

خیر. مدل ممکن است اطلاعات نادرست را با زبانی روان و مطمئن ارائه کند. صحت ادعاها باید با پاسخ مرجع یا منابع معتبر بررسی شود.

ارزیابی انسانی بهتر است یا خودکار؟

هیچ‌کدام در همه شرایط بهترین نیستند. ارزیابی خودکار برای آزمون‌های تکراری و معیارهای مشخص مناسب است؛ ارزیابی انسانی نیز در سنجش معنا، ظرافت زبان و پیامدهای کاربردی اهمیت دارد. ترکیب این دو معمولاً رویکرد مناسب‌تری است.

چند نمونه برای ارزیابی یک مدل کافی است؟

عدد ثابتی برای همه پروژه‌ها وجود ندارد. تعداد نمونه‌ها باید با تنوع ورودی‌ها، پیچیدگی وظیفه و ریسک خطا متناسب باشد. در کاربردهای حساس، آزمون‌های گسترده‌تر و نمونه‌های مرزی ضروری‌اند.

آیا مدل می‌تواند خودش کیفیت پاسخ خود را ارزیابی کند؟

می‌توان از مدل خواست پاسخ خود را بررسی کند، محدودیت‌ها را مشخص کند یا موارد مشکوک را فهرست کند؛ اما این کار تضمین‌کننده صحت نیست. برای ارزیابی قابل‌اعتماد، از منابع مستقل، پاسخ مرجع یا ارزیاب‌های اعتبارسنجی‌شده استفاده کنید.

چگونه بفهمیم نسخه جدید مدل بهتر است؟

نسخه جدید را با همان مجموعه آزمون، معیارها و تنظیمات قابل‌مقایسه ارزیابی کنید. علاوه بر میانگین عملکرد، نوع خطاها، هزینه، سرعت و اثر تغییر بر وظایف حساس را نیز بررسی کنید.

جمع‌بندی

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

برای ارزیابی مؤثر، ابتدا هدف کاربرد را مشخص کنید، مجموعه آزمون متناسب بسازید، معیارهای روشن تعیین کنید و خروجی‌ها را با منابع معتبر یا پاسخ‌های مرجع مقایسه کنید. سپس خطاها را دسته‌بندی کرده و پس از هر اصلاح، آزمون را تکرار کنید.

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