LongCodeBench: Evaluating Coding LLMs at 1M Context Windows (LongCodeBench: 1백만 컨텍스트 창에서 코딩 LLM 평가)

좋은 논문입니다. context 길이에 따른 검색 정확도

​

배경 및 개요

모델의 컨텍스트 길이는 불과 몇 년 만에 수천 토큰에서 수백만 토큰으로 급격히 증가했습니다. 현대 장문맥(long-context) 모델의 극단적인 컨텍스트 크기로 인해 현실적인 장문맥 벤치마크를 구축하는 것이 어려워졌습니다. 이는 수백만 컨텍스트 작업을 수집하는 비용뿐만 아니라 상당한 컨텍스트를 필요로 하는 현실적인 시나리오를 식별하는 데에도 어려움이 있기 때문입니다.

본 연구는 코드 이해 및 복구를 장문맥 모델을 위한 자연스러운 테스트 환경이자 도전 과제로 식별하고, 장문맥 시나리오에서 LLM 코딩 능력을 테스트하기 위한 벤치마크인 LongCodeBench (LCB)를 소개합니다. LCB 벤치마크는 실제 GitHub 이슈에서 도출하고 QA (LongCodeQA) 및 버그 수정 (LongSWE-Bench) 작업을 구성하여 현실적이고 중요한 환경에서 LCLM(Large Context Language Models)의 이해 및 복구 능력을 모두 테스트합니다. 벤치마크의 복잡성을 신중하게 계층화하여 Qwen2.5 14B Instruct부터 Google의 주력 모델인 Gemini에 이르기까지 다양한 규모의 모델을 평가할 수 있도록 했습니다.

연구 결과, 장문맥은 모든 모델에게 여전히 약점이며, Claude 3.5 Sonnet의 경우 29%에서 3%로, Qwen2.5의 경우 70.2%에서 40%로 성능이 저하되는 것으로 나타났습니다.

장문맥 모델링은 전체 코드 저장소 또는 대규모 문서 모음과 같은 확장된 입력을 처리할 수 있는 모델의 잠재력에 의해 동기를 부여받아 활발한 연구 분야로 부상했습니다. 이러한 추세는 업계 주도 모델이 현재 수백만 토큰까지 컨텍스트 창을 지원하는 대규모 컨텍스트 언어 모델(LCLM)의 등장에 반영되어 있습니다. 병행하여 실험적인 아키텍처는 장거리 모델링을 위한 새로운 접근 방식을 계속 탐색하고 있습니다. 그림 1에서 볼 수 있듯이 모델 컨텍스트 길이는 최근 몇 년 동안 초지수적으로 증가하여 이러한 컨텍스트 크기가 효과적인지 여부와 그 방식을 이해하는 것이 중요해졌습니다. 수백만 토큰 LCLM의 평가는 많은 연구가 합성 테스트에 의존하는 등 어려운 과제였습니다.

​

모델별 각 테스트 결과

본 연구는 LongCodeBench(LCB)를 사용하여 다양한 최신 대규모 컨텍스트 언어 모델(LCLM)의 성능을 평가했습니다. 평가는 주로 LongCodeQA (코드 이해)와 LongSWE-Bench (코드 복구) 두 가지 작업에 대해 다양한 컨텍스트 길이(32K, 64K, 128K, 256K, 512K, 1M 토큰)에서 수행되었습니다.

표 3: 다양한 컨텍스트 길이에서 LongCodeQA 및 LongSWE-Bench에 대한 모델 성능

(LongCodeQA는 답변 정확도(%), LongSWE-Bench는 해결된 이슈 비율(%)로 평가됨. 상단은 오픈 소스 모델, 하단은 비공개 소스 모델)

주요 분석 결과 (Analysis):

LongCodeQA 성능 (코드 이해):

대부분의 모델은 짧거나 중간 길이의 컨텍스트(32K–128K)에서 경쟁력 있는 성능을 보였으며, 거의 모든 모델에서 64K와 128K 사이에서 정확도가 최고조에 달했습니다.

Llama 3.1은 64K에서 72.4%로 최대 정확도를 달성했고, GPT-4o는 짧은-중간 범위에서 76.3%로 가장 높은 결과를 보였습니다.

Claude 3.5 Sonnet과 Jamba는 낮은 컨텍스트 창에서 모두 69% 이상의 견고한 성능을 유지했습니다.

Qwen2.5는 32K에서 61.9%로 시작하여 512K에서 70.2%까지 꾸준히 향상되어 긴 컨텍스트에서 안정성을 보였지만, 1M에서는 정확도가 40.0%로 급격히 떨어졌습니다.

GPT-4.1은 작업에서 가장 좋은 결과를 보였으며, 특히 이전 모델인 GPT-4o보다 향상된 성능과 컨텍스트 길이에 따른 일관성을 보여주었습니다.

Llama 4는 Llama 3.1보다 향상되어 더 긴 컨텍스트 창과 64K 및 128K에서 더 나은 성능을 보였습니다.

Gemini 2 Flash, Gemini 1.5 Pro, Gemini 2.5 Pro는 1M까지의 모든 구간에서 63–72% 범위로 매우 안정적인 동작을 보이며 극도로 긴 컨텍스트에서 정확도를 유지했습니다. (그림 3: Gemini 2 Flash의 LongCodeQA 성능을 파일 길이 중앙값 기준으로 나눈 하위 집합 정확도 비교. 긴 파일에서 정확도가 더 높은 경향 관찰)

전반적으로 LongCodeQA는 컨텍스트 길이가 증가함에 따라 모델 성능이 단조롭거나 균일하지 않으며, 여러 모델이 초기에 정점을 찍거나 급격히 성능이 저하되는 것을 보여줍니다.

LongSWE-Bench 성능 (코드 복구):

작업의 어려움(실제 버그 수정은 정확한 코드 패치 필요)으로 인해 LongCodeQA에 비해 결과가 상당히 낮았습니다.

Claude 3.5 Sonnet은 짧은 컨텍스트 길이에서 가장 강력한 성능을 보여 32K에서 29%의 이슈를 해결했습니다. 64K와 128K에서도 비교적 높은 성공률을 유지했지만 256K에서는 3%로 급격히 떨어졌습니다.

Gemini 2 Flash와 GPT-4o는 32K에서 각각 11%와 10%로 정점을 찍고 더 긴 컨텍스트에서 점진적으로 하락했습니다.

Gemini 1.5 Pro는 전체 범위에서 1%에서 6% 사이의 일관되게 낮은 성능을 보였습니다.

Gemini 2.5 Pro는 32K 창에서 23%로 Claude 3.5와 비슷한 성능을 보였고 256K까지 일관된 성공률을 유지하다가 1M에서 7%로 감소했습니다.

오픈 소스 모델은 성능이 훨씬 더 나빴습니다. Jamba는 32K에서 최대 3%의 이슈를 해결했지만 256K에서는 0%로 떨어졌습니다. Qwen2.5, Llama 3.1, Llama 4, GPT-4.1은 테스트된 모든 구간에서 어떤 이슈도 해결하지 못했습니다.

이러한 결과는 생성적 코드 작업의 증가된 어려움과 장문맥 코드 복구에서 오픈 소스 모델과 비공개 소스 모델 간의 현재 격차를 반영합니다. LongSWE-Bench는 현재 LCLM의 장문맥 설정에서의 한계를 드러냅니다.

일반적인 관찰:

파일 길이 대 성능: LongCodeQA의 각 구간에서 평균 파일 길이 중앙값을 기준으로 두 하위 집합으로 나누어 Gemini 2 Flash의 정확도를 평가한 결과, 더 긴 파일이 6개 구간 중 5개에서 더 높은 정확도와 연관되어 있음을 관찰했습니다. 이는 더 긴 파일이 일반적으로 더 복잡하고 성능 저하를 유발할 것으로 예상되는 것과는 반대되는 결과입니다. 512K 구간에서는 성능 차이가 거의 40%에 달했습니다. (그림 3)

주제별 성능 (Topics): LongCodeQA에서 가장 빈번한 6개 주제에 대한 Gemini 1.5 Pro의 성능을 방사형 파이 차트로 시각화했습니다. “소프트웨어 개발”이 가장 큰 부분(265개 샘플)을 차지하며 70.9%의 정확도를 보였고, “데이터베이스”는 가장 높은 정확도(84.2%)를 달성했지만 빈도는 낮았습니다(38개 샘플). 전반적으로 정확도는 평균 70% 주변에서 변동하여 저장소 도메인에 관계없이 모델의 비교적 안정적인 성능을 반영했습니다. (그림 4)

테스트 데이터 셋 목록 및 내용

LongCodeBench (LCB)는 코드 이해 및 복구라는 두 가지 주요 작업을 통해 장문맥 시나리오에서 코딩 LLM을 평가하기 위해 제안된 새로운 벤치마크입니다. 모든 데이터는 공개 GitHub 저장소에서 가져왔습니다.

​

1. LongCodeQA (코드 이해 작업):

작업 정의: 장문맥 시나리오에서 모델의 코드 이해 능력을 테스트하는 객관식 질문 작업입니다. 각 질문은 공개 GitHub Python 저장소에서 파생되어 실제 소프트웨어 엔지니어링 시나리오에 기반한 벤치마킹을 제공합니다.

데이터 수집:

저장소 선택: GitHub REST API를 통해 닫힌 GitHub 이슈에서 질문을 수집합니다. 총 토큰 길이를 기준으로 저장소를 선택하여 다양한 컨텍스트 길이 구간에 걸쳐 일관된 샘플 분포를 보장합니다. 공개적으로 사용 가능한 이슈가 많은 저장소를 우선시합니다.

이슈 필터링: LLM(GPT-4)을 활용하여 버그 수정, 새 기능 추가, 설치 문제, 프로젝트 로드맵 또는 개발 관행과 관련된 사례를 필터링합니다.

질문 변환: 선택된 이슈에 대해 LLM이 구조화된 출력을 사용하여 객관식 질문으로 변환하도록 지시합니다.

데이터 오염 방지: 컨텍스트 없이 GPT-4에 각 질문에 답변하도록 요청하고, 모델이 내부 지식만으로 성공한 질문은 필터링합니다. 모든 반복 후 초기 이슈의 3.99%만이 적절한 질문으로 변환됩니다.

최종 질문 생성: 이슈, 정답, 나머지 세 개의 오답에서 특정 질문을 생성합니다.

데이터 검증:

신뢰성: 각 컨텍스트 길이 구간에 대해 9개 질문의 계층화된 무작위 하위 집합에 대한 수동 검증을 수행합니다. 선택된 54개 질문 중 52개(96.3%)가 성공적으로 답변하기 위해 저장소 및 내부 코드베이스에 대한 심층 조사가 필요함을 확인했습니다.

공정성: 전체 코드베이스를 참조하지 않고 이슈 “토론”만 사용하여 모든 질문을 생성합니다.

데이터셋 통계 (표 2 상단):

총 98개 공개 GitHub 저장소에서 가져온 443개의 질의응답 인스턴스로 구성됩니다.

컨텍스트 길이 구간별 인스턴스 수: 32K(113), 64K(76), 128K(92), 256K(65), 512K(47), 1M(50)

저장소당 평균 파일 수 및 파일당 평균 토큰 수는 컨텍스트 길이에 따라 다양합니다.

​

2. LongSWE-Bench (코드 복구 작업):

작업 정의: 실제 환경에서 모델의 코드 복구 능력을 테스트하며, 특히 버그 수정 작업을 대상으로 합니다. 각 인스턴스는 공개 Python 저장소의 실제 GitHub 이슈에서 파생되며, 모델은 여러 저장소 파일로 구성된 장문맥 입력을 고려하여 코드베이스 오류를 수정해야 합니다.

데이터 수집 (3단계 반복적 정제):

저장소 선택: 품질 및 크기 기준을 충족하는 공개 Python GitHub 저장소를 선택합니다. 보고된 이슈가 많고 활발한 개발 주기를 가진 저장소를 우선시합니다.

이슈 필터링: 풀 리퀘스트를 통해 해결된 이슈를 필터링합니다. 명시적인 테스트 케이스가 없거나 명확한 버그 수정보다는 리팩토링과 관련된 이슈는 제외합니다. 단위 테스트를 사용할 수 있는 이슈로 선택을 제한합니다.

수동 필터링: 문제에 대한 명확한 설명과 제공된 정보 내에 잘 정의된 솔루션이 포함된 잘 구성된 샘플만 남기고, 기능 요청이나 모호한 버그 보고서는 제외합니다.

데이터 검증:

신뢰성: 벤치마크의 모든 인스턴스를 수동으로 평가하여 잘 구성되고 명확하도록 합니다.

재현성: 각 이슈를 복제하기 위한 전용 실행 환경을 만듭니다. 패치를 적용하기 전에 버그 존재를 확인하고 올바른 종속성을 설치하는 인스턴스별 전용 Docker 이미지를 만듭니다.

데이터셋 통계 (표 2 하단):

6개의 컨텍스트 길이 구간(32K ~ 1M)에 걸쳐 균등하게 분포된 600개의 버그 수정 인스턴스로 구성되며, 각 구간당 100개의 인스턴스가 있습니다.

이 인스턴스들은 61개의 공개 Python 저장소에서 샘플링되었습니다.

저장소 구성(파일 수 및 파일당 평균 토큰 길이)도 분석됩니다.

LCB 데이터셋 공개: https://huggingface.co/datasets/Steefano/LCB

연구 방법론 및 결론

1. 연구 방법론

LongCodeBench (LCB) 구축:

목표: 최대 1백만 토큰의 컨텍스트 창에서 실제 코딩 작업에 대한 장문맥 언어 모델(LCLM)을 평가하는 포괄적인 벤치마크를 만듭니다.

두 가지 핵심 작업:

LongCodeQA (코드 이해): GitHub 이슈에서 파생된 객관식 질문에 답변하여 코드베이스 이해도를 평가합니다.

LongSWE-Bench (코드 복구): 실제 GitHub 버그를 수정하는 코드 패치를 생성하여 코드 복구 능력을 평가합니다.

데이터 소스: 공개 GitHub 저장소.

핵심 원칙: 확장성(Scalability), 현실성(Realism), 장문맥(Long-context).

컨텍스트 길이 다양화: 32K, 64K, 128K, 256K, 512K, 1M 토큰의 여러 규모에서 평가를 제공하여 장문맥 행동에 대한 세분화된 분석을 가능하게 합니다.

평가 대상 모델 (LCLM 선택):

다양한 오픈 소스 및 비공개 소스 모델을 포함하여 컨텍스트 창이 최대 1M 토큰인 모델을 평가합니다.

선택 기준: 전반적인 성능, 최대 컨텍스트 길이, 아키텍처 다양성.

포함된 모델 예시: GPT-4o, GPT-4.1, Claude 3.5 Sonnet, Gemini 시리즈 (2 Flash, 1.5 Pro, 2.5 Pro), Qwen2.5–14B-Instruct, Jamba 1.5 400B Large, Llama 3.1 405B Instruct, Llama 4 Scout.

평가 지표:

LongCodeQA: 정확도 (정답 응답 비율).

LongSWE-Bench: 해결된 이슈 비율 (단위 테스트 통과 기준).

분석:

컨텍스트 길이에 따른 모델 성능 변화 추이 분석.

모델 아키텍처 및 크기에 따른 성능 비교.

파일 길이 및 주제와 같은 데이터 특성이 모델 성능에 미치는 영향 분석.

​

2. 결론

본 연구는 최대 1백만 토큰 창까지 실제 코딩 작업에 대한 장문맥 언어 모델을 평가하는 포괄적인 벤치마크인 LongCodeBench를 소개합니다. GitHub에서 가져온 코드 이해 및 복구 작업을 결합함으로써, LCB는 장문맥 입력에 대한 모델 성능을 평가하기 위한 확장 가능하고 현실적인 프레임워크를 제공합니다. 연구 결과, 현재 LCLM은 규모에 따라 성능이 저하되는 경우가 많아 주장된 컨텍스트 능력과 효과적인 컨텍스트 능력 사이에 격차가 있음을 보여줍니다. LCB는 이러한 과제를 강조하고 현실적인 소프트웨어 엔지니어링 환경에서 장문맥 모델링을 발전시키기 위한 토대를 제공합니다.

​

시사점

LongCodeBench의 도입과 이를 통한 LCLM 평가는 다음과 같은 중요한 시사점을 제공합니다.

장문맥 능력의 현실적 검증 필요성: 모델이 이론적으로 지원하는 컨텍스트 길이와 실제 복잡한 작업에서 효과적으로 활용할 수 있는 컨텍스트 능력 사이에는 괴리가 존재합니다. LCB와 같은 현실적인 벤치마크는 이러한 괴리를 측정하고 모델의 실제 장문맥 처리 능력을 평가하는 데 중요합니다.

코드 이해와 복구 능력의 상호 보완적 평가: LCB는 코드 이해(LongCodeQA)와 코드 복구(LongSWE-Bench)라는 두 가지 상호 보완적인 작업을 통해 LCLM의 코딩 능력을 다각도로 평가합니다. 이는 모델이 단순히 정보를 찾는 것을 넘어, 실제 코드베이스를 수정하고 개선하는 능력을 갖추었는지 확인하는 데 도움이 됩니다.

컨텍스트 길이에 따른 성능 저하 현상 확인: 대부분의 LCLM이 컨텍스트 길이가 증가함에 따라 성능 저하를 겪는다는 결과는, 현재 장문맥 처리 기술이 아직 완벽하지 않으며 “가운데 있는 것을 잃어버리는(lost in the middle)” 현상 등이 여전히 중요한 과제임을 시사합니다.

오픈 소스 모델과 비공개 소스 모델 간의 격차: 특히 코드 복구와 같이 더 어려운 생성 작업에서는 비공개 소스 모델(예: Claude 3.5 Sonnet, Gemini 2.5 Pro)이 오픈 소스 모델보다 우수한 성능을 보이는 경향이 나타났습니다. 이는 장문맥 추론 및 코드 생성 능력에서 두 그룹 간의 기술 격차가 존재함을 의미할 수 있습니다.

데이터셋 구성 원칙의 중요성 (현실성, 확장성, 장문맥): LCB는 실제 GitHub 데이터를 기반으로 현실적인 작업을 구성하고, 다양한 컨텍스트 길이를 포괄하며, 최대 1백만 토큰까지 확장 가능한 평가를 제공함으로써 장문맥 LCLM 연구에 필요한 견고한 기반을 마련했습니다.

향후 LCLM 발전 방향 제시: LCB를 통해 드러난 현재 LCLM의 장문맥 처리 약점(예: 긴 컨텍스트에서의 성능 저하, 특정 작업에서의 낮은 성공률)은 향후 모델 아키텍처 개선, 학습 방법론 개발, 그리고 장문맥 데이터 처리 효율성 향상 연구의 필요성을 강조합니다.

벤치마크의 공개 및 투명성: LCB 데이터셋을 공개적으로 사용할 수 있도록 함으로써, 연구 커뮤니티가 LCLM의 장문맥 코딩 능력을 투명하게 평가하고 비교하며 관련 연구를 발전시키는 데 기여할 것입니다.

결론적으로 LongCodeBench는 LCLM의 실제 장문맥 코딩 능력을 측정하는 데 중요한 도구이며, 이 분야의 연구와 개발을 촉진하는 데 기여할 것으로 기대됩니다.

LongCodeBench #CodingLLM #LongContext #CodeComprehension #CodeRepair #Benchmark

롱코드벤치 #코딩LLM #장문맥 #코드이해 #코드복구 #벤치마크

​

​

출처 : https://arxiv.org/pdf/2505.07897