1. 왜 이 평가를 진행했는가?
벡터 검색은 RAG 아키텍처의 핵심 요소입니다. Jina v3 출시 이후, 다국어와 장문에 대한 높은 점수에도 불구하고 점수만으로 실제 사용 가능성은 판단할 수 없습니다. 우리는 세 가지 주요 문제에 집중했습니다:
- 다국어 검색 방향성: 한글에서 영어로 또는 그 반대의 경우, 성능 차이는 없는가?
- 규모 안정성: 5천 문서 테스트 결과를 10만 규모의 실제 데이터베이스에 직접 적용할 수 있는가?
- 장문-장문 검색의 실제 난이도: 장문 쿼리로 장문 문서를 검색하는 것이 실제로 얼마나 효과적인가?
2. 실험 설계 및 데이터셋 구축 (핵심!)
"점수 올리기식 평가"를 피하기 위해 MIRACL을 주 평가 데이터셋으로 사용하고, BRIGHT와 ACORD를 추가하여 장문 검색을 보완적으로 평가했습니다.
주의사항: 장문 검색 테스트 중, MIRACL 문서 본문을 Query로 사용하여 동일한 문서 풀에서 검색하는 비공식 방법을 시도했습니다. 이는 Query와 대상 Document가 동일한 출처에서 나온 것으로, 결과가 과대평가되기 쉽습니다 (예: MRR=1.0). 이는 실제 검색 능력을 나타내지 않습니다! 실제 장문 검색 결과는 BRIGHT/ACORD를 기준으로 해야 합니다.
데이터셋 설명
- MIRACL: 주 평가 데이터셋, 다국어, 규모 (5k/20k/100k), 짧은-긴 문서를 평가.
- BRIGHT (Stack Overflow): 영어 기술 질문으로 긴 기술 문서를 검색. 도메인이 기술적이고, 코드와 전문 용어가 많으며 유사하지만 관련 없는 부정 샘플이 많아 어려움.
- ACORD: 계약서/법률 조항을 검색, 여러 관련 단락에 대한 Query가 많아 모델의 커버리지를 극도로 요구함.
3. 핵심 발견 및 비즈니스 해석
3.1 다국어 검색: 방향성 미스, 노력 손실
Jina v3는 단일 언어 검색에서는 매우 강력하지만 (중/영/프 단일 언어 5k의 MRR은 모두 0.94 이상), 다국어 검색에는 방향성이 있습니다:
- 영-프 상호 검색: 거의 손실 없음, 저위험 시나리오.
- 중→영/프: 사용 가능하지만 순위가 하락 (MRR 유지율 약 91%).
- 영/프→중: 최대 약점, MRR 유지율 84%, 순위 질 하락 가장 심함.
비즈니스 해석: 중국어 지식베이스에서 영어 Query로 검색하면 정답이 첫 페이지 이후로 밀릴 가능성이 큽니다. Reranker나 BM25 혼합 검색을 추가해야 합니다.
3.2 규모 확장: 다국어 검색 피해 증가
문서 풀을 5k에서 100k로 확장했을 때, 다국어 검색의 성능 저하가 더욱 명확해집니다:
- 단일 언어 기준: 100k 규모에서 중국어 단일 언어 MRR은 0.8476 (5k 대비 10.6% 하락).
- 다국어 저하: 예를 들어 프랑스어에서 중국어 검색 시, 100k 규모에서 MRR이 0.8044에서 0.5927로 26.3% 하락합니다.
비즈니스 해석: 규모가 커질수록 유사 부정 샘플이 증가하며, 정답이 비슷한 문서에 의해 눌리는 경향이 있습니다. 5k의 좋은 결과를 100k에 직접 적용해서는 안 됩니다. 대규모 시나리오에서는 Top-10뿐만 아니라 Top-50/100까지 확인해야 합니다.
3.3 장문-장문 검색: 동일 출처 테스트 결과의 과대평가 제거
가장 의외의 결론:
- 동일 출처 장문-장문: MRR = 1.0, Recall@10 = 1.0 (Query와 대상 문서가 동일 출처이므로 만점이 필연적).
- BRIGHT (117개 Query, 100k 문서 풀): MRR이 0.1755로 급격히 하락, Recall@10은 0.1593. 코드와 용어, 유사 부정 샘플이 많아 첫 화면 경험과 커버리지가 동시에 붕괴됨.
- ACORD (4k 문서 풀, 다중 양성 사례): Hit@100은 1.0 (각 문제마다 Top100에서 적중), 그러나 Recall@100은 0.3082. 법무 계약 조항은 종종 하나의 Query에 여러 관련 단락이 있어, 벡터 검색으로 모든 관련 부분을 찾기 어렵습니다.
비즈니스 해석: 실제 장문 작업은 생각보다 어렵습니다. Jina v3는 장문 도메인의 기본 리콜로 사용할 수 있지만, 완전한 검색 솔루션으로는 부족합니다.
4. 최적 아키텍처 제안: 기본 설정만으로는 안 된다!
평가는 다음과 같은 아키텍처를 추천합니다:
[사용자 Query]
│
▼
┌─────────────────────────────────────────────┐
│ Stage 1: 넓은 리콜 │
│ - Jina v3 벡터 검색 (Top-100 선택) │
│ - BM25 키워드 검색 (Top-50 선택) │
│ (참고: 중국어 시나리오에서는 jieba 등의 형태소 분석기 필요) │
│ - 병합 및 중복 제거 │
└─────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────┐
│ Stage 2: 재정렬 │
│ - Cross-Encoder 모델 도입 │
│ - 문서 구조/제목 필드를 이용한 정밀 정렬 │
└─────────────────────────────────────────────┘
│
▼
[LLM에 입력하여 답변 생성]
핵심 아이디어: Jina v3로 기본 리콜을 보장하고, Reranker로 순위 문제를 해결하며, BM25로 외국어 검색 및 키워드 정확 매칭 문제를 해결합니다.
5. 복원 및 코드 가이드
평가를 직접 실행할 수 있도록 핵심 스크립트를 공유합니다:
- 데이터셋 구축:
build_datasets.py로 MIRACL/BRIGHT/ACORD 서브셋 생성. - 지표 계산:
summary.py로 MRR/Recall/NDCG 합산 CSV 생성.
# 예제: 평가 파이프라인 실행 방법
# 1. MIRACL / BRIGHT / ACORD 3개의 합산 CSV 생성
python summary.py
# 2. 시각화 차트 업데이트
python visualize.py
# 3. 확장 평가 실행
python run_extend_eval_acord_bright.py