위키 검색이 실제로 얼마나 잘 찾는지 측정한 과정

지난 글에서 위키에 붙인 로컬 하이브리드 검색은 질의 20개에서 상위 5개 안에 정답이 들어오는 비율(hit@5)이 0.95였습니다. 그런데 그 20개는 Claude Code가 작성했고 페이지의 주제 단어가 그대로 들어간 질의가 많아서, 제가 실제로 던지는 질문과는 거리가 있었습니다. 그래서 이번에는 검색을 더 잘 만들기보다 먼저 평가 세트를 늘려 더 정직하게 재 보기로 했습니다.

평가 세트를 세 갈래로 나눴습니다

질의 20개를 그대로 ‘개발용’(dev) 세트로 두고, 같은 방식으로 20개를 더 만들어 40개로 늘렸습니다. 여기에 한 번 확정한 뒤에는 건드리지 않는 ‘홀드아웃’(held-out) 세트를 따로 두었습니다. 개선을 시도할 때는 개발용 세트로 고르고, 고른 설정이 정말 나아졌는지는 홀드아웃 세트로 한 번만 확인하는 구조입니다. 개발용 세트에 맞춰 조정하다 보면 그 세트에만 잘 맞는 설정이 나오기 쉽기 때문입니다.

질의는 종류를 나눠서 만들었습니다. 정확한 용어(exact), 같은 뜻을 다른 말로 쓴 질의(paraphrase), 공통 단어가 거의 없는 느슨한 질의(loose), 여러 페이지가 답인 질의(multi-source), 한국어와 영어를 넘나드는 질의(cross-lingual)입니다. 예를 들어 느슨한 질의 중에 “why the same AI model gives different answers and how designers should handle that”가 있는데, 정답 페이지는 probabilistic-design이고 질의에는 ‘probabilistic’이라는 말이 없습니다. 새 질의는 Claude Code가 페이지를 무작위로 골라 제목의 단어를 쓰지 않고 질문을 만든 다음, 검색을 돌리기 전에 정답 페이지를 먼저 정하는 순서로 작성했습니다. 저는 만들어진 질의 40개를 검토해 문제가 없다고 확인했습니다. 마지막으로 제가 실제로 위키에 묻고 싶었던 한국어 질문 5개를 직접 주었고, 이 질문들의 정답 페이지 후보는 Claude Code가 제시하고 제가 그대로 승인했습니다.

처음 점수는 많이 낮았습니다

세트	하이브리드 hit@5
기존 질의 20개	0.95
개발용 세트 40개	28/40 (0.70)
제가 직접 던진 질문 5개	1/5 (키워드만 쓰면 2/5, 벡터만 쓰면 0/5)

정확한 용어는 12개 모두 찾았지만, 느슨한 질의는 4개 중 0개, 언어를 넘나드는 질의는 3개 중 0개였습니다. 제 질문은 문장이 길고 한국어라서 가장 약했습니다.

시도한 것들, 그리고 통하지 않은 것들

질의를 번역해서 쓰기. 한국어 질문을 영어 모델이 더 잘 다루지 않을까 하는 생각에서, 에이전트가 질의를 영어로 바꿔 검색하게 하면 어떨지 제가 제안했습니다. Claude Code가 번역을 작성해 시험해 보니 번역문으로 원래 질의를 대체하면 점수가 28/40에서 17/40으로 떨어졌습니다. 위키의 페이지는 원래 언어로 저장되어 있어서, 한국어 페이지는 한국어 단어로 찾아야 하기 때문입니다. 반면 원래 질의를 그대로 두고 번역을 하나 더 얹으면 도움이 되었습니다. 홀드아웃 세트에서도 한국어 질의에 영어 번역을 더했을 때 3개를 더 찾았습니다. 영어 질의를 한국어로 바꾸는 쪽은 효과가 없었습니다.

더 큰 임베딩 모델. 용량이 125MB인 검색용 모델(potion-retrieval-32M)로 바꿔 보았습니다. 기본 모델은 30MB입니다. 개발용 세트에서 28/40이던 점수가 27/40으로 오히려 한 개 줄었고, 추가 용량도 처음 정한 한도(+50MB)를 넘었습니다. 그래서 채택하지 않았고 홀드아웃에서는 채점하지 않았습니다.

한국어에서는 하이브리드가 오히려 나빴습니다. 홀드아웃 세트의 한국어 질의에 영어 번역을 더한 설정에서, 키워드 검색은 19개 중 17개를 찾았는데 벡터 검색은 7개, 둘을 합친 하이브리드는 12개였습니다. 영어 중심 모델이 한국어를 제대로 임베딩하지 못해, 합치는 과정에서 키워드가 맞힌 결과가 묻힌 것으로 보입니다. 다만 개발용 세트에서는 하이브리드가 조금 더 나았기 때문에, 표본이 작아서 결론으로 삼기는 어렵습니다.

영어를 먼저 보기로 했습니다

여기서 우선순위를 바꿨습니다. 제 질문은 대부분 영어이고 위키 페이지도 대부분 영어이므로 한국어 검색 품질은 우선순위가 높지 않다고 판단하고, 한국어 관련 개선은 보류했습니다. 영어 질의만 모아 보니(개발용 26개와 홀드아웃 19개, 합쳐 45개) 키워드 30개, 벡터 30개, 하이브리드 33개를 찾았습니다. 영어에서는 합치는 방식이 두 방식보다 낫다는 뜻이어서, 구조 자체는 괜찮다고 보았습니다. 남은 문제는 느슨한 질의였습니다.

채택한 두 가지

새로운 영어 홀드아웃 세트(질의 30개)를 실험 전에 확정하고, 두 가지를 시험했습니다.

페이지 개요 청크. 페이지마다 설명, 별칭, 첫 45단어를 묶은 청크를 하나씩 더 만들어 검색 대상에 넣었습니다. 본문 청크는 문장 단위라서 페이지가 무슨 이야기인지 전체 요지가 검색에 잡히지 않는 문제를 줄이려는 것입니다. 모든 청크의 임베딩에 제목과 설명을 붙이는 변형은 효과가 없어서 버렸습니다.

에이전트가 쓰는 질의 재작성. 검색을 부르는 에이전트가 질문 하나에 짧은 영어 키워드 질의를 2~3개 더 붙이게 했습니다. 재작성은 Claude Code의 서브에이전트(메인 세션과 별도로 띄운 보조 에이전트)가 맡았고, 이 서브에이전트에게는 질의 문장과 위키 영역에 대한 한 문단 설명만 주고 페이지나 정답은 보여주지 않았습니다.

설정	홀드아웃(30개) 하이브리드 hit@5	MRR
기본	24/30 (0.80)	0.71
에이전트 재작성	27/30 (0.90)	0.70
페이지 개요 청크	27/30 (0.90)	0.79
둘 다	29/30 (0.97)	0.80

MRR은 정답이 위에 나올수록 높아지는 지표입니다.

두 가지는 서로 보완했고, 개발용 영어 질의 26개에서도 같은 방향이었습니다(기본 20개, 둘 다 24개). 비용은 인덱스가 약 2MB 늘어나는 정도이고 새로 설치할 것은 없습니다. 이후 제가 채택하기로 결정했고, 개요 청크를 기본값으로 바꾸고 재작성 규칙을 스킬과 AGENTS.md에 넣는 작업은 Claude Code가 했습니다.

에이전트가 정말 재작성을 붙일까

Claude Code가 새 세션을 열어, 도구를 언급하지 않은 채 “AI 제품이 답변을 기다리는 사용자를 어떻게 다뤄야 하는지”를 묻게 했습니다. 새 세션의 에이전트는 질의 뒤에 재작성 두 개를 스스로 붙였고, 가장 위에 나온 페이지를 열어 출처와 함께 답했습니다. 질의 하나로 확인한 것이라 규칙이 꾸준히 지켜진다고 말하기는 이릅니다.

한계

• 홀드아웃 세트는 30개라서 질의 하나가 3.3점에 해당합니다. 27/30과 29/30의 차이는 작습니다.
• 사용한 홀드아웃 세트는 이 설정들에 대해 이미 소진되었습니다. 이후 추가로 바꾸는 설정은 새 세트로 확인해야 합니다.
• 정답 목록이 완전하지 않아서, 실제로는 맞는데 목록에 없어 오답으로 처리된 결과가 있을 수 있습니다. 모든 설정의 상위 결과를 합쳐 사람이 다시 판정하는 작업을 아직 하지 않았습니다.
• 한국어 질의는 보류했으므로 해결된 것이 아닙니다.

마치며

점수가 0.95에서 0.70으로 내려간 것은 검색이 나빠져서가 아니라 질의가 현실에 가까워졌기 때문이었습니다. 질의 세트를 정직하게 만들고 나서야 어떤 개선이 실제로 통하는지 알 수 있었습니다. 시험해 본 더 큰 모델처럼 그럴듯해 보이는 선택은 효과가 없었고, 오히려 개요 청크와 질의 재작성처럼 비용이 거의 없는 두 가지가 점수를 올렸습니다. 다만 표본이 작으므로, 비슷한 규모의 지식 저장소에서 다른 결과를 얻으셨다면 어떤 설정이었는지 들려주시기 바랍니다.

이상으로 위키 검색 품질을 측정하고 개선한 과정에 대해서 알아보았습니다.