MIRACL을 읽고 다국어 Hybrid baseline을 MES의 정답으로 옮길 수 없는 이유

MIRACL 논문을 읽었다.

처음에는 한국어에서도 BM25와 Dense를 합치면 좋아진다는 근거를 찾으려고 읽었다. 실제 결과는 그 생각을 어느 정도 지지했다. 한국어에서 BM25와 mDPR의 nDCG@10은 각각 0.419였고, 두 점수를 합친 Hybrid는 0.609였다.

하지만 논문을 읽고 더 오래 남은 것은 0.609라는 숫자가 아니었다. 그 숫자가 나오도록 query와 정답을 어떻게 만들었는가였다. MIRACL은 다국어 검색 모델 논문이기 전에, 18개 언어의 검색 평가 데이터를 직접 만든 benchmark 논문이다.

요약본

무엇을 만들었나

MIRACL은 query와 passage가 같은 언어인 monolingual retrieval dataset이다. 18개 언어의 Wikipedia passage를 대상으로 78,000개가 넘는 query와 726,000개가 넘는 relevance judgment를 제공한다. query 작성과 관련성 판정은 해당 언어의 native speaker가 수행했다.

어떻게 만들었나

annotator는 Wikipedia 글의 앞부분을 prompt로 보고, 그 prompt만으로 바로 답할 수 없는 자연어 질문을 만들었다. 이후 BM25, mDPR, mColBERT가 검색한 후보의 점수를 정규화·결합하고, 상위 passage를 사람이 관련 또는 비관련으로 판정했다.

왜 이렇게 만들었나

기존 다국어 dataset에는 번역체 query, 합성 label, 적은 언어 수, 한 Wikipedia 문서 안에서만 찾은 정답 같은 한계가 있었다. MIRACL은 native query, 전체 Wikipedia 검색, 여러 retriever가 만든 후보, 명시적인 negative judgment로 이 문제를 줄이려 했다.

결과는 무엇이었나

개발셋 전체 평균 nDCG@10은 BM25 0.385, mDPR 0.418, BM25+mDPR Hybrid 0.566이었다. 결합은 강한 zero-shot baseline이었다. 그러나 모든 언어에서 이긴 것은 아니다. Indonesian에서는 BM25가 Hybrid보다 조금 높았고, Yoruba에서는 Hybrid가 BM25와 mDPR보다 모두 낮았다.

내가 이 논문에서 가져갈 결론은 다음 한 문장이다.

다국어 검색에서도 lexical과 Dense가 서로 다른 정답을 보완할 가능성은 컸다. 그렇다고 고정 비율 Hybrid가 언어와 업무 domain을 가리지 않는 정답이라는 뜻은 아니다.

무엇을 평가한 논문인가

MIRACL의 중심 문제는 ad hoc retrieval이다. 사용자가 질문을 입력하면 같은 언어의 corpus에서 관련 passage를 순서대로 반환한다.

여기서 먼저 구분해야 할 것이 있다.

MIRACL
한국어 query → 한국어 Wikipedia passage
태국어 query → 태국어 Wikipedia passage

cross-lingual retrieval
한국어 query → 영어 passage

MIRACL은 첫 번째 문제를 다룬다. 여러 언어를 한 dataset에 넣었다는 이유로 번역 검색이나 cross-lingual 검색 성능까지 확인한 것으로 읽으면 안 된다.

18개 언어는 10개 language family와 13개 sub-family, 11개 script에 걸쳐 있다. 논문이 강조한 것은 언어 개수만이 아니었다. 공개 자원이 많은 영어·중국어뿐 아니라 Telugu, Swahili, Yoruba처럼 검색 연구에서 상대적으로 덜 다뤄진 언어도 포함했다.

이 dataset이 필요했던 이유는 기존 다국어 평가셋의 생성 방식과 연결된다.

• 영어 query를 다른 언어로 번역하면 실제 사용자가 만드는 query와 다른 translation artifact가 남을 수 있다.
• Wikipedia title이나 entity를 query로 쓰면 자연어 정보 탐색을 충분히 반영하지 못한다.
• BM25 점수로 relevance를 자동 생성하면 lexical 방식에 유리한 평가셋이 될 수 있다.
• 한 문서의 passage만 정답 후보로 보면 다른 문서에 있는 관련 passage를 놓친다.

MIRACL은 번역이나 자동 label 대신 native speaker가 query와 judgment를 만들도록 했다. 데이터 수집에는 31명의 annotator와 10,000시간 이상, 논문 표현으로 약 5 person-years가 들었다.

어떻게 query와 정답을 만들었나

query는 검색 결과를 보기 전에 만들었다

annotator는 무작위 Wikipedia article의 첫 100단어를 prompt로 받았다. 그 내용에서 궁금증을 떠올리되, prompt 자체로 바로 답할 수 있는 질문은 피했다. 답이 명확할 것 같은 완전한 자연어 질문을 작성했고, 떠오르는 질문이 없으면 prompt를 건너뛸 수 있었다.

중요한 점은 이 단계에서 annotator가 검색 결과를 아직 보지 않았다는 것이다. 연구팀도 Wikipedia와 관련된 질문을 쓰라고 직접 말하지 않았다. 검색기에 잘 걸리는 단어를 보고 query를 역으로 만드는 bias를 줄이려는 설계로 이해했다.

동시에 query가 완전히 자연 발생한 것도 아니다. Wikipedia의 한 부분이 질문을 떠올리게 하는 prompt였다. 실제 MES 사용자가 작업 도중 입력하는 짧은 화면명, 에러 코드, 불완전한 구어체와는 출발점이 다르다.

정답 후보는 세 retriever가 만들었다

relevance assessment의 후보는 다음 세 방식에서 왔다.

각 방식이 query마다 상위 1,000개 passage를 검색했다. 세 점수를 0~1 범위로 정규화한 뒤 평균해 최종 순위를 만들고, 상위 10개 passage를 annotator가 binary relevance로 판정했다.

Mr. TyDi에서 이어받은 11개 언어의 기존 query에는 예외가 있었다. passage segmentation이 달라져 기존 정답을 그대로 연결할 수 없었기 때문에, 연구팀은 과거 relevant passage를 query처럼 사용해 새 MIRACL corpus를 BM25로 검색했다. 점수 차가 크면 상위 1개, 그렇지 않으면 상위 5개를 추가 후보로 넣어 사람이 다시 판정했다. 따라서 모든 judgment가 세 retriever의 단순 top-10에서만 나온 것은 아니다.

한 종류의 검색기만으로 pool을 만든 것보다 lexical, single-vector, multi-vector의 오류를 섞으려 한 점이 좋았다. 명시적으로 판정한 hard negative도 학습 데이터로 쓸 수 있다.

그래도 pool의 바깥은 판정하지 못한다. 네 번째 방식이 세 baseline과 전혀 다른 관련 passage를 찾으면 qrels에 없을 가능성이 남는다. query-passage 한 쌍도 한 annotator만 판정했다. 별도의 native reviewer가 표본을 검사했지만 모든 label을 여러 사람이 독립 판정한 구성은 아니다.

결과를 어떻게 읽었나

평균에서는 Hybrid가 분명히 강했다

MIRACL 개발셋의 주요 결과는 다음과 같다.

Hybrid는 BM25와 mDPR의 점수를 각각 0~1로 정규화하고, tuning 없이 0.5 대 0.5로 합쳤다.

s_hybrid = 0.5 × s_BM25 + 0.5 × s_mDPR

별도 가중치 탐색도 하지 않은 결합이 평균에서 각 retriever보다 높았다. 이 결과는 두 방식의 error가 완전히 같지 않았다는 근거로 볼 수 있다. BM25가 같은 term이 있는 passage를 잡고 mDPR이 표현이 다른 passage를 보충했다면, 합친 후보와 점수가 상위 10개와 상위 100개의 관련 문서를 늘릴 수 있다.

다만 논문은 query별 overlap이나 각 방식만 찾은 relevant passage 수를 표로 직접 분해하지 않았다. 따라서 “왜 0.566이 됐는가”에 대한 위 설명은 결과에 맞는 해석이지, 논문이 모든 query에서 원인을 검증한 것은 아니다.

한국어 결과는 Hybrid 실험의 이유가 되지만 정답은 아니다

한국어 결과만 보면 결합 효과가 크다.

BM25와 mDPR의 nDCG@10이 같아도 찾은 문서까지 같다는 뜻은 아니다. Hybrid 결과를 보면 서로 다른 후보를 보완했을 가능성이 높다. 사내 한국어 검색에서도 BM25-only와 Dense-only뿐 아니라 결합을 반드시 비교할 이유는 생겼다.

하지만 여기서 0.609를 MES 예상 성능으로 옮기면 안 된다.

MIRACL은 자연어 질문 + Wikipedia passage + 정보성 정답
MES는 품번 + 화면 ID + SOP + 장애 기록 + 표 + 실시간 업무 데이터

같은 한국어라도 relevance를 결정하는 신호가 다르다. Wikipedia에서는 의미가 통하는 설명이 중요하지만, WO-20260721-0031에서는 한 글자 차이가 다른 작업 지시를 뜻할 수 있다.

평균은 언어별 실패를 숨겼다

Hybrid가 항상 이긴 것은 아니다.

• Indonesian nDCG@10은 BM25 0.449, mDPR 0.272, Hybrid 0.443이었다.
• Yoruba nDCG@10은 BM25 0.406, mDPR 0.396, Hybrid 0.374였다.
• Yoruba에서는 mColBERT가 0.561로 가장 높았다.

특히 Yoruba는 단순 결합이 두 입력보다 모두 낮았다. 점수를 정규화해도 잘못된 dense signal을 같은 비중으로 섞으면 lexical ranking을 해칠 수 있다는 사례다. 0.5 대 0.5라는 설정이 평균에서는 강했지만 언어별 최적값은 아니었다.

이 결과를 보고 “Hybrid가 좋다”보다 “Hybrid 가중치는 validation 대상이다”라는 문장이 더 정확하다고 생각했다.

그럼 어떤 경우에 쓰면 좋을까

MIRACL dataset을 쓰기 좋은 경우

• 같은 언어 안에서 검색하는 multilingual retriever의 기본 성능을 비교할 때
• 번역 query가 아니라 native speaker가 작성한 query로 평가하고 싶을 때
• BM25, Dense, multi-vector의 언어별 실패를 비교할 때
• 18개 언어에 걸친 fine-tuning data와 hard negative가 필요할 때
• 평균뿐 아니라 언어별 nDCG@10과 Recall@100을 확인할 때

반대로 cross-lingual 검색, 최신 web 검색, 표·코드 중심 검색, 긴 문서 전체 검색의 대표 benchmark로 쓰기에는 범위가 맞지 않는다.

BM25+mDPR 결합을 쓰기 좋은 경우

query와 document가 같은 언어이고 다음 두 실패가 함께 존재할 때 먼저 시도할 baseline으로 좋다.

BM25는 같은 의미인데 단어가 다르면 놓친다.
Dense는 고유명사·숫자·희귀 term의 표면형을 놓친다.

두 retriever의 Recall@k를 따로 측정했을 때 각자만 찾는 정답이 존재해야 결합할 이유가 생긴다. 후보가 거의 같다면 비용만 늘 수 있다.

과연 이것이 정답일까

내 답은 아니다. MIRACL은 “항상 Hybrid를 써라”는 결론보다, 다국어 검색에서도 하나의 retriever만 보고 결론 내리지 말라는 실험 근거에 가깝다.

정답으로 일반화할 수 없는 이유는 네 가지다.

1. 평가 corpus가 Wikipedia passage다.
2. query는 native speaker가 작성했지만 Wikipedia prompt에서 출발한 정보성 질문이다.
3. qrels는 BM25·mDPR·mColBERT의 상위 후보 안에서 만들어졌다.
4. Hybrid 가중치 0.5는 언어별·query별로 tuning하지 않은 고정값이다.

그리고 논문이 비교한 mDPR과 mColBERT는 영어 MS MARCO로 fine-tuning한 당시 baseline이다. 이 결과만으로 현재의 모든 Dense model이나 learned sparse model의 우열을 정할 수도 없다.

이것보다 더 좋은 것은 무엇일까

“더 좋다”의 기준부터 나눠야 했다.

이 중 하나가 항상 MIRACL Hybrid보다 낫다는 뜻은 아니다. 예를 들어 reranker는 후보에 정답이 없으면 복구하지 못하고, multi-vector는 index와 연산 비용이 커진다. learned sparse도 품번을 exact key로 보존하는 기능을 대신하지 않는다.

MES에서는 하나의 더 강한 retriever보다 routing이 더 나을 수 있다고 생각한다.

identifier query → exact lookup
live value query → API / SQL
document query   → BM25 + Dense candidates
ranking failure  → selected reranker

이 구조는 MIRACL의 결론이 아니라, 논문에서 확인한 검색 방식의 차이를 MES 데이터 경계에 대입한 설계 가설이다.

새로 배운 것

다국어 dataset도 번역 방식부터 확인해야 한다

언어가 18개라는 숫자만 보고 multilingual이라고 끝내면 안 됐다. query가 실제 native speaker의 질문인지, 영어에서 번역됐는지, corpus와 query의 언어가 같은지부터 봐야 했다. multilingual과 cross-lingual도 같은 평가가 아니다.

qrels는 검색 모델과 독립적으로 생기지 않는다

MIRACL은 세 종류의 retriever를 섞어 후보 pool을 넓혔다. 좋은 설계라고 생각한다. 동시에 정답 판정 범위는 여전히 그 세 방식의 검색 결과에 묶인다. benchmark score를 볼 때 model뿐 아니라 candidate pool 생성 방식도 같이 기록해야 한다.

Hybrid의 핵심은 모델 개수가 아니라 서로 다른 오류다

BM25와 Dense를 켰다는 사실만으로 결합 가치가 생기지 않는다. 각각만 찾은 relevant document가 얼마나 있는지, 합쳤을 때 Recall@k가 오르는지 확인해야 한다. 그다음에 점수 또는 rank를 어떻게 합칠지 정해야 한다.

언어 평균은 서비스 평균이 아니다

MIRACL 전체 평균에서는 Hybrid가 강했지만 Indonesian과 Yoruba에서는 예외가 나왔다. 사내 평가도 전체 평균 하나로 끝내면 품번 검색의 실패와 자연어 장애 검색의 개선이 서로 지워질 수 있다. 언어 대신 query 유형별로 같은 문제가 생긴다.

느낀 점

이 논문을 읽기 전에는 multilingual retrieval을 모델의 언어 지원 개수로 생각했다. 읽고 나서는 좋은 다국어 검색을 만들기 전에 좋은 다국어 질문과 정답을 만드는 비용이 먼저 보였다. 31명의 native speaker와 10,000시간 이상의 작업은 embedding model 하나를 고르는 것보다 평가 데이터가 더 어려운 문제일 수 있다는 점을 보여줬다.

Hybrid 결과도 생각을 바꿨다. Dense가 BM25를 대체하는 순서가 아니라, 둘이 다른 실수를 하면 같이 남을 수 있다. 반대로 Yoruba처럼 결합이 악화된 결과를 보면 두 모델을 합쳤다는 사실 자체에는 가치가 없다. 가중치와 후보 구성까지 포함해 검증해야 하나의 검색 방식이 된다.

가장 경계하게 된 문장은 “한국어 benchmark에서 0.609가 나왔다”이다. 사실이지만, 이 문장만 남으면 MES에서도 검증된 것처럼 읽힌다. 내가 가져갈 수 있는 것은 점수가 아니라 다음 실험 순서다.

한국어에서도 BM25와 Dense의 오류가 달랐는지 확인하고, 같지 않다면 결합이 그 차이를 실제로 줄이는지 측정한다.

이 논문의 한계

• Wikipedia passage retrieval이라 기업 문서, 코드, 표, 실시간 데이터와 성격이 다르다.
• query가 자연어이지만 Wikipedia prompt에서 유도됐다.
• relevance는 binary label이고 query-passage 쌍마다 한 annotator가 판정했다.
• 주로 세 baseline의 상위 후보를 판정했으므로 pool 바깥의 관련 passage는 누락될 수 있다.
• 긴 문서 전체 검색과 cross-lingual retrieval을 직접 평가하지 않는다.
• 평균 Hybrid는 강했지만 언어별 최적 가중치와 비용을 탐색한 논문은 아니다.

MES에 적용한다면 다음에 확인할 것

1. 실제 query를 품번, 화면명, 절차, 장애 증상, 지표 정의로 나눈다.
2. exact lookup, BM25, Dense 각각의 Recall@k와 독점 hit를 기록한다.
3. score fusion과 rank fusion을 같은 candidate budget에서 비교한다.
4. 전체 평균과 query 유형별 결과를 함께 본다.
5. 한국어 analyzer, 사용자 사전, 품번용 exact field를 별도 실험 축으로 둔다.
6. latency와 index size를 품질 점수 옆에 기록한다.
7. 새 retriever가 찾은 미판정 문서를 사람이 다시 확인해 qrels 누락을 찾는다.

MIRACL은 MES 검색의 답을 주지 않았다. 대신 공개 benchmark를 사내 정답처럼 복사하기 전에, query와 qrels가 만들어진 과정을 먼저 읽어야 한다는 기준을 줬다.

Reference

• Xinyu Zhang, Nandan Thakur, Odunayo Ogundepo, Ehsan Kamalloo, David Alfonso-Hermelo, Xiaoguang Li, Qun Liu, Mehdi Rezagholizadeh, Jimmy Lin. MIRACL 논문. TACL, 2023.