Baseline First 10 KO

첫 후보 보존 10: 직접 사용할 수 있는 비학습 보조 검색

English · 전체 결과

기존 검색의 첫 후보를 고정하고 식별자 분리 검색의 후보를 사이에 넣는다. 2,948개 문서 설명 질문에서 첫 후보 정답률을 유지하면서 상위 10개 발견률과 평균 정답 순위를 개선했다. 학습 모델의 성과가 아닌 비학습 기준선이며, 기본 옵션은 바꾸지 않는다.

바로 시험하기

모델 다운로드나 Python 없이 다음 원본 공개 예제로 실행할 수 있다.

printf '%s\n' '{"snapshot_id":"demo","query":"read config","documents":[{"id":"a","text":"read"},{"id":"b","text":"config"},{"id":"c","text":"func ReadConfig() {}"}]}' \
  | go run ./cmd/riido-hints --identifier-hints

기존 순서는 a,b,c이고 새 순서는 a,c,b다. 첫 후보 a는 유지하면서 ReadConfig를 read config로 나눠 찾은 c를 두 번째에 제안한다. 출력은 후보 ID·순위·기존 BM25 점수이며 원문 코드를 내보내지 않는다. 점수는 기존 검색 점수이므로 새 순서에서 반드시 내림차순인 것은 아니다. status: unverified, policy: identifier_bm25_baseline_first로 표시된다.

옵션을 빼면 기존 검색이다. 외부 힌트나 --model과 함께 사용하면 명시적으로 거부한다. 분리 후 자료가 기존 입력 한도를 넘거나 질문에 검색할 단어가 없으면 기존 순서로 돌아가며 bm25_identifier_input_out_of_scope로 표시한다. 호출자는 접근 가능한 자료만 전달해야 한다. 이 도구가 저장소를 자동으로 읽거나 권한을 판단하지는 않는다. 현재 전체 후보를 출력하므로 많은 후보의 출력 토큰 비용도 별도로 고려해야 한다.

보호 범위

Go API는 hintsearch.InterleaveBaselineFirst(baseline, hints)다. 부분 힌트도 허용하고, 누락·중복 없이 모든 기존 후보를 남긴다. 기존 r번째 후보는 늦어도 2r−1번째(전체 후보 수 이내)에 나온다. 예를 들어 기존 3번째 후보는 최대 5번째다. 이는 정확하고 동일 비용인 후보 검사를 가정한 개수 제한이다. 실제 시간·토큰·복수 증거 수집이나 보조 검색 생성 비용의 제한은 아니다. 첫 후보가 같아도 그 뒤의 일부 순위는 나빠질 수 있다.

실제 자료 결과

앞선 07/09와 같은 고정된 세 저장소·3,009개 함수·2,948개 고유 설명을 사용했다. 제외 정책, 후보 해시 순서와 알려진 정답은 바꾸지 않았다. 첫 원천 점수 계산 전에 구현을 commit했고, 재실행의 전체 JSON이 바이트 단위로 같았다. 이미 관찰한 문서 기반 자료이므로 새 독립 사용자 질문 시험은 아니다.

방식	첫 후보 정답률	상위 10개 발견률	MRR	평균 첫 정답 순위
기존 BM25	41.79%	74.83%	0.5336	48.99
보조 검색 후보부터 교차	39.21%	81.51%	0.5479	26.71
기존 후보부터 교차	41.79%	81.38%	0.5601	26.70

기존 후보부터 교차한 결과 733개 질문에서 순위가 좋아지고, 674개에서 나빠지고, 1,541개는 같았다. 평균 개선이 모든 질문의 개선이라는 뜻은 아니다. 저장소별 수치도 JSON에 있다. 이 비학습 기준선을 이후 학습 모델이 추가 비용까지 고려해 넘어야 한다. 기존 09의 실패 모델을 합격으로 바꾸거나 HF 가중치를 교체하지 않았다.

검증과 비용

1~7개 후보의 모든 힌트 순열·부분 길이에 대해 첫 후보·전체 후보 보존과 2r−1 제한을 검사했다. 기존 보조 후보 우선 동작도 계속 검사한다. 기존 09 학습을 새 공통 구현으로 다시 실행해 전체 결과 JSON이 같음을 확인했다. CLI는 실제 실행 예제와 충돌·범위 초과 복귀를 검사한다.

Apple M4 Pro/Go1.27.1 CPU에서 비교 도구 전체는 wall 3.02초/user CPU 2.67초/최대 RSS 94,683,136바이트였다. 두 정책 비교를 위해 원천 검증과 두 번의 전체 검색 준비를 포함한다. 단일 CLI 검색이나 서비스 지연 수치가 아니다. 옵션은 추가 색인과 검색을 수행하므로 작업 시간을 항상 줄인다고 주장하지 않는다. 학습·GPU·LLM 호출은 이 비교에 없다.

# 07에서 준비한 고정 원천을 사용한다.
go run ./cmd/riido-interleaveprobe
go test -race ./pkg/hintsearch ./cmd/riido-hints ./internal/retrievalbench

다음 학습은 이 순서를 기준으로 실제 검사량 이득과 보조 검색 비용을 다뤄야 한다. 실제 사용자 작업 성공·전체 시간·토큰 절감, 독립 질문 자료와 보류한 CoSQA 평가는 아직 남아 있다.