SWE-agent, GitHub इश्यू समाधान दर 12% वाला स्वचालित डेवलपमेंट एजेंट

 (github.com/princeton-nlp)
10 पॉइंट द्वारा GN⁺ 2024-04-04 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • SWE-agent, GPT-4 जैसे language models (LMs) को software engineering agents में बदलकर वास्तविक GitHub repositories के bugs और issues को ठीक करता है
  • पूरे SWE-bench test set में 12.29% issues को हल करके, पूरे test set पर सर्वश्रेष्ठ प्रदर्शन हासिल किया

एजेंट-कंप्यूटर इंटरफेस (ACI)

  • यह परिणाम LM-केंद्रित commands और feedback format डिज़ाइन करके हासिल किए गए, ताकि एजेंट के लिए repository को explore करना, code files को देखना, edit करना और run करना आसान हो सके.
  • इसे agent-computer interface (ACI) कहा जाता है, और repository-स्तर के coding agents के लिए ACI design को आसानी से iterate करने हेतु SWE-agent repository बनाई गई.
  • यह दिखाता है कि अच्छा ACI design, agents का उपयोग करते समय कहीं बेहतर परिणाम देता है.

सेटअप

  • Docker इंस्टॉल करें और लोकल में Docker शुरू करें.
  • Miniconda इंस्टॉल करें और conda env create -f environment.yml का उपयोग करके swe-agent environment बनाएं.
  • conda activate swe-agent का उपयोग करके इसे activate करें.
  • ./setup.sh चलाकर swe-agent Docker image बनाएं.
  • इस repository के root में keys.cfg फ़ाइल बनाएं और आवश्यक API keys तथा GitHub token दर्ज करें.

उपयोग

  • SWE-agent pipeline में दो चरण होते हैं. पहला inference चरण है, जो GitHub issue को input के रूप में लेकर उसे हल करने की कोशिश करने वाला pull request लौटाता है.
  • दूसरा चरण केवल SWE-bench benchmark के issues के लिए संभव है, और यह evaluation चरण है जो जांचता है कि बनाया गया pull request वास्तव में issue को हल करता है या नहीं.

मूल्यांकन

  • यह चरण केवल SWE-bench set के issues के लिए संभव है.
  • बनाए गए pull request का मूल्यांकन करने के लिए evaluation/ directory में जाएं और ./run_eval.sh चलाएं.

GN⁺ की राय

  • SWE-agent, वास्तविक GitHub issues को हल करने में language models का उपयोग करने वाला एक नवोन्मेषी दृष्टिकोण प्रस्तुत करता है, जिससे software development process में automation की संभावनाएं बढ़ती हैं.
  • इस तकनीक में यह क्षमता है कि डेवलपर्स बार-बार होने वाले bug-fixing कार्यों से मुक्त होकर अधिक रचनात्मक और जटिल समस्या-समाधान पर ध्यान केंद्रित कर सकें.
  • ACI design के महत्व पर ज़ोर देकर, यह मशीन और मनुष्य के बीच interaction को optimize करने वाली interface design की अहमियत को उजागर करता है.

संबंधित पढ़ाई

3 टिप्पणियां

 
botplaysdice 2024-04-05

ऐसे agent अगर डेवलपर से इस तरह सवाल पूछते हुए काम करें, तो यह सच में काफ़ी अच्छा लगेगा।

"मैंने bug report में बताए गए reproduction steps को समस्या को reproduce करने वाले test code में बदलकर देखा है। क्या आप यह code देखकर बता सकते हैं कि मैंने सही समझा है या नहीं?"

"इस design के बजाय अगर हम इस तरह refactoring करें, तो लगता है कि पूरे project में 20312 lines of code कम की जा सकती हैं, do you approve?"
 
fastkoder 2024-04-04

काफी आकर्षक open source है
 
GN⁺ 2024-04-04
Hacker News राय

  • bug report पर टिप्पणी:

    • डेमो में matrix operations के बारे में एक स्पष्ट bug report दिखाई गई है.
    • असली bug reports ज़्यादातर "X पर क्लिक किया तो Y हुआ" जैसी अस्पष्ट होती हैं.
    • bug को ठीक करने की असली कठिनाई उसके root cause का पता लगाने में होती है.
    • यह तो पता है कि LLMs साधारण defects को ठीक कर सकते हैं, लेकिन इससे वास्तव में क्या साबित होता है, इस पर सवाल उठाया गया.
    • किसी ने paper को विस्तार से देखा है या नहीं, और समस्याओं से इसका अंतर क्या है, यह जानने की जिज्ञासा व्यक्त की गई.

  • project पर टिप्पणी:

    • इसे बहुत शानदार project बताया गया.
    • पहले इसी तरह के प्रयोग किए गए थे, लेकिन वे अक्सर अव्यवस्थित और महंगी असफलताओं में बदल गए.
    • swe-bench पर 12% success rate दिखा, लेकिन बाकी 88% के बारे में सवाल पूछा गया.
    • यह जानने की जिज्ञासा जताई गई कि swe-bench क्या उसी group ने बनाया है, और क्या कभी "skilled human upper bound" score मापा गया है.
    • यह अनुभव साझा किया गया कि swe-bench के कुछ randomly चुने गए tasks skilled humans के लिए भी "solve" करना कठिन थे.

  • इस्तेमाल की गई methodology पर टिप्पणी:

    • ऐसा लगता है कि langchain methodology का इस्तेमाल किया गया.
    • कुछ prompts को उदाहरण के रूप में दिखाते हुए GitHub link दिया गया.

  • AI और bug tracker पर टिप्पणी:

    • अगर AI-जनित pull requests लोकप्रिय हो गए, तो public bug trackers के अंत की आशंका जताई गई.
    • bug गायब नहीं होंगे, बल्कि pull request review की लागत की तुलना में project को होने वाला लाभ बहुत बड़ा नुकसान बन सकता है, ऐसा मत व्यक्त किया गया.

  • SWEbench benchmark पर टिप्पणी:

    • SWEbench benchmark में केवल Python code projects शामिल हैं, इसलिए यह सभी programming languages और frameworks का प्रतिनिधित्व नहीं करता.
    • JS, SQL, Python आदि के लिए अधिक सामान्य SWE task evaluation framework विकसित किए जाने का परिचय दिया गया.

  • डेमो तुलना पर टिप्पणी:

    • राय दी गई कि डेमो Devin project से बहुत मिलता-जुलता है, इसलिए इसे जाकर देखा गया.
    • डेमो की विश्वसनीयता पर सवाल उठाते हुए, किसी third party का मूल्यांकन सुनने की इच्छा जताई गई.

  • review work पर टिप्पणी:

    • यह पूछा गया कि AI द्वारा सुझाए गए fixes की समीक्षा करने में वास्तविक लोगों पर कितना अतिरिक्त काम पड़ा.

  • समान project पर टिप्पणी:

    • बताया गया कि एक ऐसा ही project चल रहा है, और GitHub link दिया गया.
    • focus इस बात पर है कि model के गलत दिशा में चले जाने को कैसे संभाला जाए.
    • इस बात पर ज़ोर दिया गया कि developer-AI feedback loop को पूरा करना ही वास्तविक productivity gains की कुंजी है.

  • लेखकों के लिए सुझाव वाली टिप्पणी:

    • यह इंगित किया गया कि success rate केवल researchers के लिए ही अर्थपूर्ण है, और सुझाव दिया गया कि README में SWE-agent द्वारा pass किए गए tests और fail हुए tests के उदाहरण जोड़े जाएँ.

  • open source project contribution पर टिप्पणी:

    • एक beginner developer के रूप में open source projects में योगदान करने के तरीके खोजने में मदद करने वाला tool चाहा गया.
    • यह अनुभव साझा किया गया कि Python packaging documentation कठिन होने के बावजूद, उसे पार करके चीज़ों को आसान बनाना संभव हुआ.
    • ऐसे projects खोजकर उन्हें सुधारने के सुझाव देने और लागू करने की योजना बताई गई जो modernize नहीं हुए हैं.
    • ऐसे लोगों के साथ ideas साझा करने की इच्छा जताई गई जिनके पास मिलते-जुलते विचार या प्रेरणा हो.