MuSiQue 멀티홉 QA — 지식그래프는 개선이 아니라 전제 조건이다

MuSiQue는 답이 한 문서에 없는 질문으로 구성된 공개 멀티홉 QA 벤치마크입니다. 두 개에서 네 개의 문서를 순서대로 거쳐야 답이 나오고, 중간 단계를 건너뛰면 그럴듯한 오답이 나오도록 설계돼 있습니다.

대조 설계

지식그래프가 검색 품질에 기여한다는 주장은 그래프를 쓴 결과만으로는 증명되지 않습니다. 같은 질문 집합에서 그래프를 뺀 조건이 필요합니다.

세 조건은 질문 집합, 코퍼스, 프롬프트, 추출 파이프라인을 모두 공유하고 융합 가중치만 다릅니다. 코퍼스는 100개 질문의 문단을 하나의 볼트로 합친 것이며, 모든 질문을 그 전체에 대해 묻습니다. 질문별로 자기 문단 20개 안에서만 순위를 매기는 쉬운 설정이 아닙니다.

주지표는 ALL@10으로 잡았습니다. 근거 문단을 전부 회수한 질문의 비율입니다. 2홉 질문에서 두 문단 중 하나만 회수하면 답할 수 없으므로, 멀티홉에서 답변 가능 여부를 실제로 가르는 것은 평균 회수율이 아니라 이 지표입니다.

조건	ALL@10
키워드 검색 전용	23.0%
그래프 제거	25.0%
지식그래프 사용	63.0%

질문별 R@5에 대응표본 부호검정을 적용하면 그래프 제거는 p=4.6e-07, 키워드 전용은 p=2.5e-07입니다. 짝지어 비교한 이유는 질문마다 난이도가 크게 다르기 때문입니다. 두 조건의 평균만 비교하면 어려운 질문이 어느 쪽에 몰렸는지에 따라 결과가 흔들립니다.

홉 수를 나눠 본 결과

전체 평균보다 중요한 것은 홉 수별 분해입니다.

홉	n	그래프 사용	그래프 제거
2홉	52	80.8%	36.5%
3홉	31	54.8%	19.4%
4홉	17	23.5%	0.0%

4홉 질문 17개 중 그래프 없이 근거를 전부 회수한 것은 하나도 없습니다. 낮은 것이 아니라 0입니다.

이 차이는 정도의 차이가 아니라 종류의 차이입니다. 키워드 검색으로는 4홉 질문을 맞히는 경로 자체가 존재하지 않습니다. 첫 번째 문서에서 두 번째 문서를 가리키는 단서는 표면 어휘가 아니라 관계이고, 관계는 색인돼 있지 않으면 검색될 수 없습니다.

그래서 이 결과의 결론은 “그래프를 쓰면 검색이 좋아진다”가 아닙니다. 어떤 질문 부류에서는 그래프가 성능 개선 요소가 아니라 전제 조건입니다.

이 실행이 실제로 바꾼 결정

45개 구성을 훑는 가중치 스윕을 같은 코퍼스에서 돌렸더니 상위 6개 구성이 전부 키워드 가중치 0이었습니다. 그리고 그 결과는 자체 볼트의 측정과 정면으로 어긋납니다.

코퍼스	키워드 가중치 1.0	키워드 가중치 0	효과
실제 볼트 (recall@10)	95.3%	88.0%	+7.3pp, 도움
MuSiQue (R@5)	61.9%	77.1%	−15.2pp, 손해

같은 파라미터가 한 코퍼스에서 돕고 다른 코퍼스에서 비슷한 크기로 해칩니다. 원인은 MuSiQue의 구성 방식에 있습니다. 이 벤치마크의 방해 문단은 질문과 주제가 겹치도록 일부러 고른 것이라 어휘적으로 함정이고, 키워드 검색은 정확히 그것들을 끌어올립니다.

출하 가중치는 바꾸지 않았습니다. 사용자의 볼트는 본인이 쓴 노트이지 헷갈리도록 선별된 위키피디아 문단 집합이 아닙니다. 두 개의 실제 볼트에서 검증된 값을 벤치마크 점수를 위해 되돌리는 것은 벤치마크 과적합이고, 여기서 대표성이 낮은 쪽은 벤치마크입니다. 이 실행이 산 것은 점수가 아니라 반례입니다. 현재 가중치가 보편적으로 최적이 아니라 두 볼트에 대해 최적이라는 사실을 이제 측정으로 갖고 있습니다.

실제 볼트에서 다시 확인한 것

공개 벤치마크는 코퍼스가 정제돼 있어 실제 사용 환경과 다릅니다. 그래서 같은 비교를 실제 볼트 두 개에서 반복했습니다. 지표는 recall@10, 검정은 대응표본 정확 McNemar입니다.

볼트	전체 융합	키워드 전용	McNemar p
Market (n=150)	90.7%	60.0%	3.5e-13
e2e (n=150)	76.0%	37.3%	6.9e-18

네 개 비교 중 세 개에서 대조군이 얻은 질문은 0개입니다. 순수한 손실이지 재배치가 아닙니다. 그리고 이 질문 계층은 하니스가 “질문에 주어가 그대로 나오는” 조건으로 뽑은 것이라 키워드 검색에 가장 유리합니다. 대조군을 약하게 잡으면 이겼다는 사실이 아무것도 말해주지 않습니다.

표본 크기가 결론을 뒤집은 사례

같은 그래프 제거 비교를 하니스 기본값인 n=40으로 돌리면 −5pp, 질문 2개 차이, p=0.25가 나옵니다. 잡음과 구별되지 않습니다. n=150에서 같은 비교는 −12pp, p=4e-05입니다.

기준선 회수율 자체는 두 표본에서 안정적이었습니다(90.0% 대 90.7%). 움직인 것은 수준이 아니라 효과 추정치이므로, 이것은 편향이 아니라 분산입니다. 그래서 더 위험합니다. 숫자가 그럴듯해 보입니다. 원안대로 n=40에서 돌렸다면 위음성이 나왔고, 검색 로드맵의 우선순위가 잘못 정해졌을 것입니다.

한계

• 절대 점수를 공개 수치와 비교하면 안 됩니다. 이 실행의 풀은 100개 질문에서 나온 1,730개 문단입니다. 공개된 MuSiQue 검색 수치는 보통 1,000개 질문, 약 12,000개 문단이고, 풀이 커지면 회수율은 떨어집니다. 이 설정이 더 쉽습니다.
• 스윕 최댓값을 우리 시스템의 점수로 인용하면 안 됩니다. R@5 78%는 키워드 가중치 0인 구성의 값이고, 그 구성은 실제 볼트에서 더 나쁩니다. 출하 구성의 점수는 62.2%입니다.
• 공개된 베이스라인을 1차 출처와 대조하지 않았습니다. 같은 시기 감사에서 외부 인용의 약 3분의 1이 사실 확인을 통과하지 못했기 때문에, 기억에 의존한 수치는 여기 적지 않았습니다.
• 검색만 측정했습니다. 리더 단계의 EM/F1 점수는 산출하지 않았습니다. 다른 지표입니다.
• 그래프 구축 비용은 표에 없습니다. 저장 시점에 증분으로 처리되지만 0은 아닙니다.

측정 기록

항목	값
실행 시점	2026년 7월 26일
데이터셋	MuSiQue-Ans dev, 100문항을 홉 수 층화로 고정 시드 추출 (2홉 52 / 3홉 31 / 4홉 17)
코퍼스	고유 문단 1,730개, 문단당 마크다운 노트 1개, 전부 하나의 볼트로 통합
추출	테스트 하니스가 아니라 실제 앱 파이프라인. 문서 그래프 1,727/1,730, 엔티티 9,499, 쿼드 63,492, 임베딩 결손 0
추출 비용	약 $45
하니스	eval/musique_prep.py + qa_eval.rs::musique_multihop
실볼트 A/B	2026년 7월 26일, Market 및 consilience-e2e, n=150, 출하 경로 그대로

그래프 제거 조건과 45개 구성 스윕은 같은 하니스에서 설정만 바꿔 돌렸습니다. 질문별 출력 줄에 홉 수와 질문 id와 R@5가 실려 있고, 부호검정은 그 줄을 입력으로 씁니다.

층화 추출은 선택이 아닙니다. dev 파일은 홉 유형 순으로 정렬돼 있어서 앞에서 N개를 취하면 100% 2홉이 뽑히고, 가장 쉬운 슬라이스를 조용히 측정하게 됩니다.

측정 기록 원본은 Consilience 저장소의 docs/details/musique-multihop-2026-07-26.md와 docs/details/retrieval-ablation-2026-07-26.md에 있습니다.