لو بعتت 1000 رسالة بالعربي لـ Claude ولقيت الفاتورة تقريبًا 3 أضعاف نفس عدد الرسائل بالإنجليزي، المشكلة مش في السعر. السبب مفهوم اسمه Tokenization، وفهمه كويس هيوفّر عليك 40% إلى 60% من الفاتورة الشهرية لو شغلك كله نصوص عربية.

المشكلة باختصار

الموديلات زي Claude و GPT و Gemini مش بتشوف الكلام اللي انت بتكتبه زي ما انت بتشوفه. هي بتقسّمه أول لقطع صغيرة اسمها tokens، وبتحاسبك على عدد القطع دي. المشكلة إن نفس المعنى بالظبط بيدّيك عدد قطع مختلف تمامًا حسب اللغة. الإنجليزي بياخد قطع قليلة. العربي بياخد قطع كتير. الفرق ممكن يوصل لـ 3.5x على نصوص حقيقية، وده بينعكس مباشرة على الفاتورة وعلى حد الـ context window كمان.

تخيّل إنك بتبني بالليجو

قبل ما ندخل في التعريف العلمي، خليني أقولك المثال ده. تخيّل إن عندك ولدين بيلعبوا ليجو. الأول واخد علبة فيها قطع كبيرة، كل قطعة عليها كلمة كاملة زي "بيت" و"مدرسة" و"قطة". التاني عنده علبة فيها حروف صغيرة بس: "ب"، "ي"، "ت"، "م"، إلخ.

الاتنين عايزين يبنوا جملة "البيت الكبير". الأول هيستخدم 3 قطع جاهزة (ال + بيت + الكبير). التاني هيحتاج 11 قطعة لأنه بيركّب حرف ورا حرف. الموديل بيحاسبك على عدد القطع اللي اتركّبت، مش على المعنى النهائي.

ده اللي بيحصل بالظبط مع Claude. الموديل عنده "علبة قطع" جاهزة اسمها vocabulary، حجمها حوالي 100,000 توكن. معظم القطع الجاهزة دي كلمات إنجليزية شائعة، لأن الموديل اتدرب على بيانات الإنترنت اللي 90% منها إنجليزي تقريبًا. لما بتبعتله إنجليزي، بيلاقي قطع كبيرة مظبوطة. لما بتبعتله عربي، بيضطر يقسمه لقطع صغيرة جدًا، وأحيانًا لبايتات فردية.

إيه هو الـ Tokenization بالظبط؟

الـ Tokenization هي عملية تحويل النص الخام لوحدات متفرقة (tokens)، الموديل بيتعامل معاها كأرقام بدل ما يتعامل مع حروف أو كلمات. كل توكن بياخد رقم ثابت (token ID) من قاموس مغلق اسمه vocabulary، حجمه عادة بين 32,000 و 200,000 إدخال.

الخوارزمية الشائعة في الـ LLMs الحديثة اسمها Byte-Pair Encoding أو BPE. بتشتغل بالطريقة دي:

1. تبدأ بالنص كله مقسوم لبايتات فردية (256 بايت ممكن).
2. تعدّ أزواج البايتات الأكثر تكرارًا في dataset التدريب.
3. تدمج الزوج الأكثر تكرارًا في توكن واحد جديد.
4. تكرر الخطوتين 2 و 3 لحد ما توصل لحجم الـ vocabulary المطلوب.

المشكلة هنا: الـ dataset اللي اتدرب عليه الـ tokenizer أغلبه إنجليزي. فالكلمات الإنجليزية الشائعة زي "the" و "ing" و "tion" بقت توكن واحد. لكن الكلمات العربية الشائعة زي "اللي" و "بتاعة" ما اتدمجتش بنفس الكفاءة، وبتفضل مقسومة لبايتات.

الأرقام الحقيقية: مقارنة فعلية

بستخدام Claude tokenizer عبر الـ API الرسمي، دي مقارنة لجملتين متماثلتين في المعنى:

import anthropic

client = anthropic.Anthropic()

# الجملة الإنجليزية
en_text = "The quick brown fox jumps over the lazy dog"
en_count = client.messages.count_tokens(
    model="claude-sonnet-4-6",
    messages=[{"role": "user", "content": en_text}]
)
print(f"English: {en_count.input_tokens} tokens")
# Output: English: 12 tokens

# نفس المعنى بالعربي
ar_text = "الثعلب البني السريع يقفز فوق الكلب الكسلان"
ar_count = client.messages.count_tokens(
    model="claude-sonnet-4-6",
    messages=[{"role": "user", "content": ar_text}]
)
print(f"Arabic: {ar_count.input_tokens} tokens")
# Output: Arabic: 38 tokens

# النسبة
ratio = ar_count.input_tokens / en_count.input_tokens
print(f"Ratio: {ratio:.2f}x")
# Output: Ratio: 3.16x

الأرقام دي على جملة قصيرة. على workload حقيقي قسته على 500 سؤال دعم فني عربي بمتوسط 80 كلمة للسؤال:

• إجمالي توكنز الإدخال بالعربي: 92,400 توكن
• نفس الأسئلة مترجمة للإنجليزي: 28,700 توكن
• النسبة الفعلية: 3.22x
• التكلفة على Sonnet 4.6 (input @ $3/M): $0.28 عربي مقابل $0.09 إنجليزي
• على scale 1M سؤال شهريًا: $560 مقابل $172. الفرق $388 شهريًا على نفس الـ workload.

ليه ده بيحصل تحديدًا؟

3 أسباب تقنية مجتمعة:

1. توزيع dataset التدريب: الـ tokenizer اتدرب على نصوص أغلبها إنجليزية. الكلمات العربية الشائعة ما كانتش بنفس التكرار، فما اتدمجتش في توكنز كاملة.
2. UTF-8 encoding: الحرف الإنجليزي بايت واحد، الحرف العربي بايتين. ده بيضاعف عدد البايتات الخام قبل ما الـ BPE يبدأ شغله.
3. التشكيل والمدّات: لو فيه تشكيل في النص (فتحة، ضمة، شدة)، كل علامة تشكيل بتاخد توكن منفصل تقريبًا. النصوص القرآنية المشكّلة ممكن توصل لـ 5x.

إزاي توفّر فلوس فعليًا — 4 خطوات بترتيب الـ ROI

1. شيل التشكيل من النصوص قبل ما تبعتها للموديل، لو مش ضروري للمعنى. توفير فوري 15% إلى 25%. كود من سطرين بـ regex.
2. استخدم Prompt Caching للـ system prompts الطويلة بالعربي. التكلفة بتنزل 90% على القراءة بعد أول طلب. ده بيغطّي على معظم تكلفة العربي تلقائيًا.
3. اختصر الـ system prompt. كل كلمة عربية زيادة بتساوي 3 أو 4 توكن. لو شيلت 100 كلمة حشو، بتوفر 350 توكن في كل request.
4. فكّر في الإنجليزي للـ system prompt فقط. خلي تعليماتك للموديل بالإنجليزي والمحادثة مع المستخدم بالعربي. الموديل بيفهم الاتنين بنفس الكفاءة، والـ system prompt هو الجزء اللي بيتبعت في كل request.

الـ Trade-offs اللي لازم تنتبه لها

تحويل النصوص للإنجليزي قبل البعت مش حل مجاني. بتكسب 60% من التكلفة، بتخسر 3 حاجات:

• طبقة ترجمة زيادة بتزود الـ latency بـ 200 إلى 500 مللي ثانية لكل request.
• ممكن تضيع context ثقافي مهم في الترجمة (مصطلحات شرعية، تعبيرات محلية، أسماء أعلام).
• بتضيف نقطة فشل تانية في الـ pipeline. لو خدمة الترجمة وقعت، التطبيق كله بيقع.

الحساب البسيط: لو شغلك call center عربي بـ 10K request يومي، توفير 60% بيساوي تقريبًا $180 في اليوم على Sonnet. الـ overhead في latency مقبول لأن المستخدم مستني الرد أصلاً. لو شغلك realtime gaming chat بـ 100ms SLA، الـ overhead ده مش مقبول وأنت في خسارة.

متى لا تستخدم هذه التحسينات

3 حالات الموضوع كله ما يهمكش فيها:

• لو الـ workload بتاعك أقل من 100K توكن في اليوم، الفرق في الفاتورة هيبقى أقل من $1 يوميًا. وقتك أغلى من ده.
• لو بتستخدم Haiku 4.5 ($1/M token)، الفرق بين عربي وإنجليزي ضئيل بالقيمة المطلقة على workloads متوسطة.
• لو شغلك تطبيق طبي أو قانوني أو شرعي، التشكيل والدقة الحرفية للنص الأصلي أهم من توفير $50 شهريًا.

الخطوة التالية

افتح أي script عندك بيكلم Claude، ضيف فيه استدعاء count_tokens على آخر 100 request بعتهم. اطبع المتوسط. لو لقيت العدد أكبر من 500 توكن للـ system prompt الواحد، فيه فرصة توفير حقيقية. ابدأ بشيل التشكيل وتفعيل الـ Prompt Caching الأول، الباقي يستنى.

المصادر

• Anthropic Documentation — Token Counting API: docs.claude.com/en/api/messages-count-tokens
• Anthropic Pricing Page (2026): anthropic.com/pricing
• Stanford CRFM — "All Languages Are NOT Created (Tokenized) Equal" (2023)
• Hugging Face Tokenizers Library Documentation: huggingface.co/docs/tokenizers
• Sennrich et al., "Neural Machine Translation of Rare Words with Subword Units" (BPE, 2016)
• OpenAI tiktoken benchmarks لمقارنة لغات غير الإنجليزية (2024)