https://arxiv.org/pdf/2405.15793


Abstract:

  • 이 논문이 제안된 배경은 인간이 IDE 를 가지고 코딩 문제를 해결하듯이 Agent 도 필요한 도구를 가진다면 더 나은 성능을 낼것이라는 가정하에 실험된 논문임.
  • Agent 에게 컴퓨터 인터페이스 (ACI) 를 제공했더니 SWE-bench에서 pass@1 기준 12.5% (기존 3.8%), HumanEvalFix에서 pass@1 기준 87.7% 높은 성능을 달성함 (이건 LLM 보다 크게 높은 성능이라고 함):
    • 제공된 기능은 코드 파일 생성 및 편집, 코드 저장소 탐색, 테스트 및 기타 프로그램 실행임.
    • 코딩 능력을 LLM 보다 높힌건 아님.
    • 다만 LLM 자체는 파일을 찾는 능력이 없고, 테스트를 실행할 능력이 없고 한번에 코드를 생성함. (이건 잘못된 코드를 조금이라도 생성하면 그게 영향을 주는 오류 전파에 취약)

 

 

Introduction:

  • 최근 연구들은 코드 생성과 실행 피드백을 통해 언어 모델 에이전트의 효능을 입증했음. 하지만 소프트웨어 엔지니어링과 같은 더 복잡한 코드 작업에 에이전트를 적용하는 연구는 아직 충분히 이루어지지 않았음.
  • 현재 LLM 에이전트는 주로 Linux 셸이나 Python 인터프리터와 같은 기존 애플리케이션을 사용하여 프로그래밍 작업을 수행하는 반면 인간 엔지니어들은 VSCode와 같은 정교한 통합 개발 환경(IDE)과 강력한 도구 및 확장 기능을 활용하여 소프트웨어 엔지니어링 작업을 수행함.
  • 이러한 작업 환경이 작업 생산성에 영향을 미치므로 LLM 에이전트도 소프트웨어 엔지니어링 작업을 수행하는 데 있어 더 잘 설계된 인터페이스의 혜택을 받을 수 있을지 탐구하고자 함.
  • 현재의 Agent 는 직접 Linux 셀을 이용하기에는 여러가지 어려움이 있기 때문에 여기서는 ACI (에이전트 컴퓨터 인터페이스) 를 제공함:
    • Linux 셸은 매우 다양한 명령어와 옵션을 제공함. 이것들을 조합해서 사용하기에는 어려움이 있을 수 있음. -> 그래서 보다 간단한 인터페이스를 제공함 (e.g create_file(filename, content), edit_file(filename, changes), search_in_files(query) 등)
    • Linux 셀은 실패와 성공에 대해서 피드백을 주지 않음. 실패하면 실패했다고 뜨고, 성공하면 별 응답이 없음. -> ACI 에서는 뚜렷한 피드백 메시지를 제공
    • Linux 셀을 직접 이용하면 상태 관리를 해야함. (현재 디렉토리, 환경 변수, 실행 중인 프로세스 등) -> ACI 에서는 이를 알아서 해줌.
  • SWE-agent에서의 ACI의 구체적 예시:
    • 파일 보기(View File): 특정 파일의 내용을 읽어와 에이전트에게 제공:
      • 명령어 예시: view_file("main.py")
      • 피드백 예시: "Contents of 'main.py':\nimport sys\n..."
    • 파일 검색(Search Files): 특정 키워드를 포함하는 파일을 검색
      • 명령어 예시: search_files("def main")
      • 피드백 예시: "Found 'main.py' containing 'def main'"
    • 파일 수정(Edit File): 특정 파일의 내용을 수정합니다.:
      • 명령어 예시: edit_file("main.py", "def main():\n print('Hello, World!')")
      • 피드백 예시: "File 'main.py' edited successfully."
    • 테스트 실행: 작성된 코드를 테스트
      • 명령어 예시: run_tests()
      • 피드백 예시: "All tests passed successfully."
    • Guardrail 제공:
      • 가드레일(guardrails) 을 사용해서 일반적인 실수를 제거할 수 있음.
      • 예를 들어, 파일 경로가 잘못되었을 때 자동으로 수정하거나, 금지된 명령어 실행을 방지할 수 있음.

 

 

The Agent-Computer Interface:

  • ACI 는 Agent 가 컴퓨터와 효과적으로 상호작용할 수 있도록 하는 인터페이스임. 서버로 치면 API 같은 것.
  • ACI 는 Function Calling 과 유사해보임. 언어 모델이 외부 환경과 상호작용 할 수 있는 추상화 매커니즘을 제공한다는게.
  • 여기서 발견한 ACI 의 원칙은 다음과 같음:
    • a) 행동(action)은 단순하고 이해하기 쉬워야 한다:
      • 많은 Bash 명령어는 수십 개의 옵션을 포함하는 문서화를 가지고 있음.
      • 단순한 명령어는 에이전트가 쉽게 사용할 수 있으며, Few-shot 이나 파인튜닝의 필요성을 줄여줌.
      • 이는 SWE-agent의 모든 명령어 설계의 기본 원칙
    • b) 행동(action)은 간결하고 효율적이어야 함:
      • 중요한 작업(예: 파일 내비게이션, 편집)은 가능한 한 적은 수의 행동으로 통합되어야 함. (한번의 행동으로 수행되어야 함)
      • 반면, 잘못 설계된 인터페이스는 많은 단순한 행동을 요구하여 고차원적인 작업을 여러 번의 반복을 통해 수행해야 할 수 있음.
    • c) 환경 피드백은 유익하면서도 간결해야 한다:
      • 고품질 피드백은 에이전트에게 현재 환경 상태와 최근 행동의 효과에 대한 실질적인 정보를 제공해야 함.
      • 불필요한 세부 사항은 피해야함:
      • SWE-agent의 ACI 설계가 검색 및 편집과 같은 작업에서 에이전트의 성능에 어떤 영향을 미치는지 평가한 결과는 다음과 같음:
        • 검색(Search) 인터페이스:
          • No Search:
            • 에이전트는 ls 또는 grep과 같은 기본적인 Bash 명령어만 사용하여 코드를 탐색
            • 제한된 정보와 수동적인 탐색으로 인해 에이전트가 관련 정보를 찾는 데 어려움을 겪음.
          • Iterative Search:
            • 에이전트는 search 명령어로 하나씩 검색 결과를 확인하고, 다음 결과로 넘어가기 위해 반복적으로 명령을 실행함.
            • 검색이 체계적이긴 하지만, 효율성이 떨어지며 결과가 여러 번 반복되므로 작업 시간이 증가할 수 있음.
            • No Search 보다 성능이 안나옴.
          • Summarized Search:
            • 모든 검색 결과를 한 번에 요약하여 제공하며, 에이전트가 이를 기반으로 작업을 효율적으로 진행할 수 있도록 함.
            • 이게 가장 성능이 좋음.
        • 편집(Edit) 인터페이스:
          • No Edit:
            • 에이전트는 Bash 명령어만 사용해 파일을 읽고(cat) 직접 내용을 추가하거나 수정함.
          • Edit w/o Linting:
            • 에이전트는 편집 작업을 하나의 명령으로 수행하며, Bash 명령어 대신 파일 뷰어와 편집 명령어를 사용함.
            • 그러나 구문 검사(linting) 이 없기 때문에 에이전트가 편집 중 실수를 저지르면 그 영향을 바로 감지하거나 복구하기 어려움.
          • Edit w/ Linting:
            • 편집 작업에 구문 검사를 추가해서 에이전트의 실수를 감지하고 수정할 수 있음.
        • 파일 뷰어(File Viewer):
          • 전체 파일 내용을 표시하는 것보다 파일 뷰어에서 100줄만 표시하는게 더 성능이 나음.
        • 컨테긋트 제공:
          • Full History: 모든 히스토리를 관리하면 불필요한 정보가 포함되어 성능이 감소하고, 최근 5개의 관찰 내용만 관리하는 방식이 가장 성능이 나음.
    • d) 가드레일(Guardrails)은 오류 전파를 완화하고 복구를 촉진해야 함:
      • 인간과 마찬가지로, LM도 편집이나 검색 시 실수를 저지를 수 있으며, 이러한 오류에서 회복하는 데 어려움을 겪을 수 있음.
      • 가드레일을 구축하면 에이전트가 실수를 인식하고 신속하게 수정할 수 있도록 도와줄 수 있다. 예를 들어, 코드 구문 검사기를 통해 자동으로 실수를 감지할 수 있음.

 

 

SWE-agent: Designing an ACI for Software Engineering:

  • Agnet 는 ReAct 방식으로 동작해서 ACI 를 사용함:
    • ACI 행동들 (파일 검색, 편집 등) 을 Agent 가 결정되면 내부적으로 명령을 리눅스 기반의 bash 로 변환되서 실행이 될 것. (아마 구현은 파이썬일듯)
  • 구체적으로 제공되는 ACI 기능들:
    • 검색 및 탐색(Search and Navigation):
      • find_file: 특정 파일 이름을 찾기 위해 사용.
      • search_file: 파일 내 문자열을 검색.
      • search_dir: 하위 디렉토리에서 문자열을 검색.
      • 검색 결과가 반환되면, 에이전트는 이를 분석하여 다음 행동을 계획할거임. (결과가 너무 많으면 쿼리를 더 구체적으로 조정, 특정 파일을 찾으면 해당 파일을 열기 위해 파일 뷰어 명령 실행.)
      • 검색 결과는 최대 50개로 제한. 결과가 초과되면 보다 구체적인 쿼리를 작성하도록 에이전트에게 안내
    • 파일 뷰어(File Viewer):
      • open("PvSystem.py"): 파일 열기. (최대 100줄씩 파일 내용을 표시)
      • scroll_down: 창을 아래로 스크롤.
      • goto(50): 특정 줄로 이동.
      • 파일 뷰어에서 반환된 피드백(현재 창의 줄 번호, 생략된 줄 등)을 기반으로 탐색 전략을 조정할거임.
    • 파일 편집(File Editor):
      • 일을 생성하거나 편집하는 것.
      • edit 명령어를 사용하여 파일 내용을 수정할 거고 다름 3가지 인자를 요구함:
        • 시작 줄 번호(start line).
        • 끝 줄 번호(end line).
        • 교체할 텍스트(replacement text).
        • 한 번의 명령으로 지정된 줄을 새로운 텍스트로 대체
      • IDE의 구문 강조(syntax highlighting)처럼, 파일 편집 시 에이전트가 오류를 감지할 수 있음.
    • 컨텍스트 관리:
      • ACI 명령어 관리: Bash 및 ACI 명령어 사용법에 대한 문서와 데모를 에이전트에게 제공
      • 오류 메시지 처리:
        • 잘못된 명령 생성 시, 에러 메시지를 반환하고 올바른 명령이 생성될 때까지 반복 요청
        • 반복된 에러 메시지는 첫 번째 메시지 외에는 생략하여 불필요한 정보를 줄임.
      • 명확한 출력:
        • 명령 실행 후 출력이 없을 경우, “Your command ran successfully and did not produce any output”과 같은 메시지를 제공하여 혼란을 방지
      • 컨텍스트 축소:
        • 이전 관찰 중 마지막 5개만 유지하고, 그 이전의 관찰은 한 줄로 축소하여 필요한 정보만 유지.

 

 

Analysis of Agent Behavior:

  • 에이전트의 문제 해결 괴정 플로우:
    • (1) Reproduction(재현) 및 Localization(위치 추적):
      • 문제 해결의 첫 번째 단계로 재현 코드 작성과/또는 문제의 원인을 특정 코드 줄로 국지화하는 작업을 수행
      • 모든 문제 해결 경로는 create(재현 코드 작성) 또는 find_file/search_dir(문제 위치 탐색) 명령어로 시작
      • 에이전트는 새 파일을 생성하고(create), 재현 코드를 추가한 후(edit), 해당 코드를 실행(python)하여 결과를 관찰
      • 아니면 디렉토리 수준에서의 키워드 검색(search_dir)을 통해 넓은 범위의 정보를 탐색한 후, 특정 파일(find_file)과 줄(goto)로 점점 좁혀나감.
    • (2) Edit-Execute 루프
      • 편집과 코드 실행을 반복적으로 함.
      • 그리고 새로운 정보를 얻기 위해 코드를 재실행하거나(python), 필요에 따라 파일 탐색(search_file, scroll_up/down, search_dir, find_file) 작업을 추가로 수행.
  • Agent 가 어려움을 겪는 부분:
    • 편집 작업 중 비율적으로 많은 오류가 발생하며, SWE-agent(GPT-4 Turbo)의 2,294개 작업 중 51.7%(1,185개)에서 1회 이상의 편집 실패가 관찰되었음.
      • 에이전트는 실패한 편집 작업에서 종종 회복(recovery)하지만, 실패가 누적될수록 복구 확률이 감소함.
      • 첫 시도 시: 90.5% 로 성공, 한번 실패하고 나면 57.2% 로 성공
      • 복구 능력이 실패가 쌓일수록 떨어져보임.
    • 잘못된 구현(Incorrect Implementations):
      • 실패한 작업을 9개의 카테고리로 분류했을 떄 52%는 잘못된 구현을 하거나 지나치게 특정화된 구현을 했다고 함. (여러 코드 수정의 가능성을 탐색해보면 도움이 되어보임.
      • 23.4% 는 실패한 편집 작업이 연쇄적으로 이어진걸로 보임. (에이전트가 편집에만 집중할 수 있도록 출력 포맷을 간단화 하는 것도 도움이 되어보임. 인지 부담을 줄이는 것, 아니면 보다 구체적인 피드백을 얻을 수 있는 방법을 적용, 아니면 여러번의 샘플링, 아니면 한번에 복잡한 작업을 하기 보다는 나눠서 하거나)

+ Recent posts