보조 검색 주장 모델 09: 작게 학습했지만 아직 이득을 만들지 못함

English · 고정 계획 · 전체 결과와 가중치 해시 · 재현·자원

주 후보는 2,948개 질문 모두에서 보조 검색을 제안하지 않아 기준선을 개선하지 못했다. 이 실패를 기록하고 기본 적용하지 않는다. 질문 수는 2,948개이며, 24개는 질문 수가 아니라 저장한 모델 파일 수다.

무엇을 주장하나

입력은 질문의 모양과 기존 BM25 검색 점수 통계다. 출력은 '식별자 분리 검색을 추가하면 정답 후보에 더 일찍 도달할 수 있을 것 같다'는 가설이다. 정답 판정, 권한 승인, 도구 실행이나 Codex 모델 선택을 수행하지 않는다. 실험에서는 이 주장이 양수일 때 보조 검색과 기존 검색을 번갈아 제안하고, 음수이면 기존 순서를 유지했다. 어느 경우든 전체 후보를 보존한다.

특징은 12개다: 상수항, 단어 수, 바이트 수, 대문자·숫자·밑줄 비율, camelCase 경계 수, 고유 단어 비율, 최고 점수, 1·2위 점수 차이, 상위 10개 양수 점수 비율, 전체 후보 양수 점수 비율. 모두 실행 시 알 수 있다. 정답 함수 이름, 정답 순위, 저장소 정답, 보조 검색 결과는 특징 함수의 입력에 없다. 정답 순위는 학습 라벨과 평가에만 사용한다.

라벨은 '보조 후보를 먼저 내는 교차 순서가 기존 순서보다 알려진 첫 정답 순위를 엄격히 줄였는가'다. 801/2,948개에서 참이었다. 이진 라벨은 개선 크기와 추가 검색 CPU 비용을 직접 표현하지 않는다. 점수 0 이상을 제안으로 처리하는 기준은 실행 전에 고정했고 이번 결과를 보고 낮추지 않았다. 출력 점수를 보정된 확률로 해석하지 않는다.

학습·부모와 자식 모델

사전 학습 인코더 없이 Go로 12계수 층을 처음부터 학습했다. Laya/Model2Vec 전체 인코더를 압축한 결과가 아니다. 의미 모델 실험과 분리된, 검색 제어에 필요한 최소 신호 실험이다.

평가 저장소	학습 저장소	epoch 선택용 검증 저장소
etcd	kubernetes/test-infra	lxc/lxd
kubernetes/test-infra	lxc/lxd	etcd
lxc/lxd	etcd	kubernetes/test-infra

각 fold에서는 평가 질문의 라벨을 학습·epoch 선택에 사용하지 않는다. 전체 코드 후보 색인은 실제 검색 카탈로그로 세 fold 모두에서 볼 수 있다. 원천 설명은 이미 07에서 관찰한 자료이므로 새 독립 최종 시험은 아니다. 다른 fold에서는 같은 저장소가 학습용이 된다. 세 fold의 모델을 합쳐 이 평가가 독립이라고 주장해서는 안 된다.

각 fold/seed마다 FP32와 3진 STE를 별도로 학습했다. FP32에서 INT8과 3진 PTQ가 파생되고, STE는 별도 학습한 형제 모델이다. 3 fold × 2 seed × 2 학습 방식 = 12회 학습, 파생본 포함 24개 파일이다. 학습률 0.1, L2 0.0001, batch 64, 100 epoch를 고정하고 검증 BCE가 최소인 epoch를 선택했다. 주 후보는 FP32/seed1729다.

결과

각 질문은 자신의 저장소를 평가용으로 둔 모델에서 한 번만 집계했다.

방법	보조 검색 호출	첫 후보 정답률	상위 10개 발견률	평균 첫 정답 순위
기존 BM25	0	41.79%	74.83%	48.99
항상 보조 검색 교차	2,948	39.21%	81.51%	26.71
FP32 주 후보	0	41.79%	74.83%	48.99
INT8/seed1729	0	41.79%	74.83%	48.99
3진 PTQ/seed1729	53	41.82%	75.00%	47.73
3진 STE/seed1729	0	41.79%	74.83%	48.99

seed2718의 모든 방식도 보조 검색 호출 0회였다. PTQ 한 구성의 작은 개선을 주 후보로 바꿔 채택하지 않는다. 사전 기준인 평균 순위 10% 개선과 첫 후보/상위 10개 발견률 비하락을 통과한 구성은 없었다. 항상 교차하는 비학습 대조군은 평균 순위를 줄이지만 첫 후보 정답률을 떨어뜨린다. 모델의 작은 크기만으로 유용성을 주장할 수 없다.

다음 가설은 손실·점수 기준과 실제 이득의 불일치다. 단순히 도움 여부를 맞히는 것과 검사해야 할 후보 수를 줄이는 것은 다른 목표다. 다음 별도 실험에서는 기존 첫 후보를 우선 보존하는 순서와 비용을 반영한 학습/검증을 검토한다. 이 결과를 지우거나 기준을 사후 변경하지 않는다.

자원·재현·공개

Apple M4 Pro/Go1.27.1 CPU에서 원천 검증·두 검색·라벨 생성·12회 학습·24개 내보내기를 포함해 wall 1.80초, user CPU 1.44초, 최대 RSS 94,273,536바이트였다. 재실행의 모델 24개와 전체 결과가 바이트 단위로 같았다. GPU는 사용하지 않았다.

한 모델은 계수 12개이며 현재 float64 런타임 계수만 96바이트, 메타데이터 포함 JSON은 521~669바이트다. 전체 프로그램·색인 메모리가 아니다. 3진 값이 들어 있어도 현재 JSON은 압축된 1.58-bit 실행 형식이 아니다. 이미 계산한 3,009개 후보 점수에서 특징을 뽑는 고정 질문 벤치마크는 약 1.75µs/32B 새 할당/1회 할당이었다. 검색과 모델 추론 시간은 이 수치에 포함하지 않는다.

# 앞선 07의 고정 원천과 ZIP을 먼저 준비한다. 출력 폴더는 새 것이어야 한다.
go run ./cmd/riido-claimtrain --out .cache/search-claim-new
go test -race ./internal/searchclaim ./internal/retrievalbench

가중치는 Git에 넣지 않는다. 공개 연구 묶음은 고정 결과·파일 해시와 CI를 확인한 뒤 HF에 게시하는 별도 단계다. 원문 질문·코드·라벨 행과 ZIP은 로컬에만 둔다. riido-hubcheck의 새 계약은 숫자 계수, fold/차원/seed, 명시된 파일 목록과 출처 고지를 확인하고 알 수 없는 모델·manifest 필드를 거부한다. 무결성 검사가 사용성이나 이용 조건 전체를 증명하지는 않는다. .claim.json은 연구 파일이며 기존 riido-hints --model의 .hbin 형식과 호환되지 않는다.

원천은 앞선 07에서 점검한 세 공개 저장소의 코드와 설명이다. 별도 고지가 있는 사례 등을 제외한 절차와 라이선스 한계는 07에 기록했다. 이 모델의 특징은 저차원 통계이며 원문 문자열을 가중치 파일에 저장하지 않는다. CoSQA reserve 두 묶음은 학습·점수 계산에 사용하지 않았다. 실제 사용자 작업, 토큰 절감, 배포 준비 완료는 아직 입증하지 못했다.

검증한 HF 연구 공개

고정 연구 묶음을 공개했다. 24개 가중치와 문서를 포함한 31개 파일을 다시 내려받아 전체 원격 목록·바이트·해시가 로컬 묶음과 같은지 확인했다. riido-hubcheck --require-ci도 통과했다. 소스 84a5f74f779cb7d2d0fbbd65a8f303a0d37da1b4의 CI가 통과했고 PR32는 병합됐다. HF 공개 연구 컬렉션에도 추가했다. 배포 무결성이 확인된 실패 기록이며 품질 합격이나 기본 적용을 의미하지 않는다.