🔍 Multi-Query Retriever RAG: AI의 문서 검색 정확도를 획기적으로 향상시키는 방법

발행: 21시간 전 (2025년 12월 7일 오후 04:34 GMT+9)

7 min read

원문: Dev.to

Source: Dev.to

문제: 표준 RAG가 실패하는 이유

어휘 불일치 문제

아름다운 RAG 시스템을 구축했다고 상상해 보세요. 수천 개의 문서를 인덱싱하고, 임베딩을 만들고, 챗봇을 배포했습니다. 그런데 사용자들이 계속 불평합니다: “AI가 관련 정보를 찾지 못해요!”

표준 RAG는 단일 쿼리 임베딩만을 사용해 유사한 문서를 찾습니다. 문제는 사용자는 문서가 쓰여진 방식과 다르게 질문한다는 점입니다.

실제 사례: 어휘 격차

사례 1: IT 지원 악몽

👤 사용자 질문:      "컴퓨터가 느려요, 어떻게 고치나요?"
📄 문서 내용:        "시스템 지연에 대한 성능 최적화 기법"
❌ 결과:             놓침! 임베딩이 너무 다름.

사례 2: 영업 질문

👤 사용자 질문:      "이번 달에 마감되는 딜을 보여줘"
📄 문서 내용:        "현재 기간에 마감일이 있는 기회 파이프라인"
❌ 결과:             놓침! "딜" ≠ "기회", "마감" ≠ "마감일"

사례 3: 의료 문의

👤 사용자 질문:      "이 약의 부작용이 뭐에요?"
📄 문서 내용:        "의약 화합물에 대한 이상 반응 및 금기 사항"
❌ 결과:             놓침! 일상 언어 vs. 의료 용어

사례 4: 개발자의 좌절

👤 사용자 질문:      "왜 내 API 호출이 실패하나요?"
📄 문서 내용:        "HTTP 요청 오류 처리 및 예외 관리"
❌ 결과:             놓침! "실패" ≠ "오류 처리"

사례 5: 경영진 대시보드

👤 사용자 질문:      "팀은 어떻게 하고 있나요?"
📄 문서 내용:        "분기별 성과 지표 및 KPI 분석"
❌ 결과:             놓침! 캐주얼 질문 vs. 공식 보고서 언어

사례 6: 혼란스러운 고객

👤 사용자 질문:      "내 물건이 안 돼요"
📄 문서 내용:        "장치 오작동 절차에 대한 트러블슈팅"
❌ 결과:             놓침! 모호한 사용자 언어 vs. 기술 문서

aha 순간

“문서에 완벽한 답이 있는데 사용자가 질문을 잘못했어요!”

아니요, 사용자는 잘못 질문한 것이 아니라 사람처럼 질문한 겁니다. 단순 RAG는 사용자가 문서 작성자처럼 생각하길 기대하는데, 이는 역행하는 접근입니다.

사용자가 묻는 방식	문서가 쓰여진 방식
“더 빠르게 만들어”	“성능 최적화”
“고장났어”	“오류 상태 감지”
“비용을 절감하고 싶어”	“비용 절감 전략”
“누가 이기고 있어?”	“경쟁 분석 지표”
“다음 단계는?”	“추천 액션 아이템”

이 어휘 격차가 RAG 정확도를 크게 떨어뜨립니다.

단일 관점 제한

표준 RAG는 질문을 한 관점에서만 바라봅니다:

사용자 질문: "에이전트는 어떻게 작동하나요?"
        │
        ▼
단일 쿼리 임베딩 → 벡터 검색 → 제한된 결과

다른 용어를 사용해 같은 개념을 다루는 문서는 완전히 놓치게 됩니다.

테스트에서 얻은 실제 통계

쿼리 유형	단순 RAG 놓침 비율	절대 찾지 못한 문서
단순 쿼리	5‑10%	최소
복합 쿼리	15‑25%	상당히 많음
모호한 쿼리	30‑40%	많은 관련 문서

단순 RAG에서는 관련 문서의 최대 40 %가 보이지 않을 수 있습니다.

멀티-쿼리 RAG란?

정의

멀티-쿼리 RAG(Retrieval‑Augmented Generation)는 LLM을 사용해 사용자의 쿼리를 여러 변형으로 생성한 뒤, 모든 변형으로 검색하고 결과를 병합합니다. 하나의 쿼리 대신 같은 질문을 3‑5가지 다른 표현으로 검색합니다.

핵심 인사이트

“질문을 다섯 가지 다른 방식으로 하면, 한 번만 물어봤을 때는 절대 찾지 못한 답을 발견하게 된다.”

멀티-쿼리 RAG는 LLM을 활용해 자동으로 질문을 재구성함으로써 다음을 포착합니다:

다른 어휘(동의어, 전문 용어)
다른 관점(사용자 vs. 전문가)
다른 구체성 수준(광범위 vs. 좁음)
다른 구조(질문 vs. 서술)

멀티-쿼리 RAG 작동 방식

단계별 프로세스

Step 1: 사용자 쿼리 수신

User query input

Step 2: 쿼리 변형 생성 (LLM)

LLM generates variations

Step 3: 모든 변형으로 벡터 데이터베이스 검색
각 생성된 쿼리를 임베딩하고 벡터 스토어에서 후보 문서를 가져옵니다.

Step 4: 결과 병합 및 순위 매기기
모든 쿼리의 결과를 결합하고, 중복을 제거한 뒤 (예: reciprocal rank fusion 또는 cross‑encoder 사용) 재순위합니다.

Step 5: 검색된 컨텍스트를 생성 모델에 전달
최종적으로 선정된 관련 구절들을 LLM에 입력해 답변을 생성합니다.