Untrusted Authors, Trusted Answers: A Calculus of Fidelity-Graded Translations
यह शोध पत्र एक लीन 4-मैकेनाइज्ड कैलकुलस (Lean 4-mechanized calculus) और एक ड्यूल-प्लेन सिस्टम ("हर्डी-गर्डी") प्रस्तुत करता है जो अविश्वसनीय LLMs को प्रोग्रामिंग भाषाओं के बीच स्व-प्रमाणित, फिडेलिटी-ग्रेडेड अनुवाद उत्पन्न करने में सक्षम बनाता है, यह सुनिश्चित करते हुए कि एक निरंतर विकसित होता, मानव-सत्यापित ट्रस्ट ग्राफ निरंतर बढ़ती आश्वासन के साथ निर्णायक प्रोग्राम प्रश्नों पर अभिसरित (converge) होता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
जासूसी की दुविधा: जब आप संदेशवाहक पर भरोसा नहीं कर सकते
कल्पना कीजिए कि आप एक जटिल मशीन, जैसे कि कार के इंजन या किसी वीडियो गेम के पात्र के व्यवहार के बारे में एक रहस्य सुलझाने की कोशिश कर रहे हैं। आपके पास एक प्रश्न है: "यदि मैं 50 मील प्रति घंटे की गति पर एक्सीलरेटर दबाता हूँ, तो क्या यह कार दुर्घटनाग्रस्त हो जाएगी?" इसका उत्तर देने के लिए, आप केवल कार को देख कर काम नहीं चला सकते; आपको इसकी अव्यवस्थित, वास्तविक दुनिया की यांत्रिकी को एक ऐसी भाषा में अनुवादित करना होगा जिसे एक सुपर-स्मार्ट कंप्यूटर सॉल्वर समझ सके, जैसे कि एक गणितीय समीकरण। लेकिन यहाँ एक पेंच है: जो व्यक्ति कार का गणित में अनुवाद कर रहा है, वह गलती कर सकता है। शायद वह एक गियर भूल गया, या शायद उसने ब्रेक कैसे काम करते हैं, इसे समझने में चूक कर दी। यदि अनुवादक गलत है, तो गणितीय सॉल्वर आपको गलत प्रश्न का एकदम सटीक उत्तर देगा।
कंप्यूटर विज्ञान की दुनिया में, यह "अनुवाद" (translation) की समस्या है। हमें अक्सर एक प्रोग्राम को एक भाषा (जैसे C या Python) से दूसरी भाषा (जैसे सॉल्वर के लिए एक लॉजिक पहेली) में स्थानांतरित करना पड़ता है ताकि यह जांचा जा सके कि वह सुरक्षित है या नहीं। पारंपरिक रूप से, वैज्ञानिकों ने इसे यह सिद्ध करके हल करने की कोशिश की कि अनुवादक एक बार के लिए और हमेशा के लिए पूर्ण है, जैसे कि किसी के गाड़ी चलाने से पहले पुल को सुरक्षित प्रमाणित करना। लेकिन यह अविश्वसनीय रूप से कठिन है, खासकर जब अनुवादक जटिल हों या उन्हें आर्टिफिशियल इंटेलिजेंस द्वारा लिखा गया हो। यह शोध पत्र एक अलग सवाल पूछता है: क्या होगा अगर हम अनुवादक को पूर्ण सिद्ध करने की कोशिश करना छोड़ दें, और इसके बजाय एक ऐसा सिस्टम बनाएं जो काम करते समय ही अनुवादक की गलतियों को पकड़ ले? यह एक जंगल में आपका मार्गदर्शन करने के लिए एक अकेले गाइड पर भरोसा करने और गाइडों की एक टीम रखने के बीच का अंतर है जो एक-दूसरे के मानचित्रों की जांच करते हैं, और जिनका नियम यह है कि यदि वे असहमत हों, तो आप रुक जाएं और पता लगाएं कि कौन गलत है।
"हर्डी-गर्डी" मशीन: भरोसेमंद उत्तरों का एक कारखाना
यह शोध पत्र hurdy-gurdy नामक एक सिस्टम पेश करता है (इसका नाम एक संगीत वाद्ययंत्र के नाम पर रखा गया है जो धुनें निकालता है, लेकिन यहाँ यह उत्तर निकालता है)। लेखक, क्रिस्टोफ किर्श के नेतृत्व में, कंप्यूटर प्रोग्रामों को संभालने का एक नया तरीका प्रस्तावित करते हैं: उन्हें "टेलीफोन" के खेल की तरह मानें जहाँ हर कदम की जाँच की जाती है, और हर उत्तर के साथ एक रसीद आती है।
मूल विचार सरल लेकिन शक्तिशाली है: अनुवादक पर भरोसा न करें; प्रक्रिया पर भरोसा करें।
कल्पंत कीजिए कि आपके पास C भाषा में लिखे गए एक प्रोग्राम के बारे में एक प्रश्न है। प्रोग्राम को केवल एक अनुवादक के पास भेजने के बजाय, सिस्टम इसे दो अलग-अलग रास्तों पर भेजता है।
- अनुवाद (The Translation): प्रोग्राम को एक सरल लॉजिक भाषा में अनुवादित किया जाता है (जैसे एक उपन्यास को गणितीय समीकरण में बदलना)।
- दोहरी जाँच (The Double-Check): सिस्टम मूल प्रोग्राम और अनुवादित संस्करण को साथ-साथ चलाता है। यह जाँचता है कि क्या वे एक ही तरह से व्यवहार करते हैं। यदि वे करते हैं, तो बहुत अच्छा! यदि वे नहीं करते हैं, तो सिस्टम ठीक उस चरण की ओर इशारा करता है जहाँ वे अलग हुए, जैसे कि रेफरी द्वारा ठीक उसी क्षण सीटी बजाना जब कोई खिलाड़ी फाउल करता है।
- "विटनेस" ट्रिक (The "Witness" Trick): यदि सॉल्वर कहता है, "हाँ, दुर्घटना संभव है," तो सिस्टम केवल सॉल्वर की बात पर विश्वास नहीं करता। वह "प्रमाण" (वे विशिष्ट स्थितियाँ जो दुर्घटना का कारण बनती हैं) को लेता है और उसे अनुवाद के माध्यम से पीछे की ओर चलाता है। वह उन स्थितियों को मूल प्रोग्राम में फीड करता है। यदि मूल प्रोग्राम वास्तव में दुर्घटनाग्रस्त होता है, तो उत्तर 100% वास्तविक है। सिस्टम ने अपराध स्थल को "रीप्ले" कर लिया है।
दो तल (The Two Planes): निर्माण और उपयोग
इस सिस्टम के दो अलग-अलग मोड हैं, जैसे एक फैक्ट्री का फर्श और एक शोरूम:
- उपयोग तल (The Use Plane - शोरूम): यह वह जगह है जहाँ उत्तर मिलते हैं। यहाँ, एक AI (या एक मानव) प्रश्न पूछता है। सिस्टम केवल अनुमान नहीं लगाता; यह एक मार्ग चुनता है, अनुवाद की जाँच करता है, और यदि उत्तर "हाँ, यह संभव है" है, तो यह प्रमाण के लिए रीप्ले चलाता है। यदि उत्तर "नहीं, यह असंभव है" है, तो सिस्टम जाँचों के एक ढेर पर भरोसा करता है: कई अनुवादक, कई सॉल्वर, और यहाँ तक कि गणितीय रूप से सत्यापित प्रमाणपत्र भी, ताकि सुनिश्चित किया जा सके।
- विकास तल (The Evolution Plane - कारखाना): यह वह जगह है जहाँ सिस्टम बढ़ता है। यदि सिस्टम किसी प्रश्न का उत्तर नहीं दे पाता है, तो वह हार नहीं मानता। वह लिख देता है कि वह क्यों विफल हुआ (उदाहरण के लिए, "हमारे पास इस विशिष्ट प्रकार के लूप के लिए अनुवादक नहीं है")। फिर वह एक नया अनुवादक बनाने के लिए AI का उपयोग करता है ताकि उस कमी को पूरा किया जा सके। एक बार बनने के बाद, नए अनुवादक का पुराने अनुवादकों के विरुद्ध परीक्षण किया जाता है। यदि वह पास हो जाता है, तो उसे रजिस्ट्री में जोड़ दिया जाता है। यदि वह विफल हो जाता है, तो उसे सुधारा जाता है। यह लूप अनिश्चित काल तक चलता रहता है, जिससे सिस्टम समय के साथ अधिक स्मार्ट और अधिक भरोसेमंद बनता है, लेकिन महत्वपूर्ण रूप से, विकास प्रक्रिया स्वयं कभी भी प्रश्न का उत्तर नहीं देती। यह केवल उत्तर देने के लिए उपकरण बनाती है।
"अविश्वसनीय रचनाकारों" का मोड़
शोध पत्र का सबसे आश्चर्यजनक हिस्सा यह है कि अनुवादकों को स्वयं अविश्वसनीय AI एजेंटों द्वारा बनाया गया था। लेखकों ने अनुवादकों को हाथ से कोड नहीं किया; उन्होंने एक पन्ने के विवरण के आधार पर AI मॉडल से उन्हें लिखने के लिए कहा। सामान्यतः, यह एक आपदा होती। लेकिन क्योंकि सिस्टम हर चरण की जाँच करता है, AI की गलतियों को तुरंत पकड़ लिया गया।
उदाहरण के लिए, एक परीक्षण में, एक AI अनुवादक ने एक विशिष्ट निर्देश को छोड़ दिया, जिससे वह मूल प्रोग्राम की तुलना में अलग व्यवहार करने लगा। सिस्टम के "स्क्वायर चेक" (साइड-बाय-साइड तुलना) ने त्रुटि को तुरंत पकड़ लिया, और ठीक उस लाइन और उस वेरिएबल की पहचान की जो गलत था। सिस्टम ने फिर अनुवादक को ठीक कर दिया। शोध पत्र दिखाता है कि भले ही AI रचनाकार गलत हो सकते हैं, सिस्टम का आर्किटेक्चर यह सुनिश्चित करता है कि अंतिम उत्तर भरोसेमंद हों।
सिस्टम ने क्या पाया (और क्या नहीं पाया)
लेखकों ने जुलाई 2026 के अपने कार्य के एक स्नैपशॉट पर इस सिस्टम को चलाया। यहाँ वे चीजें हैं जिन्हें उन्होंने मापा:
- कवरेज (Coverage): उन्होंने 13 अलग-अलग भाषाओं (C, Python और यहाँ तक कि रासायनिक प्रतिक्रिया नेटवर्क सहित) से प्रोग्रामों को सफलतापूर्वक लॉजिक सॉल्वरों में अनुवादित किया। RISC-V प्रोसेसर भाषा के लिए, उन्होंने 96 में से 96 विशिष्ट निर्देश प्रकारों को कवर किया, जिसका अर्थ है कि सिस्टम बिना कुछ खोए उस सेट के प्रत्येक निर्देश को संभाल सकता था।
- सहमति (Agreement): जब उन्होंने एक ही प्रश्न को दो अलग-अलग अनुवाद पथों (एक मैनुअल पर आधारित और दूसरा औपचारिक मॉडल पर आधारित) के माध्यम से भेजा, तो टेस्ट केस पर उनके उत्तर 100% समय सहमत थे।
- पकड़ी गई खामियां (Defects Caught): सिस्टम ने अपने स्वयं के अनुवादकों और उपकरणों में 24 विशिष्ट दोषों को पकड़ा। कुछ साधारण टाइपो थे, अन्य लॉजिक त्रुटियां थीं जहाँ AI ने यह समझने में गलती की थी कि एक कंप्यूटर निर्देश कैसे काम करता है। महत्वपूर्ण रूप से, सिस्टम ने इन त्रुटियों को मानव द्वारा कोड देखे बिना ही खोज लिया।
- "ब्लाइंड स्पॉट" (The Blind Spot): सिस्टम ने एक सीमा भी पाई। यदि दो अलग-अलग अनुवादक ठीक वही गलती करते हैं (क्योंकि दोनों ने एक ही नियम को गलत समझा है), तो सिस्टम उसे नहीं पकड़ सकता। इसे "कॉमन-मोड फेल्योर" कहा जाता है। पेपर स्वीकार करता है कि यह एक जोखिम है, लेकिन सिस्टम को विविध स्रोतों का उपयोग करके इस जोखिम को कम करने के लिए डिज़ाइन किया गया है।
- LLM खिलाड़ी (LLM Players): उन्होंने परीक्षण किया कि क्या एक AI सिस्टम का उपयोग करके उत्तर दे सकता है। एक प्रयोग में, बिना टूल्स वाले AI ने 8 में से 7 प्रश्नों के सही उत्तर दिए लेकिन कठिन वाले पर अनुमान लगाया। सिस्टम के साथ वाला AI 8 में से 8 सही उत्तर दे पाया, और हर उत्तर के साथ एक मशीन-चेक किया गया प्रमाण भी था।
निचोड़
यह शोध पत्र यह दावा नहीं करता है कि इसने सभी कंप्यूटर सुरक्षा समस्याओं को हल कर लिया है। यह यह नहीं कहता कि AI अनुवादक अब पूर्ण हैं। इसके बजाय, यह सिद्ध करता है कि आप अविश्वसनीय हिस्सों से एक भरोसेमंद सिस्टम बना सकते हैं।
हर अनुवाद को एक संभावित गलती मानकर और एक ऐसा "रैचेट" (ratchet) बनाकर जो केवल सुधारों को टिकने की अनुमति देता है, सिस्टम विश्वास की एक सीढ़ी बनाता है। यदि प्रश्न यह है कि "क्या यह हो सकता है?", तो सिस्टम घटना को साबित करने के लिए उसे रीप्ले कर सकता है। यदि उत्तर "नहीं, यह नहीं हो सकता" है, तो सिस्टम निश्चित होने के लिए स्वतंत्र जाँचों और गणितीय रूप से सत्यापित प्रमाणों की एक श्रृंखला पर निर्भर करता है।
लेखक निष्कर्ष निकालते हैं कि यह दृष्टिकोण—रास्तों के ग्राफ का उपयोग करना, हर चरण की जाँच करना और साक्ष्य को रीप्ले करना—आधुनिक सॉफ़्टवेयर की जटिलता को संभालने का एक व्यवहार्य तरीका है, भले ही उपकरण बनाने वाले लोग (या AI) त्रुटिपूर्ण हों। यह "रचनाकार पर विश्वास करने" से "आर्किटेक्चर पर विश्वास करने" की ओर एक बदलाव है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।