Rank Reuse 08 KO

순위 배열 재사용 08: 결과를 유지하며 누적 할당 약 97% 감소

English · 전체 측정 · 검색 자료와 한계

반복 검색의 메모리 할당은 줄었지만, 큰 검색 속도 개선이나 상주 메모리 감소는 입증하지 못했다. 이전 2,948개 질문/3,009개 후보를 그대로 사용했다. 새 학습, 평가 자료 선별, 검색 점수 변경은 없다.

변경과 사용

pkg/hintsearch.Index.RankInto(query, previous)가 호출자 소유의 순위·점수 배열을 재사용한다. 기존 Rank는 독립된 결과를 반환하는 계약을 유지한다. 점수 계산, 동점 처리, 0점 후보와 전체 후보 보존은 동일하다.

var scratch hintsearch.Ranking
for _, query := range queries {
    var err error
    scratch, err = index.RankInto(query, scratch)
    if err != nil {
        return err
    }
    // Consume scratch.Order and scratch.Scores before the next call.
}

다음 호출은 같은 배열을 덮어쓴다. 결과를 오래 보관하려면 복사하거나 기존 Rank를 사용한다. 여러 작업자가 동시에 검색하면 작업자마다 별도의 배열을 둔다. 색인은 불변이며 공유 풀·맵·뮤텍스를 추가하지 않았다. 잘못된 질문은 기존 배열을 수정하기 전에 거부한다. 더 큰/작은 색인에서 재사용해도 필요한 길이로 조정하고 남은 점수를 초기화한다.

한 번만 요청을 처리하는 riido-hints CLI가 이번 변경으로 반복 검색 수준의 절감을 얻는다는 주장은 하지 않는다. 주된 사용처는 같은 색인에 여러 번 질문하는 Go 호출자와 향후 daemon이다. 평가 CLI에서는 --reuse-rank로 직접 사용할 수 있다.

실제 자료의 결과 보존과 할당

기존 방식 → 재사용 → 재사용 → 기존 방식 순서로 네 번 실행했다. 각 실행에서 두 검색 방식(raw/identifiers)을 모두 평가했다. 질문별 모든 후보 순서와 float64 점수 비트를 해시했고 네 실행에서 일치했다. 기존 07의 전체·이름 유무·저장소별 품질 지표도 모두 같았다.

실행	질문 처리 루프의 누적 할당 합계	전체 wall	최대 RSS
기존 1	298,879,080 B	1.89초	102,465,536 B
재사용 1	9,176,888 B	1.50초	92,291,072 B
재사용 2	9,176,888 B	1.50초	93,503,488 B
기존 2	298,884,224 B	1.52초	91,062,272 B

누적 할당은 약 96.93% 감소했다. 이 합계는 두 방식으로 각각 2,948번 검색하는 루프의 Go TotalAlloc 차이이며 전처리·추적 해시·평가 집계도 포함한다. 동시에 살아 있는 메모리나 모델 크기가 아니다. 원천 ZIP 검증과 색인 준비는 루프 할당에서 제외하지만 전체 wall/RSS에는 포함한다. 두 번째 기존 방식의 RSS가 재사용보다 낮았으므로 최대 RSS 개선을 확정하지 않는다. 개별 검색 p95도 거의 같았으며 JSON에 원값을 남겼다.

작은 벤치마크

원본 공개용 고정 문자열로 후보 64개/3,009개를 만들고 같은 질문을 반복했다. 각 구성 300ms씩 5회 측정한 중앙값이다. 이것은 실제 질문 2,948개의 다양성을 대체하지 않는다.

후보 수	방식	호출당 새 할당	호출당 할당 횟수	시간 중앙값
64	기존	1,112 B	5	655.3ns
64	재사용	88 B	3	588.9ns
3,009	기존	49,240 B	5	59,595ns
3,009	재사용	88 B	3	59,493ns

3,009개 후보의 호출당 할당은 약 99.82% 줄었지만 속도 차이는 미미했다. 재사용 배열이 없어지는 것은 아니다. 결과 배열은 준비 후 호출자가 보유하고, 88바이트는 그 이후 각 호출의 새 할당만 센다. 남은 비용은 질문 토큰화와 정렬 등에 있다. SIMD 효과를 측정한 실험이 아니다.

재현과 검증

Apple M4 Pro/Go1.27.1 CPU. 앞선 07의 고정 원천과 ZIP을 준비하고 실행한다.

go test -race ./pkg/hintsearch ./internal/retrievalbench
go test ./pkg/hintsearch -run '^$' -bench BenchmarkRankReuse -benchmem -benchtime=300ms -count=5
go run ./cmd/riido-retrievalbench --stage evaluate
go run ./cmd/riido-retrievalbench --stage evaluate --reuse-rank

회귀 시험은 서로 다른 질문으로 남은 점수 지우기, 무매칭·동점 후보 보존, 색인 크기 변경, 잘못된 입력의 비수정, 작업자별 버퍼를 사용한 동시 검색을 검사한다. 기존 BM25 계산 참조 시험과 후보 보존 시험도 유지했다.

이 결과는 검색 런타임의 할당 개선이다. 새로운 모델 성능이나 실제 에이전트 성공률·LLM 절감을 입증하지 않는다. 다음 의미 모델 실험은 검색 도움 여부를 런타임에서 관측 가능한 신호로 예측하되 별도 자료·기준으로 검증해야 한다.