기술 요약: LibEvoBench

문제 정의

현대 소프트웨어 개발은 독립적으로 진화하는 제3자 라이브러리에 크게 의존하며, 이로 인해 프로덕션 코드베이스가 구버전의 API에 고정되는 현상이 빈번히 발생합니다. 이는 API 호출의 정확성이 라이브러리 일반에 대한 지식이 아니라, 프로젝트의 의존성 매니페스트에 명시된 정확한 버전에 따라 결정되는 "버전 특정적 개발 컨텍스트(version-specific development development context)"를 생성합니다.

현재의 대규모 언어 모델(LLM)은 여러 라이브러리 버전의 코드와 문서를 동시에 집계하는 시계열적으로 혼합된 코퍼스로 학습됩니다. 학습 목표는 이러한 이질적인 자료를 명시적인 시간적 계층화 메커니즘 없이 단일한 가중치 세트로 압축합니다. 결과적으로 LLM은 버전별 추론에 어려움을 겪으며, 이는 **시대착오적 오류(anachronistic errors)**로 이어집니다. 즉, 요청된 라이브러리 버전과는 다른 버전에 유효한 코드를 생성하게 됩니다. 이전 연구들이 일반적인 사실 영역에서의 시간적 지식을 다루었으나, 버전 인식 코드 생성은 별개의 도전 과제를 제시합니다. 모델은 대상 환경에 대해 문법적으로는 유효하지만 의미론적으로는 틀린 코드를 생성하는 것을 방지하기 위해, 동일한 API의 여러 공존하는 버전을 구분할 수 있어야 합니다.

방법론

LibEvoBench 벤치마크

저자들은 널리 사용되는 Python 라이브러리(PyTorch, NumPy, SciPy)에 걸쳐 버전 인식 API 지식을 평가하기 위해 설계된 멀티태스크 벤치마크인 LibEvoBench를 소개합니다. 이 벤치마크는 29개의 라이브러리 버전에 걸쳐 125,000개 이상의 평가 인스전스를 포함합니다.

벤치마크 구축 파이프라인은 완전히 자동화되어 있습니다:

1. 데이터 수집: requirements.txt 파일이 고정된 공개 GitHub 저장소를 마이닝하여 실제 세계의 코드 컨텍스트를 수집합니다.
2. API 표면 재구성: 공식 Sphinx 문서 인벤토리와 직접적인 런타임 검사를 사용하는 두 가지 상호 보완적인 소스를 사용하여 각 버전의 공개 API 표면을 재구성합니다. 두 소스가 모두 일치하는 경우에만 API가 존재하는 것으로 간주하여 결정론적인 그라운드 트루스를 생성합니다.
3. API 분류: 호환성 매트릭스를 기반으로 API를 Stable(버전 간 시그니처가 변경되지 않음) 또는 Evolving(추가, 삭제 또는 수정됨)으로 분류합니다.

평가 태스크

LibEvoBench는 세 가지 뚜렷한 모달리티의 지식을 평가합니다:

1. API 호출 (API-C): 불완전한 코드 스니펫이 주어졌을 때, 모델은 누락된 API 호출을 생성해야 합니다. 이 태스크는 서로 다른 능력을 격리하기 위해 네 가지 노이즈 감소 수준(L0–L3)을 사용합니다:
   • L0: 순수 코드 컨텍스트만 제공.
   • L1: 코드 + 편집된 독스트링 (회상과 검색을 분리).
   • L2: 코드 + 독스트링 + 명시적 버전 제약 조건 (버전 인식을 테스트).
   • L3: API 이름 + 버전 (세밀한 파라미터 회상을 테스트).
2. API 식별 (API-I): 모듈 경로와 편집된 설명이 주어졌을 때, 모델은 올바른 API 이름을 식별해야 합니다. 이는 구성적 추론으로부터 선언적 지식을 격리합니다.
3. 시그니처 회상 (SR): 전체 경로가 포함된 API 이름과 대상 버전만 주어졌을 때, 모델은 메모리로부터 완전한 함수 시그니처를 재현해야 합니다. 이는 인자, 기본값 및 순서에 대한 파라미터 지식을 조사합니다.

환각 분류 체계 (Hallucination Taxonomy)

버전 인덱싱된 API 표면을 기준으로 모델 오류를 분류하기 위한 새로운 결정론적 분류 시스템이 도입되었습니다:

• Correct (정확): 대상 버전의 그라운드 트루스와 일치함.
• Unknown (알 수 없음): 예측된 심볼이 관찰된 어떤 버전에도 존재하지 않음 (조작/Fabrication).
• Invalid (유효하지 않음): 심볼이 대상 버전에 존재하지만 의도한 것이 아님 (검색 혼동).
• Anachronistic (시대착오적): 심볼이 라이브러리의 이력에는 존재하지만 요청된 버전에는 존재하지 않음 (시간적 혼동). 이 카테고리는 모델이 존재하지 않는 심볼을 환각하는 것이 아니라 버전을 혼동하는 오류를 구체적으로 격리합니다.

소프트웨어 진화 이해 점수 (SEUS)

성능을 집계하기 위해 저자들은 불일치와 시대착오를 페널티로 부여하는 복합 지표인 SEUS를 제안합니다. 이는 다음 요소에 의해 조정된 Stable 및 Evolving API 점수의 조화 평균으로 계산됩니다:

• 안정성 페널티 (Stability Penalty): Evolving API의 다양한 버전 간 성능 편차에 대해 페널티를 부여합니다.
• 시대착오 페널티 (Anachronism Penalty): 시대착오적 예측 비율에 대해 페널티를 부여합니다.

주요 결과

저자들은 프런티어 프라이머리 모델(OpenAI GPT-4.1 ~ GPT-5.5, Anthropic Claude Sonnet 4/4.6, Google Gemini 2.0/2.5/3 Flash)과 오픈 웨이트 Qwen-3.5 제품군(35B, 122B, 397B)을 평가했습니다.

1. 버전 망각 (Version-Obliviousness): 최첨단 모델들은 대체로 버전 인식 능력이 결여되어 있습니다. Evolving API에 대한 성능은 라이브러리 버전이 최신이 될수록 크게 저하되는 반면, Stable API에 대한 성능은 평탄하게 유지됩니다. 가장 강력한 모델(예: GPT-5.5, Sonnet 4.6)조차도 Stable과 Evolving API 사이에서 지속적인 7~10 포인트의 정확도 격차를 보입니다.
2. 구조적 한계: 이러한 저하는 모델 규모의 한계가 아니라 학습 과정의 구조적 특성입니다. Qwen-3.5 제품군 내에서 모델 크기가 커질수록 절대적인 성능은 향상되지만, Evolving API에서의 하향 추세 자체를 바꾸지는 못합니다.
3. 명시적 제약의 무효성: 프롬프트에 명시적인 라이브러리 버전 제약을 제공하는 것(L1→L2)은 정확도 향상에 측정 가능한 개선을 가져오지 못했습니다. 이는 버전 태그가 응답을 트리거할 수는 있지만, 모델이 이를 뒷받침할 근본적인 버전 차별화 지식을 갖추지 못했음을 시사합니다.
4. 문서의 이점: 관련 문서를 제공하는 것(L0→L1)은 일관되게 10~20 포인트의 성능 향상을 가져오며, 이는 모델이 정보를 명시적으로 제공받으면 검색하고 사용할 수 있지만 학습 과정에서 이를 내재화하는 데 실패함을 나타냅니다.
5. 오류 분석: 오류는 주로 조작(Fabrication)보다는 혼동(Confusion)에 의해 발생합니다. 모델은 동일한 라이브러리 내의 유효하지만 잘못된 심볼(Invalid)이나 다른 버전의 심볼(Anachronistic)을 자주 생성합니다. 시대착오적 오류는 파라미터 수준의 오류에서 상당한 비중(Signature Recall에서 6~14%)을 차지하며, 대상 버전이 최신일수록 심화됩니다.

의의 및 기여

본 논문은 세 가지 주요 기여를 합니다:

1. LibEvoBench: 결정론적인 버전 인덱싱된 그라운드 트루스를 특징으로 하여, 기존 연구의 휴리스틱한 한계를 피하고 LLM이 진화하는 API를 얼마나 잘 탐색하는지 평가하는 새로운 대규모 벤치마크를 제시합니다.
2. SEUS 지표: 일관되지 않은 버전 특정 지식과 시대착오적 오류에 명시적으로 페널티를 부여하여 소프트웨어 진화 이해도를 추적하도록 설계된 통합 지표입니다.
3. 역량 격차에 대한 실증적 증거: 본 평가는 현재의 LLM이 근본적으로 버전 인식 능력이 결여되어 있음을 입증합니다. 연구 결과는 모델 규모나 최근의 학습 데이터가 시간적 지식의 계층화를 해소하는 데 충분하지 않다는 것을 보여줍니다.

저자들은 코드 생성에서의 시간적 지식 계층화가 지속적이고 일차적인 역량 격차라고 결론짓습니다. 이 결과는 정적인 코드 생성을 넘어, 실제 소프트웨어 생태계의 연속적이고 버전별로 차별화되는 진화를 숙달하기 위해 시간적으로 특정된 컨텍스트에 코드 생성을 접지(grounding)할 수 있는 새로운 학습 및 검색 접근 방식이 필요함을 시사합니다.