PDCA 02: 강한 검색 기준선과 틀린 힌트의 비용 제한

English · 전체 결과 · 기획

이번에 쓸 수 있는 것

pkg/hintsearch는 Go만으로 BM25 검색과 외부 힌트의 순서 조합을 제공한다. cmd/riido-hints는 같은 기능을 JSON 입출력으로 제공한다. 모델 다운로드·Python·GPU 없이 실행한다. 기존 라우터 설정을 변경하지 않는다.

go run ./cmd/riido-hints < examples/hints/request.json

예시는 의도적으로 틀린 cache 힌트를 먼저 준다. 출력의 첫 후보는 cache, 두 번째는 BM25가 찾은 payments다. 모든 후보가 남고 상태는 항상 unverified다. bm25_score는 원래 문서 관련성 점수이며 최종 순서의 신뢰 확률이 아니다. hints를 생략하면 BM25 순서만 반환한다.

사람은 JSON 문서 목록을 편집해서 시험할 수 있고, 에이전트는 동일한 stdin/stdout 계약을 사용할 수 있다. 실제 저장소를 읽거나 API를 호출하지 않는다. 사용자가 접근 가능한 문서만 넣어야 하며 snapshot ID는 호출자가 카탈로그·권한 변경마다 갱신해야 한다. CLI가 실제 내용의 버전을 암호학적으로 증명하지는 않는다. 힌트의 query/snapshot 불일치, 중복/알 수 없는 ID는 오류로 거부한다. 입력 오류는 비정상 종료하며 일부 결과를 먼저 내보내지 않는다.

반환 결과를 실행 명령으로 취급하지 않는다. 후속 검증기는 하나씩 검사하고, 예산 종료 시 incomplete를 반환해야 한다. 이 CLI 자체는 검증·예산 집행·캐시를 아직 구현하지 않는다.

왜 번갈아 확인하나

원래 검색 목록 B와 학습기 등의 힌트 목록 H에서 번갈아 하나씩 꺼내며 이미 확인할 예정인 후보는 건너뛴다. H는 일부 후보만 제공해도 된다. B는 전체 후보를 유지해야 한다.

증명 범위: 원래 r번째 후보보다 앞선 B 후보는 r−1개다. 매 회전은 H에서 최대 1개, B에서 아직 나오지 않은 후보 최대 1개를 출력한다. H가 B의 앞 후보를 먼저 내보내면 B의 진도는 더 빨라진다. 따라서 r번째 원래 후보는 늦어도 r회전, 즉 min(N, 2r)번째까지 나온다. 전체 순서에는 중복이나 누락이 없다.

이것은 동일 단위 비용의 정확한 단일 후보 검증 횟수에 대한 보장이다. 느린 후보, 여러 근거를 모으는 작업, 힌트 생성비, LLM 토큰, 총 응답 시간에는 그대로 적용되지 않는다. 불완전한 검증기의 오답도 해결하지 않는다. 외부 힌트 생성에 별도 시간/메모리 한도가 필요하다. 효율 향상 보장이 아니라 손해를 제한하는 장치다.

구현과 검증

• BM25 k1=1.2, b=0.75. 단어 빈도·문서 길이·희귀도를 사용한다. query 중복 단어는 한 번만 계산한다. 의미 모델이 아니다.
• 정렬된 어휘와 연속된 posting 열 배열(doc 위치, 빈도), 문서 정규화 배열을 사용한다. 공유 index는 불변이며 query 경로에 map·lock이 없다. 결과 배열은 호출별로 소유한다. Go 런타임 내부 동기화가 없다는 뜻은 아니다.
• 1..4096문서, 문서 본문 합계 2MiB, query 8192B, 인코딩된 CLI JSON 16MiB 한도. 입력 한도가 전체 RSS 한도와 같지는 않다.
• 수식 수치 대조, 빈 문서·한국어 토큰, query/catalog 한도, 동시 호출, stale 힌트 거부를 검사한다. 한국어 토큰화 통과는 한국어 의미 검색 품질의 증거가 아니다.
• 최대 7후보의 모든 힌트 순열과 모든 길이의 prefix를 열거해 2r 한계와 보존을 검증했다. 최종 모델 학습 성능 테스트와는 다르다.

같은 52개 개발 요청으로 측정

방법	Recall@1	Recall@4	평균 oracle 검증	BM25 대비 최대 개별 검증 비율
BM25	52.08%	75.00%	4.615	1.0
token 힌트 + BM25 교대	52.08%	75.00%	4.615	1.0
고정 난수 힌트 + BM25 교대	6.25%	75.00%	5.308	2.0
BM25 역순 힌트 + BM25 교대	2.08%	75.00%	5.385	2.0

모든 방법의 정답 없음 4건은 16번 모두 확인했다. BM25도 직접 표현 16/16, paraphrase 1/16, 대조 8/16으로, 기존 정확 토큰 기준선과 동일하다. 이것은 의미 학습 개선이 아니다. 부실한 힌트는 평균 비용을 악화시켰으며, 아무 힌트나 추가하면 이득이라는 가설은 지지되지 않는다. 같은 개발 자료를 재사용했으므로 새 final 성과로 보고하지 않는다.

이번 단일 run에서 BM25 warm p95는 0.625µs, 전체 9방법 비교 프로세스 최대 RSS는 11,862,016B(11.31MiB), peak footprint는 9,732,576B, wall 0.48초, user CPU 0.10초, swap 0이었다. 16후보 query 토큰화·점수·정렬을 포함하고 초기 index 생성과 검증은 제외한다. 고정 순서 벤치마크의 작은 시간 차이는 실행 순서/노이즈 영향을 받으므로 CPU 가속 비율을 주장하지 않는다.

64개 동일 문서로 만든 별도 dense-posting microbenchmark는 523.7ns/op, 1128B/op, 5allocs/op이었다. 실제 저장소 품질·실제 부하를 대표하지 않는다. pprof 표본의 대부분이 Go 런타임 대기/메모리 관리에 있어 SIMD나 새 lock 최적화의 근거로 사용하지 않았다. 원시 CPU/heap 프로파일은 공개하지 않는다. GPU 사용·전력 절감·LLM 비용은 측정하지 않았다.

다음 단계

이제 학습 모델의 힌트 순서를 동일 CLI와 검증 계약에 끼울 수 있다. 하지만 아직 학습 모델은 없고 HF 릴리스도 없다. 다음 사이클은 가족 분리된 공개 데이터, BM25·가벼운 학습 기준선, FP32/INT8/3진 비교다. 새로운 의미 가족 final을 봉인하고, 단순 토큰/BM25보다 실제로 검증 비용이 줄어드는지 확인한다. 현재 목표는 완료되지 않았다.