💻 computer science

Validated Code Translation for Projects with External Libraries

यह शोध पत्र एक ऐसे ढांचे को प्रस्तुत करता है जो सार्वजनिक लाइब्रेरी एपीआई से एडेप्टर (adapters) को संश्लेषित करने वाले क्रॉस-लैंग्वेज वैलिडेशन पाइपलाइन के साथ एक एपीआई रिट्रीवल मैकेनिज्म को जोड़कर, बाहरी डिपेंडेंसी वाले गो (Go) प्रोजेक्ट्स को रस्ट (Rust) में अनुवादित करने की प्रक्रिया को उन्नत करता है, जिससे संकलन सफलता दर (compilation success rates) में उल्लेखनीय सुधार होता है और ओपेक टाइप्स (opaque types) का हेरफेर करने वाले कोड के लिए सिमेंटिक समानता सुनिश्चित होती है।

मूल लेखक: Hanliang Zhang, Arindam Sharma, Cristina David, Meng Wang, Brandon Paulsen, Daniel Kroening, Wenjia Ye, Taro Sekiyama

प्रकाशित 2026-02-24

📖 6 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Hanliang Zhang, Arindam Sharma, Cristina David, Meng Wang, Brandon Paulsen, Daniel Kroening, Wenjia Ye, Taro Sekiyama

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

कल्पना कीजिए कि आपके पास एक विशाल, जटिल लाइब्रेरी है जो Go (एक प्रोग्रामिंग भाषा) में लिखी गई है, और आप उन सभी किताबों को एक नई, अधिक सख्त और सुरक्षित लाइब्रेरी में ले जाना चाहते हैं जो Rust में लिखी गई है। यह एक व्यस्त शहर को एक देश से दूसरे देश में ले जाने जैसा है जहाँ कानून, सड़क के संकेत और यहाँ तक कि भाषा भी थोड़ी अलग है।

आपने जो पेपर साझा किया है वह एक नए "मूविंग कंपनी" (एक सॉफ़्टवेयर टूल) के बारे में है जो इस अनुवाद को करने के लिए AI का उपयोग करता है, लेकिन इसमें एक विशेष मोड़ है: यह उन दो समस्याओं को हल करता है जिन्हें पिछले मूवर्स संभाल नहीं सके थे।

यह कहानी है कि उन्होंने इसे कैसे किया, कुछ रोज़मर्रा के उदाहरणों का उपयोग करते हुए।

समस्या: "भ्रमित करने वाला" अनुवादक और "बंद बक्से" (Locked Boxes)

अतीत में, जब AI ने कोड को अनुवाद करने की कोशिश की, तो उसे दो बड़ी समस्याओं का सामना करना पड़ा:

भ्रमित होने वाला लाइब्रेरियन (The Hallucinating Librarian):
कल्पना कीजिए कि आप एक AI से एक Go फंक्शन को अनुवाद करने के लिए कहते हैं जो sha512 नामक एक विशिष्ट टूल का उपयोग करता है। AI, मददगार बनने की कोशिश में, एक नकली Rust टूल sha512_rust_new बना सकता है जो वास्तव में मौजूद ही नहीं है। या, हो सकता है कि उसे पता हो कि वह टूल मौजूद है, लेकिन वह उस "निर्देश पुस्तिका" (import statement) को लाना भूल जाए जिसकी उसे उपयोग करने के लिए आवश्यकता है।
- परिणाम: अनुवाद कागज़ पर तो अच्छा दिखता है, लेकिन जब आप इसे बनाने (build करने) की कोशिश करते हैं, तो यह क्रैश हो जाता है क्योंकि टूल्स गायब हैं या नकली हैं।
बंद बक्से (Opaque Types):
पुराने दिनों में, यदि आप यह जांचना चाहते थे कि अनुवाद काम कर रहा है या नहीं, तो आप बस "पहले" और "बाद के" बक्सों की तुलना करते। लेकिन आधुनिक प्रोग्रामिंग में, लाइब्रेरी अक्सर "ओपेक टाइप्स" (opaque types) का उपयोग करती हैं।
- उदाहरण: कल्पना कीजिए कि एक Go प्रोग्राम एक फंक्शन को एक लॉक की गई तिजोरी (safe) भेजता है। AI उस कोड को Rust में अनुवाद करता है, लेकिन अब वह एक अलग प्रकार की तिजोरी है। आप तिजोरी को खोलकर यह नहीं देख सकते कि उसके अंदर क्या है क्योंकि चाबियाँ अलग हैं, और तिजोरियाँ अलग सामग्रियों से बनी हैं। आप तुलना करने के लिए उनके अंदर भी नहीं झाँक सकते। पिछले टूल्स यहाँ हार मान लेते थे क्योंकि वे इन "बंद बक्सों" के अंदर की तुलना नहीं कर पाते थे।

समाधान: "क्रॉसक्रेट" (CrossCrate) मूविंग कंपनी

लेखकों ने CrossCrate नामक एक सिस्टम बनाया है जो एक सुपर-स्मार्ट, अच्छी तरह से तैयार मूविंग टीम की तरह काम करता है। उन्होंने दो मुख्य चरणों में इन समस्याओं को हल किया:

चरण 1: "रियल-टाइम डिक्शनरी" (RAG)

AI को नकली टूल्स बनाने से रोकने के लिए, उन्होंने इसे एक रियल-टाइम डिक्शनरी (तकनीकी रूप से जिसे रिट्रीवल-ऑगमेंटेड जनरेशन या RAG कहा जाता है) दी।

यह कैसे काम करता है: AI द्वारा कोड की एक लाइन को अनुवाद करने से पहले, वह रुकता है और एक विशाल, सत्यापित डेटाबेस से पूछता है: "हे, इस Go टूल का सटीक Rust समकक्ष क्या है? और मुझे कौन सी सटीक लाइन लिखनी चाहिए ताकि यह काम कर सके?"
उदाहरण: AI को अपनी याददाश्त से अनुमान लगाने देने के बजाय (जो गलतियों के प्रति संवेदनशील है), वे उसे Rust शहर का एक सत्यापित मानचित्र (verified map) थमा देते हैं। यदि Go कोड किसी विशिष्ट लाइब्रेरी का उपयोग करता है, तो मानचित्र AI को बताता है कि उसे किस Rust 'crate' (लाइब्रेरी) का उपयोग करना चाहिए और सबसे महत्वपूर्ण बात यह है कि उसे कौन सी सटीक "import" लाइनें लिखनी हैं ताकि कोड वास्तव में कंपाइल हो सके।
परिणाम: AI नकली टूल्स बनाना बंद कर देता है। वह केवल वास्तविक, मौजूदा टूल्स और सही निर्देशों का उपयोग करता है।

चरण 2: "यूनिवर्सल पैकिंग क्रेट" (The Adapter)

"बंद बक्से" की समस्या को हल करने के लिए, उन्होंने एक यूनिवर्सल पैकिंग क्रेट का आविष्कार किया।

समस्या: आप एक Go "तिजोरी" की सीधे एक Rust "तिजोरी" से तुलना नहीं कर सकते।
समाधान: उन्होंने एक तटस्थ, मानक कंटेनर बनाया (जो Protobuf नामक प्रारूप पर आधारित है)।
1. पैकिंग: वे Go "तिजोरी" को लेते हैं, उसे खोलते हैं (लाइब्रेरी की सार्वजनिक कुंजियों का उपयोग करके), और उसकी सामग्री को इस यूनिवर्सल क्रेट में पैक करते हैं।
2. अनपैकिंग: वे Rust "तिजोरी" को लेते हैं, उसे खोलते हैं, और उसकी सामग्री को एक समान य적인 यूनिवर्सल क्रेट में पैक करते हैं।
3. तुलना: अब, दो अलग-अलग तिजोरियों की तुलना करने के बजाय, वे केवल यूनिवर्सल क्रेट्स की तुलना करते हैं। चूंकि क्रेट्स डिज़ाइन के अनुसार समान हैं, इसलिए यदि सामग्री मेल खाती है, तो अनुवाद सही है!
उदाहरण: कल्पना कीजिए कि आप एक नाजुक फूलदान को स्थानांतरित कर रहे हैं। आप पुराने घर के फूलदान की तुलना नए घर के फूलदान से सीधे नहीं कर सकते क्योंकि वे अलग तरह से लिपटे हुए हैं। इसलिए, आप फूलदान को बाहर निकालते हैं, उसे एक मानक शिपिंग बॉक्स में रखते हैं, उसे ले जाते हैं, और फिर देखते हैं कि बॉक्स की सामग्री मेल खाती है या नहीं। यदि वे मेल खाते हैं, तो फूलदान सुरक्षित है।

परिणाम: एक आदर्श स्थानांतरण

टीम ने वास्तविक दुनिया के छह जटिल Go प्रोजेक्ट्स (जैसे पासवर्ड जेनरेटर और एन्क्रिप्शन टूल्स) पर इसका परीक्षण किया जो बाहरी लाइब्रेरीओं पर बहुत अधिक निर्भर थे।

उनकी मदद के बिना: AI कोड को कंपाइल करने में विफल रहा या यह साबित नहीं कर सका कि यह काम करता है (सबसे कठिन कार्यों पर 0% सफलता)।
उनकी मदद के साथ: उन्होंने 95% से 100% सफलता दर हासिल की।
- कोड वास्तव में कंपाइल हुआ (कोई नकली टूल्स नहीं)।
- कोड बिल्कुल एक जैसा व्यवहार करता था (यूनिवर्सल क्रेट्स मेल खाते थे)।

मुख्य निष्कर्ष

यह पेपर AI को एक सावधान, अच्छी तरह से शोधित अनुवादक बनने के लिए सिखाने के बारे में है, न कि केवल एक आत्मविश्वासी अनुमान लगाने वाले के बारे में।

टूल्स का अनुमान न लगाएं: सही टूल्स और निर्देश खोजने के लिए एक सत्यापित डेटाबेस का उपयोग करें।
बंद बक्सों के अंदर न झांकें: डेटा को एक भाषा से दूसरी भाषा में ले जाने के लिए एक मानक "पैकिंग क्रेट" का उपयोग करें ताकि आप निष्पक्ष रूप से तुलना कर सकें।

ऐसा करके, उन्होंने यह संभव बना दिया कि जटिल, वास्तविक दुनिया के सॉफ़्टवेयर को एक भाषा से दूसरी भाषा में स्वचालित और सुरक्षित रूप से माइग्रेट किया जा सके, भले ही वह सॉफ़्टवेयर रहस्यमय, लॉक-डाउन लाइब्रेरीओं पर निर्भर हो।

यहाँ शोध पत्र "Validated Code Translation for Projects with External Libraries" का विस्तृत तकनीकी सारांश दिया गया है।

1. समस्या विवरण (Problem Statement)

यह शोध पत्र उन बाहरी लाइब्रेरीज़ (external libraries) पर अत्यधिक निर्भर सॉफ़्टवेयर प्रोजेक्ट्स (विशेष रूप से Go से Rust) के अनुवाद के लिए लार्ज लैंग्वेज मॉडल्स (LLMs) के उपयोग की महत्वपूर्ण सीमाओं को संबोधित करता है। मौजूदा दृष्टिकोण दो प्राथमिक क्षेत्रों में विफल रहते हैं:

भ्रम (Hallucination) और इम्पोर्ट रेज़ोल्यूशन (Import Resolution): LLMs अक्सर गैर-मौजूद लक्षित API को भ्रमित रूप से बना देते हैं या गलत लाइब्रेरी चुन लेते हैं। इसके अलावा, वे आवश्यक import स्टेटमेंट्स उत्पन्न करने में भी विफल रहते हैं जो Rust में उन APIs को कॉल करने योग्य बनाने के लिए आवश्यक हैं, विशेष रूप से तब जब APIs को ट्रेट्स (traits) या क्रेट्स (crates) के माध्यम से री-एक्सपोर्ट किया जाता है।
ओपेक टाइप्स (Opaque Types) का सत्यापन: जब फ़ंक्शंस ओपेक लाइब्रेरी-परिभाषित प्रकारों (ऐसे प्रकार जिनमें प्राइवेट फील्ड्स या जटिल आंतरिक इनवेरिएंट्स होते हैं) का हेरफेर करते हैं, तो स्रोत और लक्ष्य कोड के बीच सिमेंटिक समानता को सत्यापित करना कठिन होता है। पारंपरिक डिफरेंशियल टेस्टिंग (differential testing) इनपुट/आउटपुट प्रकारों की संरचनात्मक पहचान (structural identity) को मानती है, जो तब टूट जाती है जब प्रकार बाहरी लाइब्रेरी में परिभाषित होते हैं और उन्हें भाषा की सीमाओं के पार सीधे तुलना या सीरियलाइज़ नहीं किया जा सकता।

2. कार्यप्रणाली (Methodology)

लेखक CrossCrate प्रस्तावित करते हैं, जो एक अनुवाद और सत्यापन ढांचा (framework) है जो रिट्रीवल-ऑगमेंटेड जनरेशन (RAG) को स्कीमा-बैकड क्रॉस-लैंग्वेज इंटरऑपरेबिलिटी पाइपलाइन के साथ जोड़ता है। यह दृष्टिकोण तीन चरणों में विभाजित है:

चरण 1: क्रॉस-लैंग्वेज लाइब्रेरी मैपिंग (RAG)

भ्रम को रोकने और इम्पोर्ट को हल करने के लिए, सिस्टम LLM प्रॉम्प्ट को क्रेट-स्कोपेड नॉलेज बेस (Crate-Scoped Knowledge Base) के साथ संवर्धित करता है:

क्रेट मैचिंग (Crate Matching): Go पैकेजों को संगत Rust क्रेट्स के साथ मैप करता है (जैसे, crypto/sha512 $\to$ sha2)।
नॉलेज बेस निर्माण ( $K_{crate}$ ): प्रत्येक लक्षित क्रेट के लिए, सिस्टम सार्वजनिक APIs, उनके दस्तावेज़ों और महत्वपूर्ण रूप से, उनके वैध इम्पोर्ट पाथ्स (री-एक्सपोर्ट और ट्रेइट स्कोप को संभालते हुए) को इंडेक्स करता है।
रिट्रीवल (Retrieval): Go फ़ंक्शन का अनुवाद करते समय, सिस्टम Go API के नाम और दस्तावेज़ का उपयोग करके $K_{crate}$ से शीर्ष-रैंक वाले Rust API उम्मीदवारों और उनके उपयोग के लिए आवश्यक सटीक इम्पोर्ट स्टेटमेंट्स को प्राप्त करता है।

चरण 2: अनुवाद जनरेशन (Translation Generation)

LLM प्राप्त API उम्मीदवारों और इम्पोर्ट पाथ्स को संदर्भ (context) के रूप में उपयोग करके Rust अनुवाद उत्पन्न करता है। अनुवाद मॉड्यूलर है, जो डिपेंडेंसी समरी के मार्गदर्शन में प्रकारों और फ़ंक्शन्स को अलग-थलग (isolation) तरीके से संभालता है।

चरण 3: क्रॉस-लैंग्वेज वैलिडेशन (मुख्य नवाचार)

डायरेक्ट मेमोरी शेयरिंग या स्ट्रक्चरल टाइप मैचिंग के बिना समानता को सत्यापित करने के लिए, लेखक एक स्कीमा-बैकड कैरियर रिप्रेजेंटेशन (Schema-Backed Carrier Representation) पेश करते हैं:

प्रोटोबफ स्कीमा सिंथेसिस (Protobuf Schema Synthesis): एक LLM मूल Go प्रकारों से एक भाषा-तटस्थ प्रोटोबफ स्कीमा ( $T_{Proto}$ ) तैयार करता है। यह स्कीमा एक इंटरमीडिएट डेटा फॉर्मेट (IDF) के रूप में कार्य करता है।
कैरियर प्रकार (Carrier Types): प्रोटोबफ कंपाइलर दोनों Go ( $T_{Go}^{Proto}$ ) और Rust ( $T_{Rust}^{Proto}$ ) में ठोस कैरियर प्रकार उत्पन्न करता है।
एडाप्टर सिंथेसिस (Adapter Synthesis): सिस्टम इनके बीच रूपांतरण के लिए "ग्लू कोड" (एडाप्टर) तैयार करता है:
- मूल Go प्रकार $\leftrightarrow$ Go कैरियर ( $T_{Go}^{Proto}$ )
- मूल Rust प्रकार $\leftrightarrow$ Rust कैरियर ( $T_{Rust}^{Proto}$ )
- प्रतिबंध: ये एडाप्टर विशेष रूप से सार्वजनिक लाइब्रेरी APIs (कन्स्ट्रक्टर्स, सीरियलाइजेशन रूटीन) का उपयोग करके सिंथेसाइज किए जाते हैं, न कि डायरेक्ट फील्ड एक्सेस के माध्यम से, जिससे वे लाइब्रेरी इनवेरिएंट्स का सम्मान करते हैं।
राउंड-ट्रिप वैलिडेशन (Round-Trip Validation): समानता का परीक्षण करने से पहले, सिस्टम यूनिट-टेस्ट इनपुट्स पर राउंड-ट्रिप गुणों (जैसे, $A^{-1}_{Go}(A_{Go}(v)) = v$ ) की जाँच करके यह सत्यापित करता है कि एडाप्टर जानकारी को सुरक्षित रखते हैं।
डिफरेंशियल I/O टेस्टिंग (Differential I/O Testing): एक बार इंटरऑपरेबिलिटी स्थापित हो जाने के बाद, सिस्टम मूल Go फ़ंक्शन और अनुवादित Rust फ़ंक्शन को समान इनपुट्स पर चलाता है (कैरियर के माध्यम से परिवर्तित)। यह एक सामान्य प्रतिनिधित्व में वापस बदलने के बाद आउटपुट्स की तुलना करता है ताकि I/O समानता को सत्यापित किया जा सके।

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

ओपेक प्रकारों के लिए प्रथम वैलिडेटेड ट्रांसलेशन: बाहरी लाइब्रेरी द्वारा परिभाषित संरचनात्मक रूप से भिन्न और ओपेक इनपुट/आउटपुट प्रकारों वाले फ़ंक्शन्स की समानता को सत्यापित करने में सक्षम पहला दृष्टिकोण।
इम्पोर्ट रेज़ोल्यूशन के लिए RAG: एक नवीन रिट्रीवल मैकेनिज्म जो न केवल APIs को मैप करता है बल्कि विशिष्ट, नॉन-लोकल इम्पोर्ट पाथ्स को भी हल करता है जो Rust कंपाइलेशन के लिए आवश्यक हैं, जिससे भ्रम (hallucination) काफी कम हो जाता है।
स्कीमा-बैकड इंटरऑपरेबिलिटी: प्रोटोबफ इंटरमीडिएट फॉर्मेट और सिंथेसाइज्ड एडेप्टर का उपयोग करके Go और Rust को जोड़ने का एक तरीका, जो साझा रनटाइम या डायरेक्ट मेमोरी एक्सेस की आवश्यकता के बिना डिफरेंशियल टेस्टिंग को सक्षम बनाता है।
व्यापक मूल्यांकन: एक ढांचा जो केवल सिंटैक्स चेकिंग से आगे बढ़कर कंपाइलेशन सफलता और कार्यात्मक समानता दोनों को सत्यापित करता है।

4. प्रयोगात्मक परिणाम (Experimental Results)

सिस्टम का मूल्यांकन छह वास्तविक दुनिया के Go रिपॉजिटरीज़ पर किया गया जिनमें गैर-मामूली बाहरी निर्भरताएं (जैसे age, pbkdf2, और argon2 जैसी क्रिप्टोग्राफिक लाइब्रेरीज़) शामिल थीं।

कुल सफलता दर (Overall Success Rate): इस दृष्टिकोण ने सभी बेंचमार्क में कंपाइलेशन और I/O समानता के लिए औसतन 95.83% सफलता दर प्राप्त की।
RAG का प्रभाव:
- पूर्ण सिस्टम (Full System): 95.83% (Comp) / 95.83% (Equiv).
- बिना RAG के (Baseline): 41.33% (Comp) / 0% (Equiv).
- बिना इम्पोर्ट्स के (No Imports): 41.33% (Comp) / 0% (Equiv).
- अवलोकन: RAG-आधारित इम्पोर्ट रेज़ोल्यूशन के बिना, LLM लाइब्रेरी-डिपेंडेंट फ़ंक्शन्स के लिए कंपाइलेबल कोड बनाने में विफल रहता है, और सही इम्पोर्ट्स के बिना, समानता सत्यापन असंभव है।
बेसलाइन के साथ तुलना: Oxidizer (एक अत्याधुनिक टूल) की तुलना में, CrossCrate ने औसतन 2x सुधार दिखाया, और सबसे अधिक निर्भरता वाले मामले (age) में 100% सुधार तक पहुँचा, जहाँ Oxidizer लाइब्रेरी-डिपेंडेंट फ़ंक्शन्स पर 0% सफलता प्राप्त करता है।

5. महत्व (Significance)

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