인덱스 한 쌍 재사용 — 실험 35

전체 2,400개 평가에서는 빨라지지 않았고 최대 메모리가 증가했다. 기본 활성화를 보류하고 명시적인 실험 옵션으로만 제공한다. 같은 파일 목록을 반복해서 검색하는 경우에 대한 가설과, 여러 저장소·과거 시점이 섞인 이번 평가를 구분한다.

사전 계획은 구현·측정 전에 고정했다. 기준 소스는 실험 34 병합본이다. 원래 전체 요청·파일 목록·검색 정책·평가 순서를 유지했다. 학습이나 정답 기반 튜닝은 없다.

fileeval.Ranker는 직전 파일 경로 배열의 모든 문자열이 같은 순서로 일치할 때만 원래 BM25와 식별자 분리 BM25 인덱스를 재사용한다. 해시만 믿거나 저장소 이름만 비교하지 않는다. 한 목록만 보관하며 변경되면 교체한다. 질문·검색 결과·정답은 캐시에 저장하지 않는다. 반환 순위는 호출별 소유이며 기존 결과를 덮어쓰지 않는다. 작업자별 인스턴스를 사용하므로 잠금은 없고, 한 인스턴스를 동시에 호출하면 안 된다. 입력 한도와 fallback은 유지한다.

실행 순서	방식	전체 초	user / system 초	최대 RSS 바이트
1	기존	52.59	53.88 / 2.06	108,150,784
2	재사용	52.94	55.09 / 1.83	122,044,416
3	재사용	52.72	55.33 / 1.88	128,991,232
4	기존	52.65	55.25 / 1.94	109,920,256

Apple M4 Pro CPU에서 서로 겹치지 않게 실행했다. 방식별 두 관측의 시간 중앙값은 52.62 → 52.83초이며, 최대 관측 RSS는 약 104.8 → 123.0MiB다. 측정 횟수가 적어 작은 시간 차이를 통계적으로 확정하지 않는다. 재사용은 매번 3회뿐이고 2,397개 목록을 새로 만들었다. 전체 프로세스는 입력·캐시 검증·파일 읽기·검색·채점·출력을 포함하므로 순수 추론 시간이 아니다. 모든 관측값.

모든 실행은 실험 34 집계와 바이트 단위로 같으며, 2,400개 작업의 세 정책 전체 순위 지문도 일치했다. 작업 ID 길이·정책 번호·후보 수·모든 후보 위치를 순서대로 SHA-256에 기록한다. 따라서 상위 정답 수만 같은 비교가 아니다. 원문이나 작업별 순위는 공개하지 않는다.

사전 승인 조건은 전체 순위·집계 일치와 시간 중앙값 감소, 최대 관측 RSS 비증가다. 속도·메모리 조건을 통과하지 못했다. 사후에 작업을 재정렬하거나 캐시 크기를 늘려 같은 실험의 성공으로 바꾸지 않는다. 향후 배치 순서 변경은 별도 실험이다.

# 기본: 직전 인덱스를 유지하지 않음
go run ./cmd/riido-fileeval --out .cache/file-eval-new
# 명시적 실험 옵션: 직전 파일 목록 하나만 유지
go run ./cmd/riido-fileeval --reuse-path-indexes --out .cache/file-eval-reuse-new

실험 34의 고정된 로컬 요청·정답 projection과 전체 캐시가 필요하다. 기본 실행도 전체 순위 지문을 출력한다. 무효·변경 입력, 호출자 배열 변경, 긴 정규화 질문의 fallback, 기존 반환값 보존, 독립 작업자 동시 사용을 검증한다. 기존 standalone Rank는 호출 사이 캐시를 남기지 않는다.

이 실험은 검색 실행 비용만 다룬다. Laya·3진 모델 추론/학습, GPU, 실제 에이전트 토큰 절감 또는 새 품질 증거가 아니다. 기존 최종 예비 평가셋과 모델 파일은 변경하지 않았으며 Hugging Face 배포도 없다. 공개 자료는 원본 합성 fixture·코드·집계이고 원문·경로 목록·정답·pprof 파일은 비공개 로컬에 둔다.

별도의 원본 합성 fixture는 같은 10,000개 경로와 질문을 반복한다. pprof를 켠 3회 benchmark에서 기존 방식은 18.90–19.77ms/op, 약 29.16MB 할당/op, 80,249회 할당/op였고 재사용은 0.1127–0.1130ms/op, 약 0.423MB 할당/op, 21회 할당/op였다. 초기 인덱스 생성은 각 benchmark에 한 번 포함되어 반복 횟수에 분산된다. 이 유리한 반복 조건을 실제 2,400개 결과에 일반화하지 않는다.

결합 pprof의 누적 할당은 순위 배열 생성과 병합에도 집중됐다. 방식별 실행 횟수가 크게 다르므로 전체 누적 바이트 비율은 방식 간 메모리 효율 비교가 아니다. CPU 표본에는 런타임 대기·메모리 반환 비용이 크게 나타났으며, SIMD나 추가 잠금이 해결책이라는 근거는 없다. pprof 누적 할당량은 상주 메모리나 GPU 메모리가 아니다. 전체 race·vet·형식 검사를 통과했다.