Pixels for Programs? A Cross-Provider Case Study of Input-Token Accounting for Source Code as Text and Images

ملخص تقني: بكسلات للبرامج؟ دراسة حالة عبر المزودين حول محاسبة رموز الإدخال (Input-Tokens) للكود المصدري كنص وصور

بيان المشكلة
غالبًا ما تتجاوز سياقات الكود المصدري الطويلة حدود الرموز (tokens) الخاصة بنماذج اللغات الكبيرة، مما يحفز مقترحات لتحويل الكود إلى صور لتعامل معها نماذج الرؤية واللغة (VLMs). وبينما تبحث الأبحاث الحديثة فيما إذا كانت النماذج قادرة على حل مهام الكود بعد هذا التحول، يظل هناك سؤال تقني هام لم يُجب عليه بعد: كيف تقوم شركات توفير واجهة برمجة التطبيقات (API) التجارية بمحاسبة الطلبات الناتجة؟ وتحديدًا، من غير الواضح كيف تتغير محاسبة رموز الإدخال عند إرسال الكود كنص خام مقابل صور مضغوطة مصورة، وكيف تتناسب هذه العلاقة مع طول المصدر، وما إذا كان "الضغط البصري" يوفر تقليلًا صافيًا في عدد الرموز المبلغ عنها عبر مختلف المزودين والأسماء المستعارة للنماذج.

المنهجية
تستخدم الدراسة بروتوكول قياس قابل للتكرار يعمل كـ "صندوق أسود" لمقارنة محاسبة رموز الإدخال عبر ثلاثة مزودين رئيسيين: Anthropic وOpenAI وGoogle Vertex AI.

• المتن (Corpus): تتكون مجموعة البيانات من خمسة ملفات مصدرية مثبتة الإصدار (Python، JavaScript، Rust، Go، وJava) من مشاريع مفتوحة المصدر بارزة. تم تقسيم هذه الملفات إلى تسعة مستويات متداخلة من البادئات (prefixes) تتراوح من 20 إلى 2,000 سطر.
• المعالجة (الصورة المضغوطة): يطبق ذراع الصورة تحويلًا ثنائي المرحلة:
  1. ضغط المسافات البادئة: استبدال المسافات الرائدة بعلامات مضغوطة (مثل > للمسافات البادئة بمقدار 4 مسافات، و ^N للمسافات غير المنتظمة).
  2. التصوير (Rendering): تحويل النص المحول إلى صفحات بصيغة PNG.
• التصميم التجريبي: لكل حجم مصدر ولغة، يتم إرسال طلبات مزدوجة إلى 15 اسمًا مستعارًا متاحًا للنماذج (4 لـ Anthropic، 6 لـ OpenAI، و5 لـ Gemini). يتضمن كلا الذراعين تعليمات تلخيص مكونة من جملة واحدة متطابقة ("لخص ما يفعله هذا الكود في جملة واحدة").
• المقاييس: المقياس الأساسي هو نسبة رموز إدخال الصور المبلغ عنها ($I$) إلى رموز النص المدخل ($T$). تسجل الدراسة النسب المجمعة الموزونة (مجموع كل الرموز عبر مجموعة البيانات) والنسب المصنفة حسب الحجم لتحديد نقاط التعادل.
• القيود: تعزل الدراسة صراحةً "محاسبة الرموز" عن الدقة الدلالية، دقة المهام، زمن الاستجابة (latency)، التكلفة المالية، أو كفاءة الوكيل البرمجي. وهي لا تدعي أن رموز الصور مكافئة حوسبيًا لرموز النصوص.

المساهمات الرئيسية

1. أثر قابل للتكرار: مجموعة بيانات تضم 1,350 استدعاءً ناجحًا لواجهة برمجة التطبيقات و675 زوجًا كاملاً من (النص/الصورة)، بما في ذلك سجلات الاستخدام الخام، وأدوات التحقق، وسكريبتات التحليل الحتمية.
2. قياسات مصنفة حسب الحجم: أدلة تجريبية تظهر أن تقليل الرموز ليس موحدًا؛ فهو يختلف بشكل كبير باختلاف طول المصدر والمزود.
3. تدقيق النمط (Modality Audit): تحقيق مستهدف يكشف عن سلوك غير رتيب (non-monotonic) في محاسبة الصور، وتحديدًا عند حدود الصفحات.
4. حد الصلاحية: تمييز واضح بين مقاييس عد الرموز وبين الحفاظ على المعلومات، لتجنب الخلط بين "عدد أقل من الرموز" و"أداء أفضل" أو "تكلفة أقل".

النتائج

• التقليلات الإجمالية: عبر الاختبار الكامل، تتلقى الصور المضغطة عددًا أقل بكماً من رموز الإدخال المبلغ عنها مقارنة بالنص الخام:
  • Anthropic: نسبة 0.135 (تقليل بنسبة 86.5%).
  • OpenAI: نسبة 0.194 (تقليل بنسبة 80.6%).
  • Gemini: نسبة 0.242 (تقليل بنسبة 75.8%).
• سلوك نقطة التعادل: تخفي النسب الإجمالية اختلافات حرجة في التوسع:
  • Anthropic وOpenAI: تتلقى مدخلات الصور عددًا أقل من الرموز من النص عند كل حجم تم اختباره (من 20 إلى 2,000 سطر).
  • Gemini: تتحمل الصور تكاليف إضافية هائلة في السياقات القصيرة. عند 20 سطرًا، تتطلب صور Gemini 6.95 ضعف عدد رموز النص. ولا يصبح نهج الصورة مفيدًا (يتخطى نقطة التساوي) إلا عند 200 سطر.
• الأسماء المستعارة للنماذج: ضمن المزودين، تشترك العديد من الأسماء المستعارة للنماذج في تواقيع محاسبية متطابقة (على سبيل المثال، جميع نماذج OpenAI الستة في الدراسة أعادت نسبًا إجمالية متطابقة)، مما يشير إلى قواعد محاسبة داخلية مشتركة بدلاً من سلوكيات نماذج مستقلة.
• عدم الرتابة (Non-Monotonicity): كشف تدقيق مستهدف لـ Gemini أن عدد رموز الصور المبلغ عنها يمكن أن يتغير بشكل غير رتيب عند حدود الصفحات. على سبيل المثال، زيادة المصدر من 800 إلى 1,200 سطر (إضافة صفحة ثانية) أدت إلى انخفاض في رموز الصور المبلغ عنها لأحد النماذج، مما يناقض التوقع بأن أعداد الرموز تتوسع خطيًا مع المحتوى.

الأهمية والادعاءات
تدعي الورقة أنه بينما يمكن لتمثيل الكود كصور مضغوطة أن يقلل بشكل كبير من رموز الإدخال المبلغ عنها للسياقات الطويلة، فإن هذه الفائدة مشروطة للغاية:

1. خصوصية المزود: لا يوجد ميزة "ضغط بصري" عالمية. فالمزودون مثل Gemini لديهم تكاليف ثابتة عالية تجعل الصور غير مجدية للسياقات القصيرة.
2. آثار التوجيه (Routing): لا يمكن لنظام برمجي (harness) الاعتماد على سياسة عالمية لـ "إرسال الكود كصور". بدلاً من ذلك، يجب معايرة منطق التوجيه لكل مزود وحجم مصدر، مع إمكانية العودة إلى النص للسياقات القصيرة أو عند حدوث انقطاعات بسبب حدود الصفحات.
3. محدودية أعداد الرموز: تؤكد الدراسة أن تقليل الرموز المبلغ عنها لا يعني محتوى معلوماتي مكافئ، أو تكلفة مالية أقل، أو قدرة حوسبية أقل. فقد تُفسر علامات المسافات البادئة بشكل خاطئ، أو قد يؤدي التصوير النقطي (rasterization) إلى طمس علامات الترقيم أو الهيكل.
4. العمل المستقبلي: يضع المؤلفون هذه الدراسة كـ "سطح قياس" يمكن للأبحاث المستقبلية البناء عليه. ويجادلون بأن الخطوة الضرورية التالية هي مقاطعة التمثيل مع جودة المهام (مثل النسخ الدقيق، أو تحديد مواضع العيوب) لتحديد ما إذا كانت وفورات الرموز تترجم إلى فائدة برمجية فعلية.

تخلص الورقة إلى أن الكود المصدري المصور بشكل مضغوط يعد استراتيجية قابلة للتطبيق في محاسبة الرموز في أنظمة محددة (السياقات الطويلة، مزودون محددون)، ولكنه يتطلب معايرة دقيقة خاصة بكل مزود وتحققًا إضافيًا فيما يتعلق بدقة المعلومات.