Composer को विकसित करने के हमारे तरीके का एक उल्लेखनीय पहलू यह है कि हम भविष्य के मॉडल्स की प्रशिक्षण प्रक्रिया को बेहतर बनाने के लिए मॉडल के पिछले संस्करणों का उपयोग करते हैं।

इस तरह से बूटस्ट्रैप करने का सबसे स्पष्ट उपयोग परिवेश सेटअप में दिखता है। RL प्रशिक्षण के लिए runnable परिवेश चाहिए होते हैं, और अगर शुरुआत में ही परिवेश खराब हो, तो मॉडल समस्याएँ हल करना सीखने के बजाय सेटअप डीबग करने में टोकन बर्बाद करता है। सबसे खराब स्थिति में, खराब परिवेश किसी समस्या को पूरी तरह अंसुलझा बना सकता है, जिससे बिना किसी रिवॉर्ड सिग्नल के compute व्यर्थ खर्च होता है।

इसे हल करने के लिए, हमने Composer autoinstall बनाया—एक ऐसी प्रणाली जो बिना कॉन्फ़िगर किए गए रिपॉज़िटरी checkout से काम करने वाले RL परिवेश स्वचालित रूप से तैयार करने के लिए पहले के Composer मॉडल्स का उपयोग करती है। मॉडल के सबसे हालिया संस्करण, Composer 2, के प्रशिक्षण के दौरान हमने इस प्रक्रिया को संभालने के लिए उसके पूर्ववर्ती Composer 1.5 का उपयोग किया। केवल चरण-दर-चरण निर्देशों का पालन करने से आगे बढ़कर, हमने पाया कि आधुनिक कोडिंग मॉडल्स सफलतापूर्वक कॉन्फ़िगर करने, प्रोजेक्ट निर्भरताओं को mock करने, और यह जाँचने के लिए कि सेटअप सही से काम कर रहा है, काफी हद तक प्रयास करते हैं।

#बेहतर परिवेश से बेहतर प्रशिक्षण संकेत मिलता है

हमारे मॉडल विकास के कई दूसरे पहलुओं की तरह, autoinstall भी प्रोडक्शन Cursor सिस्टम्स से प्रेरित है। Cursor क्लाउड एजेंट में, हमारे पास एक ऐसी सुविधा है जो उपयोगकर्ताओं के लिए क्लाउड परिवेशों का सेटअप अपने-आप करती है, ताकि उनके एजेंट्स mock परिवेश में प्रोजेक्ट्स पर काम कर सकें। git checkout से शुरू करके, एजेंट पैकेज इंस्टॉल करता है, सेटिंग्स कॉन्फ़िगर करता है, और यह सुनिश्चित करने के लिए बुनियादी जाँच चलाता है कि कोड चल रहा है और स्थिर है। इससे आगे के अनुरोध सही सेटअप से शुरू हो पाते हैं।

RL प्रशिक्षण के लिए, यह समस्या और भी ज़्यादा महत्वपूर्ण है, लेकिन चुनौतीपूर्ण भी हो सकती है। किसी रिपॉज़िटरी से शुरू करते हुए, autoinstall का लक्ष्य कोडबेस का एक runnable mock base संस्करण बनाना है, ताकि भविष्य में आने वाली किसी अनदेखी कोडिंग समस्या को हल किया जा सके। यह base परिवेश बहुत महत्वपूर्ण है, क्योंकि Composer को टूल्स के एक पूरे सेट के साथ प्रशिक्षित किया जाता है, जिसमें प्रोग्रामिंग भाषा के lint कमांड, खोज, और शेल का सैंडबॉक्स्ड उपयोग शामिल है। परिवेश को सही तरीके से सेट अप न कर पाने से प्रशिक्षण कम प्रभावी हो जाता है और बिना किसी रिवॉर्ड सिग्नल के compute व्यर्थ जा सकता है।

#एक एजेंट सफलता को परिभाषित करता है, अगला उसे हासिल करने की कोशिश करता है

Autoinstall दो चरणों में होता है। पहले “लक्ष्य निर्धारण” चरण में, हम Cursor एजेंट को एक fixed checkout पर कोडबेस देते हैं और उससे 10 कमांड तथा आउटपुट का एक उच्च-स्तरीय विवरण प्रस्तावित करने के लिए कहते हैं, जो परिवेश सही तरह से सेट अप होने पर चलना चाहिए।

एजेंट परिवेश से जुड़े किसी भी readme या makefiles को देखेगा, और साथ ही uv जैसे project managers या clippy जैसे linters जैसी सामान्य, भाषा-विशिष्ट कमांड भी आज़माएगा। एजेंट के काम में आम तौर पर setup कमांड, यदि उपलब्ध हों तो परीक्षण, और executables के लिए launch कमांड शामिल होंगे।

दूसरे चरण में, हम एक अलग Composer एजेंट को परिवेश की शुरुआती स्थिति के साथ-साथ प्रस्तावित 10 में से चुनी गई तीन लक्ष्य कमांड देते हैं। इसके बाद एजेंट कोडबेस को देखेगा और टूल कॉल्स का उपयोग करके परिवेश को इस तरह सेट अप करेगा कि वे कमांड चल सकें। बाद में, हम जाँच करते हैं कि तीनों कमांड चलें और आउटपुट पहले एजेंट के लक्ष्य विवरण से मेल खाए। अगर ऐसा नहीं होता, तो हम दूसरे चरण को फिर से शुरू करते हैं। अगर इस प्रक्रिया को पाँच बार दोहराने के बाद भी एजेंट परिवेश को संतोषजनक स्तर तक सेट अप नहीं कर पाता, तो हम उस परिवेश को छोड़ देते हैं।

Autoinstall के ज़रिए, Composer का लक्ष्य किसी परिवेश को यथासंभव पूरी तरह और सही ढंग से सेट अप करना है। इसे हासिल करने के लिए, यह गायब फ़ाइलों को mock कर सकता है, placeholder images बना सकता है, या यहाँ तक कि नकली database tables भी बना सकता है। कुछ projects में परीक्षण चलाने के लिए अतिरिक्त components इंस्टॉल करने पड़ते हैं, जैसे S3 फ़ोल्डर या गायब sidecar containers। Composer अक्सर इन्हें भी mock कर देता है, MinIO configs या Docker containers बनाकर ताकि ये काम कर सकें। लंबे समय तक चलने वाली प्रक्रियाओं के समर्थन के लिए, हमने Autoinstall को RL उपयोग की शुरुआत में इन्हें launch करने के लिए एक start script बनाने की अनुमति दी।

#वास्तविक प्रोजेक्ट्स के लिए Autoinstall

Autoinstall की प्रक्रिया को समझाने के लिए, हम अपने एक वास्तविक प्रयोग का उदाहरण लेते हैं, जिसमें हमने एक जटिल वास्तविक प्रोजेक्ट का सेटअप करने के लिए Autoinstall का उपयोग किया। यह प्रोजेक्ट, Celo, celo-org/celo-monorepo में इम्प्लीमेंट किया गया है। यह एक बड़ा blockchain प्रोजेक्ट है, जिसमें कई प्रमुख निर्भरताएँ हैं। यह प्रोजेक्ट Autoinstall के लिए एक दिलचस्प परीक्षण है, क्योंकि इसमें इंस्टॉल के लिए बड़ी संख्या में निर्भरताओं को मैनेज करना पड़ता है और फिर टेस्टिंग के लिए एक प्रमाणीकरण फ़्लो को mock करना पड़ता है।

Autoinstall के पहले चरण के दौरान, हमने देखा कि एजेंट इंस्टॉलेशन की मुख्य कमांड खोजने के लिए प्रोजेक्ट के दस्तावेज़ और कोड को खंगालता है। हालांकि, प्रोजेक्ट के साथ शामिल दस्तावेज़ अपेक्षाकृत कम थे, इसलिए उसने आगे के सेटअप कमांड खोजने के लिए प्रोजेक्ट की दस्तावेज़ीकरण साइट पर वेब कमांड का भी उपयोग किया। जिन कमांड की पहचान हुई, उनमें ज़्यादातर इंस्टॉलेशन या परीक्षण से जुड़ी थीं, लेकिन इसमें दस्तावेज़ों में दिया गया सॉफ़्टवेयर उपयोग करने वाला एक बुनियादी न्यूनतम एप्लिकेशन भी शामिल था।

दूसरे चरण में, एजेंट को इन कमांड को वास्तव में चलाने का कार्य दिया गया। हालांकि कार्यों का दायरा स्पष्ट था, मॉडल को पहले से यह नहीं पता था कि उसे किन समस्याओं का सामना करना पड़ेगा। इस विशेष मामले में, उसे पता चला कि Foundry जैसी कई अन्य निर्भरताएँ भी इंस्टॉल करनी होंगी, जो एक संबंधित रेपो है। इस आवश्यक प्रोजेक्ट के दस्तावेज़ पढ़ने के लिए उसने वेब खोज का उपयोग किया। उसे इस परिवेश में एक न्यूनतम एप्लिकेशन चलाने का कार्य भी दिया गया था। इस चरण के पहले iteration में, वह इस परीक्षण एप्लिकेशन को चलाने में असफल रहा, लेकिन दूसरे iteration में उसे पता चला कि वह एक mock उपयोगकर्ता बनाकर एप्लिकेशन को लोकल रूप से शुरू कर सकता है और आवश्यकता पूरी कर सकता है।

#अगली पीढ़ी के लिए आधार तैयार करना।

Autoinstall, पिछले मॉडल की मदद से RL प्रक्रिया को बूटस्ट्रैप करने का एक दिलचस्प उदाहरण है। खास तौर पर, Composer 2 अब Terminal-Bench पर काफ़ी अधिक स्कोर करता है (Composer 1.5 के 47.9% के मुकाबले 61.7%)। यह एक ऐसा बेंचमार्क है जिसमें डेवलपर परिवेश सेट अप करने की मॉडल की क्षमता के परीक्षण शामिल हैं। इससे संकेत मिलता है कि Composer 2, autoinstall के लिए बेहतर आधार प्रदान करेगा। हमें उम्मीद है कि भविष्य के रन में, पिछले Composer इंस्टेंस प्रशिक्षण प्रक्रिया के कई अन्य पहलुओं में भी बड़ी भूमिका निभाएँगे, जिसमें रन प्रबंधन, डेटा प्रीप्रोसेसिंग और आर्किटेक्चर ट्यूनिंग शामिल हैं।

Composer 2 के बारे में और जानें