Natural Language Processing

[2025-2] 김민정 - Are Large Language Models Memorizing Bug Benchmarks?

덥프 2025. 9. 6. 12:51

2411.13323v3.pdf
1.20MB

1. Introduction

  • LLM은 코드 생성, 버그 탐지, 자동 프로그램 수리(APR) 등 소프트웨어 엔지니어링 분야에서 중요한 역할을 함.
  • 이를 평가하기 위해 Defects4J, BugsInPy, SWEBench 같은 버그 벤치마크가 널리 사용됨.
  • 그러나 이 벤치마크들은 오래전부터 공개되어 있어, 학습 데이터에 포함되었을 가능성이 높음. → Data leakage 위험
  • 벤치마크 데이터가 이미 모델 학습에 포함되었다면, 모델의 성능이 실제 능력이 아니라 암기 효과로 보일 수 있음.
  • LLM이 버그 벤치마크를 암기하고 있는가?

2. Methodology

  • 데이터 수집: 주요 버그 벤치마크(Defects4J, BugsInPy, BugsCpp, GitBug-Java, SWEBench-Lite)와 2024년 GitHub 신규 저장소
  • 모델 선택: CodeGen, CodeLLaMa, LLaMa 3.1, StarCoder 2, Gemma 2, CodeGemma, Mistral 등 대표적인 오픈소스 코드 LLM
  • 평가 지표:
    1. Membership – TheStack 데이터셋 포함 여부 확인
    2. Negative Log Likelihood (NLL) – 모델이 코드에 얼마나 익숙한지
    3. 5-gram Accuracy – 연속된 토큰 시퀀스를 얼마나 정확히 재현하는지

3. Results

(1) Membership

  • Defects4J와 SWEBench-Lite는 80% 이상이 TheStack에 포함. → 높은 누출 가능성
  • GitBug-Java는 가장 낮은 포함률 → 새로운 벤치마크로 적합.

(2) Negative Log Likelihood

  • CodeGen-multi는 Defects4J에서 NLL 0.15 → 강력한 암기 증거
  • 최신 모델(LLaMa 3.1)은 전반적으로 균일한 NLL → 특정 벤치마크에 치우치지 않음.

(3) 5-gram Accuracy

  • CodeGen-multi: Defects4J에서 82% 일치 → 벤치마크 솔루션을 그대로 재현.
  • GitBug-Java 및 신규 GitHub repo: 40~50% 수준 → 일반적인 코드 패턴 인식으로 해석.
  • LLaMa 3.1은 전반적으로 낮고 균일한 수치 → 덜 암기된 경향.

4. Discussion

  • Defects4J는 LLM 암기 현상의 대표 사례 → 더 이상 공정한 평가 지표로 보기 어려움.
  • BugsInPy, BugsCpp 같은 비교적 최신 벤치마크는 누출 위험이 상대적으로 낮음.
  • 최신 모델(LLaMa 3.1)은 더 큰 데이터와 다양한 학습으로 특정 벤치마크 편향이 줄어듦.
  • 연구자들은 NLL, n-gram, 데이터셋 중복 여부를 함께 고려해 모델을 평가해야 한다고 강조.
  • 평가 시 구형 벤치마크 + 신형 벤치마크 병행 필요.

5. Limitations and Threats

  • 신규 GitHub 데이터셋도 완벽히 누출이 배제되었다고 보장하기 어려움.
  • 패치 파일과 버그 파일이 유사해도 높은 정확도가 나올 수 있음 → 해석 주의 필요.
  • 파인튜닝 과정에서 forgetting이 일어나기도 하지만, 대규모 모델일수록 오히려 암기 성향이 강해질 수 있음.
  • 따라서 누출 위험은 완전히 제거하기 어렵고, 지속적 모니터링 필요.
  • 향후에는 데이터 누출을 최소화한 새로운 평가 프레임워크 필요.

6. Conclusion

해당 논문은  LLM이 버그 벤치마크를 외우고 있다고 주장하며, 특히 오래된 Defects4J는 이미 누출 위험이 매우 높아 평가에 적합하지 않으며, 연구자들은 반드시 새로운 벤치마크와 다양한 지표를 활용해야 한다는 점을 강조한다.

  • Defects4J는 LLM에 의해 강하게 암기되어 평가에 부적절.
  • GitBug-Java, BugsInPy, BugsCpp 같은 새로운 벤치마크는 누출 위험이 낮아 공정한 평가에 더 적합.
  • NLL, 5-gram accuracy, membership 분석을 통해 벤치마크 누출 여부를 점검하는 절차가 필요.
  • 앞으로는 구형 벤치마크와 신형 벤치마크를 병행, 데이터 누출을 고려한 공정한 평가 프레임워크를 구축해야 함.

7. Fair Evaluation 연구와 연결 포인트

(1) 벤치마크 적합성 논의

  • 오래된 벤치마크는 이미 학습 데이터에 포함될 확률이 높음 → 공정한 평가 도구로서 부적절.
  • 논문에서 제안한 방법(NLL, 5-gram, membership check)은 벤치마크 선정 시 필수 점검 절차로 활용 가능.
    → LLM 평가 논문에서 “벤치마크를 선택하기 전에 누출 여부를 진단해야 한다”는 근거로 활용.

(2) 평가 지표 다양화

  • 기존 LLM 평가 연구는 성능 지표(정확도, Pass@k 등)에만 집중 → 데이터 누출 여부는 무시하는 경우 많음.
  • 이 논문은 메타-평가 지표(benchmark contamination risk metric)를 제안.
    → "단일 성능 수치가 아닌, 누출 지표를 함께 제시해야 한다”는 주장을 강화하는 데 활용 가능.

(3) 모델 공정성 vs. 크기/데이터 효과

  • 결과적으로, 더 큰 모델 + 더 많은 학습 데이터 → NLL 감소 + n-gram 정확도 상승 → 암기 위험 증가.
  • 그러나 LLaMa 3.1처럼 최신 모델은 다양한 데이터로 학습해 특정 벤치마크에 편향되지 않음.
    → “모델 크기·데이터량 차이가 평가 결과에 불공정한 우위를 줄 수 있다”는 논의 근거가 됨.

(4) 새로운 벤치마크 필요성

  • GitBug-Java, BugsCpp 같은 최근/미포함 데이터셋은 누출 위험이 낮음.
    → “평가의 공정성을 확보하려면 최신·검증된 데이터셋을 병행해야 한다”는 논리로 확장 가능.