[논문리뷰] How to Understand Whole Software Repository?

0. Abstract

• LLM 기반 에이전트로 -> 자동 소프트웨어 공학(ASE)의 발전함
  • 기존 방법 : 코드의 지역 정보(예: 이슈, 클래스, 함수)에 초점을 맞춤
  • 시스템 내의 전역 컨텍스트와 상호 의존성을 포착하는 데 한계가 있다. 전체 리포지토리에 대한 이해가 ASE의 중요할 것이라 생각
  • 그러나 전체 리포지토리를 이해하는 것은 아래와 같은 어려움이 있다.
    • 극도로 긴 코드 입력
    • 노이즈가 많은 코드 정보
    • 복잡한 의존 관계
• 에이전트가 전체 리포지토리를 포괄적으로 이해하도록 안내하는 RepoUnderstander라는 새로운 ASE 방법을 개발
  • 리포지토리의 복잡성을 줄이기 위하여 아래와 같은 방법을 사용:
    • 탑다운 방식으로 전체 리포지토리의 중요 정보를 리포지토리 지식 그래프로 압축
    • 몬테카를로 트리 검색 기반 리포지토리 탐색 전략을 제안하여, 에이전트에게 전체 리포지토리를 이해하는 능력을 부여
    • 레포지토리 지식을 더 잘 사용하도록, 에이전트가 요약, 분석 및 계획을 수행하도록 안내

1. Introduction

• ASE - 소프트웨어 공학(SE) 작업을 자동으로 수행하는 것을 목표
  • 과거 연구 
  • Devin : 복잡한 실제 SE 작업(즉, 실제 Github 이슈 해결)을 위한 엔드-투-엔드 LLM 기반 에이전트 시스템 연구
    • 사용자 요구사항을 계획하고, 편집기, 터미널, 검색 엔진 도구를 활용하여 독립적인 의사결정과 추론을 수행하며, 최종적으로 요구사항을 충족하는 코드 패치를 생성
  •  SWE-agent : SE 에이전트가 코드 파일 생성 및 편집하고, 리포지토리를 탐색하며, 프로그램을 실행할 수 있도록 하는 Agent Computer Interface(ACI)를 전략적으로 설계.
  • AutoCodeRover : 프로그램의 추상 구문 트리를 추출, 요구사항에 따라 유용한 정보를 반복적으로 검색하며, 프로그램 패치를 생성
•  허나, 지역 정보에 초점을 맞추어, 함수와 클래스 간의 전역 컨텍스트와 복잡한 상호 의존성을 파악하는 데 실패
  • SWE-agent : 에이전트가 위아래로 스크롤할 수 있는 코드 파일 내의 컨텍스트 창을 유지
  • AutoCodeRover : 전체 리포지토리 내에서 함수나 클래스를 검색, 일반적으로 특정 기능에 대한 전체 로직은 여러 폴더와 파일에 걸쳐 논리적으로 분산되어 있다. 특히 사용자 요구사항만으로 수천 개의 파일 중에서 모든 관련 코드 파일을 검색하는 것은 어렵다.
• 전체 리포지토리의 방대한 정보를 활용하는 것은 아래와 같은 어려움이 있음.
  • 첫째, GitHub 리포지토리는 수천 개의 코드 파일을 포함할 수 있어 이들을 모두 LLM의 컨텍스트 창에 포함시키는 것은 어렵다
  • 둘째, 사용자 요구사항이 자연어로 설명되기 때문에, 리포지토리 내에서 관련 코드를 식별하는 것은 어렵다.
  • 셋째, 코드 실행의 고유한 로직은 파일 내 코드 텍스트의 순서와 뚜렷하게 다르다. 예) 에러가 발생한 위치와, 실제 고쳐야하는 위치가 다를 수 있으나, 관계적으로는 연관이 있음.

이 문제를 해결하기 위해...

• RepoUnderstander제안 : 전체 리포지토리를 포괄적으로 이해하고 학습된 리포지토리 지식 활용
  • 1. 레포지토리 수준의 정보를 TopDown 방식으로 리포지토리 지식 그래프를 구성하여 압축 : 구체적으로, 리포지토리는 코드의 컨텍스트와 범위를 명확히 이해할 수 있는 계층적 트리로 구성
  • 2. 몬테카를로 트리 검색(MCTS) 기반 리포지토리 탐색 전략 : LLM 기반 에이전트에게 리포지토리 수준 지식을 수집하고 학습하는 능력을 부여.
    • ㄱ) 탐색-활용(Explore-and-Exploit)를 통해 리포지토리 지식 그래프에서 SE 작업과 관련된 중요 정보를 수집
    • ㄴ) 여러 궤적을 시뮬레이션하고 그 보상 점수를 평가하여 검색 공간을 좁히고 에이전트가 가장 관련성 높은 영역에 집중하도록함.
    • ㄷ) 에이전트가 요약, 분석, 계획을 수행하도록 안내 - SE 목표와 관련된 리포지토리 수준의 지식을 효과적이고 효율적으로 수집하고 학습, 정확한 결함 위치 파악과 정보에 기반한 패치 생성을 용이
    • ㄹ) 마지막으로, 에이전트는 API 도구를 조작하여 동적으로 local 정보를 획득하고, 패치를 생성하여 실제 이슈를 해결하도록 함.

2. Related Work

2.1 LLM-based Software Engineering Agents

Introduction과 중복되어 생략

2.2 Evaluation of LLM-based Software Engineering Agents

• 과거 :
  • 간단한 문제 설명, 해결책, 그리고 해당 단위 테스트 데이터로 구성. 그러나 LLM의 성능으로 인해 더 이상 실제 SE 작업에서의 능력을 종합적으로 평가할 수 없게 되었다. 이를 위해, 리포지토리 수준의 코드 완성 및 생성 평가하기 위해 제시되었습니다.
• NEW - SWE-bench : 12개 리포지토리의 실제 GitHub 이슈를 수집
  • 단위 테스트의 자동 실행을 기반(과거와 동일)
  • 허나, 테스트 세트는, 리포지토리 탐색, 결함 위치 찾기, 디버깅, 코드 생성, 프로그램 수리 등 여러 능력을 갖추어야 함. 또한, SWE-bench Lite는 SWE-bench의 부분집합으로, 원본 버전과 유사한 다양성과 리포지토리 분포를 가짐.

2.3 Repository-level Code Intelligence

• StarCoder2와 Deepseek-Coder는 사전 학습 단계에서 리포지토리 지식을 모델링하고, 참조 의존성에 따라 리포지토리 파일을 정렬하며, 모델이 리포지토리 정보의 전역 의존성을 학습하도록 한다.
• RepoCoder는 RAG를 반복하여 관련 콘텐츠를 지속적으로 검색
• CoCoMIC와 RepoFuse와 같은 방법들은 (RAG 모듈, 현재 파일의 의존성 관계 모듈) jointly 사용하여 LLM의 컨텍스트로 사용
• 위의 방법들이 모델의 리포지토리 컨텍스트 이해를 어느 정도 향상시키나, 리포지토리 수준의 코드는 복잡한 맥락적 관계를 포함하고 있어 RAG 방법만으로는 의미적으로 관련된 모든 내용을 포함하지 못할 수 있다. 또한, RAG 결과에 대량의 무관한 정보가 포함될 수 있어 정확한 결함 위치 파악에 어려움이 있을 수 있음.

3. Methodology

3.1 Overview

• RepoUnderstander는 세 가지 주요 단계를 포함: 
  • 레포지토리 지식 그래프 구성 : 
    • 전체 레포지토리를 표현하는 그래프 구축 : 엔티티 간의 관계 설명
      -> 소프트웨어 구조를 이해하고, 탑다운으로 파싱.
    • 계측정 트리로 구성 : 코드의 컨텍스트와 범위를 명확하게 이해할 수 있게 함.
  • MCTS 강화 레포지토리 이해 : 
    • 몬테카를로 트리 검색 알고리즘 사용하여 전체 그래프를 동적으로 탐색
      -> 이슈 해결에 중요한 영향을 미치는 핵심정보(레포지토리 기능, 구조)를 발견하는데 초점을 맞춘다.
    • 핵심 정보 발견에 초점을 둠.
      -> 여러 궤적을 시뮬레이션 및 중요성을 평가
  •  정보 활용 및 패치 생성 :
    • 전역적 사전 지식 형성 : 레포지토리 이해 단계에서 수집된 정보를 요약하여, 전체 레포지토리에 대한 정보 형성.
    • AutoCodeRover의 API도구를 사용하여, 동적 정보 추출
    • 전역적 경험을 바탕으로 결함 위치 파악 및 패치 생성.

3.2 Repository Knowledge Graph Construction

• 인간의 경우 : 
  • 프로젝트의 소프트웨어 리포지토리를 검토 및 이해함
    -> 소프트웨어 리포지토리의 계층적 트리 구조 및 호출 그래프 구축하는 것이 포함됨.
  • 계층적 트리 구조를 통해 개발자는 프로젝트의 전체 아키텍처와 각 모듈 간의 관계를 살핌.
  • 호출 그래프를 통해 개발자는 함수 간의 호출 관계와 의존성 경로를 이해하여 문제의 근본 원인을 식별함.
• 이 연구에서도 사람과 비슷하게 형성 : 
  -> 리포지토리 지식 그래프로 표현, 소프트웨어 구조를 파싱하여 엔티티 간의 관계를 설명한다(그림 1의 Repo. Knowledge Graph Construction 참조).
  • 리포지토리를 계층적 구조 트리 변환 : 리포지토리의 구조를 하향식으로 분석하여 리포지토리를 계층적 구조 트리(파일, 클래스, 함수 포함)로 코드의 컨텍스트와 범위를 명확히 이해.
  • 참조 그래프로 확장 : 트리 구조를 함수 호출 관계를 포함하는 참조 그래프로 확장하여 모델이 포괄적인 의존성 및 상호작용 분석을 수행할 수 있게 한다.(예 : 함수A가 함수B를 호출하면, 두 함수 사이에 연결(Edge)를 만든다.)
    -> 참조 관계에서는 함수만 포함한다.
    -> 함수가 프로그램 실행의 기본 단위이며 함수 간의 호출 관계가 프로그램의 동작과 실행 로직에 직접적인 영향을 미치기 때문
    -> 과도한 참조 관계는 그래프 구조의 복잡성을 증가시키고 모델의 분석 효율성과 정확성에 영향을 줄 수 있다. 
• 구체적으로,
  • 리포지토리의 각 코드 파일을 재귀적으로 순회
    -> 모든 디렉토리와 하위 디렉토리를 탐색하여 각 코드 파일을 찾는다.
  • 해당 파일들을 각각 파싱하여 클래스와 함수 등의 기본 단위를 얻는다
    • 여기에는 (이름 / 코드 스니펫 / 경로 / 파일 내 위치 등이 포함)
  • 탑다운 구조 트리에 추가
    
  • 마지막으로, 함수 간의 호출 관계를 분석하고 그래프에 해당하는 방향성 있는 엣지 추가

3.3 MCTS-Enhanced Repository Understanding

• 현대 소프트웨어 시스템의 복잡성과 규모는, 종종 수백 개의 파일과 수천 개의 함수를 포함
  검색 공간의 방대한 규모로 인해 철저한 분석은 비현실적. 따라서 그래프에서 높은 관련성을 가진 노드와 엣지를 식별하는 방법이 필요
• 몬테카를로 트리 검색(MCTS)을 활용 : LLM과 에이전트의 소프트웨어 리포지토리 이해를 향상시키는 리포지토리 탐색 접근법을 제안(그림 1의 MCTS-Enhanced Repo. Understanding 참조).
  • 여러 궤적을 시뮬레이션하고, 중요성을 평가함으로써, MCTS는 동적으로 검색 공간을 좁히고 가장 관련성 높은 영역에 계산 자원을 집중시킨다.
  • 목표 지향적 탐색을 통해 -> 모델은 중요한 정보에 더 효율적으로 접근, 정확한 결함 위치 파악과 정보에 기반한 패치 생성을 용이하게 한다.
•  MCTS 과정은 리포지토리는 네 가지 반복 단계로 진행
  • Selection : aims to balance exploration and exploitation in node selection process
    • 주요 도전 과제 :
      -> 리포지토리 내 높은 관련성을 가진 콘텐츠의 심층 분석 // 리포지토리 전체에서 중요한 정보에 대한 검색 사이의 균형을 유지하는 것
    • 균형의 필요성 : 높은 상관관계를 가진 모듈을 과도하게 탐구하면 모델이 Local Minimal에 갇힐 수 있으며, 다른 중요한 경로나 의존성이 존재할 수 있다는 점을 무시할 수 있다. 광범위한 검색은 컴퓨팅 리소스의 분산을 초래하고 많은 양의 무관한 정보를 처리하게 되어 모델에 부담을 주고 검색 효율성을 낮출 수 있다.
      • 노드 선택에 UCT 알고리즘을 사용 : 𝑈𝐶𝑇 = 𝑤𝑖/𝑛𝑖 + 𝑐√(2 ln 𝑛𝑝/𝑛𝑖)
        • 𝑤𝑖 : 자식 노드 𝑖의 총 보상(구체적인 보상 계산은 시뮬레이션 & 평가 섹션에서 자세히 소개.)
        • 𝑛𝑖 : 자식 노드 𝑖의 방문 횟수이고 𝑛𝑝는 부모 노드의 방문 횟수
        • 𝑐 : 탐색과 활용 사이의 균형을 조정하는 데 사용되는 탐색 매개변수. 이 작업에서는 𝑐를 √2/2로 설정함.
  • Correlation Expansion : 확장 과정에서 리프 노드는 상관성이 높은 새로운 노드에 bias되게 확장
    
    • 확장의 목적 : 탐색 트리를 더 넓고 깊게 만들어, 더 많은 가능성을 탐색
    • 자식 노드 선택 : 레포지토리 지식 그래프에서 가장 관련성이 높은 자식 노드를 선택
      상관관계 확장, 참조관계 확장에 대해 설계
      • 상관관계 확장
        
        • 일반적으로 사용자 요구사항에는 (새로운 기능을 추가, 수정)하는 부분이 들어갈 가능성이 높다.
          따라서, BM25 점수를 사용하여 관련성을 계산하고, 관련성이 더 높은 코드를 우선적으로 확장한다.
      • 참조관계 확장 : backpropagation에서 설명
  • Simulation & Evaluation(Figure1,2을 보면서 읽어야 이해 쉬움) 
    Expansion 완료 후 시뮬레이션 과정에 들어감.
    • Simulation
      • 시작 : Correlation Expansion에서 새로 확장된 노드에서 시작
      • 경로 탐색 : 시작 노드에서 시작해 가능한 여러 경로를 따라 시뮬레이션을 수행
      • 노드 선택 방법 : Correlation Expansion과 동일한 방식을 사용(Greedy)
      • 보상 : 리프 노드에 도착하면 해당 경로의 모든 노드에 보상을 부여
    • Evaluation 
      • 과거 평가의 한계 :
        • 평가 단계에서는 선택된 리프 노드와 이슈 간의 관련성을 평가해야 한다. 그러나 전통적인 평가 방법은 일반적으로 키워드 매칭과 의미 매칭 알고리즘에 의존하는데, 이는 복잡한 소프트웨어 시스템과 다양한 문제 설명을 다룰 때 성능이 좋지 않음
      • 새로운 보상 함수 설계 : In Context Learning, Chain of Thought 활용
        • 보상함수의 목적 : 리프노드와, 사용자 query 사이의 관련성을 평가하기 위함. 
        • 1) In Context Learning : 
          • 학습 : LM으로 하여금 주어진 context하에, 보상함수의 핵심 기능과 작동을 이해하도록 학습
            -> 예시 프롬프트 제공(figure2)
          • 결과 : 코드와 문제 간의 관련성을 평가하는 방법을 학습
        •  2) Chain of Thought
          • 상관관계 평가 : 모델이 질문과 코드 일부분으로 상관관계 평가
          • CoT를 사용하여 단계별 추론 수행
          • 최종적으로 관련성에 대한 점수를 출력
            -> 숫자로 점수가 출력되는데 어떠한 로직으로 출력이 되는것인지..?
        • 보상 점수가 6이상인 노드만 유지된다.

• Figure 2 해당 논문에서 사용한 보상 프롬프트 : 
• 보상 기능의 목표와, 책임을 명확하게 제시하는 프롬프트로 시작
• <문제 설명, 코드 조각, 사고 과정, 결과> 의 일련의 예시 조합을 통해 채점 < 입력, 출력, 추론 체인>을 보여준다.

Backpropagation & Reference Expansion

• Bottom-up : 평가 후 바텀업 업데이트 진행.
  -> 방문횟수 n과 보상 값 w를 업데이트 함.
• 참조 확장 진행 : 바텀업을 진행하며 높은 스코어를 갖는 노드(6점 이상)에 대해서 참조 하고 있는 모듈과 레포지토리에 대해서 참고한다. 
  -> 이렇게 찾은 노드들을 새로운 노드로 추가한다.
  -> 노드의 보상 점수가 높으면, 해당 노드가 호출하는 다른 노드들과 관련있을 가능성이 매우 높다
  -> 이 경우에는 노드의 보상점수에 대한 신뢰성이 있어야하겠는데..

 

 

 

 

 

 

 

 

 

 

 

 

 

3.4 Information Utilization & Patch Generation(Figure 3)

• 레포지토리 요약 -> 필요한 코드 획득 -> 패치 생성
• Repository Summary :
  요약 에이전트 도입 : 레포지토리 이해 단계에서 얻은 정보를 더 효과적으로 활용하기 위해
  • 요약 에이전트 : 지식 그래프에서 수집된 코드 & 유저 Query를 (분석, 요약, 해결 방법 계획) 하여 전체 레포지토리에 대한 이해를 하는 것을 목표로함.
    • Input : 이슈, 관련 코드들 -> Output : 요약들을 출력, 해결책을 계획(Figure3의 노란색 부분)
    • 정보 정리 : 전역 레포에서 수집한 정보들은 (복잡, 양이 많음)
      -> 관련 코드 조각의 위치(structural dependencies in the repository)
      -> 요약 에이전트의 출력(요약, 계획)
      위 두가지를 사용하여 후속 작업을 안내한다. 
      함수 구현을 하는것은 아니며, 전체 레포에 대한 정보 전달에 집중한다.
      -> 너무 많은 raw정보가 들어가면 할루시네이션이 발생할까 하여 정리를 중간에 하는 것으로 추측
  • Dynamic Information Acquisition : 
    • ReAct(Reson then Act) : Chain of Thought를 통해 추론 경로를 생성 -> 실제 액션을 출력
      • 예) 이슈 제기 : 로그인 기능에서 비밀번호 재설정이 작동하지 않음.
        -> 추론 : 로그인 기능과 비밀번호 재설정 관련 코드를 확인해야함. 먼저 로그인 관련 클래스를 살펴봐
        -> 행동 : 모델 search_class(Login)을 호출
        -> 결과 : 시스템이 LoginManager 클래스 발견하였음
        -> 추론 : LoginManager 클래스에서 비밀번호 재설정 관련 메소드를 찾아봐야합니다.
        -> 행동 : 모델 Search_method(reset_password, LoginManager)를 호출
        -> 결과 : 시스템이 reset_password 메소드를 발견하였습니다.
        ...
    • Tools: AutoCodeRover의 API메서드를 사용
      • Search class
      • Search_method
      • Searhc_code
    • 호출해야하는 API를 독립적으로 결정 -> 클래스, 메서드 및 코드 스니펫 검색 -> 에이전트에 전달
  • Patch Generation : 
    • Locates : 전역 정보 요약, 동적 정보를 기반으로 결함을 탐지
    • 추출 : 수정이 필요할 수 있는 코드 스니펫의 컨텍스트를 추출
    • 생성 : diff로 생성전과 생성후 비교 결과물 반환
    • if 오류 : 문법적 오류 발생시, 올바른 문법의 코드가 생성될 때까지 재시도함.

4. Experiment

4.1 Experimental Setup

• Dataset : SWE bench Lite
• Baselines : 
  • RAG기반 : Can Language Models Resolve Real-world Github Issues?
  • 에이전트 기반 : AutoCodeRover, SWE agent
• Metrics : SWE-bench기준을 적용
• Configuration :
  • 모델 : GPT4-Turbo
  • 패키지 : ast, Jedi(Repository 파악 용)
  • 몬테카를로 횟수 : 
    • search iteration : 600회
    • search seconds : 300초
    • 요약 코드 스니펫 수 : 10개(정보 활용 및 패치 생성 단계)
    • 환경설정 : AutoCodeRover가 개발한 오픈소스 도커를 활용

4.2 Comparison Experiment

• 모델에 제공한 정보 : 자연어 설명, 로컬 코드 레포지토리
• 요청 : 문제 해결하고, 테스트를 통과할 수 있는 패치를 생성하도록 함.
• 결과 :
  • RAG시스템과 비교하면 5배 향상 / SWE-agent비교해서 정확도를 18.5%개선함.
  • Apply 적용 비율 : Agent 기반 시스템들은 모두 높은 Apply를 달성한 반면, RAG는 낮음.
  • 실행 피드백 기능 : SWE-agent가 높은 Apply 적용 비율을 보인 것은 실행 피드백 기능을 도입했기 때문
    -> 실행 피드백이 중요함을 의미함
  • 앞으로... : 
    이 연구에서는 레포지토리 이해에 초점을 맞추어, 실행 피드백을 적용하지 않았으나, 적용할 예정임.
    본 연구는, SWE-agent방법과 상호 보완적이며, 두 방법을 함께 사용할 시 26.67%의 해결률을 달성함.

4.3 Dataset Analysis & Fix

SWE-bench데이터셋을 분석하며, feature request type의 정보 비대칭성을 발견함.

• 예를들어) 테스트 패치(데이터)에는 새로운 기능(feature)의 정보가 있으나, LLM에 입력되는 정보에는 이러한 정보가 없음.
  -> 이로인해, 에이전트 모델이 전체 맥락을 정확히 이해하지 못하는 경우가 발생함.
  -> 생성된 패치가 올바르더라도 테스트 과정에서 오류가 발생할 수 있음.
• Fix 버전 제안함 : 300개 중에서 45개 수정

4.4 Ablation Study

• Module Analysis : RepoUnderstander에서 각 모듈들이 어떠한 영향을 끼치는지 분석하기 위한 부분이다.
  • MCTS & 요약 모듈 제거 : Agent는 저장소 구조 및 기능에 대한 사전 지식이 없음.
  • 요약 모듈만 제거 : MCTS를 통해 얻은 저장소 정보(종속성)정보를 전역 정보로 사용하고, 정보의 요약 및 계획을 제거
    -> 요약 에이전트의 효과 검증을 목표로함
  • 리뷰 에이전트 추가 : RepoUnderstander가 적용 가능한 패치를 생성하고, 코드 리뷰 과정을 시뮬레이션하기 위해 리뷰에이젖트에 의한 패치의 정적인 리뷰를 추가한다.
    -> 새로 생성된 코드의 잠재적 결함을 발견하기 위함 (최대 3회 반복)
  • 결과 : 전역 정보의 중요성 및 요약 에이전트의 중요성 입증

• MCTS & 요약을 제거하면 64 -> 48개로 성능이 낮아짐
  -> 이슈를 자동으로 해결하는데 있어 전역 정보가 중요함을 강조함.
• 리뷰에이전트 추가후 : 성능 하락
  -> 정적인 리뷰의 한계를 시사한다. LLM기반 정적 리뷰가 코드의 표면적인 문법 정보만 의존해서는 코드의 의미를 완전히 이해하지 못할 수 있음.
  -> 프로그램 계측[14,16], 동적 프로그램 분석[7,41,46]을 결합한 방법을 후속 연구로 생각함

 

• Hyper Parameter Analysis : MCTS의 반복횟수가 미치는 영향

1) 반복 횟수가 증가함에 따라 해결하는 수가 증가함.
-> 반복 횟수가 증가할수록 더 많은 저장소 정보를 수집, 경험이 풍부해짐.

 

2) 반복 횟수가 증가함에 따라, 개선율이 감소함.

-> 학습하는 기울기가 작아짐.

 

3) 적용률 감소 : 200 -> 600으로 변할 때, Apply의 적용율이 감소함. 반복 횟수가 증가함에 따라 필요없는 정보들까지 보는 것으로 추정

 

 

4.5 Case Study

• 실패 원인 분석 : 
  • 잘못된 위치 : 에이전트가 문제의 근본 원인을 찾지 못하고, 올바른 코드를 잘못 수정함.
    • SWE-agent : 62% 잘못된 위치 찾음
    • Ours : 45%
  • 패치 적용 실패 : 에이전트가 버전에 맞는 올바른 패치를 생성하지 못함.
  • 잘못된 패치 : 버그 위치와, 패치 구문은 올바르지만, 수정된 코드가 문제를 완전히 해결하지 못하여 테스트 케이스를 모두 통과하지 못함.
    • SWE-agent : 5% 패치를 생성하지 못함.
    • Ours : 13.7% 패치를 생성하지 못함.
  •  결론 : RepoUnderstand가 버그 위치를 더 정확하게 찾으나, 올바른 패치를 생성하고, 적용 가능성을 보장하는데 약점이 있음을 보여줌.
    -> 이는 SWE-agent는 실행 피드백을 모델에 반복적으로 검증 및 생성하게 하기 때문임.(시뮬레이션)
    -> 이는 실행 피드백의 중요성을 보여줌.
• 성공 원인 분석 : 

• Ours(그림 6)
  • MCTS 저장소 탐색 단계에서 수정이 필요한 was_modified_since를 찾음
  • 요약 단계에서 이 함수를 업데이트해야 한다고 명확히 지적함
  • 마지막으로, 위 정보들을 바탕으로 -> 패치 생성 단계에서 was_modified_since 함수를 정확히 검색하고 위치를 파악하여 구현함
• SWE-agent(그림 6) 
  • 파일 검색 : 컴퓨터 인터페이스 작업을 통해 파일을 검색, 고정된 창 크기 내에서 파일 내용을 파악
  • 파일 잘못 찾음 : 지역 검색에서 get_conditional_response 함수를 잘못 찾음.
    이 함수는 이슈 해결과 어느 정도 관련이 있지만 직접적인 연관성은 없다.
    따라서 잘못된 위치를 수정한 결과 작업을 해결하지 못함.
• Ours and SWE-agent(그림 7)
  • RepoUnderstander와 SWE-agent 모두 수정이 필요한 위치를 정확히 찾음.
  • SWE-agent : 실행 피드백과 반복 작업으로, 올바른 패치를 생성할 수 있음.
    • 이는 실제 문제 해결에 있어 실행 피드백의 중요성을 보여준다.

 

5.Limitation

MCTS과정은 상당한 자원 소비가 필요함.

6.Conclusion

생략

 

 

 

비슷한 논문

https://arxiv.org/pdf/2404.05966

And this one has github

https://github.com/cyzus/thoughtsculpt.git