기술 요약: LLM의 도구 사용에 있어서 지식 격차 진단

문제 정의

코드 대규모 언어 모델(LLM)은 복잡한 과업을 해결하기 위해 소프트웨어 라이브러리와 API를 호출해야 하는 에이전트로 기능하는 경우가 점점 늘어나고 있다. 결정적인 문제는 이러한 에이전트가 새로운 API(라이브러리 버전 업데이트, 파괴적 변경 사항 또는 신규 패키지로 인해 사전 학습 데이터에 존재하지 않는 함수나 인터페이스)를 마주할 때 발생한다. 이러한 API를 성공적으로 활용하려면 단순히 함수 이름을 기억하는 것을 넘어, 다음과 같은 이질적인 지식 유형들을 조정하는 능력이 필요하다:

• 선언적 지식 (Declarative): 시그니처, 파라미터 타입, 모듈 경로.
• 절차적 지식 (Procedural): 워크플로 내에서의 올바른 구성 및 임포트(import) 해결.
• 근거 기반 지식 (Grounded): 구체적인 실행 예시 및 구현 세부 사항.

새로운 API 습득을 위한 기존의 평가 인프라는 근본적인 한계를 지닌다. 현재의 벤치마크는 정적이며(모델이 새로운 데이터를 흡수함에 따라 빠르게 퇴화함), 원인을 은폐하는 거친 집계 지표(예: pass@k)에 의존하며, 실제 라이브러리의 진화를 반영하지 못하는 인위적인 과업을 자주 합성한다. 결과적으로, 어떤 특정 지식 구성 요소가 서로 다른 적응 패러다임(예: 검색 증강 생성 vs 미세 조정)에 의해 학습되는지, 그리고 어떤 누락된 구성 요소가 특정 실패 모드로 이어지는지는 여전히 명확히 파악되지 않고 있다.

방법론: NOVELAPIBENCH

이러한 한계를 해결하기 위해 저자들은 코드 LLM의 지식 격차를 진단하기 위해 설계된 완전 자동화된 동적 실행 기반 벤치마크인 NOVELAPIBENCH를 도입한다. 이 프레임워크는 4단계 파이프라인을 통해 작동한다:

1. 새로운 API 발견 (Novel API Discovery): 대상 라이브러리 $L$과 베이스 모델 $M$이 주어지면, 시스템은 $M$의 지식 컷오프 이후에 출시된 버전에서 도입된 API를 식별한다. 시스템은 내성(introspection) 및 AST 파싱을 사용하여 사전 컷오프 버전($v_{old}$)과 사후 컷오프 버전($v_{new}$) 사이의 공개 API 표면을 비교(diff)하고, 프라이빗, 폐기되었거나 소스가 없는 항목을 필터링한다.
2. 지식 추출 (Knowledge Extraction): 각 새로운 API에 대해, 시스템은 지식을 네 가지 뚜렷한 구성 요소로 분해한다:
   • $S$ (Surface, 표면): 전체 경로 이름 및 파라미터 시그니처(타입, 기본값, 설명).
   • $E$ (Exemplars, 예시): 문서와 GitHub에서 채굴되어 샌드박스에서 검증된 표준 사용 예시.
   • $M_{prose}$ (Mechanism Prose, 메커니즘 산문): 기저의 알고리즘 또는 설계에 대한 자연어 설명.
   • $M_{code}$ (Mechanism Code, 메커니즘 코드): AST에서 추출한 구현 소스 코드.
3. 과업 생성 (Task Generation): 시스템은 난이도가 제어된 테스트 하네스를 갖춘 실행 가능한 코딩 과업을 생성한다. 결정적으로, 모든 하네스에는 **자동 주입된 타겟-API 스파이(target-API spy)**가 포함되어 타겟 API의 모든 별칭(alias)을 패치한다. 이를 통해 테스트 통과를 위해서는 타겟 API에 대한 진정한 호출이 필수적이도록 보장하며, 모델이 구조적 모방을 통해 과업을 우회하는 것을 방지한다.
4. 품질 및 참신성 필터링 (Quality & Novelty Filtering): 참조 솔루션이 유효하고, 베이스 모델이 도움 없이 해결할 수 없으며(경험적 참신성), 전체 지식 번들을 통해 해결 가능한 과업인지 확인하기 위해 과업을 필터링한다.

실패 분류 체계 (Failure Taxonomy):
핵심적인 기여는 실행 실패를 여섯 가지 상호 배타적인 범주로 분류하여 특정 오류를 누락된 지식과 연결하는 자동화된 실패 분류 체계이다:

1. WrongAPISelection (잘못된 API 선택): 타겟 API가 호출되지 않음 (환각 또는 형제 심볼 사용).
2. WrongImport (잘못된 임포트): 올바른 심볼이지만 잘못되거나 누락된 임포트 경로.
3. WrongSyntax (잘못된 구문): 유효하지 않은 Python 구문.
4. WrongParam (잘못된 파라미터): 올바른 호출이지만 잘못된 인자 사용.
5. WrongShapeDtype (잘못된 형태/데이터 타입): API 본체 내부의 계약 위반 (예: 형상 불일치).
6. WrongLogic (잘못된 로직): 올바른 API 사용에도 불구하고 주변 프로그램 구조가 틀림.

주요 기여

1. 동적 벤치마킹: 어떤 베이스 모델과 진화하는 라이브러리에도 적응할 수 있는 재생 가능한 벤치마크를 제공하여, 과업이 진정으로 참신함을 유지하도록 보장한다.
2. 세밀한 진단: 특정 실행 오류를 검색, 미세 조정, 지식 편집 패러다임 전반의 누락된 지식 구성 요소와 연결하는 자동화된 실패 분류 체계를 제공한다.
3. 체계적인 경험적 연구: 5개 도메인, 4개의 백본 모델, 그리고 여러 적응 방법(RAG, SFT, RAFT, GRACE, MEMIT, AlphaEdit)에 걸쳐 약 800개의 새로운 API를 아우르는 대규모 평가를 수행한다.

실험 결과

1. 지식 구성 요소의 효과성 (RQ1)

• 사용 예시($E$)는 가장 강력한 단독 구성 요소이다: 예시만 제공해도 pass@1이 3.1%에서 18.2%로 증가했으며, 이는 주로 WrongAPISelection 오류를 해결함으로써 달성되었다.
• 시그니처($S$)는 가장 신뢰할 수 있는 닻 역할을 한다: 표면 셀($S$)은 API 선택 오류를 줄임으로써 모든 단일 구성 요소 중 가장 높은 21.7%의 pass@1을 달성했다.
• 메커니즘 산문($M_{prose}$)은 의미적 모호성 해소에 도움을 준다: 시그니처($S$)와 결합했을 때($S+M_{prose}$), 로직 오류를 추가로 감소시켰으나 단독 구성 요소로서의 영향은 미미했다.
• 소스 코드($M_{code}$)는 노이즈를 유발한다: 구현 소스 코드를 추가하면 종종 성능이 저하된다. 이는 WrongImport 오류를 크게 증가시켰는데, 이는 원시 소스 코드가 모델을 해결하기보다 오히려 모듈 경로에 대한 노이즈를 유발하여 혼란을 준다는 것을 시사한다.
• 최적의 구성: 최적의 이중 구성은 도메인과 백본에 따라 시그니처($S$)를 메커니즘 산문 또는 예시와 짝지었을 때 나타났다.

2. 과업 및 백본의 영향 (RQ2)

• 과업의 정형성: 예시($E$)는 템플릿화된 정형 과업(예: 데이터 과학 피처)에는 매우 효과적이었으나, 예시가 특정 요구사항과 달라지는 이질적인 과업(예: AI4Science)에서는 해로웠다. 메커니즘 산문($M_{prose}$)은 과업 유형에 관계없이 더 안정적이었다.
• 백본 선호도: 최적의 보조 구성 요소는 백본의 고유한 강점에 따라 달랐다. 시그니처($S$)가 이미 강한 모델은 산문으로부터 더 많은 도움을 받았고, 예시에 의존하는 모델은 명시적인 호출 구조로부터 더 많은 도움을 받았다.
• 추론 중심 모델: 추론 중심 백본(예: R1-Distill)은 소스 코드가 도입하는 임포트 경로 노이즈에 더 강한 저항력을 보였는데, 이는 이들이 경로를 단순히 복사하기보다 식별자를 재해결하는 능력이 있기 때문으로 보인다.

3. 파라미터 적응 vs. 검색 (RQ3)

• 휘발성 사실의 내부화 실패: 어떤 파라미터 적응 패러다임(SFT, RAFT, GRACE, MEMIT, AlphaEdit)도 새로운 API 지식을 완전히 내부화하지 못했다. 추론 시 외부 지식 번들이 제거되면 성능이 급격히 떨어졌으며(예: SFT는 85.5%에서 3.3%로 하락), 검색 기반 방식과의 격차를 좁히는 데 실패했다.
• 절차적 메타 기술 학습: 미세 조정은 API 세부 사항(시그니처, 경로)을 암기하는 것이 아니라, 제공된 지식 번들을 효과적으로 활용하는 전이 가능한 절차적 기술을 학습했다.
  • SFT/RAFT/AlphaEdit는 지식 번들이 존재할 때 WrongAPISelection 및 WrongImport 오류를 크게 줄였으며, 실패 지점을 WrongLogic으로 이동시켰다.
  • 이 "번들 활용" 기술은 홀드아웃 라이브러리(OOD)로 전이되었지만, 특정 모듈 경로 지식은 전이되지 않았다. 한 라이브러리에서 학습된 모델은 새로운 라이브러리에서도 올바른 API를 식별할 수는 있었으나, 올바른 임포트 경로를 해결하는 데 실패하여 WrongImport 오류가 급증했다.

의의 및 주장

본 논문은 콘텐츠 획득(API 식별 및 계약 파악)과 절차적 실현(올바른 임포트 및 로직과 함께 이를 코드로 통합)이 서로 다른 하위 기술임을 주장한다.

• **검색(Retrieval)**은 모델이 추론하거나 암기하기 어려운 휘발적이고 구조가 낮은 사실(API 이름, 시그니처, 경로)을 공급하는 데 필수적이다.
• **파라미터 튜닝(Fine-tuning)**은 이러한 사실의 절차적 통합을 개선하는 데 효과적이다. 즉, 모델에게 검색된 증거를 올바르게 사용하는 방법을 가르치는 것이다.

저자들은 새로운 API에 적응하기 위한 최적의 아키텍처가 RAG와 미세 조정 중 하나를 선택하는 것이 아니라, 두 가지의 조합이라고 결론짓는다: 압축적이고 가치 있는 검색 단위(예: 시그니처 + 메커니즘 산문)와 절차적 통합을 숙달하도록 다양한 API 사용 과업에 걸쳐 학습된 어댑터의 결합이다. 현재의 "위치 파악 및 편집(locate-and-edit)" 방식은 아직 이 결합된 경계에 도달하지 못했다. 본 연구는 향후 발전 방향으로, API를 식별하는 것과 이를 올로 구현하는 것 사이의 간극을 메우기 위해 프로세스 수준의 감독(예: 실행 기반 강화 학습)이 필요할 수 있음을 시사한다.