ML evaluation · Developer tool
PatchCheck
Coding agent가 만든 patch는 자연스러워 보여도 요구사항을 놓치거나 주변 코드를 깨뜨릴 수 있습니다. PatchCheck는 작은 verifier로 사람이 먼저 볼 PR을 고르는 실험입니다.
- 담당
- 개인 프로젝트 · 데이터, QLoRA 학습, 평가와 GitHub Action
- 공개 범위
- 공개 저장소
- 기술
- Qwen2.5-Coder-7B · QLoRA · PyTorch · Modal · GitHub Actions
Actual product
실제 동작
이 5개 PR은 GitHub Action과 Modal 연동이 실제 리뷰 흐름에서 동작하는지 보여 주는 배포 데모입니다. 일반화 성능을 평가하는 별도 벤치마크로 해석하지 않습니다.
03
#17 · flake8-comprehensions의 C416 false positive
GitHub기준 라벨 SAFE · 모델 신호 LOWER · 안전한 변경을 낮은 검토 우선순위로 분류했습니다.
추가 실행 사례
- 실행 결과가 포함된 학습 patch
- 11,742
- 익숙한 held-out ROC-AUC
- 0.8200
- 새 저장소 OOD ROC-AUC
- 0.7479
- 새 agent OOD ROC-AUC
- 0.6751
01
Context
Coding agent의 patch는 그럴듯해 보여도 요구사항을 일부만 해결하거나 인접 경로를 깨뜨릴 수 있습니다. 더 큰 LLM을 다시 호출하는 대신, issue와 candidate diff만 보는 작은 모델이 리뷰 순서를 정하는 데 쓸 만한 신호를 내는지 확인했습니다.
익숙한 held-out 점수만으로는 실제 리뷰 도구를 설명할 수 없습니다. 새 저장소, 학습에 없던 agent family, 크기가 비슷한 SAFE/UNSAFE pair와 외부 데이터까지 같은 protocol로 평가했습니다. 이 모델은 patch correctness를 판정하거나 PR을 자동 승인하지 않습니다.
02
Engineering
Qwen2.5-Coder-7B-Instruct에 QLoRA adapter를 학습하고 입력은 issue description과 candidate diff로 제한했습니다. 같은 frozen 7B 모델의 zero-shot 결과를 control로 사용해 fine-tuning 효과를 비교했습니다.
verifier는 PASS와 REVIEW의 sequence likelihood 차이를 risk percentile로 바꿉니다. 별도 CPU analyzer는 API, auth, dependency, exception, secret-like change와 test coverage를 검사합니다. GitHub Action에서는 CPU 검사를 실행하고, GPU 모델 추론은 maintainer-gated Modal endpoint에서 수행합니다.
내가 맡은 일
- training population과 고정된 evaluation split을 구성하고 QLoRA 학습과 inference 경로를 구현했습니다.
- familiar, repository OOD, agent-family OOD, same-task hard match와 external review 평가를 설계했습니다.
- GitHub workflow가 base/head SHA의 diff를 수집하도록 했고, diff가 없거나 너무 크면 모델 점수를 내지 않도록 구현했습니다.
주요 기술 판단
같은 base model을 control로 사용
다른 모델과 비교하지 않고 prompt, tokenizer와 score definition을 고정했습니다. 그래야 fine-tuning 자체가 바꾼 부분을 볼 수 있습니다.
크기 shortcut을 통제한 hard set
1,000개의 same-task SAFE/UNSAFE pair에서 changed-file count와 patch size를 비슷하게 맞췄습니다. 큰 patch를 위험하다고 보는 단순한 shortcut만으로 점수가 나오지 않게 했습니다.
모델 점수와 정적 검사 결과를 따로 표시
모델의 순위 신호와 코드에서 직접 찾은 항목은 의미가 다릅니다. 하나의 correctness probability처럼 합치지 않고 리뷰 화면에서 각각 보여 줍니다.
03
Validation
익숙한 데이터에서 새 저장소와 새 agent로 갈수록 ROC-AUC가 낮아졌습니다. shortcut-controlled hard cases는 0.5972, external set은 0.6540이었습니다. 모든 split에서 같은 frozen zero-shot control보다 높았지만, external unsafe PR-AUC의 confidence interval은 0을 포함해 결정적인 개선으로 주장하지 않았습니다.
불확실성은 frozen seed-17 prediction에 10,000회 paired nonparametric bootstrap을 적용해 측정했습니다. 이는 evaluation sample uncertainty이며 training seed variance는 포함하지 않습니다.
확인한 결과
- hard-case verifier는 structural shortcut baseline 0.4974와 metadata baseline 0.5011보다 높았습니다. 측정한 shortcut만으로 모델 결과를 설명할 수 없다는 뜻입니다.
- 제품에는 correctness probability 대신 frozen reference distribution을 기준으로 LOWER, ELEVATED, HIGH 리뷰 우선순위만 표시합니다.
실패와 변경
- 모델 점수와 정적 검사 결과를 합치자 shortcut-controlled unsafe PR-AUC가 0.5900에서 0.5150으로 낮아졌습니다. 결합 점수를 폐기하고 두 결과를 제품에서 따로 보여 주도록 바꿨습니다.
추후 발전 방향
- 현재 모델은 issue와 diff만 보기 때문에 저장소 실행 상태나 숨은 test harness 결과를 알 수 없습니다. CI 실행 결과와 정적 분석 신호를 별도 근거로 연결해 리뷰어가 모델 점수와 실제 실행 실패를 함께 보게 하는 방향이 필요합니다.
- 외부 review set의 개선 폭은 작고 일부 confidence interval은 0을 포함합니다. 저장소와 agent별 평가셋을 더 확보해 calibration을 다시 확인하기 전까지는 auto-approve나 auto-merge가 아니라 검토 순위 추천으로 유지해야 합니다.