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

در نمایش اولیهٔ یک چت‌بات، پاسخ روان فارسی معمولاً زود به چشم می‌آید: جمله‌ها درست‌اند، لحن محترمانه است و متن شبیه ترجمهٔ کلمه‌به‌کلمه به نظر نمی‌رسد. برای انتخاب مدل، قدم بعدی بررسی چیزهایی است که کمتر دیده می‌شوند. آیا پاسخ درست است؟ آیا شرط و استثنای متن را حفظ کرده است؟ اگر سند کافی در اختیار ندارد، سؤال تکمیلی می‌پرسد یا جزئیات تازه می‌سازد؟ و آیا همین کیفیت با هزینه و زمان قابل قبول در سرویس واقعی حفظ می‌شود؟

«مدل خوب برای فارسی» باید در ارتباط با یک کار تعریف شود. مدل مناسب بازنویسی نامه، لزوماً همان انتخاب مناسب برای جست‌وجو در اسناد، استخراج اطلاعات یا تحلیل چند گزارش نیست. هدف این یادداشت، تبدیل این عبارت کلی به چند معیار قابل بررسی است؛ معیارهایی که با کمک پژوهش‌های فارسی و نمونه‌های واقعی هر سازمان، انتخاب مدل را روشن‌تر می‌کنند. چارچوب کلی انتخاب اندازه نیز در مقالهٔ «برای هر کاربرد واقعاً چه اندازه مدلی لازم داریم؟ از مدل تخصصی و SLM تا LLM» توضیح داده شده است.

ابتدا بگوییم فارسیِ چه کاری را می‌سنجیم

برای یک چت‌بات پشتیبانی، فهم سؤال کوتاه و محاوره‌ای، حفظ جزئیات گفت‌وگو و ارائهٔ راهنمای درست اهمیت دارد. در دستیار اسناد، پیدا کردن شاهد و پاسخ‌دادن بر اساس همان شاهد تعیین‌کننده است. در استخراج اطلاعات، ممکن است مهم‌ترین خروجی یک تاریخ، شناسه یا عدد در قالب مشخص باشد؛ در بازنویسی، حفظ معنا در کنار لحن و نگارش اهمیت پیدا می‌کند. بنابراین «روانی»، «درستی»، «پیروی از دستور» و «تناسب با مخاطب» بهتر است جدا ثبت شوند.

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

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

پژوهش‌های فارسی چه کمکی به انتخاب می‌کنند؟

برای آغاز کار، منابع پژوهشی فارسی در دسترس‌اند. مقالهٔ Advancing Persian LLM Evaluation، منتشرشده در Findings of NAACL 2025، حاصل همکاری پژوهشگرانی از دانشگاه‌های تربیت مدرس، صنعتی شریف، شهید بهشتی، تهران و علم و صنعت است. این کار، PeKA و PK-BETS را برای موضوع‌هایی مانند دانش فرهنگی، تاریخ، ادبیات و توانایی‌های زبانی معرفی می‌کند و چند نوع ارزیابی را کنار هم قرار می‌دهد. ارزش عملی چنین منابعی، فراهم‌کردن سؤال، معیار و زمینهٔ مقایسه است.

پژوهش‌های جدول زیر برای سنجش جنبه‌های متفاوت زبان فارسی انتخاب شده‌اند. سال انتشار هر پژوهش در جدول آمده است؛ نسخهٔ داده و مدلِ هر آزمایش نیز باید از همان پژوهش مشخص شود.

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

در استفاده از چند منبع، هم‌پوشانی داده‌ها نیز مهم است. پیش از ترکیب نتایج، باید معلوم باشد مجموعه‌ها مستقل‌اند، زیرمجموعهٔ یکدیگرند یا بخشی از سؤال‌ها و منابع مشترک دارند؛ به‌ویژه در نام‌ها و نسخه‌های نزدیک مانند PK-BETS و FarsEval-PKBETS، شناسهٔ دقیق داده باید ثبت شود. همچنین یک آزمون ترجمه‌شده می‌تواند برای مقایسهٔ بین‌زبانی مفید باشد، در کنار آن نمونه‌های نوشته‌شده در بافت فارسی نیز برای سنجش کاربرد محلی ارزش دارند.

«شاهد فارسی» باید نام وظیفه داشته باشد

برای E5-Large-Instruct، گزارش MIRACL در فارسی nDCG@10 برابر 59.4 دارد. کارت مدل نتیجهٔ MassiveIntent فارسی را هم گزارش می‌کند. اولی بازیابی سند و دومی دسته‌بندی نیت با embedding را می‌سنجد؛ هیچ‌کدام آزمون نگارش فارسی یا پاسخ‌گویی به سؤال نیست. نتیجهٔ هر مدل به همان وظیفه و مجموعه‌آزمون مربوط است و نبود نتیجه، ناتوانی آن مدل در فارسی را ثابت نمی‌کند.

از درخواست‌های واقعی، یک مجموعهٔ کوچک اما معنادار بسازیم

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

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

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

نمونه‌های جدول بعدی برای توضیح روش ساخته شده‌اند و نتیجهٔ آزمایش هیچ مدل یا نقل سؤال از بنچمارک‌ها نیستند. هر تیم می‌تواند همین نوع آزمون را با محتوای خودش بسازد؛ پاسخ مورد انتظار باید به نیاز واقعی همان سرویس متصل باشد.

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

امتیاز بدهیم، اما چند نوع کیفیت را در یک عدد گم نکنیم

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

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

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

در فارسی، روش مقایسهٔ پاسخ هم مهم است

مقایسهٔ حرف‌به‌حرف یا Exact Match برای بعضی خروجی‌ها، مانند شناسهٔ دقیق، مناسب است. در پاسخ طبیعی، «۲۵» و «25» یا دو عبارت هم‌معنا ممکن است پاسخ یکسانی را برسانند، ولی مقایسهٔ خام آن‌ها را متفاوت حساب کند. پژوهش TARAZ به همین مسئله در پاسخ کوتاه فارسی پرداخته و نرمال‌سازی و سنجش شباهت معنایی را در روش ارزیابی خود ترکیب می‌کند. نکتهٔ کاربردی آن، انتخاب روش امتیازدهی متناسب با نوع پاسخ است.

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

در پرسش‌های فرهنگی و اجتماعی، پاسخ مطلوب باید به بافت و معیار روشن متصل باشد. پرسش دربارهٔ یک واقعیت قابل مراجعه، با پرسش دربارهٔ لحن مناسب یا ترجیح مخاطب یکسان نیست؛ در دومی ممکن است چند پاسخ پذیرفتنی وجود داشته باشد. پژوهش EPT از دانشگاه صنعتی شریف نیز ارزیابی اعتمادپذیری را در محورهای جدا و با زمینهٔ فرهنگی مشخص تعریف می‌کند. هنگام استفاده از چنین منابعی، همان تعریف معیار باید حفظ شود و سلیقهٔ یک ارزیاب به «تنها فارسی صحیح» تبدیل نشود.

داور انسانی و مدل داور چگونه کنار هم قرار بگیرند؟

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

مدل داور یا LLM-as-a-Judge می‌تواند بررسی تعداد زیادی پاسخ را آسان‌تر کند، اما باید روی نمونه‌های فارسیِ همان وظیفه با داوری انسانی مقایسه شود. در پژوهش Advancing Persian LLM Evaluation، میزان توافق داورهای مدلی با ارزیابی انسانی نیز بررسی شده است. نتیجهٔ عملی برای یک تیم، انتخاب داور بر اساس توانایی آن در اجرای معیار خود تیم است؛ معروف‌بودن مدل داور یا روان‌بودن توضیحش، جای این بررسی را نمی‌گیرد.

پژوهش Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena هم مزیت استفاده از داور مدلی و هم اثرهایی مانند ترتیب پاسخ‌ها و ترجیح پاسخ‌های طولانی‌تر را بررسی می‌کند. برای کاهش این اثرها، دستور ارزیابی روشن، نمونهٔ امتیازها، امکان ثبت مساوی و جابه‌جایی جای دو پاسخ مفید است. بخشی تصادفی از همهٔ پاسخ‌ها، در کنار موارد اختلاف یا حساس، باید بازبینی انسانی شود؛ دیدن فقط مواردی که داور خودش مشکوک اعلام کرده، همهٔ خطاهای او را آشکار نمی‌کند.

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

مدل را می‌سنجیم یا سامانهٔ کامل را؟

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

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

در این مرحله، معیار embedding نیز باید متناسب با بازیابی باشد. FaMTEB، با مشارکت پژوهشگران صنعتی شریف و MCINext، هفت گروه وظیفه را جدا می‌کند؛ برای جست‌وجو، باید به نتایج بازیابیِ مرتبط توجه کرد، نه فقط میانگین همهٔ وظایف. در آزمون خود سامانه نیز بررسی کنید آیا شواهد لازم به فهرست نامزدها می‌رسند و پس از reranker باقی می‌مانند. روش انتخاب این اجزا در مقالهٔ انتخاب مدل زبانی، embedding و reranker برای دستیار اسناد سازمانی توضیح داده شده است.

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

یک مقایسهٔ منصفانه باید چه چیزهایی را ثابت نگه دارد؟

برای مقایسهٔ کیفیت مدل‌ها، سؤال‌ها، اسناد مجاز، معیار پذیرش و بودجهٔ کار باید قابل مقایسه باشند. بااین‌حال، هر مدل باید با قالب گفت‌وگو و روش اجرای سازگار خودش استفاده شود؛ تحمیل قالب اشتباه به یک مدل، به نام «یکسان‌بودن تنظیمات»، مقایسهٔ مفیدی نمی‌سازد. روش پرامپت‌نویسی، تعداد مثال‌ها، حالت reasoning، ابزارها و محدودیت خروجی باید ثبت شوند. اگر برای هر مدل تنظیم جداگانه‌ای انجام شده است، دادهٔ تنظیم باید از مجموعهٔ آزمون نهایی جدا بماند.

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

چند واحد اختلاف در یک نمونهٔ کوچک را نباید فوری به برتری عمومی تبدیل کرد. در یک مثال فرضی، ۸۱ پاسخ درست در برابر ۷۸ پاسخ درست از ۱۰۰ سؤال، به‌تنهایی نشان نمی‌دهد اختلاف در مجموعهٔ بزرگ‌تر و کاربردهای دیگر هم باقی می‌ماند. برای نتیجه‌گیری قوی‌تر، باید عدم‌قطعیتِ اختلاف و ساختار نمونه‌ها بررسی شود؛ سؤال‌های چندگانهٔ یک گفت‌وگو یا سند، لزوماً مشاهده‌های مستقل نیستند. راهنمای آزمون معناداری آماری در پردازش زبان طبیعی توضیح می‌دهد که انتخاب روش آماری به نوع وظیفه، معیار و طراحی آزمایش بستگی دارد.

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

هزینه و سرعت را با همان متن فارسی بسنجیم

پس از رسیدن به کیفیت قابل قبول، زمان پاسخ، مصرف حافظه و هزینه وارد تصمیم می‌شوند. توکنایزرها بر اساس الگوریتم و واژگان خود، متن را به قطعه‌های متفاوتی می‌شکنند؛ سازوکار آن در راهنمای توکن‌سازی Hugging Face توضیح داده شده است. برای مقایسهٔ تجربهٔ کاربر فارسی، همان متن‌ها و همان کار را به مدل‌ها بدهید و تعداد توکن واقعی هرکدام را ثبت کنید. در کنار token/s، زمان رسیدن اولین بخش مفید پاسخ و زمان پایان کار اهمیت دارد؛ پاسخ بلندتر یا خروجیِ بریده‌شده به دلیل سقف توکن نیز باید در نتیجه دیده شود.

آزمون باید با نسخه‌ای انجام شود که قرار است ارائه شود: مدل دقیق، دقت وزن‌ها یا کوانتیزه‌سازی، موتور اجرا، طول زمینه و بار هم‌زمان. نتیجهٔ نسخهٔ اصلی یک مدل را نمی‌توان بدون بررسی به همهٔ نسخه‌های چهار‌بیتی آن نسبت داد؛ همان‌طور که موفقیت یک درخواست، ظرفیت سرویس برای چند کاربر را مشخص نمی‌کند. اثر کاهش دقت وزن در مقالهٔ چهاربیتی‌کردن مدل و محدودیت حافظه زیر بار هم‌زمان در مقایسهٔ ۲۴ و ۴۸ گیگابایت برای اجرای مدل بررسی شده است.

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

خروجی ارزیابی، یک گزارش قابل استفاده باشد

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

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