طراحی پایپ‌لاین ارزیابی مدل زبانی (Evaluation Pipeline)

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

در این درس یاد می‌گیرید که چگونه یک پایپ‌لاین ارزیابی جامع و خودکار بسازید. این پایپ‌لاین با ترکیب چهار لایه‌ی ارزیابی شامل پرپلکسیتی (Perplexity)، تطابق دقیق (Exact-match)، معیار F1 در سطح توکن و یک داور شبیه‌سازی‌شده (Mock LLM-as-judge)، تصویری دقیق از نقاط قوت و ضعف مدل به شما می‌دهد.

پیاده‌سازی ارائه‌شده کاملاً مستقل از اینترنت و به صورت محلی قابل اجراست؛ بنابراین بدون نیاز به کلیدهای API خارجی، ابری یا پرداخت ارزی می‌توانید این فریم‌ورک را روی سیستم خود توسعه دهید و آن را در چرخه‌های یکپارچه‌سازی مداوم (CI) به کار بگیرید.

نظارت بر آموزش مدل با منحنی‌های تابع زیان (Loss) انجام می‌شود، اما ارزیابی مهارتی است که باید خودتان طراحی کنید. در این درس، یک پایپ‌لاین ارزیابی یکپارچه می‌سازیم که هر مدل زبانی آموزش‌دیده‌ای را تحویل می‌گیرد، چهار ارزیابی ناهمگن روی آن اجرا می‌کند، نتایج را در قالب یک گزارش تفکیک‌شده بر اساس هر وظیفه (Task) تجمیع می‌کند و یک مدل شبیه‌سازی‌شده‌ی محلی در نقش داور (LLM-as-judge) پیاده‌سازی می‌کند تا تمام این چرخه بدون نیاز به اتصال شبکه اجرا شود. این چهار ارزیابی، ابعاد حیاتی مورد نیاز برای هر مدل آماده‌ی عرضه را پوشش می‌دهند: مدل‌سازی زبان بر اساس پرپلکسیتی (Perplexity)، صحت پاسخ‌های کوتاه بر اساس تطابق دقیق (Exact-match)، شباهت پاسخ‌های باز بر اساس F1 در سطح توکن (Token F1) و امتیازدهی کیفی با داور (Judge).

اهداف یادگیری

• محاسبه‌ی پرپلکسیتی روی داده‌های ارزیابیِ نگه‌داشته‌شده (Held-out) با در نظر گرفتن توکن‌های پوشانده‌شده (Masked) در یک ترنسفورمر بسیار کوچک.
• اجرای ارزیابی تطابق دقیق روی پرامپت‌های فکت‌محور و کوتاه.
• محاسبه‌ی F1 در سطح توکن میان رشته‌ی پیش‌بینی‌شده و رشته‌ی مرجع به همراه نرمال‌سازی.
• ساخت یک مدل زبانی در نقش داورِ شبیه‌سازی‌شده و محلی که به خروجی‌های مدل امتیازی بین 1 تا 5 می‌دهد.
• تجمیع این چهار ارزیابی در یک گزارش وزندار واحد، همراه با تفکیک نتایج به ازای هر وظیفه.

صورت مسئله

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

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

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

مفهوم کلی

هر روش ارزیابی تابعی با ساختار (model, dataset) -> EvalResult است. نتیجه‌ی خروجی شامل مقدار سنجه، جزئیات هر نمونه برای بازبینی دقیق و نامی مشخص برای مرحله‌ی تجمیع است. پایپ‌لاین این ارزیابی‌ها را بر اساس یک پیکربندی کنار هم می‌گذارد که مشخص می‌کند کدام سنجه‌ها اجرا شوند و چه وزنی داشته باشند.

محاسبه‌ی دقیق پرپلکسیتی

پرپلکسیتی برابر است با exp(mean negative log-likelihood per token)؛ یعنی تابع نماییِ میانگینِ منفیِ درست‌نمایی لگاریتمی (Log-likelihood) به ازای هر توکن. در پیاده‌سازی این فرمول دو تله وجود دارد:

• میانگین باید روی موقعیت توکن‌های واقعی محاسبه شود، نه روی کل ضرب اندازه بچ در طول توالی (batch * sequence). توکن‌های پدینگ (Padding) حتماً باید از مخرج کسر حذف شوند؛ در غیر این صورت پرپلکسیتی بهتر از مقدار واقعی به نظر می‌رسد.
• مدل، توکن بعدی را پیش‌بینی می‌کند؛ بنابراین لاجیت‌ها در موقعیت i، توکن موقعیت i+1 را پیش‌بینی می‌کنند. خطاهای جابه‌جایی یکی‌به‌یکی (Off-by-one) در اینجا بی‌صدا رخ می‌دهند: آموزش مدل ادامه می‌یابد و تابع زیان کم می‌شود، اما سنجه کاملاً بی‌معنی خواهد شد.

کد ارزیابی، مجموع منفیِ لگاریتم احتمال هر توکن (-log p(token)) را روی موقعیت‌های غیرپدینگِ هر بچ و همراه با تعداد توکن‌های همان بچ محاسبه می‌کند و در پایان عمل تقسیم را انجام می‌دهد. این روش از میانگین‌گیریِ پرپلکسیتی‌های هر بچ از نظر محاسباتی پایدارتر است (چرا که میانگین‌گیری دسته‌ای، وزن کمتری به توالی‌های کوتاه می‌دهد) و دقیقاً با تعریف کتابی آن هم‌خوانی دارد.

تطابق دقیق، همراه با نرمال‌سازی

بستر آزمایشی (Harness) پیش از مقایسه، متن پیش‌بینی‌شده و متن مرجع را نرمال‌سازی می‌کند:

• تبدیل حروف به حروف کوچک (Lowercase).
• حذف فاصله‌های خالی ابتدا و انتهای متن.
• فشرده‌سازی فاصله‌های متوالی درون متن به یک فاصله‌ی تکی.
• حذف نشانه‌گذاری‌های پایانی (.، !، ؟) در صورتی که تفاوت دو متن فقط در همین نشانه‌ها باشد.

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

محاسبه‌ی اصولی F1 در سطح توکن

معیار Token F1 میانگین همساز دقت (Precision) و بازخوانی (Recall) است که روی کیسه‌ی توکن‌ها (Bag-of-tokens) محاسبه می‌شود. مراحل کار:

1. نرمال‌سازی پیش‌بینی و مرجع (با همان قواعد تطابق دقیق).
2. شکستن هر متن به فهرستی از توکن‌ها (توکن‌سازی بر اساس فاصله‌ها).
3. شمارش اشتراک چندمجموعه‌ای (Multiset intersection).
4. Precision = intersection_count / len(pred_tokens). مقدار Recall = intersection_count / len(ref_tokens). و F1 میانگین همساز این دو است.

اگر هم متن پیش‌بینی و هم مرجع خالی باشند، F1 برابر با 1 در نظر گرفته می‌شود (تطابق تهی یا Vacuous match). اگر فقط یکی از آن‌ها خالی باشد، F1 صفر خواهد بود. این الگو مطابق با مرجع ارزیابی SQuAD است و در برابر بازنویسی‌ها اعداد پایداری ارائه می‌دهد.

شبیه‌سازی محلی مدل زبانی در نقش داور

داور واقعی، مدلی پیشرو (Frontier Model) پشت یک API است. اما برای این درس داور باید به صورت آفلاین اجرا شود. داور شبیه‌سازی‌شده (Mock judge) یک امتیازدهنده‌ی قطعی است که دستورالعمل، پیش‌بینی مدل و مرجع را دریافت می‌کند و امتیازی در بازه‌ی {1, 2, 3, 4, 5} به همراه یک خط توضیح دلیل برمی‌گرداند. قواعد امتیازدهی صریح هستند:

• امتیاز 5 اگر پیش‌بینی نرمال‌شده برابر با مرجع نرمال‌شده باشد.
• امتیاز 4 اگر F1 در سطح توکن میان پیش‌بینی و مرجع حداقل 0.8 باشد.
• امتیاز 3 اگر F1 در سطح توکن در بازه‌ی [0.5, 0.8) قرار گیرد.
• امتیاز 2 اگر F1 در سطح توکن در بازه‌ی [0.2, 0.5) باشد.
• امتیاز 1 در غیر این صورت.

این یک داور واقعی نیست، اما رابط کاربری (Interface) درستی دارد. بعداً می‌توانید فقط با تغییر یک تابع، مدلی واقعی را جایگزین آن کنید؛ پایپ‌لاین کاری به این جابه‌جایی ندارد.

تجمیع نتایج

امتیاز تجمیعی، میانگین وزندار نمرات نرمال‌شده‌ی ارزیابی‌هاست. هر ارزیابی عدد خود را در بازه‌ی [0, 1] گزارش می‌دهد:

• پرپلکسیتی: به صورت 1 / (1 + log(perplexity)) نرمال می‌شود. پرپلکسیتی 1 به نمره‌ی 1 و بی‌نهایت به 0 تبدیل می‌شود.
• تطابق دقیق: از ابتدا در بازه‌ی [0, 1] است.
• معیار Token F1: از ابتدا در بازه‌ی [0, 1] است.
• داور: تقسیم بر 5 می‌شود.

وزن‌ها قابل تنظیم هستند. ترکیب پیش‌فرض شامل 0.2 پرپلکسیتی، 0.3 تطابق دقیق، 0.3 امتیاز Token F1 و 0.2 داور است. انتخاب وزن‌ها تصمیمی محصولی است؛ درس این پیچ تنظیم را در اختیارتان می‌گذارد تا بتوانید آن را آزمایش کنید.

معماری

کلاس EvalSuite یک هماهنگ‌کننده (Orchestrator) سبک است. هر ارزیابیِ مجزا، تابعی مستقل است که (model, tokenizer, dataset, config) را می‌گیرد و EvalResult برمی‌گرداند. بخش Aggregator نتایج را گردآوری کرده و گزارش نهایی را تولید می‌کند. بخش دمو، جدول نتایج را چاپ می‌کند و یک نسخه‌ی JSON هم می‌نویسد تا پایپ‌لاین‌های یکپارچه‌سازی مداوم (CI) بعدی بتوانند آن را دریافت کنند.

آنچه خواهید ساخت

پیاده‌سازی شامل یک فایل main.py و تست‌های مربوط به آن است:

1. TinyGPT: همان معماری فقط-دیکودر (Decoder-only) استفاده‌شده در درس‌های 38 تا 40؛ این بخش اضافه شده تا این درس کاملاً مستقل باشد.
2. InstructionTokenizer: توکن‌ساز در سطح بایت به همراه توکن‌های ویژه‌ی INST ،RESP و PAD.
3. چهار مجموعه‌داده‌ی آماده (Fixture): یک پیکره‌ی مدل زبانی، یک مجموعه‌ی EM، یک مجموعه‌ی F1 و یک مجموعه‌ی داور؛ هر کدام با 20 نمونه‌ی قطعی.
4. perplexity_eval: ساختار EvalResult را همراه با مقدار پرپلکسیتی و هیستوگرام تابع زیان به ازای هر توکن برمی‌گرداند.
5. exact_match_eval: میانگین EM و رکوردهای تک‌تک نمونه‌ها را برمی‌گرداند.
6. token_f1_eval: میانگین F1 سطح توکن و رکوردهای تک‌تک نمونه‌ها را برمی‌گرداند.
7. mock_judge و judge_eval: امتیاز و توضیح دلیل به ازای هر نمونه، و میانگین امتیاز کل مجموعه.
8. Aggregator.normalise: قاعده‌ی نرمال‌سازی به ازای هر ارزیابی.
9. Aggregator.aggregate: میانگین وزندار و گزارش تجمیع‌شده.
10. run_demo: مدلی کوچک را به مدت کوتاهی آموزش می‌دهد، هر چهار ارزیابی را اجرا می‌کند، جدول گزارش را چاپ کرده و فایل JSON را می‌نویسد، و در صورت موفقیت با کد صفر خارج می‌شود.

خواندن گزارش

گزارش از سه لایه تشکیل شده است. در بالا، امتیاز تجمیعی قرار دارد. زیر آن، اعداد مربوط به هر چهار ارزیابی آمده‌اند. زیر آن‌ها هم تفکیک نمونه‌به‌نمونه برای عیب‌یابی آورده شده است. اجرای ناموفق CI معمولاً فقط به امتیاز تجمیعی نیاز دارد، اما بازبینی که به دنبال علت افت کیفیت (Regression) می‌گردد، تفکیک نمونه‌به‌نمونه را می‌خواهد تا ببیند مدل کدام ورودی‌ها را اشتباه جواب داده است.

فایل خروجی JSON از کلیدهای ثابتی استفاده می‌کند تا داشبورد CI بتواند خطوط روند را در نسخه‌های مختلف رسم کند. جدول زیباچاپ‌شده‌ی ترمینال هم برای مهندسانی است که بعد از پایان آموزش به خط فرمان چشم دوخته‌اند.

اهداف تکمیلی

• افزودن ارزیابی کالیبراسیون (Calibration): آیا احتمالات خروجی سافت‌مکس (Softmax) مدل با دقت آن هم‌خوانی دارد؟ پیش‌بینی‌ها را بر اساس میزان اطمینان دسته‌بندی کنید و دقت تجربی را به ازای هر دسته گزارش دهید.
• افزودن ارزیابی استحکام (Robustness): روی هر نمونه یک برچسب اختلال (اشتباه تایپی، بازنویسی، داده‌ی گمراه‌کننده) بگذارید و افت سنجه را به ازای هر اختلال گزارش کنید.
• جایگزین کردن داور شبیه‌سازی‌شده با مدلی واقعی پشت یک فراخوانی HTTP. امضای تابع (Signature) تغییری نمی‌کند.
• افزودن یادگیری وزن‌ها به ازای هر وظیفه: به جای استفاده از وزن‌های ثابت، وزن‌ها را طوری برازش دهید که با ترتیب ترجیحی هدف برای مدل‌ها هم‌راستا شوند.

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