Log in to leave a comment
No posts yet
Cursor या Devin जैसे टूल सुविधाजनक होते हैं। लेकिन अंदरूनी तौर पर वास्तव में क्या हो रहा है, यह जानना मुश्किल है, और कभी-कभी वे कोड को उन तरीकों से काट देते हैं जो आप नहीं चाहते। एक बैकएंड डेवलपर के रूप में, पायथन स्टैंडर्ड लाइब्रेरी और LLM API को मिलाकर अपना खुद का कस्टमाइज्ड एजेंट बनाना कहीं अधिक किफायती और विश्वसनीय है।
एजेंट को केवल कोड लिखने से आगे ले जाने और उसे सीधे टर्मिनल कमांड चलाने में सक्षम बनाने के लिए, आपको subprocess मॉड्यूल को कुशलता से संभालना होगा। बिना सोचे-समझे shell=True विकल्प का उपयोग करने से आप शेल इंजेक्शन हमलों के प्रति संवेदनशील हो सकते हैं, या ऐसी समस्याएँ पैदा हो सकती हैं जहाँ टाइमआउट के दौरान प्रोसेस खत्म नहीं होती और ज़ोंबी की तरह बनी रहती है।
इसे स्वयं लागू करते समय, subprocess.run() कॉल में shell=False सेट करें और कमांड को लिस्ट के रूप में पास करें। टाइमआउट को लगभग 30 सेकंड का छोटा रखें, और यदि TimeoutExpired अपवाद (exception) होता है, तो संसाधनों को पुनः प्राप्त करने के लिए तुरंत process.kill() कॉल करें। मॉडल को रनिंग रिजल्ट देते समय पूरी सामग्री भेजने की आवश्यकता नहीं है। यदि टेक्स्ट 1,000 वर्णों से अधिक है, तो अंतिम 20 लाइनों पर ध्यान केंद्रित करते हुए इसे काट दें। यह टोकन की बर्बादी को रोकते हुए मॉडल के लिए त्रुटि के कारण को समझने के लिए पर्याप्त जानकारी है।
जैसे-जैसे बातचीत लंबी होती जाती है, संदर्भ विंडो (context window) में जमा होने वाला डेटा लागत के बड़े बोझ में बदल जाता है। Anthropic की घोषणा के अनुसार, Claude 3.5 मॉडल में cache_control मार्कर का उपयोग करने से कैश किए गए डेटा को पढ़ने की लागत में 90% तक की बचत हो सकती है। यह प्रति 1 मिलियन टोकन पर लगभग $0.30 है।
लागत कम करने के लिए, सिस्टम संदेशों और उपयोगकर्ता इनपुट को सख्ती से अलग करें। ऐसी जानकारी जो नहीं बदलती है, जैसे पूरे प्रोजेक्ट का फाइल ट्री स्ट्रक्चर, उसे सिस्टम प्रॉम्प्ट के शीर्ष पर फिक्स करें और इसे कैश पॉइंट के रूप में सेट करें। जब बातचीत का इतिहास जमा हो जाता है और टोकन की सीमा पार होने लगती है, तो tiktoken के साथ मात्रा की गणना करें और फिर पुराने संदेशों को एक अलग LLM कॉल के साथ सारांशित करने की श्रेणीबद्ध सारांश (hierarchical summarization) पद्धति का उपयोग करना अच्छा होता है। इस सारांशित संदर्भ को शीर्ष पर बनाए रखने और नवीनतम संदेशों को जोड़ने वाली स्लाइडिंग विंडो लागू करने से, आप लंबे विकास सत्रों में भी लागत को 40% से अधिक कम कर सकते हैं और मॉडल की तर्क सटीकता (inference accuracy) को बनाए रख सकते हैं।
एजेंट से पूरी फाइल को फिर से आउटपुट करवाना एक अक्षम और धीमी प्रक्रिया है। आउटपुट टोकन जितने अधिक होंगे, मॉडल द्वारा बीच के कोड को छोड़ने या गलत जानकारी देने की संभावना उतनी ही अधिक होगी। तथाकथित "Edit Trick" पद्धति केवल उस टेक्स्ट (Anchor) को खोजने और बदलने का निर्देश देती है जिसे संशोधित करने की आवश्यकता है। यह तकनीक वास्तविक डेटा में आउटपुट टोकन की मात्रा को 86% तक कम करने में प्रभावी है।
पायथन के re.sub() का उपयोग करके स्थानीय फाइलों पर केवल विशिष्ट XML टैग या रेगुलर एक्सप्रेशन के माध्यम से भेजे गए संशोधनों को लागू करने के लिए एक फ़ंक्शन बनाएं। साथ ही, सभी तकनीकी दस्तावेजों को प्रॉम्प्ट में डालने के बजाय, LanceDB जैसे हल्के वेक्टर DB को जोड़ें ताकि केवल आवश्यक दस्तावेज़ स्निपेट्स ही लाए जा सकें। इस संरचना के साथ, फाइल संशोधन की गति 79% से अधिक तेज हो जाती है, और बड़ी फाइलों पर काम करते समय मॉडल के भ्रमित होने की पुरानी समस्या हल हो जाती है।
इंसानों को मॉडल में मैन्युअल रूप से डिबगिंग संदेशों को कॉपी और पेस्ट करने की मेहनत बंद कर देनी चाहिए। एजेंट को कोड लिखने से पहले pytest आधारित टेस्ट कोड लिखने के लिए प्रेरित करें।
यदि टेस्ट विफल हो जाता है, तो बस होने वाले पूर्ण Traceback को बिना किसी प्रोसेसिंग के मॉडल को वापस भेजें और एक फीडबैक लूप बनाएं ताकि वह खुद इसे ठीक कर सके। हालांकि, rm या deploy जैसे खतरनाक कमांड के लिए, पायथन के input() फ़ंक्शन का उपयोग करके उपयोगकर्ता की मंजूरी लेने वाले सुरक्षा गार्डरेल (guardrails) को शामिल करना अनिवार्य है। एक बार जब यह चक्र पूरा हो जाता है, तो डेवलपर को केवल एजेंट द्वारा सबमिट किए गए git diff सारांश की जांच करनी होती है और कमिट बटन दबाना होता है।
अंततः, एक एजेंट बनाने की कुंजी कोई फैंसी फ्रेमवर्क नहीं है, बल्कि यह है कि आप टर्मिनल और LLM के बीच डेटा को कितनी सटीकता से रिफाइन और कैश करते हैं। आपके द्वारा लिखा गया 600 लाइनों का पायथन कोड हजारों लाइनों के ब्लैक-बॉक्स टूल की तुलना में आपके इरादों को बेहतर ढंग से प्रतिबिंबित करेगा।