한국어 문서 검색 벤치

질문 하나에 정답 문서가 정해져 있고, 모델이 코퍼스 전체에서 정답 문서를 몇 위로 올리는지 봅니다. 큰 숫자는 정답이 10위 안에 든 문항의 비율(recall@10)이고, 그 아래는 1위·5위 안 비율과 MRR 입니다. 파란 칸은 그 평가판에서 가장 높은 값입니다.

주 지표를 recall@10 으로 둔 이유: 정오표에서 정답을 더 찾아 넣은 것은 세 모델이 모두 10위 밖이던 문항뿐입니다. 10위 안에 든 문항에도 정답이 둘인 것이 섞여 있을 수 있어 recall@1 은 조금 낮게 나올 수 있습니다.

분야끼리 점수를 비교하지 않습니다. 코퍼스 크기가 1,519~6,445건로 달라서, 같은 분야 안에서 모델끼리만 비교합니다.

상용 API 는 약관을 확인하지 못해 넣지 않았습니다.

• 순위 매기는 법. 문서를 조각으로 나눠 조각마다 점수를 내고, 문서 점수는 그 문서 조각 중 가장 높은 값으로 합니다. 정답 문서가 몇 위인지 셉니다. 점수가 같은 문서가 있으면 정답을 뒤로 셉니다(정답에 불리하게). 정답이 여럿인 문항은 그중 가장 높은 순위를 씁니다.
• 정오표. 문항 파일은 처음 쓴 그대로 두고, 고칠 것은 정오표에만 더해 읽을 때 적용합니다. 그때까지 잰 세 모델(BM25 · EmbeddingGemma 2 · KURE-v2)이 모두 10위 밖이던 법 분야 문항 216개를 분야별로 정답과 상위 3개 문서 전문을 놓고 다시 판정했습니다. 유효 171 · 정답이 더 있음 41 · 문항 불량 4 로 나왔고, 정답이 더 있는 문항은 정답을 더하고, 불량 문항은 이유를 남기고 뺐습니다. 판례가 바뀐 문항 하나는 정답을 새 판례로 바꿨습니다. 같은 사건의 복사본 판례는 하나만 남겼습니다(같은 판시 문장이라도 다른 사건이면 빼지 않음). 평가판마다 무엇을 고쳤는지는 평가판 페이지의 ‘틀렸던 것’에 있습니다.
• 숨긴 문항. 평가판마다 공개 문항과 별도로 숨긴 문항을 두었습니다(문항 수는 위 표에). 질문·정답·문항별 순위는 내보내지 않고 점수만 공개합니다. 실행할 때 공개 문항과 숨긴 문항을 따로 넣습니다 — 질문도 묶어서 벡터로 바꾸므로 섞으면 묶음이 달라져 공개 문항 값이 흔들립니다. ‘전체’ 점수는 공개 문항만으로 냅니다.
• v1 고정. 판을 공개한 뒤에는 코퍼스·문항·정답·채점 방법·넣는 형식을 바꾸지 않습니다. 묶어 넣는 방식·dtype·max_seq 도 시험 조건으로 같이 고정했습니다. 바꾸면 v2 이고, 다른 판의 점수와 한 표에 섞지 않습니다. 고정한 날과 파일 해시는 평가판 페이지에 있습니다.
• 모델 6개. BM25 는 낱말 기준선입니다. EmbeddingGemma 2 는 원본 가중치(bf16)와 GGUF Q8_0(LM Studio) 두 가지로 쟀습니다. BGE-M3 는 KURE-v1 의 바탕 모델이라 같은 설정으로 재서 한국어 미세조정이 보탠 몫을 봅니다. KURE-v1 은 문서당 벡터 하나, KURE-v2 는 토큰마다 벡터를 두는 ColBERT 방식입니다.

단독 측정이 아닙니다 — 측정 내내 다른 일의 LLM(Gemma 4 26B)이 메모리 약 28GB를 쓰고 있었습니다.

법령검색-v1 · 2026-10-19 08:22:36 ~ 2026-10-19 08:51:27 · M5 Max 128GB · MPS · 모델마다 빈 캐시에서 색인부터 · 모델 사이 120초 식힘

• 메모리는 색인하는 동안의 최대치입니다. 긴 판례를 묶어 넣을 때 PyTorch MPS 할당기가 잡은 양까지 들어갑니다. EmbeddingGemma 2 가 큰 것은 max_seq 8192·bf16·16건 묶음 탓으로 보이지만 확인하지 않았습니다. 질문만 받는 운영 상태의 메모리는 이보다 작을 것으로 보지만 재지 않았습니다.
• 질문 하나 지연 = 질문 하나를 넣어 코퍼스 전체의 점수를 낼 때까지 걸린 시간입니다. 질문 10개로 재서 중앙값을 냈습니다.
• KURE-v2 가 느린 것은 토큰 벡터 200만 개와의 MaxSim 을 근사 없이 직접 계산하기 때문입니다. 근사 색인(PLAID 등)을 쓰면 달라집니다.
• 값이 비어 있는 칸은 0 이 아니라 재지 않은 것입니다.

• 다른 일의 llama-server 28GB 와 LM Studio Gemma 4 가 떠 있었다
  이렇게 둘로 적었는데 틀렸습니다. 같은 것이었습니다 — llama-server 는 LM Studio 가 모델을 돌리는 내부 프로세스입니다.
• EmbeddingGemma 2 의 max_seq 를 2048 로 옮겼다
  이렇게 옮겼는데 틀렸습니다. 다른 곳에서 쓰던 운영값을 그대로 가져왔는데, 법령검색에는 2048 토큰을 넘는 판례가 있어 28건이 잘렸습니다(먼저 잰 벡터와 코사인 최소 0.961, 길이와 상관 -0.48). 결과도 @5 0.47 · MRR 0.356 으로 달랐습니다. 모델 카드 최대인 8192 로 고쳐 같아졌습니다.

옮기며 확인한 것 — 먼저 쓰던 측정 스크립트의 숫자가 이 실행기에서 다시 나오나

1. 위 max_seq 건입니다.
2. KURE 를 글자 길이 순으로 묶어 넣었더니 r@1 이 0.61 로 하나 달랐습니다. 넣은 글자는 같았습니다(토큰 벡터 수 2,072,219개로 똑같음). 먼저 잰 쪽은 토큰 길이 순으로 8건씩 묶었고, 묶음 구성이 바뀌면 MPS 에서 일부 토큰 벡터가 최대 0.095 달라졌습니다. 토큰 길이 순으로 고치니 100문항 순위가 전부 같아졌습니다. 그래서 묶는 방식도 시험 조건으로 보고 v1 에 같이 고정했습니다. 같은 길이끼리의 순서도 정하려고 정렬을 stable 로 바꿨습니다(먼저 잰 쪽은 기본 정렬이라 벡터 최대 차이 0.035 는 남습니다. 순위에는 영향이 없었습니다).
3. EmbeddingGemma 2 는 bf16 으로 돕니다. transformers 5 의 기본 dtype 이 auto 라 모델 설정의 bf16 으로 올라옵니다. 정규화한 벡터 길이가 1 에서 ±0.4% 벗어난 것으로 알아챘습니다. 모델 파일에 dtype: bfloat16 을 적고, 실제 dtype 을 기록에 남기게 했습니다.

이 확인은 법령검색에서 같은 사건 복사본 판례를 빼기 전 코퍼스(해시 54c938f8c031, 5,829건)에서 한 것입니다. 지금 점수와 바로 같지는 않습니다.

레포를 받아 평가판 폴더와 모델 파일을 두고 아래 명령을 돌립니다. 모델마다 필요한 라이브러리 버전이 달라, 실행기가 모델 파일에 적힌 버전으로 임시 환경을 띄워 그 안에서 돕니다.

uv run bench.py run --model <이름>           # 평가판 전부. --suite 세무-v1 처럼 하나만
uv run bench.py compare kure2 gemma2         # 평가판별 지표 + McNemar (각 모델의 가장 최근 기록)

모델 이름: bm25gemma2gemma2-ggufbge-m3kure1kure2

코퍼스 해시는 corpus.jsonl 의 sha256 앞 12자입니다. 문항·숨긴 문항·정오표 파일의 해시는 평가판 페이지에 있습니다.

• 법령검색-v1
  노동법령 조문 2,346 + 판례 3,483 에서 실무 상담 말투 질문의 정답 문서 하나를 찾는다 (known-item)
• 세무-v1
  국세 6법(기본·소득·법인·부가·상속증여·징수)과 세무 판례
• 민사-v1
  민법 재산편(제1~766조)·임대차·이자·제조물책임과 민사 판례
• 가사-v1
  민법 친족·상속편(제767~1118조)·가사소송·가족관계등록과 가사 판례
• 형사-v1
  형법·형사소송법·특가법·성폭력처벌법·도로교통·교통사고특례와 형사 판례
• 개인정보소비자-v1
  개인정보·정보통신망·전자상거래·약관·소비자기본·할부거래와 그 법을 참조한 판례
• 행정-v1
  행정절차·심판·소송·기본법·국가배상·정보공개와 일반행정 판례