ضريبة الرموز في النص الفارسي: كم تكلّف تطبيقات LLM بغير الإنجليزية؟

على ١٬٠١٢ جملة متوازية، احتاجت الفارسية ١٫٥٣ ضعف رموز الإنجليزية مع مُقطِّع GPT-4o و٣٫٢٦ ضعف مع مُقطِّع GPT-4. المنهج والنتائج وما ينبغي اختباره.

يكلّف النص الفارسي رموزًا أكثر من الإنجليزي لإيصال المحتوى نفسه. هذه الزيادة هي ضريبة الرموز في الفارسية، وحجمها يعتمد على المُقطِّع (tokenizer) أكثر مما يعتمد على الخط. أحصيتُ الرموز (tokens) في ١٬٠١٢ جملة متوازية بالإنجليزية والفارسية من معيار FLORES-200. احتاجت الفارسية ١٫٥٣ ضعف عدد رموز الإنجليزية مع o200k_base، وهو الترميز الذي تربطه مكتبة tiktoken من OpenAI بنموذج GPT-4o، و٣٫٢٦ ضعف مع cl100k_base، الذي تربطه المكتبة نفسها بنموذج GPT-4. وهذان الرقمان هما طرفا المدى بين المُقطِّعات الأربعة التي تستخدمها نماذج توليد النص؛ أما bge-m3، وهو مُقطِّع نموذج تضمين (embedding)، فجاء عند ١٫١٠ ضعف. لا يشمل هذا القياس Claude ولا Gemini: فشركة Anthropic لا تنشر مُقطِّع Claude، ولم أقِس المُقطِّع المحلي الذي تتيحه حزمة Google لنماذج Gemini. وكلتا الشركتين تحصي الرموز لنماذجها عبر واجهة برمجية.

وهذه الأرقام لقطة مؤرَّخة: أُجري القياس في ١٧ سبتمبر ٢٠٢٦ بإصدارات مثبَّتة من المُقطِّعات.

لماذا يستهلك النص الفارسي رموزًا أكثر؟ البايتات والدمج وبيانات التدريب

تحاسب واجهات نماذج اللغة على أساس الرمز. في عام ٢٠٢٣ وجد Ahia وزملاؤه أدلة على أن «متحدثي عدد كبير من اللغات المدعومة يدفعون أكثر مما ينبغي بينما يحصلون على نتائج أضعف». وأظهر Petrov وزملاؤه أن النص نفسه، مترجمًا إلى لغات مختلفة، قد يختلف طوله بالرموز «بما يصل إلى ١٥ ضعفًا في بعض الحالات». وتذكر دراسة من عام ٢٠٢٥ شملت أكثر من مئتي لغة أن اللغات غير اللاتينية الخط واللغات ذات البنية الصرفية المعقدة تسجّل نسب RTC «أعلى بمقدار ٣ إلى ٥ أضعاف في الغالب»، وRTC عند الباحثَين هو اختصار «Relative Tokenization Cost»، أي التكلفة النسبية للترميز.

تلك هي ضريبة الرموز: المعنى نفسه، وفاتورة أكبر.

البايتات هي نقطة البداية لكل مُقطِّع يعمل على مستوى البايت

مُقطِّع BPE على مستوى البايت (وBPE اختصار byte-pair encoding)، وهو النوع الذي تقوم عليه GPT-4o وQwen3 وDeepSeek-V3، يبدأ من بايتات النص في ترميز UTF-8 ثم يدمج تسلسلات البايتات المتكررة ليصنع منها رموزًا. الحرف اللاتيني غير المُشكَّل بايت واحد، أما حروف اليوروبا التي تحمل علامات نبر أو نقطة سفلية فتأخذ بايتين أو أكثر. والحرف الفارسي بايتان، وZWNJ الذي يفصل داخل الكلمة الفارسية ثلاثة بايتات. في FLORES بلغ الملف الفارسي ١٫٦٩ ضعف حجم الملف الإنجليزي بالبايتات في ترميز UTF-8، مع ٠٫٩٤ ضعف عدد محارفه. الفارسية ليست أطول من حيث المحارف، بل أثقل من حيث الترميز.

وما يحدث بعد ذلك يتوقف على عمليات الدمج التي تعلّمها المُقطِّع من بيانات تدريبه. الانتقال من cl100k_base إلى o200k_base خفّض رموز الفارسية بنسبة ٥٣٫٥٪ ورموز الإنجليزية بنسبة ١٫١٪. المفردات الأحدث غيّرت وضع الفارسية، لا وضع الإنجليزية.

اليوروبا تدفع أكثر رغم كتابتها بالخط اللاتيني

لو كان الخط هو ما يحدّد الضريبة لكادت اللغات المكتوبة بالحرف اللاتيني تُعفى منها. في ورقة بحثية أعدّها Roy وRoy وPatel، قُبلت في إحدى ورش IJCAI 2026 وأُتيحت على arXiv منذ أغسطس ٢٠٢٦، وجد الباحثون أن اليوروبا «رغم استخدامها الخط اللاتيني، تسجّل أعلى علاوة ترميز في GPT-4o» ضمن مراجعتهم، عند ٢٫٣٧ ضعف. ويرجّح المؤلفون أن السبب علامات التشكيل (diacritics) ومدى تغطية المفردات. واليوروبا في تلك الورقة مقارنة استكشافية: تُرجمت نصوصها آليًّا ثم رُوجعت يدويًّا، بينما الحالتان المعتمدتان فيها هما البنغالية والهندية.

وقياسي يشير إلى الاتجاه نفسه. كلّفت اليوروبا أكثر من الفارسية في أربعة مُقطِّعات من الخمسة، وكلّفت العربية أقل من الفارسية في أربعة من الخمسة كذلك. والاستثناء في حالة العربية هو bge-m3، وهو نموذج تضمين مبني على XLM-RoBERTa ومفرداتها. دُرِّبت XLM-R على مئة لغة مأخوذة من CC-100: ١٣٬٢٥٩ مليون رمز فارسي مقابل ٢٬٨٦٩ مليون رمز عربي، ولم تكن اليوروبا بينها. وهذا متسق مع أن حصة اللغة في بيانات التدريب أهم من خطها، لكنه لا يثبته.

النتائج: الفارسية والعربية واليوروبا في مواجهة الإنجليزية

كل خانة هي مجموع رموز اللغة مقسومًا على مجموع رموز الإنجليزية عند المُقطِّع نفسه:

المُقطِّع هو المتغيّر الأكبر. نسبة الفارسية عند أسوأ مُقطِّع (٣٫٢٦ ضعف) تعادل نحو ثلاثة أمثال نسبتها عند أفضلها (١٫١٠ ضعف)، وتعادل نحو الضعفين حتى بين المُقطِّعات الأربعة المستخدمة في التوليد (٣٫٢٦ ضعف مقابل ١٫٥٣ ضعف). ويتعامل Qwen3 مع العربية بكفاءة أعلى بكثير من تعامله مع الفارسية، ١٫٦٣ ضعف مقابل ٢٫٥٨ ضعف، فلا يصلح رقم واحد للخط العربي ليمثّل اللغتين معًا. ونتيجة cl100k_base متسقة مع إحصاءات منشورة سابقًا: أرقام Petrov وزملائه لأطوال FLORES-200، بعد ضمّ قسمَي dev وdevtest، تضع الفارسية الغربية عند ٣٫٢٨ ضعف الإنجليزية، مقابل ٣٫٢٦ ضعف في قياسي على قسم devtest وحده.

وهذه هي المجاميع التي نشأت عنها تلك النسب، ومعها حجم ملف كل لغة قبل أن يلمسه أي مُقطِّع:

مدوّنتك النصية ستعطي رقمًا مختلفًا

قاست مراجعة Roy وزملائه المُقطِّع o200k_base على ١٢٠ عنصرًا من تمارين تصحيح أخطاء Python مترجمة عن الإنجليزية، وحسبت المتوسط لكل عنصر. وتذكر أن العربية عند ١٫٤٤ ضعف واليوروبا عند ٢٫٣٧ ضعف، وكلتاهما من ترجمة آلية. أما على نثر FLORES الذي ترجمه بشر، فأعطى o200k_base نفسه العربية ١٫٣٨ ضعف واليوروبا ٢٫١٧ ضعف. المُقطِّع نفسه، ونص وطريقة ترجمة مختلفان، ونتيجة مختلفة. فاحسب رموز موجّهاتك ومقاطعك المسترجَعة وإجاباتك قبل أن تضع الميزانية.

كيف قِستُ عدد الرموز في النص الفارسي

مدوّنة نصية متوازية فعلًا

يصف فريق NLLB مجموعة FLORES-200 بأنها «معيار مترجَم بشريًّا»: الجمل نفسها، بالترتيب نفسه، في كل لغة. استخدمتُ قسم devtest منها، المرخَّص بموجب CC BY-SA 4.0، من الأرشيف الرسمي بعد التحقق من بصمة SHA-256: ١٬٠١٢ جملة من Wikinews وWikivoyage وWikibooks، بالإنجليزية والفارسية الغربية والعربية الفصحى المعاصرة واليوروبا.

التوازي أهم من الحجم. الترجمة بتصرّف، كسيرة ذاتية مُعدَّة بلغتين، تضيف وتحذف وتعيد الصياغة، فتقيس نسبتها التحرير بقدر ما تقيس المُقطِّع. ولدى FLORES حدّها الخاص: فهي نثر أخبار وأدلة سفر وكتب تعليمية، لا محادثات ولا شفرة برمجية ولا عقود.

مُقطِّعات مفتوحة بإصدارات مثبَّتة، ولماذا يغيب Claude وGemini

خمسة مُقطِّعات، كلها قابلة للتنزيل دون حساب:

• مكتبة tiktoken 0.14.0: cl100k_base وo200k_base. تربط tiktoken نموذجَي GPT-4 وGPT-3.5 Turbo بالأول، وGPT-4o وo1 وo3 وGPT-4.1 وGPT-5 بالثاني.

• Qwen3 (Qwen/Qwen3-8B) وDeepSeek-V3 (deepseek-ai/DeepSeek-V3)، وكلاهما BPE على مستوى البايت، حُمِّلا بمكتبة tokenizers 0.23.2 من Hugging Face عند نسخ مثبَّتة في Hub.

• bge-m3 (BAAI/bge-m3)، وهو نموذج تضمين مُقطِّعه نموذج Unigram من نوع SentencePiece بمفردات XLM-R، لا BPE على مستوى البايت. وUnigram خوارزمية مختلفة: تختار أرجح تقسيم للنص من مفردات ثابتة. وأهميته في الاسترجاع لا في التوليد.

رُمِّزت كل جملة على حدة، دون رموز خاصة، ثم جُمعت الأعداد. ووسائط النسب على مستوى الجملة الواحدة تحكي القصة نفسها التي تحكيها المجاميع. ويتلخّص جوهر العملية في بضعة أسطر:

# after: tar -xzf flores200_dataset.tar.gz
import tiktoken
from huggingface_hub import hf_hub_download
from tokenizers import Tokenizer


def sentences(lang):
    with open(f"flores200_dataset/devtest/{lang}.devtest", encoding="utf-8") as f:
        return f.read().rstrip("\n").split("\n")


english, persian = sentences("eng_Latn"), sentences("pes_Arab")

o200k = tiktoken.get_encoding("o200k_base")
qwen3 = Tokenizer.from_file(
    hf_hub_download(
        "Qwen/Qwen3-8B",
        "tokenizer.json",
        revision="b968826d9c46dd6066d109eabc6255188de91218",
    )
)


def o200k_tokens(texts):
    return sum(len(o200k.encode_ordinary(t)) for t in texts)


def qwen3_tokens(texts):
    return sum(len(qwen3.encode(t, add_special_tokens=False).ids) for t in texts)


print(round(o200k_tokens(persian) / o200k_tokens(english), 2))
print(round(qwen3_tokens(persian) / qwen3_tokens(english), 2))

وسجلّ القياس، وفيه ما يكفي لتكرار التشغيل بحذافيره:

corpus: https://dl.fbaipublicfiles.com/nllb/flores200_dataset.tar.gz
sha256: b8b0b76783024b85797e5cc75064eb83fc5288b41e9654dabc7be6ae944011f6
split: devtest
measured: 2026-09-17
libraries:
  tiktoken: 0.14.0
  tokenizers: 0.23.2
  huggingface_hub: 1.31.0
encodings: [cl100k_base, o200k_base]
hub_revisions:
  Qwen/Qwen3-8B: b968826d9c46dd6066d109eabc6255188de91218
  deepseek-ai/DeepSeek-V3: e815299b0bcbac849fa540c768ef21845365c9eb
  BAAI/bge-m3: 5617a9f61b028005a4858fdac845db406aefb181
method: each sentence encoded on its own, no special tokens, counts summed per language

غياب Claude وGemini مقصود. لا تنشر Anthropic مُقطِّع Claude، فأي نسبة أذكرها عن Claude ستكون تخمينًا بفاصلة عشرية. وتأتي حزمة Google Gen AI للغة Python بمُقطِّع محلي تجريبي للنص فقط يربط بعض نماذج Gemini بمُقطِّعات Gemma المفتوحة، ولم أقِسه. وكلتا الشركتين تحصي الرموز نيابةً عنك: نقطة النهاية count_tokens لدى Anthropic مجانية لكنها محدودة المعدل، وتصف وثائقها النتيجة بأنها «تقدير»؛ وcount_tokens لدى Gemini تحصي المُدخل. وتستخدم نماذج Claude 4.7 وما بعدها مُقطِّعًا أحدث، والنص المُدخل نفسه فيها ينتج «رموزًا أكثر بنحو ٣٠ بالمئة مما ينتجه في النماذج الأسبق». عدد الرموز ملك للنموذج لا للشركة.

حدّان يصمدان وحدّ لا يصمد

في مُقطِّعات BPE على مستوى البايت التي تقسّم النص إلى رموز أولية قبل الدمج، وهي حال المُقطِّعات الأربعة هنا، يؤطّر العدَّ حدّان. لا يمكن أن يتجاوز عدد الرموز عدد بايتات النص في ترميز UTF-8 بعد تطبيع المُقطِّع له، لأن كل رمز يغطي بايتًا واحدًا على الأقل. ولا يمكن أن يقل عن عدد الرموز الأولية الخاصة بالمُقطِّع نفسه، أي القطع التي يشقّ بها نمطُ تقسيمه النصَّ، لأن عمليات الدمج لا تعبر حدود الرمز الأولي أبدًا. تحققتُ من الحدّين جملةً جملةً على المُقطِّعات الأربعة العاملة على مستوى البايت وعلى اللغات الأربع جميعًا: ١٦٬١٩٢ فحصًا، دون مخالفة واحدة.

وتعرض ساحة تجربة المُقطِّع في هذا الموقع كلا الرقمين لأي نص تكتبه، محسوبَين داخل المتصفح: تقسيم الرموز الأولية في cl100k_base، وبايتات النص في ترميز UTF-8. وفي cl100k_base يقع العدد الحقيقي بينهما، وهو ما يقوله الشرح أسفل كل لوحة.

والحد الأدنى ملك لمُقطِّع بعينه. فتقسيم cl100k_base ليس أرضيةً بالنسبة إلى o200k_base: في ٢٨ جملة إنجليزية احتاج o200k_base رموزًا أقل مما ينتجه cl100k_base من رموز أولية. ولا ينطبق أي من الحدّين على نموذج Unigram في bge-m3.

كيف تؤثر ضريبة الرموز في التكلفة وزمن الاستجابة ونافذة السياق وحدود المعدل

التكلفة

يحاسب مزوّدو الواجهات البرمجية على الرموز التي يعالجها النموذج ويولّدها. وبالسعر نفسه للرمز الواحد، يكلّف المحتوى نفسه بالفارسية نحو ضعف ونصف تكلفته بالإنجليزية مع o200k_base، وأكثر من ثلاثة أضعافها مع cl100k_base. وحين يكون الموجّه والإجابة بالفارسية معًا، تسري الزيادة على طرفَي الفاتورة.

زمن الاستجابة

رموز المُخرج هي التي تحدّد الإيقاع. يقول دليل زمن الاستجابة لدى OpenAI إن «خفض ٥٠٪ من رموز مُخرجك قد يخفض نحو ٥٠٪ من زمن استجابتك». أما تقليم الموجّه فأثره أقل بكثير: «خفض ٥٠٪ من موجّهك قد لا يعطي سوى تحسين بنسبة ١ إلى ٥٪ في زمن الاستجابة». والإجابة الفارسية التي تحتاج رموزًا أكثر من نظيرتها الإنجليزية يستغرق بثّها وقتًا أطول. وهذا تطبيق لتوجيه المزوّد على النسب أعلاه، لا قياس أجريته لزمن الاستجابة.

نافذة السياق

النافذة ذات السعة الثابتة تستوعب فارسية أقل. وبالقسمة على النسب، تستوعب النافذة نفسها من المحتوى الفارسي ما يعادل ٣١٪ مما تستوعبه بالإنجليزية مع cl100k_base، و٣٩٪ مع Qwen3، و٥٦٪ مع DeepSeek-V3، و٦٥٪ مع o200k_base، و٩١٪ مع bge-m3، في هذه المدوّنة. وتذكر مراجعة Roy وزملائه النقطة نفسها عن البنغالية، التي تخفض علاوتها البالغة ١٫٥٦ ضعف في GPT-4o «نافذة سياق اسمية بسعة ١٢٨ ألف رمز إلى سعة فعلية تعادل ٨٢ ألف رمز إنجليزي». وفي موجّه RAG يعني ذلك مساحة لمقاطع مسترجَعة أقل.

حدود المعدل

حدود المعدل تُحسب بالرموز أيضًا. فحدود واجهة Claude «تُقاس بالطلبات في الدقيقة (RPM)، ورموز المُدخل في الدقيقة (ITPM)، ورموز المُخرج في الدقيقة (OTPM)». وتحت سقف الرموز في الدقيقة، يصل العبء الذي يستهلك رموزًا أكثر في كل طلب إلى السقف بعدد أقل من الطلبات، وهو ما فعلته الفارسية في كل مُقطِّع قِسته هنا. وفي معظم نماذج Claude لا تُحتسب قراءات الذاكرة المؤقتة ضمن حد المُدخل.

تطبيع النص: ما يوفّر الرموز وما يكسر الاسترجاع

في الكتابة الفارسية خاصيتان تبدوان طريقًا رخيصًا لتوفير الرموز. وكلتاهما فخّ.

ZWNJ (مانع الوصل) محرف لا مسافة

المحرف U+200C المسمّى ZERO WIDTH NON-JOINER تصنيفه العام في يونيكود هو Cf، أي محرف تحكّم بالتنسيق لا محرف مسافة. وهو يمنع اتصال الحرفين على جانبيه، فتُقرأ «می‌شود» كلمةً واحدة بفاصل مرئي. ويستخدمه الملف الفارسي في FLORES ١٬٧٣٩ مرة، في ٧٣٥ جملة من جمله البالغة ١٬٠١٢.

واستبدال مسافة بكل محرف ZWNJ خفّض عدد الرموز الفارسية بنسبة ١٫٥٩٪ مع cl100k_base، و١٫٨٢٪ مع o200k_base، و١٫٥٧٪ مع Qwen3، و٨٫٠٨٪ مع DeepSeek-V3، ولم يغيّره في bge-m3 (٠٫٠٠٪). ولم يتحرك bge-m3 لأن مطبِّعه يحوّل ZWNJ إلى مسافة أصلًا: احتفظت الجمل المتغيّرة كلها، وعددها ٧٣٥، بمعرّفات الرموز نفسها.

التوفير ضئيل في ثلاثة مُقطِّعات وأكبر في DeepSeek-V3، لكنه يغيّر النص: كلمة واحدة تصير كلمتين، وما تخزّنه أو تعرضه أو تقتبسه لم يعد ما كتبه صاحبه. احتفظ بمحرف ZWNJ في النص المخزَّن، وقرّر على حدة ما الذي يعدّه المطابِق متساويًا. وهذا ما يفعله هذا الموقع بالضبط: التطبيع المستخدم داخل المقارنات وحده هو الذي يعامل ZWNJ معاملة المسافة.

الياء والكاف العربيتان مقابل الياء والكاف الفارسيتين

الياء العربية (U+064A) والياء الفارسية (U+06CC) محرفان مختلفان، وكذلك الكاف العربية (U+0643) والكاف الفارسية (U+06A9). في أول الكلمة ووسطها يبدوان متطابقين، وفي آخرها يختلفان. أما مقارنة النصوص فترى محرفين مختلفين دائمًا. وحتى FLORES يخلط بينهما: ملفه الفارسي يحوي ١١ ياء عربية و٢٢ كافًا عربية إلى جانب ٩٬٥٧٠ ياء فارسية و٢٬٩٥٧ كافًا فارسية.

وإعادة كتابة كل ياء وكاف فارسية في الملف الفارسي على الصورة العربية رفعت عدد الرموز بنسبة ٢٫٢٠٪ مع cl100k_base، و٩٫٤٩٪ مع o200k_base، و١٠٫٣٩٪ مع DeepSeek-V3، و١١٫٩٥٪ مع bge-m3، وخفضته بنسبة ٧٫٤٨٪ مع Qwen3 وحده. فإعادة الكتابة التي توفّر الرموز عند مُقطِّع واحد تكلّفها عند المُقطِّعات الأربعة الأخرى.

والمسألة الحقيقية هي الاسترجاع. فإذا استخدم النص المخزَّن والاستعلام نقاط ترميز مختلفة، تفشل المطابقة التامة والمعجمية بصمت. وهذا الموقع يطبّع النص الفارسي عند الكتابة: تعود الياء العربية والكاف العربية إلى صورتيهما الفارسيتين، ويبقى ZWNJ كما هو. ويطبّع استعلام البحث بالطريقة نفسها. ولولا ذلك لبحث استعلام مكتوب بالياء العربية عن محرف لا يحويه الفهرس، فلا يعود بشيء.

والقاعدة العامة أضيق من ذلك: طبّع النص الفارسي وحده، لأن الياء العربية والكاف العربية هما الحرفان الصحيحان في العربية. ومسترجِع هذا الموقع نفسه لا يميّز ذلك بعد؛ فهو يطبّق التطبيع الفارسي على المحتوى والأسئلة بكل اللغات، والعربية منها. ومقال البحث الهجين في RAG الفارسي يشرح هذه الثغرة ويغطي بقية جانب الاسترجاع.

الأرقام الفارسية

كتابة أرقام ASCII بالأرقام الفارسية رفعت عدد الرموز بنسبة تتراوح بين ٠٫٤٨٪ و١٫٤٧٪. وهذا ليس سببًا لتغيير ما يراه القارئ.

كيف تخفض تكلفة الرموز في النص الفارسي: اختبر ولا تفترض

اختبر كل بند من هذه على حركتك الفعلية قبل أن تعتمد عليه.

• اختر النموذج بنصّك أنت. على الجمل نفسها تراوحت نسبة الفارسية إلى الإنجليزية بين ١٫١٠ ضعف و٣٫٢٦ ضعف.

• احسب الرموز بنقطة النهاية التي يتيحها المزوّد. بالنسبة إلى Claude وGemini، لا تخبرك النسب المقيسة هنا بشيء.

• أعد الحساب عند تغيير النموذج. المُقطِّع الأحدث قادر على إزاحة كل ميزانية وضعتها.

• حدّد حجم المقاطع وميزانيات السياق بالرموز، ولكل لغة على حدة. السقف المحدَّد بالمحارف والمضبوط على الإنجليزية يستوعب رموزًا أكثر في الفارسية: من زيادة تقارب السدس مع bge-m3 إلى نحو ثلاثة أضعاف ونصف مع cl100k_base.

• قيّد طول المُخرج. رموز المُخرج تحرّك زمن الاستجابة والتكلفة معًا. وتقترح Anthropic طلب عدد من الجمل أو الفقرات بدل عدد من الكلمات.

• خزّن السياق المتكرر مؤقتًا، ثم قِس نسبة الإصابة. أي توفير يتوقف على تكرار بادئتك فعليًّا.

• عامِل موجّه النظام الإنجليزي كفرضية. يستهلك رموزًا أقل، لكن ليس لديّ قياس لأثره في الإجابات الفارسية.

• لا تحذف ZWNJ ولا تبدّل صور الحروف لتوفير الرموز. التوفير ضئيل أو غير مستقر، أما الضرر الواقع على النص والمطابقة فليس كذلك.

كيف تضع ميزانية رموز للنص الفارسي

قاعدة «كم محرفًا في الرمز» تخمين يختلف من مُقطِّع لآخر

تراوحت الفارسية بين ١٫٤٠ محرف للرمز الواحد مع cl100k_base و٣٫٦٨ مع bge-m3، وجاء o200k_base عند ٣٫٠١. وتراوحت الإنجليزية بين ٤٫٣٠ و٤٫٩١. وتقول وثائق Gemini من Google إن «الرمز يعادل نحو ٤ محارف»، وتقرن ذلك بعدد من الكلمات الإنجليزية: قاعدة مصوغة على مقاس الإنجليزية، لا قول عن الفارسية.

يبدو حجز رمز واحد لكل محرفين فارسيين سخيًّا. وقد كان هذا الموقع يفعل ذلك من قبل، ولهذا اختبرتُه على هذه الجمل: جاء دون العدد الحقيقي في الجمل الفارسية كلها، وعددها ١٬٠١٢، مع cl100k_base، وفي ٩٧٦ جملة مع Qwen3. وصمد مع o200k_base وbge-m3، وقصُر في ٦ جمل مع DeepSeek-V3. القاعدة الآمنة عند مُقطِّع قد تكون متفائلة عند الذي يليه، ولهذا لم يعد هذا الموقع يعمل بواحدة.

سقف قاطع: عدد البايتات

في BPE على مستوى البايت، يكون عدد بايتات النص كما يطبّعه المُقطِّع سقفًا قاطعًا، لكنه سقف فضفاض. فعلى مقياس يبدأ من صفر عند عدد الرموز الأولية وينتهي عند واحد عند عدد البايتات، وقعت الإنجليزية بين ٠٫٠١٥ و٠٫٠١٧: أي أن كل رمز أولي إنجليزي تقريبًا، وهو ما يعادل كلمة، يقابله رمز واحد. ووقعت الفارسية عند ٠٫٠٧ مع o200k_base وعند ٠٫٣١ مع cl100k_base: مقسّمة إلى قطع، لكنها بعيدة تمامًا عن مستوى البايتات. ولذلك فإن الحجز بالبايتات يحجز أكثر بكثير مما يلزم. وهذه هي المقايضة الصحيحة لسقف لا يجوز لأحد تجاوزه، والخاطئة لتوقّع تكلفة. أما مع Claude وGemini فاحسب بنقطتَي النهاية لديهما قبل الاستدعاء، وسجّل الاستهلاك الذي تبلّغان عنه بعده.

احجز قبل الاستدعاء، وسجّل بعده

يفصل مساعد هذا الموقع بين هاتين المهمتين. فقبل استدعاء نموذج اللغة يضيف تقديرًا للطلب (حدًّا أعلى لرموز الموجّه، مضافًا إليه سقف المُخرج كاملًا) إلى الإنفاق المسجَّل للشهر، ثم يقارن المجموع بحدّ شهري. وإذا تعذّرت قراءة عدّاد الإنفاق، فالسلوك الافتراضي هو المنع (fail closed). وعند الحد لا يُستدعى النموذج، ويرى القارئ إشعارًا بدل خطأ. وبعد الاستدعاء يسجّل الاستهلاك الذي يبلّغ عنه المزوّد. التقدير يقرّر فقط ما إذا كان للطلب أن يبدأ؛ أما المجموع الجاري فيأتي من أعداد الرموز التي يبلّغ عنها المزوّد.

ولكلا الشقّين حدّه، لكن في اتجاهين متعاكسين. فالتقدير السابق للاستدعاء يحسب الموجّه بطوله ببايتات ترميز UTF-8: السقف المذكور في القسم السابق، لا توقّعًا للتكلفة. وكل مفردات يمكن توجيه المساعد إليها هي BPE على مستوى البايت، فيصمد ذلك السقف مع أي نموذج يخاطبه وبأي لغة يكتب بها الزائر. وفي الفارسية يعني ذلك حجز أضعاف ما سيكلّفه الموجّه فعلًا، يُحتجَز لطلب واحد ولا يُسجَّل إنفاقًا أبدًا. وقد كان هذا التقدير يحسب الموجّه من قبل بقاعدة المحرفين لكل رمز التي اختُبرت أعلاه، والتي جاءت دون العدد الحقيقي في الجمل الفارسية كلها، وعددها ١٬٠١٢، مع cl100k_base. والحجز الأصغر من اللازم سقفٌ مخطئ في الاتجاه الوحيد الذي لا يجوز لسقف أن يخطئ فيه، ولهذا كان هذا القياس سبب تغييره: شرح دالة التقدير في شفرة الموقع يحيل إلى هذا التشغيل نفسه على ١٬٠١٢ جملة. وفي الحالين يُبنى المجموع الشهري من الاستهلاك المسجَّل لا من التقدير.

وعلى السجل أن يتعامل مع صمت محتمل. تبلّغ OpenAI وAnthropic كلتاهما عن رموز المُخرج بعد النص المولَّد، ويحذّر مرجع البث لدى OpenAI من أنه إذا قُطع البث أو أُلغي «فقد لا تصلك كتلة الاستهلاك الأخيرة». والبثّ الذي ينقطع مبكرًا، بفعل حارس بث أو بإغلاق لسان تبويب، ينتهي قبل وصول ذلك البلاغ، وكل محرف أنتجه فعلًا محسوب على الفاتورة. ولذلك يحتفظ المساعد بالنص أثناء بثّه، وحيثما لم يبلّغ المزوّد بشيء سدّ الفجوة بعدد البايتات نفسه، فيسجّل أكثر من الحقيقة لا أقل منها. وأرقام المزوّد هي المعتمدة حيثما أعطى رقمًا: فالدور الذي يكتمل يُسجَّل له ما قيس بالضبط، لا تقدير تقريبي له. ومقال حواجز الهلوسة في RAG يبيّن موضع هذا الفحص بين طبقات المساعد الأخرى.

والمبدأ نفسه يصحّ في المنتج. ففي Booq، حيث أقود هندسة الذكاء الاصطناعي، يعرض كل عمل سعره أو تقديره الابتدائي قبل أن يبدأ، ويُرَدّ مقابلُ أي عمل يفشل تلقائيًّا، كما تشرح دراسة حالة Booq.

أسئلة شائعة

هل يستهلك النص الفارسي رموزًا أكثر من الإنجليزي في نماذج OpenAI؟

نعم. على جمل FLORES-200 نفسها، احتاجت الفارسية ١٫٥٣ ضعف عدد رموز الإنجليزية مع o200k_base (الذي تربطه tiktoken بنماذج GPT-4o وGPT-4.1 وGPT-5)، و٣٫٢٦ ضعف مع cl100k_base (الذي تربطه بنموذج GPT-4). وحركتك أنت ستعطي نسبة مختلفة، فاحسبها.

كم يستهلك النص الفارسي من الرموز في Claude أو Gemini؟

لا يستطيع هذا القياس أن يقول. لا تنشر Anthropic أي مُقطِّع لنماذج Claude، وتتيح حزمة Google Gen AI عدًّا محليًّا تجريبيًّا لبعض نماذج Gemini مبنيًّا على مُقطِّعات Gemma المفتوحة لم أقِسه. والنسب أعلاه لا تنسحب على أي من الشركتين. استخدم نقطة النهاية count_tokens لدى Anthropic أو count_tokens لدى Gemini على طلبات حقيقية، وأعد الحساب كلما غيّرت النموذج.

هل العربية أرخص من الفارسية؟

في أربعة من المُقطِّعات الخمسة المقيسة هنا، نعم: مع o200k_base احتاجت العربية ١٫٣٨ ضعف عدد رموز الإنجليزية مقابل ١٫٥٣ ضعف للفارسية. ومع bge-m3 كان الأمر معكوسًا، ١٫١٧ ضعف مقابل ١٫١٠ ضعف، وهو ما يتسق مع احتواء بيانات تدريب XLM-R على فارسية أكثر بكثير من العربية.

هل أحذف ZWNJ أو أنتقل إلى صور الحروف العربية لتوفير الرموز؟

لا. استبدال مسافة بمحرف ZWNJ غيّر الأعداد بخفض يتراوح بين ١٫٥٧٪ و٨٫٠٨٪ في المُقطِّعات العاملة على مستوى البايت، وهو يغيّر الكلمات. أما صور الحروف العربية فلم توفّر الرموز إلا مع Qwen3، وكلّفت بين ٢٫٢٠٪ و١١٫٩٥٪ في غيره. وكلاهما يكسر المطابقة التامة ما لم يتغيّر كل استعلام بالطريقة نفسها.

كم محرفًا في الرمز الفارسي الواحد؟

يتوقف ذلك على المُقطِّع: من ١٫٤٠ مع cl100k_base إلى ٣٫٦٨ مع bge-m3 في هذا القياس، مقابل ٤٫٣٠ إلى ٤٫٩١ للإنجليزية. والقاعدة الثابتة الآمنة عند مُقطِّع قد تُنقص العدّ عند غيره. وقد تخلّى هذا الموقع عن حجزه القائم على محرفين لكل رمز بعد هذا التشغيل، وصار يحجز عدد البايتات، وهذه هي النصيحة العامة: احجز في مواجهة سقف قاطع أو عدّ من المزوّد، لا في مواجهة قاعدة سريعة.

المصادر

• FLORES-200 README، دليل FLORES-200 في مستودع facebookresearch/flores

• facebookresearch/flores، مستودع FLORES بتراخيصه وإشعار أرشفته

• facebook/flores، بطاقة مجموعة بيانات FLORES في Hugging Face

• FLORES-200 dataset archive، أرشيف البيانات الرسمي

• No Language Left Behind: Scaling Human-Centered Machine Translation، ورقة فريق NLLB لعام ٢٠٢٢

• Measuring the Tokenization Premium: A Cost Audit for Underserved Language Communities، ورقة Roy وRoy وPatel المقبولة في إحدى ورش IJCAI 2026

• Language Model Tokenizers Introduce Unfairness Between Languages، ورقة Petrov وزملائه في مؤتمر NeurIPS لعام ٢٠٢٣

• tokenization_lengths.csv، بيانات أطوال الترميز لدى Petrov وزملائه على FLORES-200

• compute_tokenizations.py، سكربت Petrov وزملائه الذي يضمّ قسمَي dev وdevtest

• Tokenization Disparities as Infrastructure Bias، ورقة Teklehaymanot وNejdl لعام ٢٠٢٥

• Do All Languages Cost the Same? Tokenization in the Era of Commercial Language Models، ورقة Ahia وزملائه لعام ٢٠٢٣

• Unsupervised Cross-lingual Representation Learning at Scale، ورقة Conneau وزملائه عن XLM-R ومدوّنة CC-100

• M3-Embedding، ورقة Chen وزملائه عن BGE-M3

• BAAI/bge-m3، بطاقة النموذج bge-m3 في Hugging Face

• Qwen3، بطاقة النموذج Qwen3 في Hugging Face

• DeepSeek-V3، بطاقة النموذج DeepSeek-V3 في Hugging Face

• openai/tiktoken model.py، خريطة النماذج إلى الترميزات في tiktoken

• Token counting، وثائق Claude عن عدّ الرموز

• Rate limits، وثائق Claude عن حدود المعدل

• Reducing latency، وثائق Claude عن خفض زمن الاستجابة

• Streaming messages، وثائق Claude عن بثّ الرسائل

• Latency optimization، وثائق OpenAI API عن تحسين زمن الاستجابة

• Chat Completions streaming events، مرجع OpenAI API عن أحداث البث

• Understand and count tokens، وثائق Gemini API عن عدّ الرموز

• local_tokenizer.py، المُقطِّع المحلي التجريبي في حزمة Google Gen AI للغة Python

• _local_tokenizer_loader.py، خريطة نماذج Gemini إلى مُقطِّعات Gemma في الحزمة نفسها

• UnicodeData.txt، قاعدة بيانات محارف يونيكود

إن كنت تخطّط لميزة قائمة على LLM لمستخدمين ناطقين بالفارسية، فابدأ من تحديد نطاق مشروعك.