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

مقدمه

یکی از مشکلات مشترکی که تقریباً در تمام حوزه‌های هوش مصنوعی مولد (generative AI) مشاهده می‌شود، ارزیابی صحیح آن‌هاست. روش اندازه‌گیری کیفیت نتایج آن کاملاً متفاوت از نحوه اندازه‌گیری مسائل رگرسیون کلاسیک یا پیش‌بینی و طبقه‌بندی است. ارزیابی متن، یا تصاویر نیز کاملاً متفاوت است.

در متن می‌توانیم راه‌های مختلفی برای بیان یک‌چیز پیدا کنیم، و اینکه آیا یکی صحیح‌تر از دیگری است ممکن است بیشتر به محیطی که متن در آن استفاده خواهد شد بستگی داشته باشد تا به شکل خود متن. این نوع وظایف، که در آن‌ها پاسخ یکتا و مشخصی وجود ندارد، «وظایف پایان-باز» (Open-ended tasks) نامیده می‌شوند. در مقابل، «وظایف پایان-بسته» (Closed-ended tasks) مانند طبقه‌بندی احساسات یا تشخیص موجودیت نامدار، پاسخ‌های معین و محدودی دارند و ارزیابی آن‌ها با متریک‌های استاندارد یادگیری ماشین (دقت، صحت، F1 و غیره) انجام‌پذیر است.

از سوی دیگر، ما نه‌تنها باید شکل آن متن را ارزیابی کنیم، بلکه باید تشخیص دهیم که آیا مدل، متن را بر اساس داده‌های واقعی تولید می‌کند، یا برعکس، تصمیم گرفته است از تخیل خود استفاده کند و متن را به روشی که فکر می‌کند بهترین است، تکمیل کند و داده‌ها را جعل کرده و از توهمات (hallucinations) خود استفاده کند. البته همیشه این‌ها بد نیستند و بستگی به ویژگی‌های پروژه ما دارد، مثلاً اگر مدل به‌عنوان پشتیبان برای یک نویسنده داستان استفاده شود، واضح است که در برخی لحظات، ممکن است لازم باشد پاسخ‌های کاملاً تخیلی ارائه دهد.

به این موضوع باید اضافه کنیم که هیچ راه روشنی برای دانستن اینکه چرا یک مدل در نهایت یک پاسخ تولید می‌کند وجود ندارد، بنابراین لازم است کنترل بر روی آنچه به هر یک از promptها پاسخ می‌دهد حفظ شود، یعنی قابلیت ردیابی (traceability) پاسخ‌های مدل حفظ شود، زیرا چه بخواهید چه نخواهید، در برخی از نقاط پروژه، باید تجزیه‌وتحلیل شوند.

ارزیابی در مراحل مختلف توسعه مدل اهمیت دارد: در حین آموزش (برای بهینه‌سازی تابع زیان)، توسعه (تنظیم هایپرپارامترها، توقف زودهنگام)، انتخاب مدل (کدام مدل برای کار من بهترین است؟)، استقرار (آیا مدل به اندازه کافی خوب است؟) و حتی انتشار علمی (برای مقایسه با کارهای دیگران). نیازهای ارزیابی در هر مرحله متفاوت است؛ مثلاً در آموزش، سرعت و قابلیت مشتق‌پذیری مهم است، درحالی‌که در استقرار، قابل اعتماد بودن و مرتبط بودن با وظیفه اهمیت بیشتری دارد.

در ابتدا با بررسی دو معیار کلاسیک برای ارزیابی مدل‌های زبان بزرگ شروع می‌کنیم: ROUGE و BLEU. هر دو بر اساس مفهومی به نام N-Grams هستند.

BLEU، ROUGE و N-Grams

BLEU و ROUGE دو مورد از کلاسیک‌ترین معیارها برای ارزیابی نتایج مدل‌های زبان هستند.

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

معیارROUGE نیز تکاملی از BLEU است که برای اندازه‌گیری کیفیت خلاصه‌های ایجادشده توسط یک مدل زبانی تطبیق داده شده است. مانند BLEU، بر اساس مقایسه N-grams است.

اگر نمی‌دانید N-Grams چیست بیایید کوتاه توضیح دهیم:

N-Grams

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

برای مثال، جمله زیر را در نظر بگیرید: «گربه آرام می‌خوابد.» (The cat sleeps quietly)

اگر با 1-gram (unigram) کار کنیم، از هر کلمه به‌طور جداگانه استفاده خواهیم کرد («گربه»، «آرام»، «می‌خوابد»)، درحالی‌که اگر از 2-gram (bigram) استفاده کنیم، هر جفت کلمه را در نظر می‌گیریم: «گربه آرام»، «آرام می‌خوابد.»

معیارهای مبتنی بر N-gram معمولاً n-gramهای جمله تولیدشده را با n-gramهای یک متن مرجع مقایسه می‌کنند و نشان می‌دهند که آیا تفاوت زیاد، کم یا هیچ تفاوتی بین متن تولیدشده و متن مرجع وجود دارد.

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

اندازه‌گیری کیفیت ترجمه با BLEU

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

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

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

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

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

با نتایج به‌دست‌آمده با استفاده از BLEU، می‌توانیم تصمیم بگیریم که کدام سیستم ترجمه به بهترین وجه با نیازهای پروژه مطابقت دارد.

مثل همیشه، بهتر است این را با کمی کد و یک مثال ببینیم.

کد زیر در Github را مشاهده کنید:

https://github.com/Alireza-Akhavan/LLM/blob/main/03_bleu_score.ipynb

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

from nltk.translate.bleu_score import sentence_bleu

reference = ["من از این که یک فنجان  قهوه گرم مینوشم خوشحال هستم.".split()]
generated = "من از این که قهوه مینوشم خوشحال هستم.".split()

# Compute BLEU score
bleu_score = sentence_bleu(reference, generated)
bleu_score

 

کد بالا مقدار حدود 0.35 بر می‌گرداند، در حالی که جمله تولید شده اگر کلمات بیشتری از جمله معیار را داشته باشد این معیار بالاتر برمیگرداند، مثلا:

reference = ["من از این که یک فنجان  قهوه گرم مینوشم خوشحال هستم.".split()]
generated = "من از این که یک فنجان قهوه مینوشم خوشحال هستم.".split()

# Compute BLEU score
bleu_score = sentence_bleu(reference, generated)
bleu_score

کد بالا حدود 0.71 بر میگرداند، چرا که به «یک فنجان» نیز اشاره شده است. اما هنوز معیار 1 نیست که در این جمله به دلیل نبودن صفت «گرم» است که در جمله معیار وجود داشته ولی در ترجمه ما نیست!

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

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

در برخی از پیاده سازی ها، BLEU فقط یک عدد برنمی‌گرداند. درست است که اولین معیار ارائه‌شده با عنوان ‘bleu’ برچسب‌گذاری شده و به‌عنوان یک شاخص کلی از کیفیت ترجمه عمل می‌کند. بااین‌حال، با مقادیر بسیار دیگری همراه است که باید تفسیر شوند.

• BLEU: مقداری بین ۰ و ۱ برگردانده می‌شود. هرچه این مقدار به ۱ نزدیک‌تر باشد، ترجمه بهتر است. مقداری که با ترجمه‌ اول به دست آوردیم زیر ۰.۵ هستند. این ممکن است ما را به این فکر وادارد که ترجمه‌های بی‌کیفیتی هستند، مقداری بین ۰.۳ و ۰.۴، اگرچه کامل نیست، اما نمی‌توان آن را بد در نظر گرفت؛ معنا را حفظ می‌کند و قابل‌فهم است. اگر مقدار BLEU بین ۰.۴ و ۰.۵ باشد، یک ترجمه بسیار خوب در نظر گرفته می‌شود. مقادیر بالای ۰.۶ به‌ندرت دیده می‌شوند، حتی در مترجمان انسانی.
• Precisions: دقت (Precision) تعداد n-gramهای یکسان یافت شده بین ترجمه در حال ارزیابی و ترجمه مرجع را ارزیابی می‌کند. همان‌طور که می‌بینید، چهار مقدار دقت برمی‌گرداند که مربوط به 1-gram، 2-gram، 3-gram و 4-gram است. طبیعتاً، با افزایش اندازه n-gram، مقدار دقت کاهش می‌یابد.
• Brevity_penalty: جریمه اختصار (brevity penalty) عمدتاً یک ضریب داخلی است که بر امتیاز کلی BLEU تأثیر می‌گذارد و ترجمه‌هایی را که حاوی کلمات کمتری نسبت به متن مرجع هستند، جریمه می‌کند. مقادیر ۱ یا بالاتر نشان می‌دهد که متن ترجمه‌شده حاوی کلمات بیشتری نسبت به متن مرجع است.
• Length_ratio: رابطه بین طول متن تولیدشده و متون مرجع را نشان می‌دهد. هرچه به ۱ نزدیک‌تر باشد، طول متون مشابه تر است. با استفاده از translation_length و reference_length محاسبه می‌شود.

مهم‌ترین تفاوت در نحوه کاهش دقت با افزایش اندازه n-gram نهفته است.

اندازه‌گیری کیفیت خلاصه با ROUGE

ROUGE (Recall-Oriented Understudy for Gisting Evaluation) معیاری است که مشابه BLEU عمل می‌کند. مجموعه‌ای از اعداد را برمی‌گرداند که به ما امکان می‌دهد کیفیت یک متن تولیدشده را با یک متن مرجع مقایسه کنیم.

به‌عنوان تکاملی از BLEU، کاربردهای آن گسترده‌تر است: ترجمه‌ها، خلاصه‌ها یا استخراج موجودیت‌ها (entity extractions) چند نمونه هستند. عمدتاً برای بررسی کیفیت خلاصه‌ها استفاده می‌شود، که مثالی است که در ادامه خواهید دید. بااین‌حال، ازآنجاکه بر انجام مقایسه‌ها با یک متن مرجع با استفاده از n-gram تمرکز دارد، برای استخراج موجودیت نیز به‌خوبی کار می‌کند.

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

من یک مثال کوچک ارائه می‌دهم، زیرا معتقدم می‌تواند به روشن شدن این توضیح کمک کند:

فرض کنید ما یک مجموعه داده با داستان‌های کوتاه یا مقالات خبری داریم و می‌خواهیم مدلی ایجاد کنیم که بتواند تمام شهرهای ذکرشده در هر یک از داستان‌ها را استخراج کند.

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

['ما شب به پاریس رسیدیم؛ سفر طولانی بود. از شهر کوچکی به نام رئوس حرکت کردیم، جایی که دوستانمان ما را سوار کردند و توانستیم بدون اینکه کسی ما را ببیند به بارسلونا برسیم. با مدارک جعلی و نام‌های جدیدمان، سوار قطاری شدیم که به سمت پاریس می‌رفت. اکنون در امان هستیم، اما باید هر چه زودتر به لندن برسیم.']

در این متن کوتاه، چهار شهر اروپایی ذکر شده است: پاریس، بارسلونا، لندن و رئوس. بنابراین، متن مرجع ما برای آن باید این باشد:

['پاریس، بارسلونا، رئوس، لندن']

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

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

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

{'rouge1': 1.0, 'rouge2': 0.66, 'rougeL': 0.75, 'rougeLsum': 0.75}

بیایید ببینیم اگر همه شهرها دقیقاً به همان ترتیبی که در متن مرجع ظاهر می‌شوند، مکان‌یابی شوند، نتیجه چه خواهد بود:

{'rouge1': 1.0, 'rouge2': 1.0, 'rougeL': 1.0, 'rougeLsum': 1.0}

همان‌طور که می‌بینید، درست مانند BLEU، ROUGE یک معیار ترکیبی است. قبل از ادامه با مثال استفاده، فکر می‌کنم زمان آن رسیده است که توضیح مختصری در مورد معنای هر یک از اعدادی که معیار ROUGE را تشکیل می‌دهند، ارائه دهم.

• ROUGE-1: این نشان‌دهنده تطابق بین متن تولیدشده و متن مرجع با استفاده از 1-gram یا کلمات منفرد (recall محور) است.
• ROUGE-2: همانند ROUGE-1 است، اما مجموعه‌هایی از 2-gram را در نظر می‌گیرد.
• ROUGE-L: این معیار تطابق طولانی‌ترین زیردنباله مشترک (Longest Common Subsequence – LCS) کلمات بین دو متن را ارزیابی می‌کند. کلمات نیازی به ترتیب دقیق یکسان ندارند.
• ROUGE-Lsum: مشابه ROUGE-L است اما در سطح خلاصه (summary-level) عمل می‌کند و LCS را در سطح جملات جداگانه در نظر می‌گیرد.

می‌توانید اطلاعات بیشتری در https://pypi.org/project/rouge-score/ پیدا کنید. اما مطمئناً قبلاً متوجه شده‌اید که عملکرد آن بسیار شبیه به BLEU است؛ بااین‌حال، این نیز معیاری است که مبتنی بر n-gram است. درهرصورت، همیشه باید به یاد داشته باشید که، مانند BLEU، قابلیت اطمینان ROUGE به کیفیت متن مرجع مورداستفاده بستگی دارد.

مایلم نگاهی به مقادیر ارائه‌شده در مثال کوچکی که قبلاً دیدید بیندازید، که در آن معیارهای بازگشتی توسط Rouge را هنگام جستجوی موجودیت‌ها در یک متن کوچک مقایسه کردم. Rouge1 در هر دو مورد مقدار ۱ را به دست آورد که نشان می‌دهد متن ارزیابی‌شده از همان کلمات متن مرجع تشکیل شده است. بااین‌حال، در مورد اول، که در آن کلمات به همان ترتیب شناسایی نشدند، مقادیر rouge2، rougeL و rougeLsum کمتر از ۱ هستند، درحالی‌که در مورد دوم، هنگامی‌که کلمات به همان ترتیب مقایسه شدند، تمام مقادیر به‌عنوان ۱ گزارش می‌شوند.

در مورد مثال، ما فقط باید روی rouge1 تمرکز کنیم، زیرا ترتیب کلمات مهم نیست، چون یک مسئله تشخیص موجودیت است. از سوی دیگر، برای ارزیابی کیفیت خلاصه‌ها، باید به هر یک از مقادیر بازگشتی توجه کنید.

پس از این معرفی به ROUGE، اکنون زمان آن است که از آن برای آنچه واقعاً برای آن در نظر گرفته شده بود استفاده کنیم: ارزیابی خلاصه‌ها.

نکات کلیدی و مطالب بیشتر برای یادگیری (متریک‌های کلاسیک)

در این بخش، با دو مورد از کلاسیک‌ترین معیارها در NLP (پردازش زبان طبیعی) آشنا شدید. یاد گرفتید که n-gram چیست و چگونه با این تکنیک‌ها برای انجام ارزیابی‌ها استفاده می‌شود.

یکی از معایب بزرگ متریک‌های مبتنی بر همپوشانی کلمات (مانند BLEU و ROUGE) این است که به ارتباط معنایی بین کلمات توجه نمی‌کنند. برای مثال، اگر پاسخ مرجع “heck yes” باشد، مدل ممکن است “yes” (امتیاز BLEU نسبتاً خوب)، “you know it” (امتیاز پایین‌تر) یا “yep” (امتیاز صفر) تولید کند، درحالی‌که هر سه معنای مشابهی دارند. همچنین ممکن است “heck no” امتیاز بالایی بگیرد ولی معنای کاملاً متفاوتی داشته باشد (مثبت کاذب).

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

خبر خوب این است که به دست آوردن معیارهایی مانند BLEU یا ROUGE بسیار آسان است، که می‌تواند به ما در فرآیند تصمیم‌گیری کمک کند و قضاوت‌های بهتری در مورد مدل داشته باشیم.

پس از این معیارهای کلاسیک، زمان آن رسیده است که برخی از ابزارهای مدرن‌تر را ببینیم. در بخش بعدی، با یک ابزار ردیابی مدل زبان آشنا خواهید شد: LangSmith، از سازندگان LangChain.

ارزیابی و ردیابی با LangSmith

LangSmith جدیدترین محصول تیم LangChain است و به‌عنوان یک پلتفرم کامل DevOps برای راه‌حل‌های مبتنی بر مدل‌های زبان بزرگ طراحی شده است. ازجمله ویژگی‌های آن، می‌توان از آن به‌عنوان یک ابزار ردیابی برای راه‌حل‌های ایجادشده با مدل‌های زبان بزرگ استفاده کرد.

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

این مشکل به‌ویژه در راه‌حل‌های مبتنی بر فراخوانی API به مدل‌هایی مانند OpenAI بارز است، جایی که حتی یک بازبینی جزئی از مدل می‌تواند پاسخ‌های آن را تغییر دهد و راه‌حل ما را مختل کند.

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

پاسخ‌های غیرمنتظره هنوز هم می‌توانند به دلیل تغییرات کوچک در prompt یا داده‌های محیطی، مانند داده‌های به‌دست‌آمده در یک سیستم RAG، رخ دهند.

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

در این بخش، ما فقط بخش کوچکی از آنچه LangSmith ارائه می‌دهد را پوشش خواهیم داد، زیرا برای پوشش کل چرخه عمر یک راه‌حل مبتنی بر مدل‌های زبان بزرگ طراحی شده و یک راه‌حل کامل DevOps ارائه می‌دهد.

دو مثال کوچک خواهید دید. در مثال اول، به ارزیابی خلاصه‌ها ادامه خواهید داد اما از فاصله embedding به‌عنوان معیار، با پشتیبانی LangSmith استفاده خواهید کرد. این رویکرد، نوعی “متریک مبتنی بر مدل” (Model-based metric) است که سعی می‌کند با استفاده از نمایش‌های یادگرفته شده (embeddings) شباهت معنایی را بهتر از متریک‌های مبتنی بر همپوشانی کلمات، ارزیابی کند. در مثال دوم، یک سیستم مبتنی بر agent ایجاد خواهید کرد و از LangSmith برای ردیابی هر آنچه بین ورودی کاربر و پاسخ مدل رخ می‌دهد استفاده خواهید کرد. این به شما درک بهتری از نحوه استفاده از LangSmith برای ارزیابی و ردیابی در سناریوهای مختلف می‌دهد.

ارزیابی خلاصه‌های LLM با استفاده از فاصله Embedding با LangSmith

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

این بار، از فاصله کسینوسی (cosine distance) بین embeddings برای شناسایی اینکه کدام خلاصه بیشترین شباهت را به نسخه اصلی دارد، استفاده خواهید کرد. سایر متریک‌های مبتنی بر مدل که از embeddings استفاده می‌کنند شامل **BERTScore** (که از embeddings حاصل از BERT برای مقایسه کلمات در متن تولید شده و مرجع استفاده می‌کند) و **BLURT** (که یک مدل BERT را برای پیش‌بینی امتیازات کیفیت بر اساس داده‌های ارزیابی انسانی آموزش می‌دهد) هستند.

تفاوت‌های بین استفاده از یک روش مبتنی بر embedding و یک روش مبتنی بر n-gram چیست؟ میدانیم که یک embedding چیزی جز یک بردار نیست که سعی می‌کند معنای معنایی متن تبدیل‌شده را ثبت کند. ازآنجاکه بردارها چیزی جز ارقام عددی نیستند، می‌توان عملیاتی را با آن‌ها انجام داد، و یکی از این عملیات محاسبه فاصله بین آن‌هاست.

برای محاسبه فاصله بین embeddings، Langsmith به‌طور پیش‌فرض از فاصله کسینوسی استفاده می‌کند. این معیار می‌تواند مقداری بین ۰ و ۲ بگیرد. هرچه embeddings به هم نزدیک‌تر باشند، مقدار به ۰ نزدیک‌تر خواهد بود (شباهت بیشتر).

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

یک مثال ساده برای ارزیابی فاصله embedding با LangSmith (به صورت مفهومی):

from langsmith import Client
from langsmith.evaluation import evaluate
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain.evaluation import load_evaluator

# Initialize LangSmith client
# client = Client() # Requires API key setup

# Example data
reference_summary = "این یک خلاصه مرجع دقیق و کامل از متن اصلی است."
generated_summary_good = "این خلاصه تولید شده بسیار شبیه به متن مرجع است و نکات کلیدی را پوشش می‌دهد."
generated_summary_bad = "این یک متن کاملا نامرتبط است و هیچ شباهتی به خلاصه اصلی ندارد."

# Conceptual evaluation setup
# In a real LangSmith setup, you'd define datasets and evaluators.
# Here's a simplified local equivalent using LangChain's evaluators for illustration.

# Load the embedding distance evaluator
embedding_evaluator = load_evaluator("embedding_distance")

# Evaluate good summary
result_good = embedding_evaluator.evaluate_strings(
    prediction=generated_summary_good,
    reference=reference_summary,
)
print(f"Embedding distance for good summary: {result_good['score']}") # Expect a low score

# Evaluate bad summary
result_bad = embedding_evaluator.evaluate_strings(
    prediction=generated_summary_bad,
    reference=reference_summary,
)
print(f"Embedding distance for bad summary: {result_bad['score']}") # Expect a higher score

# To integrate with LangSmith for tracing and dataset evaluation:
# 1. Create a dataset in LangSmith with inputs and reference outputs.
# 2. Define an evaluation run using evaluators like 'embedding_distance'.
#    LangSmith will run your model on the dataset inputs and compare
#    predictions to references using the specified evaluator.

نکته مهم در مورد متریک‌های مبتنی بر مدل (مانند فاصله embedding، BERTScore، BLURT) و حتی متریک‌های کلاسیک (BLEU, ROUGE) این است که کیفیت آن‌ها به شدت به کیفیت متون مرجع بستگی دارد. اگر متون مرجع ضعیف باشند، امتیازات این متریک‌ها نیز گمراه‌کننده خواهند بود.

ارزیابی انسانی (Human Evaluation)

همانطور که دیدیم، متریک‌های خودکار مانند BLEU، ROUGE، یا حتی متریک‌های مبتنی بر embedding، دارای محدودیت‌هایی هستند. آن‌ها نمی‌توانند تمام جنبه‌های کیفیت متن مانند روان بودن، انسجام، خلاقیت، یا صحت واقعی اطلاعات را به طور کامل درک کنند. به همین دلیل، **ارزیابی انسانی** اغلب به عنوان **استاندارد طلایی (gold standard)** برای وظایف پایان-باز در نظر گرفته می‌شود.

در ارزیابی انسانی، از افراد خواسته می‌شود تا کیفیت متن تولید شده توسط مدل را بر اساس معیارهای مختلف (مانند روان بودن، انسجام، مفید بودن، دقت، سبک و غیره) ارزیابی کنند. این ارزیابی می‌تواند به صورت نمره‌دهی (مثلاً در مقیاس لیکرت ۱ تا ۵) یا مقایسه زوجی (انتخاب گزینه بهتر بین دو خروجی مدل) باشد.

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

چالش‌های ارزیابی انسانی

با وجود اینکه ارزیابی انسانی استاندارد طلایی است، چالش‌های قابل توجهی دارد:

• کند و پرهزینه بودن: ارزیابی توسط انسان‌ها زمان‌بر است و اگر نیاز به استخدام ارزیاب‌های متخصص یا پرداخت به پلتفرم‌های众包 (crowdsourcing) باشد، هزینه بالایی دارد.
• عدم توافق بین ارزیاب‌ها (Inter-annotator disagreement): افراد مختلف ممکن است در مورد کیفیت یک متن نظرات متفاوتی داشته باشند، حتی اگر دستورالعمل‌های دقیقی به آن‌ها داده شود. برای مثال، در پروژه AlpacaFarm، حتی محققانی که ساعت‌ها در مورد دستورالعمل‌ها بحث کرده بودند، تنها در حدود ۶۷٪ موارد با یکدیگر هم‌نظر بودند (در حالی که ۵۰٪ توافق تصادفی است).
• عدم توافق درون ارزیاب (Intra-annotator disagreement): یک ارزیاب ممکن است در زمان‌های مختلف، ارزیابی‌های متفاوتی از یک متن ارائه دهد (بسته به خستگی، خلق‌وخو و غیره).
• عدم تکرارپذیری: به دلیل موارد بالا و تفاوت در تنظیمات آزمایش (مانند دستورالعمل‌ها، رابط کاربری، انتخاب ارزیاب‌ها)، نتایج ارزیابی انسانی اغلب به سختی قابل تکرار هستند. یک مطالعه نشان داد که تنها حدود ۵٪ از ارزیابی‌های انسانی در مقالات NLP به طور کامل قابل تکرار بودند.
• تمرکز بر دقت (Precision) و نه بازیابی (Recall): ارزیاب‌ها معمولاً تنها خروجی ارائه شده توسط مدل را می‌بینند و نمی‌توانند تمام پاسخ‌های خوبِ ممکن دیگر را که مدل می‌توانست تولید کند، ارزیابی کنند.
• عدم همسویی انگیزه‌ها: در پلتفرم‌های众包، ارزیاب‌ها ممکن است برای به حداکثر رساندن درآمد خود در ساعت، کار را با سرعت و دقت کمتری انجام دهند. این می‌تواند منجر به سوگیری‌هایی شود، مانند ترجیح پاسخ‌های طولانی‌تر صرف‌نظر از کیفیت واقعی آن‌ها.
• پیچیدگی در طراحی و اجرا: تعریف دقیق وظیفه، نوشتن دستورالعمل‌های (rubrics) واضح، طراحی رابط کاربری مناسب، انتخاب، آموزش و نظارت بر ارزیاب‌ها، همگی فرآیندهای پیچیده‌ای هستند.

ارزیابی بدون مرجع (LLM به عنوان داور)

با توجه به چالش‌های ارزیابی انسانی، به خصوص هزینه و زمان، جامعه پژوهشی به دنبال جایگزین‌های سریع‌تر و ارزان‌تر بوده است. یکی از رویکردهای نوظهور و امیدوارکننده، استفاده از خود مدل‌های زبانی بزرگ (LLMها) به عنوان داور برای ارزیابی خروجی مدل‌های دیگر است. این روش، **ارزیابی بدون مرجع (Reference-free evaluation)** نامیده می‌شود، زیرا برخلاف BLEU/ROUGE یا حتی برخی روش‌های مبتنی بر embedding، نیازی به متن مرجع نوشته شده توسط انسان ندارد.

ایده اصلی این است که یک LLM قدرتمند (مانند GPT-4) می‌تواند کیفیت، انسجام، یا مفید بودن یک متن تولید شده را، مشابه یک انسان، قضاوت کند. به LLM داور، دستورالعمل (prompt) داده می‌شود که چگونه ارزیابی را انجام دهد، به همراه خروجی مدلی که باید ارزیابی شود (و گاهی اوقات ورودی اصلی که منجر به آن خروجی شده است).

مثال: AlpacaEval

یکی از بنچمارک‌های شناخته‌شده در این زمینه **AlpacaEval** است. در AlpacaEval:

1. یک دستورالعمل (مثلاً “یک داستان کوتاه در مورد یک ربات بنویس”) به دو مدل مختلف (مدل A و مدل B که می‌خواهیم مقایسه کنیم) داده می‌شود.
2. خروجی‌های هر دو مدل جمع‌آوری می‌شوند.
3. این دو خروجی به یک LLM داور قدرتمند (مانند GPT-4) ارائه می‌شوند و از آن خواسته می‌شود که بگوید کدام خروجی بهتر است یا به هر کدام امتیاز دهد.
4. این فرآیند برای مجموعه‌ای از دستورالعمل‌ها تکرار می‌شود و در نهایت یک نرخ برد (win rate) برای هر مدل محاسبه می‌شود.

مطالعات نشان داده‌اند که ارزیابی توسط LLMهای قدرتمند می‌تواند به طرز شگفت‌آوری با قضاوت‌های agregat انسانی همبستگی بالایی داشته باشد (گاهی حتی بیشتر از همبستگی بین دو انسان منفرد!). این به این دلیل است که LLMهای داور، گرچه ممکن است سوگیری‌هایی داشته باشند، اما در قضاوت خود بسیار **سازگار (consistent)** هستند (واریانس پایین)، در حالی که انسان‌ها واریانس بیشتری در قضاوت‌های خود نشان می‌دهند. استفاده از LLM به عنوان داور می‌تواند تا ۱۰۰ برابر سریع‌تر و ارزان‌تر از ارزیابی انسانی باشد.

ملاحظات در استفاده از LLM به عنوان داور

با وجود مزایا، استفاده از LLM به عنوان داور نیز بدون چالش نیست:

• سوگیری‌های ذاتی LLM داور: LLM داور ممکن است سوگیری‌های خاصی داشته باشد که از داده‌های آموزشی آن ناشی می‌شود. برای مثال، ممکن است پاسخ‌های طولانی‌تر یا پاسخ‌هایی با سبک نوشتاری خاص را ترجیح دهد.
• سوگیری موقعیت (Positional Bias): LLM داور ممکن است به طور سیستماتیک خروجی اول یا دوم را ترجیح دهد. این مشکل را می‌توان با تصادفی کردن ترتیب ارائه خروجی‌ها کاهش داد.
• سوگیری به نفع خود (Self-bias): اگر LLM داور، خود یکی از مدل‌هایی باشد که در حال ارزیابی است (یا از همان خانواده باشد)، ممکن است به طور نامنصفانه‌ای خروجی‌های خود را ترجیح دهد. اگرچه این سوگیری مشاهده شده، اما همیشه به اندازه‌ای نیست که رتبه‌بندی کلی را به هم بریزد.
• حساسیت به Prompt: نحوه نگارش prompt برای LLM داور می‌تواند تأثیر قابل توجهی بر نتایج ارزیابی داشته باشد. تغییرات کوچک در prompt می‌تواند منجر به تغییر در رتبه‌بندی مدل‌ها شود. در AlpacaEval، برای مقابله با سوگیری طول، از روش‌های باز-وزن‌دهی (re-weighting) استفاده شد.
• فقدان درک عمیق: LLMها هنوز ممکن است در درک ظرایف پیچیده، استدلال‌های چند مرحله‌ای یا بررسی صحت واقعی اطلاعات (fact-checking) به اندازه انسان‌ها توانمند نباشند.

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

روش‌های رایج فعلی برای ارزیابی LLM‌ها

در حال حاضر، ارزیابی مدل‌های زبانی بزرگ (LLMها) معمولاً ترکیبی از رویکردهای مختلف است:

Perplexity (حیرت)

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

• کاربرد: اغلب در طول پیش‌آموزش (pre-training) مدل‌ها برای نظارت بر پیشرفت یادگیری استفاده می‌شود. همچنین مشاهده شده است که Perplexity با عملکرد در وظایف پایین‌دستی (downstream tasks) همبستگی دارد.
• محدودیت‌ها: مقادیر Perplexity بین مجموعه داده‌های مختلف یا توکنایزرهای مختلف قابل مقایسه نیستند. همچنین، Perplexity به تنهایی نمی‌تواند کیفیت تولید متن در وظایف خاص مانند خلاصه‌سازی یا پاسخ به سوال را ارزیابی کند.

بنچمارک‌های چند وظیفه‌ای (Multi-task Benchmarks)

این بنچمارک‌ها مدل‌ها را بر روی طیف وسیعی از وظایف NLP ارزیابی می‌کنند و معمولاً یک امتیاز میانگین کلی ارائه می‌دهند. هدف، سنجش قابلیت‌های عمومی زبان مدل است.

• نمونه‌ها:
  • SuperGLUE: یکی از بنچمارک‌های قدیمی‌تر و چالش‌برانگیز شامل وظایفی مانند پاسخ به سوال، استنتاج و درک مطلب.
  • MMLU (Massive Multitask Language Understanding): یکی از محبوب‌ترین بنچمارک‌های فعلی که شامل ۵۷ وظیفه چند گزینه‌ای در حوزه‌هایی مانند علوم انسانی، علوم اجتماعی، STEM و غیره است. این بنچمارک به دلیل پوشش گسترده موضوعات، به شدت مورد توجه قرار گرفته است (حتی مارک زاکربرگ نیز به امتیاز Llama 3 در MMLU اشاره کرد).
  • Helm (Holistic Evaluation of Language Models): یک تلاش جامع برای ارزیابی مدل‌ها بر اساس طیف وسیعی از سناریوها و متریک‌ها، از جمله دقت، استحکام، عدالت، و کارایی.
  • Hugging Face Open LLM Leaderboard: یک پلتفرم عمومی که مدل‌های متن‌باز را بر روی مجموعه‌ای از بنچمارک‌ها ارزیابی و رتبه‌بندی می‌کند.
• وظایف رایج دیگر در این بنچمارک‌ها:
  • کدنویسی: بنچمارک‌هایی مانند HumanEval یا MBPP که توانایی مدل در تولید کد را بر اساس توضیحات متنی ارزیابی می‌کنند. ارزیابی معمولاً با اجرای تست‌های واحد (unit tests) انجام می‌شود. عملکرد خوب در کدنویسی اغلب با توانایی استدلال بهتر همبستگی دارد.
  • ریاضیات: بنچمارک‌هایی مانند GSM8K (سوالات ریاضی دوران دبستان) که توانایی حل مسائل ریاضی را می‌سنجند.
  • ارزیابی Agentها: یک حوزه نوظهور که توانایی LLMها در استفاده از ابزارها، فراخوانی APIها و انجام وظایف در محیط‌های شبیه‌سازی شده (sandbox environments) را ارزیابی می‌کند. این ارزیابی‌ها به دلیل نیاز به محیط‌های امن و پیچیدگی تعاملات، چالش‌برانگیز هستند.

ارزیابی به سبک آرنا (Arena-Style)

در این روش، خروجی‌های دو مدل به صورت ناشناس در کنار هم به یک داور (انسان یا LLM) ارائه می‌شوند و داور انتخاب می‌کند کدام خروجی بهتر است.

• نمونه: Chatbot Arena: یک پلتفرم عمومی که به کاربران اجازه می‌دهد با دو مدل ناشناس چت کنند و سپس به پاسخ بهتر رأی دهند. با جمع‌آوری تعداد زیادی رأی، یک رتبه‌بندی (معمولاً با سیستم ELO مشابه شطرنج) برای مدل‌ها ایجاد می‌شود.
• مزایا: به خوبی می‌تواند ترجیحات کاربران را در وظایف مکالمه‌ای و دنبال کردن دستورالعمل‌ها (instruction following) منعکس کند.
• معایب: برای مدل‌های کمتر شناخته‌شده، جمع‌آوری آرای کافی دشوار است. نتایج می‌تواند تحت تأثیر نوع سوالات پرسیده شده توسط کاربران تصادفی قرار گیرد. برای ارزیابی انسانی در مقیاس بزرگ، هزینه و تلاش زیادی لازم است.

به طور کلی، ارزیابی مدل‌های پیش‌آموزش‌دیده (pre-trained models) بیشتر بر Perplexity و بنچمارک‌های چند وظیفه‌ای متمرکز است، در حالی که برای مدل‌های تنظیم‌شده (fine-tuned models) برای وظایف خاص (مانند چت‌بات‌ها)، ارزیابی به سبک آرنا و بنچمارک‌های چند وظیفه‌ای اهمیت بیشتری پیدا می‌کنند.

مسائل و چالش‌های ارزیابی‌های فعلی

با وجود پیشرفت‌های قابل توجه در روش‌های ارزیابی LLMها، هنوز چالش‌ها و مسائل متعددی وجود دارد:

مسائل مربوط به سازگاری (Consistency)

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

• مثال MMLU: مشخص شده است که برای بنچمارک MMLU، پیاده‌سازی‌های مختلف (با promptهای متفاوت، روش‌های نمونه‌برداری متفاوت از پاسخ چند گزینه‌ای، یا استفاده از احتمال لگاریتمی به‌جای تولید مستقیم توکن گزینه) می‌توانند به امتیازات کاملاً متفاوتی برای یک مدل یکسان منجر شوند. برای مثال، امتیاز Llama 65B در MMLU بسته به پیاده‌سازی (Helm، original MMLU، یا harness از Hugging Face) می‌توانست از حدود ۴۸٪ تا ۶۳٪ متغیر باشد.
• تغییر فرمت گزینه‌ها (مثلاً از A, B, C, D به نمادهای تصادفی) نیز می‌تواند عملکرد مدل را تغییر دهد.

آلودگی داده (Contamination)

این یک مشکل جدی است که در آن داده‌های آزمایشی (benchmark data) به نحوی در داده‌های آموزشی مدل وجود داشته‌اند. این امر منجر به امتیازات بیش از حد خوش‌بینانه و غیرواقعی می‌شود.

• مثال‌ها: گزارش‌هایی مبنی بر اینکه GPT-4 در سوالات Codeforces مربوط به قبل از سال ۲۰۲۱ عملکرد عالی داشته اما در سوالات جدیدتر عملکرد ضعیفی داشته است، که به شدت به آلودگی داده اشاره دارد. موارد مشابهی برای مدل‌های دیگر نیز گزارش شده است.
• چالش‌ها: تشخیص آلودگی، به خصوص برای مدل‌های بسته (closed-source) که به داده‌های آموزشی آن‌ها دسترسی نداریم، بسیار دشوار است. حتی با دسترسی به داده‌ها، حجم عظیم داده‌های پیش‌آموزش، بررسی کامل را تقریباً غیرممکن می‌کند.
• راه‌حل‌های بالقوه:
  • استفاده از **مجموعه‌های آزمایشی خصوصی (private test sets)** که به طور عمومی منتشر نشده‌اند (مانند GSM1K که نسخه جدیدی از GSM8K است).
  • **بنچمارک‌های پویا (dynamic benchmarks)** که به طور منظم به‌روز می‌شوند (مانند Chatbot Arena).
  • روش‌هایی برای **تخمین آلودگی**، مانند بررسی احتمال بالای پاسخ‌های خاص توسط مدل، یا بررسی اینکه آیا مدل ترتیب مثال‌ها را در مجموعه آزمایشی “به خاطر سپرده” است (با تغییر ترتیب مثال‌ها و مشاهده افت احتمال لگاریتمی).

بیش‌برازش (Overfitting) به بنچمارک‌ها

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

تک‌فرهنگی (Monoculture) در بنچمارک‌های NLP

یک انتقاد رایج به حوزه ارزیابی NLP، تمرکز بیش از حد بر روی موارد زیر است:

• زبان انگلیسی: یک مطالعه بر روی مقالات کنفرانس ACL 2021 نشان داد که حدود ۷۰٪ مقالات تنها بر روی زبان انگلیسی کار کرده‌اند. با وجود بنچمارک‌های چندزبانه متعدد (مانند XTREME، Belebele، Mega)، هنوز توجه کافی به زبان‌های دیگر نمی‌شود.
• معیار دقت (Accuracy): همان مطالعه نشان داد که حدود ۴۰٪ مقالات تنها از معیار دقت برای ارزیابی استفاده کرده‌اند و جنبه‌های دیگر مانند کارایی، تفسیرپذیری، یا عدالت را نادیده گرفته‌اند.

تقلیل به یک معیار واحد

اغلب، عملکرد مدل‌ها با یک عدد واحد (مثلاً میانگین امتیاز در چند وظیفه) خلاصه می‌شود. این کار می‌تواند نقاط قوت و ضعف خاص مدل را پنهان کند.

• نادیده گرفتن جنبه‌های دیگر: علاوه بر دقت، معیارهای دیگری مانند **کارایی محاسباتی** (سرعت آموزش و استنتاج – بنچمارک MLPerf در این زمینه فعالیت می‌کند)، **استحکام** (robustness) در برابر تغییرات ورودی، و **سوگیری‌ها (biases)** نیز مهم هستند.
• اهمیت نابرابر مثال‌ها: در بسیاری از بنچمارک‌ها، به تمام مثال‌ها وزن یکسانی داده می‌شود، در حالی که در دنیای واقعی، برخی خطاها ممکن است پیامدهای بسیار جدی‌تری نسبت به خطاهای دیگر داشته باشند. همچنین، نیازهای گروه‌های اقلیت ممکن است نادیده گرفته شود.

سوگیری‌ها در ارزیاب‌ها

هم ارزیاب‌های انسانی و هم ارزیاب‌های مبتنی بر LLM می‌توانند سوگیری‌هایی داشته باشند.

• سوگیری در LLMهای داور: LLMهای داور (مانند GPT-4) می‌توانند منعکس‌کننده سوگیری‌های موجود در داده‌های آموزشی خود باشند. مطالعات نشان داده‌اند که نظرات LLMها ممکن است با نظرات گروه‌های جمعیتی خاصی (مثلاً افراد تحصیل‌کرده، یا افرادی از مناطق خاص جغرافیایی که در برچسب‌زنی داده‌های آموزشی نقش داشته‌اند) همسوتر باشد. این امر می‌تواند منجر به تقویت ناخواسته این سوگیری‌ها در مدل‌هایی شود که با استفاده از این داورها ارزیابی و بهبود می‌یابند.
• سوگیری در متریک‌های کلاسیک: متریک‌هایی مانند BLEU و ROUGE بر اساس توکنایزیشن و شمارش کلمات هستند و فرض می‌کنند که تقسیم‌بندی متن به کلمات به راحتی امکان‌پذیر است. این فرض برای زبان‌هایی مانند تایلندی (بدون فاصله بین کلمات) یا ویتنامی (با فاصله‌هایی که همیشه مرز کلمه نیستند) مشکل‌ساز است و نشان می‌دهد که این الگوریتم‌ها عمدتاً برای زبان‌های غربی طراحی شده‌اند.

فقدان انگیزه برای تغییر

شاید بزرگترین چالش این باشد که با وجود آگاهی از محدودیت‌های بنچمارک‌های فعلی (مانند BLEU)، جامعه پژوهشی و داوران مقالات اغلب همچنان بر استفاده از آن‌ها اصرار دارند، عمدتاً به دلیل نیاز به **قابلیت مقایسه** با کارهای قبلی. این امر حرکت به سمت بنچمارک‌ها و روش‌های ارزیابی بهتر را کند می‌کند.

نکات کلیدی نهایی در مورد ارزیابی

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

• نیازهای ارزیابی متفاوت: روش و معیارهای ارزیابی باید متناسب با مرحله توسعه مدل (آموزش، توسعه، انتخاب، استقرار، انتشار) و هدف نهایی انتخاب شوند.
• وظایف پایان-بسته در مقابل پایان-باز: ارزیابی وظایف پایان-بسته (مانند طبقه‌بندی) با متریک‌های استاندارد یادگیری ماشین ساده‌تر است، در حالی که وظایف پایان-باز (مانند تولید متن) به رویکردهای پیچیده‌تری نیاز دارند.
• محدودیت‌های متریک‌های خودکار: متریک‌هایی مانند BLEU، ROUGE، و حتی متریک‌های مبتنی بر embedding، تصویر کاملی از کیفیت ارائه نمی‌دهند و به کیفیت داده‌های مرجع وابسته هستند.
• ارزیابی انسانی به عنوان استاندارد طلایی (با چالش‌های خاص خود): با وجود کندی و هزینه، ارزیابی انسانی همچنان بهترین راه برای سنجش جنبه‌های ظریف کیفیت متن است.
• LLM به عنوان داور، یک جایگزین امیدوارکننده: استفاده از LLMهای قدرتمند برای ارزیابی می‌تواند سریع‌تر و ارزان‌تر باشد، اما باید مراقب سوگیری‌های آن‌ها بود.
• آگاهی از چالش‌ها: مسائلی مانند سازگاری، آلودگی داده، بیش‌برازش، تک‌فرهنگی بودن بنچمارک‌ها، و سوگیری‌ها باید همیشه در نظر گرفته شوند.
• فراتر از یک عدد واحد: به جای تمرکز صرف بر یک امتیاز کلی، به جنبه‌های مختلف عملکرد مدل، از جمله کارایی، استحکام و عدالت توجه کنید.
• مهم‌ترین نکته: خروجی‌های مدل را خودتان بررسی کنید! هرگز به طور کورکورانه به اعداد و امتیازات اعتماد نکنید. درک شهودی از عملکرد مدل در سناریوهای واقعی بسیار ارزشمند است. همانطور که یان کولتون در سخنرانی خود اشاره کرد، گاهی اوقات یک مدل ممکن است در بنچمارک‌های استاندارد عملکرد فوق‌العاده‌ای نداشته باشد، اما در عمل و هنگام تعامل مستقیم، بسیار خوب به نظر برسد (مانند تجربه اولیه با Alpaca).

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

 

منابع:

• Pere Marta – Large Language Models Projects_ Apply and Implement Strategies for Large Language Model (2024, Apress)
• Stanford CS224N: NLP with Deep Learning | Spring 2024 | Lecture 11 – Benchmarking by Yann Dubois