코딩 평가에서 신호와 잡음 분리하기

1 hour ago 1
  • AI 모델의 코딩 능력 평가는 배포와 안전성 판단에 직접 연결되지만, OpenAI의 감사에서 SWE-Bench Pro 작업 중 약 30%가 깨진 상태로 추정됨
  • SWE-Bench Pro는 더 긴 작업 범위와 현실적인 과제를 목표로 했으나, 731개 공개 작업에서 통과율이 8개월 만에 23.3%에서 80.3%로 오른 결과를 그대로 믿기 어려워짐
  • 결함은 과도하게 엄격한 테스트, 과소명세 프롬프트, 낮은 커버리지 테스트, 오도하는 프롬프트로 나뉘며, 올바른 제출이 실패하거나 불완전한 수정이 통과할 수 있음
  • 감사는 모델 시도, 작업 메타데이터, 실패 추적을 바탕으로 286개 잠재 문제 작업을 표시한 뒤, 조사 에이전트와 숙련 엔지니어 5명의 독립 검토를 거침
  • OpenAI는 SWE-Bench Pro 채택 권고를 철회했으며, 평가 벤치마크는 모델 능력과 안전성 판단을 왜곡하지 않는 의미 있는 신호를 제공해야 함

SWE-Bench Pro 감사에서 드러난 문제

  • OpenAI는 SWE-Bench Pro를 감사한 결과, 전체 작업의 약 30%가 깨진 상태라고 추정함
  • 모델 능력을 정확히 측정하는 일은 Preparedness Framework에 따른 배포와 안전성 판단에도 영향을 줌
  • 결함 있는 평가는 모델 능력을 실제보다 잘못 이해하게 만들고, 안전성 판단과 연구 우선순위를 흔들 수 있음

SWE-Bench Pro의 목적과 통과율 변화

  • OpenAI는 앞서 널리 쓰이던 SWE-bench Verified에서 설계와 오염 문제를 확인했고, 이 평가가 소프트웨어 개발 능력에 대한 의미 있는 신호를 더 이상 주지 못한다고 판단함
  • 당시 OpenAI는 커뮤니티에 SWE-Bench Pro로 전환하라고 권고함
  • SWE-Bench Pro는 SWE-bench Verified를 개선해 더 긴 작업 범위와 더 현실적인 코딩 과제로 에이전트형 코딩 능력을 추적하도록 설계됨
  • 작업은 공개·비공개 저장소의 기능 변경 이력에서 프로그래밍 방식으로 추출됨
    • 모델은 기존 기능을 깨뜨리지 않으면서 새 기능 테스트를 통과하는 솔루션을 구현해야 함
    • 731개 작업 공개 분할에서 프런티어 모델 통과율은 8개월 동안 23.3%에서 80.3%로 상승함

품질 보증 파이프라인

  • OpenAI는 각 데이터포인트가 실제 모델 능력을 반영하는지 확인하기 위해 품질 보증 파이프라인을 만듦
  • 초기 자동 필터는 모델에 주어진 지시, 모델의 해결 시도, 채점 테스트를 검토해 깨졌거나 문제가 의심되는 예시를 표시함
  • 이 과정에서 286개 잠재 문제 작업이 표시됨
  • 표시된 부분집합은 두 경로로 더 깊게 검토됨
    • 인간이 감독하는 에이전트 검토: 조사 에이전트가 세부 확인을 수행하고 최종 인간 판단을 거침
    • 인간 주석 캠페인: 숙련 소프트웨어 개발자가 작업을 직접 검토함

에이전트 검토와 인간 검토 방식

  • 표시된 문제는 Codex 기반 조사 에이전트가 감사함
    • 에이전트는 작업 저장소와 실행 환경에 접근함
    • 테스트 실행, 저장소 파일 검사, 모델 시도와 공통 실패 모드 조사가 가능함
    • 주변 코드와 저장소 관례로 해결 가능한 합리적 모호성과 실제 과소명세를 구분하는 데 활용됨
  • 여러 차례의 독립 심층 감사 뒤 연구자가 요약을 검토하고 최종 판단과 문제 라벨을 지정함
  • 병렬로 진행된 인간 주석 캠페인에서는 숙련 소프트웨어 엔지니어가 벤치마크 목표, 문제 분류, 경계 사례에 대한 교육을 받은 뒤 작업을 검토함
  • 각 작업은 엔지니어 5명이 검토함
    • 검토자는 보이는 문제 설명, 테스트 케이스, 정답 참조 솔루션인 gold patch를 바탕으로 먼저 독립 판단을 내림
    • 이후 파이프라인 분석이나 기록을 보조 맥락으로 사용함
    • 구체적 근거에 따라 라벨과 심각도를 지정하고, 의견 불일치나 낮은 확신 사례는 추가 검토로 올림

네 가지 실패 유형

  • 감사에서 확인된 문제는 주로 네 범주로 나뉨
    • 과도하게 엄격한 테스트: 프롬프트에 없는 특정 구현 세부사항을 강제해 기능적으로 올바른 제출을 무효화함
    • 과소명세 프롬프트: 숨겨진 테스트가 요구하지만 합리적으로 추론하기 어려운 요구사항을 빠뜨림
    • 낮은 커버리지 테스트: 요청된 기능을 충분히 확인하지 않아 불완전한 수정도 통과할 수 있음
    • 오도하는 프롬프트: 모델을 잘못된 동작으로 유도하거나 테스트 요구사항과 모순됨
  • 일부 작업에서는 프롬프트가 특정 구현을 요구했지만, 숨겨진 테스트 케이스는 다른 동작을 기대함

인간 검토와 에이전트 검토의 차이

  • 인간 검토자는 조사 에이전트보다 작업을 깨진 것으로 표시할 가능성이 더 높았음
  • 두 검토 경로 사이에는 범주 판단 차이가 있었지만, 표시된 작업 중 인간 라벨에서 “깨지지 않음”이 최다 라벨인 경우는 없었음
  • 에이전트 파이프라인이 표시한 범주와 인간 검토자의 판단은 74% 사례에서 겹침
  • 인간 검토자는 한 작업에 여러 라벨을 선택하는 경우도 더 많았음
    • 작업이 여러 방식으로 깨졌거나 단일 범주에 깔끔하게 들어맞지 않았다는 신호임
    • 에이전트와 검토자를 함께 쓰는 파이프라인은 인간이 찾은 넓은 실패 모드를 포착했지만, 추가·중복 문제는 보수적으로 적게 셈
  • 가장 큰 차이는 낮은 커버리지 테스트에서 나타남
    • 인간은 이를 벤치마크의 9.4%에서 가장 흔한 문제로 선택함
    • 에이전트 파이프라인은 4.1%로 표시함

벤치마크 구축이 어려운 이유

  • SWE-Bench Pro와 SWE-bench Verified 사례는 벤치마크를 엄격하게 검증해야 함을 보여줌
  • 오픈소스 저장소의 이슈와 풀 리퀘스트는 원래 모델 평가가 아니라 인간 협업을 위해 만들어짐
  • 유지관리자와 기여자 사이에 긴 왕복 논의가 많은 환경에서는 문제 설명, 병합된 코드, 단위 테스트가 모델 평가용으로 깨끗하고 독립적인 작업을 항상 구성하지 않음
  • 풀 리퀘스트에 포함된 테스트는 특정 변경을 검증하기 위해 작성되는 경우가 있어, 구현 방식에 독립적인 해결 기준보다 특정 구현을 강제할 수 있음

앞으로의 평가 방향

  • 모델 능력이 향상되면서 평가 결함도 예전보다 더 쉽게 찾을 수 있게 됨
  • 향상된 모델은 프롬프트, 테스트, 패치, 실행 추적, 경계 사례를 더 깊고 일관되게 검사해, 예전에는 대규모로 찾기 어렵거나 비용이 컸던 벤치마크 문제를 드러낼 수 있음
  • OpenAI는 더 넓은 평가 커뮤니티가 숙련 소프트웨어 개발자가 직접 모델 능력 테스트를 목적으로 만든 새 벤치마크를 개발하길 기대함
  • 이런 방식은 측정하려는 높은 난도와 현실성을 유지하면서, 과정 전반에서 더 나은 인간 감독을 가능하게 함
  • OpenAI는 이번 분석에서 드러난 문제 때문에 SWE-Bench Pro 채택에 대한 이전 권고를 철회함
  • 평가는 조작하기 어렵고 신뢰하기 쉬우며, 모델 능력이나 정렬 상태를 실제로 반영하는 의미 있는 신호를 제공해야 함
Read Entire Article