What Context Does a Coding Agent Actually Need to Act?
यह शोध पत्र यह प्रदर्शित करता है कि कोड संपादित करने वाले कोडिंग एजेंटों के लिए, आवश्यक संदर्भ सख्ती से केवल संशोधित किए जा रहे विशिष्ट फ़ाइलों तक ही सीमित है, क्योंकि प्राकृतिक भाषा के सारांश और आस-पास की फ़ाइल सामग्री, स्रोत कोड की तुलना में समस्या समाधान में नगण्य योगदान देती है, जबकि यह गैर-नियत API अनुमान (non-deterministic API inference) के कारण बेंचमार्क परिणामों में एक महत्वपूर्ण शोर स्तर (noise floor) को भी प्रकट करता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने नहीं लिखा है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक विशाल, 100 मंजिला गगनचुंबी इमारत में एक टपकते हुए नल को ठीक करने की कोशिश कर रहे हैं। आपको रिंच (wrench) खोजने के लिए पूरी इमारत के ब्लूप्रिंट, कैफेटेरिया के मेनू या सुरक्षा लॉग को पढ़ने की आवश्यकता नहीं है। आपको बस यह जानने की जरूरत है कि कौन सा पाइप टपक रहा है और उसके आसपास का सटीक क्षेत्र देखना है।
यह "कोडिंग एजेंटों" (कोडिंग एजेंट)—यानी सॉफ्टवेयर लिखने और ठीक करने वाले AI बॉट्स—के बारे में इस नए अध्ययन से मिलने वाला एक आश्चर्यजनक सबक है। लंबे समय तक, तकनीकी जगत ने यह मान लिया था कि इन बॉट्स को अपना काम करने के लिए किसी प्रोजेक्ट के पूरे कोडबेस (कभी-कभी लाखों लाइनें) को अपने "दिमाग" में समाहित करने की आवश्यकता होती है। विचार यह था: "जितना अधिक संदर्भ (context) होगा, उतना ही बेहतर होगा।"
लेकिन यह पेपर कहता है: दिमाग को ठूसना बंद करें। यह पता चला है कि कोड को ठीक करने के वास्तविक कार्य के लिए, AI को उन विशिष्ट लाइनों के अलावा लगभग किसी भी चीज़ की आवश्यकता नहीं होती जिन्हें वह बदलने वाला है।
"खोजना" बनाम "कार्य करना"
शोधकर्ताओं ने समस्या को दो भागों में विभाजित किया:
- खोजना (The Find): टूटे हुए कोड का पता लगाना।
- कार्य करना (The Act): एक बार मिल जाने के बाद वास्तव में उसे ठीक करना।
इसका परीक्षण करने के लिए, उन्होंने एक "जादुई मानचित्र" (ओरेकल) का उपयोग किया जो AI को ठीक से बता देता था कि टूटा हुआ कोड कहाँ था। इसका मतलब था कि AI को यह अनुमान लगाने की आवश्यकता नहीं थी कि कहाँ देखना है; उसे बस इस बात पर ध्यान केंद्रित करना था कि इसे कैसे ठीक किया जाए। इसके बाद उन्होंने AI को उस कोड के विभिन्न "दृश्य" (views) दिए ताकि देखा जा सके कि क्या सबसे अच्छा काम करता है।
बड़ी निराशा: सारांश काम नहीं करते
एक लोकप्रिय विचार था: "चलिए AI को कोड का एक प्राकृतिक भाषा सारांश (natural language summary) दे देते हैं, जैसे किसी किताब का परिचय (blurb) होता है।"
- परीक्षण: उन्होंने AI से कोड के व्यवहार के बारे में कठिन प्रश्न पूछे, जिसमें या तो पूरा सोर्स कोड या एक बहुत ही स्मार्ट AI (एक "फ्रंटियर मॉडल") द्वारा लिखा गया सारांश दिया गया था।
- परिणाम: पूर्ण सोर्स कोड ने 45 में से 27 प्रश्न सही हल किए। सारांशों ने? वे केवल 45 में से 4 सही कर पाए।
- ट्विस्ट: इससे कोई फर्क नहीं पड़ता था कि सारांश दुनिया के सबसे स्मार्ट AI द्वारा लिखा गया था या एक छोटे, बुनियादी मॉडल द्वारा; दोनों समान रूप से विफल रहे। समस्या लेखक की नहीं थी; समस्या फॉर्मेट की थी। एक सारांश उस विशिष्ट "व्यवहार संबंधी" विवरणों को नहीं ले जा सकता जो बग को ठीक करने के लिए आवश्यक होते हैं। यह एक कार के इंजन को ठीक करने के लिए कार के बारे में एक ट्रैवल ब्रोशर पढ़ने जैसा है; ब्रोशर अच्छा है, लेकिन वह आपको यह नहीं बताता कि कौन सा बोल्ट ढीला है।
"कंकाल" बनाम "पूरा शरीर"
इसके बाद, उन्होंने परीक्षण किया कि क्या AI को पूरे, मांसल कोड की आवश्यकता है या केवल "कंकाल" (संरचना, जैसे फंक्शन के नाम और सिग्नेचर) की।
- सेटअप: उन्होंने 70 वास्तविक दुनिया की कोडिंग समस्याओं को लिया। कुछ के लिए, उन्होंने AI को पूरी फाइलें दीं। अन्य के लिए, उन्होंने इसे केवल "कंकाल" (UML डायग्राम और सिग्नेचर) या एक "keep/drop" संस्करण (केवल आवश्यक हिस्सों को रखना और बाकी को हटा देना) दिया।
- परिणाम: "कंकाल" और "keep/drop" संस्करणों ने भी उतनी ही समस्याओं को हल किया जितनी कि पूरी फाइलों ने। वास्तव में, "keep/drop" विधि ने पूरी फाइलों (19 में से 70) की तुलना में थोड़े अधिक (25 में से 70) समस्याओं को हल किया, हालांकि यह अंतर इतना कम था कि यह केवल किस्मत भी हो सकता है।
- लागत: यहाँ मुख्य बात है। एक समस्या को हल करने के लिए पूरी फाइलों ने AI के 94,000 टोकन (टेक्स्ट की एक इकाई) खर्च किए। केवल 19,000 टोकन वाले संकुचित "keep/drop" विधि के साथ इसे हल करने में लागत आई। यह एक विशाल बचत है—लगभग 3 से 3.7 गुना सस्ता—बिना प्रदर्शन में किसी कमी के।
"शोर" (Noise) की चेतावनी
शोधकर्ताओं ने एक अजीब लेकिन महत्वपूर्ण बात भी पाई: भले ही उन्होंने बिल्कुल एक ही सेटिंग्स के साथ वही परीक्षण चलाया हो, AI कभी-कभी अलग-अलग उत्तर देता था। लगभग 9% बार, परिणाम एक रन से दूसरे रन के बीच बदल गया। इसका मतलब है कि यदि आप दो विधियों के बीच एक छोटा सा अंतर देखते हैं (जैसे 2% का सुधार), तो यह केवल रैंडम शोर (noise) हो सकता है, न कि कोई वास्तविक सफलता।
निष्कर्ष
पेपर यह निष्कर्ष निकालता है कि कोड को ठीक करने के विशिष्ट कार्य के लिए, कम ही अधिक है।
- क्या काम करता है: AI को कोड की वे सटीक लाइनें देना जिन्हें उसे संपादित करने की आवश्यकता है, जिन्हें उनके आवश्यक तत्वों तक सीमित कर दिया गया हो।
- क्या काम नहीं करता: AI को कोड के सारांश, पूरी फाइल हिस्ट्री, या जटिल संरचनात्मक डायग्रामों से भर देना।
- फैसला: "सिग्नल" कोड के भीतर ही रहता है, उस कहानी में नहीं जो हम कोड के बारे में बताते हैं। अनावश्यक चीजों को हटाकर, हम लागत के एक अंश पर बग्स को ठीक कर सकते हैं, बिना एक टपकते नल को ठीक करने के लिए पूरी इमारत को पढ़े।
लेखक बहुत सावधानी से कहते हैं कि यह "सिंगल-शॉट" फिक्स (जहाँ AI एक बार प्रयास करता है और फिर से पढ़ने या मदद मांगने का मौका नहीं पाता) पर लागू होता है। लेकिन संपादन के उस विशिष्ट, उच्च-दांव वाले क्षण के लिए, डेटा स्पष्ट है: आपको पूरी लाइब्रेरी की आवश्यकता नहीं है; आपको बस सही पन्ने की आवश्यकता है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।