← नवीनतम पेपर
💻 computer science

TRACE: Evaluating Execution Efficiency of LLM-Based Code Translation

यह शोध पत्र **TRACE** को प्रस्तुत करता है, जो LLM-अनुवादित कोड की निष्पादन दक्षता (execution efficiency) का मूल्यांकन करने के लिए डिज़ाइन किया गया पहला बेंचमार्क है, जो यह प्रकट करता है कि कार्यात्मक शुद्धता (functional correctness) दक्षता के लिए एक अविश्वसनीय प्रॉक्सी है और वर्तमान मॉडल अक्सर एल्गोरिद्मिक दोषों, भाषा के बेमेल होने और संसाधन कुप्रबंधन के कारण अक्षम अनुवाद उत्पन्न करते हैं।

मूल लेखक: Zhihao Gong, Zeyu Sun, Dong Huang, Qingyuan Liang, Jie M. Zhang, Dan Hao

प्रकाशित 2026-03-18
📖 5 मिनट में पढ़ें🧠 गहराई से पढ़ें
CC BY 4.0

मूल लेखक: Zhihao Gong, Zeyu Sun, Dong Huang, Qingyuan Liang, Jie M. Zhang, Dan Hao

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। ✨ नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

कल्पना कीजिए कि आपके पास एक मास्टर शेफ है जो एक भाषा से दूसरी भाषा में रेसिपी अनुवाद करने में अविश्वसनीय रूप से प्रतिभाशाली है। यदि आप उन्हें इतालवी में "स्पैगेटी कार्बोनारा" (Spaghetti Carbonara) की रेसिपी देते हैं, तो वे इसे अंग्रेजी, फ्रेंच या जापानी में पूरी तरह से अनुवाद कर सकते हैं। सामग्री की सूची सटीक है, चरण तार्किक हैं, और अंतिम व्यंजन बिल्कुल मूल जैसा ही स्वाद देता है।

लेकिन यहाँ एक पेंच है: क्या होगा अगर अनुवाद इतना अक्षम हो कि एक डिश बनाने में 10 घंटे लग जाएं जिसे 20 मिनट में बनना चाहिए था? या क्या होगा अगर अनुवाद एक साधारण टोस्टर के बजाय एक विशाल औद्योगिक ओवन का उपयोग करता है, जिससे इतनी बिजली बर्बाद होती है कि उससे एक छोटे शहर को बिजली दी जा सकती है?

यही वह समस्या है जिसे TRACE (ट्रांसलेटिंग कोड एफिशिएंसी - Translating Code Efficiency) हल करता है।

समस्या: "यह काम करता है, लेकिन यह धीमा है"

लंबे समय से, शोधकर्ता बड़े भाषा मॉडल (LLMs) की कोड अनुवाद करने की क्षमता (जैसे C++ कोड को Python में बदलना) का परीक्षण कर रहे हैं। वे पूछ रहे हैं: "क्या कोड बिना क्रैश हुए चलता है?"

यदि कोड चलता है, तो वे उसे एक स्वर्ण पदक (gold star) दे देते हैं। लेकिन वे एक महत्वपूर्ण प्रश्न को अनदेखा कर रहे हैं: "इसे चलाने में कितनी तेजी और कितनी कम लागत आती है?"

लेखक इस बात को समझाने के लिए एक मजेदार उपमा का उपयोग करते हैं: कल्पना कीजिए कि एक अनुवादक "दुकान तक जाओ" जैसे सरल निर्देश को "दुकान तक जाओ, लेकिन पहले, चंद्रमा तक एक चक्कर लगाओ, वापस आओ, और फिर दुकान तक जाओ" में बदल देता है। निर्देश तकनीकी रूप से सही है (आप अभी भी दुकान पर ही पहुँचते हैं), लेकिन यह अविश्वसनीय रूप से अक्षम है।

समाधान: "स्ट्रेस टेस्ट" जिम

लेखकों ने TRACE नामक एक नया बेंचमार्क बनाया है। TRACE को कोड अनुवादकों के लिए एक हाई-इंटेंसिटी जिम की तरह समझें।

  1. छोटे परीक्षण बनाम स्ट्रेस टेस्ट: पुराने बेंचमार्क धीमी, स्थिर गति से ट्रेडमिल पर चलने जैसे थे। सब कुछ ठीक लग रहा था। TRACE "स्ट्रेस टेस्ट" पेश करता है—ये एक भारी बैकपैक लेकर पहाड़ पर दौड़ने (स्प्रिंट करने) जैसा है।

    • उदाहरण: पेपर में, उन्होंने एक गणितीय एल्गोरिदम का अनुवाद किया। छोटी संख्याओं पर, दोनों "अच्छे" और "बुरे" अनुवाद 0.02 सेकंड में चल गए। लेकिन जब उन्होंने कोड में एक विशाल संख्या डाली (एक स्ट्रेस टेस्ट), तो "बुरा" अनुवाद 11 सेकंड तक चला (500 गुना धीमा!) क्योंकि उसने तर्क में एक ऐसी मूर्खतापूर्ण गलती की जो केवल दबाव में ही सामने आई।

  2. "एफिशिएंसी" स्कोरकार्ड: TRACE केवल यह जाँच नहीं करता कि कोड काम करता है या नहीं; यह मापता है:

    • समय (Time): इसे चलने में कितना समय लगता है?
    • मेमोरी (Memory): यह कितनी RAM खाता है?

उन्होंने क्या खोजा

लेखकों ने इस नए जिम का उपयोग करके 28 अलग-अलग AI मॉडलों (OpenAI और Google जैसे बड़े टेक दिग्गजों से लेकर ओपन-सोर्स मॉडल तक) का परीक्षण किया। यहाँ सरल भाषा में समझाए गए आश्चर्यजनक निष्कर्ष दिए गए हैं:

  • "स्मार्ट" होने का मतलब "तेज़" होना नहीं है: वह AI मॉडल जो सही उत्तर देने में सबसे अच्छा था (Claude-4-think), वह वास्तव में तेज़ होने के मामले में औसत दर्जे का था। वहीं, एक छोटा, सस्ता ओपन-सोर्स मॉडल (Qwen2.5) अक्सर तेज़ था। यह साबित हुआ कि तर्क में "प्रतिभाशाली" होना अपने आप में "दक्षता विशेषज्ञ" (efficiency expert) होने की गारंटी नहीं है।
  • "अनुवाद का जाल" (The Translation Trap): लगभग 4 में से 1 अनुवाद जो तकनीकी रूप से सही था, फिर भी प्रदर्शन के मामले में बहुत खराब था।
      • "गलत टूल" की समस्या:* कभी-कभी AI काम के लिए गलत टूल चुन लेता है। कल्पना कीजिए कि अखरोट तोड़ने के लिए हथौड़े का उपयोग करना। कोड के संदर्भ में, AI एक धीमा, जटिल डेटा स्ट्रक्चर इस्तेमाल कर सकता है जब कि एक सरल, तेज़ स्ट्रक्चर काम आ सकता था।
      • "भाषा का टकराव":* कभी-कभी AI भूल जाता है कि अलग-अलग भाषाओं के अलग-अलग "इडियम्स" (idioms) होते हैं। वह एक तेज़ C++ ट्रिक को एक धीमे, बोझिल Python लूप में अनुवाद कर सकता है, यह जाने बिना कि Python के पास इसके लिए एक इन-बिल्ट शॉर्टकट मौजूद है।
  • प्रॉम्प्टिंग कोई जादू की छड़ी नहीं है: शोधकर्ताओं ने AI को "चीट शीट्स" (प्रॉम्प्ट्स) देने की कोशिश की, जिसमें उसे बताया गया, "हे, इसे तेज़ बनाओ!" इससे थोड़ी मदद मिली, लेकिन पर्याप्त नहीं। यह एक ड्राइवर को यह सिखाए बिना "तेज़ चलो" कहने जैसा है कि गियर कैसे बदलते हैं। AI में अभी भी दक्षता की एक आंतरिक समझ की कमी है।

यह क्यों मायने रखता है

वास्तविक दुनिया में, सॉफ्टवेयर केवल "क्या यह काम करता है?" के बारे में नहीं है, बल्कि "क्या यह अच्छी तरह से काम करता है?" के बारे में है।

  • लागत (Cost): धीमा कोड सर्वर बिलों में अधिक पैसा खर्च कराता है।
  • बैटरी (Battery): अक्षम कोड आपके फोन की बैटरी खत्म कर देता है।
  • उपयोगकर्ता अनुभव (User Experience): किसी को भी ऐसा ऐप पसंद नहीं आता जो 10 सेकंड के लिए फ्रीज हो जाए।

मुख्य निष्कर्ष (The Bottom Line)

पेपर का तर्क है कि हमें कोड अनुवाद को केवल एक सरल भाषा अभ्यास की तरह नहीं, बल्कि इंजीनियरिंग की तरह मानना चाहिए। सिर्फ इसलिए कि एक पुल खड़ा है (सटीकता), इसका मतलब यह नहीं है कि वह भारी ट्रैफिक को भी संभाल सकता है (दक्षता)।

TRACE वह नया पैमाना है जिसकी हमें न केवल यह मापने के लिए आवश्यकता है कि कोड सही है या नहीं, बल्कि यह भी कि क्या वह अच्छा है। यह AI जगत के लिए एक चेतावनी है: "सिर्फ ऐसा कोड बनाना बंद करें जो काम करता है; ऐसा कोड बनाना शुरू करें जो उड़ता है।"

अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?

आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।

Digest आज़माएँ →

इसी तरह के और पेपर

इस विषय के सभी पेपर देखें 💻 cs →