سؤالی که هر تیمی در نقطه‌ی شروع می‌پرسد: «کدام مدل متن‌باز را برداریم؟» و جوابِ رایج هم معمولاً غلط است: «هر کدام بنچمارک بالاتری دارد». جدول‌های عمومی روی مجموعه‌ی آزمون‌های عمومی ساخته شده‌اند — و مدل‌ها هم همین را می‌دانند؛ نتیجه، عددی است که روی داده‌ی واقعی شما قابل بازتولید نیست. این مطلب به‌جای اعلام برنده، یک روش مقایسه می‌سازد که با خانواده‌ی Gemma به‌عنوان نمونه‌ی مطالعه شروع می‌کنیم ولی روی هر خانواده‌ی متن‌بازی قابل اجراست.
خانواده‌ی Gemma در یک نگاه
Gemma خانواده‌ی مدل‌های متن‌باز گوگل است و ارزشش در پوشش طیف اندازه است: از نسخه‌های کوچکِ مناسب اجرا روی دستگاه تا نسخه‌های میان‌اندازه برای سرورهای کوچک، با نسخه‌های چندوجهی که تصویر هم می‌فهمند. سازگاری با اکوسیستم ابزارهای متن‌باز خوب است — از موتورهای استنتاج تا ابزارهای کوانتیزاسیون — و همین یعنی هزینه‌ی آزمودنش پایین است. برای تیمی که اولین مدل متن‌بازش را انتخاب می‌کند، داشتن چند اندازه از یک خانواده‌ی واحد یک مزیت واقعی است: تجربه‌ی تنظیم و ارزیابی روی اندازه‌ی کوچک، به اندازه‌های بزرگ‌تر همان خانواده قابل انتقال است.
قاعده‌ی طلایی: هم‌اندازه با هم‌اندازه، هم‌شرایط با هم‌شرایط
مقایسه‌ی بی‌انصاف رایج‌ترین خطای بنچمارک شخصی است. دو قاعده سفت: اول، هر مدل را فقط با رقبای هم‌کلاس اندازه مقایسه کنید — مدل ۲ میلیاردی با مدل‌های ۲ میلیاردی، ۹ میلیاردی با ۹ میلیاردی؛ مقایسه‌ی عرضی بین کلاس‌ها فقط برای تصمیم «چقدر بودجه لازم دارم» است نه «کدام بهتر است». دوم، شرایط اجرا یکسان باشد: همان سطح کوانتیزاسیون، همان طول زمینه، همان تنظیمات تولید. یک مدل با نسخه‌ی full precision امتیاز خوب می‌گیرد و با کوانتیزاسیون ۴ بیتی چند نمره می‌افتد — و شما قرار است نسخه‌ی کوانتیزه را اجرا کنید، پس همان را بسنجید.
سه محور آزمون
استدلال: مسائل ریاضی و منطق چندمرحله‌ای که جوابشان را می‌دانید؛ نه فقط «جواب درست است یا نه» — مسیر استدلال را هم بخوانید. مدلی که مسیرش سالم است ولی گاهی حسابش می‌لغزد، با یک ابزار محاسبه قابل ترمیم است؛ مدلی که مسیرش می‌شکند، ترمیم‌پذیر نیست. کدنویسی: سه دسته امتحان کنید — تولید تابع از توضیح، رفع باگ از کد خراب، و کد در بستر پروژه‌ی واقعی شما با کتابخانه‌های خودتان؛ دسته‌ی سوم جایی است که رتبه‌بندی‌های عمومی بیشترین فاصله را با واقعیت دارند. چندزبانه — و برای ما، فارسی: این محور معمولاً تعیین‌کننده است و در بنچمارک‌های عمومی کم‌نمایش است. چهار آزمون ساده: پاسخ روان و طبیعی به فارسی (نه ترجمه‌مانند)، حفظ نیم‌فاصله و املای درست در متن تولیدی، مقاومت در مخلوط فارسی-انگلیسی (جایی که خیلی از مدل‌ها می‌شکنند)، و فهم اصطلاحات بومی. مدل‌های گوگل به‌طور تاریخی در پوشش چندزبانه قوی بوده‌اند، اما این را روی وظیفه‌ی خودتان تست کنید، نه بر اساس سابقه.
بنچمارک عمومی به شما می‌گوید کدام مدل‌ها از دور امیدبخش‌اند؛ بنچمارک خودتان می‌گوید کدام یک برنده است.
بنچمارک اختصاصی: یک بعدازظهر کار
بنیان آن سخت نیست: ۵۰ تا ۱۰۰ پرسش واقعی از کار روزمره‌ی محصول‌تان جمع کنید — از لاگ‌ها، تیکت‌های پشتیبانی، اسناد واقعی. جواب استاندارد برای بخشی از آن‌ها بنویسید (یا مدل قوی‌تر به‌عنوان پیش‌نویس و شما بازبینی). سپس هر کاندید را با تنظیمات ثابت روی همین مجموعه اجرا کنید و سه‌گانه بسنجید: درستی، وفاداری به زمینه، و کیفیت قالب خروجی. داوری اولیه را می‌توانید به یک مدل قوی بسپارید، اما نمونه‌ای از داوری‌هایش را با چشم خودتان چک کنید. این مجموعه را زنده نگه دارید — هر ماه چند نمونه‌ی جدید از ترافیک واقعی اضافه و نمونه‌های لو‌رفته حذف کنید.
از بنچمارک تا استقرار
برنده‌ی بنچمارک، تا وقتی روی سخت‌افزار شما تست نشده، برنده نیست. سه سنجه‌ی استقراری را به جدول اضافه کنید: سرعت واقعی (توکن بر ثانیه) روی همان سخت‌افزار اجرایی، مصرف حافظه در پیک — و رفتار در طولانی‌مدت: افت کیفیت در گفتگوهای طولانی و پنجره‌های بزرگ. اگر نهایتاً قرار است مدل را برای دامنه‌ی خودتان تنظیم دقیق کنید، مدل‌های یک خانواده را بعد از fine-tuning دوباره مقایسه کنید — ترتیب برنده‌ها بعد از تنظیم، اغلب عوض می‌شود.
جمع‌بندی
روش پیشنهادی در یک خط: خانواده‌های کاندید را در دو سه کلاس اندازه لیست کنید، با شرایط اجرای یکسان روی بنچمارک ۵۰-۱۰۰ تاییِ خودتان بیاورید، سه محور استدلال/کد/چندزبانه-فارسی را جدا بسنجید و برنده‌ی هر کلاس را روی سخت‌افزار واقعی تأیید کنید. انتخاب مدل یک تصمیم یک‌باره نیست؛ با زنده نگه‌داشتن مجموعه‌ی ارزیابی، هر نسخه‌ی جدید را روی همان خط می‌گذارید. چارچوب کلی‌تر انتخاب را در راهنمای انتخاب مدل و حساب هزینه‌اش را در راهنمای هزینه‌ی API ببینید. برای تست مدل‌ها روی پرسش‌های واقعی خودتان، یک حساب بسازید.