تلهٔ توکن‌سازی؛ چرا مقایسهٔ Perplexity بین مدل‌های مختلف گمراه‌کننده است

اگر امروز بر اساس اعداد Perplexity تصمیم می‌گیرید کدام مدل زبانی را برای پروژه خود انتخاب کنید، احتمالاً در حال دنبال کردن یک توهم ریاضی هستید. این عدد که سال‌ها به عنوان معیار طلایی کیفیت پیش‌بینی مدل‌ها شناخته می‌شد، در لحظهٔ مقایسهٔ دو مدل با معماری متفاوت، اعتبار خود را از دست می‌دهد.

برای سال‌ها، جامعهٔ هوش مصنوعی از Perplexity (پراکندگی یا سرگشتگی) به عنوان معیاری برای سنجش توانایی مدل در پیش‌بینی توکن بعدی استفاده کرده است. این معیار در واقع نمایی از آنتروپی متقاطع (Cross-Entropy) — شبیه به اندازه‌گیری میزان غافلگیری مدل از دیدن کلمه بعدی — است. طبق مستندات فنی، اگر یک مدل در حین آموزش به زیان (Loss) ۲.۰ برسد، Perplexity آن تقریباً ۷.۳۸۹ خواهد بود؛ یعنی مدل در هر گام، بین ۷.۳۹ گزینه تردید دارد.

به گزارش وب‌سایت dev.to در ۱۲ اوت ۲۰۲۶، این شهود برای رصد پیشرفت یک مدل واحد مفید است، اما در بنچمارک‌های متقاطع خطرناک است. مشکل اصلی این است که Perplexity زیان را «به ازای هر توکن» می‌سنجد، نه به ازای هر کاراکتر یا بایت.

ریاضیات پشت پرده

از نظر ریاضی، Perplexity برابر است با نماییِ میانگین منفی لگاریتم احتمال. رابطه آن با زیان ساده است: اگر زیان بر حسب nats باشد، PPL برابر است با exp(cross_entropy_loss). برای درک بهتر، این تبدیل‌ها را ببینید:

• زیان ۱.۵۰ $\rightarrow$ PPL ۴.۴۸۲
• زیان ۲.۰۰ $\rightarrow$ PPL ۷.۳۸۹
• زیان ۳.۰۰ $\rightarrow$ PPL ۲۰.۰۸۶

همان‌طور که در بحث‌های گذشته ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، درک دقیق معیارهای ارزیابی برای جلوگیری از خطاهای استراتژیک در استقرار مدل‌ها حیاتی است.

تلهٔ توکن‌ساز

تصور کنید یک متن داریم که مجموع عدم قطعیت آن ۲,۰۰۰ نات است. این مقدار، ویژگی خودِ متن است و ربطی به نحوهٔ برش آن ندارد. حالا دو توکن‌ساز مختلف را بررسی کنیم:

• توکن‌ساز A: متن را به ۱,۰۰۰ توکن (Token) — تکه‌های کوچکی از متن، مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — تقسیم می‌کند. میانگین زیان می‌شود ۲.۰ و Perplexity برابر با ۷.۳۸۹.
• توکن‌ساز B: بهینه‌تر است و همان متن را به ۸۰۰ توکن تقسیم می‌کند. میانگین زیان به ۲.۵ می‌رسد و Perplexity به ۱۲.۱۸۲ افزایش می‌یابد.

در این سناریو، توکن‌ساز «بهتر» که متن را فشرده‌تر می‌کند، باعث می‌شود مدل روی کاغذ ۶۵٪ بدتر به نظر برسد. مخرج کسر تغییر کرد، اما صورت آن ثابت ماند.

وقتی معیارها دروغ می‌گویند

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

• تفاوت مجموعه داده: Perplexity در کدنویسی بسیار کمتر از نثر است چون کد پیش‌بینی‌پذیرتر است. در واقع، تکیه بر معیارهای آماری در کدنویسی می‌تواند گمراه‌کننده باشد، چرا که سوابق اجرای کد در دیباگینگ معیار دقیق‌تری نسبت به برتری مدل‌های زبانی است.
• پنجره متنی: استفاده از پنجره متنی (Context Window) — میزان متنی که مدل هم‌زمان در ذهن نگه می‌دارد، مثل میز کاری که جا برای چند ورق دارد — بزرگ‌تر، نمره بهتری می‌دهد.
• نشت داده: اگر متن ارزیابی در داده‌های آموزش بوده باشد، مدل فقط حافظه خود را می‌سنجد، نه قدرت تعمیم.
• تنظیم دستوری: مدل‌های تنظیم دستوری (Instruction-tuned) اغلب در Perplexity ضعیف‌تر از مدل‌های پایه هستند، اما در عمل بسیار کاربردی‌ترند.

راهکار: بیت بر بایت (BPB)

برای مقایسهٔ واقعی، باید از معیاری استفاده کرد که به توکن‌ساز وابسته نباشد: بیت بر بایت (Bits Per Byte). در این روش، مجموع زیان بر تعداد بایت‌های واقعی متن (UTF-8) تقسیم می‌شود.

در مثال قبلی (۲,۰۰۰ نات و ۵,۰۰۰ بایت)، هر دو توکن‌ساز A و B به عدد یکسان ۰.۵۷۷۱ بیت بر بایت می‌رسند. این عدد مستقیماً نشان‌دهندهٔ نرخ فشرده‌سازی بهینه است و در تمام زبان‌ها و مدل‌ها قابل مقایسه است.

کاربردهای معتبر

البته Perplexity کاملاً منسوخ نشده است. این معیار برای رصد یک مدل واحد با توکن‌ساز ثابت در طول زمان عالی است. به‌ویژه در زمان کوانتیزاسیون (Quantization) — یعنی کاهش دقت وزن‌ها برای سبک‌تر کردن مدل — اگر Perplexity ناگهان از ۷.۳۹ به ۱۱ بپرد، یعنی مدل در سطح ساختاری شکسته است.

گام بعدی شما

• در گزارش‌های فنی مدل‌ها، به جای تکیه بر Perplexity، به دنبال نتایج Task-based یا معیارهای نرمال‌شده مانند BPB باشید.
• اگر مدل خود را کوانتایز می‌کنید، از Perplexity فقط به عنوان زنگ خطر برای شناسایی تخریب شدید مدل استفاده کنید.
• برای ارزیابی کیفیت نهایی، همواره از ارزیابی انسانی یا مدل‌های داور (LLM-as-a-judge) بهره ببرید.

اما تأثیر این خطاهای اندازه‌گیری بر هزینه استنتاج در مقیاس صنعتی حتی پیچیده‌تر است — به تحلیل ما درباره هزینه GPUها مراجعه کنید.