ماشین فارسی را چطور می‌ خواند؟

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

۱. مسئله دقیقا چیست؟

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

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

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

۲. فارسی برای رایانه چه ویژگی‌هایی دارد؟

فارسی برای انسان زبان پیوسته و آشنایی است، اما سامانه‌ی پردازش متن با چند لایه از ابهام روبه‌رو می‌شود. نخست، فارسی ساخت‌واژه‌ی فعالی دارد: پیشوند، پسوند و واژه‌بست می‌توانند صورت‌های زیادی از یک بن بسازند؛ مانند «می‌خوانم»، «نمی‌خواند»، «خوانده‌بودیم» و «کتاب‌هایمان». دوم، فارسی ضمیرانداز است؛ فاعل می‌تواند در جمله نیاید و از صرف فعل یا بافت فهمیده شود. سوم، ساخت اضافه معمولا نوشته نمی‌شود و رابطه‌ی «کتابِ خوب» در متن عادی اغلب بدون علامت کسره ثبت می‌شود. چهارم، واکه‌های کوتاه نوشته نمی‌شوند؛ در نتیجه یک رشته‌ی نوشتاری ممکن است بیش از یک خوانش داشته باشد. همین ترکیب — ساخت‌واژه‌ی گسترده، نحو ضمیرانداز، ساخت اضافه و خط راست‌به‌چپ — فارسی را در ادبیات پردازش زبان در ردیف زبان‌های کم‌منبع و پرچالش قرار می‌دهد (Hosseini et al., 2026)؛ همان پژوهشی که بنچمارک توهم‌زایی PerHalluEval را در بخش ۷ معرفی می‌کند.

خط راست‌به‌چپ نیز به‌خودی‌خود نشانه‌ی ضعف نیست، اما در ترکیب با نشانه‌های لاتین، اعداد، نشانی وب و کد، ترتیب نمایش و ترتیب منطقی نویسه‌ها می‌تواند برای ابزارهای ویرایش و استخراج متن دردسرساز شود؛ این رفتار در الگوریتم دوجهته‌ی یونیکد، یعنی Unicode Consortium (UAX #9)، به‌طور رسمی مشخص شده است. مهم‌تر از جهت خط، ناپایداری قراردادهای نوشتن است: یک نویسنده «می‌رود»، دیگری «می رود» و سومی «میرود» می‌نویسد. چشم انسان معمولا هر سه را به یک مفهوم نگاشت می‌کند، اما ماشین ابتدا سه رشته‌ی متفاوت می‌بیند.

• کم‌ منبع بودن یعنی نبودن داده نیست

در پردازش زبان طبیعی، «کم‌منبع» تعریف واحد و قطعی ندارد و بسته به متن می‌تواند به کمبود داده‌ی خام، داده‌ی برچسب‌خورده، ابزار پردازشی، بنچمارک یا توان محاسباتی اشاره کند. در این مقاله، منظور از کم‌منبع بودن فارسی عمدتا این است که در قیاس با اندازه‌ی جامعه‌ی زبانی، تنوع موضوعی و نیازهای کاربردی، داده‌ی پاک، برچسب‌خورده و قابل استفاده کمتر است؛ نه اینکه هیچ داده‌ای وجود ندارد. برای فارسی پیکره‌ها و بنچمارک‌های مهمی مانند ParsiNLU، PQuAD، PersianMMLU و PerHalluEval ساخته شده‌اند؛ برای نمونه PersianMMLU یا چالش خیام (Ghahroodi et al., 2024) از ۲۰٬۱۹۲ پرسش چهارگزینه‌ای در ۳۸ حوزه و سطح آموزشی تشکیل شده و دانش عمومی و پاسخ‌گویی چندگزینه‌ای را می‌سنجد، نه لزوما فهم زبانی را در معنای گسترده‌تر. پژوهش Bourbour Hosseinbeigi et al. (2026) که در LREC 2026 منتشر شده، از آموزش مدل‌های ویژه‌ی فارسیِ به‌کاررفته در یک سامانه‌ی بازیابی‌افزوده روی پیکره‌ای با ۷۳٫۱۱ میلیارد توکن فارسی گزارش می‌دهد. پس تصویر درست این نیست که «برای فارسی کاری نشده»؛ تصویر درست این است که پوشش، تنوع و امکان مقایسه هنوز با انگلیسی فاصله دارد.

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

۳. لایه‌ی اول: نویسه و رمزگذاری

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

در محاسبه‌ی کوچک این مقاله، عبارت انگلیسی «machine reads Persian» شامل ۲۱ نویسه و ۲۱ بایت بود. عبارت فارسی «ماشین فارسی را می‌خواند» با ۲۳ نویسه، ۴۴ بایت داشت. این فقط ویژگی UTF-8 است. از این عدد نمی‌توان درباره‌ی کیفیت مدل نتیجه گرفت؛ برای آن باید توکن واقعی هر توکنایزر را شمرد.

• نویسه‌های هم‌شکل اما متفاوت

یکی از مشکلات عملی فارسی، حضور شکل‌های عربی و فارسی «ی» و «ک» است. «ی» فارسی U+06CC با «ي» عربی U+064A یکسان نیست؛ «ک» فارسی U+06A9 نیز با «ك» عربی U+0643 تفاوت دارد. ممکن است فونت آن‌ها را بسیار شبیه نشان دهد، اما جست‌وجوی دقیق، حذف موارد تکراری، شمارش واژه و توکن‌سازی می‌تواند رفتار متفاوتی داشته باشد. اعداد هم سه خانواده‌ی رایج دارند: 123 لاتین، ۱۲۳ فارسی و ١٢٣ عربی. اعراب، کشیده و برخی علامت‌های نامرئی نیز می‌توانند رشته‌هایی بسازند که برای چشم یکی و برای رایانه متفاوت‌اند.

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

۴. لایه‌ی دوم: مرز واژه و نیم‌فاصله

نیم‌فاصله یا ZWNJ نویسه‌ای نامرئی است که جلوی اتصال ظاهری دو حرف را می‌گیرد، بی‌آنکه مانند فاصله‌ی معمولی واژه را به دو بخش مستقل تبدیل کند. در نگارش معیار، صورت‌هایی مانند «می‌رود»، «کتاب‌ها» و «خانه‌ام» با نیم‌فاصله نوشته می‌شوند. در عمل، صفحه‌کلید، عادت نویسنده، ویرایشگر و فرایند کپی‌کردن سبب می‌شوند همان واژه با فاصله، بدون فاصله یا با نویسه‌ی نامرئی دیگری ثبت شود.

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

• حتی ابزار اختصاصی هم بی‌خطا نیست

پژوهش Doostmohammadi et al. (2020) در COLING مسئله‌ی اصلاح جدانویسی و تشخیص نیم‌فاصله را به‌صورت مشترک مدل‌سازی کرد و روی پیکره‌ی دشوار ۵۰۰ جمله، امتیاز F1 میانگین کلان ۹۲٫۴۰ درصد گزارش داد. این نتیجه قوی است، اما کامل نیست: حتی سامانه‌ای که دقیقا برای همین وظیفه ساخته شده، بخشی از موارد را خطا می‌کند. علت روشن است؛ تصمیم درباره‌ی مرز واژه گاهی به نقش دستوری، بافت و شیوه‌ی پذیرفته‌شده وابسته است.

• ابزارها چه می‌کنند و چه نمی‌کنند؟

Hazm و Parsivar مجموعه‌ای از امکانات پردازش فارسی مانند نرمال‌سازی، جداسازی جمله و واژه، ریشه‌یابی یا تحلیل صرفی عرضه می‌کنند (Mohtaj et al., 2018). ParsiNorm بیشتر با هدف نرمال‌سازی برای کاربردهای گفتاری طراحی شده و نشانه‌ها، تاریخ، ساعت و عدد را نیز به شکل قابل تلفظ تبدیل می‌کند (Oji et al., 2021). انتخاب ابزار باید تابع کاربرد باشد؛ نرمال‌سازی متن برای جست‌وجوی سایت با آماده‌سازی ورودی سامانه‌ی تبدیل متن به گفتار یکسان نیست.

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

۵. لایه‌ی سوم: توکن‌ سازی

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

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

• یک آزمایش کوچک توکن‌ شماری

برای دیدن اندازه‌ی تقریبی اختلاف، ده جمله‌ی کوتاه فارسی در موضوع پردازش زبان نوشته شد و برای هرکدام یک ترجمه‌ی معنایی انگلیسی تهیه شد. مجموع تعداد توکن‌های هر زبان در چهار رمزگذاری عمومی کتابخانه‌ی tiktoken نسخه‌ی ۰٫۱۴٫۰ شمرده شد: r50k_base، p50k_base، cl100k_base و o200k_base. هیچ پیام سیستمی، قالب گفت‌وگو یا توکن ویژه‌ای افزوده نشد. آزمایش در ۲۵ شهریور ۱۴۰۵ اجرا شد و فقط طول متن خام را می‌سنجد. متن کامل هر ده جفت جمله در ادامه آمده است.

رمزگذاری توکنایزر	توکن فارسی	توکن انگلیسی	نسبت فارسی به انگلیسی
r50k_base	۵۵۲	۹۶	۵٫۷۵
p50k_base	۵۵۲	۹۶	۵٫۷۵
cl100k_base	۳۵۹	۹۵	۳٫۷۸
o200k_base	۱۵۸	۹۵	۱٫۶۶

در این نمونه، r50k_base و p50k_base برای متن فارسی ۵٫۷۵ برابر متن انگلیسی توکن تولید کردند؛ این نسبت در cl100k_base به ۳٫۷۸ و در o200k_base به ۱٫۶۶ رسید. این کاهش نشان می‌دهد «جریمه‌ی توکن فارسی» عدد ثابتی نیست و با رمزگذاری توکنایزر و متن نمونه تغییر می‌کند. بنابراین هر عدد باید همراه نام رمزگذاری، متن نمونه، نسخه‌ی ابزار و تاریخ اندازه‌گیری منتشر شود.

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

• محدودیت‌های آزمایش

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

• متن کامل نمونه‌ی آزمایش

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

ردیف	جمله‌ی فارسی	ترجمه‌ی معنایی انگلیسی
1	مدل زبانی متن را به توکن‌های کوچک‌تر تقسیم می‌کند.	A language model splits text into smaller tokens.‎
2	نیم‌فاصله می‌تواند مرز توکن‌ها را تغییر دهد.	The zero-width non-joiner can change token boundaries.‎
3	نویسه‌های فارسی و عربی همیشه کد یکسانی ندارند.	Persian and Arabic characters do not always share the same code.‎
4	توکن بیشتر لزوما به معنای فهم ضعیف‌تر نیست.	More tokens do not necessarily mean weaker understanding.‎
5	کیفیت داده آموزشی بر عملکرد مدل اثر می‌گذارد.	Training data quality affects model performance.‎
6	مدل معنا را با توجه به بافت جمله بازنمایی می‌کند.	The model represents meaning according to sentence context.‎
7	متن فارسی باید پیش از پردازش نرمال‌سازی شود.	Persian text should be normalized before processing.‎
8	پنجره بافت ظرفیت ورودی مدل را محدود می‌کند.	The context window limits the model input capacity.‎
9	ترجمه می‌تواند دشواری یک پرسش را تغییر دهد.	Translation can change the difficulty of a question.‎
10	شمارش توکن به تنهایی کیفیت پاسخ را پیش‌بینی نمی‌کند.	Token count alone does not predict response quality.‎

• سه پیامد قطعی‌تر توکن بیشتر

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

• از شناسه‌ی توکن به بازنمایی بافتی

شناسه‌ی عددی توکن به‌خودی‌خود معنا ندارد. مدل ابتدا هر شناسه را به یک بردار اولیه تبدیل می‌کند و سپس، با توجه به جایگاه و توکن‌های اطراف در معماری ترنسفورمر (Vaswani et al., 2017)، آن را در لایه‌های مختلف پردازش می‌کند. به همین دلیل، بازنمایی واژه‌ی «شیر» در جمله‌ی «شیر آب را ببند» با بازنمایی آن در جمله‌ی «شیر در جنگل زندگی می‌کند» یکسان باقی نمی‌ماند.

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

۶. آیا توکن بیشتر یعنی فهم ضعیف‌تر؟

استدلال شهودی جذاب است: اگر واژه‌ای به قطعه‌های بیشتری شکسته شود، مدل باید از گام‌های بیشتری معنای آن را بسازد؛ پس احتمالا خطای بیشتری رخ می‌دهد. پژوهش‌های کنترل‌شده نیز نشان داده‌اند انتخاب توکنایزر می‌تواند هزینه‌ی آموزش و عملکرد پایین‌دستی را تغییر دهد. برای نمونه، مطالعه‌ی Ali et al. (2024) با عنوان «Tokenizer Choice For LLM Training: Negligible or Crucial?» با آموزش ۲۴ مدل تک‌زبانه و چندزبانه در مقیاس ۲٫۶ میلیارد پارامتر گزارش کرد که انتخاب توکنایزر می‌تواند مهم باشد و توکنایزر انگلیسی‌محور در محیط چندزبانه به افت عملکرد و افزایش هزینه‌ی آموزش منجر شود. این پژوهش پنج زبان اروپایی پرکاربرد — انگلیسی، آلمانی، فرانسوی، ایتالیایی و اسپانیایی — را بررسی کرد، نه فارسی؛ از آن می‌توان اصل کلی اهمیت انتخاب توکنایزر را نتیجه گرفت، اما اندازه‌ی دقیق اثر را نباید بدون آزمایش مستقل به فارسی تعمیم داد.

اما همان پژوهش نکته‌ی مهم‌تری هم دارد: معیارهای ساده‌ی کارایی مانند fertility یا parity همیشه عملکرد پایین‌دستی را پیش‌بینی نمی‌کنند. یعنی از روی نسبت تعداد توکن به کلمه نمی‌توان با اطمینان گفت مدل در پرسش‌پاسخ، استدلال یا خلاصه‌سازی چند درصد ضعیف‌تر خواهد بود. توکن‌سازی با داده‌ی پیش‌آموزش، معماری، اندازه‌ی مدل، تنظیم آموزشی و نوع وظیفه تعامل دارد. یافته‌ای هم‌راستا از پژوهش Bean et al. (2024) روی بنچمارک LingOly هم به دست آمده: در مقایسه‌ی کارایی توکن‌سازی با عملکرد مدل‌ها روی معماهای زبان‌شناسی زبان‌های کم‌منبع، هیچ نشانه‌ای از اینکه توکن‌سازی مانع عملکرد باشد دیده نشد.

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

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

۷. بنچمارک‌های فارسی چه می‌گویند؟

مطالعه‌ی Abaskohi et al. (2024) با عنوان «Benchmarking Large Language Models for Persian» در LREC-COLING — که عمدتا GPT-3.5، GPT-4 و OpenChat-3.5 را ارزیابی کرد — یکی از نخستین ارزیابی‌های جامع مدل‌های زبانی روی مجموعه‌ای از وظایف کلاسیک، استدلالی و دانش‌محور فارسی است. نویسندگان گزارش کردند مدل‌های بزرگ، به‌ویژه GPT-4، در استدلال و دانش عمومی توانمند بودند، اما در برخی وظایف از مدل‌های کوچک‌ترِ مخصوص همان وظیفه عقب ماندند. این یافته یادآوری می‌کند که «مدل بزرگ‌تر» همیشه برای هر مسئله‌ی فارسی بهترین انتخاب نیست.

در همان پژوهش، ترجمه‌ی مجموعه‌های آزمون به انگلیسی پیش از ورود به GPT-3.5 در مواردی عملکرد را بهتر کرد. مرز تعمیم این نتیجه حیاتی است: پژوهش درباره‌ی زبان ورودی آزمون بود، نه این ادعا که محتوای وب فارسی باید انگلیسی نوشته شود. تغییر زبان می‌تواند خودِ مسئله، نشانه‌های فرهنگی و دشواری سؤال را تغییر دهد. از این یافته فقط می‌توان گفت مدل مورد آزمایش در آن تنظیم با نسخه‌ی انگلیسی عملکرد بهتری داشته است.

بهترشدن عملکرد در نسخه‌ی انگلیسی آزمون می‌تواند با عوامل مختلفی مرتبط باشد: سهم بیشتر داده‌های انگلیسی در آموزش، کیفیت متفاوت توکن‌سازی، آشنایی بیشتر مدل با الگوهای دستوردهی انگلیسی، یا تغییر دشواری سؤال پس از ترجمه. پژوهش Abaskohi et al. (2024) سهم مستقل هیچ‌کدام از این عوامل را اندازه‌گیری نکرده است؛ بنابراین از این یافته نمی‌توان درباره‌ی ساختار دقیق فضای برداری مدل نتیجه گرفت.

• توهم‌زایی و فارسی

نویسندگان PerHalluEval، یعنی Hosseini et al. (2026؛ که ابتدا در سال ۲۰۲۵ به‌صورت پیش‌چاپ منتشر و سپس در LREC 2026 داوری و چاپ شد)، آن را نخستین بنچمارک پویای ویژه‌ی سنجش توهم در فارسی معرفی می‌کنند. ارزیابی ۱۲ مدل نشان داد مدل‌ها در تشخیص متن توهم‌آمیز فارسی عموما مشکل دارند؛ در وظیفه‌ی خلاصه‌سازی، ارائه‌ی سند اصلی به مدل توانست بخشی از این خطا را کاهش دهد، هرچند این نتیجه لزوما به هر نوع سند بیرونی یا هر وظیفه‌ی دیگری تعمیم‌پذیر نیست. نویسندگان همچنین تفاوت معناداری میان مدل‌های ویژه‌ی فارسی و دیگر مدل‌ها در معیار توهم گزارش نکردند.

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

۸. لایه‌ی زیرساخت و دسترسی از ایران

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

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

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

۹. چه کاری از دست ناشر و برند برمی‌آید؟

• نویسه‌ها را پیش از انتشار نرمال کنید

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

• نیم‌فاصله را به تصمیم فنی تبدیل کنید

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

• موجودیت‌ها را بی‌ابهام بنویسید

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

• دسترسی خزنده را پیش از ظرافت‌های محتوایی حل کنید

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

• کارهایی که پشتوانه‌ی کافی ندارند

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

  گم شود

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

۱۰. آنچه هنوز نمی‌دانیم

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

• سربار توکن فارسی در توکنایزرهای مدل‌های روز و در ژانرهای مختلف چقدر است؟
• آیا یکدست‌کردن نیم‌فاصله، با ثابت نگه‌داشتن سایر عوامل، اثر قابل اندازه‌گیری بر بازیابی یا پاسخ دارد؟
• مدل‌های چندزبانه روابط فرهنگی و موجودیت‌های فارسی را در فضای برداری چگونه جای می‌دهند؟
• در متن فارسی، اطلاعات ابتدای سند، میانه و انتها چه تفاوتی در بازیابی و پاسخ ایجاد می‌کنند؟
• روش‌های اثبات‌شده در «GEO چیست؟» تا چه اندازه در محتوای فارسی همان نتیجه را تکرار می‌کنند؟

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

جمع‌بندی

ماشین فارسی را در یک جهش از جمله به معنا نمی‌برد. ابتدا نویسه‌ها را می‌بیند، سپس مرزها را بر اساس توکنایزر می‌سازد و بعد از بافت، نمایش عددی و احتمال توکن بعدی استفاده می‌کند. فارسی در این مسیر با ناپایداری نویسه، نیم‌فاصله، ساخت‌واژه‌ی غنی و داده‌ی کمتر روبه‌روست. این ویژگی‌ها می‌توانند تعداد توکن، ظرفیت موثر و هزینه را تغییر دهند. آزمایش کوچک ما نیز نشان داد نسبت توکن فارسی به انگلیسی در رمزگذاری‌های بررسی‌شده از ۵٫۷۵ در r50k_base و p50k_base به ۱٫۶۶ در o200k_base رسید؛ پس هیچ «عدد ثابت» برای فارسی وجود ندارد.

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

واژه‌نامه

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

توکنایزر: قاعده و واژگانی که متن را به توکن‌ها تبدیل می‌کند.

نرمال‌سازی: تبدیل شکل‌های متفاوت و هم‌معنا یا هم‌کارکرد به یک قرارداد نوشتاری ثابت.

نیم‌فاصله: نویسه‌ی U+200C یا ZWNJ که اتصال حروف را می‌شکند، بدون آنکه فاصله‌ی کامل بسازد.

پنجره‌ی بافت: حداکثر توکن‌هایی که مدل در یک نوبت پردازش می‌کند.

بنچمارک: مجموعه‌ داده و روش ارزیابی استاندارد برای مقایسه‌ی سامانه‌ها.

توهم: تولید محتوای نادرست یا بی‌پشتوانه با ظاهر پاسخ معتبر.

منابع

پژوهش‌های داوری‌شده

• Doostmohammadi, Nassajian & Rahimi (2020). Joint Persian Word Segmentation Correction and Zero-Width Non-Joiner Recognition Using BERT. COLING, F1=92.40% on 500 sentences. https://aclanthology.org/2020.coling-main.406/ (DOI: 10.18653/v1/2020.coling-main.406)
• Mohtaj et al. (2018). Parsivar: A Language Processing Toolkit for Persian. LREC. https://aclanthology.org/L18-1179/
• Oji et al. (2021). ParsiNorm: A Persian Toolkit for Speech Processing Normalization. 2021 7th International Conference on Signal Processing and Intelligent Systems (ICSPIS), IEEE. https://arxiv.org/abs/2111.03470
• Abaskohi et al. (2024). Benchmarking Large Language Models for Persian: A Preliminary Study Focusing on ChatGPT. LREC-COLING. https://arxiv.org/abs/2404.02403
• Ali et al. (2024). Tokenizer Choice For LLM Training: Negligible or Crucial? Findings of NAACL (languages studied: English, German, French, Italian, Spanish). https://aclanthology.org/2024.findings-naacl.247/ (DOI: 10.18653/v1/2024.findings-naacl.247)
• Ghahroodi et al. (2024). Khayyam Challenge (PersianMMLU): Is Your LLM Truly Wise to The Persian Language? Published as a conference paper at COLM 2024. https://arxiv.org/abs/2404.06644
• Khashabi et al. (2021). ParsiNLU: A Suite of Language Understanding Challenges for Persian. Transactions of the ACL (TACL), vol. 9. https://arxiv.org/abs/2012.06154
• Darvishi et al. (2023). PQuAD: A Persian Question Answering Dataset. Computer Speech & Language, 80:101486. https://arxiv.org/abs/2202.06219
• Bean et al. (2024). LINGOLY: A Benchmark of Olympiad-Level Linguistic Reasoning Puzzles in Low-Resource and Extinct Languages. NeurIPS Datasets and Benchmarks Track. https://arxiv.org/abs/2406.06196
• Vaswani et al. (2017). Attention Is All You Need. NeurIPS. https://arxiv.org/abs/1706.03762
• Bourbour Hosseinbeigi et al. (2026). Advancing Retrieval-Augmented Generation for Persian. LREC. https://aclanthology.org/2026.lrec-1.580/ (DOI: 10.63317/2ev2hvzqjmwh)
• Hosseini et al. (2026). PerHalluEval: Persian Hallucination Evaluation Benchmark for Large Language Models. LREC. https://aclanthology.org/2026.lrec-1.243/ (DOI: 10.63317/3xhrjewfcyrm)

ابزار و مستندات فنی

• tiktoken v0.14.0, public tokenizer library and encodings used for the token-count experiment. https://github.com/openai/tiktoken
• Unicode Consortium. The Unicode Standard and UTF-8 encoding. https://www.unicode.org/standard/standard.html
• Unicode Consortium. UAX #9: Unicode Bidirectional Algorithm. https://www.unicode.org/reports/tr9/
• IETF (Yergeau, F., 2003). RFC 3629: UTF-8, a transformation format of ISO 10646. https://www.rfc-editor.org/rfc/rfc3629
• Unicode Consortium. General Punctuation code chart (defines U+200C ZERO WIDTH NON-JOINER). https://www.unicode.org/charts/PDF/U2000.pdf
• Roshan-AI. Hazm (v0.12.1): Python library for Persian NLP. The normalization test in this article was run with this exact version and is directly reproducible. https://www.roshan-ai.ir/hazm/