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

तकनीकी सारांश: पिक्सेल प्रोग्राम्स के लिए? टेक्स्ट और इमेज के रूप में सोर्स कोड के लिए इनपुट-टोकन अकाउंटिंग का एक क्रॉस-प्रदाता केस स्टडी

समस्या विवरण (Problem Statement)
लंबे सोर्स-कोड संदर्भ अक्सर भाषा मॉडलों (language models) की टोकन सीमाओं से अधिक हो जाते हैं, जो विजन-लैंग्वेज मॉडल्स (VLMs) के लिए कोड को इमेज के रूप में रेंडर करने के प्रस्तावों को प्रेरित करते हैं। जबकि हालिया शोध इस बात की जांच करता है कि क्या मॉडल इस रूपांतरण के बाद कोड कार्यों को हल कर सकते हैं, एक महत्वपूर्ण सिस्टम संबंधी प्रश्न अनसुलझा बना हुआ है: वाणिज्यिक API प्रदाता परिणामी अनुरोधों की गणना कैसे करते हैं? विशेष रूप से, यह स्पष्ट नहीं है कि जब कोड को कच्चे टेक्स्ट बनाम कॉम्पैक्ट रेंडर किए गए इमेजेस के रूप में भेजा जाता है, तो इनपुट-टोकन अकाउंटिंग कैसे बदलता है, यह संबंध सोर्स की लंबाई के साथ कैसे स्केल करता है, और क्या "विजुअल कंप्रेशन" विभिन्न प्रदाताओं के बीच रिपोर्ट किए गए टोकन में शुद्ध कमी प्रदान करता है।

कार्यप्रणाली (Methodology)
यह अध्ययन तीन प्रमुख प्रदाताओं: Anthropic, OpenAI, और Google Vertex AI के बीच इनपुट-टोकन अकाउंटिंग की तुलना करने के लिए एक पुनरुत्पादनीय (reproducible), ब्लैक-बॉक्स माप प्रोटोकॉल का उपयोग करता है।

• संग्रह (Corpus): डेटासेट में प्रमुख ओपन-सोर्स प्रोजेक्ट्स से पांच रिवीज़न-पिन्ड (revision-pinned) सोर्स फाइलें (Python, JavaScript, Rust, Go, और Java) शामिल हैं। इन फाइलों को नौ नेस्टेड प्रीफिक्स (20 से 2,000 लाइनों तक) में विभाजित किया गया है।
• उपचार (Compact Image): इमेज आर्म (image arm) एक दो-चरणीय रूपांतरण लागू करता है:
  1. इंडेंटेशन कंप्रेशन (Indentation Compression): लीडिंग स्पेस को कॉम्पैक्ट मार्कर्स (जैसे, 4-स्पेस इंडेंट के लिए > और अनियमित रन के लिए ^N) से बदल दिया जाता है।
  2. रेंडरिंग (Rendering): रूपांतरित टेक्स्ट को PNG पेजों के रूप में रेंडर किया जाता है।
• प्रायोगिक डिजाइन (Experimental Design): प्रत्येक सोर्स साइज और भाषा के लिए, 15 उपलब्ध मॉडल एलियास (4 Anthropic, 6 OpenAI, 5 Gemini) को युग्मित (paired) अनुरोध भेजे जाते हैं। दोनों आर्म्स में एक समान एक-वाक्य सारांश निर्देश ("Summarize what this code does in one sentence") शामिल है।
• मेट्रिक्स (Metrics): प्राथमिक मेट्रिक प्रदाता-रिपोर्टेड इमेज इनपुट टोकन ($I$) और टेक्स्ट इनपुट टोकन ($T$) का अनुपात है। अध्ययन भारित एग्रीगेट अनुपात (पूरे डेटासेट में सभी टोकन का योग) और साइज-स्ट्रैटिफाइड अनुपात की रिपोर्ट करता है ताकि ब्रेक-ईवन पॉइंट्स की पहचान की जा सके।
• सीमाएं (Constraints): अध्ययन स्पष्ट रूप से टोकन अकाउंटिंग को सिमेंटिक फिडेलिटी (semantic fidelity), कार्य सटीकता, लेटेंसी, मौद्रिक लागत, या कोडिंग-एजेंट दक्षता से अलग करता है। यह दावा नहीं करता है कि इमेज टोकन, टेक्स्ट टोकन के रूप में कम्प्यूटेशनल रूप से समान हैं।

प्रमुख योगदान (Key Contributions)

1. पुनरुत्पादनीय आर्टिफैक्ट (Reproducible Artifact): 1,350 सफल API कॉल्स और 675 पूर्ण टेक्स्ट/इमेज पेयर्स का एक डेटासेट, जिसमें रॉ यूसेज रिकॉर्ड, वैलिडेटर्स और नियतात्मक (deterministic) विश्लेषण स्क्रिप्ट शामिल हैं।
2. साइज-स्ट्रैटिफाइड मेजरमेंट्स (Size-Stratified Measurements): अनुभवजन्य साक्ष्य जो दिखाते हैं कि टोकन रिडक्शन एकसमान नहीं है; यह सोर्स की लंबाई और प्रदाता के अनुसार काफी भिन्न होता है।
3. मोडैलिटी ऑडिट (Modality Audit): एक लक्षित जांच जो पेज बाउंड्रीज़ पर नॉन-मोनोटोनिक व्यवहार को प्रकट करती है।
4. वैलिडिटी बाउंड्री (Validity Boundary): टोकन काउंटिंग मेट्रिक्स और सूचना संरक्षण के बीच एक स्पष्ट विभाजन, जो "कम टोकन" को "बेहतर प्रदर्शन" या "कम लागत" के साथ मिलाने से रोकता है।

परिणाम (Results)

• एग्रीगेट रिडक्शन (Aggregate Reductions): पूरे बेंचमार्क में, कॉम्पैक्ट इमेजेस कच्चे टेक्स्ट की तुलना में काफी कम रिपोर्ट किए गए इनपुट टोकन प्राप्त करते हैं:
  • Anthropic: 0.135 अनुपात (86.5% की कमी)।
  • OpenAI: 0.194 अनुपात (80.6% की कमी)।
  • Gemini: 0.242 अनुपात (75.8% की कमी)।
• ब्रेक-ईवन व्यवहार (Break-Even Behavior): एग्रीगेट अनुपात महत्वपूर्ण अंतरों को छिपा देते हैं:
  • Anthropic और OpenAI: इमेज इनपुट हर टेस्ट किए गए साइज (20 से 2,000 लाइन्स) पर टेक्स्ट की तुलना में कम टोकन काउंट प्राप्त करते हैं।
  • Gemini: इमेजेस छोटे कॉन्टेक्स्ट के लिए भारी ओवरहेड वहन करते हैं। 20 लाइनों पर, Gemini इमेजेस को टेक्स्ट की तुलना में 6.95 गुना अधिक टोकन की आवश्यकता होती है। इमेज दृष्टिकोण केवल 200 लाइनों पर ही फायदेमंद (पैरिटी के नीचे पार करना) होता है।
• मॉडल एलियास (Model Aliases): प्रदाताओं के भीतर, कई मॉडल एलियास समान अकाउंटिंग सिग्नेचर साझा करते हैं (उदाहरण के लिए, अध्ययन में सभी छह OpenAI मॉडलों ने समान एग्रीगेट अनुपात लौटाया), जो स्वतंत्र मॉडल व्यवहार के बजाय साझा आंतरिक अकाउंटिंग नियमों का सुझाव देते हैं।
• नॉन-मोनोटोनिसिटी (Non-Monotonicity): Gemini के एक लक्षित ऑडिट ने खुलासा किया कि रिपोर्ट किए गए इमेज टोकन काउंट पेज बाउंड्रीज़ पर नॉन-मोनोटोनिक रूप से बदल सकते हैं। उदाहरण के लिए, सोर्स को 800 से 1,200 लाइनों तक बढ़ाने (दूसरा पेज जोड़ने) के परिणामस्वरूप एक मॉडल के लिए रिपोर्ट किए गए इमेज टोकन में कमी आई, जो इस अपेक्षा के विपरीत है कि टोकन काउंट कंटेंट के साथ रैखिक रूप से स्केल होता है।

महत्व और दावे (Significance and Claims)
पेपर का दावा है कि हालांकि कॉम्पैक्ट रेंडर किया गया कोड लंबे कॉन्टेक्स्ट के लिए रिपोर्ट किए गए इनपुट टोकन को नाटकीय रूप से कम कर सकता है, लेकिन इसका लाभ अत्यधिक सशर्त है:

1. प्रदाता विशिष्टता (Provider Specificity): कोई सार्वभौमिक "विजुअल कंप्रेशन" लाभ नहीं है। Gemini जैसे प्रदाता उच्च निश्चित लागत (fixed costs) प्रदर्शित करते हैं जो छोटे कॉन्टेक्स्ट के लिए इमेजेस को प्रतिproductive (counterproductive) बनाते हैं।
2. रूटिंग निहितार्थ (Routing Implications): एक कोडिंग हार्नेस एक वैश्विक नीति पर "कोड को इमेज के रूप में भेजना" नहीं मान सकता है। इसके बजाय, रूटिंग लॉजिक को प्रति प्रदाता और सोर्स साइज के अनुसार कैलिब्रेट किया जाना चाहिए, जो संभावित रूप से छोटे कॉन्टेक्स्ट के लिए टेक्स्ट पर वापस जा सकता है या जब पेज बाउंड्रीज़ विच्छेदन (discontinuities) पेश करती हैं।
3. टोकन काउंट्स की सीमाएं (Limitations of Token Counts): अध्ययन इस बात पर जोर देता है कि रिपोर्ट किए गए टोकन में कमी, समान सूचना सामग्री, कम मौद्रिक लागत, या कम कंप्यूट का संकेत नहीं देती है। इंडेंटेशन मार्कर्स को गलत तरीके से डिकोड किया जा सकता है, और रस्टरलाइजेशन (rasterization) पंकचुएशन या स्ट्रक्चर को अस्पष्ट कर सकता है।
4. भविष्य का कार्य (Future Work): लेखक इस अध्ययन को एक "मेजरमेंट सरफेस" के रूप में देखते हैं जिस पर भविष्य के शोध निर्माण कर सकें। उनका तर्क है कि अगला आवश्यक कदम टास्क क्वालिटी (जैसे, सटीक ट्रांसक्रिप्शन, डिफेक्ट लोकलाइजेशन) के साथ प्रतिनिधित्व को क्रॉस-रेफरेंस करना है, ताकि यह निर्धारित किया जा सके कि क्या टोकन बचत वास्तव में कोडिंग उपयोगिता में परिवर्तित होती है।

पेपर निष्कर्ष निकालता है कि कॉम्पैक्ट रेंडर किया गया कोड विशिष्ट व्यवस्थाओं (लंबे कॉन्टेक्स्ट, विशिष्ट प्रदाता) में टोकन अकाउंटिंग के लिए एक व्यवहार्य रणनीति है, लेकिन इसके लिए सावधानीपूर्वक, प्रदाता-विशिष्ट अंशांकन (calibration) और सूचना फिडेलिटी के संबंध में आगे के सत्यापन की आवश्यकता है।