검색 기초 시험 07: 고유 질문 2,948개에서 보조 검색의 장단점

English · 고정 계획 · 결과 · 재현·오류 수정 기록

함수 이름이 없는 설명에서는 식별자 분리가 도움이 됐지만, 전체 첫 정답률은 낮아졌다. 기존 검색을 일괄 교체하지 않는다. 이번에는 실제로 서로 다른 설명 2,948개를 검색했다. 24개 질문의 후보 수나 반복 횟수를 늘려 만든 수가 아니다. 다만 세 저장소의 문서 설명을 질문으로 사용하는 대리 시험이며 실제 사용자 질문 2,400개의 독립 최종 시험은 아니다.

무엇을 비교했나

후보는 Go 함수 3,009개다. 원문 코드만 색인하며 정답 설명이나 저장소 경로를 검색 본문에 덧붙이지 않았다. 같은 정규화 설명에 연결된 함수가 여러 개면 모두 알려진 정답 후보로 취급한다. 나머지 후보는 미판정이지 자동 오답이 아니다. 후보 순서는 저장소·경로·코드 해시로 고정했고 질문·정답 순서나 점수로 정렬하지 않았다.

• raw: 기존 pkg/hintsearch의 BM25. 식별자를 통째로 검색하는 기준선이다.
• identifiers: 코드와 질문의 camelCase/snake_case 등을 동일한 방식으로 나눠 BM25를 적용한다. 학습 모델은 없다.

학습·설정 탐색 없이 두 방법을 모두 실행했다. 계획과 평가기 초안은 첫 원천 점수 계산 전에 commit 33bd500으로 고정했다. 첫 실행에서 질문 중복 제거용 소문자 문자열을 실제 전처리 입력으로 잘못 사용한 오류를 발견했다. 코드에는 대소문자가 남아 있어 양쪽 분리가 달랐다. 첫 결과는 무효로 기록하고 회귀 시험과 함께 2b44d9e에서 수정했다. 아래는 수정 후 결과다. 자료를 이미 관찰했으므로 앞으로 이 자료의 재시험을 새로운 독립 검증이라고 부르지 않는다.

결과

상위 10개 발견률은 알려진 정답 중 하나가 검색 결과 10개 안에 있는 질문 비율이다. MRR은 첫 정답 순위의 역수를 평균한 값으로 높을수록 좋다.

질문 집합	방법	첫 후보 정답률	상위 10개 발견률	MRR	평균 첫 정답 순위
전체 2,948개	기존 BM25	41.79%	74.83%	0.5336	48.99
전체 2,948개	식별자 분리	39.21%	77.27%	0.5262	30.00
이름 포함 2,604개	기존 BM25	44.51%	78.49%	0.5640	19.12
이름 포함 2,604개	식별자 분리	40.48%	79.22%	0.5412	16.08
이름 없음 344개	기존 BM25	21.22%	47.09%	0.3038	275.12
이름 없음 344개	식별자 분리	29.65%	62.50%	0.4121	135.39

이름 유무는 평가 때 정답 함수 이름을 보고 분류했다. 실제 서비스의 라우터가 이 정답 정보를 알고 있다고 가정해서는 안 된다. 이름 없는 344개에서 개선됐다는 사실을 이름 없는 2,400개에서 검증됐다고 확대하지 않는다. 세 저장소 결과는 JSON에 따로 기록했고, 질문 2,948개가 모두 독립이라는 가정의 신뢰구간이나 전체 저장소에 대한 일반화 주장은 하지 않는다.

출처 점검과 제외

이전 자료 점검에서 루트 고지를 확인한 세 저장소의 원천 commit ZIP을 내려받아 해시를 고정했다. 전체 717개 해당 파일에서 3,095개 코드 조각이 원본에 그대로 존재하는지 확인했다. 파일을 실행하거나 ZIP을 추출하지 않았다.

순서대로 적용한 상호 배타적 제외 사유는 생성 코드 표시 63개, 하위 디렉터리 별도 고지 14개, 다른 라이선스 헤더 8개, 설명 전체가 코드에 포함된 1개다. 남은 3,009개 후보는 고유 설명 2,948개와 연결됐다. 예를 들어 lxd의 shared/log15/LICENSE, lxd shared/cert.go와 etcd pkg/pathutil/path.go의 BSD 관련 헤더를 발견했다. 다른 라이선스가 사용 불가능하다는 뜻이 아니라, 이번 단일 조건 점검 범위에서 제외했다는 뜻이다.

원천 revision·ZIP·루트 고지 해시는 결과에 있다. 헤더가 없으면 확인한 루트 고지를 출처 근거로 삼았지만, 이 절차가 모든 권리나 생성 코드 여부를 완전히 확인한다는 뜻은 아니다. 원문과 코드 조각은 로컬에만 보관한다. 문서 설명의 이름 편향, 세 저장소 집중, 의미 복제 미탐지 등의 한계를 유지한다. CoSQA의 두 reserve에는 접근해 점수를 매기거나 학습하지 않았다.

자원과 재현

Apple M4 Pro/Go1.27.1 CPU에서 전체 프로세스 wall 1.74초/user CPU 1.41초/최대 RSS 94,519,296바이트(약 90.1MiB)였다. ZIP·원천 로딩과 검증, 두 색인 생성, 전체 평가를 포함한다. 다운로드·Parquet 투영·컴파일은 제외한다. ZIP 준비 비용이 포함된 값이므로 상시 검색 서버의 메모리라고 해석하지 않는다.

질문 전처리와 순위 계산을 포함한 p95는 기존 약 0.206ms, 식별자 분리 약 0.209ms였다. 색인 생성 시간에는 코드 전처리가 포함된다. 후보 정답 검사·JSON 출력·파일 읽기는 개별 검색 지연에 포함하지 않는다. 3,009개 후보와 이 장비에서의 측정이며 대규모 저장소 성능이나 LLM 비용 절감이 아니다. 재실행의 모든 품질 지표와 자료 구성은 동일했고 시간 값은 달랐다.

앞선 투영 절차를 수행한 뒤 고정 ZIP을 준비한다.

mkdir -p .cache/retrieval-source-07
curl -fL 'https://codeload.github.com/kubernetes/test-infra/zip/8125fbda10178887be5dff9e901d6a0a519b67bc' -o .cache/retrieval-source-07/test-infra.zip
curl -fL 'https://codeload.github.com/lxc/lxd/zip/7a41d14e4c1a6bc25918aca91004d594774dcdd3' -o .cache/retrieval-source-07/lxd.zip
curl -fL 'https://codeload.github.com/etcd-io/etcd/zip/616592d9ba993e3fe9798eef581316016df98906' -o .cache/retrieval-source-07/etcd.zip
go run ./cmd/riido-retrievalbench --stage audit
go run ./cmd/riido-retrievalbench --stage evaluate

원천·계획·선택 후보 해시와 개수가 다르면 거부한다. GitHub가 ZIP 직렬화 방식을 바꿔도 해시 불일치를 무시하지 않는다. ZIP은 50MiB, 읽는 파일은 8MiB로 제한하며 디스크에 추출하지 않는다. 원천 준비·점검에서 쓰는 맵은 오프라인 도구용이고 실제 순위 계산은 기존 불변 배열 색인을 사용한다.

다음 가설

추가 모델 없이 얻은 이 비교는 '어떤 보조 검색이 지금 도움이 될 수 있는가'를 제안하는 초소형 주장 모델의 학습 목표 후보가 된다. 실제 입력에서 얻을 수 있는 신호만으로 두 검색의 도움 가능성을 예측하고, 잘못된 힌트에도 기존 후보를 보존하는 방식을 다음 별도 실험으로 검토한다. 이 평가의 이름 유무 정답이나 결과를 런타임 입력으로 제공하지 않는다. 충분한 독립 질문과 저장소 분리 검증, 전체 작업 시간·사용량 측정 전에는 자동 적용이나 유용성 입증을 선언하지 않는다.

CPU pprof도 실제 전체 평가에서 수집했다. 표본 1,330ms 중 Rank 누적 비중은 42.86%, runtime.madvise 자체 비중은 29.32%였다. 짧은 단일 표본이므로 절감률로 해석하지 않는다. 다음 최적화에서는 SIMD보다 먼저 호출자가 재사용할 수 있는 순위 배열과 정렬 비용을 확인한다. 원시 프로파일은 공개하지 않는다. --cpuprofile .cache/new-cpu.pprof로 새 로컬 파일에 수집할 수 있으며 이 실행의 품질 지표도 동일했다.