SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (Jimenez et al., Princeton, ICLR 2024)
Introduction
HumanEval(Chen et al., 2021)이나 MBPP 같은 기존 코딩 벤치마크는 “함수 한두 개를 작성하는 합성 문제”였다. 함수 시그니처와 docstring을 주고 빈 함수를 채우게 한다. 이런 문제는 GPT-4가 이미 80% 이상을 푼다.
그러나 실제 소프트웨어 엔지니어링은 이렇지 않다. 논문이 인용하는 표현 그대로다.
“In the real world, software engineering is not as simple. Fixing a bug might involve navigating a large repository, understanding the interplay between functions in different files, or spotting a small error in convoluted code.”
실세계 task는 다음을 요구한다.
- 수천 개 파일이 있는 대규모 codebase 탐색 (평균 438K 라인)
- 여러 함수·클래스·파일에 걸친 변경 조율
- 매우 긴 context 처리
- 실행 환경과의 상호작용
- 자연어 issue 설명을 코드 변경으로 번역
SWE-bench는 이 현실을 그대로 평가한다. 12개 인기 Python 레포지토리에서 실제로 해결된 GitHub 이슈 2,294개를 모아, LLM이 직접 패치를 만들어 테스트를 통과시키는지를 본다.
기여를 정리하면:
- 실세계 GitHub 이슈 기반 평가: 합성 task에서 실제 PR로 paradigm 전환
- Execution-based scoring: LLM judge가 아닌 테스트 실행 결과로 채점 → contamination에 강건
- 확장 가능한 데이터 구축 파이프라인: 새 이슈로 지속적 갱신 가능
- SWE-Llama: oracle context로 fine-tuned된 baseline 모델 공개
발표 시점(2023-10)에는 Claude-2가 1.96%, GPT-4가 1.74%였다. 2년 반 후 SWE-bench Verified에서 GPT-5.5가 88.7%를 기록한다. agent 능력의 사실상의 바로미터가 된 벤치마크다.
Related Work
| 분류 | 대표 벤치마크 | 한계 |
|---|---|---|
| 함수 단위 코드 생성 | HumanEval, MBPP, APPS | 짧은 self-contained 문제, repo 탐색 없음 |
| 경쟁 프로그래밍 | CodeContests | algorithmic, 실세계 SWE와 거리 |
| 버그 수정 (소규모) | Defects4J, QuixBugs | 학술적·작은 단위, 자연어 issue 설명 없음 |
SWE-bench의 차별점은 두 가지다.
- 자연어 issue를 입력으로: 사용자가 실제 작성한 모호한 자연어 설명을 그대로 사용
- multi-file patch + test 검증: 한 함수가 아니라 codebase 전체에서 변경이 필요할 수 있고, 검증은 실제 테스트 실행으로 한다
데이터셋 구축
12개 Python 레포
PyPI 상위 5,000 패키지 중 top 100에서 라이선스가 허용하는 것을 선별한다. 인기 레포를 고른 이유는 (a) 잘 관리되고, (b) contributor guideline이 있으며, (c) test coverage가 우수하기 때문이다.
| Repository | Crawled PRs | Final Instances |
|---|---|---|
| django/django | 16,914 | 850 |
| sympy/sympy | 11,928 | 386 |
| scikit-learn/scikit-learn | 15,159 | 229 |
| sphinx-doc/sphinx | 4,931 | 187 |
| matplotlib/matplotlib | 16,545 | 184 |
| pytest-dev/pytest | 5,147 | 119 |
| pydata/xarray | 3,416 | 110 |
| astropy/astropy | 9,469 | 95 |
| pylint-dev/pylint | 3,848 | 57 |
| psf/requests | 2,344 | 44 |
| mwaskom/seaborn | 1,004 | 22 |
| pallets/flask | 2,434 | 11 |
| Total | 93,139 | 2,294 |
Django alone이 37%, 상위 3개(Django + SymPy + scikit-learn)가 약 64%를 차지하는 long-tail 분포다.
3단계 필터링 파이프라인
90,000개의 raw PR을 2,294개의 최종 task로 줄이는 파이프라인은 다음과 같다.
Stage I — Repo selection & scraping
12개 레포에서 PR 전수 수집. 약 93,139개 PR.
Stage II — Attribute-based filtering
3가지 조건을 모두 만족하는 PR만 통과시킨다.
- PR status가 Merged
- PR이 issue를 resolve (제목/본문/커밋 메시지에서 “fixes #24”, “closes #N” 같은 키워드)
- test 파일을 수정 (PR이 새 테스트를 contribute)
이 단계에서 약 11,407개로 줄어든다.
Stage III — Execution-based filtering
실제로 실행해 본다.
- test patch를 적용한 후 PR의 솔루션 코드 적용 전후 테스트 결과를 비교
- 최소 1개 이상의 fail-to-pass test가 있어야 함 (즉 PR이 실제로 뭔가를 해결)
- installation/runtime error가 있는 instance 제거
최종 2,294 task instances가 남는다.
Task 구조
입력과 출력
| 항목 | 설명 |
|---|---|
| Issue text | 평균 195 단어의 자연어 problem statement |
| Codebase snapshot | PR base commit의 전체 코드 (평균 3,010개 non-test 파일, 438K lines) |
| 출력 | unix diff 형식의 .patch 파일 |
흥미로운 발견 하나: 모델에게 patch를 생성하게 하는 것이 whole file을 재생성하게 하는 것보다 잘 작동한다. Claude-2의 경우 patch 4.8% vs whole file 2.2%다. 모델 입장에서 “바꿔야 하는 부분만 표현”하는 것이 더 자연스럽다.
FAIL_TO_PASS vs PASS_TO_PASS
평가에는 두 종류 테스트가 사용된다.
| 종류 | 솔루션 적용 전 | 솔루션 적용 후 | 의미 |
|---|---|---|---|
| FAIL_TO_PASS (F2P) | fail | pass | 이슈가 실제로 해결됐는지 |
| PASS_TO_PASS (P2P) | pass | pass | 기존 기능을 깨지 않았는지 (regression 검증) |
- 모든 instance가 ≥1개의 F2P test 보유, 40%는 ≥2개. 평균 9.1개.
- Median 51개의 추가 P2P 테스트. 평균 120.8개의 total tests.
Task가 “resolved”되려면: 모든 F2P + 모든 P2P가 pass해야 한다. 패치가 이슈는 고쳤지만 다른 기능을 깨면 실패다.
평가 파이프라인
- base commit으로 codebase reset
- version별 conda 환경 activate
- installation 실행
- test patch T 적용 (정답 테스트 포함)
- 모델의 prediction patch δ̂ 적용 (실패 시 auto-fix: context line 제거, header 재계산)
- test 실행 → log 생성
- test-to-status mapping을 ground truth와 비교
각 task마다 conda 환경이 다르고 dependency도 다르다. SWE-bench의 환경 구축 비용이 큰 이유다.
평가 메트릭
- % Resolved (pass@1): 모든 F2P + P2P test를 통과한 task 비율 → 주요 메트릭
- % Apply: patch가 적용은 성공한 비율 (부분 점수)
Experiments
평가 모델 및 context length
| Model | Max Tokens | % Instances 처리 가능 |
|---|---|---|
| ChatGPT-3.5 (16k) | 16,385 | 58.1% |
| GPT-4 (32k) | 32,768 | 84.1% |
| Claude-2 | 100,000 | 96.4% |
| SWE-Llama 7b/13b | ≥100,000 | ≥94.8% |
SWE-bench는 codebase 자체가 크기 때문에 context length가 평가 가능 여부를 결정한다. 100K context를 가진 Claude-2조차 3.6%의 instance는 처리 불가다.
BM25 Retrieval 결과
오라클이 아닌 일반 시나리오에서 (BM25 retrieval, 13K context):
| Model | % Resolved | % Apply |
|---|---|---|
| Claude 2 | 1.96 | 43.07 |
| Claude 3 Opus (v3 추가) | 3.79 | 46.56 |
| GPT-4-turbo (32k) | 1.74 | 26.90 |
| ChatGPT-3.5 | 0.17 | 26.33 |
| SWE-Llama 7b | 0.70 | 51.74 |
| SWE-Llama 13b | 0.70 | 53.62 |
모든 모델이 5% 미만이다. SWE-Llama는 fine-tuned model인데도 BM25 context에서는 1% 이하다.
Context length의 영향 — distractibility
Claude 2의 BM25 context length별 점수:
| Context | % Resolved |
|---|---|
| 13K | 1.96 |
| 27K | 1.87 |
| 50K | 1.22 |
context가 길어질수록 성능이 하락한다. 이는 “Lost in the Middle”(Liu et al., 2023) 현상과 일치한다. 더 많은 정보가 오히려 distractor로 작용한다.
Oracle Retrieval — 정답 파일을 알려준 경우
만약 모델에게 “수정해야 할 파일이 어디인지” 알려준다면?
| Model | % Resolved | % Apply |
|---|---|---|
| Claude 2 | 4.80 | 62.82 |
| SWE-Llama 13b | 3.97 | 66.78 |
| SWE-Llama 7b | 3.01 | 65.52 |
| GPT-4* | 1.74 | 34.00 |
| ChatGPT-3.5 | 0.52 | 21.80 |
* GPT-4는 budget 제약으로 25% random subset에서 평가
흥미롭게도 fine-tuned SWE-Llama 13b가 GPT-4를 능가한다. 다만 SWE-Llama는 oracle context로 학습되었기 때문에 BM25 context에서는 급격히 떨어진다(3.97% → 0.70%).
Oracle-Collapsed (정답 파일 + edit 부근 ±15 lines)
훨씬 더 친절한 시나리오:
| Model | % Resolved | % Apply |
|---|---|---|
| Claude 3 Opus | 9.39 | 48.00 |
| Claude 2 | 5.93 | 68.18 |
| GPT-4 | 3.40 | 48.65 |
| ChatGPT-3.5 | 1.09 | 40.93 |
Localization을 거의 다 풀어줘도 10% 이하다. 문제는 어디를 고칠지 모르는 것보다 어떻게 고칠지 모르는 것이다.
SWE-Llama Fine-tuning 세부
저자는 baseline으로 CodeLlama-Python 7B/13B를 LoRA fine-tune했다.
- Training data: 12개 평가 repo와 disjoint한 37개 추가 Python 레포에서 19,000 issue-PR 쌍 수집
- LoRA: r=16, α=16, dropout=0.05, attention sublayer만 튜닝
- 30K 토큰 이상 시퀀스 제외 → effective 10,000 instances
- 7b: 20시간 / 4×A100, 13b: 47시간 / 8×A100
- DeepSpeed Ulysses + Flash Attention 사용
실패 분석
1. Patch는 syntactically valid해도 semantically 틀림
Claude 2 oracle: 62.82% apply, 4.80% resolve. 거의 60%가 적용은 되지만 테스트를 통과 못 한다. 즉 모델이 patch syntax는 알지만 실제 fix는 못한다.
2. 모델은 더 짧고 단순한 edit을 생성
Gold patch와 Claude 2 patch의 크기 비교:
| 지표 | Gold patch | Claude 2 patch |
|---|---|---|
| Lines | 74.5 | 19.6 |
| Lines added | 22.3 | 4.2 |
| Lines removed | 10.5 | 1.9 |
| Functions edited | 3.0 | 1.1 |
| Files edited | 1.7 | 1.0 |
모델은 거의 항상 single file, single function edit을 만든다. Gold patch는 multi-file에 걸친 구조적 변경이 많다. 모델은 “minimal local fix”에 머문다.
3. Qualitative 예시: sphinx-8713
논문이 분석한 대표 사례. 모델은 올바른 파일과 함수(_parse_other_parameters_section)를 찾았다. 그러나 config flag(napoleon.use_param) 분기를 무시하고 항상 True인 것처럼 동작하게 변경했다.
Gold patch는 _parse_parameters_section처럼 config를 체크하지만, 모델은 그 코드 패턴을 따르지 않았다. 모델은 “primitive Python code”를 작성하는 경향이 있고, 기존 third-party 라이브러리나 codebase 패턴을 활용하지 않는다.
4. 이미지 포함 issue 처리 불가
- matplotlib instance의 32%가 이미지 포함
- seaborn의 10%가 이미지 포함
이런 visual debugging은 multi-modal model이나 외부 tool이 필요하다.
5. Repository별 난이도 차이
Oracle setting 기준:
| 가장 쉬운 repo | 점수 | 가장 어려운 repo | 점수 |
|---|---|---|---|
| requests | 15.91% (Claude 2) | seaborn | 0% (모두) |
| requests | 18.18% (SWE-Llama 7b) | pylint | 1.75% |
| django | 6.15% (Claude 2) | matplotlib | (이미지 issue 비중 큼) |
6. Temporal Analysis로 contamination 우려 완화
2023년 전후 instance에서 성능 차이가 거의 없다. 즉 모델이 단순히 “newer version을 기억해서” 해결하는 게 아니다. SWE-bench가 contamination에 비교적 강건함을 보여주는 증거다.
이후 동향 (2024-2026)
SWE-bench의 변종들
SWE-bench Lite (2024 초)
300 instances. “self-contained, functional bug fixes” 중심. 빠른 evaluation을 위한 sampling.
SWE-bench Verified (2024-08, OpenAI × Princeton)
가장 widely-cited variant. 93명의 contracted software developer가 instance를 검증했다. 1,699 instance를 3명씩 review하여 unambiguous, fair test, solvable한 500개를 선별했다. 원본 SWE-bench의 약 38%가 결함 있다는 지적이 후속 분석에서 나왔다.
검증 항목:
- 모호한 problem statement
- Unfair test (모델이 모를 수 없는 implementation detail 요구)
- Underspecified expected behavior
SWE-bench Multilingual (2024)
300 tasks, 42 repos, 9개 언어 (C, C++, Go, Java, JavaScript, TypeScript, PHP, Ruby, Rust). Python 한정의 한계를 해결.
Multi-SWE-bench (ByteDance-Seed)
2,132 instances, 8개 언어. 68명의 expert annotator. mini(400)/flash(300) 버전도 존재.
SWE-bench Pro (Scale AI)
더 어려운 task, 구조화된 requirements와 explicit interface spec. contamination 우려가 적다 (private/non-public data 포함).
Agent 시대의 도래
SWE-Agent (Yang et al., Princeton/Stanford, NeurIPS 2024)
Agent-Computer Interface (ACI) 제안. LM이 파일 편집, repo navigation, test 실행을 위한 명령어 인터페이스. 출시 시점에 SWE-bench full에서 12.5% pass@1 (당시 SOTA).
OpenHands (formerly OpenDevin)
오픈소스 agent framework. 2025년 SWE-bench Verified 60.6%, 이후 inference-time scaling + critic model로 77.6% 달성. Multi-SWE-bench에서 1위.
Cognition Devin
첫 commercial autonomous SWE agent. SWE-bench로 마케팅(~13.86% in early 2024).
현재 SOTA (2026년 5월 기준)
SWE-bench Verified 기준:
| 모델 | 점수 |
|---|---|
| GPT-5.5 (OpenAI, 2026-04-23) | 88.7% |
| Claude Opus 4.7 (Anthropic, 1M context) | 87.6% |
| GPT-5.3-Codex | 85.0% |
| Claude Sonnet 4.6 | 79.6% |
| TRAE (2025-06, Claude 4 ensemble) | 75.2% |
SWE-bench Pro: Claude Opus 4.7이 64.3%로 선두.
논문 발표(2023-10) 대비 2년 반 만에 1.96% → 88.7%, 약 45배 향상.
Discussion / 한계
논문이 명시한 한계 (Section 7):
- Python 전용: 다른 언어/도메인 확장 필요 → Multilingual로 확장됨
- 단순한 baseline: agent-based, tool-augmented 접근을 의도적으로 다루지 않음 — future work
- Test pass ≠ 좋은 코드: 모델 생성 코드가 인간 작성보다 less comprehensive, efficient, readable할 수 있음
- Environment 재현 비용: version별 conda env 수동 구성, dependency 직접 파악 → 이후 Docker로 완화
- 이미지 처리 불가: 일부 issue는 multi-modal 능력 필요
- Data contamination 우려: 다만 temporal analysis에서 큰 영향 없음 확인
- Repo distribution 편향: Django alone 37% — long-tail
- Gold patch만이 정답이 아님: 다른 valid한 해결책도 가능하나 정답 test에 fail할 수 있음
후속 평가에서 드러난 추가 한계 (Verified가 만들어진 이유):
- 모호한 problem statement
- Unfair test
- Underspecified expected behavior
- 약 38%의 original SWE-bench instance가 결함 있다고 평가됨
Conclusion
SWE-bench가 agent 평가에 끼친 영향은 막대하다.
- Sandboxed execution evaluation의 표준: LLM judge가 아닌 실제 코드 실행으로 채점. 가장 객관적인 평가 중 하나.
- Contamination에 강건: 테스트 통과는 데이터 암기로 풀 수 없다.
- 실세계 task 평가의 paradigm: 합성 task에서 real-world repo + real-world issue로의 전환.
- specialized agent 진화의 촉매: SWE-Agent, OpenHands, Devin 등 SWE-bench를 풀기 위한 agent framework가 폭발적으로 등장.
한계도 명확하다. Python 한정, Docker 환경 구축 비용, “test 통과 = 좋은 코드”가 아닐 수 있음 등. 그러나 이 한계들조차 후속 작업(Multilingual, Verified, Pro)을 낳는 출발점이 되었다.
논문이 던진 핵심 질문 — “LLM이 진짜 GitHub 이슈를 풀 수 있는가?” — 의 답은 2년 반 만에 “1.96%”에서 “88.7%”로 바뀌었다. 그러나 100%는 아니다. 남은 11.3%가 무엇인지, 그리고 인간 SWE의 진짜 작업이 SWE-bench가 측정하는 것 이상의 무엇인지에 대한 논의가 지금도 진행 중이다.
이어서 읽기: AgentBench, TravelPlanner: planning에서 GPT-4도 1% 미만, TelAgentBench
참고 문헌
- SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (arXiv 2310.06770) — Jimenez et al., ICLR 2024
- SWE-bench 공식 사이트
- SWE-bench GitHub
- SWE-bench Verified (OpenAI)
- SWE-bench Multilingual
- SWE-Agent (arXiv 2405.15793) — Yang et al., NeurIPS 2024
- OpenHands SOTA Blog
- Multi-SWE-bench (ByteDance)
- Lost in the Middle (Liu et al., 2023)
Enjoy Reading This Article?
Here are some more articles you might like to read next: