실제 파일 위치 평가 — 실험 34

53개 저장소의 실제 수정 작업 2,400개에서 전체 검색 페이지 합계가 약 9.0% 감소했지만, 개선 118개보다 악화 378개가 많았다. 기본 적용과 모델 승격은 보류한다. 이것은 어휘 기반 파일 검색 비교이며 Laya·3진 모델의 성능이나 LLM 비용 절감 결과가 아니다.

계획을 첫 순위 계산 전에 고정했다. 전체·저장소별 결과는 독립 재실행과 바이트 단위로 일치했다. 같은 2,400개 요청 원문과 수정 전 전체 파일 경로를 사용하며 긴 질문이나 큰 저장소를 잘라내지 않았다. 학습·임계값 조정·좋은 결과만 선택하는 과정은 없다.

방식	첫 후보 정답	첫 10개 안 정답	첫 100개 안 정답	첫 정답까지 페이지 합계
원래 경로 BM25	171	769	1,509	45,377
식별자 분리 BM25	173	780	1,524	42,946
원래 검색 우선 교차 병합	171	785	1,530	41,272

정답률 분모는 전체 2,400개다. 주 비교인 교차 병합의 Hit@10은 32.04% → 32.71%, 약 0.67%p 증가했다. 페이지는 후보 20개 묶음이며 기존 파일 정답이 있는 2,398개에서만 계산한다. 개선 118개·악화 378개·동일 1,902개다. 새 파일만 만드는 2개는 비용 계산에서 제외하되 전체 정답률 분모에 남긴다. 기존 파일 정답 3,912개는 모두 후보 목록에 있었다. 파싱 실패·순위 실패·보조 검색 fallback은 모두 0이다.

사전 기준인 전체 페이지 비증가 및 Hit@10 비감소는 통과했다. 그러나 저장소별 페이지 합계는 16곳 개선·23곳 악화·14곳 동일이다. 저장소마다 같은 가중치를 준 Hit@10 평균은 31.56% → 31.39%로 오히려 낮아졌다. 전체 순페이지 절감 4,105 중 Django가 3,296, 약 80.3%를 차지한다. 이는 사후 기술 분석이며 사전 기준을 바꾸거나 통계적 유의성을 주장하지 않는다. 2,400개가 서로 의미적으로 독립이라는 뜻도 아니다.

fileeval.Rank는 요청과 파일 경로만 받는다. 정답은 순위 완성 후 Measure에만 전달한다. 원래 검색과 기존 NormalizeText 식별자 분리 검색을 비교하며 변환 텍스트가 같아도 원래 파일은 별도 후보다. 보조 입력 한도 초과 시 원래 검색으로 복귀한다. 후보는 실행 파일·심볼릭 링크 경로를 포함하며 확장자·테스트·vendor 필터를 적용하지 않고 링크를 따라가지 않는다.

Apple M4 Pro CPU에서 오프라인 전체 프로세스는 52.07초, user CPU 54.33초, system CPU 1.97초, 최대 RSS 113,491,968바이트(약 108.2MiB)였다. 내부 평가 루프 39.41초는 캐시 읽기·두 인덱스 생성·검색·채점·출력을 포함한다. 세 정책을 한 프로세스에서 계산했으므로 각 정책의 단독 실행시간 차이나 순수 추론 시간으로 해석할 수 없다. GPU·모델 추론·학습은 수행하지 않았다.

go run ./cmd/riido-fileeval --out .cache/file-eval-new

고정된 요청·정답 projection과 전체 로컬 파일 목록 캐시가 필요하다. 네트워크 없이 실행하며 하나라도 미확보면 첫 순위 계산 전에 중단한다. 실제 불완전 캐시에서 중단 동작을 검증했다. 공개하는 것은 집계뿐이며 원문·패치·작업별 정답·캐시·프로파일은 올리지 않는다.

페이지 지표는 정답을 정확히 알아보는 동일 비용 확인을 가정하고, 수정 파일 목록도 관련 파일의 완전한 정답은 아니다. 실제 에이전트 성공률·토큰·지연 절감, 난이도·분할·저장소 추천은 검증하지 않았다. 이번 결과를 보고 조정하는 후속 모델에는 이 자료를 개발 평가셋으로 취급하고, 학습과 새 최종 평가는 별도 자료로 분리한다. 기존 최종 예비 평가셋은 사용하지 않았다. 모델 변경이 없으므로 Hugging Face 배포도 없다.