Theory Under Construction: Orchestrating Language Models for Research Software Where the Specification Evolves
यह शोध पत्र Comet-H प्रस्तुत करता है, जो एक इटरेटिव प्रॉम्प्ट ऑटोमेटन (iterative prompt automaton) है जो अनुसंधान सॉफ्टवेयर में मतिभ्रम (hallucination) और असंतुलन (desynchronization) को रोकने के लिए कोड, सिद्धांत और दस्तावेज़ीकरण के युग्मित विकास को व्यवस्थित करता है, और एक पायथन स्टैटिक-एनालिसिस टूल के माध्यम से अपनी प्रभावशीलता प्रदर्शित करता है जो 90-मामलों के बेंचमार्क पर बेसलाइन से काफी बेहतर प्रदर्शन करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक नए तरह की कार बनाने की कोशिश कर रहे हैं, लेकिन आपके पास कोई तैयार ब्लूप्रिंट नहीं है। इसके बजाय, आपके पास इंजीनियरों की एक अविश्वसनीय रूप से प्रतिभाशाली और तेज़ सोचने वाली टीम (AI) है जो एक साथ पुर्जे बना सकती है, इंजन तैयार कर सकती है और ओनर मैनुअल (उपयोगकर्ता मार्गदर्शिका) लिख सकती है।
समस्या यह है कि ये इंजीनियर दो विशिष्ट गलतियाँ करने के आदी हैं:
- "दिखावा करने तक सच मान लो" वाला जाल (The "Fake It Till You Make It" Trap): वे मैनुअल में लिख सकते हैं, "यह कार 200 मील प्रति घंटे की रफ्तार से चलती है," इससे पहले कि उन्होंने वास्तव में यह साबित करने के लिए इंजन बनाया हो कि यह संभव है। फिर, अगला इंजीनियर उस दावे को पढ़ता है, उसे सच मान लेता है, और 200 मील प्रति घंटे की रफ्तार के लिए डिज़ाइन किया गया चेसिस बनाता है। यदि इंजन वास्तव में इतना नहीं कर पाता, तो पूरा प्रोजेक्ट एक झूठ की बुनियाद पर खड़ा हो जाता है।
- "अनुवाद में खो जाने" वाला जाल (The "Lost in Translation" Trap): जिस इंजीनियर ने इंजन डिज़ाइन किया था, उसने काम करने के तरीके के बारे में अपना विचार बदल दिया, लेकिन मैनुअल लिखने वाले को इसकी जानकारी नहीं है। अब मैनुअल एक पुराने इंजन का वर्णन करता है, ब्लूप्रिंट एक नए इंजन को दिखाता है, और असेंबली लाइन पर वास्तविक कार कुछ और ही होती है। वे सब एक-दूसरे से अलग होते जा रहे हैं।
यह शोध पत्र, "Orchestrating Language Models for Research Software Where the Specification Evolves," इन समस्याओं को ठीक करने के लिए Comet-H नामक एक नया सिस्टम पेश करता है। यह अनुसंधान (research) को एक सीधी रेखा के रूप में नहीं, बल्कि एक नृत्य के रूप में देखता है जहाँ संगीत, कदम और नर्तक सभी को एक-दूसरे के साथ लगातार तालमेल बिठाना पड़ता है।
मुख्य विचार: AI के लिए एक "कंडक्टर" (The Core Idea: A "Conductor" for the AI)
AI को केवल "कोड लिखने" के लिए कहने के बजाय, लेखकों ने एक कंडक्टर (कंट्रोलर) बनाया है जो पूरे ऑर्केस्ट्रा का प्रबंधन करता है। यह कंडक्टर केवल AI को यह नहीं बताता कि क्या करना है; यह लगातार "वर्कस्पेस" (कोड, गणितीय सिद्धांत, बेंचमार्क और पेपर) की जांच करता है कि क्या कुछ गायब है या तालमेल से बाहर है।
यहाँ बताया गया है कि Comet-H कैसे काम करता है, सरल उपमाओं का उपयोग करते हुए:
1. "मिटती हुई टू-डू लिस्ट" (The "Fading To-Do List" - Obligation Decay)
कल्पना कीजिए कि आप एक पुस्तक लिख रहे हैं। आपके पास एक स्टिकी नोट है जिस पर लिखा है, "मुझे इस अध्याय की तथ्य-जांच (fact-check) करनी है।"
- पुराना तरीका: यदि आप इसे चेक करना भूल जाते हैं, तो वह नोट हमेशा के लिए वहीं रहता है, आपकी मेज पर भीड़ बढ़ाता है, या आप इसे अनदेखा कर आगे बढ़ जाते हैं।
- Comet-H का तरीका: उस नोट की एक 'हाफ-लाइफ' (अर्ध-आयु) होती है। जैसे ही आप प्रोजेक्ट में एक कदम आगे बढ़ते हैं, वह नोट थोड़ा धुंधला होता जाता है। यदि आप इसे जल्द ही हल नहीं करते हैं, तो यह फीका पड़ जाता है। लेकिन यदि यह बहुत हालिया है, तो यह चमकीले लाल रंग में चमकता है।
- यह क्यों मायने रखता है: यह AI को अधूरे काम (जैसे "इस दावे को सिद्ध करें") को तब तक निपटाने के लिए मजबूर करता है जब तक कि वह ताज़ा है। यदि AI इस ऋण (debt) को अनदेखा करने की कोशिश करता है, तो इसकी "चमक" बढ़ती जाती है, और कंडक्टर AI को आगे बढ़ने से पहले रुकने और इसे ठीक करने के लिए मजबूर करता है।
2. "वास्तविकता की जाँच" (The "Reality Check" - Reactive Grounding)
जब भी AI प्रोजेक्ट के "सार्वजनिक चेहरे" (जैसे README फ़ाइल या रिसर्च पेपर) को बदलता है, Comet-H पॉज़ बटन (Pause Button) दबा देता है।
- नियम: आप तथ्यों की जाँच किए बिना कहानी नहीं बदल सकते।
- प्रक्रिया: यदि AI लिखता है, "हमारा टूल 10 गुना तेज़ है," तो सिस्टम तुरंत रुक जाता है और कहता है, "ठीक है, मुझे दौड़ के परिणाम दिखाओ।" यह AI को कोड चलाने और एक "ग्राउंडिंग लेजर" (एक मशीन-पठनीय रसीद) उत्पन्न करने के लिए मजबूर करता है जो दावे को सिद्ध करता है।
- परिणाम: यह "दिखावा करने तक सच मान लो" वाले जाल को रोकता है। एक झूठ केवल एक कदम तक ही जीवित रह सकता है, इससे पहले कि उसे पकड़ लिया जाए और सुधारा जाए।
3. "सुरक्षित कदम" (The "Safe Step" - Adjacency Constraints)
कभी-कभी, एक AI उत्साहित हो जाता है और "साइकिल बनाने" से सीधे "स्पेसशिप बनाने" की ओर कूदना चाहता है।
- नियम: Comet-H केवल समीपवर्ती कदमों (adjacent moves) की अनुमति देता है। AI एक छोटा कदम आगे ले सकता है (जैसे, "साइकिल में एक गियर जोड़ना"), लेकिन वह पूरी तरह से अलग ब्रह्मांड में नहीं कूद सकता।
- यह क्यों मायने रखता है: यह प्रोजेक्ट को ज़मीन से जोड़े रखता है। यदि AI मूल सिद्धांत को बदलना चाहता है, तो उसे इसे इस तरह से करना होगा कि यह कल जो बनाया गया था उससे जुड़ा रहे। यह इस बात को रोकता है कि टीम इतनी दूर न चली जाए कि वे भूल जाएँ कि वे मूल रूप से क्या बनाने की कोशिश कर रहे थे।
परिणाम: "a3" केस स्टडी (The Results: The "a3" Case Study)
लेखकों ने इस सिस्टम का परीक्षण 46 विभिन्न रिसर्च सॉफ्टवेयर प्रोजेक्ट्स का एक पोर्टफोलियो बनाकर किया। इस शो का मुख्य आकर्षण a3 नामक एक टूल है, जो पायथन (Python) कोड में बग खोजने के लिए डिज़ाइन किया गया एक प्रोग्राम है।
- चुनौती: आमतौर पर, बग-खोजने वाले टूल्स शोर मचाने वाले पड़ोसियों की तरह होते; वे हर चीज़ पर "BUG!" चिल्लाते हैं, भले ही वह ठीक हो। इससे बहुत सारे 'फॉल्स अलार्म' पैदा होते हैं।
- Comet-H का दृष्टिकोण: सिस्टम ने केवल टूल ही नहीं बनाया; इसने इसके पीछे के सिद्धांत को विकसित किया। इसने एक सरल विचार से शुरुआत की, महसूस किया कि यह गणना करने में बहुत कठिन है, और कंडक्टर ने टीम को एक नए गणितीय दृष्टिकोण (इस्तेमाल करते हुए "सेफ्टी सर्टिफिकेट्स") की ओर मुड़ने की अनुमति दी जो वास्तव में काम करता था।
- परिणाम: अंतिम टूल अविश्वसनीय रूप से सटीक था। इसने वास्तविक बग पकड़े (उच्च परिशुद्धता/precision), बिना उन चीजों के बारे में चिल्लाए जो टूटी नहीं थीं। इसने एक टेस्ट स्केल पर 0.768 स्कोर किया, जबकि अगले सबसे अच्छे टूल ने केवल 0.364 स्कोर किया।
हमने AI व्यवहार के बारे में क्या सीखा?
इन 46 प्रोजेक्ट्स पर AI को काम करते हुए देखकर, लेखकों ने कुछ दिलचस्प पैटर्न देखे:
- "क्लीनअप क्रू" (सफाई दल) वास्तविक है: शुरुआत में, AI नए फीचर्स बनाने में व्यस्त रहता है। लेकिन जैसे-जैसे प्रोजेक्ट अंत के करीब पहुँचता है, AI अपना अधिकांश समय ऑडिट करने और ठीक करने में बिताता है। यह एक निर्माण दल की तरह है जो प्रोजेक्ट के आखिरी सप्ताह में केवल यह जाँचने में समय बिताता है कि पेंट सूख गया है या नहीं और दरवाजे खुल रहे हैं या नहीं, बजाय इसके कि वे नई दीवारें बनाएँ।
- ईमानदारी उभरती है: जब उन्हें अपने दावों को सिद्ध करने के लिए मजबूर किया गया, तो AI आश्चर्यजनक रूप से ईमानदार हो गया। विफलताओं को छिपाने के बजाय, इसने स्पष्ट रूप से कहना शुरू कर दिया, "हम अभी इस विशिष्ट प्रकार की समस्या को हल नहीं कर सकते।" सिस्टम ने यह ईमानदारी प्रोग्राम नहीं की थी; यह इसलिए उभरी क्योंकि "रियलिटी चेक" ने झूठ बोलना बहुत कठिन बना दिया था।
- स्व-संगठन (Self-Organization): समय के साथ, AI ने अपने कोड को अधिक स्वच्छ और तार्किक संरचनाओं में व्यवस्थित करना शुरू कर दिया, भले ही उसे इसके लिए स्पष्ट रूप से नहीं कहा गया था।
बड़ी तस्वीर (The Big Picture)
यह शोध पत्र तर्क देता है कि रिसर्च सॉफ्टवेयर बनाना किसी दस्तावेज़ में टाइपो (typo) ठीक करने से अलग है। यह एक सह-विकास (co-evolution) प्रक्रिया है। सिद्धांत, कोड, परीक्षण, और कहानी को एक साथ बढ़ना चाहिए।
यदि आप केवल AI को "एक पेपर और कोड लिखें" कहते हैं, तो वह संभवतः भटक जाएगा, भ्रमित (hallucinate) होगा और तालमेल खो देगा। लेकिन यदि आप उसे एक कंडक्टर देते हैं जो लगातार स्कोर की जाँच करता है, वास्तविकता की जाँच के लिए मजबूर करता है, और सुनिश्चित करता है कि कदम जुड़े रहें, तो आप जटिल, भरोसेमंद रिसर्च टूल्स बना सकते हैं जो वास्तव में काम करते हैं।
संक्षेप में: Comet-H एक ऐसा सिस्टम है जो AI को ख्याली पुलाव पकाने से रोकता है और उसे अपने वादे निभाने के लिए मजबूर करता है, यह सुनिश्चित करता है कि वह कहानी जो वह सुना रहा है, उसके कोड से मेल खाती है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।