SWE-QA: Can Language Models Answer Repository-level Code Questions?

다음은 논문 "SWE-QA: Can Language Models Answer Repository-level Code Questions?"에 대한 상세한 기술 요약입니다.

1. 문제 제기

현재의 대규모 언어 모델 (LLM) 은 코드 이해 분야에서 유망한 성과를 보였으나, 기존 벤치마크 (예: CoSQA, CodeQA) 는 주로 고립된 코드 스니펫, 함수, 또는 API 에 집중하고 있습니다. 이러한 설정은 실제 소프트웨어 공학의 복잡성을 포착하지 못합니다. 실제 개발자들은 다음과 같은 작업을 수행해야 하기 때문입니다:

• 여러 파일에 걸친 대규모 상호 연결된 코드베이스를 탐색합니다.
• 소프트웨어 아키텍처와 설계 근거를 이해합니다.
• 장거리 의존성을 추적하고 다중 홉 (multi-hop) 추론을 수행합니다.
• 복잡한 "왜 (Why)" 및 "어떻게 (How)" 질문에 답하기 위해 아키텍처 지식을 종합합니다.

심층적인 다중 파일 컨텍스트와 구조적 이해를 요구하는 저장소 수준 (repository-level) 질문 응답 (QA) 을 평가하는 고품질 인간 검증 벤치마크는 부족합니다.

2. 방법론: SWE-QA 벤치마크 구축

저자들은 15 개의 다양한 Python 저장소 (SWE-Bench 에서 12 개, SWE-Bench-Live 에서 3 개) 를 포함하는 4 단계 파이프라인 (그림 2) 을 통해 구축된 저장소 수준 코드 QA 벤치마크인 SWE-QA를 제안합니다.

A. 시드 수집 및 분류 체계 구축

• 데이터 소스: 12 개의 인기 있는 저장소에서 77,100 개의 GitHub 이슈를 크롤링했습니다.
• 필터링: 1,000 자 이상의 실질적인 내용을 가진 41,955 개의 이슈를 선정하고, LLM 을 사용하여 127,415 개의 명시적 코드 관련 질문을 추출했습니다.
• 분류 체계: 3 년 이상의 경험을 가진 두 명의 인간 전문가가 1,000 개의 샘플 질문을 수동으로 분석하여 2 단계 분류 체계를 작성했습니다:
  • 1 단계 (의문사): What, Why, Where, How.
  • 2 단계 (의도): 의존성 추적, 설계 근거, 기능 위치, 알고리즘 구현 등 12 가지 세분화된 카테고리.
• 분포: "How" 질문 (35.2%) 과 "Where" 질문 (28.4%) 이 가장 빈번하여 절차적 및 위치적 지식의 필요성을 반영합니다.

B. 질문 구체화

• 컨텍스트 추출: tree-sitter 를 사용하여 저장소 구조를 타입이 지정된 그래프 (노드: 클래스, 메서드, 파일; 엣지: 호출, 임포트) 로 파싱했습니다.
• 생성: 초점 요소 (예: 특정 클래스) 를 선택하고 분류 체계에서 파생된 시드 템플릿과 구조적 컨텍스트를 결합했습니다.
• 프로세스: LLM 이 특정 저장소에 맞춘 후보 질문을 생성하여 다중 홉 추론이 필요하고 단순 검색으로는 답할 수 없도록 보장했습니다.

C. 답변 수집 및 검증

• RAG 파이프라인: 관련 코드 스니펫, 문서, 메타데이터를 검색하는 검색 증강 생성 (RAG) 방식을 사용하여 답변을 생성했습니다.
• 인간 개입 (Human-in-the-Loop):
  • 전문가 수정: 두 명의 시니어 개발자가 Cursor 와 같은 도구를 사용하여 각 답변의 사실적 정확성, 완전성, 명확성을 검토했습니다. 이견은 세 번째 전문가가 해결했습니다.
  • 품질 필터링: 모호하거나 사실적으로 부정확하거나 코드에 대한 충분한 근거가 없는 쌍은 폐기되었습니다.
• 최종 데이터셋: 13,300 개의 파일과 340 만 줄 이상의 코드를 아우르는 720 개의 고품질 QA 쌍 (저장소당 48 개) 입니다.

3. 주요 기여

1. SWE-QA 벤치마크: 15 개의 Python 저장소에 걸친 720 개의 인간 검증 QA 쌍을 갖춘 저장소 수준 QA 벤치마크입니다. 이는 다중 홉 추론, 파일 간 의존성, 아키텍처 이해를 독창적으로 결합합니다.
2. 유연한 생성 파이프라인: 시드 템플릿과 정적 코드 분석을 사용하여 새로운 오픈소스 저장소에 대한 QA 데이터셋을 반자동으로 생성할 수 있는 모듈식 프레임워크입니다.
3. 포괄적 평가: 다양한 컨텍스트 증강 전략 (직접 프롬프팅, RAG, 에이전트 프레임워크) 하에서 LLM 에 대한 엄격한 평가입니다.

4. 실험 결과

저자들은 다양한 전략을 사용하여 6 개의 고급 LLM(GPT-5.1, Gemini 2.5 Pro, GLM-4.6, Qwen3-Coder 포함) 을 평가했습니다:

• 컨텍스트 증강 영향:
  • 직접 프롬프팅: 성능이 저조했습니다 (예: Kimi K2 는 약 51/100 점). 이는 저장소 컨텍스트의 필요성을 강조합니다.
  • RAG(슬라이딩 윈도우/함수 청킹): 성능을 크게 향상시켰습니다 (예: +10~14 점).
  • 에이전트 프레임워크 (OpenHands, SWE-agent): 반복적 추론과 도구 사용을 가능하게 하여 최고의 결과를 달성했습니다. OpenHands 와 GPT-5.1은 70.79/100이라는 최고 점수를 기록했습니다.
• 모델 성능:
  • GPT-5.1과 GLM-4.6(OpenHands 사용) 이 가장 앞섰습니다.
  • 작은 모델들 (예: Qwen3-30B) 은 에이전트 프레임워크에서 어려움을 겪었으며, RAG 와 비슷하거나 더 낮은 성능을 보여 장기 기억 및 도구 계획의 한계를 시사합니다.
  • 상용 도구 (Cursor, Tongyi Lingma) 는 경쟁력 있는 성능 (69~70) 을 보여 종단간 도구 증강 솔루션의 유효성을 입증했습니다.
• 분류 체계 분석:
  • 모델은 문서화에 명시적으로 정보가 포함된 API 지원과 관련된 "Why"(설계 근거) 질문과 "How" 질문에서 뛰어난 성능을 보였습니다.
  • 파일 간에 분산된 논리를 재구성해야 하는 "What"(아키텍처 탐색) 과 "Where"(기능 위치) 질문에서는 어려움을 겪었습니다.
• 저장소 간 일반화:
  • 성능은 저장소 복잡성에 따라 다양했습니다. "Flask"가 가장 쉬웠고 (75.42), "Pylint"(62.01) 와 "Conan"(64.51) 이 가장 어려웠습니다.
  • SWE-Bench-Live(데이터 누출이 적음) 의 저장소는 SWE-Bench 의 저장소보다 더 어려웠습니다.

5. 의의 및 향후 방향

• 현실적인 평가: SWE-QA 는 스니펫 수준 테스트를 넘어 실제 소프트웨어 공학 작업에 필요한 "전체 저장소" 이해를 평가합니다.
• 에이전트 프레임워크: 결과는 RAG 가 도움이 되지만, 토큰 비용이 더 높음에도 불구하고 에이전트 기반 프레임워크가 현재 복잡한 다중 파일 코드베이스를 탐색하는 데 가장 효과적인 접근법임을 시사합니다.
• 한계: 현재 벤치마크는 Python 전용이며 정적 스냅샷에 기반합니다. 향후 연구는 다른 언어와 동적이며 진화하는 저장소로 확장하는 것을 목표로 합니다.
• 열린 과제: 논문은 LLM 이 여전히 심층 의존성 추적 및 정밀한 위치 추론에서 어려움을 겪고 있음을 강조하며, 더 나은 코드 그래프 통합 및 추론 능력의 필요성을 지적합니다.

이 논문은 에이전트와 결합될 때 특히 저장소 수준 QA 에서 LLM 이 유망한 성과를 보이지만, 복잡한 다중 홉 의존성과 아키텍처 추론을 처리하는 데에는 여전히 상당한 과제가 남아 있다고 결론지었습니다.