Golden Set Scale KO

24건에서 2,400건으로: 골든셋의 수와 근거를 읽는 법

English

구체적인 단계·원천·작업 종류·실행 예산은 2,400개 확보 계획에 있다. 목표와 실제 확보 수는 구분한다.

24건은 초기 동작을 확인하기에는 유용하지만 실사용 성능을 판단하기에는 작다. 이 프로젝트의 다음 성능 주장에는 주장을 하는 평가 영역마다 서로 구분되는 최종 요청 최소 2,400건을 목표로 한다. 파일 검색, 실제 모델 선택, 저장소 선택, 작업 분할은 각각 자기 정답과 결과가 필요하다. 파일 검색 2,400건으로 다른 영역의 표본 수를 채울 수 없다.

2,400은 프로젝트가 정한 하한이며 모든 문제에 통하는 통계적 보증은 아니다. 단순 정답률에서 한 사례의 판정이 바뀌면 24건에서는 약 4.17%p, 2,400건에서는 약 0.0417%p가 움직인다. 이 차이는 표본 수의 효과를 설명할 뿐, 편향이나 잘못된 정답을 해결하지 않는다. 드문 과소 라우팅, 저장소별 실패, 한국어·영어 차이를 판단하려면 해당 구간에도 충분한 사례가 있어야 한다.

현재 확인한 규모

자료	확인한 수	의미와 한계
합성 의미 검색 예비 실험	최종 probe 24개 요청	한 작성자의 제한된 문법·주제 전이 시험. 이미 본 자료이므로 이후 개발 자료다.
난이도 개발 fixture	36개 작업	작성자가 붙인 예상 난이도와 분류를 비교한다. 실제 하위 모델의 작업 성공 정답은 아니다.
로컬 실제 코딩 후보 registry	8개 후보·세 코드 가족·한 저장소	54까지 실제 시도한 로컬 범위는 세 가족의 고유 요청 5개·CLI 기록 16개. 54의 새 파서 요청 네 반복 모두 독립 검사 75개·정상 종료·전체 사용량 확인. 반복과 테스트는 고유 요청 수가 아니다. 모집단·학습 라벨이 아니다.
55 이후 누적 실제 코딩 개발 관측	고유 요청 7개·기록 20개·시도한 코드 가족 5개·저장소 3개	기존 외부 두 요청을 v2 조건으로 처음 실제 관측해 4기록을 추가했다. 새 논리 요청 추가는 0개다. 55의 네 후보 중 세 개 accepted이며 학습·final 적격을 부여하지 않는다.
공개 Go 원천 조사: 53의 역사적 snapshot	8개 저장소·원본 행동 후보 120개·당시 실행 적격 0개	원본 목록은 보존한다. 파일·revision·LICENSE/출처를 읽은 개발 자료이며 전체 120개의 독립 계약·closure는 확보하지 않았다. 실행 수·학습 라벨·final 확보 수가 아니다.
54의 외부 계약 준비	원천 120개 중 2개, 당시 외부 모델 실행 0개	선택한 두 요청의 원천·독립 검사·대조군을 로컬에서 검증했다. 전체 컴파일된 검사 작업은 7개·3개 저장소이며 위의 로컬 후보 8개와 범위가 다르다. 외부 학습 라벨·final 적격은 0개다.
CoSQA 관련성 평가	2,400개 질문/코드 쌍, 724개 연결 그룹	실제 채점했지만 BM25 대비 유용한 개선을 입증하지 못했다. 한 쌍의 관련성을 평가하며 후보 검색·라우팅 성능을 증명하지 않는다.
실험 46 학습	적격 4,456개	16개 수치 특징으로 계수를 맞춘 개발 요청이다.
실험 46 validation	적격 2,599개	epoch·패널티·임계값 선택에 사용했다. final이 아니다.
파일 검색의 protected final	2,402개 요청	보호한 분할이며 결과를 읽거나 채점하지 않았다. 최종 성능이나 모든 요청의 평가 가능성을 확인한 수치가 아니다.

원문은 24개 합성 probe, 36개 난이도 fixture, 2,400쌍 평가, 규모·분할 원칙, 실험 46에 있다. semantic-scale의 2,400쌍 평가와 실험 46의 2,402개 protected final은 서로 다른 자료다. protected final은 분할에 배정된 요청 수이며, 평가할 수 있는 골든셋 2,402개를 확보했다는 뜻은 아니다. 추후 평가·배포 전에는 원천과 비용 자료의 적격성도 따로 확인해야 한다.

실험 46은 수를 늘렸어도 기존 5% 페이지 절감 gate를 통과하지 못했다. validation에서 항상 helper를 쓰면 116건은 페이지가 줄고, 283건은 늘며, 2,200건은 같았다. 패널티가 0일 때 가중치가 0이 아닌 행은 학습 734개, validation 399개였다. 이는 입력 행 4,456개·2,599개와 다른 수이며 다른 패널티에 그대로 적용되지 않는다. 많은 요청이 있어도 이득과 손해를 구분할 신호가 충분하다는 뜻은 아니다. 새 정책을 활성화하거나 새 가중치를 공개하지 않았다.

공개 실제 작업 후보의 예상 난이도는 실제 모델 결과로 확인할 수 있을 때까지 가설로 남긴다. 요청한 모델·추론 설정, 라우터 제안, 실제 적용 설정도 구분해 기록한다. 사용량을 확인할 수 없는 실행은 0으로 채우지 않고 미확인으로 보고한다.

실험 50은 코딩 본 실행 전에 거절됐고, 별도 실험 51은 한 주석 작업의 CLI 두 시도를 직접 기록했다. 첫 시도는 사용량이 알려졌지만 정확한 변경 계약을 충족하지 못했고, 두 번째는 요청 프로필이 지원되지 않아 사용량도 미확정이었다. 초기 오류 이벤트의 집계 호환성 공백으로 나머지 네 계획 항목을 중단했다. 이 두 기록은 학습 라벨에서 제외하며, 지원 오류를 모델의 능력 부족으로 세지 않는다. 초기 도구의 직접 작성 예제에 모델 결과가 0개였던 기록 49는 역사적 기록으로 그대로 보존한다.

별도 실험 52은 사용 가능한 요청 프로필을 따로 고정해 기존 세 개발 요청에서 여섯 시도를 기록했다. 두 주석 요청은 양쪽의 수용·사용량 비교가 가능해졌지만, 기능 요청의 Sol6는 범위 수용 후 시간 제한에 걸려 전체 비용은 미확인이다. 51에서 이미 수행한 요청을 반복해도 고유 요청을 늘리지 않는다. 52 시점의 누적 세 요청은 역사적 소계다.

실험 53은 새 키워드 보호 행동 요청 하나를 Luna/Sol low로 각각 두 번 반복했다. 네 후보 모두 수용·정상 종료·전체 기본 사용량을 확인했고 같은 보호 변경을 runtime에 반영했다. 51·52·53까지의 역사적 합계는 고유 요청 4개·두 실제 시도 가족·한 저장소·12기록이다. 53의 입력 합계 339,805에는 캐시 280,576이 포함되고 출력 4,890에는 reasoning 76이 포함된다. Luna의 총 입력은 적지만 uncached 입력은 Luna 31,425·Sol 27,804여서 실제 비용 절감을 결정할 수 없다. 고정 Laya의 새 관측은 standard 0.669로 보류, cold RSS 약 1.50GB였으며 초저자원 목표 달성을 입증하지 않는다.

실험 54는 새 파서 요청 하나를 Sol6/Luna low로 각각 두 번 실행해 네 후보 모두 수용·정상 종료·전체 기본 사용량을 확인했다. 54까지의 역사적 실제 개발 누적은 고유 요청 5개·세 실제 시도 가족·한 저장소·기록 16개이다. 독립 검사 75개는 요청 한 개의 요구사항 검사이며 75개의 작업이 아니다. Laya 사전 예측은 standard 점수 0.610351로 보류했다. CPU 한 스레드의 한 cold 관측은 1,183ms·최대 RSS 1,508,032,512 bytes (약 1.508 GB)였으며 native 로딩을 포함한다. warm 지연·Go heap· GPU 자원이나 보정된 성공 확률이 아니고 초저자원 목표 달성을 증명하지 않는다. 이 요청에서 Luna의 관측 시간과 토큰은 작았지만 실제 모델 정체·금액·구독 소모율은 미확정이다.

원천 후보 120개 조사는 53 시점의 개발 자료로 보존한다. 54에서 외부 두 요청의 독립 계약을 로컬에서 준비했지만 당시 외부 모델 실행·학습 라벨·final 적격은 0개였다. 원천 후보 120개 전체를 실행 가능한 계약이나 학습 정답으로 확보한 것이 아니며, 별도로 수집할 보호 final 2,400개를 대신하지 않는다. 후보·검사 계약·실행·완료·라벨·최종 적격 수를 각각 보고한다.

실험 55는 기존 외부 두 논리 요청을 v2 전체 Prompt·원본 모듈 언어로 각각 두 요청 프로필에서 한 번씩 실행했다. humanize는 양쪽 모두 accepted, UUID는 Luna low rejected·Sol low accepted였다. 네 실행 모두 정상 종료·전체 사용량·정리 영수증을 확인했다. 이번 최초 관측으로 누적 범위는 고유 요청 7개·기록 20개·시도한 코드 가족 5개·저장소 3개지만, v2가 컴파일된 7개 논리 작업 registry에 추가한 새 논리 요청은 0개다. 결과 JSON

슬롯 2·3 사이에는 사용자 요청의 검토·일시정지가 있었고 이후 미실행 슬롯만 재개했다. UUID 실패는 오류 시 부분 UUID를 반환하는 후보 소스의 정적 검토로 설명하며 재실행하지 않았다. 제공자가 확인한 모델 정체는 모두 미확인이고, 서로 다른 캐시 사용량과 요청당 한 관측으로 모델 순위·금액·구독 소모율 절감을 주장하지 않는다. 두 사전 native 예측은 전체 Prompt가 잘려 보류했다. 기본 라우팅 변경·학습·final 채점·새 가중치 배포는 없으며, 55의 실제 개발 관측은 2,400개의 보호된 최종 요청이나 적격 학습 라벨로 전환하지 않는다.

영역마다 필요한 최종 요청과 정답

다음 표는 앞으로 확보할 목표와 필요한 근거다. 이미 수집한 건수나 검증된 정답 목록이 아니다.

평가 영역	최종 목표	정답·증거와 측정할 결과
검색 hint·후보 순서	최소 2,400개 구분되는 검색 요청	고정 후보와 허용 가능한 관련 증거·파일 목록, 순위와 누락, 비용 및 품질. 실제 유용성 주장에는 충분한 증거를 찾은 뒤의 독립 검증도 필요하다.
실제 모델 라우팅	최소 2,400개 구분되는 작업 요청	비교할 모델을 같은 조건에서 실행하고 독립 테스트·수용 기준으로 성공을 확인한다. 성공 가능한 모델 집합과 전체 비용이 정답의 근거다. 작성자의 fast/standard/strong 예상은 출발 가설이다.
저장소 선택	최소 2,400개 구분되는 선택 요청	요청 시점의 권한과 후보 범위, 수행 가능한 저장소의 허용 집합, 정답이 없거나 접근할 수 없을 때 보류할 조건을 고정한다.
작업 분할	최소 2,400개 구분되는 부모 작업 요청	단일 실행·병렬 실행·의존 실행의 허용 가능한 계획, 선후 의존과 인터페이스, 합친 결과의 정확성, 부모 작업 전체의 완료 조건을 검증한다.

예상 난이도, 검색 비용 대리지표, 검증한 후속 효용은 다른 근거다. 실험 46의 비용은 첫 정답 파일을 찾을 때까지 20개 후보씩 넘긴 페이지 수다. 실제 LLM 토큰·요금·완료 시간은 아니다. 모델 라우팅은 첫 시도뿐 아니라 실패, 재시도, 승격, 보류, 검증을 포함한 모든 시도와 총 호출·사용량·시간·비용을 기록해야 한다. 분할도 하위 작업 수나 개별 성공만으로 끝내지 않고 병합·검증 비용과 부모 결과를 함께 센다.

수를 늘려도 지켜야 할 분리

한 요청을 두 seed, 여러 epoch·모델·설정으로 실행해도 요청 수는 하나다. 같은 요청의 번역·바꿔 쓰기나 같은 코드·템플릿에서 파생한 사례는 연결 그룹으로 관리한다. 부모 작업과 그 자식·형제 작업도 같은 분할에 둔다. 같은 저장소에서 나온 작업도 서로 의존할 수 있다. 총 요청 수와 고유 원천·저장소·그룹 수를 함께 보고하고, 상관된 요청을 모두 독립 표본이라고 부르지 않는다.

새 수집에서는 학습, 선택용 validation, 보정용 calibration, 최종 final을 점수를 보기 전에 그룹 단위로 고정한다. 새 저장소 일반화를 주장하려면 저장소 전체를 분리해야 한다. 데이터 해시, 모델·설계 선택 절차, 비용·품질 지표, 실패·범위 밖·누락 처리와 gate도 먼저 고정한다. 설계 수정에 사용한 final은 이후 개발 자료이며, 이미 본 validation을 final로 이름만 바꿀 수 없다.

앞으로의 분포는 직접 표현과 바꿔 말하기, 짧고 긴 요청, 모호하거나 정답 없는 요청, 여러 저장소·언어·변경 범위, 드문 위험한 실패를 포함하도록 제안한다. 각 구간의 목표와 평가 범위를 먼저 정하고 실제 확보 수·누락·불확실성을 보고한다. 목표 분포를 측정 결과로 적거나, 예상 난이도를 검증된 성공 라벨로 바꾸지 않는다. 기존 분할과 gate는 유지하며 새 학습·final 채점을 수행하지 않았다. 별도 개발 파일럿의 누적 실제 CLI 20회·고유 요청 7개도 2,400개의 독립 최종 요청 목표나 절감 근거를 대신하지 않는다.

SWE-bench 공식 평가 안내는 패치를 적용한 뒤 저장소 테스트로 해결 여부를 확인하는 방법의 참고다. SWE-bench Goes Live!는 최신 작업과 다양한 저장소를 통한 평가 설계의 참고다. 두 출처를 인용하는 것은 해당 자료의 채택, 이용·배포 권리 승인 또는 이 프로젝트의 사전학습 오염 부재를 뜻하지 않는다.