|
| 1 | +# SWE-bench Verified A/B benchmark — harness-boot vs vanilla Claude Code |
| 2 | + |
| 3 | +> Object: **객관적으로 측정** — 같은 task 를 (a) 그냥 Claude Code 와 (b) harness-boot 로 풀었을 때, 결과물 퀄리티 / 토큰 소비 / 목표 달성률에 정량적 차이가 있는가? |
| 4 | +
|
| 5 | +이 디렉터리는 **재현 가능한 비교 framework** 입니다. 실측 데이터는 `REPORT.md` 에 누적됩니다. |
| 6 | + |
| 7 | +--- |
| 8 | + |
| 9 | +## 1. 왜 SWE-bench Verified? |
| 10 | + |
| 11 | +| 기준 | SWE-bench Verified | 다른 후보 | |
| 12 | +|---|---|---| |
| 13 | +| 권위 | Anthropic / Princeton 이 표준으로 사용 — 모든 frontier model 의 비교 baseline | HumanEval (단순 함수, contamination) · MBPP (구식) · Aider polyglot (단일 언어 X) | |
| 14 | +| 현실성 | 실제 GitHub repo 의 issue → PR. multi-file fix. test 통과 여부로 자동 채점 | LiveCodeBench (월별 갱신 noise) · TAU-bench (도메인 한정) | |
| 15 | +| harness fit | **multi-step agentic + AC 명시 가능 + repo-level → harness 의 가치 axis 모두 발현** | HumanEval 류는 single function 이라 harness overhead 가 정량 패배 | |
| 16 | +| 외부 인용 가능 | Anthropic / OpenAI / Google 모두 인용 — README marketing 가치 | 자체 benchmark 는 외부 검증 X | |
| 17 | + |
| 18 | +**500 → 20 task 축소 근거**: full run 은 task 당 $1-10 × 모델 × 양쪽 = $40+ × 500 = $20,000 비현실적. 20 task subset 으로 first-order signal 확보 후 결과에 따라 확장. |
| 19 | + |
| 20 | +`tasks.json` 의 20 pick 은 repo 다양성 (django · sympy · flask · pandas · matplotlib · sphinx · scikit-learn · pytest · pylint · requests 등) + difficulty 분포 (hard 4 · medium 12 · easy 4) + harness-fit axis (single-fix vs multi-step) 의 mix. |
| 21 | + |
| 22 | +--- |
| 23 | + |
| 24 | +## 2. 측정 4 axis |
| 25 | + |
| 26 | +각 task 의 양쪽 시도 (vanilla · harness) 결과를 `results/<approach>/<task_id>.json` 에 기록. schema: |
| 27 | + |
| 28 | +```json |
| 29 | +{ |
| 30 | + "task_id": "django__django-13551", |
| 31 | + "approach": "vanilla" | "harness", |
| 32 | + "resolved": true, // SWE-bench test harness 가 PASS 판정 |
| 33 | + "tokens_input": 123456, // 누적 input token (vanilla: /cost 수기, harness: `harness token` 자동) |
| 34 | + "tokens_output": 7890, |
| 35 | + "wall_time_sec": 720, |
| 36 | + "attempts": 1, // 같은 task 재시도 횟수 |
| 37 | + "code_loc": 45, // patch 의 +line - -line |
| 38 | + "tests_added": 3, // 새로 작성한 test 수 |
| 39 | + "tests_passed": "all" | "partial" | "none", |
| 40 | + "harness_drift_catches": 0, // harness only: 15-detector 가 잡은 issue 수 |
| 41 | + "harness_evidence_kinds": ["manual_check", "test", "..."], // harness only |
| 42 | + "notes": "..." // 정성적 관찰 |
| 43 | +} |
| 44 | +``` |
| 45 | + |
| 46 | +집계 (`scripts/aggregate.py`): |
| 47 | +- **Resolve rate** = `Σ(resolved == true) / N` |
| 48 | +- **Mean tokens per task** = input + output 합산 평균 |
| 49 | +- **Mean wall time per task** = sec 평균 |
| 50 | +- **Per-task delta** = harness − vanilla 의 분포 |
| 51 | + |
| 52 | +--- |
| 53 | + |
| 54 | +## 3. 비교 절차 (재현) |
| 55 | + |
| 56 | +자세한 단계는 `scripts/setup.md`. 요약: |
| 57 | + |
| 58 | +```bash |
| 59 | +# 1) SWE-bench 환경 셋업 (한 번만) |
| 60 | +git clone https://github.com/princeton-nlp/SWE-bench.git |
| 61 | +cd SWE-bench |
| 62 | +pip install -e . |
| 63 | + |
| 64 | +# 2) 20 task subset 추출 |
| 65 | +python scripts/pick_subset.py --tasks docs/benchmark/swe-bench-verified/tasks.json |
| 66 | + |
| 67 | +# 3) vanilla 시도 (모든 task 순회) |
| 68 | +bash docs/benchmark/swe-bench-verified/scripts/run-vanilla.sh |
| 69 | + |
| 70 | +# 4) harness 시도 (모든 task 순회) |
| 71 | +bash docs/benchmark/swe-bench-verified/scripts/run-harness.sh |
| 72 | + |
| 73 | +# 5) 집계 + REPORT.md 갱신 |
| 74 | +python docs/benchmark/swe-bench-verified/scripts/aggregate.py |
| 75 | +``` |
| 76 | + |
| 77 | +vanilla 와 harness 의 토큰 측정: |
| 78 | +- **vanilla**: Claude Code 의 `/cost` 명령을 매 task 직후 호출, 누적값을 result JSON 에 수기 입력 |
| 79 | +- **harness**: `harness token --in X --out Y --model M --feature F-N` 으로 자동 기록 (F-172 의 인프라) |
| 80 | + |
| 81 | +--- |
| 82 | + |
| 83 | +## 4. harness 가 정확히 어떻게 다른가 (가설) |
| 84 | + |
| 85 | +이 비교가 noise 가 아닌 signal 을 잡으려면 가설이 명확해야: |
| 86 | + |
| 87 | +| 가설 | 측정 방법 | 예상 | |
| 88 | +|---|---|---| |
| 89 | +| harness 는 **AC 미커버 task** 에서 vanilla 보다 더 자주 resolve | `tests_passed == "all"` 비율 | harness +5~15% | |
| 90 | +| harness 는 **drift 패턴 (e.g. README 와 code 불일치)** 을 자동 catch | `harness_drift_catches > 0` 인 task 수 | harness 가 vanilla 보다 0~3 건 더 | |
| 91 | +| harness 는 **multi-step task** 에서 token 단축 (자동 sync · ceremony 가 manual prompt 절감) | `tokens_input + tokens_output` 평균 | harness −10~30% | |
| 92 | +| harness 는 **single-fix task** 에서 token 증가 (boilerplate overhead) | 같은 axis | harness +10~30% | |
| 93 | +| harness 는 **resolve rate 자체는 비슷** (모델은 같으니까) | resolve rate | ±0~5% | |
| 94 | + |
| 95 | +→ 결과가 가설과 다르면 그게 더 가치 있는 발견. **null result 도 정직하게 기록**. |
| 96 | + |
| 97 | +--- |
| 98 | + |
| 99 | +## 5. 정직한 한계 |
| 100 | + |
| 101 | +- **Single model · single author** (Claude). vanilla 와 harness 양쪽 동일 모델 사용. 사람 user 의 prompt 차이는 confounder. |
| 102 | +- **Single time**. v0.15.7 시점 plugin · 특정 모델 release 시점. |
| 103 | +- **Benchmark contamination**. SWE-bench Verified 의 일부 task 는 training data 에 포함됐을 가능성. resolve rate 자체를 절대값으로 신뢰 X — 두 approach 간 **상대 차이** 가 중요. |
| 104 | +- **20 task subset**. 500 의 4%. statistical power 약함. p-value 보다는 effect size 의 magnitude 관찰. |
| 105 | +- **harness fit per task**. AC 가 명확한 task 는 harness 우위, 단순 typo fix 는 harness overhead. task selection 의 mix 자체가 결과에 영향. |
| 106 | + |
| 107 | +자세한 분석: `analysis/threats-to-validity.md`. |
| 108 | + |
| 109 | +--- |
| 110 | + |
| 111 | +## 6. 산출물 라이프사이클 |
| 112 | + |
| 113 | +1. **Framework (이 PR)** — 폴더 / 방법론 / 스크립트 / skeleton — landed v0.15.8 |
| 114 | +2. **Pilot run (5 task)** — maintainer 가 외부 환경에서 실측, REPORT.md 의 일부 row 채움 |
| 115 | +3. **Full run (20 task)** — pilot 결과 보고 확장. 별도 cycle. |
| 116 | +4. **README link** — 결과 안정화되면 project root `README.md` 의 "Status" / "Built with" 근처에 link 추가 |
| 117 | + |
| 118 | +--- |
| 119 | + |
| 120 | +## 7. 디렉터리 구조 |
| 121 | + |
| 122 | +``` |
| 123 | +docs/benchmark/swe-bench-verified/ |
| 124 | +├── README.md # 이 파일 — 방법론 + 한계 |
| 125 | +├── REPORT.md # 결과 누적 (실측 후 채움) |
| 126 | +├── tasks.json # 20-task selection + 근거 |
| 127 | +├── results/ |
| 128 | +│ ├── vanilla/<task_id>.json |
| 129 | +│ └── harness/<task_id>.json |
| 130 | +├── scripts/ |
| 131 | +│ ├── run-vanilla.sh |
| 132 | +│ ├── run-harness.sh |
| 133 | +│ ├── aggregate.py |
| 134 | +│ └── setup.md |
| 135 | +└── analysis/ |
| 136 | + └── threats-to-validity.md |
| 137 | +``` |
| 138 | + |
| 139 | +--- |
| 140 | + |
| 141 | +## 8. 인용 |
| 142 | + |
| 143 | +이 benchmark suite 의 데이터를 인용할 때: |
| 144 | + |
| 145 | +``` |
| 146 | +harness-boot SWE-bench Verified A/B (v0.15.8+) |
| 147 | +https://github.com/qwerfunch/harness-boot/tree/main/docs/benchmark/swe-bench-verified |
| 148 | +``` |
| 149 | + |
| 150 | +비교 대상이 vanilla Claude Code 가 아닌 다른 도구라면 fork 후 새 디렉터리로 분기 권장. |
0 commit comments