이 논문은 코드를 수정하거나 새로운 기능을 추가하는 등의 작업을 자동화하는 모델에 대한 내용이다.
일반적으로 코드 작성 시 llm을 사용할 때 보통 코드를 짜주거나 단순 개선 등에 이용되는데, 이 논문은 그와 다르게 소프트웨어 유지보수 / 업데이트에 필요한 개선 자동화를 주로 하고 있다. 코드를 짜는 목표가 아니라, 시스템적으로 코드 수정에 특화된 방식을 개발하였다는 말.
다른 논문에서도 llm을 쓰는 것이 종종 있었지만, 기본적으로 '바꿔야 할 부분'을 주고 이를 바꾸라고 시킨다. 하지만 저자들이 말하기를 전체 코드상에서 틀린 부분을 찾는 것조차도 이미 굉장히 어려운 태스크라고 주장한다. (실제 코드를 짜 보면 알겠지만, 어디가 틀렸는지 보통 디버거로 찾아 들어가야 한다. 그마저도 안 보이는 경우도 존재하고, 분명 맞는 로직인데 어디선가 충돌이 나서 틀린 로직으로 보이는 경우도 존재)
이 논문에서는 다음과 같은 작업을 통해 문제를 해결한다.
- AST를 사용하여 코드의 구조적인 이해를 돕는다. 다른 llm이 단순 줄 코드로 학습된 것을 생각하면, ast를 사용하여 코드의 '구조적인' 정보를 더 추가했다고 볼 수 있다.
- 코드 재검색: 코드를 계속해서 반복적으로 검색하여 문제의 원인을 찾아내도록 한다. 그러니까, 틀린 위치를 지속적으로 탐색한다는 말
- SBFL: 테스트의 통과 / 실패 부분을 분석해서 보다 정밀한 오류 발생 candidate를 찾아냄.
Method
AutoCodeRover가 문제를 해결하는 방식은 다음과 같다.
- 문제 이해: 일단 natural language로 설명된 부분을 분석하여 문제를 이해하며, 관련 코드 snippet을 초기로 찾는다.
- 코드 색출: 식별 부분을 기초로 해서 여러 api를 호출하여 관련 클래스 / 메소드 / snippet를 찾아낸다. 이 때 AST가 사용되는데, 코드의 구조적인 정보 및 요구 부분을 찾아내는 데 사용
2.1. 반복적 검색: 여러 단계애 걸쳐 해당 부분이 문제와 관련된 부분인지 색출 - 패치 수정
3.1. 패치 구성: 수정 패치를 만든다 (수정될 부분 및 내용을 상단에서 파악)
3.2. 패치 적용: 테스트가 달려 있어 성공적으로 대치가 이루어졌는지 확인
3.3. 반복 및 최적화: 3.2. 에서 실패할 경우! 다시 돌아가 - 평가: 3.3이랑은 다르다. 그냥 최종적으로 확정되었을 때 수정 코드 성능을 확인하는 작업
위에 나오는 api는 다음과 같음
각 패치 작성 시 다음과 같이 프롬프트로 지속적인 수정 및 대치 작업을 한다. (마치 agent와 같이 동작)
오류 부분 검색을 진행할 때, 코드의 상단부터 시작하여 계층적으로 나아가게 된다.
agent와 비슷하게 동작하며, insufficient인 경우 계속해서 다음 계층을 탐색하여 들어가는 느낌.
이때 초반 검색 시 '반복적인 검색' '반복적인 성능 평가' 등이 나오는데, 이 기법이 SBFL이다.
SBFL(spectrum-based fault localization)은 테스트를 기반으로 오류 발생 가능성이 있는 프로그램의 위치를 찾아내는 기법이다.
사용하지 않은 경우 코드 문맥을 찾는 데 한계가 있었다고 설명함. 마치 RAG를 하지 않았을 때 실제 정보에 한계가 있던 것처럼, 실제 정보에 거의 접근한 정보를 알려줌으로서 정답에 가깝게 답변할 수 있도록 보강하는 느낌이다.
Experiments
- 실제 github에서 발생하는 문제를 얼마나 많이 풀 수 있는가?
- dataset: SWE-bench-lite(github issue 300)
- 평가: 정답률(테스트 코드가 있다) 시간 / resources 등
오 너무 낮은데? 라고 생각했는데 원본 벤치마크에서 충격받았다.
