DeepLearing/NLP(LLM)

[논문리뷰] SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering(작성중)

notdecidedyet 2024. 8. 3. 19:36

Appendix의 양이 어마어마해서 시간이 소요될 것으로 예상.

 

0. Abstract

  • 인터페이스 설계가 언어 모델 에이전트의 성능에 어떤 영향을 미치는지 조사
  • SWE-agent를 소개
    • 1. 정의 : LM 에이전트가 소프트웨어 엔지니어링 작업을 해결하기 위해 자율적으로 컴퓨터를 사용할 수 있게 하는 시스템
    • 2. SWE-agent의 맞춤형 에이전트-컴퓨터 인터페이스(ACI)는 에이전트가 코드를 생성, 편집, 전체 저장소를 탐색, 테스트 및 기타 프로그램을 실행하는 능력을 향상시킴.
  • ACI의 설계가 에이전트의 행동과 성능에 어떤 영향을 미칠 수 있는지에 대한 통찰을 제공

 

1. Introduction

  • Execution Feedback(Reflexion: Language Agents with Verbal Reinforcement Learning)을 통한 코드 생성은 성공적
  • 소프트웨어 엔지니어링과 같이 더 복잡한 작업에서의 수행 능력은 검증되지 않음.
    • 기존 : LM은 복잡한 작업을 하기 위해서 Linux shell, Python어플리케이션을 사용함
    • But : 사람은 더 복잡한 작업을 하기 위해 VSCode와 같은 도구 및 Extension들을 사용
    • 그렇다면 LM에게 도구와 같은 것들을 제공한다면???
      • 인간-컴퓨터 상호작용(HCI)에서 영감을 받아 ACI를 소개함.
        • ACI는 파일을 검색, 보고, 편집 할 수 있음. (일부분만 제공하는 것이, Linux shell의 광범위한 명령어를 제공하는 것보다 효과적임)
        • 매 턴마다 명령의 효과에 대한 구체적이고 간결한 피드백을 받음.
      • GPT-4 Turbo 사용, SWE-bench테스트 중 12.4%의 문제 해결
        • 과거 RAG를 통한 SOTA는 3.8%
  • 기여점
    • ACI 개념 소개
      • 이 프레임워크 안에서 (사용, 프롬프트 테크닉, 코드 실행, 등)을 복합적으로 사용
    • LM의 가중치 수정하지 않고도 성능 향상 달성

 

2. The Agent-Computer Interface(ACI)

  • ACI : LM Agent <-> 컴퓨터 상호작용으로 부른다.
  • HCI : 인간이 코딩 및 컴퓨터를 더 잘 사용하기 위해 IDE와 같은 것을 사용하는 것과 같이, Agent가 컴퓨터를 더 잘 사용하기 위해 ACI를 정의함.

  • LM에서는...
    • 단점 :
      • 시각적 정보에 취약
      • 제공된 정보를 무시할 수 없음 -> 사람은 찾은 자료중에서 일부분을 효과적으로 사용함.
    • 반면에... : Syntax checking, navigation tools과 같은 부분은 LM에 효과적일 수 있음.
    • 결론 : state of the application을 더 잘 이해할 수 있게
      • 불필요한 컨텍스트를 피하기 위해 이전 히스토리 관리, 액션 제공
      • LM이 사용할 수 있는 명령과 환경 상태가 제공되어야 한다.
  • 제안
    • 1) 에이전트 행동을 수동으로 검사하여, 어려움을 확인하고 개선 제안
    • 2) 최상의 ACI 구성을 선택하기 위해 그리드 검색
  • Insights
    • 액션은 간단해야 함  : 파인튜닝을 하지 않기 때문에, 액션이 간단해야함.
    • 액션은 압축적이고 효율적이여야 함 : (파일 탐색, 편집) 가능한 적은 수의 액션으로 통합되어야 한다. 잘못 설계된 작업은 문제를 풀기 위해 많은 턴이 필요함(5.1 인터페이스 분석에서 살펴봄)
    • 환경 피드백은 정보를 제공하면서도 간결해야 함 : 현 환경상태 및 최근 액션에 대한 정보를 제공해야함.(Figure3)
      • (Action했던 히스토리를 저장해서 LM에 제공하는 듯)
    • 가드레일 : LM도 실수를 함(편집, 검색 시) -> 실수를 자동으로 감지하는 코드 구문 검사기와 같은 가드레일 적용

 

3. SWE-agent : Designing an ACI for Software Engineering

LM이 소프트웨어 엔지니어링 에이전트로 작동할 수 있게, ACI를 제공하는 방법에 대해서 다룬다.

  • (검색/탐색, 파일 뷰어, 파일 편집기, 컨텍스트 관리 등) 여러 구성 요소 다룸
  • 각 단계에서 SWE-agent는 (생각, 명령) 생성 -> 환경에서 명령 실행의 피드백을 통합함

 

Search and Nevigation 

  • 코드 베이스 탐색 -> 관련 파일과 내용을 찾아야 한다.
    • 탐색 방법 : 이슈에서 언급된 (파일, 함수, 클래스 정의)를 찾기
    • find_file, search_file, search_dir라는 명령어를 도입 : 파일 이름 검색, 파일 내에서 혹은 디렉토리 내에서 문자열을 검색할 때 검색 결과의 요약을 출력
      • find_file : Repository에서 파일 이름 검색
      • search_file, search_dir : 파일 또는 하위 디렉토리의 파일에서 문자열을 찾는다.
    • 검색 명령어는 최대 50개의 결과를 반환, 검색 결과가 이를 초과하면, 에이전트에게 더 구체적인 쿼리 작성하도록 제안함.

 

File viewer(Figure 3a 위위 에 올렸음)

  • 보고싶은 파일을 찾은 후, open 명령어를 호출해 대화형 파일 뷰어를 사용
    • 파일 뷰어는 최대 100줄의 파일 내용을 보여주는 창
    • Scroll down, Scroll up 명령어로 창을 이동
    • goto 명령어로 틀정 줄에 접근 가능
  • 열린 파일의 (전체 경로, 파일의 총 줄 수, 현재 창 이전과 이후에 생략된 줄 수, 줄 앞에 붙은 줄 번호 표시) -> 그림 3a 참고

File editor

LM이 파일 생성 및 편집할 수 있는 몇가지 명령어를 제공

  • edit : 파일 뷰어와 연계하여 작동하고, 열린 파일의 특정 줄을 수정할 수 있다.
  • (시작, 끝, 대체 텍스트)가 인풋으로 주어져야 한다. 
  • 시작 줄과 끝 줄 사이의 모든 줄을 대체 텍스트로 교체할 수 있음. -> Figure 3b
  • 교체 후 : updated contents가 표시되고, 수정된 부분의 영향을 즉각적으로 관찰
    • edit에 linter를 넣음으로서 구문 오류등을 알려주며, 유효하지 않은 편집은 폐기하고, 에이전트에게 파일 편집을 다시 시도하는 요청을 한다.

Context Management

  • 사용하는 정보 : (정보를 제공하는 프롬프트/ 오류 메시지 / 히스토리 프로세서)
  • 제공받는 정보 : (Instruction / documentation and demonstration on correct use of bash and ACI commands)
  • 매 시점 : 생각과 액션을 생성하라 한다.
    • 만약 잘못된 정답을 생성하여 오류가 발생하면 -> 오류 응답을 트리거로 에이전트에게 다시 시도하도록 한다.
    • 만약 아무 답변도 생성되지 않을 경우 -> Your command ran successfully and did not produce any output
    • 컨텍스트 관련성을 더 개선하기 위해, 마지막 5개 이전의 관찰은 한줄로 요약된다.
    • 이전 관찰의 대부분 내용을 제거하여, 계획가 행동 히스토리에 대한 필수적인 정보 유지 및 불필요한 컨텍스트를 줄임
      -> A에서 세부사항 보여준다.(읽어볼것)

 

4. Experimental Setup

Dataset(SWE bench) : 12개 인기 있는 Python 패키지 / 2,294개 인스턴스

  • Test set : Full SWE-bench
  • Ablation & analysis : SWE-bench Light(300개 선별된 데이터셋) -> 버그 수정에 초점을 맞춘 데이터 셋

Models

  • Closed : GPT-4-Turbo / Claude 3 Opus
  • Open : Llama3 / DeepSeek Coder -> 성능이 안좋았다, Context Length가 너무 짧다.

Baseline

  • non-interactive RAG 방법(Jimenez) : BM25 검색 방법론을 사용
  • Shell Only : 대화형 코딩 프레임워크 - Linux의 셀 프로세스와 상호작용

Metrics

  • %Resolved  | pass@1 : 모델이 적용한 뒤 성공한 비율
  • &Avg. Cost : API 추론 비용 -> 인스턴스당 $4의 예산을 선정

Configuration Search

작은 데이터셋을 기반으로 정성적 분석을 통해 최종 ACI 설정함. 나머지 하이퍼파라미터( 윈도우 크기, 히스토리 처리, Temperature)는 B.1에 설명함.

 

5.Results

SWE-agent가 최고 성능 달성

  • SWE-bench : 12.47% (286/2294)
  • SWE-Light : 18% (54/300)
  • RAG와 비교하면 8-13배 비용 발생하나 6.7배 문제를 잘 해결함.
  • Shell only보다 ACI가 64%더 좋았음.

5.1 ACI 설계 분석

Human user interfaces are not always suitable as agent-computer interfaces.

  • 현재의 LM은 Linux 셸 환경에서 관련 콘텐츠를 검색할 때 여러 가지 함정에 취약하다
    • 일부 탐색 패턴(예: 연쇄적으로 cd, ls, cat)은 극도로 비효율적
    • grep이나 find 검색이 더 나은 성능을 보일 수 있지만 때때로 무관한 결과를 생성

Compact, efficient file editing is critial to performance

  • SWE-agent editor and viewer :
    • 편집 프로세스를 단일 명령으로 통합하여 일관된 피드백으로 여러 줄을 쉽게 편집할 수 있게함.
    • 일관적인 피드백 제공, 편집 후 에이전트의 파일 보기를 자동으로 업데이트하도록 설계
  • No edit setting :
    • 리디렉션과 덮어쓰기를 통해 전체 파일을 교체
    • sed 유틸리티 사용 : 단일 줄 또는 검색 및 교체 편집
    • 단점 : 
      • 리디렉션 : -> 비효율적, 사소한 변경에도 전체 파일을 복사하고 다시 작성하여 오류 발생하기 쉬움
      • sed :  특정 편집을 용이하나, 의도하지 않은 결과를 초래할 수 있음.
      • 두 전략 모두 파일 업데이트에 대한 즉각적인 피드백을 하지 않아, 모델이 혼란스러워 할 수 있음.
      • SWE-agent의 파일 편집기 인터페이스가 없으면 성능이 (10.3% ↓ 7.7)로 떨어짐
  • 줄 수에 민감함 : 에이전트가 파일 뷰어가 표시하는 줄 수에 민감하다는 것을 발견. 너무 적은 내용(30줄, 14.3% ↓ 3.7) 또는 너무 많은 내용(전체 파일, 12.7% ↓ 5.3)은 모두 성능을 저하시킴

Guardrails can improve error recovery(Figure 6 참고)

  • 두드러진 실패 예 : 모델이 반복적으로 같은 코드 스니팻을 edit 하는 것이 두드러진 실패이다.
    • 같은 코드 스니펫을 생성하는 이유 : 일반적으로 구문 오류이다.
      • 구문오류 : 들여쓰기, 추가 괄호 같은 것
  • 두드러진 실패를 하지 않은 경우에만 edit을 적용할 수 있도록 로직에 추가함.
  • 린팅 없이는 (15% ↓ 3)이다.

edit w/o Linting에서 synthax error를 스스로 발견하기에는 어려움.

 

5.2 Analysis of Agent Behavior

  • LM에 유용하고 직관적인 ACI를 제공할 때 반복적인 문제 해결 패턴이 나타난다.
  • 이 챕터에서는 여러 모델 행동과 문제 해결 패턴을 설명한다.

Reproduction and/or localization is the first step.

  • 에이전트는, Reproduction 코드를 작성, 이슈의 원인을 특정 코드 라인으로 지역화하는 것으로 시작함.
    • 그림 7, 모든 궤적은 create(재현) 또는 find_file/search_dir(지역화)로 시작
    • 재현을 위해 모델은 1.새 파일 생성 / 2.edit로 재현 코드를 추가 / 3.python으로 실행.
    • 피드백 및 이슈 설명에 있는 파일 이름과 심볼을 참고하여, 넓은 디렉토리 수준의 키워드 검색을 하고 점차 특정한 파일과 라인으로 좁혀간다 -> Figure22. Transition Probabiltities Heatmap을 통해 Agent의 행동을 사후 분석함.
      • 예 locaization sequences -> (python, find_file) and (search_dir, open) are search_file and goto, indicative of how an agent zoom in on a bug

Remaining turns are mostly “edit, then execute" loops.

  • 그림 7에서, 5턴째부터 모든 턴에서 가장 빈번한 액션은 edit, python이다.
  • 추가적인 localization을 위해 search_file / scroll_up, down / search_dir / find_file등과 같은 행동함.
  • 이러한 행동은 재현 스크립트를 다시 실행한 결과 새로운 정보에 대한 응답으로 발생

Editing remains challenging for agents.

  • 소수의 edit 액션이 린팅 오류를 발생시킴
  • 2,294개의 태스크 인스턴스 중 1,185개(51.7%)의 SWE-agent w/ GPT-4 Turbo에서 1회 이상의 실패한 편집이 있다.
  • 실패한 편집이 누적될수록 회복 가능성은 감소함(회복 : 연속 실패 후 성공적으로 편집하는 경우)
  • 최종적으로, 편집 시도는 90.5%의 확률로 성공하나, 최초 실패 후 편집의 성공률은 57.2%이다.
    (편집에 대해 §B.3.3에서 논의)

Agents succeed quickly and fail slowly.

  • 성공적인 실행이 성공하지 못한 것들보다 더 일찍, 더 저렴한 비용으로 완료된다는 것을 관찰했다
  • GPT-4를 사용한 SWE-agent에 의해 해결된 성공적인 인스턴스는 중간값 $1.21의 비용과 12단계로 완료
  • 반면, 성공하지 못한 것들은 평균 $2.52의 비용과 21단계가 소요
  • 해결된 인스턴스의 93.0%가 비용 예산을 소진하기 전에 제출
  • 반면, 전체 인스턴스의 69.0%만이 그렇다는 것을 발견

-> 이러한 이유로, 최대 예산이나 토큰 제한을 증가시키는 것이 성능을 크게 향상시킬 가능성이 낮다고 생각한다. (§B.9)

-> 아무리 루핑을 돌더라도, 해결 할 수 없다고 생각함.

Most failures are incorrect implementations.

 

  • GPT-4를 사용하여 해결되지 않은 궤적(SWE-bench Lite의 SWE-agent w/ GPT-4 Turbo, n=248)을 표 9에 9개로 설정한 카테고리 중 하나로 자동 분류함
  • 검증 세트에서, LM의 판단은 저자들의 판단과 87%의 인스턴스에서 일치함
  • 그림 8에서, 해결되지 않은 인스턴스의 약 절반(52.0%)이 잘못된 구현 또는 지나치게 구체적인 구현
  • 에이전트가 제안한 해결책이 (이슈를 기능적으로 해결하지 못하거나 / 일반적인 해결책이 아니라는 것을 시사)
  • 연속적인 실패한 편집은 실패의 또 다른 23.4%를 차지
  • (더 자세한 내용은 §B.4에서 확인할 수 있습니다)

 

 

 

 

 

6. Related Work

6.1 Software Engineering Benchmarks