Long Query 32 KO

긴 요청을 버리지 않는 검색 입력 — 실험 32

고정한 실제 요청 2,400개를 잘라내지 않고 모두 검색 함수에 통과시켰다. 기존 8,192바이트 한도를 넘는 53개도 포함한다. 검색 대상은 비용 확인용 합성 문서이므로 실제 작업의 정답 검색률을 측정한 것은 아니다.

사용 방법

Go pkg/hintsearch에 선택적으로 사용하는 Index.RankLongInto(query, dst)를 추가했다. UTF-8 원문을 최대 128KiB까지 받아 한 번 토큰화하고, 기존과 같은 고유 검색어 BM25 및 동점 순서를 사용한다. 요약·분할·잘림은 없다. 상한 초과나 잘못된 입력은 버퍼를 바꾸기 전에 오류로 반환한다.

index, err := hintsearch.New(documents)
if err != nil { return err }
ranking, err := index.RankLongInto(completeRequest, hintsearch.Ranking{})
if err != nil { return err }
// ranking.Order는 원래 문서 위치다. 다음 요청에서 ranking 버퍼를 재사용할 수 있다.

기존 Rank/RankInto의 8KiB 한도는 그대로다. 인덱스는 불변이고 결과 버퍼는 호출자 소유다. 동시에 호출할 때 버퍼를 공유하지 않는다. 모델·특징 추출·CLI·세션의 입력 한도를 확대하거나 긴 입력을 학습 모델에 연결한 변경은 아니다. 후속 평가 및 Go 호출자가 원문 전체의 lexical 기준선을 사용할 수 있게 한 것이다.

실제 실행 결과

사전 계획을 고정한 다음 기존 projection에서 같은 선택 해시를 다시 계산했다. 문서는 document 0000 source code ... 형식의 자체 합성 자료 4,096개다. 문서 번호 외의 단어가 대부분 같아 실제 저장소보다 단순하다. 정답이나 패치를 읽지 않았다.

항목	결과
전체 요청 / 성공 / 실패	2,400 / 2,400 / 0
8KiB 초과 요청	53
원문 합계 / 최대 길이	4,363,135 / 71,136바이트
잘린 요청	0
짧은 입력 기존 결과 비교 / 불일치	2,347 / 0

점수 배열과 전체 문서 순서를 정확히 비교했다. 집계는 재실행에서 바이트 일치했다. 마지막 검색어가 8KiB 뒤에 있는 사례의 점수를 독립적인 BM25 계산으로 확인했고, Unicode 경계·상한·오류 시 버퍼 보존·동시 호출도 테스트했다. 전체 Go race/vet, 형식 및 redacted 보안 검사를 수행한다.

비용과 한계

M4 Pro CPU에서 마지막 실행의 검색 루프 2,400회는 109,067,791ns(약 0.109초), 누적 Go 할당 43,429,152바이트, 할당 16,741회였다. 호출자 결과 버퍼는 자체 fixture로 먼저 준비했다. 이 측정에는 검색 루프만 포함되며 원천 읽기·선택·인덱스 생성·짧은 입력 비교는 제외한다. 누적 할당량은 최대 상주 메모리가 아니다.

전체 프로세스는 wall 0.92초/user 0.56초/sys 0.02초, 최대 RSS 35,749,888바이트(약 34.1MiB)였다. 시간과 할당값은 실행별로 달라질 수 있어 결정적인 결과 JSON과 별도로 기록한다. 합성 문서 비용을 실제 저장소 검색·모델·GPU·LLM 비용으로 확대하지 않는다.

이제 긴 요청 때문에 53개 작업을 제외할 필요가 없다. 다음은 수정 전 파일 목록을 준비해 실제 파일 후보에서 검색과 힌트의 효과를 측정하는 것이다. 이 결과는 라우팅·난이도·작업 분할 품질을 입증하지 않는다. 새 학습·HF 배포·기본 활성화는 없으며 최종 예비 평가셋도 사용하지 않았다.

후속: 실험 33에서 전체 2,400개 실제 파일 목록과 분리된 파일 위치 정답을 확보했다. 실제 검색 순위 비교는 후속 평가에서 진행한다.