ارزیابی مدل‌های زبانی بزرگ (LLM): بنچمارک‌ها، ارزیابی‌ها (Evals) و تست‌ها

چرا ارزیابی LLMها دشوار است؟

مدل‌های زبانی بزرگ (LLM) برخلاف مدل‌های کلاسیک یادگیری ماشین، خروجی‌های باز و نامحدود تولید می‌کنند. در یک مدل کلاسیک (مثلاً طبقه‌بندی ایمیل به «Spam» یا «Not Spam») می‌توان به‌راحتی معیارهای دقیق مانند دقت، فراخوانی (recall) و دقت مثبت (precision) را محاسبه کرد؛ زیرا خروجی‌ها به‌صورت دو‑کلاسه ثابت هستند.

اما یک LLM می‌تواند در همان سؤال پاسخ‌های متنوعی مانند «Spam»، «Not Spam»، «Promotional»، «Unsubscribe Offer» یا حتی جملات نامرتبط تولید کند. این توهم (hallucination) باعث می‌شود که تعریف دقیق «درست» یا «نادرست» برای یک پیش‌بینی دشوار شود و معیارهای سنتی به‌صورت مبهم یا گمراه‌کننده ظاهر شوند.

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

مقایسهٔ سادهٔ یک مدل کلاسیک و یک LLM

مدل	خروجی‌های ممکن	مشکل اصلی
مدل طبقه‌بندی ایمیل	«Spam» یا «Not Spam»	خروجی ثابت؛ محاسبهٔ دقیق دقت/فراخوانی
LLM برای همان کار	«Spam», «Not Spam», «Promotional», «Unsubscribe Offer», «Questionable» …	چه‌کار کنیم با خروجی‌های خارج از دسته‌بندی؟ آیا به‌عنوان خطا یا به‌عنوان دستهٔ جدید در نظر بگیریم؟

در مثال عددی، اگر توهم‌ها را به‌عنوان خطاهای منفی (False Negatives) یا خطاهای مثبت (False Positives) در نظر بگیریم، معیارهای دقت و فراخوانی به‌صورت زیر تغییر می‌کنند:

• دقت (Precision) = TP / (TP + FP + Hallucination₂) ≈ 72.7 %
• فراخوانی (Recall) = TP / (TP + FN + Hallucination₁) ≈ 88.9 %

اگر توهم‌ها را نادیده بگیریم، دقت به 80 % و فراخوانی به 95.2 % می‌رسد. این اختلاف نشان می‌دهد که نحوهٔ تعریف توهم‌ها می‌تواند نتایج ارزیابی را به‌طور چشمگیری تغییر دهد و تفسیر نتایج را دشوار می‌کند.

بنچمارک‌ها (Benchmarks)

1. هدف بنچمارک‌ها

بنچمارک‌ها مجموعه‌های دادهٔ ثابت و وظایف استاندارد (مانند SQuAD, GLUE, WMT) هستند که برای مقایسهٔ عمومی توانایی مدل‌ها استفاده می‌شوند. آن‌ها به‌دست آوردن یک نقطهٔ مقایسه بین مدل‌های مختلف کمک می‌کنند.

2. محدودیت‌های بنچمارک‌ها

1. ساکن بودن – بنچمارک‌ها یک بار تعریف می‌شوند و تغییر نمی‌کنند؛ بنابراین نمی‌توانند شرایط پویا و متغیر دنیای واقعی را بازتاب دهند.
2. سطح سطحی – نمرهٔ بالا در یک بنچمارک به معنای توانایی مدل در تمام زمینه‌ها نیست؛ مدل ممکن است در موارد خاص (مثلاً پرسش‌های مبهم یا دامنه‌های تخصصی) شکست بخورد.
3. بهینه‌سازی برای بنچمارک – برخی تیم‌ها مدل‌های خود را به‌طور مستقیم روی داده‌های بنچمارک آموزش می‌دهند؛ این کار باعث می‌شود مدل در بنچمارک عالی باشد اما در برنامه‌های واقعی عملکرد ضعیفی داشته باشد.

ارزیابی‌های کاربردی (Evals)

1. تعریف Evals

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

2. حوزه‌های ارزیابی

حوزه	مثال
حساسیت به ورودی	بررسی اثر تغییرات جزئی در پرسش (مثلاً «What’s the capital of France?», «What is the capital of France?») بر پاسخ.
اهمیت توکن‌ها	شناسایی توکن‌های کلیدی که خروجی را به‌طور غیرمنتظره تغییر می‌دهند (مانند قالب‌بندی نادرست در Promptهای RAG).
تشخیص ابهام	ارزیابی اینکه آیا زمینهٔ داده‌شده برای انجام کار کافی است یا نه.
اندازه‌گیری عدم قطعیت	محاسبهٔ توزیع احتمالی خروجی برای یک Prompt خاص.
تشخیص توهم	شناسایی مواردی که مدل اطلاعاتی را اضافه می‌کند که در متن منبع وجود ندارد.
سازگاری و روانی	استفاده از معیارهای BLEU/ROUGE به‌همراه ارزیاب‌های انسانی برای سنجش روانی متن.
تجزیه و تحلیل ویژگی‌ها	بررسی کدام توکن‌ها یا عبارات بیشترین وزن را در تصمیم‌گیری مدل دارند (مانند روش‌های SHAP یا Integrated Gradients).
تحلیل مسیرهای نورونی	استخراج فعال‌سازی لایه‌های میانی برای درک الگوهای داخلی (موردی که در زمینهٔ تفسیر مکانیکی مدل‌ها مورد استفاده قرار می‌گیرد).

3. چرا Evals مهم‌اند؟

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

تست‌های نرم‌افزاری (Tests)

1. نقش تست‌ها

تست‌ها اعتبارسنجی نهایی هستند؛ هدف آن‌ها اطمینان از این است که سیستم در شرایط تولید به‌درستی کار می‌کند. در محیط‌های LLM‑محور، تست‌ها باید بر پایهٔ Evals ساخته شوند تا معیارهای پذیرش (pass/fail) واضحی داشته باشند.

2. روش‌های عملی

1. تقسیم سیستم به مؤلفه‌های کوچکتر – LLM را به‌عنوان یک جعبهٔ سیاه (black‑box) در نظر بگیرید؛ ورودی متن و خروجی متن. مؤلفه‌های پیش‌پردازش (prompt engineering) و پس‌پردازش (پست‑پروسسینگ) به‌صورت جداگانه تست می‌شوند.
2. ایجاد تست‌های خودکار بر پایهٔ Evals – به‌عنوان مثال، یک ارزیابی توهم می‌تواند به‌صورت یک تست CI/CD تعریف شود که اگر نرخ توهم بیش از ۲ ٪ شد، تست «شکست» می‌کند.
3. ادغام در CI/CD – پس از هر به‌روزرسانی مدل یا تغییر Prompt، Evals اجرا می‌شوند؛ نتایج به‌صورت متریک‌های عددی ذخیره می‌شوند و تست‌های پاس/فیلد بر پایهٔ آستانه‌های تعیین‌شده (مثلاً دقت ≥ 80 %، توهم ≤ 3 %) اجرا می‌شوند.

چارچوب ذهنی: بنچمارک ↔ Evals ↔ Tests

سطح	هدف	مثال
Benchmarks	مقایسهٔ کلی بین مدل‌ها	GLUE، SQuAD، WMT
Evals	درک رفتار مدل در کاربرد خاص	ارزیابی توهم در خلاصه‌سازی اخبار، حساسیت به تغییرات جزئی Prompt
Tests	اعتبارسنجی نهایی در محیط تولید	تست CI که اگر نرخ توهم > 5 % باشد، استقرار متوقف می‌شود

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

نکات کلیدی برای پیاده‌سازی

1. تعریف واضح برای توهم‌ها – تصمیم بگیرید که آیا توهم را به‌عنوان خطای مثبت، منفی یا دستهٔ جداگانه در نظر می‌گیرید؛ این تصمیم مستقیماً بر محاسبهٔ دقت/فراخوانی تأثیر می‌گذارد.
2. ثبت دقیق ورودی‑خروجی – برای هر ارزیابی، Prompt، تنظیمات (temperature, top‑p) و خروجی را ذخیره کنید تا بتوانید تجزیه و تحلیل پس‌از‑دست را انجام دهید.
3. استفاده از چندین متریک – ترکیب معیارهای عددی (precision, recall) با معیارهای کیفی (روان بودن، سازگاری) برای داشتن تصویر کامل‌تر.
4. به‌روزرسانی مداوم Evals – پس از هر به‌روزرسانی مدل یا تغییر Prompt، ارزیابی‌ها را دوباره اجرا کنید؛ این کار به‌خصوص برای مدل‌های استوکاستیک (stochastic) مهم است.
5. آموزش تیم – توسعه‌دهندگان باید با مفهوم «حساسیت به ورودی» و «تشخیص توهم» آشنا شوند تا بتوانند Promptها را به‌صورت هدفمند بهبود دهند.

برای مطالعه موارد بیشتر اینجا کلیک کنید.

ارزیابی سیستم‌های مبتنی بر مدل‌های زبانی بزرگ نیازمند تغییر نگرش نسبت به روش‌های سنتی است. بنچمارک‌ها تنها یک نقطهٔ مقایسهٔ سطحی فراهم می‌کنند؛ برای درک عمیق‌تر باید Evals را به‌کار بگیریم که رفتار مدل را در زمینهٔ کاربرد واقعی، ورودی‌های متغیر و تصمیم‌گیری‌های داخلی بررسی می‌کند. سپس، تست‌های نرم‌افزاری بر پایهٔ این ارزیابی‌ها ساخته می‌شوند تا اطمینان حاصل شود که سیستم در محیط تولید در محدودهٔ پذیرش باقی می‌ماند.

با پیاده‌سازی این سه لایه (Benchmarks → Evals → Tests) می‌توان به‌صورت مستمر کیفیت، ایمنی و قابلیت اطمینان مدل‌های زبانی بزرگ را ارتقا داد و از بروز ریسک‌های ناشی از توهم یا عدم سازگاری جلوگیری کرد. این رویکرد، گام مهمی برای انتقال پروژه‌های Proof‑of‑Concept به تولید واقعی در حوزهٔ GenAI است.

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