باحثو الذكاء الاصطناعي آران كوماتسوزاكي ينشرون مؤخراً على منصة X تحليلاً تجريبياً يكشف عن وجود مشكلة خطيرة تتمثل في “ضريبة اللغات غير الإنجليزية (non-English tax)” لدى مُجزِّئات الكلمات (tokenizers) الخاصة بالنماذج اللغوية الكبيرة السائدة (LLM). وتُشير المناقشات في المجتمع إلى أن نموذج كلود (Claude) التابع لشركة Anthropic يستهلك مواد اللغات الصينية واليابانية والكورية ما يصل إلى نحو 3 أضعاف تقريباً من عدد الـ tokens.
منهجية التجربة: ورقة كلاسيكية لقياس فروقات تكلفة اللغة
اعتمد كوماتسوزاكي على المقال الكلاسيكي “The Bitter Lesson” كمادة، وقام بترجمته إلى لغات متعددة مثل الصينية واللغة الهندية والعربية والكورية واليابانية، ثم أرسله على حدة إلى مُجزِّئات الكلمات الخاصة بكل نموذج كبير لحساب عدد tokens المستهلكة. تُجرى التجربة مع جعل النسخة الإنجليزية من OpenAI مرجعاً (1.0×)، عبر مقارنة كفاءة كل نموذج في التعامل مع لغات مختلفة من خلال مضاعفات معيارية.
عدد الـ tokens يحدد مباشرةً تكلفة استخدام واجهة برمجة التطبيقات وزمن الاستجابة؛ فكلما زاد عدد الـ tokens زادت التكلفة وانخفضت السرعة. لذلك، فإن الفروق في كفاءة المُجزِّئات تعني عملياً اختلافاً في مصروفات المستخدمين وجودة تجربة الاستخدام.
أرفق كوماتسوزاكي أيضاً موقعاً مصمماً من جهته يمكنه حساب كمية tokens:
هل لدى الذكاء الاصطناعي تمييز عرقي؟ كلود يدفع أعلى “ضريبة لغوية”، والهندية تتصدر
OpenAI مقابل Anthropic: مخطط أشرطة لمضاعفات استهلاك الـ Token حسب اللغة
تُظهر البيانات أن مضاعفات الـ tokens لدى OpenAI عبر اللغات تكون عموماً ضمن 1.4×، بينما يكون الفارق لدى Anthropic (Claude) لافتاً للغاية:
الهندية: 3.24× (Claude) مقابل 1.37× (OpenAI)
العربية: 2.86× (Claude) مقابل 1.31× (OpenAI)
الروسية: 2.04× (Claude) مقابل 1.31× (OpenAI)
الصينية: 1.71× (Claude) مقابل 1.15× (OpenAI)
وبعبارة أخرى، إذا استخدم مطور هندي واجهة Claude API لمعالجة محتوى باللغة الهندية، فقد تكون التكلفة الفعلية بما يعادل أكثر من 3 أضعاف تكلفة المهمة نفسها باللغة الإنجليزية، كما سينخفض أيضاً زمن الاستجابة بشكل واضح بسبب تضخم عدد tokens.
مقارنة أفقية بين ستة نماذج: نماذج محلية صينية تتفوق، وGemini تظهر أفضل أداء
مخطط خريطة حرارية لمضاعفات استهلاك الـ Token عبر اللغات لنماذج ستة
وسّع كوماتسوزاكي لاحقاً نطاق المقارنة في منشوره، ليشمل نماذج مثل Gemini 3.1 وQwen 3.6 وDeepSeek V4 وKimi K2.6، وأظهرت النتائج:
Gemini 3.1: 1.22× (الأكثر ملاءمة لمستخدمي اللغات غير الإنجليزية)
Qwen 3.6: 1.23×
OpenAI: 1.33×
DeepSeek V4: 1.49×
Kimi K2.6: 1.76×
Anthropic: 2.07× (الأقل ملاءمة لمستخدمي اللغات غير الإنجليزية)
تُظهر البيانات أن استهلاك tokens في الصينية يكون أقل من خط الأساس في Qwen (0.85×) وDeepSeek (0.87×) وKimi (0.81×)، ما يشير إلى أن النماذج المحلية الصينية أجرت تحسينات عميقة للغة الصينية. واعترف كوماتسوزاكي بنفسه في رده قائلاً: “لم أتوقع أن يكون أداء كلود بهذه السوء وعدم التوازن”.
قلق المجتمع: “فجوة التكلفة” مشكلة خطيرة في عملية تعميم الذكاء الاصطناعي
أطلقت نتائج التجربة صدى قوياً في مجتمع X، حيث قال العديد من المطورين غير الناطقين بالإنجليزية إن معالجة نفس المستندات الصينية أو الكورية باستخدام Claude تكلف فعلاً أكثر بكثير من Gemini في الاستخدام العملي.
امتدت المناقشات أيضاً إلى الجذور التقنية: غالباً ما تعود فروقات كفاءة tokenizer إلى أن بيانات التدريب تركز أساساً على المحتوى الإنجليزي والحروف اللاتينية، ما يؤدي إلى انخفاض فهم النموذج للأنظمة الكتابية الأخرى. وبذلك، يحتاج كل حرف أو مفردة إلى استهلاك المزيد من tokens. حتى لو كان عدد مستخدمي اللغة الهندية في العالم يبلغ مئات الملايين، فإن ندرة مواد التدريب عالية الجودة مع تعقيد البنية الصرفية للكتابة يجعلها الفئة الأعلى تكلفة في استخدام الذكاء الاصطناعي.
ويرى بعض رواد الإنترنت أن قاعدة عملاء Anthropic تميل أكثر إلى الشركات الناطقة بالإنجليزية وسيناريوهات تطوير البرمجيات، وبالتالي لا توجد دافع قوي لتحسين دعم تعدد اللغات. في المقابل، يُجيد OpenAI التعامل مع محتوى اللغات، وقال أحدهم صراحة: “كان من المفترض أن يكون الذكاء الاصطناعي تقنية ديمقراطية للمساواة، لكن المستخدمين غير الناطقين بالإنجليزية يدفعون الفاتورة عن التمييز اللغوي”.
واليوم، فإن الجدل الدائر حول تصميم tokenizer لم يعد مجرد مشكلة تقنية، بل يعكس أيضاً اختلالاً في موازين صناعة الذكاء الاصطناعي خلال توسعها عالمياً.
هل ستُحصِّل Claude “ضريبة لغوية” في هذه المقالة؟ بحث يكشف أن الترجمة بين الصينية واليابانية والكورية تستهلك أكبر عدد من tokens، يصل إلى ما يقرب من 3 أضعاف، وأول ظهور كان على موقع 鏈新聞 ABMedia.
