Call Change Audit 26 KO

보조 검색 호출 변경과 큰 손실 분석 26

고유 질문 2,948개를 모두 유지한 분석에서, 주 비교의 페이지 증가 150 중 144가 한 질문에 집중됐다. 기존 16개 특징 모델에서 새 20개 특징 모델로 바꿀 때 크게 도움이 되던 보조 검색을 생략한 것이 주된 손실 원인이다. 이 질문을 제외하거나 기준을 완화하지 않는다.

비교 방법

사전 계획에 따라 실험21과25의 공개 아카이브 해시를 검증하고 고정 모델·임계값을 그대로 재생했다. 재학습이나 재보정 없이 저장소별 및 전체 기존 지표를 정확히 재현했다. 질문마다 두 정책 모두 호출하지 않음 / 새 정책만 호출 / 이전 정책만 호출 / 모두 호출의 네 경우로 나눴다.

24개 같은 모델 파일 수와 질문 수를 혼동하지 않는다. 이 분석은 질문2,948개, 후보3,009개이며 두 초기값은 같은 질문을 반복한 비교다. 저장소3개의 이미 관찰한 개발 자료이므로 새로운 독립 평가가 아니다.

결과

초기값	이전→새 페이지	이전→새 호출	악화 질문 / 증가 페이지	개선 질문 / 감소 페이지	최대 한 질문 / 전체 증가
1729	6,326→6,439	2,408→2,363	4 / 150	12 / 37	144 / 150 (96%)
2718	6,331→6,440	2,317→2,328	3 / 147	13 / 38	144 / 147 (97.96%)

집중도의 분모는 손해가 난 질문들의 증가 페이지 합이다. 순증가113으로 나누지 않는다. 각 초기값에서 한 질문이144페이지 증가했다는 결과이며, 집계만으로 두 초기값의 질문이 동일하다고 주장하지 않는다.

주 초기값에서 새 정책만 호출한127개 질문은 순31페이지를 절약했다. 이전 정책만 호출한172개 질문은 새 정책에서 순144페이지를 더 요구했다. 새 정책이 잡아낸 유익한 호출 수는315→320으로 늘었지만, 놓친 이익의 크기는53→170페이지로 늘었다. 유익한 사례를 더 많이 맞히더라도 큰 이익을 놓치면 전체 비용이 악화될 수 있다.

다음 가설: 생략을 되돌릴 기회

첫 응답에서 보조 검색을 생략했더라도 사용자가 다음 페이지를 요청하면 한 번 실행하는 방식을 별도 실험으로 검토한다. 런타임은 정답을 알 수 없으므로 실제 후속 요청만 계기로 삼아야 한다. 평가의 정답 도달 시점은 사용자가 멈추는 상황을 흉내 내는 별도 가정이며 실제 사용자 검증과 같지 않다.

이 방식의 이득은 아직 측정하지 않았다. 별도 계획에서 비교군·페이지 순서·중복 제거·호출 수·완료 품질·자원 비용을 고정해야 한다. 큰 손실 질문을 남기고, 기존 정적 모델의 실패 기록과 합격 기준도 유지한다.

검증과 제한

전체 집계 보고서는 재실행에서 바이트 단위로 일치했다. 합성 테스트로 네 호출 변화, 손익 부호, 합계 보존, 집중도 분모, 손실 구간 및 잘못된 순위를 검사했다. 전체 Go race 검사와 vet도 통과했다.

M4 Pro CPU에서 원천 검증·특징 계산·두 정책 재생·집계 전체는 wall1.83초, user1.42초, peak RSS98,238,464바이트(약93.7MiB)였다. 단일 추론 시간이나 GPU 메모리 측정이 아니다.

go run ./cmd/riido-callchange --out .cache/call-change-new

전체 집계. 새 모델이나 HF 가중치는 만들지 않았다. Git에는 질문 원문·개별 정답·모델 가중치·프로파일을 넣지 않는다. 실제 LLM 비용 절감과 실사용 적합성은 미검증이다. 학습·튜닝과 분리된 새로운 실제 요청 최소2,400개의 최종 평가가 여전히 필요하다. 검색 결과를 모델 선택·저장소 선택·작업 분할의 성능 증거로 전용하지 않는다.

PR #49 · CI

Follow-up: deferred helper experiment27.